From stefan.lk.hakansson@ericsson.com Fri Jul 1 05:33: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 3615A11E929D for ; Fri, 1 Jul 2011 05:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, 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 rVHxWdwU+50m for ; Fri, 1 Jul 2011 05:33:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5203011E9765 for ; Fri, 1 Jul 2011 05:10:31 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-97-4e0db930b8d3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.B9.09774.039BD0E4; Fri, 1 Jul 2011 14:10:24 +0200 (CEST) Received: from [150.132.141.128] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 1 Jul 2011 14:10:23 +0200 Message-ID: <4E0DB92F.8010501@ericsson.com> Date: Fri, 1 Jul 2011 14:10: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.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20110630004852.10947.88695.idtracker@ietfa.amsl.com> <910D1894-3B1D-49CA-BAEF-9F50FF2B4ADB@skype.net> In-Reply-To: <910D1894-3B1D-49CA-BAEF-9F50FF2B4ADB@skype.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [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: Fri, 01 Jul 2011 12:33:47 -0000 Reading the draft I get the impression that the intention is to multiplex (multiple) RTP streams with arbitrary datagrams on the same 5-tuple. In that light the method lacks IMO: * There is no multiplexing support for different RTP flows - as discussed at the Interim meeting session separation should be maintained * There is no support for rate/congestion control of the datagrams * There is no support for multiplexing different datagram flows (the need for this can be argued though - could be done by the web app) Stefan On 2011-06-30 02:50, Matthew Kaufman wrote: > 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* >> >> 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 "compatible" with RTP and RTCP, and STUN usage of a >> shared >> UDP address and port. >> >> >> >> >> The IETF Secretariat > From dzonatas@gmail.com Fri Jul 1 08:12: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 A0F709E800A for ; Fri, 1 Jul 2011 08:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.243 X-Spam-Level: X-Spam-Status: No, score=-4.243 tagged_above=-999 required=5 tests=[AWL=-0.644, 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 im4oB-IVbFzE for ; Fri, 1 Jul 2011 08:12:51 -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 85EFF21F8527 for ; Fri, 1 Jul 2011 08:11:31 -0700 (PDT) Received: by pzk5 with SMTP id 5so3943805pzk.31 for ; Fri, 01 Jul 2011 08:11:31 -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=jOkzhj65CgU6IPMylGAUZy4PC2dF9mWpBXQTIwVArpg=; b=p3xIjTrvQ3xlHYnFojQ0SIn2azixbJJb/U4GYnw/B29tbDRVTZ2mBEkw3XHyhNbkom a5/PyzIQDZL8lPcz9rmwH59y+ZvTX9HR5zLwhtf+wMqb5vLXVOQgP2lRYx4nC9WK+NvN 1FHNy1IlZbuI5YxkO/myckOTgAFpCbUCfAkJk= Received: by 10.68.8.231 with SMTP id u7mr3548976pba.401.1309533091168; Fri, 01 Jul 2011 08:11:31 -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 i9sm2044098pbk.52.2011.07.01.08.11.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:11:30 -0700 (PDT) Message-ID: <4E0DE382.9070309@gmail.com> Date: Fri, 01 Jul 2011 08:10:58 -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: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> In-Reply-To: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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 15:12:52 -0000 Hi, I read the entire overview. Only one concern, in 2.4 Terminology: > Real-time media: Media where generation of content and display of > content are intended to occur closely together in time (on the > order of no more than hundreds of milliseconds). Can that just read: > Real-time media: Media where generation of content and display of > content are intended to occur closely together in a given time scale. I've found early specification of date systems may affect assets in ways unintended (or implied). There is no simple cure, so I think this is clearer without the noted "hundreds of milliseconds", there. Some have tried to build "authoritative" dates from such real-time mechanics. Others pass that date thinking it is part of the asset. I've seen it happen, so I'm just thinking it would be nice to have some way to say that was not intended, yet I haven't found any. On 06/30/2011 10:52 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Overview: Real Time Protocols for Brower-based Applications > 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 > _______________________________________________ > 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 ton.kalker@gmail.com Fri Jul 1 19:22: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 5D67621F8C13; Fri, 1 Jul 2011 19:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOWH9zigNCvw; Fri, 1 Jul 2011 19:22:55 -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 193DD21F8CAA; Fri, 1 Jul 2011 19:22:37 -0700 (PDT) Received: by vxi40 with SMTP id 40so3367549vxi.31 for ; Fri, 01 Jul 2011 19:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type; bh=XRkHrS45oHdUJDhkA6XN3l+lyasAQhUPvT4s85iRe5w=; b=X7ZQTItawbPyfXEEWdMJJpea53XsytSkKXJ8EcsAGKQ9/REcrje9VbpYB/Bw1E+Y3O OKwTlrVAuGwA1AuP4/rF4vebYxPa+YYEcYU1tO1wXiYpvu1ftJyskZkCeMV8RGzA64oC +NL4BsjpRjoGhQfPHfNMhATlGA/SYeAhuSwx4= Received: by 10.220.15.194 with SMTP id l2mr1388658vca.242.1309573354620; Fri, 01 Jul 2011 19:22:34 -0700 (PDT) References: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> In-Reply-To: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (iPad Mail 8J3) From: Ton Kalker Date: Fri, 1 Jul 2011 19:22:30 -0700 Message-ID: <-2659032708503533090@unknownmsgid> To: "internet-drafts@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [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: Sat, 02 Jul 2011 02:22:56 -0000 One minor remark: the definition of echo cancelation in this document is non-standard. The current definition addresses only a particular instance of echo. The general definition would be the suppression of acoustical feedback loops below perceptually noticeable levels. Ton Sent from my tPad e ton.kalker@{huawei.com,gmail.com,ieee.org} c +1.831.917.1350 On Jun 30, 2011, at 10:52 PM, "internet-drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Overview: Real Time Protocols for Brower-based Applications > 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Sun Jul 3 11:28: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 E7F9611E807E for ; Sun, 3 Jul 2011 11:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.036 X-Spam-Level: X-Spam-Status: No, score=-5.036 tagged_above=-999 required=5 tests=[AWL=-1.437, 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 cefWFfxJMiEa for ; Sun, 3 Jul 2011 11:28:09 -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 52C3B11E807C for ; Sun, 3 Jul 2011 11:28:09 -0700 (PDT) Received: by pzk5 with SMTP id 5so24598pzk.31 for ; Sun, 03 Jul 2011 11:28:09 -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=uO1x5Jec0v0qD2S7osllF5Wq6zIKU7veRRWpW64F19E=; b=i68qnMuCbv/35FMCJhE6Hv69OJqDA95bFHYsipRVd4MfA4jTKyAQtbBWhqGoFvuQuc JZqEu1lW2kJfFqEJnSYWIO5hM8CwVNnMj39OL9eXz40PqetRJ9eyvU1HGjxNgZrpRp9I 3PEpAyuykiNhn9Ww0f3GjgcT7rF/YCEwO6Htk= Received: by 10.68.40.66 with SMTP id v2mr6584963pbk.370.1309717688901; Sun, 03 Jul 2011 11:28:08 -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 i9sm3421228pbk.36.2011.07.03.11.28.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jul 2011 11:28:07 -0700 (PDT) Message-ID: <4E10B49D.2000908@gmail.com> Date: Sun, 03 Jul 2011 11:27: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: Dzonatas Sol , rtcweb@ietf.org References: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> <4E0DE382.9070309@gmail.com> In-Reply-To: <4E0DE382.9070309@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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: Sun, 03 Jul 2011 18:28:10 -0000 Before another glossary action happens, let me get this in (can't wait for tomorrow): > Real-time media: Media where generation of content and display of > content are intended to occur closely together in a given time scale. """ Real-time media: Media where generation of content and display of content are intended to occur closely together in a given time scale between known ahead-of-time (AOT) rate and known just-in-time (JIT) rate. """ On 07/01/2011 08:10 AM, Dzonatas Sol wrote: > Hi, I read the entire overview. Only one concern, in 2.4 Terminology: > > > Real-time media: Media where generation of content and display of > > content are intended to occur closely together in time (on the > > order of no more than hundreds of milliseconds). > > Can that just read: > > > Real-time media: Media where generation of content and display of > > content are intended to occur closely together in a given time > scale. > > I've found early specification of date systems may affect assets in > ways unintended (or implied). There is no simple cure, so I think this > is clearer without the noted "hundreds of milliseconds", there. > > Some have tried to build "authoritative" dates from such real-time > mechanics. Others pass that date thinking it is part of the asset. > I've seen it happen, so I'm just thinking it would be nice to have > some way to say that was not intended, yet I haven't found any. > > On 06/30/2011 10:52 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Real-Time Communication >> in WEB-browsers Working Group of the IETF. >> >> Title : Overview: Real Time Protocols for Brower-based >> Applications >> 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 >> _______________________________________________ >> 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 gonzalo.camarillo@ericsson.com Mon Jul 4 03: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 2198C21F8623 for ; Mon, 4 Jul 2011 03:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EdB9YoorJgxf for ; Mon, 4 Jul 2011 03:01:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD8E21F8622 for ; Mon, 4 Jul 2011 03:01:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-be-4e118f614bd8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A9.7C.09774.16F811E4; Mon, 4 Jul 2011 12:01:05 +0200 (CEST) Received: from [131.160.36.41] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Jul 2011 12:01:05 +0200 Message-ID: <4E118F60.9040209@ericsson.com> Date: Mon, 4 Jul 2011 13:01:04 +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: "igor.faynberg@alcatel-lucent.com" References: <4E00A355.2040309@w3.org> <4E0ACA93.8050500@ericsson.com> <4E0BEC01.4090809@alcatel-lucent.com> In-Reply-To: <4E0BEC01.4090809@alcatel-lucent.com> 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: Mon, 04 Jul 2011 10:01:07 -0000 Hi Igor, note that this is not a joint meeting. This is a W3C meeting (i.e., under W3C rules) that will be organized in the same venue as the IETF. With respect to the scheduling of the meeting, it was unfortunately impossible to find a day that worked for everyone. Saturday was the best trade-off that could be found. Cheers, Gonzalo On 30/06/2011 6:22 AM, Igor Faynberg wrote: > 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From gonzalo.camarillo@ericsson.com Mon Jul 4 03:02: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 B45F421F8629 for ; Mon, 4 Jul 2011 03:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 8dbzBSpoznV1 for ; Mon, 4 Jul 2011 03:02:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E804821F84EF for ; Mon, 4 Jul 2011 03:02:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1a-4e118fbc103c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 63.FA.20773.CBF811E4; Mon, 4 Jul 2011 12:02:37 +0200 (CEST) Received: from [131.160.36.41] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Jul 2011 12:02:36 +0200 Message-ID: <4E118FBC.1000401@ericsson.com> Date: Mon, 4 Jul 2011 13:02:36 +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: rtcweb@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Fwd: W3C WebRTC working group meeting: Saturday, July 23 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: Mon, 04 Jul 2011 10:02:38 -0000 Folks, FYI. This meeting has now also been announced on the general IETF announce list (see email below). Cheers, Gonzalo -------- Original Message -------- Subject: W3C WebRTC working group meeting: Saturday, July 23 2011 Date: Thu, 30 Jun 2011 20:32:29 +0200 From: Alexa Morris To: ietf-announce@ietf.org The W3C Web Real-Time Communications working group will meet on Saturday 23 July 2011 afternoon, starting at 2PM, in Quebec City, Canada, co-located with the IETF Meeting. The choice of the date and place is meant to favor synergies between the W3C WebRTC and the IETF RTCWEB groups. IETF attendees, especially those following the RTCWEB WG, are welcome to attend this W3C face-to-face meeting as meeting guests. Attendees need to register before July 15th using the following URL: http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/ Note that this is a W3C meeting and, thus, it will be held under W3C rules. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From internet-drafts@ietf.org Mon Jul 4 04:37: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 BF70D21F8722; Mon, 4 Jul 2011 04:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 wCLe+dmA1E1z; Mon, 4 Jul 2011 04:37:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FCB21F86DA; Mon, 4 Jul 2011 04:37:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704113719.18992.44580.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 04:37:19 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-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, 04 Jul 2011 11:37:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-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-01.txt Pages : 15 Date : 2011-07-04 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-01.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-01.txt From stefan.lk.hakansson@ericsson.com Mon Jul 4 04:41: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 E88E21F0C40 for ; Mon, 4 Jul 2011 04:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.138, 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 9tCVjl5oKBZn for ; Mon, 4 Jul 2011 04:41:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE941F0C36 for ; Mon, 4 Jul 2011 04:41:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ae-4e11a7024d80 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 21.7A.20773.207A11E4; Mon, 4 Jul 2011 13:41:54 +0200 (CEST) Received: from [153.88.47.89] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Jul 2011 13:41:53 +0200 Message-ID: <4E11A6FE.809@ericsson.com> Date: Mon, 4 Jul 2011 13:41:50 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= 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="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-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, 04 Jul 2011 11:41:56 -0000 I've uploaded a new version of the use-case and requirements doc. The changes are the ones I proposed in an earlier mail (). I received no responses to that mail; if people have problems with (some or all of) the changes I made I guess we will have to revert them in the next version Stefan -------- Original Message -------- Subject: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-01.txt Date: Mon, 4 Jul 2011 13:37:19 +0200 From: internet-drafts@ietf.org To: Stefan Håkansson LK CC: Stefan Håkansson LK , Göran Eriksson AP , Christer Holmberg A new version of I-D, draft-ietf-rtcweb-use-cases-and-requirements-01.txt has been successfully submitted by Stefan Hakansson and posted to the IETF repository. Filename: draft-ietf-rtcweb-use-cases-and-requirements Revision: 01 Title: Web Real-Time Communication Use-cases and Requirements Creation date: 2011-07-04 WG ID: rtcweb Number of pages: 15 Abstract: 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. The IETF Secretariat From cbran@cisco.com Mon Jul 4 12:57: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 811A811E810B for ; Mon, 4 Jul 2011 12:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPeX556kS4Zo for ; Mon, 4 Jul 2011 12:57:29 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 921B211E8108 for ; Mon, 4 Jul 2011 12:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=813; q=dns/txt; s=iport; t=1309809449; x=1311019049; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=ksjDwEwpUvdz5IuEfU2/p7Xw2fcky7aG2us5fpleoSQ=; b=Yi6iZ+j2i4R/ruU8dfkS4WVqZAsh1ABXmwxcSxjN9FAnLT2W5F+bJRJL GbI9hi7ILEDL7z/gFEmnTY5LuwH2O32c/WfOFkVjSMRczcZSpKKBrfXDN QvuR25/wRrviQSNIO2rW2I4UtRhKX8cKrrBczMsufGgk4AThCSbW1pv4w w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAPIZEk6rRDoG/2dsb2JhbABTmQmOc3erHoEinV2GNgSHP4p3hQGLVQ X-IronPort-AV: E=Sophos;i="4.65,475,1304294400"; d="scan'208";a="289693588" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-4.cisco.com with ESMTP; 04 Jul 2011 19:57:29 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p64JvT0P024126 for ; Mon, 4 Jul 2011 19:57:29 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 12:57:29 -0700 Received: from 10.21.124.203 ([10.21.124.203]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Jul 2011 19:57:28 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 04 Jul 2011 12:57:27 -0700 From: cbran To: Message-ID: Thread-Topic: ID-Action: draft-cbran-rtcweb-negotiation-00.txt Thread-Index: Acw6hJlcP2u3HwQwUEe9f0AcJb2jjA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Jul 2011 19:57:29.0206 (UTC) FILETIME=[9AAD8960:01CC3A84] Subject: [rtcweb] ID-Action: draft-cbran-rtcweb-negotiation-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, 04 Jul 2011 19:57:30 -0000 This is message one of five. I have submitted new drafts for RTC-Web: signaling and negotiation methods, media transports, datagram transport for non-media data, and media processing and codecs. Cheers, -Cary A new version of I-D, draft-cbran-rtcweb-negotiation-00.txt has been successfully submitted by Cary Bran and posted to the IETF repository. Filename: draft-cbran-rtcweb-negotiation Revision: 00 Title: RTC-Web Negotiation and Signaling Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document outlines the negotiation and signaling protocols for RTC-Web client application implementation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cbran-rtcweb-negotiation-00.txt From cbran@cisco.com Mon Jul 4 12:57: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 F1CD011E8108 for ; Mon, 4 Jul 2011 12:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzBoNJWG+7o6 for ; Mon, 4 Jul 2011 12:57:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8D11E810F for ; Mon, 4 Jul 2011 12:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=817; q=dns/txt; s=iport; t=1309809456; x=1311019056; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=v/o8ThQD76w8eu8/f2t2HQVswW8wdUT/GfYAAV//U4I=; b=cT8+jlHXrZS0yCvA54HZpZ+P80KhAX4on2lUv66gbY1bMBOVqtf62S5g Y/dNYb39/UhiX87s5Imvxj1p9E1RED/m2wEd41eYF6E3SvkIgLoXE0WmE YwNe4qfMAooceD+omgxEQykqNIjGHkRI2EATRjjZh+R286w0gL9miJYXD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAPIZEk6rRDoJ/2dsb2JhbABTmQmOc3erHoEinV2GNgSHP4p3hQGLVQ X-IronPort-AV: E=Sophos;i="4.65,475,1304294400"; d="scan'208";a="360774280" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2011 19:57:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p64JvaKW029762 for ; Mon, 4 Jul 2011 19:57:36 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 12:57:35 -0700 Received: from 10.21.124.203 ([10.21.124.203]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Jul 2011 19:57:35 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 04 Jul 2011 12:57:35 -0700 From: cbran To: Message-ID: Thread-Topic: ID-Action: draft-cbran-rtcweb-data-00.txt Thread-Index: Acw6hJ4h2whj/MtFYUqZbVbCyhnOLg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Jul 2011 19:57:35.0940 (UTC) FILETIME=[9EB11040:01CC3A84] Subject: [rtcweb] ID-Action: draft-cbran-rtcweb-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: Mon, 04 Jul 2011 19:57:42 -0000 This is message two of five. I have submitted new drafts for RTC-Web: signaling and negotiation methods, media transports, datagram transport for non-media data, and media processing and codecs. Cheers, -Cary A new version of I-D, draft-cbran-rtcweb-data-00.txt has been successfully submitted by Cary Bran and posted to the IETF repository. Filename: draft-cbran-rtcweb-data Revision: 00 Title: RTC-Web Non-Media Data Transport Requirements Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 6 Abstract: This document outlines a protocol and requirements for RTC-Web client application to transmit real-time, non-media data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cbran-rtcweb-data-00.txt From cbran@cisco.com Mon Jul 4 12:57: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 48DE211E8112 for ; Mon, 4 Jul 2011 12:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLDP7TGImBD1 for ; Mon, 4 Jul 2011 12:57:44 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id DECCB11E8111 for ; Mon, 4 Jul 2011 12:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=805; q=dns/txt; s=iport; t=1309809464; x=1311019064; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=8T7ewkDgqdPsiT5n6LfCfYeg3Cdd1Xzv+KwdQuZqA6U=; b=MAYiyYmHJNkmR0rbs6jNXpRrknI3DHWbaRDtRhB7qSJbA5z5pr0rYH9/ gDgqgx1CDknZ4optaFlQqU1Ds/6a3WHynyQPU5yO7okZ8PRczOHgk8dEo mcQiG55AtO3aQnEC+0KjW7GJ2XEDtFvt6j/C/WSMooxCXgHj371F4aYU1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAPIZEk6rRDoG/2dsb2JhbABTmQmOc3erHoEinV2GNgSHP4p3hQGLVQ X-IronPort-AV: E=Sophos;i="4.65,475,1304294400"; d="scan'208";a="289693650" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-4.cisco.com with ESMTP; 04 Jul 2011 19:57:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p64Jvi72024223 for ; Mon, 4 Jul 2011 19:57:44 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 12:57:44 -0700 Received: from 10.21.124.203 ([10.21.124.203]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Jul 2011 19:57:43 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 04 Jul 2011 12:57:43 -0700 From: cbran To: Message-ID: Thread-Topic: ID-Action: draft-cbran-rtcweb-nat-00.txt Thread-Index: Acw6hKLmxYJtrHMCpEaPsjEmm9P7pQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Jul 2011 19:57:44.0581 (UTC) FILETIME=[A3D79350:01CC3A84] Subject: [rtcweb] ID-Action: draft-cbran-rtcweb-nat-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, 04 Jul 2011 19:57:45 -0000 This is message three of five. I have submitted new drafts for RTC-Web: signaling and negotiation methods, media transports, datagram transport for non-media data, and media processing and codecs. Cheers, -Cary A new version of I-D, draft-cbran-rtcweb-nat-00.txt has been successfully submitted by Cary Bran and posted to the IETF repository. Filename: draft-cbran-rtcweb-nat Revision: 00 Title: RTC-Web Network Address Translation Creation date: 2011-07-01 WG ID: Individual Submission Number of pages: 8 Abstract: This document outlines the network address translation (NAT) mechanisms and requirements for RTC-Web client applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cbran-rtcweb-nat-00.txt From cbran@cisco.com Mon Jul 4 12:57: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 4C23811E8119 for ; Mon, 4 Jul 2011 12:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5Zn19J+V7uB for ; Mon, 4 Jul 2011 12:57:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id B28EA11E811A for ; Mon, 4 Jul 2011 12:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=793; q=dns/txt; s=iport; t=1309809471; x=1311019071; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=umi9NLJTIZpiP6YAU2oTmb4YBIyWeoxNz3ze0eyAHt8=; b=DH0GBZdhXGCEcrr3209AtFYII+joKwOsWJ3WB04hq3YnlWoqW2qz9xsT oZzS0IZM0YCLIvvTj3hSbQf7rNodSAm27VpjS3+DTSV41VTiyauVwTgUJ Jouru7vDWv1bnEWP3tyvNC+XRuH/POtevZ9e1riYpM+MbzimPTkyJKt7L s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAPIZEk6rRDoI/2dsb2JhbABTmQmOc3erHoEinV2GNgSHP4p3hQGLVQ X-IronPort-AV: E=Sophos;i="4.65,475,1304294400"; d="scan'208";a="360774326" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2011 19:57:51 +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 p64JvpHW025403 for ; Mon, 4 Jul 2011 19:57:51 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, 4 Jul 2011 12:57:51 -0700 Received: from 10.21.124.203 ([10.21.124.203]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Jul 2011 19:57:50 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 04 Jul 2011 12:57:50 -0700 From: cbran To: Message-ID: Thread-Topic: ID-Action: draft-cbran-rtcweb-media-00.txt Thread-Index: Acw6hKcSgd5F8IYHO02JCmgUV0Eajg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Jul 2011 19:57:51.0407 (UTC) FILETIME=[A7E923F0:01CC3A84] Subject: [rtcweb] ID-Action: draft-cbran-rtcweb-media-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, 04 Jul 2011 19:57:55 -0000 This is message four of five. I have submitted new drafts for RTC-Web: signaling and negotiation methods, media transports, datagram transport for non-media data, and media processing and codecs. Cheers, -Cary A new version of I-D, draft-cbran-rtcweb-media-00.txt has been successfully submitted by Cary Bran and posted to the IETF repository. Filename: draft-cbran-rtcweb-media Revision: 00 Title: RTC-Web Media Transport Requirements Creation date: 2011-06-29 WG ID: Individual Submission Number of pages: 11 Abstract: This document outlines the media transport protocols and requirements for RTC-Web client applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cbran-rtcweb-media-00.txt From cbran@cisco.com Mon Jul 4 12:58: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 5279E11E8110 for ; Mon, 4 Jul 2011 12:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C029-cfLXXWQ for ; Mon, 4 Jul 2011 12:58:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id EB41911E80A0 for ; Mon, 4 Jul 2011 12:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=820; q=dns/txt; s=iport; t=1309809538; x=1311019138; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=1eoT9x7O4i0zvOsZAmt5DpBzwRgVXCdUAq1ZAlztXy0=; b=AiQ18w95yAymXTCKGQ603A0KLZostTfUu7we8rRD8paCiqRhWJu8Xit4 PqFc8kfzPC/gFo1sO8JPuESkoCkiz48Rf1FQW2HBIJI0Ai3ObpyVl3tsv jYmH9wh4AvC1+MSyEfRNhtJlQF7dCspR62MgUmYoCPbvlnJDE9q6UiNry s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAPIZEk6rRDoJ/2dsb2JhbABTmQmOc3erHoEinV2GNgSHP4p3hQGLVQ X-IronPort-AV: E=Sophos;i="4.65,475,1304294400"; d="scan'208";a="360774348" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2011 19:57:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p64JvwfT029912 for ; Mon, 4 Jul 2011 19:57:58 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, 4 Jul 2011 12:57:58 -0700 Received: from 10.21.124.203 ([10.21.124.203]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Jul 2011 19:57:57 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 04 Jul 2011 12:57:57 -0700 From: cbran To: Message-ID: Thread-Topic: ID-Action: draft-cbran-rtcweb-codec-00.txt Thread-Index: Acw6hKs+YfAgoOmuAEuGIRGDheU9dQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Jul 2011 19:57:58.0297 (UTC) FILETIME=[AC047890:01CC3A84] Subject: [rtcweb] ID-Action: draft-cbran-rtcweb-codec-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, 04 Jul 2011 19:58:59 -0000 This is message five of five. I have submitted new drafts for RTC-Web: signaling and negotiation methods, media transports, datagram transport for non-media data, and media processing and codecs. Cheers, -Cary A new version of I-D, draft-cbran-rtcweb-codec-00.txt has been successfully submitted by Cary Bran and posted to the IETF repository. Filename: draft-cbran-rtcweb-codec Revision: 00 Title: RTC-Web Codec and Media Processing Requirements Creation date: 2011-06-28 WG ID: Individual Submission Number of pages: 7 Abstract: This document outlines the codec and media processing requirements for RTC-Web client application and endpoint devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cbran-rtcweb-codec-00.txt From jdrosen@jdrosen.net Mon Jul 4 15:19: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 4AE3A1F0C42 for ; Mon, 4 Jul 2011 15:19:04 -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 nv80MrH+nxx5 for ; Mon, 4 Jul 2011 15:19:03 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.48.15]) by ietfa.amsl.com (Postfix) with ESMTP id CD8831F0C37 for ; Mon, 4 Jul 2011 15:19:03 -0700 (PDT) Received: from pool-173-63-59-84.nwrknj.fios.verizon.net ([173.63.59.84] helo=new-host.home) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdrTq-0003Lt-Sx for rtcweb@ietf.org; Mon, 04 Jul 2011 18:19:03 -0400 Message-ID: <4E123C54.10405@jdrosen.net> Date: Mon, 04 Jul 2011 18:19:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; 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-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-rosenberg-rtcweb-rtpmux-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, 04 Jul 2011 22:19:04 -0000 We put together the draft below to argue in favor of using a single port for multiplexing voice and video traffic over RTP. Looking forward to a lively discussion on this, I am sure.. ;) Thanks, Jonathan R. -------- Original Message -------- Subject: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt Date: Mon, 04 Jul 2011 15:14:25 -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 : Multiplexing of Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time Communications (RTC) Author(s) : Jonathan Rosenberg Cullen Jennings Jon Peterson Matthew Kaufman Eric Rescorla Tim Terriberry Filename : draft-rosenberg-rtcweb-rtpmux-00.txt Pages : 12 Date : 2011-07-04 This document argues that multiplexing of voice and video traffic over a single RTP session should be specified as the baseline mode of operation for multimedia traffic in RTC web. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-rtcweb-rtpmux-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-rosenberg-rtcweb-rtpmux-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 stewe@stewe.org Tue Jul 5 07:39: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 DB35211E809C for ; Tue, 5 Jul 2011 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 m14lZrnzm7Mk for ; Tue, 5 Jul 2011 07:39:22 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF3411E807F for ; Tue, 5 Jul 2011 07:39:21 -0700 (PDT) Received: from [192.168.1.107] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 9565-1743317 for ; Tue, 05 Jul 2011 16:39:19 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 05 Jul 2011 07:39:15 -0700 From: Stephan Wenger To: "rtcweb@ietf.org" Message-ID: Thread-Topic: draft-wenger-rtcweb-layered-codec-00 posted Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392696359_312233" 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] draft-wenger-rtcweb-layered-codec-00 posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Jul 2011 14:39:23 -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_3392696359_312233 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, As promised, Alex Eleftheriadis and myself have thrown together a quick draft outlining the advantages and desirability of layered codecs. You can find it here:http://datatracker.ietf.org/doc/draft-wenger-rtcweb-layered-codec/ Happy reading. Stephan --B_3392696359_312233 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,
As promis= ed, Alex Eleftheriadis and myself have thrown together a quick draft outlini= ng the advantages and desirability of layered codecs.  You can find it = here:http://datatracker.ietf.org/doc/draft-wenger-rtcweb-layered-codec/<= /div>
Happy reading.
Stephan
--B_3392696359_312233-- From fluffy@cisco.com Tue Jul 5 09:00: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 1001F11E8163 for ; Tue, 5 Jul 2011 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 YMZcLR6ZBEa0 for ; Tue, 5 Jul 2011 09:00:50 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 8B91311E818A for ; Tue, 5 Jul 2011 09:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2002; q=dns/txt; s=iport; t=1309881650; x=1311091250; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=f3k25BC7byHGh081kWmXfAi7j/94+pYQ9D0xB7ucdS4=; b=ACdH+koHQHfNFZPq0yhCjJylIWvxGPON/ZRqDWONY6ay/jPnfZO70UNH 52YXXxiOTagVzo28fpP4h1Pc6cQW80k02FcuVg9rPA4GBcknIMMwZVxZW r0k3n1AFG9lYTYHCRBMIDWCrccte4QSIfhCgzlRKwwmzbuRU7FaocebVb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskHAIc0E06rRDoH/2dsb2JhbABTmRGOdnerYIEinW+GNgSHP4p3hHiLXQ X-IronPort-AV: E=Sophos;i="4.65,479,1304294400"; d="scan'208";a="290381729" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2011 16:00:50 +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 p65G0nAY011343 for ; Tue, 5 Jul 2011 16:00:49 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2011 10:00:48 -0600 Message-Id: <3017EF1A-D479-4D61-B9B2-BECD5DA043C0@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] draft rtcweb agenda for IETF 81 - version 2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Jul 2011 16:00:51 -0000 Here is the rough agenda that Ted, Magnus, and I have been thinking = of..... bash away ... Agenda - version 2 Agenda Bash 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 ( 20 min ) draft-ietf-rtcweb-use-cases-and-requirements =20 Architecture and System Overview ( 20 min) draft-ietf-rtcweb-overview =20 Security ( 20 min ) draft-rescorla-rtcweb-security draft-kaufman-rtcweb-security-ui draft-johnston-rtcweb-media-privacy NAT ( 20 min) draft-kaufman-rtcweb-traversal =20 draft-cbran-rtcweb-nat =20 =20 Start of Session two (Chairs) - 5 min =20 Negotiation & signaling (25 min) draft-cbran-rtcweb-negotiation =20 Media (other than multiplexing) (20 min) draft-perkins-rtcweb-rtp-usage draft-cbran-rtcweb-media =20 =20 Datagram transports (20 min) draft-cbran-rtcweb-data Multiplexing (30 min) draft-rosenberg-rtcweb-rtpmux draft-perkins-rtcweb-rtp-usage=20 * focus on how/if we multiplex on one UDP port=20 Media processing & codec (20 min) draft-cbran-rtcweb-codec draft-alvestrand-dispatch-rtcweb-protocols * focus on requirements for codecs=20 =20 =20 From stewe@stewe.org Tue Jul 5 09:45:24 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 61E9D11E81A5 for ; Tue, 5 Jul 2011 09:45:24 -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 ZpgrUe0yMJ5Q for ; Tue, 5 Jul 2011 09:45:23 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 54FDD11E8118 for ; Tue, 5 Jul 2011 09:45:21 -0700 (PDT) Received: from [192.168.1.107] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 9668-1743317 for multiple; Tue, 05 Jul 2011 18:45:21 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 05 Jul 2011 09:45:14 -0700 From: Stephan Wenger To: Cullen Jennings , Message-ID: Thread-Topic: [rtcweb] draft rtcweb agenda for IETF 81 - version 2 In-Reply-To: <3017EF1A-D479-4D61-B9B2-BECD5DA043C0@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Re: [rtcweb] draft rtcweb agenda for IETF 81 - version 2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Jul 2011 16:45:24 -0000 Hi Cullen, all, We would like to have a few minute sin the last subsection to introduce layered codecs: draft-wenger-rtcweb-layered-codec-00 Thanks, Stephan On 7.5.2011 09:00 , "Cullen Jennings" wrote: > >Here is the rough agenda that Ted, Magnus, and I have been thinking >of..... bash away ... > > > >Agenda - version 2 > > Agenda Bash > Status report (Chairs) - 10 min > > Liaison Report from W3C WebRTC -(WebRTC Chairs) - 10 min > The W3C will have just had a meeting the Saturday before > > 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 > > Use Cases ( 20 min ) > draft-ietf-rtcweb-use-cases-and-requirements > > Architecture and System Overview ( 20 min) > draft-ietf-rtcweb-overview > > Security ( 20 min ) > draft-rescorla-rtcweb-security > draft-kaufman-rtcweb-security-ui > draft-johnston-rtcweb-media-privacy > > NAT ( 20 min) > draft-kaufman-rtcweb-traversal > draft-cbran-rtcweb-nat > > > > Start of Session two (Chairs) - 5 min > > Negotiation & signaling (25 min) > draft-cbran-rtcweb-negotiation > > > Media (other than multiplexing) (20 min) > draft-perkins-rtcweb-rtp-usage > draft-cbran-rtcweb-media > > > Datagram transports (20 min) > draft-cbran-rtcweb-data > > > Multiplexing (30 min) > draft-rosenberg-rtcweb-rtpmux > draft-perkins-rtcweb-rtp-usage > * focus on how/if we multiplex on one UDP port > > > Media processing & codec (20 min) > draft-cbran-rtcweb-codec > draft-alvestrand-dispatch-rtcweb-protocols > * focus on requirements for codecs > > > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Jul 5 15:30: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 2250021F88E4 for ; Tue, 5 Jul 2011 15:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3-WESo3cD5e for ; Tue, 5 Jul 2011 15:30:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 343E321F88C5 for ; Tue, 5 Jul 2011 15:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5593; q=dns/txt; s=iport; t=1309905022; x=1311114622; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cF4X17AjUzzfDaqmQCDPzvoKLqQdQJoEOwHcKzJPN+g=; b=dxVm2jeiya4AIWB6X/QJJPwBpKuiIROG8oMB7gsn9lEibP3TsFkXyBjs AbGy0qXgmGqclzel+mCy6ZFcZPQRoSPyvkgsHk8Fxdlj89waltVPSDsLT bs2aZQPZEiFPtgYgWUql2zHpnEYYWEqnZBtmRlD+BMQC4tii07WE0Ylo4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABmQE06rRDoI/2dsb2JhbABTqA13iHqlcZ4ShjYEhz+Kd4R4i10 X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208";a="361775840" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 22:30:21 +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 p65MUK2Y018560; Tue, 5 Jul 2011 22:30:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Tue, 5 Jul 2011 16:30:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4D8B4033-8A5E-464E-82E7-983386498064@cisco.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> <46A1DF3F04371240B504290A071B4DB601301A8D@SZXEML501-MBS.china.huawei.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, 05 Jul 2011 22:30:23 -0000 Agree with folks on this thread about this being a way for the receiver = to tell the send it's preferences - Perhaps the receiver might indicate = that it would like 1080P video but the best the sender can do is 720P = because that is the size of camera they have. In this case the sender = does what the sender wants ignoring the receiver. There are other cases = where say the receiver can not decode a bitstream above 768 kbps but the = sender would typically send a stream at a much higher rate than this. In = this case the sender needs to do what the receiver wants. You might have = an old browser that support vp8 and newer version of the browser that = does both vp8 and vp9 and you use vp8 when that is all you have but = prefer vp9 if both sides support it. I'm not sure exactly how to phrase = all this but roughly speaking we need a way for the sender and receiver = to agree on a format that meets the constraints of both and somewhat = optimizes the desiree format within these constraints.=20 On Jun 22, 2011, at 12:06 AM, Stefan H=E5kansson LK wrote: > All, > =20 > this RFC could perhaps be useful for this purpose of signaling display = size: http://www.rfc-editor.org/rfc/rfc6236.txt > =20 > Stefan >=20 > 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:) >=20 > Hi Justin, all, > =20 > 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. > =20 > Best regards, > Bert > =20 > =20 > From: Justin Uberti [mailto:juberti@google.com]=20 > 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:) > =20 > 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. > =20 >=20 > 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. >=20 > Best regards, > Bert >=20 >=20 > -----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:) >=20 >=20 > On Jun 20, 2011, at 1:30 , Harald Alvestrand wrote: >=20 > > 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. >=20 > Consider two different video flows using the same codec ... >=20 > Stream A is 640 x 480 at 1mbps which is this scaled to 320x240 and = displayed >=20 > 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 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell1@jesup.org Tue Jul 5 19:58: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 800EA21F8803 for ; Tue, 5 Jul 2011 19:58:30 -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_15=0.6, J_CHICKENPOX_16=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 kHo-AZ3QTG3d for ; Tue, 5 Jul 2011 19:58:29 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id B40AD21F8802 for ; Tue, 5 Jul 2011 19:58:29 -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 1QeIJp-0001mm-BK for rtcweb@ietf.org; Tue, 05 Jul 2011 21:58:29 -0500 Message-ID: <4E13CE93.9070402@jesup.org> Date: Tue, 05 Jul 2011 22:55:15 -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> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB601301A8D@SZXEML501-MBS.china.huawei.com> <4D8B4033-8A5E-464E-82E7-983386498064@cisco.com> In-Reply-To: <4D8B4033-8A5E-464E-82E7-983386498064@cisco.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 - 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: Wed, 06 Jul 2011 02:58:30 -0000 Resend from the right address... On 7/5/2011 6:30 PM, Cullen Jennings wrote: > Agree with folks on this thread about this being a way for the receiver to tell the send it's preferences - Perhaps the receiver might indicate that it would like 1080P video but the best the sender can do is 720P because that is the size of camera they have. In this case the sender does what the sender wants ignoring the receiver. There are other cases where say the receiver can not decode a bitstream above 768 kbps but the sender would typically send a stream at a much higher rate than this. In this case the sender needs to do what the receiver wants. These sorts of issues are at least partly addressed in the O/A section of the H.264 spec (RFC 6184, update to RFC 3984). Obviously that only applies to H.264. There are also issues about limitations due to the other direction; in particular look at level-asymmetry-allowed and what happens if it's not used. As mentioned, there are issues both of initial negotiation (as implied here) and in-call changes. I think a) the two sides should indicate what they support receiving in negotiation, and b) indicate their initial preferred resolution/etc in negotiation. In-call, there should be a mechanism for changing preference without a full call renegotiation (I suggest an RTCP-FB message), though one could fall back on a full new SDP exchange. > You might have an old browser that support vp8 and newer version of the browser that does both vp8 and vp9 and you use vp8 when that is all you have but prefer vp9 if both sides support it. That's just classic SDP and Offer/Answer: New: m=video 1234 RTP/AVP 98 99 100 a=rtpmap 98 VP9/90000 a=rtpmap 99 VP8/90000 a=rtpmap 100 H264/90000 Old: m=video 1234 RTP/AVP 99 100 a=rtpmap 99 VP8/90000 a=rtpmap 100 H264/90000 > I'm not sure exactly how to phrase all this but roughly speaking we need a way for the sender and receiver to agree on a format that meets the constraints of both and somewhat optimizes the desiree format within these constraints. RFC 6236 certainly looks like a reasonable option to consider; in fact I'd consider it to be the defacto choice barring some problematic limitation. It allows asymmetry within the limits of the codec negotiation; if RFC 6184 is used for H.264 then level asymmetry is allowed. There *might* be an argument for also describing the portions of the decoded window that aren't visible (per the previous conversation). My biggest issue is that they assume it can only be changed via UPDATE or re-INVITE. Maybe that's reasonable, but I have to say I'd lean towards solutions that are direct end-to-end in-call to cut overhead and lower reaction time. Randell > > On Jun 22, 2011, at 12:06 AM, Stefan Hkansson LK wrote: > >> 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 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 >> >> _______________________________________________ >> 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 > > -- Randell Jesup randell-ietf@jesup.org From randell1@jesup.org Tue Jul 5 20:20: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 A565621F8717 for ; Tue, 5 Jul 2011 20:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 7DOOsMt36Yz4 for ; Tue, 5 Jul 2011 20:20:49 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94321F884F for ; Tue, 5 Jul 2011 20:20:49 -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 1QeIfR-0005Y7-0o for rtcweb@ietf.org; Tue, 05 Jul 2011 22:20:49 -0500 Message-ID: <4E13D3CE.8070406@jesup.org> Date: Tue, 05 Jul 2011 23:17:34 -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: <20110630004852.10947.88695.idtracker@ietfa.amsl.com> <910D1894-3B1D-49CA-BAEF-9F50FF2B4ADB@skype.net> In-Reply-To: <910D1894-3B1D-49CA-BAEF-9F50FF2B4ADB@skype.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] 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: Wed, 06 Jul 2011 03:20:51 -0000 On 6/29/2011 8:50 PM, Matthew Kaufman wrote: > 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. http://www.ietf.org/id/draft-kaufman-rtp-compatible-data-00.txt | One alternative considered was to encapsulate the arbitrary datagrams | within RTP as an RTP payload type. However the semantics associated | with RTP are not always appropriate, depending on the type of | arbitrary data being transmitted. This needs to be expanded on. Why are they not appropriate? (Not disagreeing, but state it please.) If this data traverses various SBC/midboxes/NATs-with-ALGs/etc, will the apparent "invalid" nature cause possible breakage? | 5. Security Considerations | | The contents of these messages SHOULD be encrypted. Reuse of the | keying used for an associated RTP session that is using the same IP | address and port MAY be an acceptable method of key specification and | cryptosystem choice. I'd say "The User Message Data of these messages"... to avoid confusion about encryption of the all-zeros 4-byte header. Also: should it say anything about authentication? Congestion control needs to be discussed, even if it's to say that it's the job of a higher or application layer to define. I do want to as part of rtcweb design make congestion handling be unified, whether or not we use a single port (though we probably should use 1 port). -- Randell Jesup randell-ietf@jesup.org From bernard_aboba@hotmail.com Tue Jul 5 23:06: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 285FD21F8603 for ; Tue, 5 Jul 2011 23:06:55 -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 SZSks2REHwe3 for ; Tue, 5 Jul 2011 23:06:54 -0700 (PDT) Received: from blu0-omc3-s7.blu0.hotmail.com (blu0-omc3-s7.blu0.hotmail.com [65.55.116.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBD621F85EC for ; Tue, 5 Jul 2011 23:06:45 -0700 (PDT) Received: from BLU152-W2 ([65.55.116.73]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 23:06:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3c8c217e-a003-49e2-b30d-c5c717d4d46f_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Tue, 5 Jul 2011 23:06:44 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jul 2011 06:06:45.0065 (UTC) FILETIME=[E214B390:01CC3BA2] Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Jul 2011 06:06:55 -0000 --_3c8c217e-a003-49e2-b30d-c5c717d4d46f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: A couple of quick comments: * The last slide now says that WhatWG proposal is low path=3B this is not t= rue. The WhatWG proposal as I read it is mute on how the SDPs are exchanged= =2C it just hands those SDPs over to the=20 application (though high path is indicated: "Communications are coordinated= via a signaling channel provided by script in the page via the server=2C 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=2C= but if your application=20 initially only sets up a PeerConnection with no media Streams=2C there will= be a peer-to-peer datagram channel available. It can be used by the web ap= p to exchange the SDPs=20 for media negotiation when you add Streams (then we have a separate thread = on that datagram channel - is it 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 -=20 and this would have to be done at the start of the session and every time y= ou do a NIC change (a use case you added BTW!) Stefan [BA] I agree that the WhatWG proposal is not inherently low=2C medium or hi= gh path. The signalling mechanism is totally up to the signalling callbac= k function. I did have a question about how the PeerConnection API manages the gatherin= g of the ICE candidates=2C though. It was my (naive?) assumption that beyo= nd the host candidates (always included?)=2C the other gathered candidates would based based on the Type information pas= sed (e.g. STUN/STUNS=2C TURN/TURNS). If the SDP Blob is not considered "o= paque" the signalling=20 callback could manipulate/change it=2C to affect the subsequent ICE proces= sing. The peer could do the same thing on its end. If this were true (is = it?) then that would allow quite a bit of flexibility.=20 I was also a bit uncertain about the precise timing of when ICE connectivit= y checks are kicked off within the API=2C and how things like a NIC change = are handled. For example=2C is it envisaged that it would be possible to implement RTCWEB mobility (e.g. hand= off of media between interfaces)?=20 =20 = --_3c8c217e-a003-49e2-b30d-c5c717d4d46f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:

A couple of quick comments:

* The last slide now says that WhatWG proposal is low path=3B this is not t=
rue. The WhatWG proposal as I read it is mute on how the SDPs are exchanged=
=2C it just hands those SDPs over to the 
application (though high path =
is indicated: "Communications are coordinated via a signaling channel provi=
ded by script in the page via the server=2C 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=2C=
 but if your application 
initially only sets up a PeerConnection with n=
o media Streams=2C there will be a peer-to-peer datagram channel available.=
 It can be used by the web app to exchange the SDPs 
for media negotiati=
on when you add Streams (then we have a separate thread on that datagram ch=
annel - is it 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

[BA] I agree that the WhatWG proposal is not inherently low=
=2C medium or high path.   The signalling mechanism is totally up to the si=
gnalling callback function.

I did have a question about how the Peer=
Connection API manages the gathering of the ICE candidates=2C though.  It w=
as my (naive?) assumption that beyond the host candidates (always included?=
)=2C
the other gathered candidates would based based on the Type informa=
tion passed (e.g. STUN/STUNS=2C TURN/TURNS).   If the SDP Blob is not consi=
dered "opaque" the signalling 
callback could manipulate/change it=2C to=
 affect the  subsequent ICE processing.  The peer could do the same thing o=
n its end.  If this were true (is it?) then that would allow quite a bitof flexibility. 

I was also a bit uncertain about the precise timin=
g of when ICE connectivity checks are kicked off within the API=2C and how =
things like a NIC change are handled.   For example=2C is it
envisaged t=
hat it would be possible to implement RTCWEB mobility (e.g. handoff of medi=
a between interfaces)?

= --_3c8c217e-a003-49e2-b30d-c5c717d4d46f_-- From stefan.lk.hakansson@ericsson.com Tue Jul 5 23:21: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 BE14121F8504 for ; Tue, 5 Jul 2011 23:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.103, 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 KVZPRzgq3PbA for ; Tue, 5 Jul 2011 23:21:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E970F21F84FD for ; Tue, 5 Jul 2011 23:21:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-41-4e13fed61d48 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 70.08.20773.6DEF31E4; Wed, 6 Jul 2011 08:21:11 +0200 (CEST) Received: from [153.88.63.210] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 6 Jul 2011 08:21:10 +0200 Message-ID: <4E13FED3.9070003@ericsson.com> Date: Wed, 6 Jul 2011 08:21:07 +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 References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Jul 2011 06:21:12 -0000 On 2011-07-06 08:06, Bernard Aboba wrote: > Stefan said: > > A couple of quick comments: > > * The last slide now says that WhatWG proposal is low path; this is not true. 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 indicated: "Communications are coordinated via a signaling channel provided by script in the page via the server, e.g. using XMLHttpRequest.") > > * Notably the WhatWG PeerConnection API does allow both high path and low path. You can exchange all the SDPs over the server as the spec indicates, but if your application > initially only sets up a PeerConnection with no media 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 it 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 available 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 > > [BA] I agree that the WhatWG proposal is not inherently low, medium or high path. The signalling mechanism is totally up to the signalling callback function. > > I did have a question about how the PeerConnection API manages the gathering of the ICE candidates, though. It was my (naive?) assumption that beyond the host candidates (always included?), > the other gathered candidates would based based on the Type information passed (e.g. STUN/STUNS, TURN/TURNS). If the SDP Blob is not considered "opaque" the signalling > callback could manipulate/change it, to affect the subsequent ICE processing. The peer could do the same thing on its end. If this were true (is it?) then that would allow quite a bit > of flexibility. [SH] I have the same understanding. > > I was also a bit uncertain about the precise timing of when ICE connectivity checks are kicked off within the API, and how things like a NIC change are handled. For example, is it > envisaged that it would be possible to implement RTCWEB mobility (e.g. handoff of media between interfaces)? [SH] I think that is the assumption. Quote from the API spec "...any time the network topology changes and the ICE Agent performs an ICE Restart". > > > From randell-ietf@jesup.org Tue Jul 5 19:54: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 99BA421F87ED for ; Tue, 5 Jul 2011 19:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=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 mdxRtrYU7P6x for ; Tue, 5 Jul 2011 19:54:41 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id D1EFB21F8807 for ; Tue, 5 Jul 2011 19:54:41 -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 1QeIG8-0001PM-KF for rtcweb@ietf.org; Tue, 05 Jul 2011 21:54:40 -0500 Message-ID: <4E13CDAC.40401@jesup.org> Date: Tue, 05 Jul 2011 22:51: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> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> <46A1DF3F04371240B504290A071B4DB601301A8D@SZXEML501-MBS.china.huawei.com> <4D8B4033-8A5E-464E-82E7-983386498064@cisco.com> In-Reply-To: <4D8B4033-8A5E-464E-82E7-983386498064@cisco.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 - 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: X-Mailman-Approved-At: Wed, 06 Jul 2011 08:26:25 -0700 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, 06 Jul 2011 02:54:42 -0000 On 7/5/2011 6:30 PM, Cullen Jennings wrote: > Agree with folks on this thread about this being a way for the receiver to tell the send it's preferences - Perhaps the receiver might indicate that it would like 1080P video but the best the sender can do is 720P because that is the size of camera they have. In this case the sender does what the sender wants ignoring the receiver. There are other cases where say the receiver can not decode a bitstream above 768 kbps but the sender would typically send a stream at a much higher rate than this. In this case the sender needs to do what the receiver wants. These sorts of issues are at least partly addressed in the O/A section of the H.264 spec (RFC 6184, update to RFC 3984). Obviously that only applies to H.264. There are also issues about limitations due to the other direction; in particular look at level-asymmetry-allowed and what happens if it's not used. As mentioned, there are issues both of initial negotiation (as implied here) and in-call changes. I think a) the two sides should indicate what they support receiving in negotiation, and b) indicate their initial preferred resolution/etc in negotiation. In-call, there should be a mechanism for changing preference without a full call renegotiation (I suggest an RTCP-FB message), though one could fall back on a full new SDP exchange. > You might have an old browser that support vp8 and newer version of the browser that does both vp8 and vp9 and you use vp8 when that is all you have but prefer vp9 if both sides support it. That's just classic SDP and Offer/Answer: New: m=video 1234 RTP/AVP 98 99 100 a=rtpmap 98 VP9/90000 a=rtpmap 99 VP8/90000 a=rtpmap 100 H264/90000 Old: m=video 1234 RTP/AVP 99 100 a=rtpmap 99 VP8/90000 a=rtpmap 100 H264/90000 > I'm not sure exactly how to phrase all this but roughly speaking we need a way for the sender and receiver to agree on a format that meets the constraints of both and somewhat optimizes the desiree format within these constraints. RFC 6236 certainly looks like a reasonable option to consider; in fact I'd consider it to be the defacto choice barring some problematic limitation. It allows asymmetry within the limits of the codec negotiation; if RFC 6184 is used for H.264 then level asymmetry is allowed. There *might* be an argument for also describing the portions of the decoded window that aren't visible (per the previous conversation). My biggest issue is that they assume it can only be changed via UPDATE or re-INVITE. Maybe that's reasonable, but I have to say I'd lean towards solutions that are direct end-to-end in-call to cut overhead and lower reaction time. Randell > > On Jun 22, 2011, at 12:06 AM, Stefan Hkansson LK wrote: > >> 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 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 >> >> _______________________________________________ >> 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 > > -- Randell Jesup randell-ietf@jesup.org From henry.sinnreich@gmail.com Wed Jul 6 13:21: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 9C60421F84F9 for ; Wed, 6 Jul 2011 13:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPrZERessYRb for ; Wed, 6 Jul 2011 13:21:51 -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 853B221F8B6F for ; Wed, 6 Jul 2011 13:21:51 -0700 (PDT) Received: by gyd5 with SMTP id 5so153068gyd.31 for ; Wed, 06 Jul 2011 13:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=R748yCkblc4dhAHPVtRCLbcKTvOJKijgII6gnUEE+so=; b=bGFkDKhSwn3khDexC/OExwd7UyPiNRRgtD780Z1vpOO7Wbgdu1Ydr/JcE9Vkhwc9d4 ogR3As3s6imAWFiB3m62EZNZr4SfhYtC9INeqUrBR+vqqCzZcRuA5L1ri1Is80WB/m7y AJxOeWeDly+lE2Y5PSU7LPLb7K4MvepdiFtlA= Received: by 10.236.143.2 with SMTP id k2mr10136567yhj.500.1309983709965; Wed, 06 Jul 2011 13:21:49 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-164.tx.res.rr.com [76.184.227.164]) by mx.google.com with ESMTPS id z28sm177484yhn.63.2011.07.06.13.21.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 13:21:48 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 06 Jul 2011 15:21:45 -0500 From: Henry Sinnreich To: Jonathan Rosenberg , , Cullen Jennings Message-ID: Thread-Topic: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt Thread-Index: Acw8GlM5XHyU+684ZUyGBsW2Rg3W1w== In-Reply-To: <4E123C54.10405@jdrosen.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 06 Jul 2011 20:21:52 -0000 +1 Though usually quite skeptical of I-D's not supported by open, available code and test results, I find this I-D is quite refreshing, realistic and based on the huge deployment experience of the products supported by the authors. The only nit at first reading is not considering audio/video/IM chat as the normal minimal deployment scenario, either CS or P2P. Thanks, Henry On 7/4/11 5:19 PM, "Jonathan Rosenberg" wrote: > We put together the draft below to argue in favor of using a single port > for multiplexing voice and video traffic over RTP. > > Looking forward to a lively discussion on this, I am sure.. ;) > > Thanks, > Jonathan R. > > -------- Original Message -------- > Subject: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt > Date: Mon, 04 Jul 2011 15:14:25 -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 : Multiplexing of Real-Time Transport Protocol (RTP) > Traffic for Browser based Real-Time Communications (RTC) > Author(s) : Jonathan Rosenberg > Cullen Jennings > Jon Peterson > Matthew Kaufman > Eric Rescorla > Tim Terriberry > Filename : draft-rosenberg-rtcweb-rtpmux-00.txt > Pages : 12 > Date : 2011-07-04 > > This document argues that multiplexing of voice and video traffic > over a single RTP session should be specified as the baseline mode of > operation for multimedia traffic in RTC web. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-rtcweb-rtpmux-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-rosenberg-rtcweb-rtpmux-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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Wed Jul 6 14:26: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 1486A21F892E for ; Wed, 6 Jul 2011 14:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.533 X-Spam-Level: X-Spam-Status: No, score=-110.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 HGPRxi4bypC4 for ; Wed, 6 Jul 2011 14:26:58 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id D562621F8AAC for ; Wed, 6 Jul 2011 14:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=233; q=dns/txt; s=iport; t=1309987616; x=1311197216; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=btszC/pow7b9IJrwHtB+Y3ADzzx1tdT/IHLhblFIanw=; b=U3lECzVWNo57eaLtePDWhyfoXgVgpJ0jKfpKZDRB814qIjvcoSEFxrCW shik16EH2XcAkV+/fwax7rnZVnVqdp7uSDRHA/FHNtD5BPR81dz8SLxba fseOsv9FnRTWx8VT3phPPmgfwML/y352B6xD+Ep4HG7aCWuFdVYuc01Fy M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAErSFE6rRDoJ/2dsb2JhbABTqAt3iHqlC54MhjcEh0aKe4R6i2I X-IronPort-AV: E=Sophos;i="4.65,489,1304294400"; d="scan'208";a="362715435" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2011 21:26:56 +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 p66LQtrE032548; Wed, 6 Jul 2011 21:26:56 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 6 Jul 2011 15:26:55 -0600 Content-Transfer-Encoding: 7bit Message-Id: <35993042-1E3E-4508-B3BB-11FDF6077C0F@cisco.com> References: To: Henry Sinnreich X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 06 Jul 2011 21:26:59 -0000 On Jul 6, 2011, at 2:21 PM, Henry Sinnreich wrote: > Though usually quite skeptical of I-D's not supported by open, available > code and test results I hope to have open, available code, and results by later this year ... From fluffy@cisco.com Wed Jul 6 20:32: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 5DA1B21F899C for ; Wed, 6 Jul 2011 20:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.318 X-Spam-Level: X-Spam-Status: No, score=-106.318 tagged_above=-999 required=5 tests=[AWL=-3.719, 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 N5ZBTirX-iGO for ; Wed, 6 Jul 2011 20:32:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9D62A21F899B for ; Wed, 6 Jul 2011 20:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2637; q=dns/txt; s=iport; t=1310009570; x=1311219170; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/yC2hCK6kRTcnIabSHqzOZCR08m5U8U2jhW+xQRea98=; b=Af6iIsmqrhwCS1AmEMFTIVHEDoqCG47GZQaXZ8pHP7SB06S3p891rn8j kvM82o8jTY7FPa3NIjkaGrcB8w7XLDX5wHZcL2ETkm81VzWrecgSeVXLk C/fSYKDSPEm9UMYS7jXq4Ai9OnHlralTdp4WSGSgPdIuiTD8aZUZIsaj8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGEoFU6rRDoI/2dsb2JhbABTqBd3iHulKJ4AhjcEh0mKfYR9i2M X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="516713" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jul 2011 03:32:50 +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 p673Wm3h018320; Thu, 7 Jul 2011 03:32:49 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 6 Jul 2011 21:32:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4D1D6581-F70D-461C-8153-F99AEE8FCB0A@cisco.com> References: To: Stephan Wenger X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft rtcweb agenda for IETF 81 - version 2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Jul 2011 03:32:51 -0000 Added - and if we can figure out a way to get more time in that section, = we will... On Jul 5, 2011, at 10:45 AM, Stephan Wenger wrote: > Hi Cullen, all, > We would like to have a few minute sin the last subsection to = introduce > layered codecs: draft-wenger-rtcweb-layered-codec-00 > > Thanks, > Stephan >=20 > On 7.5.2011 09:00 , "Cullen Jennings" wrote: >=20 >>=20 >> Here is the rough agenda that Ted, Magnus, and I have been thinking >> of..... bash away ... >>=20 >>=20 >>=20 >> Agenda - version 2 >>=20 >> Agenda Bash >> 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 ( 20 min ) >> draft-ietf-rtcweb-use-cases-and-requirements >>=20 >> Architecture and System Overview ( 20 min) >> draft-ietf-rtcweb-overview >>=20 >> Security ( 20 min ) >> draft-rescorla-rtcweb-security >> draft-kaufman-rtcweb-security-ui >> draft-johnston-rtcweb-media-privacy >>=20 >> NAT ( 20 min) >> draft-kaufman-rtcweb-traversal >> draft-cbran-rtcweb-nat >>=20 >>=20 >>=20 >> Start of Session two (Chairs) - 5 min >>=20 >> Negotiation & signaling (25 min) >> draft-cbran-rtcweb-negotiation >>=20 >>=20 >> Media (other than multiplexing) (20 min) >> draft-perkins-rtcweb-rtp-usage >> draft-cbran-rtcweb-media >>=20 >>=20 >> Datagram transports (20 min) >> draft-cbran-rtcweb-data >>=20 >>=20 >> Multiplexing (30 min) >> draft-rosenberg-rtcweb-rtpmux >> draft-perkins-rtcweb-rtp-usage >> * focus on how/if we multiplex on one UDP port >>=20 >>=20 >> Media processing & codec (20 min) >> draft-cbran-rtcweb-codec >> draft-alvestrand-dispatch-rtcweb-protocols >> * focus on requirements for codecs >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From fluffy@cisco.com Wed Jul 6 20:43: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 1ED1321F8A22 for ; Wed, 6 Jul 2011 20:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.123 X-Spam-Level: X-Spam-Status: No, score=-106.123 tagged_above=-999 required=5 tests=[AWL=-3.524, 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 i7xVi4Ok+of0 for ; Wed, 6 Jul 2011 20:43:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 706D721F8A1D for ; Wed, 6 Jul 2011 20:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=843; q=dns/txt; s=iport; t=1310010207; x=1311219807; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Z1g2a7vRdjsHTCYLM526CVfJNvg1Pgre6hYO3fawpfs=; b=cmAlvMKTadn1+BhtYuqq+exh+iuJWjlv3tfs7CGdbJ6C3nq8BiGb/3Qc VcaPfA2z/JBvzq3+YgPaFrWL8Y2869h2hyQD6lrMKsB/pc/0kVpDlkjPc rWv7k9UcwonZSqTRHr6MHFD2Qh9RrON9Y6MJ0+oA8m9Kc2s0TXHDhB/J3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMAqFU6rRDoH/2dsb2JhbABTqBd3rgydf4Y3BIdJin2EfYtj X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="517898" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 07 Jul 2011 03:43:26 +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 p673hPRk015587; Thu, 7 Jul 2011 03:43:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 6 Jul 2011 21:43:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Jul 2011 03:43:28 -0000 On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote: >=20 >=20 > * The last slide now says that WhatWG proposal is low path; this is = not true. The WhatWG proposal as I read it is mute on how the SDPs are = exchanged, it just hands those SDPs over to the=20 >=20 > application (though high path is indicated: "Communications are = coordinated via a signaling channel provided by script in the page via = the server, e.g. using XMLHttpRequest.") Hmm - my understanding was only the ICE related information was = communicated that way and the SDP related information when across the = channel set up by ICE but I could be totally wrong. It's pretty vague in = the spec - I got that idea by talking to some of the people involved. = Anyways, glad to retract that WhatWG is doing low path and just change = it to not clear.=20 From fluffy@cisco.com Wed Jul 6 20:47: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 25B8721F8A61 for ; Wed, 6 Jul 2011 20:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=-3.348, 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 ZXqEf-Uzd19R for ; Wed, 6 Jul 2011 20:47:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6417C21F8A4D for ; Wed, 6 Jul 2011 20:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=354; q=dns/txt; s=iport; t=1310010454; x=1311220054; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=X/xI+WZu6ACYVZ1UtlW5vqQqfLvKckVao9O5ooHR3fY=; b=b1o7aP2HCY3OROul1j9pZCb1gneDLj7KdKaHoE2osOM+7A4paCKgz3Vk proEFvlALj8NcLjV+2L9YLRyFbrAIxapZ0+rryoU/nkG1Miy4XIdJNpIC YkhuQbkHDZjYOxBTRtf83//S1oBWKZSF3rJMukU1sAWtFr11IFdYHa39l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoHANMrFU6rRDoJ/2dsb2JhbABTmSaOcXeIe6USnX+GNwSHSYp9hH2LYw X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="518149" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 07 Jul 2011 03:47: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 p673lWd0001381; Thu, 7 Jul 2011 03:47:33 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E09CE8F.8000508@alcatel-lucent.com> Date: Wed, 6 Jul 2011 21:47:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E090781.20308@jitsi.org> <4E09CE8F.8000508@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1084) 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: Thu, 07 Jul 2011 03:47:35 -0000 On Jun 28, 2011, at 6:52 AM, 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. People objected. WIth my chair hat on I do not yet see consensus on this = topic one way or the other.=20= From fluffy@cisco.com Wed Jul 6 20:57: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 5D97E21F8A85 for ; Wed, 6 Jul 2011 20:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.787 X-Spam-Level: X-Spam-Status: No, score=-105.787 tagged_above=-999 required=5 tests=[AWL=-3.188, 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 TxXFOP0pWIGn for ; Wed, 6 Jul 2011 20:57:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7356521F88D2 for ; Wed, 6 Jul 2011 20:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2169; q=dns/txt; s=iport; t=1310011052; x=1311220652; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EBXoJlmrwdAUlUMTpSto4kTY3JPUZqiv3OR2CDSVSIM=; b=ioBpUyvlRyaiTigEP1VURAafTSGco3D6YXKDdcm9f4SesZuXD0s0JVF4 UNRGgg/J8ECfuTIAJRsT0VPla5DYNRU1yaLwZP1GGTKc81NvtBtOCNHwu 9GGY0fb0g7F3ifPphUcLAvhaoS1UkR0PifDQinhUghdjb14Be69sXvlva 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHYtFU6rRDoH/2dsb2JhbABGDagXd4h7pRKdfYMigxUEh0mKfYR9i2M X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="519889" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jul 2011 03:57:28 +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 p673vRiY023155; Thu, 7 Jul 2011 03:57:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E0832FE.7010401@ericsson.com> Date: Wed, 6 Jul 2011 21:57:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3B711EF7-9FC9-4E0C-A9D1-E115F41AF02D@cisco.com> References: <4E0832FE.7010401@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) 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: Thu, 07 Jul 2011 03:57:33 -0000 On Jun 27, 2011, at 1:36 AM, Magnus Westerlund wrote: >=20 > Does anyone like to add additional use cases? BFCP=20 I'm interested in the use cases that have real time requirements and = latency is an issue. >=20 >=20 > Are you supporting the inclusion of a unreliable datagram service > directly between peers? yes > 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 don't have a big need for this but don't have a problem with it if = others need it=20 > 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 +1=20 > - Datagram oriented > * Size limited by MTU > - Path MTU discovery needed +1 > * Fragmentation by the application +1 > - Low latency, i.e. Peer to Peer preferable +5 > - Congestion Controlled, to be > * Network friendly +1 > * Not become a Denial of Service tool +1 > - Security > * Confidentiality +1 > * Integrity Protected +1 > * Source Authenticated (at least bound to the signalling peer) +1 - I might phrase this a bit differently but I think we are getting at = the same thing. If we are going to have encryption, there no point in = encrypting something if you have no idea you our sending encrypted data = to and from. We need some sort of identity / autehntication > * Ensure consent to receive data +5 In addition to your, I'd like to add that I am trying to maximize the = odds of it making though the various NATs and Firewalls involved with = and enterprise or home user.=20 Cullen in my individual contributor role. From fluffy@cisco.com Wed Jul 6 21:04: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 B267E21F864F for ; Wed, 6 Jul 2011 21:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.642 X-Spam-Level: X-Spam-Status: No, score=-105.642 tagged_above=-999 required=5 tests=[AWL=-3.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FneHDUqoQ3bN for ; Wed, 6 Jul 2011 21:04:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 10BC021F862D for ; Wed, 6 Jul 2011 21:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=780; q=dns/txt; s=iport; t=1310011499; x=1311221099; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=E5MsYL+EJQU8l7uyDBqqLlsw2Mbne9GSIbYaGsG9yN4=; b=Xqg96EHk/oSEQiFK0ucyeIyw+cb/8DBVWefzu+VkcdXDfJRrR3FvfKNv GB1k2zv4yvNcRBTBTjhmijMrQ8oaJdK6VZ89ErO2goxlaUfc0Sq+i1rvL TXnElzUiuFtQEnK/VMOpBv+jJqNqOtONYWPkTgR5ci76Gj22+9ffOmNzq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM4vFU6rRDoG/2dsb2JhbABTqBd3iHulB519hjcEh0mKfYR9i2M X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="521397" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jul 2011 04:04:58 +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 p6744vXZ013339; Thu, 7 Jul 2011 04:04:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E13CE93.9070402@jesup.org> Date: Wed, 6 Jul 2011 22:04:56 -0600 Content-Transfer-Encoding: quoted-printable 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> <4D8B4033-8A5E-464E-82E7-983386498064@cisco.com> <4E13CE93.9070402@jesup.org> To: Randell Jesup 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: Thu, 07 Jul 2011 04:04:59 -0000 On Jul 5, 2011, at 8:55 PM, Randell Jesup wrote: > RFC 6236 certainly looks like a reasonable option to consider; in fact = I'd consider it to be the > defacto choice barring some problematic limitation. =20 yah, make sense to me > There *might* be an argument for also describing the portions of the = decoded window that aren't visible > (per the previous conversation). I worry about too much "optimization" :-) >=20 > My biggest issue is that they assume it can only be changed via UPDATE = or re-INVITE. Maybe that's > reasonable, but I have to say I'd lean towards solutions that are = direct end-to-end in-call to cut overhead > and lower reaction time. It one of the arguments people make in favor of the "low path". Or = perhaps H.245 :-) From fluffy@cisco.com Wed Jul 6 21:11: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 8544A21F8552 for ; Wed, 6 Jul 2011 21:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.51 X-Spam-Level: X-Spam-Status: No, score=-105.51 tagged_above=-999 required=5 tests=[AWL=-2.911, 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 JBnrpyiHEOkT for ; Wed, 6 Jul 2011 21:11:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D7AB721F893C for ; Wed, 6 Jul 2011 21:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=457; q=dns/txt; s=iport; t=1310011898; x=1311221498; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=g24lgDbOFqrKmF2cg11xrIzhtG9ZVTU3ylyhQjiJXw4=; b=IsbrU1T3V5BtdDoPNG0FOD/pKN1DWdARdDVCVu+RxYJOiSoyXMuljIrY +FlVqNrgQdW6pCX2sOSPFLQS2OnWSqXdQVuv0AFHRzigIzp8gxRVxe6pt 0Q4XOExNdRntB0GtXVUnmyKhh8oFjO1mKAmHDC5OcDca7D6hk2e0BNKdp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIwxFU6rRDoH/2dsb2JhbABTqBd3iHulC519hjcEh0mKfYR9i2M X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="522175" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 07 Jul 2011 04:11:37 +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 p674Baq2030140; Thu, 7 Jul 2011 04:11:36 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 6 Jul 2011 22:11:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2AE62384-D2B0-4630-A27A-C89AB7A5B826@cisco.com> References: To: Niklas Enbom X-Mailer: Apple Mail (2.1084) 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, 07 Jul 2011 04:11:38 -0000 I'm confused about it. So how does the current implementation negotiate = the codec information?=20 On Jun 30, 2011, at 2:39 AM, Niklas Enbom wrote: > 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. >=20 > Niklas >=20 From bernard_aboba@hotmail.com Wed Jul 6 21:46: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 5B18821F87CB for ; Wed, 6 Jul 2011 21:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, 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 IfUNPjT0jStB for ; Wed, 6 Jul 2011 21:46:18 -0700 (PDT) Received: from blu0-omc4-s21.blu0.hotmail.com (blu0-omc4-s21.blu0.hotmail.com [65.55.111.160]) by ietfa.amsl.com (Postfix) with ESMTP id AA17B21F87C6 for ; Wed, 6 Jul 2011 21:46:18 -0700 (PDT) Received: from BLU152-W17 ([65.55.111.137]) by blu0-omc4-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 21:46:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8672e6dc-4b4e-478c-8ff3-4ca1f309f3ef_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Wed, 6 Jul 2011 21:46:17 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2011 04:46:17.0997 (UTC) FILETIME=[CF5653D0:01CC3C60] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Jul 2011 04:46:19 -0000 --_8672e6dc-4b4e-478c-8ff3-4ca1f309f3ef_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My understanding of the API is that the signalling callback is handed the S= DP blob which includes ICE candidates gathered as directed=2C to manipulate= and send as it pleases. Once an answer is received it is passed down. Th= e spec is indeed vague on some points=2C but hey=2C that's what sample code= is for : ( > Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture > From: fluffy@cisco.com > Date: Wed=2C 6 Jul 2011 21:43:25 -0600 > CC: rtcweb@ietf.org > To: bernard_aboba@hotmail.com >=20 >=20 > On Jul 6=2C 2011=2C at 12:06 AM=2C Bernard Aboba wrote: >=20 > >=20 > >=20 > > * The last slide now says that WhatWG proposal is low path=3B this is n= ot true. The WhatWG proposal as I read it is mute on how the SDPs are excha= nged=2C it just hands those SDPs over to the=20 > >=20 > > application (though high path is indicated: "Communications are coordin= ated via a signaling channel provided by script in the page via the server= =2C e.g. using XMLHttpRequest.") >=20 > Hmm - my understanding was only the ICE related information was communica= ted that way and the SDP related information when across the channel set up= by ICE but I could be totally wrong. It's pretty vague in the spec - I got= that idea by talking to some of the people involved. Anyways=2C glad to re= tract that WhatWG is doing low path and just change it to not clear.=20 >=20 >=20 = --_8672e6dc-4b4e-478c-8ff3-4ca1f309f3ef_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My understanding of the API is that the signalling callback is handed the S= DP blob which includes ICE candidates gathered as directed=2C to manipulate= and send as it pleases. =3B Once an answer is received it is passed do= wn. =3B The spec is indeed vague on some points=2C but hey=2C that's wh= at sample code is for : (

>=3B Subject: Re: [rtcweb] Media ne= g-eo-tiation and signalling archa-tecture
>=3B From: fluffy@cisco.com<= br>>=3B Date: Wed=2C 6 Jul 2011 21:43:25 -0600
>=3B CC: rtcweb@ietf.= org
>=3B To: bernard_aboba@hotmail.com
>=3B
>=3B
>=3B= On Jul 6=2C 2011=2C at 12:06 AM=2C Bernard Aboba wrote:
>=3B
>= =3B >=3B
>=3B >=3B
>=3B >=3B * The last slide now says th= at WhatWG proposal is low path=3B this is not true. The WhatWG proposal as = I read it is mute on how the SDPs are exchanged=2C it just hands those SDPs= over to the
>=3B >=3B
>=3B >=3B application (though high p= ath is indicated: "Communications are coordinated via a signaling channel p= rovided by script in the page via the server=2C e.g. using XMLHttpRequest."= )
>=3B
>=3B Hmm - my understanding was only the ICE related info= rmation was communicated that way and the SDP related information when acro= ss the channel set up by ICE but I could be totally wrong. It's pretty vagu= e in the spec - I got that idea by talking to some of the people involved. = Anyways=2C glad to retract that WhatWG is doing low path and just change it= to not clear.
>=3B
>=3B
= --_8672e6dc-4b4e-478c-8ff3-4ca1f309f3ef_-- From randell1@jesup.org Wed Jul 6 22:19: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 AA7BC21F899B for ; Wed, 6 Jul 2011 22:19:10 -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 Z83J3Ov5ZeUq for ; Wed, 6 Jul 2011 22:19:10 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCED21F899F for ; Wed, 6 Jul 2011 22:19:09 -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 1QegzP-0006W5-RE for rtcweb@ietf.org; Thu, 07 Jul 2011 00:19:03 -0500 Message-ID: <4E1540FD.3070109@jesup.org> Date: Thu, 07 Jul 2011 01:15:41 -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> <3B711EF7-9FC9-4E0C-A9D1-E115F41AF02D@cisco.com> In-Reply-To: <3B711EF7-9FC9-4E0C-A9D1-E115F41AF02D@cisco.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] 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, 07 Jul 2011 05:19:10 -0000 On 7/6/2011 11:57 PM, Cullen Jennings wrote: >> Are you supporting the inclusion of a unreliable datagram service >> directly between peers? > yes I support it as well. >> 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 don't have a big need for this but don't have a problem with it if others need it I think we need to provide at least unreliable datagram service, and probably reliable datagram service. >> 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'd rather have one well-debugged standard reliable datagram service than N so-so debugged 3rd-party services, which might not "play well together". >> 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 > +1 > >> - Datagram oriented >> * Size limited by MTU >> - Path MTU discovery needed > +1 > >> * Fragmentation by the application > +1 > >> - Low latency, i.e. Peer to Peer preferable > +5 > >> - Congestion Controlled, to be >> * Network friendly > +1 And I'd say (generally to all the part of rtcweb) Unified Congestion Control of all streams that are part of the same session. >> * Not become a Denial of Service tool > +1 > >> - Security >> * Confidentiality > +1 >> * Integrity Protected > +1 >> * Source Authenticated (at least bound to the signalling peer) > +1 - I might phrase this a bit differently but I think we are getting at the same thing. If we are going to have encryption, there no point in encrypting something if you have no idea you our sending encrypted data to and from. We need some sort of identity / autehntication I'm not sure I agree on Integrity Protection and Source Authentication. There are use cases where we want to have a private conversation (no eavesdropping or video leaked to Youtube!), but don't care if someone can block or disrupt the call. (Someone with control of a link or midbox can do that already.) I think those are important optional services. >> * Ensure consent to receive data > +5 > > In addition to your, I'd like to add that I am trying to maximize the odds of it making though the various NATs and Firewalls involved with and enterprise or home user. +5 -- Randell Jesup randell-ietf@jesup.org From alan.b.johnston@gmail.com Thu Jul 7 06:44: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 ABC9321F867A for ; Thu, 7 Jul 2011 06:44:07 -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 89275Veyu4dw for ; Thu, 7 Jul 2011 06:44:07 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D566221F863B for ; Thu, 7 Jul 2011 06:44:06 -0700 (PDT) Received: by gwb20 with SMTP id 20so451459gwb.31 for ; Thu, 07 Jul 2011 06:44:00 -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:content-transfer-encoding; bh=AzSbgXlyQQWYd89TECErfcJ8acH1N1YBa9hSWtXSDE4=; b=b23nQbAIz/y9M3d2lDNDYEu8aebGxCPQB6UBBAYO1yzNZoeQUjnvnskl3n2SiwLzeI m6oANvbWX02QyZSu4ucylxn/RV5R5jb84fFFnWMOkZcoEQmojr61vnJsmMXCPKpTLHZ5 BGiiheI41gcOWJ0Php13zY1H3s/xeB3+YNIR4= MIME-Version: 1.0 Received: by 10.150.170.12 with SMTP id s12mr987255ybe.191.1310046239990; Thu, 07 Jul 2011 06:43:59 -0700 (PDT) Received: by 10.151.114.1 with HTTP; Thu, 7 Jul 2011 06:43:59 -0700 (PDT) In-Reply-To: <9D227A73-B310-4226-90C8-AFD9963C5022@skype.net> References: <20110629233542.25579.52406.idtracker@ietfa.amsl.com> <9D227A73-B310-4226-90C8-AFD9963C5022@skype.net> Date: Thu, 7 Jul 2011 08:43:59 -0500 Message-ID: From: Alan Johnston To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: prz@mit.edu Subject: Re: [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: Thu, 07 Jul 2011 13:44:07 -0000 This is a reasonable start to expressing in requirement form some of the ideas described in draft-johnston-rtcweb-media-privacy and that I presented on the interim call. Some additional comments: At the start, it should be made clear that the UI described is the browser UI and not anything rendered by the web page. This is described in the last requirement of Section 2, but it needs to be clearly stated up front. Most of the UI descriptions seem to be described in terms of an inspector - with additional clicks a user can determine additional information about the media session, which is reasonable. However, if we do allow non-encrypted media sessions (which I really hope we do not - this goes against the current direction of web security in moving from http to https), then the encrypted/non encrypted state needs to be visible as much as possible, in the same way that a user does not need to click anything to see if http or https is in use. Of course, full screen modes and other considerations can limit this. " If the transmission is encrypted, the "security characteristics" MUST include an indication as to the source of the keying material, particularly whether the keying material was delivered out-of-band (from a server) or was generated as a result of a pairwise negotiation." I think I understand and agree with this requirement. However, I think we can do better in our description of the keying material. I think the distinction we are after is whether the keying material was derived directly between the browsers, or between the browser and the server. " If possible for the cryptosystem in use, the "security characteristics" MUST include information regarding the authenticity of the far station identity. (For example, in the case of a self- signed certificate with RSA key the contents of the certificate and the key fingerprint.)" I'm not sure about this one. Unless a PKI is in use, I don't think there is any useful identity information that can be derived. I've been told in the past that "self signed certificates" are actually just containers for a public key, and as such none of the information is useful. Also, I don't understand the value in providing a key fingerprint to a user. This might be useful for debugging, but it isn't of use to users. Ekr has provided a reference in the past why this is so. " If possible for the cryptosystem in use, the "security characteristics" SHOULD include a Short Authentication String which may be used by the user to authenticate the far station identity and keying integrity (specifically, the presence or lack of a man-in-the- middle that may be in collusion with the service provider to attempt to bypass authentication tests) by communicating this string out-of- band with the far party." I think providing a SAS is very important, so I believe this requirement to be a MUST. Also, this wording about "if possible" might be interpreted to mean "if ZRTP is used". I think having an SAS is valuable for any keying method that is browser to browser - I don't think it has any value for broswer to server keying. Since the SAS is just an algorithm based on the secret key used, it should be be possible to derive one for other keying approaches. However, we will need help from crypto experts to make sure the SAS is of sufficient length and derived correctly to make it useful. I recall with ZRTP that we were able to utilize such a short SAS due to the hash commitment design - other keying methods will need a similar analysis. Looking forward to the discussion of these issues in Quebec City. - Alan - On Wed, Jun 29, 2011 at 6:38 PM, Matthew Kaufman wrote: > 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 > > 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 reposito= ry. > > 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: > =A0=A0This document calls for a requirement to be imposed on RTCWEB clien= t > =A0=A0user interfaces whereby the user may inspect the current media > =A0=A0security status. > > > > > The IETF Secretariat > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From fluffy@cisco.com Thu Jul 7 10:52: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 41D3E1F0C5D for ; Thu, 7 Jul 2011 10:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.389 X-Spam-Level: X-Spam-Status: No, score=-105.389 tagged_above=-999 required=5 tests=[AWL=-2.790, 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 H4kbs5e6vA-s for ; Thu, 7 Jul 2011 10:52:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 735AF1F0C34 for ; Thu, 7 Jul 2011 10:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4488; q=dns/txt; s=iport; t=1310061156; x=1311270756; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JvIwhMF+vS/z1R24srbFSjbE5YyawmGLLr47rX50RII=; b=RKDdfwVqts/1Ax8sGDUxQYZET54FwXoeLtaXr3IelFJKKxUmAUTckdO+ 6pxx/Tm1doko4pB1RTV08K3Se1/pbDXuXPuOiO0o0AQB2bpwM8YuI0pYy ZDIkHLx3xKeFfti+S+PZwBWcfOWXtLQM1b6J+fbsSjSUxXiG8Ove/Xwqo s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8HAOTxFU6rRDoI/2dsb2JhbABQA5hBjnR3iHukYp16g0KCdgSHSYp9hH2LYw X-IronPort-AV: E=Sophos;i="4.65,494,1304294400"; d="scan'208";a="753699" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 07 Jul 2011 17:52:34 +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 p67HqWxk004605; Thu, 7 Jul 2011 17:52:33 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 7 Jul 2011 11:52:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.com> References: To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Jul 2011 17:52:37 -0000 I went and looked at some call flows to try and sort out what is going = on in the current released chrome code and as far as I can tell, Bernard = you are right, it is passing the data over the HTTP channel. An example = of what I see is below=20 As far as I can tell this is the JSON encoding of XEP-180 used in jingle = and a separate JSON encoding of some of SDP. Not sure this matters much = one way or the other but wanted to pass on what I had found and I will = correct the slides at some point - my apologies for getting them wrong.=20= Cullen { "media" : [ { "attributes" : { "candidate" : [ { "component" : 1, "foundation" : 1, "generation" : 0, "ip" : "144.254.150.241", "name" : "rtp", "network_name" : "Intel(R) WiFi Link 1000 BGN", "password" : "OpawIyXLYcJkwxFa", "port" : "61880", "priority" : 1.0, "proto" : "udp", "type" : "local", "username" : "90B0CPvC8p8XPMFt" } ] }, "label" : 1, "rtpmap" : [ { "103" : { "codec" : "audio/ISAC" } }, { "104" : { "codec" : "audio/ISAC" } }, { "9" : { "codec" : "audio/G722" } }, { "102" : { "codec" : "audio/iLBC" } }, { "0" : { "codec" : "audio/PCMU" } }, { "8" : { "codec" : "audio/PCMA" } }, { "99" : { "codec" : "audio/CN" } }, { "98" : { "codec" : "audio/CN" } }, { "13" : { "codec" : "audio/CN" } }, { "127" : { "codec" : "audio/red" } }, { "106" : { "codec" : "audio/telephone-event" } } ] }, { "attributes" : { "candidate" : [ { "component" : 1, "foundation" : 1, "generation" : 0, "ip" : "144.254.150.241", "name" : "video_rtp", "network_name" : "Intel(R) WiFi Link 1000 BGN", "password" : "G4dq4e3f/G7FDJ5h", "port" : "61879", "priority" : 1.0, "proto" : "udp", "type" : "local", "username" : "CBkZYp6/DTTMEFeM" } ] }, "label" : 2, "rtpmap" : [ { "120" : { "codec" : "video/VP8" } } ] } ] } On Jul 6, 2011, at 9:43 PM, Cullen Jennings wrote: >=20 > On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote: >=20 >>=20 >>=20 >> * The last slide now says that WhatWG proposal is low path; this is = not true. The WhatWG proposal as I read it is mute on how the SDPs are = exchanged, it just hands those SDPs over to the=20 >>=20 >> application (though high path is indicated: "Communications are = coordinated via a signaling channel provided by script in the page via = the server, e.g. using XMLHttpRequest.") >=20 > Hmm - my understanding was only the ICE related information was = communicated that way and the SDP related information when across the = channel set up by ICE but I could be totally wrong. It's pretty vague in = the spec - I got that idea by talking to some of the people involved. = Anyways, glad to retract that WhatWG is doing low path and just change = it to not clear.=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From niklase@google.com Fri Jul 8 00:58: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 791FB21F8747 for ; Fri, 8 Jul 2011 00:58:57 -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 qLcma7QoSW4k for ; Fri, 8 Jul 2011 00:58:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 56FD121F8741 for ; Fri, 8 Jul 2011 00:58:53 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p687wq4T018911 for ; Fri, 8 Jul 2011 00:58:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310111932; bh=XfNCoOcTORPxGwiXLE2x1tvFLjE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Yn+hJ427sj/ke1ggzeMWUGh206CJSwB9uaBKWVjlaL/tNcFykw/Y7K6bBjUfO0kXz n3J2pL3SyQUbBEVnnk4RA== 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=WoRq2/0xSekd+SklrstpUv3mLXzlZfaH7ftr/hKhNULdx9VCxEmInKJ8wD4DoGYet emYt2rTSEQony8mM5gLqA== Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by kpbe19.cbf.corp.google.com with ESMTP id p687wo7b015452 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 8 Jul 2011 00:58:51 -0700 Received: by yxl31 with SMTP id 31so868656yxl.41 for ; Fri, 08 Jul 2011 00:58:50 -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=TPWQT9is79qUKzDg5Wgs3Yyyqz7fu5/oD2DsfGTVckM=; b=pi/q/NiiOZl4raRULgMqtoK5wrv/5zhVqlHNdqqpy+ACAq4/Be9Lp/oJ5SUh7R9fYZ JJ9sVYMX77mBFBuO47fQ== MIME-Version: 1.0 Received: by 10.100.233.21 with SMTP id f21mr1422846anh.83.1310111930152; Fri, 08 Jul 2011 00:58:50 -0700 (PDT) Received: by 10.100.165.11 with HTTP; Fri, 8 Jul 2011 00:58:50 -0700 (PDT) In-Reply-To: <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.com> References: <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.com> Date: Fri, 8 Jul 2011 09:58:50 +0200 Message-ID: From: Niklas Enbom To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016367658843677bb04a78a34c8 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Jul 2011 07:58:57 -0000 --0016367658843677bb04a78a34c8 Content-Type: text/plain; charset=ISO-8859-1 Not sure in which thread I should answer... In Chrome we're trying to implement the whatwg proposal with one intentional discrepancy, and that's the string format pointed out by Cullen. See details in this thread: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg26163.html. There's also non-intentional discrepancies that we know of, which we're trying to remove. Just be careful when looking at Chrome code to interpret the whatwg spec. We're trying to interpret that spec in the same way as anyone else, and the whatwg author is not involved in the Chrome implementation. Niklas On Thu, Jul 7, 2011 at 7:52 PM, Cullen Jennings wrote: > > I went and looked at some call flows to try and sort out what is going on > in the current released chrome code and as far as I can tell, Bernard you > are right, it is passing the data over the HTTP channel. An example of what > I see is below > > As far as I can tell this is the JSON encoding of XEP-180 used in jingle > and a separate JSON encoding of some of SDP. Not sure this matters much one > way or the other but wanted to pass on what I had found and I will correct > the slides at some point - my apologies for getting them wrong. > > Cullen > > > > { > "media" : [ > { > "attributes" : { > "candidate" : [ > { > "component" : 1, > "foundation" : 1, > "generation" : 0, > "ip" : "144.254.150.241", > "name" : "rtp", > "network_name" : "Intel(R) WiFi Link 1000 BGN", > "password" : "OpawIyXLYcJkwxFa", > "port" : "61880", > "priority" : 1.0, > "proto" : "udp", > "type" : "local", > "username" : "90B0CPvC8p8XPMFt" > } > ] > }, > "label" : 1, > "rtpmap" : [ > { > "103" : { > "codec" : "audio/ISAC" > } > }, > { > "104" : { > "codec" : "audio/ISAC" > } > }, > { > "9" : { > "codec" : "audio/G722" > } > }, > { > "102" : { > "codec" : "audio/iLBC" > } > }, > { > "0" : { > "codec" : "audio/PCMU" > } > }, > { > "8" : { > "codec" : "audio/PCMA" > } > }, > { > "99" : { > "codec" : "audio/CN" > } > }, > { > "98" : { > "codec" : "audio/CN" > } > }, > { > "13" : { > "codec" : "audio/CN" > } > }, > { > "127" : { > "codec" : "audio/red" > } > }, > { > "106" : { > "codec" : "audio/telephone-event" > } > } > ] > }, > { > "attributes" : { > "candidate" : [ > { > "component" : 1, > "foundation" : 1, > "generation" : 0, > "ip" : "144.254.150.241", > "name" : "video_rtp", > "network_name" : "Intel(R) WiFi Link 1000 BGN", > "password" : "G4dq4e3f/G7FDJ5h", > "port" : "61879", > "priority" : 1.0, > "proto" : "udp", > "type" : "local", > "username" : "CBkZYp6/DTTMEFeM" > } > ] > }, > "label" : 2, > "rtpmap" : [ > { > "120" : { > "codec" : "video/VP8" > } > } > ] > } > ] > } > > > On Jul 6, 2011, at 9:43 PM, Cullen Jennings wrote: > > > > > On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote: > > > >> > >> > >> * The last slide now says that WhatWG proposal is low path; this is not > true. 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 indicated: "Communications are > coordinated via a signaling channel provided by script in the page via the > server, e.g. using XMLHttpRequest.") > > > > Hmm - my understanding was only the ICE related information was > communicated that way and the SDP related information when across the > channel set up by ICE but I could be totally wrong. It's pretty vague in the > spec - I got that idea by talking to some of the people involved. Anyways, > glad to retract that WhatWG is doing low path and just change it to not > clear. > > > > > > _______________________________________________ > > 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 > --0016367658843677bb04a78a34c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure in which thread I should answer... In Chrome we're trying to i= mplement the whatwg proposal with one intentional discrepancy, and that'= ;s the string format pointed out by Cullen. See details in this thread:=A0<= span class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; fo= nt-size: 13px; background-color: rgb(255, 255, 255); ">http://www.mail-archive.com/whatwg@lists= .whatwg.org/msg26163.html. There's also non-intentional discrepanci= es that we know of, which we're trying to remove.

Just be = careful when looking at Chrome code to interpret the whatwg spec. We're= trying to interpret that spec in the same way as anyone else, and the what= wg author is not involved in the Chrome implementation.

Nik= las

On Thu, Jul 7, 2011 at 7:= 52 PM, Cullen Jennings <fluffy@cisco.com> wrote:

I went and looked at some call flows to try and sort out what is going on i= n the current released chrome code and as far as I can tell, Bernard you ar= e right, it is passing the data over the HTTP channel. An example of what I= see is below

As far as I can tell this is the JSON encoding of XEP-180 used in jingle an= d a separate JSON encoding of some of SDP. Not sure this matters much one w= ay or the other but wanted to pass on what I had found and I will correct t= he slides at some point - my apologies for getting them wrong.

Cullen



{
=A0 "media" : [
=A0 =A0 =A0{
=A0 =A0 =A0 =A0 "attributes" : {
=A0 =A0 =A0 =A0 =A0 =A0"candidate" : [
=A0 =A0 =A0 =A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"component" : 1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"foundation" : 1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"generation" : 0,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"ip" : "144.254.150.241&= quot;,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"name" : "rtp",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"network_name" : "Intel(= R) WiFi Link 1000 BGN",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"password" : "OpawIyXLYc= JkwxFa",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"port" : "61880", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"priority" : 1.0,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"proto" : "udp", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"type" : "local", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"username" : "90B0CPvC8p= 8XPMFt"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0 },
=A0 =A0 =A0 =A0 "label" : 1,
=A0 =A0 =A0 =A0 "rtpmap" : [
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "103" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/ISAC&qu= ot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "104" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/ISAC&qu= ot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "9" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/G722&qu= ot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "102" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/iLBC&qu= ot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "0" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/PCMU&qu= ot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "8" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/PCMA&qu= ot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "99" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/CN"= ;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "98" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/CN"= ;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "13" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/CN"= ;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "127" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/red&quo= t;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "106" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "audio/telepho= ne-event"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 ]
=A0 =A0 =A0},
=A0 =A0 =A0{
=A0 =A0 =A0 =A0 "attributes" : {
=A0 =A0 =A0 =A0 =A0 =A0"candidate" : [
=A0 =A0 =A0 =A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"component" : 1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"foundation" : 1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"generation" : 0,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"ip" : "144.254.150.241&= quot;,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"name" : "video_rtp"= ;,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"network_name" : "Intel(= R) WiFi Link 1000 BGN",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"password" : "G4dq4e3f/G= 7FDJ5h",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"port" : "61879", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"priority" : 1.0,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"proto" : "udp", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"type" : "local", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"username" : "CBkZYp6/DT= TMEFeM"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0 },
=A0 =A0 =A0 =A0 "label" : 2,
=A0 =A0 =A0 =A0 "rtpmap" : [
=A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "120" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"codec" : "video/VP8&quo= t;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 ]
=A0 =A0 =A0}
=A0 ]
}


On Jul 6, 2011, at 9:43 PM, Cullen Jennings wrote:

>
> On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote:
>
>>
>>
>> * The last slide now says that WhatWG proposal is low path; this i= s not true. The WhatWG proposal as I read it is mute on how the SDPs are ex= changed, it just hands those SDPs over to the
>>
>> application (though high path is indicated: "Communications a= re coordinated via a signaling channel provided by script in the page via t= he server, e.g. using XMLHttpRequest.")
>
> Hmm - my understanding was only the ICE related information was commun= icated that way and the SDP related information when across the channel set= up by ICE but I could be totally wrong. It's pretty vague in the spec = - I got that idea by talking to some of the people involved. Anyways, glad = to retract that WhatWG is doing low path and just change it to not clear. >
>
> _______________________________________________
> 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

--0016367658843677bb04a78a34c8-- From fluffy@cisco.com Fri Jul 8 07:11: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 EA2E521F8A7C for ; Fri, 8 Jul 2011 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.831 X-Spam-Level: X-Spam-Status: No, score=-104.831 tagged_above=-999 required=5 tests=[AWL=-2.232, 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 62f3O1NrM3lz for ; Fri, 8 Jul 2011 07:11:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8621F8A77 for ; Fri, 8 Jul 2011 07:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5678; q=dns/txt; s=iport; t=1310134295; x=1311343895; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+XjkCzNXjuRNVMouugRUm1KX/bFzDYISznxcHQSUrS0=; b=EYQsr0via+itTsIaun2ppH+RXTMcIZ5efD6zgENpoU4QOrjXUwmaqSLn NwDV7wLvS4yuvreWvq7BEpwb4szcSNfKT3RJ3yC5J6j3CgrLSPyyVIUzo B/ZNzPPp59xqszYRzhWgP8SDqfzNprjhToBjRKHhcehD5UgohSNQ4sYPl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANYPF06rRDoI/2dsb2JhbABQA6dFd4h7pG6df4NCgnYEh0yIdoIKhH2LZg X-IronPort-AV: E=Sophos;i="4.65,499,1304294400"; d="scan'208";a="1052838" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jul 2011 14:11:25 +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 p68EBNaY019690; Fri, 8 Jul 2011 14:11:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 8 Jul 2011 08:11:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.com> To: Niklas Enbom X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Jul 2011 14:11:36 -0000 Makes sense - thanks. I'm trying to interpret the spec by looking at the = code. I'll stop doing that :-) On Jul 8, 2011, at 1:58 AM, Niklas Enbom wrote: > Not sure in which thread I should answer... In Chrome we're trying to = implement the whatwg proposal with one intentional discrepancy, and = that's the string format pointed out by Cullen. See details in this = thread: = http://www.mail-archive.com/whatwg@lists.whatwg.org/msg26163.html. = There's also non-intentional discrepancies that we know of, which we're = trying to remove. >=20 > Just be careful when looking at Chrome code to interpret the whatwg = spec. We're trying to interpret that spec in the same way as anyone = else, and the whatwg author is not involved in the Chrome = implementation. >=20 > Niklas >=20 > On Thu, Jul 7, 2011 at 7:52 PM, Cullen Jennings = wrote: >=20 > I went and looked at some call flows to try and sort out what is going = on in the current released chrome code and as far as I can tell, Bernard = you are right, it is passing the data over the HTTP channel. An example = of what I see is below >=20 > As far as I can tell this is the JSON encoding of XEP-180 used in = jingle and a separate JSON encoding of some of SDP. Not sure this = matters much one way or the other but wanted to pass on what I had found = and I will correct the slides at some point - my apologies for getting = them wrong. >=20 > Cullen >=20 >=20 >=20 > { > "media" : [ > { > "attributes" : { > "candidate" : [ > { > "component" : 1, > "foundation" : 1, > "generation" : 0, > "ip" : "144.254.150.241", > "name" : "rtp", > "network_name" : "Intel(R) WiFi Link 1000 BGN", > "password" : "OpawIyXLYcJkwxFa", > "port" : "61880", > "priority" : 1.0, > "proto" : "udp", > "type" : "local", > "username" : "90B0CPvC8p8XPMFt" > } > ] > }, > "label" : 1, > "rtpmap" : [ > { > "103" : { > "codec" : "audio/ISAC" > } > }, > { > "104" : { > "codec" : "audio/ISAC" > } > }, > { > "9" : { > "codec" : "audio/G722" > } > }, > { > "102" : { > "codec" : "audio/iLBC" > } > }, > { > "0" : { > "codec" : "audio/PCMU" > } > }, > { > "8" : { > "codec" : "audio/PCMA" > } > }, > { > "99" : { > "codec" : "audio/CN" > } > }, > { > "98" : { > "codec" : "audio/CN" > } > }, > { > "13" : { > "codec" : "audio/CN" > } > }, > { > "127" : { > "codec" : "audio/red" > } > }, > { > "106" : { > "codec" : "audio/telephone-event" > } > } > ] > }, > { > "attributes" : { > "candidate" : [ > { > "component" : 1, > "foundation" : 1, > "generation" : 0, > "ip" : "144.254.150.241", > "name" : "video_rtp", > "network_name" : "Intel(R) WiFi Link 1000 BGN", > "password" : "G4dq4e3f/G7FDJ5h", > "port" : "61879", > "priority" : 1.0, > "proto" : "udp", > "type" : "local", > "username" : "CBkZYp6/DTTMEFeM" > } > ] > }, > "label" : 2, > "rtpmap" : [ > { > "120" : { > "codec" : "video/VP8" > } > } > ] > } > ] > } >=20 >=20 > On Jul 6, 2011, at 9:43 PM, Cullen Jennings wrote: >=20 > > > > On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote: > > > >> > >> > >> * The last slide now says that WhatWG proposal is low path; this is = not true. 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 indicated: "Communications are = coordinated via a signaling channel provided by script in the page via = the server, e.g. using XMLHttpRequest.") > > > > Hmm - my understanding was only the ICE related information was = communicated that way and the SDP related information when across the = channel set up by ICE but I could be totally wrong. It's pretty vague in = the spec - I got that idea by talking to some of the people involved. = Anyways, glad to retract that WhatWG is doing low path and just change = it to not clear. > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From stefan.lk.hakansson@ericsson.com Sun Jul 10 05:06: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 9011821F854F for ; Sun, 10 Jul 2011 05:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.083, 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 lT24uNx6KDJI for ; Sun, 10 Jul 2011 05:06:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4E21F854C for ; Sun, 10 Jul 2011 05:06:56 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-73-4e1995dff15f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C7.2D.20773.FD5991E4; Sun, 10 Jul 2011 14:06:55 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.110]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 10 Jul 2011 14:05:23 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Cullen Jennings , Niklas Enbom Importance: low X-Priority: 5 Date: Sun, 10 Jul 2011 14:05:23 +0200 Thread-Topic: [rtcweb] Media neg-eo-tiation and signalling archa-tecture Thread-Index: Acw9eSHCWlHJLaQQTNOoUmfW2UvccABf6Ka0 Message-ID: References: <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.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] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Jul 2011 12:06:58 -0000 We also followed the WhatWG proposal as well as possible in our implementat= ion (that you can download and test here: https://labs.ericsson.com/apis/we= b-real-time-communication/downloads). We're using SDP offer/answers as prop= osed in the whatwg spec; however there is a separate SDP dialogue per strea= m (and not per session) to avoid glaring conditions. The work also generated quite some feedback to whatwg: http://lists.whatwg.= org/htdig.cgi/whatwg-whatwg.org/2011-June/031950.html Stefan ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Cullen= Jennings [fluffy@cisco.com] Sent: Friday, July 08, 2011 4:11 PM To: Niklas Enbom Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture Makes sense - thanks. I'm trying to interpret the spec by looking at the co= de. I'll stop doing that :-) On Jul 8, 2011, at 1:58 AM, Niklas Enbom wrote: > Not sure in which thread I should answer... In Chrome we're trying to imp= lement the whatwg proposal with one intentional discrepancy, and that's the= string format pointed out by Cullen. See details in this thread: http://ww= w.mail-archive.com/whatwg@lists.whatwg.org/msg26163.html. There's also non-= intentional discrepancies that we know of, which we're trying to remove. > > Just be careful when looking at Chrome code to interpret the whatwg spec.= We're trying to interpret that spec in the same way as anyone else, and th= e whatwg author is not involved in the Chrome implementation. > > Niklas > > On Thu, Jul 7, 2011 at 7:52 PM, Cullen Jennings wrote: > > I went and looked at some call flows to try and sort out what is going on= in the current released chrome code and as far as I can tell, Bernard you = are right, it is passing the data over the HTTP channel. An example of what= I see is below > > As far as I can tell this is the JSON encoding of XEP-180 used in jingle = and a separate JSON encoding of some of SDP. Not sure this matters much one= way or the other but wanted to pass on what I had found and I will correct= the slides at some point - my apologies for getting them wrong. > > Cullen > > > > { > "media" : [ > { > "attributes" : { > "candidate" : [ > { > "component" : 1, > "foundation" : 1, > "generation" : 0, > "ip" : "144.254.150.241", > "name" : "rtp", > "network_name" : "Intel(R) WiFi Link 1000 BGN", > "password" : "OpawIyXLYcJkwxFa", > "port" : "61880", > "priority" : 1.0, > "proto" : "udp", > "type" : "local", > "username" : "90B0CPvC8p8XPMFt" > } > ] > }, > "label" : 1, > "rtpmap" : [ > { > "103" : { > "codec" : "audio/ISAC" > } > }, > { > "104" : { > "codec" : "audio/ISAC" > } > }, > { > "9" : { > "codec" : "audio/G722" > } > }, > { > "102" : { > "codec" : "audio/iLBC" > } > }, > { > "0" : { > "codec" : "audio/PCMU" > } > }, > { > "8" : { > "codec" : "audio/PCMA" > } > }, > { > "99" : { > "codec" : "audio/CN" > } > }, > { > "98" : { > "codec" : "audio/CN" > } > }, > { > "13" : { > "codec" : "audio/CN" > } > }, > { > "127" : { > "codec" : "audio/red" > } > }, > { > "106" : { > "codec" : "audio/telephone-event" > } > } > ] > }, > { > "attributes" : { > "candidate" : [ > { > "component" : 1, > "foundation" : 1, > "generation" : 0, > "ip" : "144.254.150.241", > "name" : "video_rtp", > "network_name" : "Intel(R) WiFi Link 1000 BGN", > "password" : "G4dq4e3f/G7FDJ5h", > "port" : "61879", > "priority" : 1.0, > "proto" : "udp", > "type" : "local", > "username" : "CBkZYp6/DTTMEFeM" > } > ] > }, > "label" : 2, > "rtpmap" : [ > { > "120" : { > "codec" : "video/VP8" > } > } > ] > } > ] > } > > > On Jul 6, 2011, at 9:43 PM, Cullen Jennings wrote: > > > > > On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote: > > > >> > >> > >> * The last slide now says that WhatWG proposal is low path; this is no= t true. The WhatWG proposal as I read it is mute on how the SDPs are exchan= ged, it just hands those SDPs over to the > >> > >> application (though high path is indicated: "Communications are coordi= nated via a signaling channel provided by script in the page via the server= , e.g. using XMLHttpRequest.") > > > > Hmm - my understanding was only the ICE related information was communi= cated that way and the SDP related information when across the channel set = up by ICE but I could be totally wrong. It's pretty vague in the spec - I g= ot that idea by talking to some of the people involved. Anyways, glad to re= tract that WhatWG is doing low path and just change it to not clear. > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From harald@alvestrand.no Mon Jul 11 06:44: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 DFAB421F8BD1 for ; Mon, 11 Jul 2011 06:44:02 -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 4bxxYoy3RnZC for ; Mon, 11 Jul 2011 06:44:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2B28621F8BD2 for ; Mon, 11 Jul 2011 06:44:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F02D539E179 for ; Mon, 11 Jul 2011 15:42: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 XNngq59xPltX for ; Mon, 11 Jul 2011 15:42:53 +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 5131939E087 for ; Mon, 11 Jul 2011 15:42:53 +0200 (CEST) Message-ID: <4E1AFE2C.4080201@alvestrand.no> Date: Mon, 11 Jul 2011 15:44:12 +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] Media neg-eo-tiation and signalling archa-tecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Jul 2011 13:44:03 -0000 On 07/07/11 05:43, Cullen Jennings wrote: > On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote: > >> >> * The last slide now says that WhatWG proposal is low path; this is not true. 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 indicated: "Communications are coordinated via a signaling channel provided by script in the page via the server, e.g. using XMLHttpRequest.") > Hmm - my understanding was only the ICE related information was communicated that way and the SDP related information when across the channel set up by ICE but I could be totally wrong. It's pretty vague in the spec - I got that idea by talking to some of the people involved. Anyways, glad to retract that WhatWG is doing low path and just change it to not clear. Google's current implementation of the WhatWG spec is "high path". If you dump the requests that the example client programs pass to the mediation server (which is talking fairly normal HTTP), you will see the JSON objects that contain the codec negotiation information. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Mon Jul 11 07:01: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 3EB4121F887C for ; Mon, 11 Jul 2011 07:01:45 -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 ixDSvKfWyCg5 for ; Mon, 11 Jul 2011 07:01:44 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0A82221F8700 for ; Mon, 11 Jul 2011 07:01:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE89339E179 for ; Mon, 11 Jul 2011 16:00:39 +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 IRDM9iOUTGOA for ; Mon, 11 Jul 2011 16:00:38 +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 0019D39E087 for ; Mon, 11 Jul 2011 16:00:37 +0200 (CEST) Message-ID: <4E1B0254.1050403@alvestrand.no> Date: Mon, 11 Jul 2011 16:01:56 +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> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070604010309080705030302" 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, 11 Jul 2011 14:01:45 -0000 This is a multi-part message in MIME format. --------------070604010309080705030302 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 06/22/11 05:59, Justin Uberti wrote: > 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. There might be some things it can do, even if it can neither recode nor do SVC-style tricks. For instance, if it's a distribution point (one incoming video stream, many outgoing copies), it can keep track of the maximal video size requested by any of its downstreams, and signal the upstream to send a resolution that is no higher than the largest resolution requested. I agree that we can't demand that the sender send exactly the resolution requested; in *many* cases, it's reasonable to send both higher and lower resolutions than the requested ones. > > > 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 > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------070604010309080705030302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/22/11 05:59, Justin Uberti wrote:
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.
There might be some things it can do, even if it can neither recode nor do SVC-style tricks.
For instance, if it's a distribution point (one incoming video stream, many outgoing copies), it can keep track of the maximal video size requested by any of its downstreams, and signal the upstream to send a resolution that is no higher than the largest resolution requested.

I agree that we can't demand that the sender send exactly the resolution requested; in *many* cases, it's reasonable to send both higher and lower resolutions than the requested ones.



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 <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.

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


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

--------------070604010309080705030302-- From harald@alvestrand.no Mon Jul 11 07:17: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 69BFD21F8570 for ; Mon, 11 Jul 2011 07:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 xLHdhmpgjTbn for ; Mon, 11 Jul 2011 07:17:38 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2D21F8C1A for ; Mon, 11 Jul 2011 07:17:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9925939E179 for ; Mon, 11 Jul 2011 16:16:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4NEIDVT98VV for ; Mon, 11 Jul 2011 16:16:25 +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 E622439E087 for ; Mon, 11 Jul 2011 16:16:24 +0200 (CEST) Message-ID: <4E1B0607.6080202@alvestrand.no> Date: Mon, 11 Jul 2011 16:17:43 +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: <4E0B0373.3040509@ericsson.com> In-Reply-To: <4E0B0373.3040509@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [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: Mon, 11 Jul 2011 14:17:38 -0000 Just one comment-on-comment: On 06/29/11 12:50, Stefan Hkansson LK wrote: > All, > > some comments to > > > > > 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. I disagree with this proposal. While the "resizing" requirement is in "simple video communication service" as "The users can change the display sizes during the session", I believe the basic use case does not derive the requirement that the change in video size be communicated to the other party. I would propose the following changes: - Reinstate the text below: 4.2.4. Video Size Change 4.2.4.1. Description 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 regenerates the video codec paramters with Alice's browser to change the resolution of the video Alice sends to match the smaller size. 4.2.4.2. Derived Requirements F22 ( It SHOULD be possible to modify video codec parameters during a session.) - Change the text of F22 to be: It SHOULD be possible for one party to request a change in video codec parameters, such as size, during a session, and for the other party to react to this request. From harald@alvestrand.no Mon Jul 11 07:21: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 EC09F21F8C27 for ; Mon, 11 Jul 2011 07:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 CnXWn9MY1Usu for ; Mon, 11 Jul 2011 07:21:30 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5321F8C1D for ; Mon, 11 Jul 2011 07:21:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BDB839E179 for ; Mon, 11 Jul 2011 16:20:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FInaKZ6B+rfT for ; Mon, 11 Jul 2011 16:20:24 +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 72A2E39E087 for ; Mon, 11 Jul 2011 16:20:24 +0200 (CEST) Message-ID: <4E1B06F7.5090807@alvestrand.no> Date: Mon, 11 Jul 2011 16:21:43 +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: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> <4E0DE382.9070309@gmail.com> <4E10B49D.2000908@gmail.com> In-Reply-To: <4E10B49D.2000908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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: Mon, 11 Jul 2011 14:21:31 -0000 Speaking with editor hat on: Unless someone else chimes in, I am not going to act on these requests. I regard the tying of "real-time" to "hundreds of milliseconds" as important - I have been in discussions where people have started arguing about single-millisecond delays and in discussions where people argue that "lag is not important as long as delivery occurs at a constant rate" - both are, to my mind, inappropriate and/or irrelevant for our use cases. With regard to "in a given time scale between known ahead-of-time (AOT) rate and known just-in-time (JIT) rate", I don't understand its intention. On 07/03/11 20:27, Dzonatas Sol wrote: > Before another glossary action happens, let me get this in (can't wait > for tomorrow): > > > Real-time media: Media where generation of content and display of > > content are intended to occur closely together in a given time > scale. > > """ > Real-time media: Media where generation of content and display of > content are intended to occur closely together in a given time scale > between known ahead-of-time (AOT) rate and known just-in-time (JIT) rate. > """ > > On 07/01/2011 08:10 AM, Dzonatas Sol wrote: >> Hi, I read the entire overview. Only one concern, in 2.4 Terminology: >> >> > Real-time media: Media where generation of content and display of >> > content are intended to occur closely together in time (on the >> > order of no more than hundreds of milliseconds). >> >> Can that just read: >> >> > Real-time media: Media where generation of content and display of >> > content are intended to occur closely together in a given time >> scale. >> >> I've found early specification of date systems may affect assets in >> ways unintended (or implied). There is no simple cure, so I think >> this is clearer without the noted "hundreds of milliseconds", there. >> >> Some have tried to build "authoritative" dates from such real-time >> mechanics. Others pass that date thinking it is part of the asset. >> I've seen it happen, so I'm just thinking it would be nice to have >> some way to say that was not intended, yet I haven't found any. >> >> On 06/30/2011 10:52 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Real-Time >>> Communication in WEB-browsers Working Group of the IETF. >>> >>> Title : Overview: Real Time Protocols for Brower-based >>> Applications >>> 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 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> > > From matthew.kaufman@skype.net Mon Jul 11 09:59: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 7745711E8086 for ; Mon, 11 Jul 2011 09:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNPxjBH4V+Uw for ; Mon, 11 Jul 2011 09:59:40 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 756DD21F8D25 for ; Mon, 11 Jul 2011 09:59:40 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 4C32316E2; Mon, 11 Jul 2011 18:59:39 +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=wq CHfvOiCjJ0apsEEpQ3ecdGAA4=; b=rJnrdDwCMereLmVrhjH5BJOX0S4SKMRgCX hEsqPaSC9yyS5Le8plRpiaqUwCkciluKY7rc9zGXYNzPnISlVcxYRgoDtcJz8A+s uQ6e4LVdlZCUaA3MVy6Gpj7LPdtbhmH2W4scK8xCdRdOvR0GKjuoGw7Mzg+XCKlM lijZIFF5g= 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=KX8axG9qzoCL5UngtrGtbN SwvEwW57ERsjYN5q/MQjJFdR/tUVZFqYD52S7j7zXvJDkOHXhsf31EW37Njv1T3O WsggYh9smmsceaolK8ugi3iorfRmoK9dsNvD/jtnLbL+kK+4U1ZYpHtLJGOFETwM p+01PnSTfcQy8b1qlmP10= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 4AD087F8; Mon, 11 Jul 2011 18:59:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 2920735079F2; Mon, 11 Jul 2011 18:59:39 +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 j+J59i8EVa4H; Mon, 11 Jul 2011 18:59:37 +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 5F9753507767; Mon, 11 Jul 2011 18:59:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Matthew Kaufman In-Reply-To: <4E0DB92F.8010501@ericsson.com> Date: Mon, 11 Jul 2011 09:59:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7658C729-8578-42E3-9193-6884756D18A6@skype.net> References: <20110630004852.10947.88695.idtracker@ietfa.amsl.com> <910D1894-3B1D-49CA-BAEF-9F50FF2B4ADB@skype.net> <4E0DB92F.8010501@ericsson.com> To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [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: Mon, 11 Jul 2011 16:59:41 -0000 On Jul 1, 2011, at 5:10 AM, Stefan H=E5kansson LK wrote: > Reading the draft I get the impression that the intention is to = multiplex (multiple) RTP streams with arbitrary datagrams on the same = 5-tuple. In that light the method lacks IMO: >=20 > * There is no multiplexing support for different RTP flows - as = discussed at the Interim meeting session separation should be maintained This draft doesn't address that. >=20 > * There is no support for rate/congestion control of the datagrams >=20 Correct. This is a tool for getting datagrams sent and received. = Congestion control, reliability, etc. are all a high-layer problem than = this. > * There is no support for multiplexing different datagram flows (the = need for this can be argued though - could be done by the web app) >=20 I would argue that this is an application problem, or possibly the = responsibility of a layer that goes above this. Matthew Kaufman From dzonatas@gmail.com Mon Jul 11 21:51: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 2FE4E21F8DEC for ; Mon, 11 Jul 2011 21:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.071 X-Spam-Level: X-Spam-Status: No, score=-5.071 tagged_above=-999 required=5 tests=[AWL=-1.472, 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 earSadLvzZbi for ; Mon, 11 Jul 2011 21:51:04 -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 20F4621F8DDF for ; Mon, 11 Jul 2011 21:51:03 -0700 (PDT) Received: by iye7 with SMTP id 7so5229267iye.31 for ; Mon, 11 Jul 2011 21:51:03 -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=LlV8nvZjBJZQzW3WkB1t6Sbh7RBe4+Bs0iwkeQYEIpw=; b=TMkUEBqTAOUZkbfbRr2PL+0U6g+mkYZ3sZYgqNlbTC0WsdFNNr6XWLqU/pBvFP9Xul JRt+xwTuKmzzcMUDNuUaFIqxxLNnElhKOgd+oD0ktGFNbzif4C2oSfaJB7nQw8xz6HB6 pk3nPh38KpjKCqRXaBWn5gW+j8gsAWRiOjH60= Received: by 10.42.189.195 with SMTP id df3mr463883icb.419.1310446261920; Mon, 11 Jul 2011 21:51:01 -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 us2sm392013icb.7.2011.07.11.21.50.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jul 2011 21:51:00 -0700 (PDT) Message-ID: <4E1BD2AB.9020809@gmail.com> Date: Mon, 11 Jul 2011 21:50:51 -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: <20110701055226.2267.16505.idtracker@ietfa.amsl.com> <4E0DE382.9070309@gmail.com> <4E10B49D.2000908@gmail.com> <4E1B06F7.5090807@alvestrand.no> In-Reply-To: <4E1B06F7.5090807@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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: Tue, 12 Jul 2011 04:51:06 -0000 Chair, The scale factor is known here: http://mathworld.wolfram.com/AffineTransformation.html Thanks. P.S. Next year is ok for review on this, thanks again. Engineers may want to test few "same" types of values, or "same" rates, like milliseconds, and revise. On 07/11/2011 07:21 AM, Harald Alvestrand wrote: > Speaking with editor hat on: > > Unless someone else chimes in, I am not going to act on these requests. > > I regard the tying of "real-time" to "hundreds of milliseconds" as > important - I have been in discussions where people have started > arguing about single-millisecond delays and in discussions where > people argue that "lag is not important as long as delivery occurs at > a constant rate" - both are, to my mind, inappropriate and/or > irrelevant for our use cases. > > With regard to "in a given time scale between known ahead-of-time > (AOT) rate and known just-in-time (JIT) rate", I don't understand its > intention. > > On 07/03/11 20:27, Dzonatas Sol wrote: >> Before another glossary action happens, let me get this in (can't >> wait for tomorrow): >> >> > Real-time media: Media where generation of content and display of >> > content are intended to occur closely together in a given time >> scale. >> >> """ >> Real-time media: Media where generation of content and display of >> content are intended to occur closely together in a given time scale >> between known ahead-of-time (AOT) rate and known just-in-time (JIT) >> rate. >> """ >> >> On 07/01/2011 08:10 AM, Dzonatas Sol wrote: >>> Hi, I read the entire overview. Only one concern, in 2.4 Terminology: >>> >>> > Real-time media: Media where generation of content and display of >>> > content are intended to occur closely together in time (on the >>> > order of no more than hundreds of milliseconds). >>> >>> Can that just read: >>> >>> > Real-time media: Media where generation of content and display of >>> > content are intended to occur closely together in a given >>> time scale. >>> >>> I've found early specification of date systems may affect assets in >>> ways unintended (or implied). There is no simple cure, so I think >>> this is clearer without the noted "hundreds of milliseconds", there. >>> >>> Some have tried to build "authoritative" dates from such real-time >>> mechanics. Others pass that date thinking it is part of the asset. >>> I've seen it happen, so I'm just thinking it would be nice to have >>> some way to say that was not intended, yet I haven't found any. >>> >>> On 06/30/2011 10:52 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the Real-Time >>>> Communication in WEB-browsers Working Group of the IETF. >>>> >>>> Title : Overview: Real Time Protocols for >>>> Brower-based Applications >>>> 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 >>>> _______________________________________________ >>>> 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 > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From harald@alvestrand.no Tue Jul 12 04:54:16 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 747E121F8F22 for ; Tue, 12 Jul 2011 04:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 lWEQsq-1T0eP for ; Tue, 12 Jul 2011 04:54:16 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CB85921F9046 for ; Tue, 12 Jul 2011 04:54:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A5DF39E0C4 for ; Tue, 12 Jul 2011 13:53: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 sXc4CFdQbEsz for ; Tue, 12 Jul 2011 13:53:10 +0200 (CEST) Received: from [172.16.41.226] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E045C39E091 for ; Tue, 12 Jul 2011 13:53:09 +0200 (CEST) Message-ID: <4E1C35E4.9000204@alvestrand.no> Date: Tue, 12 Jul 2011 13:54:12 +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: <3017EF1A-D479-4D61-B9B2-BECD5DA043C0@cisco.com> In-Reply-To: <3017EF1A-D479-4D61-B9B2-BECD5DA043C0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Media processing and codecs (Re: draft rtcweb agenda for IETF 81 - version 2) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Jul 2011 11:54:16 -0000 On 07/05/11 18:00, Cullen Jennings wrote: > Media processing& codec (20 min) > draft-cbran-rtcweb-codec > draft-alvestrand-dispatch-rtcweb-protocols > * focus on requirements for codecs I think the technical content of draft-alvestrand-dispatch-rtcweb-protocols in the area of codecs is adequately represented by draft-cbran-rtcweb-codec, so that (older) draft does not need to be listed. There are sections of -overview that are relevant to the discussion, in particular the text about the reasons why having mandatory-to-implement codecs are good. Harald From stefan.lk.hakansson@ericsson.com Tue Jul 12 04:58: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 463E121F8FF5 for ; Tue, 12 Jul 2011 04:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 JuqfFFapz40C for ; Tue, 12 Jul 2011 04:58: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 258B521F8FEA for ; Tue, 12 Jul 2011 04:58:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-28-4e1c370077a2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A5.3D.09774.0073C1E4; Tue, 12 Jul 2011 13:58:56 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.110]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 12 Jul 2011 13:58:55 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand , "rtcweb@ietf.org" Date: Tue, 12 Jul 2011 13:58:56 +0200 Thread-Topic: [rtcweb] Comments to use-cases/reqs document Thread-Index: Acw/1WYjrSoUFie5Qii6GYVnY+0TVAAs3RfH Message-ID: References: <4E0B0373.3040509@ericsson.com>,<4E1B0607.6080202@alvestrand.no> In-Reply-To: <4E1B0607.6080202@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] 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: Tue, 12 Jul 2011 11:58:58 -0000 >> All, >> >> some comments to >> >> >> >> >> 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. > >I disagree with this proposal. >While the "resizing" requirement is in "simple video communication >service" as >"The users can change the display sizes during the session", I believe >the basic use case does not derive the requirement that the change in >video size be communicated to the other party. > >I would propose the following changes: >- Reinstate the text below: > >4.2.4. Video Size Change > >4.2.4.1. Description > > 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 regenerates the video codec paramters with Alice's > browser to change the resolution of the video Alice sends to match > the smaller size. My preference is always to keep the number of use cases down. Could we not = just add a sentence to the current "Simple Video Communication Service" use= case so it reads something like "The users can change the sizes of the vid= eo displays during the session. Changes of the display size are communicate= d from the displaying browser to the one sending the stream so that the vid= eo codec parameters can be changed accordingly." But my preference is not strong - I'm happy to reinsert the use case if peo= ple think so. >4.2.4.2. Derived Requirements > > F22 ( It SHOULD be possible to modify video codec parameters during a > session.) F22 now reads "The browser SHOULD use encoding of streams suitable for the = current rendering (e.g. video display size) and SHOULD change parameters if= the rendering changes during the session" > >- Change the text of F22 to be: > > It SHOULD be possible for one party to request a change in video >codec parameters, such as size, > during a session, and for the other party to react to this request. I think "party" is very vague. What does it mean - the browser, the user, t= he web app? Stefan _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From harald@alvestrand.no Tue Jul 12 07:17: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 06FC921F8DFE for ; Tue, 12 Jul 2011 07:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227, 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 xF6Xav16jA8N for ; Tue, 12 Jul 2011 07:17:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0921F8D90 for ; Tue, 12 Jul 2011 07:17:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 938BD39E0C4; Tue, 12 Jul 2011 16:16:07 +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 l5hRQgaqKkUX; Tue, 12 Jul 2011 16:16:06 +0200 (CEST) Received: from [172.16.41.226] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id F154139E091; Tue, 12 Jul 2011 16:16:05 +0200 (CEST) Message-ID: <4E1C5764.5070708@alvestrand.no> Date: Tue, 12 Jul 2011 16:17:08 +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: <4E0B0373.3040509@ericsson.com>, <4E1B0607.6080202@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] 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: Tue, 12 Jul 2011 14:17:19 -0000 On 07/12/11 13:58, Stefan Hkansson LK wrote: >>> All, >>> >>> some comments to >>> >>> >>> >>> >>> 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. >> I disagree with this proposal. >> While the "resizing" requirement is in "simple video communication >> service" as >> "The users can change the display sizes during the session", I believe >> the basic use case does not derive the requirement that the change in >> video size be communicated to the other party. >> >> I would propose the following changes: >> - Reinstate the text below: >> >> 4.2.4. Video Size Change >> >> 4.2.4.1. Description >> >> 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 regenerates the video codec paramters with Alice's >> browser to change the resolution of the video Alice sends to match >> the smaller size. > My preference is always to keep the number of use cases down. We may have a difference of style here - I prefer to have explicit use cases that show only a single action or attribute that needs to be supported, which means that the number of use cases tends to be high. I think this is especially important for the situation where a WG has to decide to drop an use case because no agreed-upon implementation can be found. > Could we not just add a sentence to the current "Simple Video Communication Service" use case so it reads something like "The users can change the sizes of the video displays during the session. Changes of the display size are communicated from the displaying browser to the one sending the stream so that the video codec parameters can be changed accordingly." As per above - I would prefer the "Simple Video Communication Service" to be as simple as possible. Even resizing the window locally is more than "as simple as possible" - the Gtalk video client for my phone doesn't support that. > But my preference is not strong - I'm happy to reinsert the use case if people think so. >> 4.2.4.2. Derived Requirements >> >> F22 ( It SHOULD be possible to modify video codec parameters during a >> session.) > F22 now reads "The browser SHOULD use encoding of streams suitable for the current rendering (e.g. video display size) and SHOULD change parameters if the rendering changes during the session" >> - Change the text of F22 to be: >> >> It SHOULD be possible for one party to request a change in video >> codec parameters, such as size, >> during a session, and for the other party to react to this request. > I think "party" is very vague. What does it mean - the browser, the user, the web app? Since this is the IETF WG - the "party" is the browser, user and web app together; somehow the desire for a change has to be communicated across the network, and that's the requirement I think needs to be in the IETF requirements list. The corresponding API requirement (which I'm not sure how to formulate - all this may go on in the browser and need no explicit API) needs to go into the W3C requirements list. From stewe@stewe.org Tue Jul 12 07:36: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 6EA9121F887C for ; Tue, 12 Jul 2011 07:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 u6Qbxzdtdf3n for ; Tue, 12 Jul 2011 07:36:03 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4070921F8700 for ; Tue, 12 Jul 2011 07:36:02 -0700 (PDT) Received: from [192.168.1.104] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 12153-1743317 for multiple; Tue, 12 Jul 2011 16:36:00 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 12 Jul 2011 07:35:51 -0700 From: Stephan Wenger To: Harald Alvestrand , Stefan =?ISO-8859-1?B?SOVrYW5zc29u?= LK Message-ID: Thread-Topic: [rtcweb] Comments to use-cases/reqs document In-Reply-To: <4E1C5764.5070708@alvestrand.no> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 Cc: "rtcweb@ietf.org" Subject: Re: [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: Tue, 12 Jul 2011 14:36:05 -0000 Hi Harald, If you define "simple" as "minimum functionality", then there should also be a use case "not quite so simple; offer at least the user experience you get from a Skype client today". That use case may well turn out to be more popular than the "simple" use case according to your definition. However, my preference would be not to assume minimalistic use cases, but rather tune the level of mandation of the requirements. (So I'm in Stefan's camp -- keeping the number of use cases reasonable) Stephan On 7.12.2011 07:17 , "Harald Alvestrand" wrote: >On 07/12/11 13:58, Stefan H=E5kansson LK wrote: >>>> All, >>>> >>>> some comments to >>>>=20 >>>>>>>ements/?include_text=3D1> >>>> >>>> >>>> >>>> 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. >>> I disagree with this proposal. >>> While the "resizing" requirement is in "simple video communication >>> service" as >>> "The users can change the display sizes during the session", I believe >>> the basic use case does not derive the requirement that the change in >>> video size be communicated to the other party. >>> >>> I would propose the following changes: >>> - Reinstate the text below: >>> >>> 4.2.4. Video Size Change >>> >>> 4.2.4.1. Description >>> >>> 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 regenerates the video codec paramters with Alice's >>> browser to change the resolution of the video Alice sends to match >>> the smaller size. >> My preference is always to keep the number of use cases down. >We may have a difference of style here - I prefer to have explicit use >cases that show only a single action or attribute that needs to be >supported, which means that the number of use cases tends to be high. > >I think this is especially important for the situation where a WG has to >decide to drop an use case because no agreed-upon implementation can be >found. >> Could we not just add a sentence to the current "Simple Video >>Communication Service" use case so it reads something like "The users >>can change the sizes of the video displays during the session. Changes >>of the display size are communicated from the displaying browser to the >>one sending the stream so that the video codec parameters can be changed >>accordingly." >As per above - I would prefer the "Simple Video Communication Service" >to be as simple as possible. Even resizing the window locally is more >than "as simple as possible" - the Gtalk video client for my phone >doesn't support that. >> But my preference is not strong - I'm happy to reinsert the use case if >>people think so. >>> 4.2.4.2. Derived Requirements >>> >>> F22 ( It SHOULD be possible to modify video codec parameters >>>during a >>> session.) >> F22 now reads "The browser SHOULD use encoding of streams suitable for >>the current rendering (e.g. video display size) and SHOULD change >>parameters if the rendering changes during the session" >>> - Change the text of F22 to be: >>> >>> It SHOULD be possible for one party to request a change in video >>> codec parameters, such as size, >>> during a session, and for the other party to react to this request. >> I think "party" is very vague. What does it mean - the browser, the >>user, the web app? >Since this is the IETF WG - the "party" is the browser, user and web app >together; somehow the desire for a change has to be communicated across >the network, and that's the requirement I think needs to be in the IETF >requirements list. > >The corresponding API requirement (which I'm not sure how to formulate - >all this may go on in the browser and need no explicit API) needs to go >into the W3C requirements list. > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Jul 12 08:02: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 B136E21F8CB3 for ; Tue, 12 Jul 2011 08:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.854 X-Spam-Level: X-Spam-Status: No, score=-99.854 tagged_above=-999 required=5 tests=[AWL=-2.482, BAYES_00=-2.599, GB_SUMOF=5, SARE_SUB_OBFU_Q1=0.227, 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 7WNmkRXdP4pb for ; Tue, 12 Jul 2011 08:02:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A936521F8CF4 for ; Tue, 12 Jul 2011 08:02:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E81B39E0C4; Tue, 12 Jul 2011 17:01: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 OjTVTHRx1JP0; Tue, 12 Jul 2011 17:01:46 +0200 (CEST) Received: from [172.16.41.226] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 92CC539E091; Tue, 12 Jul 2011 17:01:45 +0200 (CEST) Message-ID: <4E1C6215.1000601@alvestrand.no> Date: Tue, 12 Jul 2011 17:02: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: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [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: Tue, 12 Jul 2011 15:02:52 -0000 On 07/12/11 16:35, Stephan Wenger wrote: > Hi Harald, > If you define "simple" as "minimum functionality", then there should also > be a use case "not quite so simple; offer at least the user experience you > get from a Skype client today". That use case may well turn out to be > more popular than the "simple" use case according to your definition. > However, my preference would be not to assume minimalistic use cases, but > rather tune the level of mandation of the requirements. (So I'm in > Stefan's camp -- keeping the number of use cases reasonable) I'm all for "reasonable", but my "reasonable" may be different from yours.... the sum of all requirements should indeed allow us to build equivalents to Skype or Google Talk on top of this platform (except for the parts that don't make sense, of course :-) ), but I find it easier to talk about auto-zoom to keep head size constant (for instance - at least one Skype beta supported that) as a separate use case, not merged with the "basic use case". > Stephan > > > On 7.12.2011 07:17 , "Harald Alvestrand" wrote: > >> On 07/12/11 13:58, Stefan Hkansson LK wrote: >>>>> All, >>>>> >>>>> some comments to >>>>> >>>>> >>>> ements/?include_text=1> >>>>> >>>>> >>>>> >>>>> 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. >>>> I disagree with this proposal. >>>> While the "resizing" requirement is in "simple video communication >>>> service" as >>>> "The users can change the display sizes during the session", I believe >>>> the basic use case does not derive the requirement that the change in >>>> video size be communicated to the other party. >>>> >>>> I would propose the following changes: >>>> - Reinstate the text below: >>>> >>>> 4.2.4. Video Size Change >>>> >>>> 4.2.4.1. Description >>>> >>>> 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 regenerates the video codec paramters with Alice's >>>> browser to change the resolution of the video Alice sends to match >>>> the smaller size. >>> My preference is always to keep the number of use cases down. >> We may have a difference of style here - I prefer to have explicit use >> cases that show only a single action or attribute that needs to be >> supported, which means that the number of use cases tends to be high. >> >> I think this is especially important for the situation where a WG has to >> decide to drop an use case because no agreed-upon implementation can be >> found. >>> Could we not just add a sentence to the current "Simple Video >>> Communication Service" use case so it reads something like "The users >>> can change the sizes of the video displays during the session. Changes >>> of the display size are communicated from the displaying browser to the >>> one sending the stream so that the video codec parameters can be changed >>> accordingly." >> As per above - I would prefer the "Simple Video Communication Service" >> to be as simple as possible. Even resizing the window locally is more >> than "as simple as possible" - the Gtalk video client for my phone >> doesn't support that. >>> But my preference is not strong - I'm happy to reinsert the use case if >>> people think so. >>>> 4.2.4.2. Derived Requirements >>>> >>>> F22 ( It SHOULD be possible to modify video codec parameters >>>> during a >>>> session.) >>> F22 now reads "The browser SHOULD use encoding of streams suitable for >>> the current rendering (e.g. video display size) and SHOULD change >>> parameters if the rendering changes during the session" >>>> - Change the text of F22 to be: >>>> >>>> It SHOULD be possible for one party to request a change in video >>>> codec parameters, such as size, >>>> during a session, and for the other party to react to this request. >>> I think "party" is very vague. What does it mean - the browser, the >>> user, the web app? >> Since this is the IETF WG - the "party" is the browser, user and web app >> together; somehow the desire for a change has to be communicated across >> the network, and that's the requirement I think needs to be in the IETF >> requirements list. >> >> The corresponding API requirement (which I'm not sure how to formulate - >> all this may go on in the browser and need no explicit API) needs to go >> into the W3C requirements list. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > From stewe@stewe.org Tue Jul 12 08:09: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 4E6F121F8B32 for ; Tue, 12 Jul 2011 08:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[AWL=-2.276, BAYES_00=-2.599, GB_SUMOF=5, 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 SYqeQDcU5mkN for ; Tue, 12 Jul 2011 08:09:38 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id B8CF521F8C47 for ; Tue, 12 Jul 2011 08:09:28 -0700 (PDT) Received: from [192.168.1.104] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 12171-1743317 for multiple; Tue, 12 Jul 2011 17:09:27 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 12 Jul 2011 08:09:20 -0700 From: Stephan Wenger To: Harald Alvestrand Message-ID: Thread-Topic: [rtcweb] Comments to use-cases/reqs document In-Reply-To: <4E1C6215.1000601@alvestrand.no> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 Cc: "rtcweb@ietf.org" Subject: Re: [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: Tue, 12 Jul 2011 15:09:40 -0000 That's fine, but then you need to add at least one more use case: point-to-point, and not quite simple... Stephan On 7.12.2011 08:02 , "Harald Alvestrand" wrote: >On 07/12/11 16:35, Stephan Wenger wrote: >> Hi Harald, >> If you define "simple" as "minimum functionality", then there should >>also >> be a use case "not quite so simple; offer at least the user experience >>you >> get from a Skype client today". That use case may well turn out to be >> more popular than the "simple" use case according to your definition. >> However, my preference would be not to assume minimalistic use cases, >>but >> rather tune the level of mandation of the requirements. (So I'm in >> Stefan's camp -- keeping the number of use cases reasonable) >I'm all for "reasonable", but my "reasonable" may be different from >yours.... the sum of all requirements should indeed allow us to build >equivalents to Skype or Google Talk on top of this platform (except for >the parts that don't make sense, of course :-) ), but I find it easier >to talk about auto-zoom to keep head size constant (for instance - at >least one Skype beta supported that) as a separate use case, not merged >with the "basic use case". > >> Stephan >> >> >> On 7.12.2011 07:17 , "Harald Alvestrand" wrote: >> >>> On 07/12/11 13:58, Stefan H=E5kansson LK wrote: >>>>>> All, >>>>>> >>>>>> some comments to >>>>>> >>>>>>=20 >>>>>>>>>>>ir >>>>>> ements/?include_text=3D1> >>>>>> >>>>>> >>>>>> >>>>>> 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. >>>>> I disagree with this proposal. >>>>> While the "resizing" requirement is in "simple video communication >>>>> service" as >>>>> "The users can change the display sizes during the session", I >>>>>believe >>>>> the basic use case does not derive the requirement that the change in >>>>> video size be communicated to the other party. >>>>> >>>>> I would propose the following changes: >>>>> - Reinstate the text below: >>>>> >>>>> 4.2.4. Video Size Change >>>>> >>>>> 4.2.4.1. Description >>>>> >>>>> 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 regenerates the video codec paramters with Alice's >>>>> browser to change the resolution of the video Alice sends to >>>>>match >>>>> the smaller size. >>>> My preference is always to keep the number of use cases down. >>> We may have a difference of style here - I prefer to have explicit use >>> cases that show only a single action or attribute that needs to be >>> supported, which means that the number of use cases tends to be high. >>> >>> I think this is especially important for the situation where a WG has >>>to >>> decide to drop an use case because no agreed-upon implementation can be >>> found. >>>> Could we not just add a sentence to the current "Simple Video >>>> Communication Service" use case so it reads something like "The users >>>> can change the sizes of the video displays during the session. Changes >>>> of the display size are communicated from the displaying browser to >>>>the >>>> one sending the stream so that the video codec parameters can be >>>>changed >>>> accordingly." >>> As per above - I would prefer the "Simple Video Communication Service" >>> to be as simple as possible. Even resizing the window locally is more >>> than "as simple as possible" - the Gtalk video client for my phone >>> doesn't support that. >>>> But my preference is not strong - I'm happy to reinsert the use case >>>>if >>>> people think so. >>>>> 4.2.4.2. Derived Requirements >>>>> >>>>> F22 ( It SHOULD be possible to modify video codec parameters >>>>> during a >>>>> session.) >>>> F22 now reads "The browser SHOULD use encoding of streams suitable for >>>> the current rendering (e.g. video display size) and SHOULD change >>>> parameters if the rendering changes during the session" >>>>> - Change the text of F22 to be: >>>>> >>>>> It SHOULD be possible for one party to request a change in video >>>>> codec parameters, such as size, >>>>> during a session, and for the other party to react to this >>>>>request. >>>> I think "party" is very vague. What does it mean - the browser, the >>>> user, the web app? >>> Since this is the IETF WG - the "party" is the browser, user and web >>>app >>> together; somehow the desire for a change has to be communicated across >>> the network, and that's the requirement I think needs to be in the IETF >>> requirements list. >>> >>> The corresponding API requirement (which I'm not sure how to formulate >>>- >>> all this may go on in the browser and need no explicit API) needs to go >>> into the W3C requirements list. >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > From henry.sinnreich@gmail.com Tue Jul 12 08:56: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 2919621F8ED2 for ; Tue, 12 Jul 2011 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-2.614, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1, 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 z20LdCuqLkqB for ; Tue, 12 Jul 2011 08:56:26 -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 5D75721F8EC8 for ; Tue, 12 Jul 2011 08:56:26 -0700 (PDT) Received: by yxp4 with SMTP id 4so2515154yxp.31 for ; Tue, 12 Jul 2011 08:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ZR4M5pRN5bN24PKyFYbJyzs5Wbb60IsEpBuUawS8bFE=; b=pHeRfYou7UiP5MiekuNswXdw8faiuslp2iD5yPMZGFjIothrDneep/PL5b5BrnK+5l O/HXPSZIv7amh+GBxrp63Yu0C5IvBEtBOQY1/8xsAKcWvgaWwb3Xy64Jm+pBbMe17ArF PgKhBJ1oJL3vCcMYHXhpJH/0nHqYTUtSKnicw= Received: by 10.101.23.17 with SMTP id a17mr69021anj.143.1310486185742; Tue, 12 Jul 2011 08:56:25 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-164.tx.res.rr.com [76.184.227.164]) by mx.google.com with ESMTPS id v9sm13462239anv.30.2011.07.12.08.56.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 08:56:24 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 12 Jul 2011 10:56:21 -0500 From: Henry Sinnreich To: Harald Alvestrand , Stephan Wenger Message-ID: Thread-Topic: [rtcweb] Comments to use-cases/reqs document Thread-Index: AcxArD5C3J+SPmk77k60BK3v+Cm4CQ== In-Reply-To: <4E1C6215.1000601@alvestrand.no> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [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: Tue, 12 Jul 2011 15:56:27 -0000 +1 The use cases and especially requirements should be kept as simple/minimal as possible but no more. Actually the most interesting use cases may not be known at present; a good test if rtcweb is really innovative. =20 Quite happy that Harald and Cullen seem to keep firm control on this. As for the video/screens parameters, one of my gripes is the use of antiquated SDP instead of standard metadata formats for all screens, I/O devices, etc.=20 SDP is a big can of worms to throw out. Legacy RTP as well, but this seems to be covered for now. Finally, just to put all my gripes in one place: Why not use HIP with ICE/HIP instead if SIP-ICE? This is so self evident. Thanks, Henry On 7/12/11 10:02 AM, "Harald Alvestrand" wrote: > On 07/12/11 16:35, Stephan Wenger wrote: >> Hi Harald, >> If you define "simple" as "minimum functionality", then there should als= o >> be a use case "not quite so simple; offer at least the user experience y= ou >> get from a Skype client today". That use case may well turn out to be >> more popular than the "simple" use case according to your definition. >> However, my preference would be not to assume minimalistic use cases, bu= t >> rather tune the level of mandation of the requirements. (So I'm in >> Stefan's camp -- keeping the number of use cases reasonable) > I'm all for "reasonable", but my "reasonable" may be different from > yours.... the sum of all requirements should indeed allow us to build > equivalents to Skype or Google Talk on top of this platform (except for > the parts that don't make sense, of course :-) ), but I find it easier > to talk about auto-zoom to keep head size constant (for instance - at > least one Skype beta supported that) as a separate use case, not merged > with the "basic use case". >=20 >> Stephan >>=20 >>=20 >> On 7.12.2011 07:17 , "Harald Alvestrand" wrote: >>=20 >>> On 07/12/11 13:58, Stefan H=E5kansson LK wrote: >>>>>> All, >>>>>>=20 >>>>>> some comments to >>>>>>=20 >>>>>> >>>>> ements/?include_text=3D1> >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>> I disagree with this proposal. >>>>> While the "resizing" requirement is in "simple video communication >>>>> service" as >>>>> "The users can change the display sizes during the session", I believ= e >>>>> the basic use case does not derive the requirement that the change in >>>>> video size be communicated to the other party. >>>>>=20 >>>>> I would propose the following changes: >>>>> - Reinstate the text below: >>>>>=20 >>>>> 4.2.4. Video Size Change >>>>>=20 >>>>> 4.2.4.1. Description >>>>>=20 >>>>> Alice and Bob are in a video call in their browsers and have >>>>> negotiate a high resolution video. Bob decides to change the si= ze >>>>> of >>>>> the windows his browser is displaying video to a small size. >>>>>=20 >>>>> Bob's browser regenerates the video codec paramters with Alice's >>>>> browser to change the resolution of the video Alice sends to mat= ch >>>>> the smaller size. >>>> My preference is always to keep the number of use cases down. >>> We may have a difference of style here - I prefer to have explicit use >>> cases that show only a single action or attribute that needs to be >>> supported, which means that the number of use cases tends to be high. >>>=20 >>> I think this is especially important for the situation where a WG has t= o >>> decide to drop an use case because no agreed-upon implementation can be >>> found. >>>> Could we not just add a sentence to the current "Simple Video >>>> Communication Service" use case so it reads something like "The users >>>> can change the sizes of the video displays during the session. Changes >>>> of the display size are communicated from the displaying browser to th= e >>>> one sending the stream so that the video codec parameters can be chang= ed >>>> accordingly." >>> As per above - I would prefer the "Simple Video Communication Service" >>> to be as simple as possible. Even resizing the window locally is more >>> than "as simple as possible" - the Gtalk video client for my phone >>> doesn't support that. >>>> But my preference is not strong - I'm happy to reinsert the use case i= f >>>> people think so. >>>>> 4.2.4.2. Derived Requirements >>>>>=20 >>>>> F22 ( It SHOULD be possible to modify video codec parameters >>>>> during a >>>>> session.) >>>> F22 now reads "The browser SHOULD use encoding of streams suitable for >>>> the current rendering (e.g. video display size) and SHOULD change >>>> parameters if the rendering changes during the session" >>>>> - Change the text of F22 to be: >>>>>=20 >>>>> It SHOULD be possible for one party to request a change in video >>>>> codec parameters, such as size, >>>>> during a session, and for the other party to react to this reques= t. >>>> I think "party" is very vague. What does it mean - the browser, the >>>> user, the web app? >>> Since this is the IETF WG - the "party" is the browser, user and web ap= p >>> together; somehow the desire for a change has to be communicated across >>> the network, and that's the requirement I think needs to be in the IETF >>> requirements list. >>>=20 >>> The corresponding API requirement (which I'm not sure how to formulate = - >>> all this may go on in the browser and need no explicit API) needs to go >>> into the W3C requirements list. >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Tue Jul 12 10:23: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 997A221F8C07 for ; Tue, 12 Jul 2011 10:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=-4.308, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 hPyKdEy7XY6r for ; Tue, 12 Jul 2011 10:23:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7670E21F8C04 for ; Tue, 12 Jul 2011 10:23:27 -0700 (PDT) Received: by iwn39 with SMTP id 39so5839319iwn.31 for ; Tue, 12 Jul 2011 10:23:27 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MOWWzWDoWzf06aw/96gjzMXgMUoAIOdzRysOiOHUoMA=; b=YTYGeAx6rrtyHqi4T8OkopD2LaEsVeKq45BWrxhH5sTloS95T/Wm6bwiS9syAYcevC j7M3cSB5N27RptBAMagTtt0COUiUwdbevDTtkzIV24CoyTPquBiRFn+RIYqm+AT8BnOt I4jrHaPDn3j6eKQxril721Wxn955NwnHz8Q58= Received: by 10.42.229.198 with SMTP id jj6mr170265icb.203.1310491405526; Tue, 12 Jul 2011 10:23:25 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id v16sm8425655ibe.34.2011.07.12.10.23.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 10:23:23 -0700 (PDT) Message-ID: <4E1C8303.9010206@gmail.com> Date: Tue, 12 Jul 2011 10:23:15 -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: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [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: Tue, 12 Jul 2011 17:23:31 -0000 The crystal radio is "not quite simple" if we use standard memory technology (or hard-ware version). Given signal-to-noise, the maximal fractal surface may seem to be the union of point-to-point. That is falsifiable, the millisecond is not unless one proves one. ASCII presents "the choice" to support that. Standard? "Not my business." The event horizon for real-time appears only simulated (by us), and I like the religions topics on this, for science by science. For example, We could express: millisecond := alpha+beta We could write that with MathML, yet the published MathML is not in plain English, enough. Reason? Maybe. How do you know if that means "square root of the value of alpha plus beta" or "alpha squared plus beta squared, and that the square root of that value". Which quote is in present tense? The obvious. The constance is the power of two, a magic number in computer science, yet for mathematics, a real number? 1 + 1. Elementary support for that number? Some say not their business. Let's revisit the scale factor of affine transformations: http://mathworld.wolfram.com/AffineTransformation.html How would re-write that equation to remove the magic numbers in order to have the pure scalar value? Replace the first two and last two with "alpha" and "omega", and format with XML to MathML. Is the truth, the pure scalar value, of two relative to the affine transformation by Wolfram? Ballard's method is E=mcc, so not always. Mathematicians think relative to "Energy equals mass times speed of light to the power of two." Use-case for "real-time": law of two. On 07/12/2011 08:09 AM, Stephan Wenger wrote: > That's fine, but then you need to add at least one more use case: > point-to-point, and not quite simple... > Stephan > > > On 7.12.2011 08:02 , "Harald Alvestrand" wrote: > > >> On 07/12/11 16:35, Stephan Wenger wrote: >> >>> Hi Harald, >>> If you define "simple" as "minimum functionality", then there should >>> also >>> be a use case "not quite so simple; offer at least the user experience >>> you >>> get from a Skype client today". That use case may well turn out to be >>> more popular than the "simple" use case according to your definition. >>> However, my preference would be not to assume minimalistic use cases, >>> but >>> rather tune the level of mandation of the requirements. (So I'm in >>> Stefan's camp -- keeping the number of use cases reasonable) >>> >> I'm all for "reasonable", but my "reasonable" may be different from >> yours.... the sum of all requirements should indeed allow us to build >> equivalents to Skype or Google Talk on top of this platform (except for >> the parts that don't make sense, of course :-) ), but I find it easier >> to talk about auto-zoom to keep head size constant (for instance - at >> least one Skype beta supported that) as a separate use case, not merged >> with the "basic use case". >> >> >>> Stephan >>> >>> >>> On 7.12.2011 07:17 , "Harald Alvestrand" wrote: >>> >>> >>>> On 07/12/11 13:58, Stefan H�kansson LK wrote: >>>> >>>>>>> All, >>>>>>> >>>>>>> some comments to >>>>>>> >>>>>>> >>>>>>> >>>>>> ir >>>>>>> ements/?include_text=1> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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. >>>>>>> >>>>>> I disagree with this proposal. >>>>>> While the "resizing" requirement is in "simple video communication >>>>>> service" as >>>>>> "The users can change the display sizes during the session", I >>>>>> believe >>>>>> the basic use case does not derive the requirement that the change in >>>>>> video size be communicated to the other party. >>>>>> >>>>>> I would propose the following changes: >>>>>> - Reinstate the text below: >>>>>> >>>>>> 4.2.4. Video Size Change >>>>>> >>>>>> 4.2.4.1. Description >>>>>> >>>>>> 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 regenerates the video codec paramters with Alice's >>>>>> browser to change the resolution of the video Alice sends to >>>>>> match >>>>>> the smaller size. >>>>>> >>>>> My preference is always to keep the number of use cases down. >>>>> >>>> We may have a difference of style here - I prefer to have explicit use >>>> cases that show only a single action or attribute that needs to be >>>> supported, which means that the number of use cases tends to be high. >>>> >>>> I think this is especially important for the situation where a WG has >>>> to >>>> decide to drop an use case because no agreed-upon implementation can be >>>> found. >>>> >>>>> Could we not just add a sentence to the current "Simple Video >>>>> Communication Service" use case so it reads something like "The users >>>>> can change the sizes of the video displays during the session. Changes >>>>> of the display size are communicated from the displaying browser to >>>>> the >>>>> one sending the stream so that the video codec parameters can be >>>>> changed >>>>> accordingly." >>>>> >>>> As per above - I would prefer the "Simple Video Communication Service" >>>> to be as simple as possible. Even resizing the window locally is more >>>> than "as simple as possible" - the Gtalk video client for my phone >>>> doesn't support that. >>>> >>>>> But my preference is not strong - I'm happy to reinsert the use case >>>>> if >>>>> people think so. >>>>> >>>>>> 4.2.4.2. Derived Requirements >>>>>> >>>>>> F22 ( It SHOULD be possible to modify video codec parameters >>>>>> during a >>>>>> session.) >>>>>> >>>>> F22 now reads "The browser SHOULD use encoding of streams suitable for >>>>> the current rendering (e.g. video display size) and SHOULD change >>>>> parameters if the rendering changes during the session" >>>>> >>>>>> - Change the text of F22 to be: >>>>>> >>>>>> It SHOULD be possible for one party to request a change in video >>>>>> codec parameters, such as size, >>>>>> during a session, and for the other party to react to this >>>>>> request. >>>>>> >>>>> I think "party" is very vague. What does it mean - the browser, the >>>>> user, the web app? >>>>> >>>> Since this is the IETF WG - the "party" is the browser, user and web >>>> app >>>> together; somehow the desire for a change has to be communicated across >>>> the network, and that's the requirement I think needs to be in the IETF >>>> requirements list. >>>> >>>> The corresponding API requirement (which I'm not sure how to formulate >>>> - >>>> all this may go on in the browser and need no explicit API) needs to go >>>> into the W3C requirements list. >>>> >>>> _______________________________________________ >>>> 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 > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From stefan.lk.hakansson@ericsson.com Wed Jul 13 06: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 3667D21F8539 for ; Wed, 13 Jul 2011 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.075, 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 gxVkRKE0KcYp for ; Wed, 13 Jul 2011 06:14: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 842A221F8419 for ; Wed, 13 Jul 2011 06:14:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-c7-4e1d9a14541d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.27.09774.41A9D1E4; Wed, 13 Jul 2011 15:13:57 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.110]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 13 Jul 2011 15:13:56 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Matthew Kaufman Date: Wed, 13 Jul 2011 15:11:02 +0200 Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-kaufman-rtp-compatible-data-00.txt Thread-Index: Acw/6+ykeJ+vCxRmQ0qCIxiteuT3xgBcmP/X Message-ID: References: <20110630004852.10947.88695.idtracker@ietfa.amsl.com> <910D1894-3B1D-49CA-BAEF-9F50FF2B4ADB@skype.net> <4E0DB92F.8010501@ericsson.com>, <7658C729-8578-42E3-9193-6884756D18A6@skype.net> In-Reply-To: <7658C729-8578-42E3-9193-6884756D18A6@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [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: Wed, 13 Jul 2011 13:14:08 -0000 >> >> * There is no support for rate/congestion control of the datagrams >> > >Correct. This is a tool for getting datagrams sent and received. Congestio= n control, reliability, etc. are all a high-layer problem than this. Could you elaborate a bit on how that is supposed to work? Would there be a= nother protocol layer on top? >> * There is no support for multiplexing different datagram flows (the nee= d for this can be argued though - could be done by the web app) >> > >I would argue that this is an application problem, or possibly the respons= ibility of a layer that goes above this. As indicated, I tend to agree to that this should be handled by the applica= tion. Stefan= From magnus.westerlund@ericsson.com Wed Jul 13 08: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 BCCF621F8610 for ; Wed, 13 Jul 2011 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 AotuBzmR3FmI for ; Wed, 13 Jul 2011 08:57:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9A51921F8554 for ; Wed, 13 Jul 2011 08:57:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-41-4e1dc07dd96c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.4B.09774.D70CD1E4; Wed, 13 Jul 2011 17:57:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 13 Jul 2011 17:57:49 +0200 Message-ID: <4E1DC07B.7000807@ericsson.com> Date: Wed, 13 Jul 2011 17:57:47 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; 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> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Consensus Call on 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, 13 Jul 2011 15:57:51 -0000 Hi, I have reviewed the input both the last 2 weeks and the discussion back in April. I see a strong support but with at least 2 people disagreeing to a basic p2p datagram functionality. The use cases are various and some just state that they see it as important functionality to provide to empower the web application. Based on this I declare a rough consensus on that we should provide a non-media data service that is unreliable datagram oriented directly between the peers. One of objections against this was lack of clear requirements for what the service. The straw men requirements I included has gotten some discussion. Mostly support for them, but it is clear to me that we need to further develop them. I would recommend the proponents for driving proposals towards meeting this functionality to further discuss the requirements taking the input so far into consideration. When it comes to reliable data transfer between peers there has been 4-5 that wanted the functionality, 2 additional that explicitly stated they where okay with it. No additional that has stated against it. My interpretation is that we are close to having a rough consensus for reliable data service, but we have so far seen no proponent willing to suggest a solution for this. I would also note that a solution is likely a functionality block that isn't dependent on more than the signaling/negotiation and the NAT traversal and thus can be added a later stage or be worked on with a completion date further into the future than other pieces already. So for reliable data I would recommend that someone takes on the role of proponent and provides a draft with their perceived requirements and a straw man proposal for how to solve these requirements so we have something more tangible to discuss. Cheers Magnus On 2011-06-27 09:36, 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 > Frgatan 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 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dzonatas@gmail.com Wed Jul 13 10:08:24 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 D868211E819B for ; Wed, 13 Jul 2011 10:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.778 X-Spam-Level: X-Spam-Status: No, score=-4.778 tagged_above=-999 required=5 tests=[AWL=-1.179, 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 x6lqAKmUHQRk for ; Wed, 13 Jul 2011 10:08:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8611E818B for ; Wed, 13 Jul 2011 10:08:23 -0700 (PDT) Received: by iwn39 with SMTP id 39so6893893iwn.31 for ; Wed, 13 Jul 2011 10:08:23 -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=bNUvWFQpHMW3rPx4Na+Cv7uS6T7yz/WB3q2aJxft6AM=; b=H+I+ItDzzyG+v19M7nfMqMUyTqAqp3bh11wkSIAjEPnz4g1YkEYOmRA10Ndh2Ac0DR Wj2ETXu7R3tEeVjkbn2oMYDSlQqqMQHgoXyLeVpqUNDQpbZf3gzorb/WgYj7eiqb9MU8 gChWgK7BghW3l0YJSF89EuA8/InPnqxGylgbY= Received: by 10.42.142.6 with SMTP id q6mr1268439icu.47.1310576903406; Wed, 13 Jul 2011 10:08:23 -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 hx9sm1936252icc.0.2011.07.13.10.08.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jul 2011 10:08:21 -0700 (PDT) Message-ID: <4E1DD0FF.5070506@gmail.com> Date: Wed, 13 Jul 2011 10:08:15 -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> <4E1DC07B.7000807@ericsson.com> In-Reply-To: <4E1DC07B.7000807@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Consensus Call on 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, 13 Jul 2011 17:08:25 -0000 Instead of "NAT traversal", can we reduce-reduce that term to "synopsis". I've deleted my justification for that several times. On 07/13/2011 08:57 AM, Magnus Westerlund wrote: > Hi, > > I have reviewed the input both the last 2 weeks and the discussion back > in April. > > I see a strong support but with at least 2 people disagreeing to a basic > p2p datagram functionality. The use cases are various and some just > state that they see it as important functionality to provide to empower > the web application. > > Based on this I declare a rough consensus on that we should provide a > non-media data service that is unreliable datagram oriented directly > between the peers. > > One of objections against this was lack of clear requirements for what > the service. The straw men requirements I included has gotten some > discussion. Mostly support for them, but it is clear to me that we need > to further develop them. I would recommend the proponents for driving > proposals towards meeting this functionality to further discuss the > requirements taking the input so far into consideration. > > When it comes to reliable data transfer between peers there has been 4-5 > that wanted the functionality, 2 additional that explicitly stated they > where okay with it. No additional that has stated against it. > > My interpretation is that we are close to having a rough consensus for > reliable data service, but we have so far seen no proponent willing to > suggest a solution for this. I would also note that a solution is likely > a functionality block that isn't dependent on more than the > signaling/negotiation and the NAT traversal and thus can be added a > later stage or be worked on with a completion date further into the > future than other pieces already. > > So for reliable data I would recommend that someone takes on the role of > proponent and provides a draft with their perceived requirements and a > straw man proposal for how to solve these requirements so we have > something more tangible to discuss. > > Cheers > > Magnus > > On 2011-06-27 09:36, 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 Wed Jul 13 11:28: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 867A022800F for ; Wed, 13 Jul 2011 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.722 X-Spam-Level: X-Spam-Status: No, score=-4.722 tagged_above=-999 required=5 tests=[AWL=-1.123, 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 re3McutBaN9B for ; Wed, 13 Jul 2011 11:28:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96CED22800D for ; Wed, 13 Jul 2011 11:28:48 -0700 (PDT) Received: by iwn39 with SMTP id 39so6959889iwn.31 for ; Wed, 13 Jul 2011 11:28:48 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=U9Zxc3lMf8XewnW5h4gBpz9ahN1fwUKEEEisWl+vFjM=; b=LjGn+wOlb/rUEs07/0QX6TNMdlIr5KIWIawdDkQiz0EtaCU/pjb9L+OTmZNIcNxRwk 2ysWEYbzX6o8eLJoCTedPRMnvvMsC/C9S1wOqMD57ECRklik4GhdDDpiJHFTxXeR+4TM /e4s85z5RegLq318xv3fpNP3QvTXRtZVbh5n4= Received: by 10.42.153.132 with SMTP id m4mr1424108icw.32.1310581727891; Wed, 13 Jul 2011 11:28:47 -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 hx9sm1991411icc.0.2011.07.13.11.28.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jul 2011 11:28:46 -0700 (PDT) Message-ID: <4E1DE3D8.2060206@gmail.com> Date: Wed, 13 Jul 2011 11:28:40 -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: Dzonatas Sol References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E1DD0FF.5070506@gmail.com> In-Reply-To: <4E1DD0FF.5070506@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus Call on 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, 13 Jul 2011 18:28:55 -0000 One more thing, the constraint on that reduce-reduce is the high path. P.S. "noise-reduction", we do not get upset over "soft" patents for noise reduction, please do... On 07/13/2011 10:08 AM, Dzonatas Sol wrote: > Instead of "NAT traversal", can we reduce-reduce that term to > "synopsis". I've deleted my justification for that several times. > > On 07/13/2011 08:57 AM, Magnus Westerlund wrote: >> Hi, >> >> I have reviewed the input both the last 2 weeks and the discussion back >> in April. >> >> I see a strong support but with at least 2 people disagreeing to a basic >> p2p datagram functionality. The use cases are various and some just >> state that they see it as important functionality to provide to empower >> the web application. >> >> Based on this I declare a rough consensus on that we should provide a >> non-media data service that is unreliable datagram oriented directly >> between the peers. >> >> One of objections against this was lack of clear requirements for what >> the service. The straw men requirements I included has gotten some >> discussion. Mostly support for them, but it is clear to me that we need >> to further develop them. I would recommend the proponents for driving >> proposals towards meeting this functionality to further discuss the >> requirements taking the input so far into consideration. >> >> When it comes to reliable data transfer between peers there has been 4-5 >> that wanted the functionality, 2 additional that explicitly stated they >> where okay with it. No additional that has stated against it. >> >> My interpretation is that we are close to having a rough consensus for >> reliable data service, but we have so far seen no proponent willing to >> suggest a solution for this. I would also note that a solution is likely >> a functionality block that isn't dependent on more than the >> signaling/negotiation and the NAT traversal and thus can be added a >> later stage or be worked on with a completion date further into the >> future than other pieces already. >> >> So for reliable data I would recommend that someone takes on the role of >> proponent and provides a draft with their perceived requirements and a >> straw man proposal for how to solve these requirements so we have >> something more tangible to discuss. >> >> Cheers >> >> Magnus >> >> On 2011-06-27 09:36, 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 Wed Jul 13 15:12: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 3909321F8B73 for ; Wed, 13 Jul 2011 15:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.671 X-Spam-Level: X-Spam-Status: No, score=-4.671 tagged_above=-999 required=5 tests=[AWL=-1.072, 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 FJLi4attB631 for ; Wed, 13 Jul 2011 15:12:14 -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 CDAA821F8B6B for ; Wed, 13 Jul 2011 15:12:13 -0700 (PDT) Received: by iye7 with SMTP id 7so7047537iye.31 for ; Wed, 13 Jul 2011 15:12: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=eTL0E1Hk2b7zU8erOpgE3XHTk7cclFR51fXLCcdTu2Q=; b=vnxvyX464/fCQmbBmhsNWeTWJ1LUBWeSOqJIoMlEUC9F6ZsTI3edrAXez9s/GYeJcs bloqMdhNQONCr5jSVBV330CVLXOgiYB/FtRbZlRcZELwLZVQAqiFVB8qc/1ffXrEMPiC tbNEhE8o/s3N7Du0KYPxGKC8rWtwPQGgyjxlw= Received: by 10.42.28.2 with SMTP id l2mr1635610icc.57.1310595132708; Wed, 13 Jul 2011 15:12:12 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id a5sm2205410icb.15.2011.07.13.15.12.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jul 2011 15:12:11 -0700 (PDT) Message-ID: <4E1E1835.5070602@gmail.com> Date: Wed, 13 Jul 2011 15:12:05 -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: Dzonatas Sol , "rtcweb@ietf.org" References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E1DD0FF.5070506@gmail.com> <4E1DE3D8.2060206@gmail.com> In-Reply-To: <4E1DE3D8.2060206@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Consensus Call on 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, 13 Jul 2011 22:12:18 -0000 Updated: medium path flow called either "petrifaction" or "cloud". I know there are better words, oh ya, "traits". Trinary machines... enjoy. On 07/13/2011 11:28 AM, Dzonatas Sol wrote: > One more thing, the constraint on that reduce-reduce is the high path. > > P.S. "noise-reduction", we do not get upset over "soft" patents for > noise reduction, please do... > > On 07/13/2011 10:08 AM, Dzonatas Sol wrote: >> Instead of "NAT traversal", can we reduce-reduce that term to >> "synopsis". I've deleted my justification for that several times. >> >> On 07/13/2011 08:57 AM, Magnus Westerlund wrote: >>> Hi, >>> >>> I have reviewed the input both the last 2 weeks and the discussion back >>> in April. >>> >>> I see a strong support but with at least 2 people disagreeing to a >>> basic >>> p2p datagram functionality. The use cases are various and some just >>> state that they see it as important functionality to provide to empower >>> the web application. >>> >>> Based on this I declare a rough consensus on that we should provide a >>> non-media data service that is unreliable datagram oriented directly >>> between the peers. >>> >>> One of objections against this was lack of clear requirements for what >>> the service. The straw men requirements I included has gotten some >>> discussion. Mostly support for them, but it is clear to me that we need >>> to further develop them. I would recommend the proponents for driving >>> proposals towards meeting this functionality to further discuss the >>> requirements taking the input so far into consideration. >>> >>> When it comes to reliable data transfer between peers there has been >>> 4-5 >>> that wanted the functionality, 2 additional that explicitly stated they >>> where okay with it. No additional that has stated against it. >>> >>> My interpretation is that we are close to having a rough consensus for >>> reliable data service, but we have so far seen no proponent willing to >>> suggest a solution for this. I would also note that a solution is >>> likely >>> a functionality block that isn't dependent on more than the >>> signaling/negotiation and the NAT traversal and thus can be added a >>> later stage or be worked on with a completion date further into the >>> future than other pieces already. >>> >>> So for reliable data I would recommend that someone takes on the >>> role of >>> proponent and provides a draft with their perceived requirements and a >>> straw man proposal for how to solve these requirements so we have >>> something more tangible to discuss. >>> >>> Cheers >>> >>> Magnus >>> >>> On 2011-06-27 09:36, 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 magnus.westerlund@ericsson.com Thu Jul 14 00:15: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 046BA21F88B2 for ; Thu, 14 Jul 2011 00:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 hYwkFKVxIwxg for ; Thu, 14 Jul 2011 00:15:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B678121F88A0 for ; Thu, 14 Jul 2011 00:15:28 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3b-4e1e978fc037 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 31.BB.20773.F879E1E4; Thu, 14 Jul 2011 09:15:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Jul 2011 09:15:27 +0200 Message-ID: <4E1E978D.8050505@ericsson.com> Date: Thu, 14 Jul 2011 09:15:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Dzonatas Sol References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E1DD0FF.5070506@gmail.com> In-Reply-To: <4E1DD0FF.5070506@gmail.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus Call on 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, 14 Jul 2011 07:15:30 -0000 On 2011-07-13 19:08, Dzonatas Sol wrote: > Instead of "NAT traversal", can we reduce-reduce that term to > "synopsis". I've deleted my justification for that several times. > Dzonatas, your comments doesn't make sense to me. We need to use terms that are as commonly well understood as possible. 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 gonzalo.camarillo@ericsson.com Thu Jul 14 01:16: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 04C1821F8B4E for ; Thu, 14 Jul 2011 01:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.629 X-Spam-Level: X-Spam-Status: No, score=-106.629 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 D2MnlEA662-G for ; Thu, 14 Jul 2011 01:16: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 74DE021F8B4B for ; Thu, 14 Jul 2011 01:16:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-c6-4e1ea5e38086 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9A.57.09774.3E5AE1E4; Thu, 14 Jul 2011 10:16:35 +0200 (CEST) Received: from [131.160.126.174] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Jul 2011 10:16:35 +0200 Message-ID: <4E1EA5E3.9060505@ericsson.com> Date: Thu, 14 Jul 2011 11:16:35 +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: "rtcweb@ietf.org" References: <4E118FBC.1000401@ericsson.com> In-Reply-To: <4E118FBC.1000401@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Fwd: W3C WebRTC working group meeting: Saturday, July 23 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: Thu, 14 Jul 2011 08:16:42 -0000 Hi, note that the deadline for registering to this meeting is tomorrow (see email below). Cheers, Gonzalo On 04/07/2011 1:02 PM, Gonzalo Camarillo wrote: > Folks, > > FYI. This meeting has now also been announced on the general IETF > announce list (see email below). > > Cheers, > > Gonzalo > > -------- Original Message -------- > Subject: W3C WebRTC working group meeting: Saturday, July 23 2011 > Date: Thu, 30 Jun 2011 20:32:29 +0200 > From: Alexa Morris > To: ietf-announce@ietf.org > > The W3C Web Real-Time Communications working group will meet on Saturday > 23 July 2011 afternoon, starting at 2PM, in Quebec City, Canada, > co-located with the IETF Meeting. > > The choice of the date and place is meant to favor synergies between the > W3C WebRTC and the IETF RTCWEB groups. IETF attendees, especially those > following the RTCWEB WG, are welcome to attend this W3C face-to-face > meeting as meeting guests. Attendees need to register before July 15th > using the following URL: > > http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/ > > Note that this is a W3C meeting and, thus, it will be held under W3C > rules. > > Regards, > Alexa > > ----------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From dzonatas@gmail.com Thu Jul 14 07:33: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 943FE21F85E6 for ; Thu, 14 Jul 2011 07:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.624 X-Spam-Level: X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=-1.025, 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 NpOLLOq81qRu for ; Thu, 14 Jul 2011 07:33:02 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3921F8519 for ; Thu, 14 Jul 2011 07:33:01 -0700 (PDT) Received: by iwn39 with SMTP id 39so297582iwn.31 for ; Thu, 14 Jul 2011 07:33: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5fGODzzRsY47R2rHAhSBNTd82DVUcwuS00MhD2FCXXc=; b=Caz0sfXrxD5i08NE3FJ+Bnoh2/JFwcVGLsxh+NUSXpvLW5l+Bp68I/aUMbjTgK4/3E UEEmHcVd3o/wmKQE6WxfjnHvsH4oE4QmLUwL6Nl6Z4a22CFDKXBi5ocXu9YlCvpNPO/q JGPHAZwRMXfrav9ZGK6pU6jdZtslW3l8edNhY= Received: by 10.42.137.129 with SMTP id y1mr2533662ict.397.1310653981246; Thu, 14 Jul 2011 07:33:01 -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 y3sm216235iba.21.2011.07.14.07.32.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jul 2011 07:32:59 -0700 (PDT) Message-ID: <4E1EFE16.30104@gmail.com> Date: Thu, 14 Jul 2011 07:32:54 -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: Magnus Westerlund References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E1DD0FF.5070506@gmail.com> <4E1E978D.8050505@ericsson.com> In-Reply-To: <4E1E978D.8050505@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus Call on 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, 14 Jul 2011 14:33:02 -0000 My bad for thinking out-loud about star-topology. On 07/14/2011 12:15 AM, Magnus Westerlund wrote: > On 2011-07-13 19:08, Dzonatas Sol wrote: > >> Instead of "NAT traversal", can we reduce-reduce that term to >> "synopsis". I've deleted my justification for that several times. >> >> > Dzonatas, your comments doesn't make sense to me. We need to use terms > that are as commonly well understood as possible. > > 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 > ---------------------------------------------------------------------- > > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From matthew.kaufman@skype.net Thu Jul 14 13:03: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 35B9811E80AE for ; Thu, 14 Jul 2011 13:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OZSj++hEvDE4 for ; Thu, 14 Jul 2011 13:03:54 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9FD11E8087 for ; Thu, 14 Jul 2011 13:03:54 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 022101B25 for ; Thu, 14 Jul 2011 22:03:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:subject:content-type: content-transfer-encoding; s=mx; bh=Dnr06dNS0AgQS8p7RJysn4aWLyo= ; b=m2ip4zrczOexLOd8yjqwt6FlXGzqvMsTSDlrU6ravGct9VRtkcejK8WLW4rp 0eGGbAVMS3HhUhmByAoftsrThwvcHS3HLZFSySPj7zk91Dn/fkP5Q1LLlpGBgb5v JLCgN4pN/UogSsNqHPrLWY+HD3iomIBAVtZWZBC+G5WA+58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:subject:content-type:content-transfer-encoding; q=dns; s=mx; b=f5ynD/dF3t6u5uC27SaWcXzGhF24CDFKePpet1SKGLPQv712 cCtBoVuOz9fwDR/ixGd+fKcXSYkiTDuKfFk4wbolL6jXNREnbmp0eSlqZ/WbX1P4 hK+QA0bwJxi6ypjx+AHGng6ZJtTrAH9WQMgp69CeMH1R2zricCNQbUWox9E= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 54B6A1700 for ; Thu, 14 Jul 2011 21:33:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 3A78C35081D0 for ; Thu, 14 Jul 2011 21:33:16 +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 zNIPpI0GfAiG for ; Thu, 14 Jul 2011 21:33:15 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 85E3E35081CE for ; Thu, 14 Jul 2011 21:33:15 +0200 (CEST) Message-ID: <4E1F4471.8030506@skype.net> Date: Thu, 14 Jul 2011 12:33:05 -0700 From: Matthew Kaufman 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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] public-webrtc@w3.org X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Jul 2011 20:03:55 -0000 Does anyone on this list have a contact for the admin of the w3 list? I have a posting that's more relevant for that list that appears to have gone into a black hole. Matthew Kaufman From fluffy@cisco.com Fri Jul 15 08:52: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 12BE121F853A for ; Fri, 15 Jul 2011 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.361 X-Spam-Level: X-Spam-Status: No, score=-104.361 tagged_above=-999 required=5 tests=[AWL=-1.762, 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 5qhfWxRnYFMa for ; Fri, 15 Jul 2011 08:52:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E347221F84F2 for ; Fri, 15 Jul 2011 08:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=6632; q=dns/txt; s=iport; t=1310745121; x=1311954721; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=S2G3RTYRnQ4JoigyX02tUcVrK+SneGpfnHb5NNyGzK8=; b=Ds7nVDP8Uvptp5qkaX8BhXWffpfBZnn9tDQx0rqi31eIwrFcbQ8jWlen ImI64489u5UhUsBCfWDblUJMQ5lB/Lb4M3BT3M/yFbABKLlC56MLXRmqL kca6ZTvpvg209fzKCjEVvtQ+o5Pt6vltnG6tGKNG1RRWdr8saI/D4zwwV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAINhIE6rRDoJ/2dsb2JhbABTp2d3iHqkLJ4rAoVZXwSHVIsSkHM X-IronPort-AV: E=Sophos;i="4.67,206,1309737600"; d="scan'208";a="3333799" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 15 Jul 2011 15:51:56 +0000 Received: from sjc-vpn5-875.cisco.com (sjc-vpn5-875.cisco.com [10.21.91.107]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6FFpsfB014972 for ; Fri, 15 Jul 2011 15:51:55 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <4E1DC07B.7000807@ericsson.com> Date: Fri, 15 Jul 2011 08:51:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Jul 2011 15:52:05 -0000 I'd like to push back on the reliable service. I've yet to hear a use = case for it that was real time. It's very hard to do a reliable real = time protocol and we have seen zero proposal for this. For non real time = data, just dump it in dropbox of whatever your equivalent is and don't = do it peer to peer. Unless someone has a real need, and wants to put = forward a proposal, I don't see a need to focus energy on this right = now. I'd rather work on the thing everyone agrees they do need which is = the unreliable transfer.=20 Cullen =20 On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: > Hi, >=20 > I have reviewed the input both the last 2 weeks and the discussion = back > in April. >=20 > I see a strong support but with at least 2 people disagreeing to a = basic > p2p datagram functionality. The use cases are various and some just > state that they see it as important functionality to provide to = empower > the web application. >=20 > Based on this I declare a rough consensus on that we should provide a > non-media data service that is unreliable datagram oriented directly > between the peers. >=20 > One of objections against this was lack of clear requirements for what > the service. The straw men requirements I included has gotten some > discussion. Mostly support for them, but it is clear to me that we = need > to further develop them. I would recommend the proponents for driving > proposals towards meeting this functionality to further discuss the > requirements taking the input so far into consideration. >=20 > When it comes to reliable data transfer between peers there has been = 4-5 > that wanted the functionality, 2 additional that explicitly stated = they > where okay with it. No additional that has stated against it. >=20 > My interpretation is that we are close to having a rough consensus for > reliable data service, but we have so far seen no proponent willing to > suggest a solution for this. I would also note that a solution is = likely > a functionality block that isn't dependent on more than the > signaling/negotiation and the NAT traversal and thus can be added a > later stage or be worked on with a completion date further into the > future than other pieces already. >=20 > So for reliable data I would recommend that someone takes on the role = of > proponent and provides a draft with their perceived requirements and a > straw man proposal for how to solve these requirements so we have > something more tangible to discuss. >=20 > Cheers >=20 > Magnus >=20 > On 2011-06-27 09:36, Magnus Westerlund wrote: >> 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=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 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From tim@phonefromhere.com Fri Jul 15 10:30: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 061CF21F8B97 for ; Fri, 15 Jul 2011 10:30:06 -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 RApes9EqLMZ6 for ; Fri, 15 Jul 2011 10:30:02 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 892F321F8B8D for ; Fri, 15 Jul 2011 10:29:58 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 43ACC37A902; Fri, 15 Jul 2011 18:39:47 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Fri, 15 Jul 2011 18:29:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Jul 2011 17:30:06 -0000 If we don't specify a reliable transport then all the page authors will = end adding a reliable layer in javascript, it will be as ugly as DTMF in = RTP ! Or worse it will be spray and pray. Most of the use-cases I can think of need sequenced and reliable = datagrams. If I'm playing a game I don't want it to drop or mis-order any one of the actions in the unholster, point, shoot = sequence :-) I don't think it is very hard to implement, we could take RFC 5456's = sequencing and retry mechanism for example. or indeed Plan9's IL . Tim. =20 On 15 Jul 2011, at 16:51, Cullen Jennings wrote: >=20 > I'd like to push back on the reliable service. I've yet to hear a use = case for it that was real time. It's very hard to do a reliable real = time protocol and we have seen zero proposal for this. For non real time = data, just dump it in dropbox of whatever your equivalent is and don't = do it peer to peer. Unless someone has a real need, and wants to put = forward a proposal, I don't see a need to focus energy on this right = now. I'd rather work on the thing everyone agrees they do need which is = the unreliable transfer.=20 >=20 > Cullen =20 >=20 > On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: >=20 >> Hi, >>=20 >> I have reviewed the input both the last 2 weeks and the discussion = back >> in April. >>=20 >> I see a strong support but with at least 2 people disagreeing to a = basic >> p2p datagram functionality. The use cases are various and some just >> state that they see it as important functionality to provide to = empower >> the web application. >>=20 >> Based on this I declare a rough consensus on that we should provide a >> non-media data service that is unreliable datagram oriented directly >> between the peers. >>=20 >> One of objections against this was lack of clear requirements for = what >> the service. The straw men requirements I included has gotten some >> discussion. Mostly support for them, but it is clear to me that we = need >> to further develop them. I would recommend the proponents for driving >> proposals towards meeting this functionality to further discuss the >> requirements taking the input so far into consideration. >>=20 >> When it comes to reliable data transfer between peers there has been = 4-5 >> that wanted the functionality, 2 additional that explicitly stated = they >> where okay with it. No additional that has stated against it. >>=20 >> My interpretation is that we are close to having a rough consensus = for >> reliable data service, but we have so far seen no proponent willing = to >> suggest a solution for this. I would also note that a solution is = likely >> a functionality block that isn't dependent on more than the >> signaling/negotiation and the NAT traversal and thus can be added a >> later stage or be worked on with a completion date further into the >> future than other pieces already. >>=20 >> So for reliable data I would recommend that someone takes on the role = of >> proponent and provides a draft with their perceived requirements and = a >> straw man proposal for how to solve these requirements so we have >> something more tangible to discuss. >>=20 >> Cheers >>=20 >> Magnus >>=20 >> On 2011-06-27 09:36, Magnus Westerlund wrote: >>> 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=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 >>=20 >>=20 >> --=20 >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From emcho@sip-communicator.org Fri Jul 15 11:16: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 BF59E21F8B18 for ; Fri, 15 Jul 2011 11:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 XLvuF1tC3PoV for ; Fri, 15 Jul 2011 11:15:56 -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 5ABFC21F8AE4 for ; Fri, 15 Jul 2011 11:15:55 -0700 (PDT) Received: by wyj26 with SMTP id 26so86448wyj.31 for ; Fri, 15 Jul 2011 11:15:46 -0700 (PDT) Received: by 10.227.174.79 with SMTP id s15mr3309483wbz.68.1310753746683; Fri, 15 Jul 2011 11:15:46 -0700 (PDT) Received: from [10.0.2.8] (host170-219-static.88-82-b.business.telecomitalia.it [82.88.219.170]) by mx.google.com with ESMTPS id fx12sm1260243wbb.25.2011.07.15.11.15.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 11:15:45 -0700 (PDT) References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <6941C2FB-9851-43A9-B619-69EA881B7620@jitsi.org> X-Mailer: iPad Mail (8J3) From: Emil Ivov Date: Fri, 15 Jul 2011 20:15:44 +0200 To: Cullen Jennings Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Jul 2011 18:16:00 -0000 On 15 juil. 2011, at 17:51, Cullen Jennings wrote: >=20 > I'd like to push back on the reliable service. I've yet to hear a use case= for it that was real time.=20 Adding to the DTMF and gaming mentioned by Tim, there's also: - remote desktop control - shared whiteboards I'd also like to mention again the file transfer case. Although it is not ex= actly real-time, it does require a reliable datagram transport for NAT trave= rsal, and it is part of most real-time applications. Cheers, Emil -- http://jitsi.org > It's very hard to do a reliable real time protocol and we have seen zero p= roposal for this. For non real time data, just dump it in dropbox of whateve= r your equivalent is and don't do it peer to peer. Unless someone has a real= need, and wants to put forward a proposal, I don't see a need to focus ener= gy on this right now. I'd rather work on the thing everyone agrees they do n= eed which is the unreliable transfer.=20 >=20 > Cullen =20 >=20 > On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: >=20 >> Hi, >>=20 >> I have reviewed the input both the last 2 weeks and the discussion back >> in April. >>=20 >> I see a strong support but with at least 2 people disagreeing to a basic >> p2p datagram functionality. The use cases are various and some just >> state that they see it as important functionality to provide to empower >> the web application. >>=20 >> Based on this I declare a rough consensus on that we should provide a >> non-media data service that is unreliable datagram oriented directly >> between the peers. >>=20 >> One of objections against this was lack of clear requirements for what >> the service. The straw men requirements I included has gotten some >> discussion. Mostly support for them, but it is clear to me that we need >> to further develop them. I would recommend the proponents for driving >> proposals towards meeting this functionality to further discuss the >> requirements taking the input so far into consideration. >>=20 >> When it comes to reliable data transfer between peers there has been 4-5 >> that wanted the functionality, 2 additional that explicitly stated they >> where okay with it. No additional that has stated against it. >>=20 >> My interpretation is that we are close to having a rough consensus for >> reliable data service, but we have so far seen no proponent willing to >> suggest a solution for this. I would also note that a solution is likely >> a functionality block that isn't dependent on more than the >> signaling/negotiation and the NAT traversal and thus can be added a >> later stage or be worked on with a completion date further into the >> future than other pieces already. >>=20 >> So for reliable data I would recommend that someone takes on the role of >> proponent and provides a draft with their perceived requirements and a >> straw man proposal for how to solve these requirements so we have >> something more tangible to discuss. >>=20 >> Cheers >>=20 >> Magnus >>=20 >> On 2011-06-27 09:36, Magnus Westerlund wrote: >>> 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 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >>=20 >> --=20 >>=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 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Sat Jul 16 10:26: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 8E79B21F872E for ; Sat, 16 Jul 2011 10:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV+9iWbAxlFP for ; Sat, 16 Jul 2011 10:26:47 -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 821B721F86FF for ; Sat, 16 Jul 2011 10:26:47 -0700 (PDT) Received: by pvh18 with SMTP id 18so2864591pvh.31 for ; Sat, 16 Jul 2011 10:26:47 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hq9UHQKdCOh2aRHM2rKwjx4njBEuL1qiKSC94AsqYs4=; b=ZwIH0OuQnru49Q00Dve+ytaPOps79IlGQIOu6ZLLw6NxZqnwc8cweEPysDWBSQvkRS hUUpqtUEJ6ceC/U2KJlmbMdt9m6ElrPPZLmu9rRaWKDZTSj7lIPn5LMUIMK095VI+HmB AHTGG/wWZfNc7eEl4rqW2DXgO0/BdK5VT5skE= Received: by 10.68.63.136 with SMTP id g8mr1447682pbs.401.1310837205148; Sat, 16 Jul 2011 10:26:45 -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 i9sm1336129pbk.52.2011.07.16.10.26.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 10:26:44 -0700 (PDT) Message-ID: <4E21C9D3.7070306@gmail.com> Date: Sat, 16 Jul 2011 10:26:43 -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: Cullen Jennings References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jul 2011 17:26:48 -0000 I'm sure I mentioned one case on another WG that oftens gets dropped. The simple idea is to deliver content ahead of time by subscription to an event. The content is then deemed reliably deployed at by the schedule event. Last minute subscriptions are turned over to unreliable. The subscription can be as simple as SMTP, so that simplicity alone is why people drop and not look at it seriously enough. If you have over 10,000 people for an event with massive amounts of pre-compiled content, then it makes sense to look at it more seriously. The complexity is only what people perceive as static content. I hate to be the nag about such, yet protein topologies and crystallization techniques already have vocab that describe such ahead-of-time content delivery. The vocab is not accessible to everybody, so this is often overlooked as something else. I don't see why we need to force pre-compiled content over real-time services, especially unreliable, and expect something reliable. People still do that, and it doesn't seem to be going away. ...as close as we can get to such use-case: start with the solution. =) On 07/15/2011 08:51 AM, Cullen Jennings wrote: > I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer. Unless someone has a real need, and wants to put forward a proposal, I don't see a need to focus energy on this right now. I'd rather work on the thing everyone agrees they do need which is the unreliable transfer. > > Cullen > > On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: > > >> Hi, >> >> I have reviewed the input both the last 2 weeks and the discussion back >> in April. >> >> I see a strong support but with at least 2 people disagreeing to a basic >> p2p datagram functionality. The use cases are various and some just >> state that they see it as important functionality to provide to empower >> the web application. >> >> Based on this I declare a rough consensus on that we should provide a >> non-media data service that is unreliable datagram oriented directly >> between the peers. >> >> One of objections against this was lack of clear requirements for what >> the service. The straw men requirements I included has gotten some >> discussion. Mostly support for them, but it is clear to me that we need >> to further develop them. I would recommend the proponents for driving >> proposals towards meeting this functionality to further discuss the >> requirements taking the input so far into consideration. >> >> When it comes to reliable data transfer between peers there has been 4-5 >> that wanted the functionality, 2 additional that explicitly stated they >> where okay with it. No additional that has stated against it. >> >> My interpretation is that we are close to having a rough consensus for >> reliable data service, but we have so far seen no proponent willing to >> suggest a solution for this. I would also note that a solution is likely >> a functionality block that isn't dependent on more than the >> signaling/negotiation and the NAT traversal and thus can be added a >> later stage or be worked on with a completion date further into the >> future than other pieces already. >> >> So for reliable data I would recommend that someone takes on the role of >> proponent and provides a draft with their perceived requirements and a >> straw man proposal for how to solve these requirements so we have >> something more tangible to discuss. >> >> Cheers >> >> Magnus >> >> On 2011-06-27 09:36, 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 >>> >>> >> >> -- >> >> 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 >> > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > 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 Sat Jul 16 10:41: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 53C2921F8422 for ; Sat, 16 Jul 2011 10:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeSN1L5-1Q3Y for ; Sat, 16 Jul 2011 10:41:02 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0E55121F8757 for ; Sat, 16 Jul 2011 10:41:02 -0700 (PDT) Received: by pzd13 with SMTP id 13so3040055pzd.39 for ; Sat, 16 Jul 2011 10:41: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xt24TrW9NsBYgMqAKs/NozlpVeaI4hHUN5JGq6M1V0o=; b=J6jx5NQvv/alTzQd4s3sXLmbhYAmL9Wjswqhxv5uTCvVu9pv6T6od1uiuyAMy/SpW8 S7QDvD71zcv0X8tPDeBOWsBeMFKHJRa1eHe8dEEbtvu1gADb69x5sf4+ATzNb1I5CAkX PcYd2a8HpiB/3V814B34qX3OJuJj1bAsRiyUQ= Received: by 10.68.62.36 with SMTP id v4mr6049793pbr.248.1310838061716; Sat, 16 Jul 2011 10:41:01 -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 b4sm1338410pba.43.2011.07.16.10.41.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 10:41:00 -0700 (PDT) Message-ID: <4E21CD2C.7080007@gmail.com> Date: Sat, 16 Jul 2011 10:41:00 -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: Dzonatas Sol References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E21C9D3.7070306@gmail.com> In-Reply-To: <4E21C9D3.7070306@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jul 2011 17:41:03 -0000 Another (independent) perspective is http://www.relayforlife.org on Second Life for current capability (and... accessibility). The common tether is the (already noted) Olympics. On 07/16/2011 10:26 AM, Dzonatas Sol wrote: > I'm sure I mentioned one case on another WG that oftens gets dropped. > The simple idea is to deliver content ahead of time by subscription to > an event. The content is then deemed reliably deployed at by the > schedule event. Last minute subscriptions are turned over to > unreliable. The subscription can be as simple as SMTP, so that > simplicity alone is why people drop and not look at it seriously enough. > > If you have over 10,000 people for an event with massive amounts of > pre-compiled content, then it makes sense to look at it more > seriously. The complexity is only what people perceive as static content. > > I hate to be the nag about such, yet protein topologies and > crystallization techniques already have vocab that describe such > ahead-of-time content delivery. The vocab is not accessible to > everybody, so this is often overlooked as something else. > > I don't see why we need to force pre-compiled content over real-time > services, especially unreliable, and expect something reliable. People > still do that, and it doesn't seem to be going away. > > ...as close as we can get to such use-case: start with the solution. =) > > On 07/15/2011 08:51 AM, Cullen Jennings wrote: >> I'd like to push back on the reliable service. I've yet to hear a use >> case for it that was real time. It's very hard to do a reliable real >> time protocol and we have seen zero proposal for this. For non real >> time data, just dump it in dropbox of whatever your equivalent is and >> don't do it peer to peer. Unless someone has a real need, and wants >> to put forward a proposal, I don't see a need to focus energy on this >> right now. I'd rather work on the thing everyone agrees they do need >> which is the unreliable transfer. >> >> Cullen >> >> On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: >> >>> Hi, >>> >>> I have reviewed the input both the last 2 weeks and the discussion back >>> in April. >>> >>> I see a strong support but with at least 2 people disagreeing to a >>> basic >>> p2p datagram functionality. The use cases are various and some just >>> state that they see it as important functionality to provide to empower >>> the web application. >>> >>> Based on this I declare a rough consensus on that we should provide a >>> non-media data service that is unreliable datagram oriented directly >>> between the peers. >>> >>> One of objections against this was lack of clear requirements for what >>> the service. The straw men requirements I included has gotten some >>> discussion. Mostly support for them, but it is clear to me that we need >>> to further develop them. I would recommend the proponents for driving >>> proposals towards meeting this functionality to further discuss the >>> requirements taking the input so far into consideration. >>> >>> When it comes to reliable data transfer between peers there has been >>> 4-5 >>> that wanted the functionality, 2 additional that explicitly stated they >>> where okay with it. No additional that has stated against it. >>> >>> My interpretation is that we are close to having a rough consensus for >>> reliable data service, but we have so far seen no proponent willing to >>> suggest a solution for this. I would also note that a solution is >>> likely >>> a functionality block that isn't dependent on more than the >>> signaling/negotiation and the NAT traversal and thus can be added a >>> later stage or be worked on with a completion date further into the >>> future than other pieces already. >>> >>> So for reliable data I would recommend that someone takes on the >>> role of >>> proponent and provides a draft with their perceived requirements and a >>> straw man proposal for how to solve these requirements so we have >>> something more tangible to discuss. >>> >>> Cheers >>> >>> Magnus >>> >>> On 2011-06-27 09:36, 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 >>>> >>> >>> -- >>> >>> 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 >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> _______________________________________________ >> 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 randell1@jesup.org Sat Jul 16 11:38: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 4EFCF21F8766 for ; Sat, 16 Jul 2011 11:38:17 -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 ORG4yx4F-JLI for ; Sat, 16 Jul 2011 11:38:16 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id CC3AE21F868A for ; Sat, 16 Jul 2011 11:38:16 -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 1Qi9km-0008CD-1k for rtcweb@ietf.org; Sat, 16 Jul 2011 13:38:16 -0500 Message-ID: <4E21DA68.7010508@jesup.org> Date: Sat, 16 Jul 2011 14:37:28 -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> <4E1DC07B.7000807@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jul 2011 18:38:17 -0000 On 7/15/2011 1:29 PM, Tim Panton wrote: > If we don't specify a reliable transport then all the page authors will end adding a reliable layer in javascript, it will be as ugly as DTMF in RTP ! > Or worse it will be spray and pray. > > Most of the use-cases I can think of need sequenced and reliable datagrams. If I'm playing a game I don't want it to > drop or mis-order any one of the actions in the unholster, point, shoot sequence :-) I must agree that if we don't provide a reliable transport in conjunction with the other streams, you'll get a hodgepodge of incompatible, semi-functional reliable transports layered on top of unreliable streams. Not that one can't do a good reliable transport on top of an unreliable layer, but people have varying abilities to get it right. Also, an integrated solution might have options for better performance than a user-layered solution would (for example, prioritizing certain packets from a reliable stream like restransmits or acks). As for the need - one of the first real-time apps on the internet was netrek. This predates the web by years (I was in a netrek league in 1991), in the days when a big international company would have a 64Kbps connection. The original TCP-based protocol broke down badly when exposed to congestion and the real net. The solution was to break the data streams into two: one unreliable one for most positional updates, and a reliable stream for game-state-critical data (like "you're dead"). Saying "if you want reliable data, use a proxy" is also silly IMHO. Perhaps some here from or formerly from Adobe can speak to the utility of reliable streams in RTFMP. In VoIP there's a consistent issue with the need to do some things (like DTMF) reliably when your primary streams are unreliable. Witness DTMF and the mess over RFC 2833 vs SIP INFO. > I don't think it is very hard to implement, we could take RFC 5456's sequencing and retry mechanism for example. > or indeed Plan9's IL . -- Randell Jesup randell-ietf@jesup.org From dzonatas@gmail.com Sat Jul 16 13:30: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 4EAD221F8890 for ; Sat, 16 Jul 2011 13:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.483 X-Spam-Level: X-Spam-Status: No, score=-4.483 tagged_above=-999 required=5 tests=[AWL=-0.884, 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 U0884rDn-fIE for ; Sat, 16 Jul 2011 13:30:10 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B621F888A for ; Sat, 16 Jul 2011 13:30:10 -0700 (PDT) Received: by pzd13 with SMTP id 13so3133309pzd.39 for ; Sat, 16 Jul 2011 13:30:10 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+S+5tCflJUzruIm+3TcgXRVfvdEITHyJr4vn3or/oqM=; b=jSlLzhUrbyJ0sXouakG6icwkPh7Wa+85OzcDa1LRrki2HuHyWikqWkn2q+vA2p7WXR uRnb+v6a0u/Supea5fMsTpDwiIGWK9YK+cB0IyhUvbqnjtQ1owre5bFuSI4azwblNsaB bi+25R4aOCYbraoxztxupXYl1OAQpFzJzC/hQ= Received: by 10.68.43.5 with SMTP id s5mr111774pbl.486.1310848210193; Sat, 16 Jul 2011 13:30:10 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id d3sm1415569pbh.85.2011.07.16.13.30.08 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 13:30:09 -0700 (PDT) Message-ID: <4E21F4D1.9010307@gmail.com> Date: Sat, 16 Jul 2011 13:30:09 -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: Randell Jesup References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E21DA68.7010508@jesup.org> In-Reply-To: <4E21DA68.7010508@jesup.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jul 2011 20:30:11 -0000 On 07/16/2011 11:37 AM, Randell Jesup wrote: > Not that one can't do a good > reliable transport on top of an unreliable layer, but people have > varying abilities > to get it right. If we assume nobody has the ability to "get it right" then; unreliable is the only solution. > In VoIP there's a consistent issue with the need to do some things > (like DTMF) reliably when > your primary streams are unreliable. Witness DTMF and the mess over > RFC 2833 vs SIP INFO. DTMF over JIT is one reason why some rather not allow others to get that right. Those who expect perfect flow rather just drop all other reliable use-cases. There is a famous case for this I avoid detail here. For some reason we can't just say order reliable before unreliable because it is a waste over the given sequence (where that is already known). Here, the difference engine is easier to talk about. If people really want anything like DTMF over JIT, then they may want to get into more formal methods of traffic-shapers, especially the schema to describe such for vocab. Shape is reliable, also known as envelopes. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Sat Jul 16 15:49: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 4CC0F21F89A7 for ; Sat, 16 Jul 2011 15:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.45 X-Spam-Level: X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[AWL=-0.851, 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 EIZErO4WnfCu for ; Sat, 16 Jul 2011 15:49:32 -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 9C5C421F89A3 for ; Sat, 16 Jul 2011 15:49:32 -0700 (PDT) Received: by pvh18 with SMTP id 18so3039889pvh.31 for ; Sat, 16 Jul 2011 15:49:32 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ovOP28WM73xtsx7UYRzRCqrBuZz6I/V/spuo1DAF538=; b=fr6qEBjAgZrVFfNmF7BnZPiNa68rqiE22e6iGZ8itwGfp+ARR0vmLCurgNxOJNDy6I TDdsobeXcouk2t6le0z57bvWZb2492LZKSreqlMKNB3lHDS1YKumHdTblE525V0q5tRo I5o8vu0a5NJjWR8s5EuXJ1Fqw1SvxXNkPbW4s= Received: by 10.68.58.10 with SMTP id m10mr3582544pbq.359.1310856571957; Sat, 16 Jul 2011 15:49:31 -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 m7sm1483344pbk.70.2011.07.16.15.49.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 15:49:31 -0700 (PDT) Message-ID: <4E22157B.80308@gmail.com> Date: Sat, 16 Jul 2011 15:49:31 -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: Randell Jesup References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E21DA68.7010508@jesup.org> In-Reply-To: <4E21DA68.7010508@jesup.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jul 2011 22:49:33 -0000 On 07/16/2011 11:37 AM, Randell Jesup wrote: > > As for the need - one of the first real-time apps on the internet was > netrek. This > predates the web by years (I was in a netrek league in 1991), in the > days when > a big international company would have a 64Kbps connection. This one is hard to beat in regards to "firsts": http://bfi.org/ I'm not gonna argue on this list when ether- existed in history; however, we can grow this now, and we moved on to polymers. If someone has a string of lazy monomers that suddenly produce one real-time event together, is that "on-the-wire"? Better question is how we can get this terminology kept in school where others want to exploit it as a chain reaction (it's not). Quantum mechanics is still seems anti-social to some. We have patience, and setup simulations. Some are afraid to approach this technology because they think they'll infringe on our business. Our business is more about the continual flow; rest assured, so some of these patents do not expire, like "instant" clean water. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From ted.ietf@gmail.com Sun Jul 17 15:54: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 4D25A21F8558 for ; Sun, 17 Jul 2011 15:54:54 -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 fHnLtoz8oP0j for ; Sun, 17 Jul 2011 15:54:53 -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 B5E8321F84E6 for ; Sun, 17 Jul 2011 15:54:53 -0700 (PDT) Received: by ywp31 with SMTP id 31so1251966ywp.31 for ; Sun, 17 Jul 2011 15:54:53 -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=D9I3kP4kMwkz4jpNvQV5u9sR1nn5KdowmPtGaNLL5J0=; b=SCHEA8GfINDKBv+qnsNLS3cc/evxhbuMR+OoQDMxzIngusfitN3mCusw5lAnqVzKQn ZRTmZkzWL2Yzh7kShI/B1iAsyVurTdag/uZuo5ZraUBUwejxQ9sDurFzfC2n4UJD9ewc myUoKJL/x/X8z4tjRRikg8WwsF9QE9v1+blwU= MIME-Version: 1.0 Received: by 10.236.177.67 with SMTP id c43mr6764214yhm.98.1310943293322; Sun, 17 Jul 2011 15:54:53 -0700 (PDT) Received: by 10.236.110.161 with HTTP; Sun, 17 Jul 2011 15:54:53 -0700 (PDT) In-Reply-To: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> Date: Sun, 17 Jul 2011 15:54:53 -0700 Message-ID: From: Ted Hardie To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf303f6a2851b42804a84bc5d4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jul 2011 22:54:54 -0000 --20cf303f6a2851b42804a84bc5d4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 15, 2011 at 8:51 AM, Cullen Jennings wrote: > > I'd like to push back on the reliable service. I've yet to hear a use case > for it that was real time. It's very hard to do a reliable real time > protocol and we have seen zero proposal for this. For non real time data, > just dump it in dropbox of whatever your equivalent is and don't do it peer > to peer. Can I see your dropbox incantation for remote camera movement? I am particularly interested in how you make it useful without a reliable, near real-time message that says "go check dropbox for $foo".... To put this another way, a reliable protocol associated with a real time stream has some pretty obvious uses (gaming has also already been mentioned). Whether it is truly "real time" or not is potentially subject to debate, but the results of the semantic nit-picking won't tell us much. The reliable protocol is a useful part of the real time system, even if its retransmission and congestion control methods make it less "real time" than rtp. Just my two cents, also as an individual contributor, Ted --20cf303f6a2851b42804a84bc5d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2011 at 8:51 AM, Cullen Jennings <fluffy@cisco.com> wrote:
<= div class=3D"gmail_quote">

I'd like to push back on the reliable service. I've yet to hear a u= se case for it that was real time. It's very hard to do a reliable real= time protocol and we have seen zero proposal for this. For non real time d= ata, just dump it in dropbox of whatever your equivalent is and don't d= o it peer to peer.

Can I see your dropbox incantation for remote camera movement?=A0 = I am particularly interested in how you make it useful without a reliable, = near real-time message that says "go check dropbox for $foo"....<= br>
To put this another way, a reliable protocol associated with a real tim= e stream has some pretty obvious uses (gaming has also already been mention= ed).=A0 Whether it is truly "real time" or not is potentially sub= ject to debate, but the results of the semantic nit-picking won't tell = us much.=A0 The reliable protocol is a useful part of the real time system,= even if its retransmission and congestion control methods make it less &qu= ot;real time" than rtp.

Just my two cents, also as an individual contributor,

Ted
=A0
--20cf303f6a2851b42804a84bc5d4-- From sergel@google.com Mon Jul 18 00:16: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 38A3621F87BD for ; Mon, 18 Jul 2011 00:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 r8CTDNImp3Qi for ; Mon, 18 Jul 2011 00:16:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7A79A21F8552 for ; Mon, 18 Jul 2011 00:16:43 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p6I7GgGj011612 for ; Mon, 18 Jul 2011 00:16:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310973402; bh=PUpiODvSHTg+KePULApLdI0p8HU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rGnYIYtV69GXKJkuAW2Fcdfs0Nmelo5yHqrEd4j3z4RC5H9ALKi0oNbRKICP0LkQH fDe2R/1zfsc7ZxslPq4Uw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=CeWVxTXccsHOfrq/yNqPuci+WorrC9TG+xURWNhKHkcGU42YeVMR/OUM2Z4dQIoRn d8KzVGZnQ3n9fGYFt69xA== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by hpaq6.eem.corp.google.com with ESMTP id p6I7GI4t013134 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Jul 2011 00:16:40 -0700 Received: by yib12 with SMTP id 12so1400538yib.2 for ; Mon, 18 Jul 2011 00:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EUzd3Feub7NEqWGIcDy37elkfP+EYmV3/UVJe/C1mIo=; b=BPwM86U2KjoyWdZTIvYi8VpzFebwCf6GMeHO2G5TH6ARlUgmfRzVvjaJjjs2zwNQSs GBAUT8W8wZLbPUsQaytg== Received: by 10.150.131.18 with SMTP id e18mr5466733ybd.150.1310973400151; Mon, 18 Jul 2011 00:16:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.201.18 with HTTP; Mon, 18 Jul 2011 00:16:10 -0700 (PDT) In-Reply-To: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> From: Serge Lachapelle Date: Mon, 18 Jul 2011 09:16:10 +0200 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=000e0cd484bcd3775d04a852c796 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 07:16:48 -0000 --000e0cd484bcd3775d04a852c796 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cullen, I agree with your push back. Focus is very important. Audio and video already present a huge challenge. (signalling, network, web developer friendly API, security, browser integration...) Also, I think that there is a real risk in introducing "duplicate" functionality in the browser as it may confuse web developers. There is a lot going on in HTML5... In my mind, this is "version 2.0" stuff. /Serge On Fri, Jul 15, 2011 at 17:51, Cullen Jennings wrote: > > I'd like to push back on the reliable service. I've yet to hear a use cas= e > for it that was real time. It's very hard to do a reliable real time > protocol and we have seen zero proposal for this. For non real time data, > just dump it in dropbox of whatever your equivalent is and don't do it pe= er > to peer. Unless someone has a real need, and wants to put forward a > proposal, I don't see a need to focus energy on this right now. I'd rathe= r > work on the thing everyone agrees they do need which is the unreliable > transfer. > > Cullen > > On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: > > > Hi, > > > > I have reviewed the input both the last 2 weeks and the discussion back > > in April. > > > > I see a strong support but with at least 2 people disagreeing to a basi= c > > p2p datagram functionality. The use cases are various and some just > > state that they see it as important functionality to provide to empower > > the web application. > > > > Based on this I declare a rough consensus on that we should provide a > > non-media data service that is unreliable datagram oriented directly > > between the peers. > > > > One of objections against this was lack of clear requirements for what > > the service. The straw men requirements I included has gotten some > > discussion. Mostly support for them, but it is clear to me that we need > > to further develop them. I would recommend the proponents for driving > > proposals towards meeting this functionality to further discuss the > > requirements taking the input so far into consideration. > > > > When it comes to reliable data transfer between peers there has been 4-= 5 > > that wanted the functionality, 2 additional that explicitly stated they > > where okay with it. No additional that has stated against it. > > > > My interpretation is that we are close to having a rough consensus for > > reliable data service, but we have so far seen no proponent willing to > > suggest a solution for this. I would also note that a solution is likel= y > > a functionality block that isn't dependent on more than the > > signaling/negotiation and the NAT traversal and thus can be added a > > later stage or be worked on with a completion date further into the > > future than other pieces already. > > > > So for reliable data I would recommend that someone takes on the role o= f > > proponent and provides a draft with their perceived requirements and a > > straw man proposal for how to solve these requirements so we have > > something more tangible to discuss. > > > > Cheers > > > > Magnus > > > > On 2011-06-27 09:36, 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 abou= t > >> 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 wil= l > >> build JS libraries for this on top of a unreliable datagram service. I= f > >> 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 requirement= s > >> 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=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 > >> > > > > > > -- > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880 Apparently, this footer is required in Europe. Apologies. This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else,please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks. --000e0cd484bcd3775d04a852c796 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cullen,

I agree with your push back.

Focus is very important. Audio and video already present a huge ch= allenge. (signalling, network, web developer friendly API, security, browse= r integration...)

Also, I think that there is a real risk in introducing = "duplicate" functionality in the browser as it may confuse web de= velopers. There is a lot going on in HTML5...

In my mind, this is "version 2.0" stuff.

/Serge


On Fri, Jul= 15, 2011 at 17:51, Cullen Jennings <fluffy@cisco.com> wrote:

I'd like to push back on the reliable service. I've yet to hear a u= se case for it that was real time. It's very hard to do a reliable real= time protocol and we have seen zero proposal for this. For non real time d= ata, just dump it in dropbox of whatever your equivalent is and don't d= o it peer to peer. Unless someone has a real need, and wants to put forward= a proposal, I don't see a need to focus energy on this right now. I= 9;d rather work on the thing everyone agrees they do need which is the unre= liable transfer.

Cullen <in my individaul contribut role>

On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote:

> Hi,
>
> I have reviewed the input both the last 2 weeks and the discussion bac= k
> in April.
>
> I see a strong support but with at least 2 people disagreeing to a bas= ic
> p2p datagram functionality. The use cases are various and some just > state that they see it as important functionality to provide to empowe= r
> the web application.
>
> Based on this I declare a rough consensus on that we should provide a<= br> > non-media data service that is unreliable datagram oriented directly > between the peers.
>
> One of objections against this was lack of clear requirements for what=
> the service. The straw men requirements I included has gotten some
> discussion. Mostly support for them, but it is clear to me that we nee= d
> to further develop them. I would recommend the proponents for driving<= br> > proposals towards meeting this functionality to further discuss the > requirements taking the input so far into consideration.
>
> When it comes to reliable data transfer between peers there has been 4= -5
> that wanted the functionality, 2 additional that explicitly stated the= y
> where okay with it. No additional that has stated against it.
>
> My interpretation is that we are close to having a rough consensus for=
> reliable data service, but we have so far seen no proponent willing to=
> suggest a solution for this. I would also note that a solution is like= ly
> a functionality block that isn't dependent on more than the
> signaling/negotiation and the NAT traversal and thus can be added a > later stage or be worked on with a completion date further into the > future than other pieces already.
>
> So for reliable data I would recommend that someone takes on the role = of
> proponent and provides a draft with their perceived requirements and a=
> straw man proposal for how to solve these requirements so we have
> something more tangible to discuss.
>
> Cheers
>
> Magnus
>
> On 2011-06-27 09:36, Magnus Westerlund wrote:
>> WG,
>>
>> At the interim it was planned to have a bit discussion on the data= gram
>> service for RTCWEB. The first question to try to resolve if there<= br> >> 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 th= e
>> 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 t= o 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 t= he
>> 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<= br> >> directly between peers? Please provide your view and any additiona= l
>> statements of motivation that you desire to provide.
>>
>> Secondly, there is a question if there needs to have something tha= t
>> provides reliable message (of arbitrary size) or byte stream orien= ted
>> data transport between the peers. I personally foresee that people= will
>> build JS libraries for this on top of a unreliable datagram servic= e. If
>> you desire reliable data service as part of the standardized solut= ion
>> please provide motivation and use case and requirements.
>>
>> I also want to take a stab on what I personally see as the require= ments
>> that exist on unreliable datagram service in the context of RTCWEB= .
>>
>> - Unreliable data transmission
>> - Datagram oriented
>> =A0 * Size limited by MTU
>> =A0 =A0 - Path MTU discovery needed
>> =A0 * Fragmentation by the application
>> - Low latency, i.e. Peer to Peer preferable
>> - Congestion Controlled, to be
>> =A0 * Network friendly
>> =A0 * Not become a Denial of Service tool
>> - Security
>> =A0* Confidentiality
>> =A0* Integrity Protected
>> =A0* Source Authenticated (at least bound to the signalling peer)<= br> >> =A0* Ensure consent to receive data
>>
>> Please debate the above. This is an attempt to ensure that we can<= br> >> establish WG consensus on both data service and any requirements.<= br> >>
>> cheers
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ----
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ------------------------------------------------------------------= ----
>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ------------------------------------------------------------------= ----
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html


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

Google Swede= n AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880=A0
Apparently, this footer is required in Europe. Apologi= es. This email may be confidential or privileged. =A0If you received this c= ommunication by mistake, please don't forward it to anyone else,please = erase all copies and attachments, and please let me know that it went to th= e wrong person. =A0Thanks.=A0
--000e0cd484bcd3775d04a852c796-- From silviapfeiffer1@gmail.com Mon Jul 18 01:17: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 E52DA21F8B6A for ; Mon, 18 Jul 2011 01:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoGZ1BVsaFzC for ; Mon, 18 Jul 2011 01:17:14 -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 7C29421F8B67 for ; Mon, 18 Jul 2011 01:17:13 -0700 (PDT) Received: by wwe5 with SMTP id 5so1973689wwe.13 for ; Mon, 18 Jul 2011 01:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=fTS76UXZ7EtPUtoyaxZuLYPpydulGerPYh52DNVtV5E=; b=Vo6efzBh7L1UG7VvFsPU5uCEf3vbKKJhybfB+RSakGX17XTxlQKNzlQ70F21hFh20V diJMSKT4wcfkQcXzjb7r53Rpw6Ybnhkt/7f5lZrAmk5O2yXe1V2ssWCBFex1thC2yKHj ZCzH3PHI7OGNlfnWBVrncq0k/XbO43XEuEbLk= Received: by 10.216.220.219 with SMTP id o69mr2558161wep.65.1310977032262; Mon, 18 Jul 2011 01:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.49.19 with HTTP; Mon, 18 Jul 2011 01:16:52 -0700 (PDT) In-Reply-To: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> From: Silvia Pfeiffer Date: Mon, 18 Jul 2011 18:16:52 +1000 Message-ID: To: Serge Lachapelle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 08:17:15 -0000 FWIW I agree that we should focus on audio and video communication and not introduce extra complexity by trying to solve real-time data communication at the same time. If it falls out as a side effect that what we are developing satisfies other use cases beyond audio and video, too, then that's fine. But we should not develop for it. In my experience, real-time data typically has different requirements than audio and video, such as a much smaller data size, such as a much higher requirement on reliability of data delivery (at least video delivery can be slightly lossy without issues), such as a much smaller requirement on isosynchronous data delivery, or a lesser requirement on low jitter. There are already other means of delivering data between browsers such as Web sockets and XMPP, so let's not confuse the landscape more by trying to be all things to all people. Regards, Silvia. On Mon, Jul 18, 2011 at 5:16 PM, Serge Lachapelle wrote= : > Hi Cullen, > I agree with your push back. > Focus is very important. Audio and video already present a huge challenge= . > (signalling, network, web developer friendly API, security, browser > integration...) > Also, I think that there is a real risk in introducing "duplicate" > functionality in the browser as it may confuse web developers. There is a > lot going on in HTML5... > In my mind, this is "version 2.0" stuff. > /Serge > > On Fri, Jul 15, 2011 at 17:51, Cullen Jennings wrote: >> >> I'd like to push back on the reliable service. I've yet to hear a use ca= se >> for it that was real time. It's very hard to do a reliable real time >> protocol and we have seen zero proposal for this. For non real time data= , >> just dump it in dropbox of whatever your equivalent is and don't do it p= eer >> to peer. Unless someone has a real need, and wants to put forward a >> proposal, I don't see a need to focus energy on this right now. I'd rath= er >> work on the thing everyone agrees they do need which is the unreliable >> transfer. >> >> Cullen >> >> On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: >> >> > Hi, >> > >> > I have reviewed the input both the last 2 weeks and the discussion bac= k >> > in April. >> > >> > I see a strong support but with at least 2 people disagreeing to a bas= ic >> > p2p datagram functionality. The use cases are various and some just >> > state that they see it as important functionality to provide to empowe= r >> > the web application. >> > >> > Based on this I declare a rough consensus on that we should provide a >> > non-media data service that is unreliable datagram oriented directly >> > between the peers. >> > >> > One of objections against this was lack of clear requirements for what >> > the service. The straw men requirements I included has gotten some >> > discussion. Mostly support for them, but it is clear to me that we nee= d >> > to further develop them. I would recommend the proponents for driving >> > proposals towards meeting this functionality to further discuss the >> > requirements taking the input so far into consideration. >> > >> > When it comes to reliable data transfer between peers there has been 4= -5 >> > that wanted the functionality, 2 additional that explicitly stated the= y >> > where okay with it. No additional that has stated against it. >> > >> > My interpretation is that we are close to having a rough consensus for >> > reliable data service, but we have so far seen no proponent willing to >> > suggest a solution for this. I would also note that a solution is like= ly >> > a functionality block that isn't dependent on more than the >> > signaling/negotiation and the NAT traversal and thus can be added a >> > later stage or be worked on with a completion date further into the >> > future than other pieces already. >> > >> > So for reliable data I would recommend that someone takes on the role = of >> > proponent and provides a draft with their perceived requirements and a >> > straw man proposal for how to solve these requirements so we have >> > something more tangible to discuss. >> > >> > Cheers >> > >> > Magnus >> > >> > On 2011-06-27 09:36, Magnus Westerlund wrote: >> >> 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 >> >> =A0 * Size limited by MTU >> >> =A0 =A0 - Path MTU discovery needed >> >> =A0 * Fragmentation by the application >> >> - Low latency, i.e. Peer to Peer preferable >> >> - Congestion Controlled, to be >> >> =A0 * Network friendly >> >> =A0 * Not become a Denial of Service tool >> >> - Security >> >> =A0* Confidentiality >> >> =A0* Integrity Protected >> >> =A0* Source Authenticated (at least bound to the signalling peer) >> >> =A0* 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 =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 094907= 9 >> >> 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 =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 >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-688= 0 > Apparently, this footer is required in Europe. Apologies. This email may = be > confidential or privileged. =A0If you received this communication by mist= ake, > please don't forward it to anyone else,please erase all copies and > attachments, and please let me know that it went to the wrong person. > =A0Thanks. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From tim@phonefromhere.com Mon Jul 18 02:28: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 4C7C721F87BC for ; Mon, 18 Jul 2011 02:28: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 W0-LhgHFk2yv for ; Mon, 18 Jul 2011 02:28:47 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6DD21F8B9A for ; Mon, 18 Jul 2011 02:28:47 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 516F837A902; Mon, 18 Jul 2011 10:38:35 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Mon, 18 Jul 2011 10:28:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <930E44D5-D72A-4F60-B28B-9DD8F3B49BAC@phonefromhere.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> To: Silvia Pfeiffer X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 09:28:51 -0000 I understand the pushback on supporting reliable datagrams from Cullen, = Silvia, Serge and others. I'm pushing for it simply because I've had it in our browser rt-audio = component, and used it extensively. Without the ability to transport reliable datagrams in 'near realtime' = the projects=20 we have done would have been far less compelling for the user. The = Datagrams are often the=20 key to providing a special user experience, beyond conventional = telephony. If we don't provide this, we risk producing the tools for a round of browser based deskphone = emulators. We can do better. As an example, the demo I show in this blog would have been much harder = and less responsive without realtime data coming back up the RFC 5456 channel : = https://babyis60.wordpress.com/2009/10/24/my-astricon-googlewave-ibook-sky= pe-demo/ So I guess I am asking: Are we aiming for browser based deskphone = emulators or a new sort of rich media experience for browser users?=20 I know what I want. Tim. From magnus.westerlund@ericsson.com Mon Jul 18 06:56: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 BCEAA21F86D1 for ; Mon, 18 Jul 2011 06:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 mp74u1jxNsHB for ; Mon, 18 Jul 2011 06:56:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 84DFA21F855E for ; Mon, 18 Jul 2011 06:56:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-2a-4e243b790207 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E9.E0.20773.97B342E4; Mon, 18 Jul 2011 15:56:09 +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; Mon, 18 Jul 2011 15:56:09 +0200 Message-ID: <4E243B77.1000900@ericsson.com> Date: Mon, 18 Jul 2011 15:56:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tim Panton References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 13:56:11 -0000 On 2011-07-15 19:29, Tim Panton wrote: > I don't think it is very hard to implement, we could take RFC 5456's > sequencing and retry mechanism for example. or indeed Plan9's IL . I would warn about thinking this is easy. It is easy to get something that works on sunny days, it is hard to build something that is secure, efficient, robust and fair. I would like to point out that a reliable protocol do need a number of functions. If those are achieve from a lower layer or need to be implemented in this protocol is a choice. However, functionalities such as: - Congestion Control - Flow Control - Retransmission - RTT estimation - Buffer handling - Parameter and functionality negotiation Are likely all need for a safe and stable and future safe protocol. There are good reasons for choosing something there is experience in that it works. For example I took a quick look at RFC5456 which appears to not have congestion control. I think it is partly relying on that the transported flow will adopt them self if trunking, or if not, that they become useless and the call terminates because of that. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tim@phonefromhere.com Mon Jul 18 07:20: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 09B8621F8BB1 for ; Mon, 18 Jul 2011 07:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=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 Ow+RVDcjN6TM for ; Mon, 18 Jul 2011 07:20:00 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8323A21F8BB9 for ; Mon, 18 Jul 2011 07:20:00 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id D0AEB37A902; Mon, 18 Jul 2011 15:29:44 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4E243B77.1000900@ericsson.com> Date: Mon, 18 Jul 2011 15:19:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <271CD938-00F7-423D-BA6E-6407811DC80E@phonefromhere.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E243B77.1000900@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 14:20:05 -0000 On 18 Jul 2011, at 14:56, Magnus Westerlund wrote: > On 2011-07-15 19:29, Tim Panton wrote: >> I don't think it is very hard to implement, we could take RFC 5456's >> sequencing and retry mechanism for example. or indeed Plan9's IL . >=20 > I would warn about thinking this is easy. It is easy to get something > that works on sunny days, it is hard to build something that is = secure, > efficient, robust and fair. >=20 Agreed, getting all 4 in any protocol is hard, indeed I don't think I've = seen it=20 done yet. > I would like to point out that a reliable protocol do need a number of > functions. If those are achieve from a lower layer or need to be > implemented in this protocol is a choice. However, functionalities = such as: >=20 > - Congestion Control > - Flow Control > - Retransmission > - RTT estimation > - Buffer handling > - Parameter and functionality negotiation Agreed, but only Retransmission is specific to reliable datagrams (as = opposed to unreliable ones).=20 >=20 > Are likely all need for a safe and stable and future safe protocol. >=20 > There are good reasons for choosing something there is experience in > that it works. >=20 > For example I took a quick look at RFC5456 which appears to not have > congestion control. I think it is partly relying on that the = transported > flow will adopt them self if trunking, or if not, that they become > useless and the call terminates because of that. RFC5456 has 2 sorts of packet - miniframes, which typically form the bulk of the traffic are handled = unreliably.=20 - fullframes which are mostly used for signalling but some of which = are reliable datagrams (e.g. the TEXT frame type). I was saying we could (in theory) ignore the miniframes and adopt the = fullframe sequence,ack,retry mechanisms for the reliable datagram transport. The core protocol has been 'repurposed' in this way before : = http://www.dundi.com/dundi.txt so it is definitely possible. I take your point about the lack of congestion control, but the ACK = mechanism could be used to detect incipient congestion. >=20 > cheers >=20 > Magnus Westerlund >=20 >=20 Tim.= From randell1@jesup.org Mon Jul 18 07:35: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 CA0B521F8C6C for ; Mon, 18 Jul 2011 07:35:28 -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 FABFgByDpsFp for ; Mon, 18 Jul 2011 07:35:28 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 47AD121F8C6B for ; Mon, 18 Jul 2011 07:35:28 -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 1Qiout-0008Lt-AB for rtcweb@ietf.org; Mon, 18 Jul 2011 09:35:27 -0500 Message-ID: <4E24447B.5010208@jesup.org> Date: Mon, 18 Jul 2011 10:34:35 -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> <4E1DC07B.7000807@ericsson.com> <4E243B77.1000900@ericsson.com> In-Reply-To: <4E243B77.1000900@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] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 14:35:28 -0000 On 7/18/2011 9:56 AM, Magnus Westerlund wrote: > On 2011-07-15 19:29, Tim Panton wrote: >> I don't think it is very hard to implement, we could take RFC 5456's >> sequencing and retry mechanism for example. or indeed Plan9's IL . > I would warn about thinking this is easy. It is easy to get something > that works on sunny days, it is hard to build something that is secure, > efficient, robust and fair. Agreed, absolutely - which is why I don't want 100 bad designs (let alone implementations) in Javascript. > I would like to point out that a reliable protocol do need a number of > functions. If those are achieve from a lower layer or need to be > implemented in this protocol is a choice. However, functionalities such as: > > - Congestion Control > - Flow Control > - Retransmission > - RTT estimation > - Buffer handling > - Parameter and functionality negotiation > > Are likely all need for a safe and stable and future safe protocol. > > There are good reasons for choosing something there is experience in > that it works. Agreed also. There are a few options, one of this is: 1) Encapsulated TCP-over-UDP, where the UDP channel is set up by the same mechanisms we use to set up the RTP channels, such as http://code.google.com/p/udptunnel/ This is a big advantage in that normally devices behind NATs can't easily set up a direct TCP connection, and we can leverage the ability to set up p2p UDP channels to get it. The UDP channel could participate in the proposed shared bandwidth handling/ congestion control, which is an advantage over a separate TCP channel. The downside is that TCP's AIMD may cause interactions with the underlying bandwidth handling, so it may need to be excluded - some analysis is needed, once we know what we're doing on congestion control for the UDP channels. TCP's time characteristics are very well understood, though not optimal. The MTU would be slightly reduced - shouldn't be a problem. It's not a datagram service, which is a minor downside, which offers the second option: 2) SCTP-over-UDP. This is datagram-oriented and provides reliable delivery. It supports ECN and congestion control. One nice thing is that SCTP allows for unreliable delivery but with sequencing, or reliable delivery without in-sequence delivery, dependent on the application needs. This can help the application optimize the realtime aspects of the reliable channel. -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Mon Jul 18 09:59: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 D409021F8BB5 for ; Mon, 18 Jul 2011 09:59:50 -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=[AWL=-0.000, 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 bEJFYORw1m19 for ; Mon, 18 Jul 2011 09:59:50 -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 CAAC721F8B3A for ; Mon, 18 Jul 2011 09:59:49 -0700 (PDT) Received: by yxp4 with SMTP id 4so1681438yxp.31 for ; Mon, 18 Jul 2011 09:59:49 -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=xBaO1cbtT5iZnxSz2CIXuPA18eZROnNSe80m3kW2oXk=; b=GphVzRCYwtLFW7yT26L3pfi4ZRJJY051kcwe515QnH4dxz6AFPipDIKmfrHt+lC23K YaNyeFUqfPAYmhxdI/x2ur2CdX1BtDbpBqLTj5ANLSXZVrkM3CE0JwCNElQSBWmeyRwx R7LikJiFTla4haRhp9BwVBim8GyiLBuJfXhAY= MIME-Version: 1.0 Received: by 10.236.181.98 with SMTP id k62mr2673547yhm.346.1311008136802; Mon, 18 Jul 2011 09:55:36 -0700 (PDT) Received: by 10.236.105.133 with HTTP; Mon, 18 Jul 2011 09:55:36 -0700 (PDT) In-Reply-To: <4E243B77.1000900@ericsson.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E243B77.1000900@ericsson.com> Date: Mon, 18 Jul 2011 09:55:36 -0700 Message-ID: From: Ted Hardie To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf305b10764ab0ee04a85ade61 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 16:59:51 -0000 --20cf305b10764ab0ee04a85ade61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Forgive the top-posting, but I want to make a meta-comment. If we were planning on building something from scratch, I would strongly agree that it would be quite tough going, especially given our timelines. But this working group is not allowed to re-use existing work, it is strongly encouraged to do so. Picking a protocol to implement which has the characteristics below is a lot less difficult than re-starting the exercise from scratch. Providing XMPP, DTLS, or SCTP between the endpoints certainly has challenges, but it would *not* involve starting from scratch. regards, Ted On Mon, Jul 18, 2011 at 6:56 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2011-07-15 19:29, Tim Panton wrote: > > I don't think it is very hard to implement, we could take RFC 5456's > > sequencing and retry mechanism for example. or indeed Plan9's IL . > > I would warn about thinking this is easy. It is easy to get something > that works on sunny days, it is hard to build something that is secure, > efficient, robust and fair. > > I would like to point out that a reliable protocol do need a number of > functions. If those are achieve from a lower layer or need to be > implemented in this protocol is a choice. However, functionalities such a= s: > > - Congestion Control > - Flow Control > - Retransmission > - RTT estimation > - Buffer handling > - Parameter and functionality negotiation > > Are likely all need for a safe and stable and future safe protocol. > > There are good reasons for choosing something there is experience in > that it works. > > For example I took a quick look at RFC5456 which appears to not have > congestion control. I think it is partly relying on that the transported > flow will adopt them self if trunking, or if not, that they become > useless and the call terminates because of that. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf305b10764ab0ee04a85ade61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Forgive the top-posting, but I want to make a meta-comment. =A0If we w= ere planning on building something from scratch, I would strongly agree tha= t it would be quite tough going, especially given our timelines. =A0But thi= s working group is not allowed to re-use existing work, it is strongly enco= uraged to do so. =A0Picking a protocol to implement which has the character= istics below is a lot less difficult than re-starting the exercise from scr= atch.

Providing XMPP, DTLS, or SCTP between the endpoints cer= tainly has challenges, but it would *not* involve starting from scratch.

regards,

Ted


On Mon, Jul 18, 2011 at 6:56 AM, Magnus Westerlund= <ma= gnus.westerlund@ericsson.com> wrote:
On 2011-07-15 19:29, Tim = Panton wrote:
> I don't think it is very hard to implement, we could take RFC 5456= 's
> sequencing and retry mechanism for example. or indeed Plan9's IL .=

I would warn about thinking this is easy. It is easy to get something=
that works on sunny days, it is hard to build something that is secure,
efficient, robust and fair.

I would like to point out that a reliable protocol do need a number of
functions. If those are achieve from a lower layer or need to be
implemented in this protocol is a choice. However, functionalities such as:=

- Congestion Control
- Flow Control
- Retransmission
- RTT estimation
- Buffer handling
- Parameter and functionality negotiation

Are likely all need for a safe and stable and future safe protocol.

There are good reasons for choosing something there is experience in
that it works.

For example I took a quick look at RFC5456 which appears to not have
congestion control. I think it is partly relying on that the transported flow will adopt them self if trunking, or if not, that they become
useless and the call terminates because of that.

cheers

Magnus Westerlund

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

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

--20cf305b10764ab0ee04a85ade61-- From fluffy@cisco.com Mon Jul 18 10:00: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 B609D21F8BBB for ; Mon, 18 Jul 2011 10:00: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 v8YZ4XyduAGT for ; Mon, 18 Jul 2011 10:00:17 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4858B21F8B3D for ; Mon, 18 Jul 2011 10:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=871; q=dns/txt; s=iport; t=1311008417; x=1312218017; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2yX1Ok5go+0TVyo72JbKwFatMoHdHCpVb74qpH9IPvc=; b=WDOh/L4374cnEBqbR0M+e/gdD0WSlcZfhSo730VX/0UWfVI8i0ZQlJul PSuTDwIfAc9DZL3Vq1HZbFd85f1CYrNuY7ZQTAXQXVKgyHXPh+bn9c7Mb 65KDRyxjI4l2m2YYSNG2lndNrktHkLadE133hvB31EXt6j0q7taSww0bL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHRmJE6Q/khL/2dsb2JhbABUp3l3iHykNJ4PhV1fBIdUixKQdQ X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="43064475" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 18 Jul 2011 17:00:07 +0000 Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6IH05OX019404; Mon, 18 Jul 2011 17:00:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <271CD938-00F7-423D-BA6E-6407811DC80E@phonefromhere.com> Date: Mon, 18 Jul 2011 10:00:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CEC8860-BF8F-44CB-8641-925F18503231@cisco.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E243B77.1000900@ericsson.com> <271CD938-00F7-423D-BA6E-6407811DC80E@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 17:00:21 -0000 On Jul 18, 2011, at 7:19 , Tim Panton wrote: >=20 > On 18 Jul 2011, at 14:56, Magnus Westerlund wrote: >=20 >> On 2011-07-15 19:29, Tim Panton wrote: >>> I don't think it is very hard to implement, we could take RFC 5456's >>> sequencing and retry mechanism for example. or indeed Plan9's IL . >>=20 >> I would warn about thinking this is easy. It is easy to get something >> that works on sunny days, it is hard to build something that is = secure, >> efficient, robust and fair. >>=20 >=20 > Agreed, getting all 4 in any protocol is hard, indeed I don't think = I've seen it=20 > done yet. FWIW - TLS over TCP with application level reconnect on failure seem to = meet all 4. Where it fails if you can't easily do it in user space. So = I'd add two more. Needs to work with high degree of nat/fw traversal = success and be easy to deploy.=20 From fluffy@cisco.com Mon Jul 18 10:12: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 7B0FA21F8672 for ; Mon, 18 Jul 2011 10:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.273 X-Spam-Level: X-Spam-Status: No, score=-104.273 tagged_above=-999 required=5 tests=[AWL=-1.674, 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 6xsbpbAqK9VH for ; Mon, 18 Jul 2011 10:12:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A609F21F85F2 for ; Mon, 18 Jul 2011 10:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2704; q=dns/txt; s=iport; t=1311009133; x=1312218733; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iTOGVn7Cuoa7LrYbXjns+qrEEJ39RDYLHXJAFlzT+xs=; b=NuNEntABmjaSwtiwBfUSnetMpR4ja9gtJZIrhkEQCqDKkDiLJY6Ma3nS N8oGv/vXwzPsMNQvGmg9UViCbzsyk4vJYQWmTZYiBanqRrCYGOTINjmWX ozXXsyvQrSkUBxDU+33sYQAkuj/DDdFgI8M/pJzDKslJNhLEBFxZqJZUe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALZnJE6rRDoJ/2dsb2JhbABUp3l3iHykMJ4RhV1fBIdUixKQdQ X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4028473" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2011 17:12:13 +0000 Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6IHCCHL019483; Mon, 18 Jul 2011 17:12:12 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 18 Jul 2011 10:12:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> To: Ted Hardie X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 17:12:18 -0000 On Jul 17, 2011, at 15:54 , Ted Hardie wrote: > On Fri, Jul 15, 2011 at 8:51 AM, Cullen Jennings = wrote: >=20 > I'd like to push back on the reliable service. I've yet to hear a use = case for it that was real time. It's very hard to do a reliable real = time protocol and we have seen zero proposal for this. For non real time = data, just dump it in dropbox of whatever your equivalent is and don't = do it peer to peer. >=20 > Can I see your dropbox incantation for remote camera movement? I am = particularly interested in how you make it useful without a reliable, = near real-time message that says "go check dropbox for $foo".... Ok, Ok, - I deserver to made fun of. There are something you can't do = with drop box or XMPP but lets take the PTU control problem. I have seen = protocols that have semantics like "start panning right" or "pan right = 10 degrees relative to current position". These protocol all have an = lousy user experience compared to the ones that have semantics of "go to = absolutely position Y at time X". IMHO, the best way to do a real time = PTU control protocol is just periodical send the absolute position you = want the camera to be at and send it more than once, or each time the = users presses the button, if you don't want to do an ACK. It's hard to = been something like that if latency is important. If latency is not = important, XMPP is easier. (thought I would still send absolute not = relative). I'll note more than one system is doing PTU control over RTP = using an approach much like sending DTMF via RTP. >=20 > To put this another way, a reliable protocol associated with a real = time stream has some pretty obvious uses (gaming has also already been = mentioned). I'm pushing back on it is obvious that there are use cases for this. = That there is simultaneous need for the semantics of "you must deliver = this data no matter how long it takes" and "this data need to get there = in less than X time or it is useless" is not obvious to me.=20 That said, if someone has a proposal to go do this, as I said before, I = have no object to doing this. It be fine to have reliability but I'm not = seeing it as critical for use cases like gaming and PTU control.=20 > Whether it is truly "real time" or not is potentially subject to = debate, but the results of the semantic nit-picking won't tell us much. = The reliable protocol is a useful part of the real time system, even if = its retransmission and congestion control methods make it less "real = time" than rtp. agree >=20 > Just my two cents, also as an individual contributor, >=20 > Ted >=20 > =20 From tim@phonefromhere.com Mon Jul 18 10:36: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 3758D21F8AD9 for ; Mon, 18 Jul 2011 10:36:02 -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 l7Q+im01NZNC for ; Mon, 18 Jul 2011 10:36:01 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 7C24A21F8A30 for ; Mon, 18 Jul 2011 10:36:00 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id DE8B637A902; Mon, 18 Jul 2011 18:45:43 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> Date: Mon, 18 Jul 2011 18:35:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <32BE1B60-DB34-4744-B17C-CEC92F2E74AE@phonefromhere.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 17:36:02 -0000 On 18 Jul 2011, at 18:12, Cullen Jennings wrote: >>=20 >>=20 >> To put this another way, a reliable protocol associated with a real = time stream has some pretty obvious uses (gaming has also already been = mentioned). >=20 > I'm pushing back on it is obvious that there are use cases for this. = That there is simultaneous need for the semantics of "you must deliver = this data no matter how long it takes" and "this data need to get there = in less than X time or it is useless" is not obvious to me.=20 To my mind, _sequence_ is vital.=20 The protocol should promise to deliver these datagrams to the = application layer in the order that they were sent. If that requires an occasional round-trip delay to cope with = packet loss (perhaps with a flag to say it was late), that's acceptable (but sub-optimal), out-of-order datagrams aren't. =20 In the vast majority of cases we can expect it to deliver the datagram = in close sync with the associated media. Tim.= From fluffy@cisco.com Mon Jul 18 11:21: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 87DD521F8640 for ; Mon, 18 Jul 2011 11:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.232 X-Spam-Level: X-Spam-Status: No, score=-104.232 tagged_above=-999 required=5 tests=[AWL=-1.633, 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 GE+iJN8NkzZq for ; Mon, 18 Jul 2011 11:21:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD6D21F85B9 for ; Mon, 18 Jul 2011 11:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=10008; q=dns/txt; s=iport; t=1311013285; x=1312222885; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dhotEnfdRZNuF4h6RgQeuF5okO08Z3+CsUjBpXNMN9o=; b=kvpWfG1iNh8eOzvdTDdUI1po3AwLS2VZcZmnnQtncHUxbLIEPIEVUz+g 2K9Gt3mZ3ayXw3q2aw7qaVcbldD19qoIzhVUtTMP6/Fbjnxn9JlRrL1qm 5yMJzhfuRQNB8Jj/x3695sTrgHM6GW0s/cYkejQcx3qZrkAYjTOvsf0pQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEJ4JE6rRDoI/2dsb2JhbABUp3p3iHykRJ4dAoVbXwSHVIsSkHU X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4052316" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2011 18:21:24 +0000 Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6IILNnI004413; Mon, 18 Jul 2011 18:21:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Mon, 18 Jul 2011 11:21:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <992E0971-8B50-4459-8779-78EC8F0C3AEB@cisco.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> To: Tim Panton X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 18:21:30 -0000 On Jul 15, 2011, at 10:29 , Tim Panton wrote: > If we don't specify a reliable transport then all the page authors = will end adding a reliable layer in javascript, it will be as ugly as = DTMF in RTP ! Tim, I agree with your concern here. My largest concern of not = specifying something is that it just means we will see a million = different things done in JavaScript. That's pretty much what we have in = the IETF today. Lots of protocols implement a different reliability = layer on top of UDP. However, it has not been all that bad and it has = been very hard to get the transport guys to go and define one that = everyone can use (I've presented in transport asking for this in the = past). The end result has not really been all that bad. The protocols = work even thought each one did there own reliability systems so I have = not been all that worried about it. I'm not sure DTMF is a fair example = to compare to... > Or worse it will be spray and pray. sort of like we do with audio and video in RTP :-)=20 > Most of the use-cases I can think of need sequenced and reliable = datagrams. If I'm playing a game I don't want it to > drop or mis-order any one of the actions in the unholster, point, = shoot sequence :-) A game might have a UI that requires you to do but due to round trip = latency times, most games are going to send over the write something = more like an object to type bullet exists at this location in Phase/Time = space and let both sides simulate from that and decide if there was a = hit or not. The phase/time space is just the location of the bullet, = information about it such as it's type, and it's velocity vector as well = as the point in time. That might get acked or retransmitted or just = ignored on loss depending on the reliability of the game but a FPS is = going to have crappy UE if it both side to multiple lock step = transaction to keep state like unholster, point, shoot in sync between = the sides.=20 >=20 > I don't think it is very hard to implement, we could take RFC 5456's = sequencing and retry mechanism for example. > or indeed Plan9's IL . Again, no object to someone coming up with a good proposal (I suspect = that 5456 would get more than a bit of push back) but it's not on my = high priority list because the games I can think of could probably work = fine with a proposal more like the above than needing a reliable = protocol. That said, I do share your concern about we will just see lots = of crappy implementations of this a reliable protocol for file transfer = on top of whatever we do for this RTCWeb work.=20 >=20 > Tim. >=20 >=20 > On 15 Jul 2011, at 16:51, Cullen Jennings wrote: >=20 >>=20 >> I'd like to push back on the reliable service. I've yet to hear a use = case for it that was real time. It's very hard to do a reliable real = time protocol and we have seen zero proposal for this. For non real time = data, just dump it in dropbox of whatever your equivalent is and don't = do it peer to peer. Unless someone has a real need, and wants to put = forward a proposal, I don't see a need to focus energy on this right = now. I'd rather work on the thing everyone agrees they do need which is = the unreliable transfer.=20 >>=20 >> Cullen =20 >>=20 >> On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: >>=20 >>> Hi, >>>=20 >>> I have reviewed the input both the last 2 weeks and the discussion = back >>> in April. >>>=20 >>> I see a strong support but with at least 2 people disagreeing to a = basic >>> p2p datagram functionality. The use cases are various and some just >>> state that they see it as important functionality to provide to = empower >>> the web application. >>>=20 >>> Based on this I declare a rough consensus on that we should provide = a >>> non-media data service that is unreliable datagram oriented directly >>> between the peers. >>>=20 >>> One of objections against this was lack of clear requirements for = what >>> the service. The straw men requirements I included has gotten some >>> discussion. Mostly support for them, but it is clear to me that we = need >>> to further develop them. I would recommend the proponents for = driving >>> proposals towards meeting this functionality to further discuss the >>> requirements taking the input so far into consideration. >>>=20 >>> When it comes to reliable data transfer between peers there has been = 4-5 >>> that wanted the functionality, 2 additional that explicitly stated = they >>> where okay with it. No additional that has stated against it. >>>=20 >>> My interpretation is that we are close to having a rough consensus = for >>> reliable data service, but we have so far seen no proponent willing = to >>> suggest a solution for this. I would also note that a solution is = likely >>> a functionality block that isn't dependent on more than the >>> signaling/negotiation and the NAT traversal and thus can be added a >>> later stage or be worked on with a completion date further into the >>> future than other pieces already. >>>=20 >>> So for reliable data I would recommend that someone takes on the = role of >>> proponent and provides a draft with their perceived requirements and = a >>> straw man proposal for how to solve these requirements so we have >>> something more tangible to discuss. >>>=20 >>> Cheers >>>=20 >>> Magnus >>>=20 >>> On 2011-06-27 09:36, Magnus Westerlund wrote: >>>> 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=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 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Magnus Westerlund >>>=20 >>> = ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> = ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> = ---------------------------------------------------------------------- >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Mon Jul 18 11:30: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 2699821F8B73 for ; Mon, 18 Jul 2011 11:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.193 X-Spam-Level: X-Spam-Status: No, score=-104.193 tagged_above=-999 required=5 tests=[AWL=-1.594, 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 BaUZguZgu5Ea for ; Mon, 18 Jul 2011 11:30:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AA66821F8B5E for ; Mon, 18 Jul 2011 11:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2093; q=dns/txt; s=iport; t=1311013833; x=1312223433; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=TgPLuNG9kuunojEf4I+eT2KD/GdEz3YvU1dgvwVOd6U=; b=ior6KAglYqqplbhjdj4RDrrfH2pO0d0rTjvvc6dkJw8douLWuCOzL5k+ ktuo9MR3Pq4PJdgEbq36sfzLs6kKIUU0+5XJQEwHo+xb/asFlKh1675RJ YaFQ8XRFXLwkWPymcNKzaFV1cw5Qpk/Y8Bv0UfbtWBOndnDA/A4WzwZCK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8HAOF6JE6rRDoG/2dsb2JhbABUmHuOf3esKIEjjnWPKYVdXwSHVIsSkHU X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4056133" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2011 18:30:28 +0000 Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6IIURae012426 for ; Mon, 18 Jul 2011 18:30:27 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 11:30:26 -0700 Message-Id: <2C6FA49B-5D95-4C45-AD67-EA5D042F972C@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Rohan Red Cross 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, 18 Jul 2011 18:30:37 -0000 I'd like to add an use case along the following lines... Rohan works for international aid agency and deploys wireless networks = in places where disasters have wiped out all the existing = infrastructure. There's just been an earthquake in Haiti. Betty works = for Canada Red Cross and need to get the Red Cross location in Haiti = connected to other aid groups in Haiti to help arrange complex logistics = of things like what order various aid agencies are even going to use the = limited resources of the runway at the airport. Rohan and Betty both use = the AidNet web application for communicating and have cached copies = using the HTML5 offline support on their computers or, if they can't get = their computers into the country, can at least get copy in via USB key = and find a local computer with a browser. Rohan sets up a wireless = access point on the tallest thing he can find and managed to provide = wireless coverage for many square miles. Betty connects to that and = manages to call Rohan to coordinate and let Rohan know the location of = RedCross so that better wireless can be arranged there.=20 This one more or less one of the use cases for P2PSIP work to be able to = set up an ad hoc voice communications system before one even had access = to DNS server or any global internet infrastructure. I think that the = whole P2PSIP system could be done inside browser (or a system similar to = it). The underling transport of P2PSIP is very close to the proposal = here including the use of ICE. One would probably need to define a new = transport that an Reload overlay could use but other than that, I think = one could meet this use case using something along the lines of Reload = running in browser.=20 It gets more interesting as you add work such as what is a happening in = the VIPR WG. The browser on the mobile could have access the the call = logs for calls made over the cellular voice part of the phone. That = would allow the browser to run the VIPR related protocols and be able to = receive VoIP calls for that number. From dzonatas@gmail.com Mon Jul 18 11:44: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 7B3E021F8B10 for ; Mon, 18 Jul 2011 11:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.42 X-Spam-Level: X-Spam-Status: No, score=-4.42 tagged_above=-999 required=5 tests=[AWL=-0.821, 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 ofWJqdeCZlyO for ; Mon, 18 Jul 2011 11:44:50 -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 600FF21F8B11 for ; Mon, 18 Jul 2011 11:44:50 -0700 (PDT) Received: by iye7 with SMTP id 7so3649948iye.31 for ; Mon, 18 Jul 2011 11:44:48 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BVjNmVTLvjQz0vaujvWyA2XCsAQh+l3A0NxWg+RcpE8=; b=pMLe/jzqZ5KiDcS+iJgY5RS8Q7W5maUL5gzQFVVZ2ZFihy1kJ3woL8skbqp0LFJ0ph f8jCSA9kRayNRGNog4IucwiGZIkMb+EIVkuhjFasMPTVhc78Ydq5wcOfB0aoQnq4Mpu2 ReaCFRev7UkxkScyFOlzqczT59uOn9s4/BH6g= Received: by 10.231.10.129 with SMTP id p1mr6185557ibp.31.1311014688647; Mon, 18 Jul 2011 11:44:48 -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 v3sm3075615ibh.67.2011.07.18.11.44.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 11:44:47 -0700 (PDT) Message-ID: <4E247F23.70904@gmail.com> Date: Mon, 18 Jul 2011 11:44:51 -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: Cullen Jennings References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> In-Reply-To: <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 18:44:54 -0000 On 07/18/2011 10:12 AM, Cullen Jennings wrote: > There are something you can't do with drop box or XMPP but lets take > the PTU control problem. I have seen protocols that have semantics > like "start panning right" or "pan right 10 degrees relative to > current position". These protocol all have an lousy user experience > compared to the ones that have semantics of "go to absolutely position > Y at time X". Gets kind of hard in consideration of gesture recognition as semantics, so I think the example above shows why semantic terminology leads to bloat without given sequences. The difference is useful where error correction is more obvious; for example, avoidance of RTT vs retransmission (over wireless). Lossless compression is valuable here, yet the semantics of compression let people think lossy is ideal, which lossy leads later to extra links (the bloat). Tweaked the example above: "track X for duration Y until Z" -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From matthew.kaufman@skype.net Mon Jul 18 11:52: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 BF41821F8562 for ; Mon, 18 Jul 2011 11:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Qdfg6d4CjL2N for ; Mon, 18 Jul 2011 11:52:43 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7F52321F8561 for ; Mon, 18 Jul 2011 11:52:43 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id D8ECC16F6; Mon, 18 Jul 2011 20:52:41 +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=Pg DHzt1agYfLpDlVJ/jj9qgecfI=; b=R6BGiDDzl0lHsQixuKwBTpjyJgiuoTpCD4 FSFo8Uqea9vaqcB3PK2S1IAL9+kBR5/9FnjRRW2NN0Qi4VLhPoQTX2kWcuEcrpqF apUtcYNaq+R2AJKCQWa+6lECB1gj8BOfJn+s74BlqlG5kFqEEZx7yrXyu2qpGHKb qOXF5g0AA= 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=dN4PpvfHIbpitoQErQ25qd WxsonTjLEBdaDgXnwljUZbT3+m5u0W0GWXUlSii3DcF1o+4CRaRQ/PmfGNGsuaqi 8kYUAZMFGF5j2SwnLGnpeAz5O4OL9MpB35dBM8JDa9zvBApvXhugwUbPgmdMBWpq sj60s8aInfEz+T11BUxAQ= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id D6F017FC; Mon, 18 Jul 2011 20:52:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id BBA953507E85; Mon, 18 Jul 2011 20:52:41 +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 sjdjIKhXCGIn; Mon, 18 Jul 2011 20:52:29 +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 A83453507E8E; Mon, 18 Jul 2011 20:52:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Mon, 18 Jul 2011 11:52:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47425BFC-EF8B-429C-BB51-764E856224B6@skype.net> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 18:52:47 -0000 On Jul 15, 2011, at 8:51 AM, Cullen Jennings wrote: >=20 > I'd like to push back on the reliable service. I've yet to hear a use = case for it that was real time. It's very hard to do a reliable real = time protocol and we have seen zero proposal for this. For non real time = data, just dump it in dropbox of whatever your equivalent is and don't = do it peer to peer. Unless someone has a real need, and wants to put = forward a proposal, I don't see a need to focus energy on this right = now. I'd rather work on the thing everyone agrees they do need which is = the unreliable transfer.=20 I'm personally torn on this one. I think that if we want to get = something actually specified and deal with the majority of the use = cases, we really need to focus on A/V and make data as simple as = possible... that means unreliable datagrams with nothing but browser = enforcement of rate via a simple congestion control algorithm. On the other hand, if we go that route, people building things with the = API will be forced to do it in Javascript... and all the arguments for = putting ICE in the browser code instead of Javascript apply here, = specifically that getting it right for N=3D# of browser implementations = case is much more likely than getting it right for N=3D# of Javascript = coders case. But to get there probably requires solving many of the same set of = problems that MFP and RTMFP solved, and that's a whole lot of = specification and code to implement it, and we haven't even started on = the agreement of which building blocks to start with (DCCP? SCTP? TCP = over UDP?) much less gotten to a complete specification. Unfortunately the right answer is probably to, once again, go to TSVAREA = and state that a protocol that fits set of requirements would be really = useful, and then not put it in browsers until it exists. There might be = some value to making that ask in the form of a requirements document, = but it needs to not be a "requirements of browsers for RTCWEB", instead = it needs to be "requirements for a data transport protocol if a = sophisticated one were to be added to RTCWEB in the future". As I do remember most of the reasons we came up with MFP and RTMFP, I = would be glad to contribute to such a requirements document. But until then, I think we need *something* that lets data get from A to = B over the direct unreliable channel. Matthew Kaufman= From fluffy@cisco.com Mon Jul 18 13:03: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 9E2C311E8070 for ; Mon, 18 Jul 2011 13:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.156 X-Spam-Level: X-Spam-Status: No, score=-104.156 tagged_above=-999 required=5 tests=[AWL=-1.557, 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 n8v5EgnLlEuw for ; Mon, 18 Jul 2011 13:03:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 117AE228010 for ; Mon, 18 Jul 2011 13:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2697; q=dns/txt; s=iport; t=1311019416; x=1312229016; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RikcCOf5D9ExNSP/xox2PzlbNRqJhwDT8LTUKdO77vI=; b=kweWegVgBMLmnoI1DGAthvqvzr73tHf9IRKeB1wkRj/6L2z/aonfqbJs Q/kl16d25dyoWm83HLodbtYbdsVl6JbwfnWYajRuS54avBCs9EGEXJPnG WwKkQ8StKLsEUWFWGlRGFHSbvNp1rV/cF+IT4aMBHjgPQiUCuV126LvTU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN6QJE6rRDoH/2dsb2JhbABTp3p3iHylDJ4vhjwEh1SLEpB1 X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4088692" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2011 20:03:35 +0000 Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6IK3Y2p023923; Mon, 18 Jul 2011 20:03:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <47425BFC-EF8B-429C-BB51-764E856224B6@skype.net> Date: Mon, 18 Jul 2011 13:03:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <47425BFC-EF8B-429C-BB51-764E856224B6@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 20:03:36 -0000 On Jul 18, 2011, at 11:52 , Matthew Kaufman wrote: >=20 > On Jul 15, 2011, at 8:51 AM, Cullen Jennings wrote: >=20 >>=20 >> I'd like to push back on the reliable service. I've yet to hear a use = case for it that was real time. It's very hard to do a reliable real = time protocol and we have seen zero proposal for this. For non real time = data, just dump it in dropbox of whatever your equivalent is and don't = do it peer to peer. Unless someone has a real need, and wants to put = forward a proposal, I don't see a need to focus energy on this right = now. I'd rather work on the thing everyone agrees they do need which is = the unreliable transfer.=20 >=20 > I'm personally torn on this one. I think that if we want to get = something actually specified and deal with the majority of the use = cases, we really need to focus on A/V and make data as simple as = possible... that means unreliable datagrams with nothing but browser = enforcement of rate via a simple congestion control algorithm. >=20 > On the other hand, if we go that route, people building things with = the API will be forced to do it in Javascript... and all the arguments = for putting ICE in the browser code instead of Javascript apply here, = specifically that getting it right for N=3D# of browser implementations = case is much more likely than getting it right for N=3D# of Javascript = coders case. >=20 > But to get there probably requires solving many of the same set of = problems that MFP and RTMFP solved, and that's a whole lot of = specification and code to implement it, and we haven't even started on = the agreement of which building blocks to start with (DCCP? SCTP? TCP = over UDP?) much less gotten to a complete specification. >=20 > Unfortunately the right answer is probably to, once again, go to = TSVAREA and state that a protocol that fits set of requirements would be = really useful, and then not put it in browsers until it exists. There = might be some value to making that ask in the form of a requirements = document, but it needs to not be a "requirements of browsers for = RTCWEB", instead it needs to be "requirements for a data transport = protocol if a sophisticated one were to be added to RTCWEB in the = future". >=20 > As I do remember most of the reasons we came up with MFP and RTMFP, I = would be glad to contribute to such a requirements document. >=20 > But until then, I think we need *something* that lets data get from A = to B over the direct unreliable channel. >=20 > Matthew Kaufman I find myself on about the same page. I'd be happy to help go write up = some requirement slides for the transport area.=20 From randell1@jesup.org Mon Jul 18 15:12: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 1253C21F880C for ; Mon, 18 Jul 2011 15:12:03 -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 71uN2HNoZWWC for ; Mon, 18 Jul 2011 15:12:02 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF0A21F8797 for ; Mon, 18 Jul 2011 15:12:02 -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 1Qiw2j-0005bh-HS for rtcweb@ietf.org; Mon, 18 Jul 2011 17:12:01 -0500 Message-ID: <4E24AF7C.4080604@jesup.org> Date: Mon, 18 Jul 2011 18:11:08 -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> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> In-Reply-To: <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.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] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jul 2011 22:12:03 -0000 On 7/18/2011 1:12 PM, Cullen Jennings wrote: > On Jul 17, 2011, at 15:54 , Ted Hardie wrote: > >> On Fri, Jul 15, 2011 at 8:51 AM, Cullen Jennings wrote: >> >> I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer. >> >> Can I see your dropbox incantation for remote camera movement? I am particularly interested in how you make it useful without a reliable, near real-time message that says "go check dropbox for $foo".... > Ok, Ok, - I deserver to made fun of. There are something you can't do with drop box or XMPP but lets take the PTU control problem. I have seen protocols that have semantics like "start panning right" or "pan right 10 degrees relative to current position". These protocol all have an lousy user experience compared to the ones that have semantics of "go to absolutely position Y at time X". IMHO, the best way to do a real time PTU control protocol is just periodical send the absolute position you want the camera to be at and send it more than once, or each time the users presses the button, if you don't want to do an ACK. It's hard to been something like that if latency is important. If latency is not important, XMPP is easier. (thought I would still send absolute not relative). I'll note more than one system is doing PTU control over RTP using an approach much like sending DTMF via RTP. I agree it's easier/more accurate to say "move to X". However, people are used to various "continuous" motion controls, like zoom and trying to frame a subject, or follow motion. From a UI point of view, a good low-delay continuous reactive system is often more functional, depending the problem space. People will find a way to fit their preferred user experience onto the protocol, even if it's not a good fit for the protocol, because they don't care about the protocol - they care about their UI. >> To put this another way, a reliable protocol associated with a real time stream has some pretty obvious uses (gaming has also already been mentioned). > I'm pushing back on it is obvious that there are use cases for this. That there is simultaneous need for the semantics of "you must deliver this data no matter how long it takes" and "this data need to get there in less than X time or it is useless" is not obvious to me. It's rare that "no matter how long it takes" is hugely delayed - if it is, you have other, bigger problems. Delayed - could well be; usually only a little, with some jitter. And SCTP would be even better as far as that's concerned. Talk to some RT networked game designers. I'll bet they all use a mix of reliable and unreliable protocols (perhaps not like TCP, more like SCTP). But even though reliable == not guaranteed, I'll bet they all want it to get there as fast as possible in the normal case. People are ignoring the huge positive of having this data connection bundled with the other streams and connected with them. Having to set up a parallel reliable stream adds all sorts of complexity to the application when firewall traversal/IP address changes/etc are included, and then you have the issue of it being a second distinct stream from a congestion point of view - it makes it very hard to control the relative bandwidth of the reliable stream versus all the unreliable streams - you're likely to get ~ 50% for the reliable stream if you're overcommitted, with the % varying quite a bit. And if the stream has to go through a relay or server while media goes P2P you have an issue for people designing services to use this protocol - increased cost and bandwidth for one. Even a chat-with-file-transfer - if the file xfer has to go through the server, you have to maintain bandwidth for that case, and transfer speed may be limited by RTT of going through a remote server (think Taiwan user to Taiwan user with a relay in the US). All that said - yes, there are complexity issues to consider, which was why I was suggesting leveraging an existing tunneled protocol like SCTP or even TCP-over-UDP. -- Randell Jesup randell-ietf@jesup.org From magnus.westerlund@ericsson.com Tue Jul 19 07:01: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 6979A21F8764 for ; Tue, 19 Jul 2011 07:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 gcK7tZfhE80B for ; Tue, 19 Jul 2011 07:01: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 95B6C21F855D for ; Tue, 19 Jul 2011 07:01:58 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4a-4e258e556b8d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 27.0E.20773.55E852E4; Tue, 19 Jul 2011 16:01:57 +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; Tue, 19 Jul 2011 16:01:57 +0200 Message-ID: <4E258E54.3010206@ericsson.com> Date: Tue, 19 Jul 2011 16:01:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Cullen Jennings References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <992E0971-8B50-4459-8779-78EC8F0C3AEB@cisco.com> In-Reply-To: <992E0971-8B50-4459-8779-78EC8F0C3AEB@cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 14:01:59 -0000 On 2011-07-18 20:21, Cullen Jennings wrote: > > Tim, I agree with your concern here. My largest concern of not > specifying something is that it just means we will see a million > different things done in JavaScript. That's pretty much what we have > in the IETF today. Lots of protocols implement a different > reliability layer on top of UDP. I would note that the the JS library at least is going to run on top of a congestion controlled and secured datagram service. Thus, any implementor can primarily hurt themselves rather than the network. > However, it has not been all that > bad and it has been very hard to get the transport guys to go and > define one that everyone can use (I've presented in transport asking > for this in the past). The end result has not really been all that > bad. The protocols work even thought each one did there own > reliability systems so I have not been all that worried about it. I'm > not sure DTMF is a fair example to compare to... I can't resist this bate as a transport guy. Well, things don't happen for free, and no one was willing to stick in there for the long haul to actually define it. There also has been a lot of political resistance, and the fact that transport development in OS etc happens at glacier speed, unless someone well connected enough truly wants something. I think a reasonable, re-use as much as possible, sane proposal has some chance. And we WG chairs should try to get early feedback from TSV-Dir etc so we avoid late surprises. Please note that this is not an a comment in any direction around the support for reliable data service. Just trying to provide some background and feel for the land. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From henry.sinnreich@gmail.com Tue Jul 19 07:16: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 E862421F8549 for ; Tue, 19 Jul 2011 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtw8SLKRbI4p for ; Tue, 19 Jul 2011 07:16:52 -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 12B0E21F889D for ; Tue, 19 Jul 2011 07:16:49 -0700 (PDT) Received: by yxp4 with SMTP id 4so2130245yxp.31 for ; Tue, 19 Jul 2011 07:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; bh=KSd0Zrdo5gQ9Qj2dv/eEK0KBxPJ7+EB3TYbVVSRlWrg=; b=gT8wGIBc64KKdSiBVEU/IXttrnCtubyG77KMwk/BXlY/a4yKLO9G5qMiH1yLUjed76 zct/zvqUraWlXPAoEeCfl4d7Ap14q+uSs8LPpSQL19NyUFQIL4Sj3EjiPKkzpSpF0szL fhgnUMEMTYM+JnBNfHVspSbthYErXeih8/xAk= Received: by 10.150.48.38 with SMTP id v38mr7016069ybv.317.1311085008539; Tue, 19 Jul 2011 07:16:48 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-164.tx.res.rr.com [76.184.227.164]) by mx.google.com with ESMTPS id j21sm38397ybg.10.2011.07.19.07.16.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 07:16:47 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 19 Jul 2011 09:16:42 -0500 From: Henry Sinnreich To: Serge Lachapelle , Cullen Jennings Message-ID: Thread-Topic: [rtcweb] realiable data service Thread-Index: AcxGHntjricir2L930+8yfMW/e9nrQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393911806_989140" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 14:16:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393911806_989140 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 Maybe it would be useful for the proponents of this and many other =B3desirable=B2 features to think from the perspective if they would have to pa= y themselves for such developments and also make the code freely available. Cullen at least will make his code available. Thanks, Henry On 7/18/11 2:16 AM, "Serge Lachapelle" wrote: > Hi Cullen, >=20 > I agree with your push back. >=20 > Focus is very important. Audio and video already present a huge challenge= . > (signalling, network, web developer friendly API, security, browser > integration...) >=20 > Also, I think that there is a real risk in introducing "duplicate" > functionality in the browser as it may confuse web developers. There is a= lot > going on in HTML5... >=20 > In my mind, this is "version 2.0" stuff. >=20 > /Serge >=20 >=20 > On Fri, Jul 15, 2011 at 17:51, Cullen Jennings wrote: >>=20 >> I'd like to push back on the reliable service. I've yet to hear a use ca= se >> for it that was real time. It's very hard to do a reliable real time pro= tocol >> and we have seen zero proposal for this. For non real time data, just du= mp it >> in dropbox of whatever your equivalent is and don't do it peer to peer. >> Unless someone has a real need, and wants to put forward a proposal, I d= on't >> see a need to focus energy on this right now. I'd rather work on the thi= ng >> everyone agrees they do need which is the unreliable transfer. >>=20 >> Cullen >>=20 >> On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: >>=20 >>> > Hi, >>> > >>> > I have reviewed the input both the last 2 weeks and the discussion ba= ck >>> > in April. >>> > >>> > I see a strong support but with at least 2 people disagreeing to a ba= sic >>> > p2p datagram functionality. The use cases are various and some just >>> > state that they see it as important functionality to provide to empow= er >>> > the web application. >>> > >>> > Based on this I declare a rough consensus on that we should provide a >>> > non-media data service that is unreliable datagram oriented directly >>> > between the peers. >>> > >>> > One of objections against this was lack of clear requirements for wha= t >>> > the service. The straw men requirements I included has gotten some >>> > discussion. Mostly support for them, but it is clear to me that we ne= ed >>> > to further develop them. I would recommend the proponents for driving >>> > proposals towards meeting this functionality to further discuss the >>> > requirements taking the input so far into consideration. >>> > >>> > When it comes to reliable data transfer between peers there has been = 4-5 >>> > that wanted the functionality, 2 additional that explicitly stated th= ey >>> > where okay with it. No additional that has stated against it. >>> > >>> > My interpretation is that we are close to having a rough consensus fo= r >>> > reliable data service, but we have so far seen no proponent willing t= o >>> > suggest a solution for this. I would also note that a solution is lik= ely >>> > a functionality block that isn't dependent on more than the >>> > signaling/negotiation and the NAT traversal and thus can be added a >>> > later stage or be worked on with a completion date further into the >>> > future than other pieces already. >>> > >>> > So for reliable data I would recommend that someone takes on the role= of >>> > proponent and provides a draft with their perceived requirements and = a >>> > straw man proposal for how to solve these requirements so we have >>> > something more tangible to discuss. >>> > >>> > Cheers >>> > >>> > Magnus >>> > >>> > On 2011-06-27 09:36, Magnus Westerlund wrote: >>>> >> WG, >>>> >> >>>> >> At the interim it was planned to have a bit discussion on the datag= ram >>>> >> 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. n= ot >>>> >> 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 th= e >>>> >> RTCWEB provide a unreliable datagram service. This clearly needs >>>> >> additional requirements to be secure and safe to deploy, but more a= bout >>>> >> 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 orient= ed >>>> >> 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 soluti= on >>>> >> please provide motivation and use case and requirements. >>>> >> >>>> >> I also want to take a stab on what I personally see as the requirem= ents >>>> >> that exist on unreliable datagram service in the context of RTCWEB. >>>> >> >>>> >> - Unreliable data transmission >>>> >> - Datagram oriented >>>> >> =A0 * Size limited by MTU >>>> >> =A0 =A0 - Path MTU discovery needed >>>> >> =A0 * Fragmentation by the application >>>> >> - Low latency, i.e. Peer to Peer preferable >>>> >> - Congestion Controlled, to be >>>> >> =A0 * Network friendly >>>> >> =A0 * Not become a Denial of Service tool >>>> >> - Security >>>> >> =A0* Confidentiality >>>> >> =A0* Integrity Protected >>>> >> =A0* Source Authenticated (at least bound to the signalling peer) >>>> >> =A0* 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0 --B_3393911806_989140 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [rtcweb] realiable data service +1
Maybe it would be useful for the proponents of this and many other “d= esirable” features to think from the perspective if they would have to= pay themselves for such developments and also make the code freely availabl= e.
Cullen at least will make his code available.

Thanks, Henry


On 7/18/11 2:16 AM, "Serge Lachapelle" <sergel@google.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>Hi Cullen,

I agree with your push back.

Focus is very important. Audio and video already present a huge challenge. = (signalling, network, web developer friendly API, security, browser integrat= ion...)

Also, I think that there is a real risk in introducing "duplicate"= ; functionality in the browser as it may confuse web developers. There is a = lot going on in HTML5...

In my mind, this is "version 2.0" stuff.

/Serge


On Fri, Jul 15, 2011 at 17:51, Cullen Jennings <fluffy@cisco.com> wrote:
<= SPAN STYLE=3D'font-size:13pt'>
I'd like to push back on the reliable service. I've yet to hear a use case = for it that was real time. It's very hard to do a reliable real time protoco= l and we have seen zero proposal for this. For non real time data, just dump= it in dropbox of whatever your equivalent is and don't do it peer to peer. = Unless someone has a real need, and wants to put forward a proposal, I don't= see a need to focus energy on this right now. I'd rather work on the thing = everyone agrees they do need which is the unreliable transfer.

Cullen <in my individaul contribut role>

On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote:

> Hi,
>
> I have reviewed the input both the last 2 weeks and the discussion bac= k
> in April.
>
> I see a strong support but with at least 2 people disagreeing to a bas= ic
> p2p datagram functionality. The use cases are various and some just > state that they see it as important functionality to provide to empowe= r
> the web application.
>
> Based on this I declare a rough consensus on that we should provide a<= BR> > non-media data service that is unreliable datagram oriented directly > between the peers.
>
> One of objections against this was lack of clear requirements for what=
> the service. The straw men requirements I included has gotten some
> discussion. Mostly support for them, but it is clear to me that we nee= d
> to further develop them. I would recommend the proponents for driving<= BR> > proposals towards meeting this functionality to further discuss the > requirements taking the input so far into consideration.
>
> When it comes to reliable data transfer between peers there has been 4= -5
> that wanted the functionality, 2 additional that explicitly stated the= y
> where okay with it. No additional that has stated against it.
>
> My interpretation is that we are close to having a rough consensus for=
> reliable data service, but we have so far seen no proponent willing to=
> suggest a solution for this. I would also note that a solution is like= ly
> a functionality block that isn't dependent on more than the
> signaling/negotiation and the NAT traversal and thus can be added a > later stage or be worked on with a completion date further into the > future than other pieces already.
>
> So for reliable data I would recommend that someone takes on the role = of
> proponent and provides a draft with their perceived requirements and a=
> straw man proposal for how to solve these requirements so we have
> something more tangible to discuss.
>
> Cheers
>
> Magnus
>
> On 2011-06-27 09:36, Magnus Westerlund wrote:
>> WG,
>>
>> At the interim it was planned to have a bit discussion on the data= gram
>> service for RTCWEB. The first question to try to resolve if there<= BR> >> 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 th= e
>> 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 t= o 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 t= he
>> 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<= BR> >> directly between peers? Please provide your view and any additiona= l
>> statements of motivation that you desire to provide.
>>
>> Secondly, there is a question if there needs to have something tha= t
>> provides reliable message (of arbitrary size) or byte stream orien= ted
>> data transport between the peers. I personally foresee that people= will
>> build JS libraries for this on top of a unreliable datagram servic= e. If
>> you desire reliable data service as part of the standardized solut= ion
>> please provide motivation and use case and requirements.
>>
>> I also want to take a stab on what I personally see as the require= ments
>> that exist on unreliable datagram service in the context of RTCWEB= .
>>
>> - Unreliable data transmission
>> - Datagram oriented
>> =A0 * Size limited by MTU
>> =A0 =A0 - Path MTU discovery needed
>> =A0 * Fragmentation by the application
>> - Low latency, i.e. Peer to Peer preferable
>> - Congestion Controlled, to be
>> =A0 * Network friendly
>> =A0 * Not become a Denial of Service tool
>> - Security
>> =A0* Confidentiality
>> =A0* Integrity Protected
>> =A0* Source Authenticated (at least bound to the signalling peer) >> =A0* Ensure consent to receive data
>>
>> Please debate the above. This is an attempt to ensure that we can<= BR> >> establish WG consensus on both data service and any requirements.<= BR> >>
>> cheers
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ----
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ------------------------------------------------------------------= ----
>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0
--B_3393911806_989140-- From magnus.westerlund@ericsson.com Tue Jul 19 07:28: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 A115E21F8681 for ; Tue, 19 Jul 2011 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 zLWhu8zTR0x8 for ; Tue, 19 Jul 2011 07:28:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B8DEA21F85D2 for ; Tue, 19 Jul 2011 07:28:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-cd-4e2594859a8a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FB.31.20773.584952E4; Tue, 19 Jul 2011 16:28:21 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 16:28:21 +0200 Message-ID: <4E259484.20509@ericsson.com> Date: Tue, 19 Jul 2011 16:28:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 14:28:23 -0000 Hi, This email is as an individual contributor. I want to get started on the discussion of the Multiplexing of the various protocols over single lower layer transport flow, such as a UDP flow. I will attempt to split up the questions into different emails. The first question I think is reasonably easy to get answered, but I think it is time we determine if my belief in the answer is correct or not. The traffic between two RTCWEB peers from the various components, such as RTP sessions, datagram service: a) MUST be sent as Individual flows for each component. b) MUST be multiplexed into a single transport flow. c) SHOULD be multiplexed into a single transport flow, but the RTCWEB peer MUST be able to send them as individual flows. I would love if people can indicate their choice or preferences. I personally prefer A as it it is simplest in all aspect except the NAT traversal. - It allows for flow based QoS. - It is the what the implementation that exist mostly do - Signaling protocols that exist support it, no extra functionality - People are used to the concept - It minimizes the difference to legacy. Thus it is the quickest road to define something with the least formal push back and concern over maturity of any solution. The downside with B and C is that we do have to solve the multiplexing and get an agreement that gets through all the hurdles. Of these two opens I do prefer C. Although it results in the extra complexities of having both alternatives, it will give us both a fallback, flow based QoS and better legacy support. Now it is your time to make your opinion heard! Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Jul 19 08:11: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 5731C21F8681 for ; Tue, 19 Jul 2011 08:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 edhv8I-1iSqg for ; Tue, 19 Jul 2011 08:11:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B37721F85A7 for ; Tue, 19 Jul 2011 08:11:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ee-4e259eae0a4b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AC.9D.09774.EAE952E4; Tue, 19 Jul 2011 17:11:42 +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, 19 Jul 2011 17:11:41 +0200 Message-ID: <4E259EAD.3060505@ericsson.com> Date: Tue, 19 Jul 2011 17:11:41 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 15:11:44 -0000 WG, As individual contributor. I would recommend that people read both https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/?include_text=1 and https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1 before getting into this debate. Assuming that the consensus of "To multiplex or not!" thread is either of the options requiring multiplexing we get to the question of how to do the multiplexing. Lets start with a very fundamental question: Explicit vs Implicit multiplexing So the explicit is when something in the received packets has the explicit purpose to identifies a context that resolves the protocol, the session context etc. Implicit is when we have no such explicit field, instead we have to rely on that investigating values of particular bits in the payload of the packet. For example trying to identify RTP based on the first byte of the RTP header where the version two bits shall be 10b. I am strongly arguing against implicit identifying the protocol for the following reasons. 1. We have 4 or more protocols (The possible set of protocols include: STUN, RTP/RTCP, Datagram, and DTLS-SRTP. There is likely future extensions, like reliable protocol) that needs to be identified and demultiplexed. A single extension in one of these protocols can cause the whole house of cards to come tumbling down. 2. It will require one to find an RTP internal session multiplexing mechanism. This is likely not easy or causes a fork of RTP into two non-compatible versions. In addition such a mechanism needs defining which takes time, likely substantial time as there is quite a lot of RTP mechanisms to consider. 3. We likely need a multiplexing layer anyway if we want a fall back over WebSockets or HTTP. Thus we see this a very fragile mechanism that creates additional work overhead and large uncertainties in when it would be available. We have in our draft: https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ looked at two possible suggestions for explicit multiplexing. Either a thin shim layer primarily consisting of a identifier that through negotiation is bound to a context, like an particular RTP session or a datagram channel. The other alternative we considered was using DCCP over UDP for RTP and datagram. That way we got a complete port space for multiplexing different purposes for flows. We also got a transport framework with its own negotiation, congestion control, a several other features. We invite people to consider these proposals or suggest better alternatives of explicit multiplexing. But I hope we can avoid a serious mistake and select implicit multiplexing. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From juberti@google.com Tue Jul 19 08:21: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 7788221F8557 for ; Tue, 19 Jul 2011 08:21:36 -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 Kr7uEDQtsJX9 for ; Tue, 19 Jul 2011 08:21:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E10BF21F8538 for ; Tue, 19 Jul 2011 08:21:18 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p6JFLIKX009641 for ; Tue, 19 Jul 2011 08:21:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311088878; bh=RuWeTmuTUJGbEygwdXmTlJDT3RA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lKyWGnLuNfweeBKYXAuO+XE3BTz2nnJgsL4ia+DcDY3T/DZNoRBZA1Soz47XNK825 qmHEf3p8WA4bmnUPjd1jA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=V572aQOJyvpK0cawB+3rVKL78BhV1rfAbZrT+hFjWwsTKuNTlFYR8/gp7zTguwQDO ANdjwwX0iAKWYE9FJRYyA== Received: from iyf40 (iyf40.prod.google.com [10.241.50.104]) by kpbe11.cbf.corp.google.com with ESMTP id p6JFLGrF027147 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Jul 2011 08:21:17 -0700 Received: by iyf40 with SMTP id 40so4711103iyf.12 for ; Tue, 19 Jul 2011 08:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Rm5vFr42GHHE6X+6lZaw0IPDAii/Z7d0+B69f5HDQVk=; b=TmGGK+HFouRqP7DHz+VefCptUy87T2YSPUDnIa5g7aTgEDNoHs5ELxv4IetPricR/v Vfl1BHq3HAnNr69T6Rxw== Received: by 10.231.73.138 with SMTP id q10mr7132595ibj.13.1311088876753; Tue, 19 Jul 2011 08:21:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.35.4 with HTTP; Tue, 19 Jul 2011 08:20:56 -0700 (PDT) In-Reply-To: <4E259484.20509@ericsson.com> References: <4E259484.20509@ericsson.com> From: Justin Uberti Date: Tue, 19 Jul 2011 08:20:56 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=000e0cd56f26c493df04a86daad8 X-System-Of-Record: true Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 15:21:37 -0000 --000e0cd56f26c493df04a86daad8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2011 at 7:28 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > This email is as an individual contributor. > > I want to get started on the discussion of the Multiplexing of the > various protocols over single lower layer transport flow, such as a UDP > flow. I will attempt to split up the questions into different emails. > > The first question I think is reasonably easy to get answered, but I > think it is time we determine if my belief in the answer is correct or no= t. > > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: > To be clear, we are talking about different RTP sessions, as opposed to different RTP sources within a single RTP session, correct? > a) MUST be sent as Individual flows for each component. > > b) MUST be multiplexed into a single transport flow. > > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. > > I would love if people can indicate their choice or preferences. > > I personally prefer A as it it is simplest in all aspect except the NAT > traversal. > - It allows for flow based QoS. > For video applications, it's not clear that flow-based QoS is sufficient, a= s some packets are of higher importance than others. Diffserv markings allow per-packet QoS to be applied, but this could be done even in a multiplexing scenario. > - It is the what the implementation that exist mostly do > - Signaling protocols that exist support it, no extra functionality > - People are used to the concept > - It minimizes the difference to legacy. > I agree that existing implementations will need to change to support this. However, is there a large enough base of deployed endpoints that support a) multiple RTP sessions and b) the other RTCWEB constrains (ICE, etc) to make this a significant concern? > Thus it is the quickest road to define something with the least formal > push back and concern over maturity of any solution. > > The downside with B and C is that we do have to solve the multiplexing > and get an agreement that gets through all the hurdles. > > Of these two opens I do prefer C. Although it results in the extra > complexities of having both alternatives, it will give us both a > fallback, flow based QoS and better legacy support. > > Now it is your time to make your opinion heard! > > 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 > --000e0cd56f26c493df04a86daad8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2011 at 7:28 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

This email is as an individual contributor.

I want to get started on the discussion of the Multiplexing of the
various protocols over single lower layer transport flow, such as a UDP
flow. I will attempt to split up the questions into different emails.

The first question I think is reasonably easy to get answered, but I
think it is time we determine if my belief in the answer is correct or not.=

The traffic between two RTCWEB peers from the various components, such
as RTP sessions, datagram service:

To b= e clear, we are talking about different RTP sessions, as opposed to differe= nt RTP sources within a single RTP session, correct?


a) MUST be sent as Individual flows for each component.

b) MUST be multiplexed into a single transport flow.

c) SHOULD be multiplexed into a single transport flow, but the RTCWEB
peer MUST be able to send them as individual flows.

I would love if people can indicate their choice or preferences.

I personally prefer A as it it is simplest in all aspect except the NAT
traversal.
- It allows for flow based QoS.

For vid= eo applications, it's not clear that flow-based QoS is sufficient, as s= ome packets are of higher importance than others. Diffserv markings allow p= er-packet QoS to be applied, but this could be done even in a multiplexing = scenario.
=C2=A0
- It is the what the implementation that exist mostly do
- Signaling protocols that exist support it, no extra functionality
- People are used to the concept
- It minimizes the difference to legacy.

I agree that existing implementations will need to change to support this= . However, is there a large enough base of deployed endpoints that support = a) multiple RTP sessions and b) the other RTCWEB constrains (ICE, etc) to m= ake this a significant concern?=C2=A0


Thus it is the quickest road to define something with the least formal
push back and concern over maturity of any solution.

The downside with B and C is that we do have to solve the multiplexing
and get an agreement that gets through all the hurdles.

Of these two opens I do prefer C. =C2=A0Although it results in the extra complexities of having both alternatives, it will give us both a
fallback, flow based QoS and better legacy support.


Now it is your time to make your opinion heard!

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone = =C2=A0+46 10 71= 48287
F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46= 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--000e0cd56f26c493df04a86daad8-- From magnus.westerlund@ericsson.com Tue Jul 19 08:23: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 064E821F8ABC for ; Tue, 19 Jul 2011 08:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 b1ofuNj-TmWb for ; Tue, 19 Jul 2011 08:23: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 0576821F8A4D for ; Tue, 19 Jul 2011 08:23:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-63-4e25a188d3dd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 00.EE.09774.881A52E4; Tue, 19 Jul 2011 17:23:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 17:23:52 +0200 Message-ID: <4E25A187.5010508@ericsson.com> Date: Tue, 19 Jul 2011 17:23:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Justin Uberti References: <4E259484.20509@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 15:23:55 -0000 On 2011-07-19 17:20, Justin Uberti wrote: > > On Tue, Jul 19, 2011 at 7:28 AM, Magnus Westerlund > > > wrote: > > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: > > > To be clear, we are talking about different RTP sessions, as opposed to > different RTP sources within a single RTP session, correct? Exactly! 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 dzonatas@gmail.com Tue Jul 19 08:30: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 F2E2021F8ACC for ; Tue, 19 Jul 2011 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.391 X-Spam-Level: X-Spam-Status: No, score=-4.391 tagged_above=-999 required=5 tests=[AWL=-0.792, 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 UrjTL610hXcs for ; Tue, 19 Jul 2011 08:30:32 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8ABB21F8ABE for ; Tue, 19 Jul 2011 08:30:31 -0700 (PDT) Received: by iwn39 with SMTP id 39so4526317iwn.31 for ; Tue, 19 Jul 2011 08:30:31 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=H3VipBgvfnhdqMXy/gapp3oXg9Y8XU5gGUwXZ0g3wWs=; b=m5E3kvyQsbtiUMrMld35R1ZfEeRozfSWzaqmESqkRDc/RoTNv99qsBGhlaru2bXz58 YgFq5lfyvPHiAFAzGdC2LEKJy55gOraraPX3rY8P5zozYn8knCyv7YQhjesnl9ffRjQJ d75yn5B6PkMGeGeNk8IB/T2+7KK2ct3SrQMpI= Received: by 10.42.169.68 with SMTP id a4mr8414555icz.301.1311089431392; Tue, 19 Jul 2011 08:30:31 -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 a9sm6392707icy.6.2011.07.19.08.30.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 08:30:30 -0700 (PDT) Message-ID: <4E25A31A.8010103@gmail.com> Date: Tue, 19 Jul 2011 08:30:34 -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: Magnus Westerlund References: <4E259484.20509@ericsson.com> In-Reply-To: <4E259484.20509@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 15:30:36 -0000 On 07/19/2011 07:28 AM, Magnus Westerlund wrote: > a) MUST be sent as Individual flows for each component. > > b) MUST be multiplexed into a single transport flow. > > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. > > One clarification please, if there are known ranges of A as one spectrum, does this WG still consider that multiplexed? IPv6, for example, allows us to multiplex in a TCP-less way, simply by fulfillment of the flows to more than one individual address. Those addresses could constitute one spectrum in a stateful manner, or not. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From matthew.kaufman@skype.net Tue Jul 19 08:39: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 77A0E11E8070 for ; Tue, 19 Jul 2011 08:39:58 -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 CpLER2Pv8pt4 for ; Tue, 19 Jul 2011 08:39:54 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2F59911E8074 for ; Tue, 19 Jul 2011 08:39:54 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EF90416FC; Tue, 19 Jul 2011 17:39:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=qtzmWiu7EnhLRV JazAgxuTNSCyQ=; b=JpJ+Qt23JCERBPIF+KGZ6mio8i2ynbjpQvpD26yiD6J/Ri pZ/TavI6Y9dOzw0nbXpZlZ1xCcKc8pXry0kxX4RXZNQxcrqU9f7UYhP5uxTJSz85 Y6E5ydRS5SMzx6cXY/sbEedtm0/KW7HVFvSoYmtvAqzLHJVl5pn7+dLhD7PYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=YsPObeeSgsFC64MSw4hC4V d/ksvEXCiZJy9DBYvSwTucayZRgIaK0ev4u9x24OZmhe3rslg0RblbUGIc7xL8qp bHXp3O2i3op9lo/01jqKFPP1wrSjjQqmc/YQjE7ZywBWW+rK3qfRAPM6LwhMxCsh KVF8V0F4SCkUDa6UUaq8c= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E4C707F6; Tue, 19 Jul 2011 17:39:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CCB8E35080D7; Tue, 19 Jul 2011 17:39:52 +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 BwT0jBV-YCZw; Tue, 19 Jul 2011 17:39:47 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 75293350806F; Tue, 19 Jul 2011 17:39:47 +0200 (CEST) Message-ID: <4E25A53B.70500@skype.net> Date: Tue, 19 Jul 2011 08:39:39 -0700 From: Matthew Kaufman 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: Magnus Westerlund References: <4E259EAD.3060505@ericsson.com> In-Reply-To: <4E259EAD.3060505@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 15:39:58 -0000 On 7/19/2011 8:11 AM, Magnus Westerlund wrote: > 1. We have 4 or more protocols (The possible set of protocols include: > STUN, RTP/RTCP, Datagram, and DTLS-SRTP. There is likely future > extensions, like reliable protocol) that needs to be identified and > demultiplexed. A single extension in one of these protocols can cause > the whole house of cards to come tumbling down. Multiplexing RTP, RTCP, and STUN on the same port already needs to keep working for lots of other reasons, we can leverage those reasons. draft-kaufman-rtp-compatible-data suggests that the data service can be multiplexed with these as well, in a way that is protected by the same things that protect the above. > 2. It will require one to find an RTP internal session multiplexing > mechanism. This is likely not easy or causes a fork of RTP into two > non-compatible versions. In addition such a mechanism needs defining > which takes time, likely substantial time as there is quite a lot of RTP > mechanisms to consider. There's one, SSRC. Since we already allow two or more audio streams to be multiplexed using SSRC, and two or more video streams to be multiplexed using SSRC, it really isn't a stretch to allow one audio and one video to be multiplexed using SSRC when the two ends agree that this works for them. > 3. We likely need a multiplexing layer anyway if we want a fall back > over WebSockets or HTTP. I agree that we currently don't have good agreement of how a TCP fallback works for RTCWEB, but it is clearly necessary. > Thus we see this a very fragile mechanism that creates additional work > overhead and large uncertainties in when it would be available. Not any more fragile than RTP+RTCP+STUN on the same port already is. > We have in our draft: > https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ looked > at two possible suggestions for explicit multiplexing. Either a thin > shim layer primarily consisting of a identifier that through negotiation > is bound to a context, like an particular RTP session or a datagram > channel. Adding a shim layer causes two problems: 1. You need to be able to run the system in a way that has the shim layer removed when you want to do legacy interoperability. 2. Existing protocol stacks and middleboxes cannot be reused as easily. > The other alternative we considered was using DCCP over UDP for RTP and > datagram. That way we got a complete port space for multiplexing > different purposes for flows. We also got a transport framework with its > own negotiation, congestion control, a several other features. Same problem, no matter what the shim layer is. I've already considered explicit multiplexing. It has lots of advantages. But it also fails several of the tests laid out in the requirements, and delays implementation and adoption. So I think we're down to implicit multiplexing, or no multiplexing at all. And when we run out of IPv4 NAT mappings, you'll understand why multiplexing should be in there. Matthew Kaufman From juberti@google.com Tue Jul 19 08:59: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 9A53821F84F6 for ; Tue, 19 Jul 2011 08:59:23 -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 eYb-q+P6toXj for ; Tue, 19 Jul 2011 08:59:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2483F21F84EA for ; Tue, 19 Jul 2011 08:59:18 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p6JFxHdH032216 for ; Tue, 19 Jul 2011 08:59:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311091157; bh=fCIBtwsygf2Ca93Wzl7Qu/8q17o=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ywAzCBc2hyHx8p9tvHvfLK5yw7yOfxcCfaD5+fnmRPZplDpWNbdEqdYJMc6Y6n2Hq rM+yKXdP+LRH6MMuBZ2cg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=JY1tUIVb4GW+UI4/XF6uVYCZyg4E9g4cyd9cEpHm9E1ACWvhIcXyzxep9gsOz6v8v Y8IwXL63qCfvN/NC+mXzw== Received: from iyi20 (iyi20.prod.google.com [10.241.51.20]) by kpbe17.cbf.corp.google.com with ESMTP id p6JFxFr0018908 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Jul 2011 08:59:15 -0700 Received: by iyi20 with SMTP id 20so5908929iyi.35 for ; Tue, 19 Jul 2011 08:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Rq/mMp0aRJGIj6I7+gERpUWX1MDZjyILRW6kvtw6RqM=; b=eWl0t8v/zkz8ouP3kd6wjQg9SRHI1YM7jG4rkoctrVgB6SXo7oA3oFOBtbBAmvVKBE S8jDpYrSL2nji9yTJFkQ== Received: by 10.231.73.138 with SMTP id q10mr7163038ibj.13.1311091155185; Tue, 19 Jul 2011 08:59:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.35.4 with HTTP; Tue, 19 Jul 2011 08:58:55 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 19 Jul 2011 08:58:55 -0700 Message-ID: To: Henry Sinnreich Content-Type: multipart/alternative; boundary=000e0cd56f2692b0a904a86e3270 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 15:59:23 -0000 --000e0cd56f2692b0a904a86e3270 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At Google, we created a TCP/ICE-UDP layering to solve this exact problem, using a user-mode implementation of TCP. It has some rough edges, but has worked well in practice, and the code is freely available. We know people will want/need a reliable messaging mechanism for p2p data. While we can debate the details of this mechanism at length, I suspect anything we choose will result in a better end-state than if we require application developers to implement their own. On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich wrote: > +1 > Maybe it would be useful for the proponents of this and many other > =E2=80=9Cdesirable=E2=80=9D features to think from the perspective if the= y would have to pay > themselves for such developments and also make the code freely available. > Cullen at least will make his code available. > > Thanks, Henry > > > > On 7/18/11 2:16 AM, "Serge Lachapelle" wrote: > > Hi Cullen, > > I agree with your push back. > > Focus is very important. Audio and video already present a huge challenge= . > (signalling, network, web developer friendly API, security, browser > integration...) > > Also, I think that there is a real risk in introducing "duplicate" > functionality in the browser as it may confuse web developers. There is a > lot going on in HTML5... > > In my mind, this is "version 2.0" stuff. > > /Serge > > > On Fri, Jul 15, 2011 at 17:51, Cullen Jennings wrote: > > > I'd like to push back on the reliable service. I've yet to hear a use cas= e > for it that was real time. It's very hard to do a reliable real time > protocol and we have seen zero proposal for this. For non real time data, > just dump it in dropbox of whatever your equivalent is and don't do it pe= er > to peer. Unless someone has a real need, and wants to put forward a > proposal, I don't see a need to focus energy on this right now. I'd rathe= r > work on the thing everyone agrees they do need which is the unreliable > transfer. > > Cullen > > On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: > > > Hi, > > > > I have reviewed the input both the last 2 weeks and the discussion back > > in April. > > > > I see a strong support but with at least 2 people disagreeing to a basi= c > > p2p datagram functionality. The use cases are various and some just > > state that they see it as important functionality to provide to empower > > the web application. > > > > Based on this I declare a rough consensus on that we should provide a > > non-media data service that is unreliable datagram oriented directly > > between the peers. > > > > One of objections against this was lack of clear requirements for what > > the service. The straw men requirements I included has gotten some > > discussion. Mostly support for them, but it is clear to me that we need > > to further develop them. I would recommend the proponents for driving > > proposals towards meeting this functionality to further discuss the > > requirements taking the input so far into consideration. > > > > When it comes to reliable data transfer between peers there has been 4-= 5 > > that wanted the functionality, 2 additional that explicitly stated they > > where okay with it. No additional that has stated against it. > > > > My interpretation is that we are close to having a rough consensus for > > reliable data service, but we have so far seen no proponent willing to > > suggest a solution for this. I would also note that a solution is likel= y > > a functionality block that isn't dependent on more than the > > signaling/negotiation and the NAT traversal and thus can be added a > > later stage or be worked on with a completion date further into the > > future than other pieces already. > > > > So for reliable data I would recommend that someone takes on the role o= f > > proponent and provides a draft with their perceived requirements and a > > straw man proposal for how to solve these requirements so we have > > something more tangible to discuss. > > > > Cheers > > > > Magnus > > > > On 2011-06-27 09:36, 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 abou= t > >> 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 wil= l > >> build JS libraries for this on top of a unreliable datagram service. I= f > >> 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 requirement= s > >> 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 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --000e0cd56f2692b0a904a86e3270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At Google, we created a TCP/ICE-UDP layering to solve this exact problem, u= sing a user-mode implementation of TCP. It has some rough edges, but has wo= rked well in practice, and the code is freely available.

We know people will want/need a reliable messaging mechanism for p2p data. = While we can debate the details of this mechanism at length, I suspect anyt= hing we choose will result in a better end-state than if we require applica= tion developers to implement their own.

On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnr= eich <hen= ry.sinnreich@gmail.com> wrote:
+1
Maybe it would be useful for the proponents of this and many other =E2=80= =9Cdesirable=E2=80=9D features to think from the perspective if they would = have to pay themselves for such developments and also make the code freely = available.
Cullen at least will make his code available.

Thanks, Henry



On 7/18/11 2:16 AM, "Serge Lachapelle" <sergel@google.com> wrote:

Hi Cullen,

I agree with your push back.

Focus is very important. Audio and video already present a huge challenge. = (signalling, network, web developer friendly API, security, browser integra= tion...)

Also, I think that there is a real risk in introducing "duplicate"= ; functionality in the browser as it may confuse web developers. There is a= lot going on in HTML5...

In my mind, this is "version 2.0" stuff.

/Serge


On Fri, Jul 15, 2011 at 17:51, Cullen Jennings <fluffy@cisco.com> wrote:

I'd like to push back on the reliable service. I've yet to hear a u= se case for it that was real time. It's very hard to do a reliable real= time protocol and we have seen zero proposal for this. For non real time d= ata, just dump it in dropbox of whatever your equivalent is and don't d= o it peer to peer. Unless someone has a real need, and wants to put forward= a proposal, I don't see a need to focus energy on this right now. I= 9;d rather work on the thing everyone agrees they do need which is the unre= liable transfer.

Cullen <in my individaul contribut role>

On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote:

> Hi,
>
> I have reviewed the input both the last 2 weeks and the discussion bac= k
> in April.
>
> I see a strong support but with at least 2 people disagreeing to a bas= ic
> p2p datagram functionality. The use cases are various and some just > state that they see it as important functionality to provide to empowe= r
> the web application.
>
> Based on this I declare a rough consensus on that we should provide a<= br> > non-media data service that is unreliable datagram oriented directly > between the peers.
>
> One of objections against this was lack of clear requirements for what=
> the service. The straw men requirements I included has gotten some
> discussion. Mostly support for them, but it is clear to me that we nee= d
> to further develop them. I would recommend the proponents for driving<= br> > proposals towards meeting this functionality to further discuss the > requirements taking the input so far into consideration.
>
> When it comes to reliable data transfer between peers there has been 4= -5
> that wanted the functionality, 2 additional that explicitly stated the= y
> where okay with it. No additional that has stated against it.
>
> My interpretation is that we are close to having a rough consensus for=
> reliable data service, but we have so far seen no proponent willing to=
> suggest a solution for this. I would also note that a solution is like= ly
> a functionality block that isn't dependent on more than the
> signaling/negotiation and the NAT traversal and thus can be added a > later stage or be worked on with a completion date further into the > future than other pieces already.
>
> So for reliable data I would recommend that someone takes on the role = of
> proponent and provides a draft with their perceived requirements and a=
> straw man proposal for how to solve these requirements so we have
> something more tangible to discuss.
>
> Cheers
>
> Magnus
>
> On 2011-06-27 09:36, Magnus Westerlund wrote:
>> WG,
>>
>> At the interim it was planned to have a bit discussion on the data= gram
>> service for RTCWEB. The first question to try to resolve if there<= br> >> 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 th= e
>> 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 t= o 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 t= he
>> 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<= br> >> directly between peers? Please provide your view and any additiona= l
>> statements of motivation that you desire to provide.
>>
>> Secondly, there is a question if there needs to have something tha= t
>> provides reliable message (of arbitrary size) or byte stream orien= ted
>> data transport between the peers. I personally foresee that people= will
>> build JS libraries for this on top of a unreliable datagram servic= e. If
>> you desire reliable data service as part of the standardized solut= ion
>> please provide motivation and use case and requirements.
>>
>> I also want to take a stab on what I personally see as the require= ments
>> that exist on unreliable datagram service in the context of RTCWEB= .
>>
>> - Unreliable data transmission
>> - Datagram oriented
>> =C2=A0 * Size limited by MTU
>> =C2=A0 =C2=A0 - Path MTU discovery needed
>> =C2=A0 * Fragmentation by the application
>> - Low latency, i.e. Peer to Peer preferable
>> - Congestion Controlled, to be
>> =C2=A0 * Network friendly
>> =C2=A0 * Not become a Denial of Service tool
>> - Security
>> =C2=A0* Confidentiality
>> =C2=A0* Integrity Protected
>> =C2=A0* Source Authenticated (at least bound to the signalling pee= r)
>> =C2=A0* Ensure consent to receive data
>>
>> Please debate the above. This is an attempt to ensure that we can<= br> >> establish WG consensus on both data service and any requirements.<= br> >>
>> cheers
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ----
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ------------------------------------------------------------------= ----
>> Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Phone =C2=A0

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


--000e0cd56f2692b0a904a86e3270-- From randell1@jesup.org Tue Jul 19 09:38: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 29B6B1F0C3B for ; Tue, 19 Jul 2011 09:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Oh6QfQ524hMp for ; Tue, 19 Jul 2011 09:38:21 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 609DA1F0C39 for ; Tue, 19 Jul 2011 09:38:09 -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 1QjDJA-0003DM-Jg for rtcweb@ietf.org; Tue, 19 Jul 2011 11:38:08 -0500 Message-ID: <4E25B2BA.8000004@jesup.org> Date: Tue, 19 Jul 2011 12:37:14 -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: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 16:38:23 -0000 On 7/19/2011 11:58 AM, Justin Uberti wrote: > At Google, we created a TCP/ICE-UDP layering to solve this exact > problem, using a user-mode implementation of TCP. It has some rough > edges, but has worked well in practice, and the code is freely available. Right; pretty much what I'd anticipate, and working open code is good. SCTP as mentioned is a good choice too, and there exist (it appears) SCTP-over-UDP implementations, which may ease things. Also the TCP-over-UDP library I pointed to. > We know people will want/need a reliable messaging mechanism for p2p > data. While we can debate the details of this mechanism at length, I > suspect anything we choose will result in a better end-state than if > we require application developers to implement their own. As is obvious from my other messages, I agree wholeheartedly. > On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich > > wrote: > > +1 > Maybe it would be useful for the proponents of this and many other > “desirable” features to think from the perspective if they would > have to pay themselves for such developments and also make the > code freely available. > Cullen at least will make his code available. > See above. No one here wants to develop *another* reliable protocol if we can avoid it. I understand your reluctance. The goal is to produce something that will meet the needs and get used. If we don't meet the needs of the prospective users it's either an total waste of time (if they ignore this effort and stick with Flash/plugins/etc) or we get all sorts of hack/bad/problematic/incompatible implementations by individual developers using the UDP (or RTP!) streams we open as a base transport. To your point, another way this effort could fail is by biting off too much or taking too long to converge, which is a real danger. That's one reason to leverage existing protocols. -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Tue Jul 19 09:40: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 C5C021F0C40 for ; Tue, 19 Jul 2011 09:40:44 -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 IXEHOktoTBPn for ; Tue, 19 Jul 2011 09:40:38 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFCE1F0C37 for ; Tue, 19 Jul 2011 09:40:38 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 9D09416F7; Tue, 19 Jul 2011 18:40:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=nVc4f8APdqWbkm zQQ3gGxbYDo+U=; b=RGLo5s60G7L9Gc9xXZdwpInaA05yjZDyz2Go+Zzhr05PI7 mAGvEdPJPrVkQsg8MIe3mFKVkm170j/6CWBoKbSrNugNCoiIT3Yhb0e3HU1FH1OE 1tpXsFfyBnjyDhhnhfsTWcUsFbLpWszkRNsyGIrOG9CYQ21iNZ9u6CdUBnh9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=foN4QckAQUAPl8DTMJ6af/ wbi4YdoUZmBVg52TN36q4IsgT2KwXEyPsV2x43UlWBqA/BpTq7TmSJYqDlL/prKK 0sMKz93y0O93Hw2cTtLroDTCWdQPCn2XbBILaPv7lYT25QtIIGOGi6RP3ZBtSSaj Mq/2/IW8VYoZ1qmjbnCPg= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 9B6EB7FC; Tue, 19 Jul 2011 18:40:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7089135080A4; Tue, 19 Jul 2011 18:40:37 +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 2ii-WlTaSLTh; Tue, 19 Jul 2011 18:40:36 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 5AA203507EA9; Tue, 19 Jul 2011 18:40:36 +0200 (CEST) Message-ID: <4E25B37D.9080404@skype.net> Date: Tue, 19 Jul 2011 09:40:29 -0700 From: Matthew Kaufman 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: Magnus Westerlund References: <4E259484.20509@ericsson.com> In-Reply-To: <4E259484.20509@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 16:40:44 -0000 On 7/19/2011 7:28 AM, Magnus Westerlund wrote: > a) MUST be sent as Individual flows for each component. > > b) MUST be multiplexed into a single transport flow. > > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. > > I would love if people can indicate their choice or preferences. C. But I'm not sure that the "must" needs to be anything more than "you just make two peer connection objects, one for each". (In other words, any API that allows for multiplexing almost certainly allows for non-multiplexing)... this assumes that the multiplexing is implicit, of course. With explicit multiplexing it is even harder... the API needs to support turning on and off the multiplexing shim as well, something I'm not in favor of. Matthew Kaufman From emil@sip-communicator.org Tue Jul 19 09:47: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 E347C21F84CD for ; Tue, 19 Jul 2011 09:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 Y1pdt5bw5DyC for ; Tue, 19 Jul 2011 09:47:31 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id C236121F84DA for ; Tue, 19 Jul 2011 09:47:30 -0700 (PDT) Received: by fxe4 with SMTP id 4so383358fxe.27 for ; Tue, 19 Jul 2011 09:47:29 -0700 (PDT) Received: by 10.223.161.80 with SMTP id q16mr375004fax.36.1311094049751; Tue, 19 Jul 2011 09:47:29 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id 28sm70297fax.27.2011.07.19.09.47.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 09:47:28 -0700 (PDT) Message-ID: <4E25B51F.7050000@jitsi.org> Date: Tue, 19 Jul 2011 18:47:27 +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: <4E259484.20509@ericsson.com> In-Reply-To: <4E259484.20509@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 16:47:35 -0000 =D0=9D=D0=B0 19.07.11 16:28, Magnus Westerlund =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > a) MUST be sent as Individual flows for each component. +1 > b) MUST be multiplexed into a single transport flow. >=20 > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. >=20 > I would love if people can indicate their choice or preferences. >=20 > I personally prefer A as it it is simplest in all aspect except the NAT= > traversal. It definitely simplifies it on paper - it would be far easier to draw an ICE negotiation diagram that only deals with a single stream component. I am not sure however to what extent this would actually simplify implementations. They would still need to handle multiple candidates and pacing and such ... and of course they'd also need to implement a de-multiplexing layer. > - People are used to the concept > - It minimizes the difference to legacy. Personally I consider this as the most important part. Cheers, Emil >=20 > Thus it is the quickest road to define something with the least formal > push back and concern over maturity of any solution. >=20 > The downside with B and C is that we do have to solve the multiplexing > and get an agreement that gets through all the hurdles. >=20 > Of these two opens I do prefer C. Although it results in the extra > complexities of having both alternatives, it will give us both a > fallback, flow based QoS and better legacy support. >=20 > Now it is your time to make your opinion heard! >=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 emil@sip-communicator.org Tue Jul 19 09:55: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 8C0FC11E8094 for ; Tue, 19 Jul 2011 09:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 jULAhlB-JC0Z for ; Tue, 19 Jul 2011 09:55:19 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id E207311E807F for ; Tue, 19 Jul 2011 09:55:18 -0700 (PDT) Received: by fxe4 with SMTP id 4so395650fxe.27 for ; Tue, 19 Jul 2011 09:55:18 -0700 (PDT) Received: by 10.223.55.8 with SMTP id s8mr12130379fag.141.1311094517905; Tue, 19 Jul 2011 09:55:17 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id 21sm75390fay.21.2011.07.19.09.55.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 09:55:16 -0700 (PDT) Message-ID: <4E25B6F2.1030607@jitsi.org> Date: Tue, 19 Jul 2011 18:55:14 +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: Justin Uberti References: <4E259484.20509@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 16:55:23 -0000 =D0=9D=D0=B0 19.07.11 17:20, Justin Uberti =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > =20 >=20 > - It is the what the implementation that exist mostly do > - Signaling protocols that exist support it, no extra functionality= > - People are used to the concept > - It minimizes the difference to legacy. >=20 >=20 > I agree that existing implementations will need to change to support > this. However, is there a large enough base of deployed endpoints that > support a) multiple RTP sessions and b) the other RTCWEB constrains > (ICE, etc) to make this a significant concern?=20 You are referring to SIP/XMPP clients using RTP and ICE, right? Well, given that this has been IETF's default way of handling RTC for the past few years I would assume that there are a bunch yes. Besides, if we ever make the ICE part optional (like XEP-0177 does for XMPP) then we'd have media-layer interoperability with any VoIP client out there and this would definitely be a great win. Emil --=20 http://jitsi.org From emil@sip-communicator.org Tue Jul 19 10:02: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 3913E21F8581 for ; Tue, 19 Jul 2011 10:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 Bo+skSAKGupl for ; Tue, 19 Jul 2011 10:02:15 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8890221F855B for ; Tue, 19 Jul 2011 10:02:14 -0700 (PDT) Received: by fxe4 with SMTP id 4so406604fxe.27 for ; Tue, 19 Jul 2011 10:02:13 -0700 (PDT) Received: by 10.223.144.66 with SMTP id y2mr10731917fau.0.1311094933625; Tue, 19 Jul 2011 10:02:13 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id l22sm77130fam.33.2011.07.19.10.02.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 10:02:13 -0700 (PDT) Message-ID: <4E25B893.6010200@jitsi.org> Date: Tue, 19 Jul 2011 19:02: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.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Randell Jesup References: <4E25B2BA.8000004@jesup.org> In-Reply-To: <4E25B2BA.8000004@jesup.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 17:02:19 -0000 =D0=9D=D0=B0 19.07.11 18:37, Randell Jesup =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > On 7/19/2011 11:58 AM, Justin Uberti wrote: >> At Google, we created a TCP/ICE-UDP layering to solve this exact=20 >> problem, using a user-mode implementation of TCP. It has some rough=20 >> edges, but has worked well in practice, and the code is freely availab= le. >=20 > Right; pretty much what I'd anticipate +1 most definitely. Again, I have yet to see a massively used RTC application that doesn't have file transfer. So if this is not part of RTCWEB we will basically be asking developers to reimplement Pseudo TCP in JavaScript. Emil >, and working open code is good. =20 > SCTP as mentioned is a good choice too, and there exist (it appears)=20 > SCTP-over-UDP implementations, which may ease things. Also the=20 > TCP-over-UDP library I pointed to. >=20 >> We know people will want/need a reliable messaging mechanism for p2p=20 >> data. While we can debate the details of this mechanism at length, I=20 >> suspect anything we choose will result in a better end-state than if=20 >> we require application developers to implement their own. >=20 > As is obvious from my other messages, I agree wholeheartedly. >=20 >> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich=20 >> > wrote: >> >> +1 >> Maybe it would be useful for the proponents of this and many other= >> =E2=80=9Cdesirable=E2=80=9D features to think from the perspective= if they would >> have to pay themselves for such developments and also make the >> code freely available. >> Cullen at least will make his code available. >> >=20 > See above. No one here wants to develop *another* reliable protocol if= =20 > we can avoid it. I understand your reluctance. >=20 > The goal is to produce something that will meet the needs and get used.= =20 > If we don't meet the > needs of the prospective users it's either an total waste of time (if=20 > they ignore this effort and stick > with Flash/plugins/etc) or we get all sorts of=20 > hack/bad/problematic/incompatible implementations > by individual developers using the UDP (or RTP!) streams we open as a=20 > base transport. >=20 > To your point, another way this effort could fail is by biting off too = > much or taking too long to > converge, which is a real danger. That's one reason to leverage=20 > existing protocols. >=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 randell1@jesup.org Tue Jul 19 10:06: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 BC4BA11E807F for ; Tue, 19 Jul 2011 10:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uay1pTv7O8ih for ; Tue, 19 Jul 2011 10:06:33 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 31F5311E8084 for ; Tue, 19 Jul 2011 10:06:24 -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 1QjDkV-0007EO-Tw for rtcweb@ietf.org; Tue, 19 Jul 2011 12:06:23 -0500 Message-ID: <4E25B959.5000803@jesup.org> Date: Tue, 19 Jul 2011 13:05:29 -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: <4E259484.20509@ericsson.com> In-Reply-To: <4E259484.20509@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] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 17:06:33 -0000 On 7/19/2011 10:28 AM, Magnus Westerlund wrote: > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: > > a) MUST be sent as Individual flows for each component. > > b) MUST be multiplexed into a single transport flow. > > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. C). I understand the appeal of a). However, we already have minor issues with handling congestion across multiple streams - i.e. congestion notification goes to one flow, but not generally to the other flows that make up the total traffic between these two points. This leads to sub-optimal response to congestion, and as the number of flows increases this would get worse. Now, this really isn't mandated by the multiplex/non-multiplex nature; it's just easier and more obvious when they're multiplexed. The other big issue is as you add more than a single or two streams, the overhead and side-issues around ICE/etc get more ... interesting. In particular you can get (I assume) cases where different streams that are meant to be synchronized and follow the same route go over different paths/interfaces. If we only had to deal with 1 audio stream, or 1 audio and 1 video stream, the balance would be different. But in the world this spec will work in I strongly believe more than 2 streams will often exist. (Witness Google's "Huddle"). -- Randell Jesup randell-ietf@jesup.org From sergel@google.com Tue Jul 19 10:10:24 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 2A8C021F84FE for ; Tue, 19 Jul 2011 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 ViKzncQxpy92 for ; Tue, 19 Jul 2011 10:10:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 05BFF21F8569 for ; Tue, 19 Jul 2011 10:10:15 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p6JH9uNb025310 for ; Tue, 19 Jul 2011 10:09:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311095396; bh=GzeBLXtE4JCt8VMeGxImPefOgXY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=geT6+36JR+cdilzKpDwXasTO8QwNXh8fluPd2TG4aEvueyHSZcwtMslTBx4WxfIPB v8o0NM+KZwAuZirbfwqRw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=qAWOANE6HEnnyGNWrW7IIeTaScY3PbJzOYHCqdv2C0Y1+hrvco2AdeceE+2aVvoQT 3GZrsQHFI/7fporZ5kADQ== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by hpaq11.eem.corp.google.com with ESMTP id p6JH9Doh018025 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Jul 2011 10:09:55 -0700 Received: by gxk7 with SMTP id 7so2520404gxk.35 for ; Tue, 19 Jul 2011 10:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JEZ7Va4NeAOsvX7JkLup0DbDX70rN1pl/njA7NxrPos=; b=MVWssgxTJyzOR6j4WizVViML2bmqsP/g2vNVhGfCJUaCACzqYRYXo2TYXn8lv9TTDF 1YoskFylE/DyRdvyOuNA== Received: by 10.150.63.10 with SMTP id l10mr2847455yba.378.1311095393139; Tue, 19 Jul 2011 10:09:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.201.18 with HTTP; Tue, 19 Jul 2011 10:09:23 -0700 (PDT) In-Reply-To: <4E25B893.6010200@jitsi.org> References: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> From: Serge Lachapelle Date: Tue, 19 Jul 2011 19:09:23 +0200 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=000e0cd39bee2cbe0904a86f2f2b X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 17:10:24 -0000 --000e0cd39bee2cbe0904a86f2f2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are many very established ways to transfer files from a web browser. Dropbox, Google Docs, yousendit, mobileme, not counting the media specific ways, such as Flickr, Spotify, Youtube, etc... All offering great APIs for uploads, ACLs, etc... Seems like re-inventing the wheel. /Serge On Tue, Jul 19, 2011 at 19:02, Emil Ivov wrote: > > > =D0=9D=D0=B0 19.07.11 18:37, Randell Jesup =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > > On 7/19/2011 11:58 AM, Justin Uberti wrote: > >> At Google, we created a TCP/ICE-UDP layering to solve this exact > >> problem, using a user-mode implementation of TCP. It has some rough > >> edges, but has worked well in practice, and the code is freely > available. > > > > Right; pretty much what I'd anticipate > > +1 most definitely. Again, I have yet to see a massively used RTC > application that doesn't have file transfer. So if this is not part of > RTCWEB we will basically be asking developers to reimplement Pseudo TCP > in JavaScript. > > Emil > > >, and working open code is good. > > SCTP as mentioned is a good choice too, and there exist (it appears) > > SCTP-over-UDP implementations, which may ease things. Also the > > TCP-over-UDP library I pointed to. > > > >> We know people will want/need a reliable messaging mechanism for p2p > >> data. While we can debate the details of this mechanism at length, I > >> suspect anything we choose will result in a better end-state than if > >> we require application developers to implement their own. > > > > As is obvious from my other messages, I agree wholeheartedly. > > > >> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich > >> > wrote: > >> > >> +1 > >> Maybe it would be useful for the proponents of this and many other > >> =E2=80=9Cdesirable=E2=80=9D features to think from the perspective= if they would > >> have to pay themselves for such developments and also make the > >> code freely available. > >> Cullen at least will make his code available. > >> > > > > See above. No one here wants to develop *another* reliable protocol if > > we can avoid it. I understand your reluctance. > > > > The goal is to produce something that will meet the needs and get used. > > If we don't meet the > > needs of the prospective users it's either an total waste of time (if > > they ignore this effort and stick > > with Flash/plugins/etc) or we get all sorts of > > hack/bad/problematic/incompatible implementations > > by individual developers using the UDP (or RTP!) streams we open as a > > base transport. > > > > To your point, another way this effort could fail is by biting off too > > much or taking too long to > > converge, which is a real danger. That's one reason to leverage > > existing protocols. > > > > -- > 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32 Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880 Apparently, this footer is required in Europe. Apologies. This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else,please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks. --000e0cd39bee2cbe0904a86f2f2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are many very established ways to transfer files from a web browser. = Dropbox, Google Docs, yousendit, mobileme, not counting the media specific = ways, such as Flickr, Spotify, Youtube, etc... All offering great APIs for = uploads, ACLs, etc...

Seems like re-inventing the wheel.

/Serge

On Tue, Jul 19,= 2011 at 19:02, Emil Ivov <emcho@jitsi.org> wrote:


=D0=9D=D0=B0 19.07.11 18:37, Randell Jesup =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0:
> On 7/19/2011 11:58 AM, Justin Uberti wrote:
>> At Google, we created a TCP/ICE-UDP layering to solve this exact >> problem, using a user-mode implementation of TCP. It has some roug= h
>> edges, but has worked well in practice, and the code is freely ava= ilable.
>
> Right; pretty much what I'd anticipate

+1 most definitely. Again, I have yet to see a massively used RTC
application that doesn't have file transfer. So if this is not part of<= br> RTCWEB we will basically be asking developers to reimplement Pseudo TCP
in JavaScript.

Emil

>, and working open code is good.
> SCTP as mentioned is a good choice too, and there exist (it appears) > SCTP-over-UDP implementations, which may ease things. =C2=A0Also the > TCP-over-UDP library I pointed to.
>
>> We know people will want/need a reliable messaging mechanism for p= 2p
>> data. While we can debate the details of this mechanism at length,= I
>> suspect anything we choose will result in a better end-state than = if
>> we require application developers to implement their own.
>
> As is obvious from my other messages, I agree wholeheartedly.
>
>> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich
>> <henry.sinnreich@gmail.com <mailto:henry.sinnreich@gmail.com>> wrote:<= br> >>
>> =C2=A0 =C2=A0 +1
>> =C2=A0 =C2=A0 Maybe it would be useful for the proponents of this = and many other
>> =C2=A0 =C2=A0 =E2=80=9Cdesirable=E2=80=9D features to think from t= he perspective if they would
>> =C2=A0 =C2=A0 have to pay themselves for such developments and als= o make the
>> =C2=A0 =C2=A0 code freely available.
>> =C2=A0 =C2=A0 Cullen at least will make his code available.
>>
>
> See above. =C2=A0No one here wants to develop *another* reliable proto= col if
> we can avoid it. =C2=A0I understand your reluctance.
>
> The goal is to produce something that will meet the needs and get used= .
> If we don't meet the
> needs of the prospective users it's either an total waste of time = (if
> they ignore this effort and stick
> with Flash/plugins/etc) or we get all sorts of
> hack/bad/problematic/incompatible implementations
> by individual developers using the UDP (or RTP!) streams we open as a<= br> > base transport.
>
> To your point, another way this effort could fail is by biting off too=
> much or taking too long to
> converge, which is a real danger. =C2=A0That's one reason to lever= age
> existing protocols.
>

--
Emil Ivov, Ph.D. =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 67000 Strasbourg, Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 France
Jitsi
emcho@jitsi.org = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0PHONE: +33.1.77.62.43.30
http://jitsi.org =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FAX: = =C2=A0 +33.1.77.62.47.31

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



--
=C2=A0Product Manager=C2=A0|=C2= =A0sergel@google.com= =C2=A0|=C2=A0+46 732 01 22 32
Google Sweden AB | Kungsbron 2, SE= -111 22 Stockholm | Org. nr. 556656-6880=C2=A0

Apparently, this footer is required in Europe. Apologi= es. This email may be confidential or privileged. =C2=A0If you received thi= s communication by mistake, please don't forward it to anyone else,plea= se erase all copies and attachments, and please let me know that it went to= the wrong person. =C2=A0Thanks.
--000e0cd39bee2cbe0904a86f2f2b-- From emil@sip-communicator.org Tue Jul 19 10:21: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 C0B5021F84B6 for ; Tue, 19 Jul 2011 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqMRFmqEQH2q for ; Tue, 19 Jul 2011 10:21:34 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EABCC21F84A5 for ; Tue, 19 Jul 2011 10:21:33 -0700 (PDT) Received: by ewy19 with SMTP id 19so133896ewy.31 for ; Tue, 19 Jul 2011 10:21:32 -0700 (PDT) Received: by 10.204.152.205 with SMTP id h13mr2185509bkw.314.1311096091858; Tue, 19 Jul 2011 10:21:31 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id s16sm3310653fah.0.2011.07.19.10.21.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 10:21:30 -0700 (PDT) Message-ID: <4E25BD19.8070605@jitsi.org> Date: Tue, 19 Jul 2011 19:21:29 +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: Serge Lachapelle References: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 17:21:38 -0000 =D0=9D=D0=B0 19.07.11 19:09, Serge Lachapelle =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > There are many very established ways to transfer files from a web > browser. Dropbox, Google Docs, yousendit, mobileme, not counting the > media specific ways, such as Flickr, Spotify, Youtube, etc... All > offering great APIs for uploads, ACLs, etc... I am sorry, I should have been more specific when referring to the file transfer use case. What I meant was the possibility to let users send files directly to each other. All of the services you quote above have a public sharing or a backup aspect that requires files to be stored on a server. Sending files however, does not have this constraint so forcing the flow to go through a public relay is only unnecessary overhead. > Seems like re-inventing the wheel. Yeah ... but people do that every now and then ;) http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseu= dotcp.h Emil >=20 > /Serge >=20 > On Tue, Jul 19, 2011 at 19:02, Emil Ivov > wrote: >=20 >=20 >=20 > =D0=9D=D0=B0 19.07.11 18:37, Randell Jesup =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0: > > On 7/19/2011 11:58 AM, Justin Uberti wrote: > >> At Google, we created a TCP/ICE-UDP layering to solve this exact= > >> problem, using a user-mode implementation of TCP. It has some ro= ugh > >> edges, but has worked well in practice, and the code is freely > available. > > > > Right; pretty much what I'd anticipate >=20 > +1 most definitely. Again, I have yet to see a massively used RTC > application that doesn't have file transfer. So if this is not part= of > RTCWEB we will basically be asking developers to reimplement Pseudo= TCP > in JavaScript. >=20 > Emil >=20 > >, and working open code is good. > > SCTP as mentioned is a good choice too, and there exist (it appea= rs) > > SCTP-over-UDP implementations, which may ease things. Also the > > TCP-over-UDP library I pointed to. > > > >> We know people will want/need a reliable messaging mechanism for= p2p > >> data. While we can debate the details of this mechanism at lengt= h, I > >> suspect anything we choose will result in a better end-state tha= n if > >> we require application developers to implement their own. > > > > As is obvious from my other messages, I agree wholeheartedly. > > > >> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich > >> > >> wrote: > >> > >> +1 > >> Maybe it would be useful for the proponents of this and many= > other > >> =E2=80=9Cdesirable=E2=80=9D features to think from the persp= ective if they would > >> have to pay themselves for such developments and also make t= he > >> code freely available. > >> Cullen at least will make his code available. > >> > > > > See above. No one here wants to develop *another* reliable > protocol if > > we can avoid it. I understand your reluctance. > > > > The goal is to produce something that will meet the needs and get= > used. > > If we don't meet the > > needs of the prospective users it's either an total waste of time= (if > > they ignore this effort and stick > > with Flash/plugins/etc) or we get all sorts of > > hack/bad/problematic/incompatible implementations > > by individual developers using the UDP (or RTP!) streams we open = as a > > base transport. > > > > To your point, another way this effort could fail is by biting of= f too > > much or taking too long to > > converge, which is a real danger. That's one reason to leverage > > existing protocols. > > >=20 > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org =20 > PHONE: +33.1.77.62.43.30 > http://jitsi.org FAX: +33.1.77.62.47.31 > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 >=20 >=20 > --=20 > Serge Lachapelle | Product Manager | sergel@google.com > | +46 732 01 22 32 > > Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6= 880=20 >=20 > Apparently, this footer is required in Europe. Apologies. This email ma= y > be confidential or privileged. If you received this communication by > mistake, please don't forward it to anyone else,please erase all copies= > and attachments, and please let me know that it went to the wrong > person. Thanks. --=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 dzonatas@gmail.com Tue Jul 19 10:37: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 5C14D228012 for ; Tue, 19 Jul 2011 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=-0.766, 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 lIXyzVOTqDn1 for ; Tue, 19 Jul 2011 10:37:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78660228010 for ; Tue, 19 Jul 2011 10:37:03 -0700 (PDT) Received: by iwn39 with SMTP id 39so4640307iwn.31 for ; Tue, 19 Jul 2011 10:37:03 -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=RoSmFDkfP7KdUN1P/YHXaLlTiNIuZTnmNDfFNP4j2co=; b=P2vhgLWyRV8iel2zviCso3ROVOOS3EdNQAZRm22SS8LpveKXQNEuyMoM/ZUJItwJNn Lm8INK5+jQgdjX+tJsy2wNSh61F6z2kK5j8wiCBqTIX3WbW6xDPS3aML19WutNRSz2m0 jQCvcJvRIgUCNFflfznNBvNi50MbOqy8zPqdc= Received: by 10.42.76.72 with SMTP id d8mr983397ick.32.1311097022942; Tue, 19 Jul 2011 10:37:02 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id a9sm6500120icy.18.2011.07.19.10.37.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 10:37:02 -0700 (PDT) Message-ID: <4E25C0C4.9020607@gmail.com> Date: Tue, 19 Jul 2011 10:37:08 -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: 8bit Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 17:37:07 -0000 I suspect that TCP becomes the new semantic word for all browsers, as otherwise the movement of TCP to user-mode is already evident, and redundantly done (as suggested). TCP was the default way for developers to find stream-modes. Portability, like this, misrepresents needs beyond beginner layers. Despite change, UDP over HTTP over S/MIME appears proper and quick enough (i.e. "can harden"). Path of least resistance... SSRC already offers that bit of available change and overlap. The question for standard besides mux is only expect RTP first or use OPTIONS to downgrade HTTP. We've used 1xx to bypass HTTP/TCP layers before, so in fairness I don't think this is correct for rtcweb in regards to states. Implementation at software level seems futile if that concept is really that hard. We need non-encrypted unshrunken headers. Either that or 402 out of no-where simply bytes for energy alone... a security disaster. I usually stay quiet about that, yet please note that harvesters are this artificially intelligent now. =) On 07/19/2011 08:58 AM, Justin Uberti wrote: > At Google, we created a TCP/ICE-UDP layering to solve this exact > problem, using a user-mode implementation of TCP. It has some rough > edges, but has worked well in practice, and the code is freely available. > > We know people will want/need a reliable messaging mechanism for p2p > data. While we can debate the details of this mechanism at length, I > suspect anything we choose will result in a better end-state than if > we require application developers to implement their own. > > On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich > > wrote: > > +1 > Maybe it would be useful for the proponents of this and many other > “desirable” features to think from the perspective if they would > have to pay themselves for such developments and also make the > code freely available. > Cullen at least will make his code available. > > Thanks, Henry > > > > On 7/18/11 2:16 AM, "Serge Lachapelle" > wrote: > > Hi Cullen, > > I agree with your push back. > > Focus is very important. Audio and video already present a > huge challenge. (signalling, network, web developer friendly > API, security, browser integration...) > > Also, I think that there is a real risk in introducing > "duplicate" functionality in the browser as it may confuse web > developers. There is a lot going on in HTML5... > > In my mind, this is "version 2.0" stuff. > > /Serge > > > On Fri, Jul 15, 2011 at 17:51, Cullen Jennings > > wrote: > > > I'd like to push back on the reliable service. I've yet to > hear a use case for it that was real time. It's very hard > to do a reliable real time protocol and we have seen zero > proposal for this. For non real time data, just dump it in > dropbox of whatever your equivalent is and don't do it > peer to peer. Unless someone has a real need, and wants to > put forward a proposal, I don't see a need to focus energy > on this right now. I'd rather work on the thing everyone > agrees they do need which is the unreliable transfer. > > Cullen > > On Jul 13, 2011, at 8:57 , Magnus Westerlund wrote: > > > Hi, > > > > I have reviewed the input both the last 2 weeks and the > discussion back > > in April. > > > > I see a strong support but with at least 2 people > disagreeing to a basic > > p2p datagram functionality. The use cases are various and > some just > > state that they see it as important functionality to > provide to empower > > the web application. > > > > Based on this I declare a rough consensus on that we > should provide a > > non-media data service that is unreliable datagram > oriented directly > > between the peers. > > > > One of objections against this was lack of clear > requirements for what > > the service. The straw men requirements I included has > gotten some > > discussion. Mostly support for them, but it is clear to > me that we need > > to further develop them. I would recommend the proponents > for driving > > proposals towards meeting this functionality to further > discuss the > > requirements taking the input so far into consideration. > > > > When it comes to reliable data transfer between peers > there has been 4-5 > > that wanted the functionality, 2 additional that > explicitly stated they > > where okay with it. No additional that has stated against it. > > > > My interpretation is that we are close to having a rough > consensus for > > reliable data service, but we have so far seen no > proponent willing to > > suggest a solution for this. I would also note that a > solution is likely > > a functionality block that isn't dependent on more than the > > signaling/negotiation and the NAT traversal and thus can > be added a > > later stage or be worked on with a completion date > further into the > > future than other pieces already. > > > > So for reliable data I would recommend that someone takes > on the role of > > proponent and provides a draft with their perceived > requirements and a > > straw man proposal for how to solve these requirements so > we have > > something more tangible to discuss. > > > > Cheers > > > > Magnus > > > > On 2011-06-27 09:36, 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 > > > _______________________________________________ > 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 > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Tue Jul 19 11:51: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 92EF921F84FE for ; Tue, 19 Jul 2011 11:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.34 X-Spam-Level: X-Spam-Status: No, score=-4.34 tagged_above=-999 required=5 tests=[AWL=-0.741, 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 792Wtu9g6Yj5 for ; Tue, 19 Jul 2011 11:51:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8C5B21F8505 for ; Tue, 19 Jul 2011 11:51:11 -0700 (PDT) Received: by iwn39 with SMTP id 39so4702874iwn.31 for ; Tue, 19 Jul 2011 11:51:11 -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=xwnoV17zav16xvzh8sPileOCTI7hYBfzL+hp5QkPoCU=; b=LH/Wdkw0sNRx/MjBYfgT3PyjaSck6K0q7snXVNRojZrjE4Gbo2Wcz7EJLbyO0itHoO cBDiyORvl8ICIB7qf3ZWGbW6EikGAu2uBICzHxAUvWkIIg5CXAwcxAEo6oJzL8e4rQ1u zNSsDHigPQAWTYG4yO/Jpxgw7K7p+TnbGSDGQ= Received: by 10.42.149.72 with SMTP id u8mr8636229icv.253.1311101471155; Tue, 19 Jul 2011 11:51:11 -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 v16sm3784646ibe.0.2011.07.19.11.51.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 11:51:10 -0700 (PDT) Message-ID: <4E25D224.1000501@gmail.com> Date: Tue, 19 Jul 2011 11:51: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: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> <4E25BD19.8070605@jitsi.org> In-Reply-To: <4E25BD19.8070605@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 18:51:19 -0000 On 07/19/2011 10:21 AM, Emil Ivov wrote: > > >> Seems like re-inventing the wheel. >> > Yeah ... but people do that every now and then ;) > > http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.h > > Emil > Exactly why mainframes and clouds go hand and hand now: TCP is not sustainable. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Tue Jul 19 16:23: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 BDC4711E808B for ; Tue, 19 Jul 2011 16:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[AWL=-0.718, 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 5Nq1S1Mxf3NX for ; Tue, 19 Jul 2011 16:23:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16857228012 for ; Tue, 19 Jul 2011 16:23:11 -0700 (PDT) Received: by iwn39 with SMTP id 39so4887422iwn.31 for ; Tue, 19 Jul 2011 16:23:10 -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=YLxjZaZ2F9teI2qtn4HfYKtQBhHDfyV0Oe9o4H1ZU7M=; b=myNITnBWjABWk1eqs+GR1EvvV/OPu0rw7pNoO+f+WYBkwbDNSl4kEtk9LsqgcRBeMT ZQ7mRwN8PnvYpFVQ2rHnMQRPWTI7Td3dkoB5Uxklv90Ce7sOeyTfncwS4PGxZN5icmGN iUb71hTQRyZlyrrSAnaUDBjJge07U5Ld2HvG0= Received: by 10.231.112.150 with SMTP id w22mr7581012ibp.61.1311117790553; Tue, 19 Jul 2011 16:23:10 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id c2sm3912222ibd.22.2011.07.19.16.23.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 16:23:09 -0700 (PDT) Message-ID: <4E2611E4.2070300@gmail.com> Date: Tue, 19 Jul 2011 16:23: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: <4E25B2BA.8000004@jesup.org> In-Reply-To: <4E25B2BA.8000004@jesup.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Jul 2011 23:23:11 -0000 On 07/19/2011 09:37 AM, Randell Jesup wrote: > > To your point, another way this effort could fail is by biting off too > much or taking too long to > converge, which is a real danger. That's one reason to leverage > existing protocols. > Baby-safe is what I keep in mind every day. I'm not perfectr, neither is danger. Maybe some systems want optimizational values out of their protocols because they see no need for the consumption of computational energy. All the riches, what the world want at even given moment. Practical reality. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From fluffy@cisco.com Tue Jul 19 17:05: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 D61BC21F862F for ; Tue, 19 Jul 2011 17:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.087 X-Spam-Level: X-Spam-Status: No, score=-104.087 tagged_above=-999 required=5 tests=[AWL=-1.488, 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 tI9jYRDD8OfC for ; Tue, 19 Jul 2011 17:05:54 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E287321F8551 for ; Tue, 19 Jul 2011 17:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4741; q=dns/txt; s=iport; t=1311120354; x=1312329954; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=B8fLj+5eHGSqTKEKpr5xKm0OL2imZBXRDqzIKha5NC4=; b=MM91482KDum/M8Kb5xdPgJReQcfp+1osWkwuxLSHoWhnhp7l5/4rwA3U hf7OIqAA550Gubhw4o1EicB+bCtNIf5Sx2/MtujNB4CZEDpH+qpwwkoIz fHb92ndFNCaUetsWR+CBwQsT+sZsb755PEbpyW1rGJ3KovolBPdn6Gmgq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKgaJk6rRDoI/2dsb2JhbABUp1t3iHylTp5MAoVbXwSHVIsUkHo X-IronPort-AV: E=Sophos;i="4.67,231,1309737600"; d="scan'208";a="4538428" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2011 00:05:53 +0000 Received: from sjc-vpn5-1870.cisco.com (sjc-vpn5-1870.cisco.com [10.21.95.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6K05qqe031203; Wed, 20 Jul 2011 00:05:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4E259484.20509@ericsson.com> Date: Tue, 19 Jul 2011 17:05:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> References: <4E259484.20509@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 00:05:57 -0000 I'd like to see it that devices MUST support multiplexing and I'd = probably be in favor of also MUST support non multiplexed flows. The = multiplexing is a big advantage for any device that needs to deal with = NATs so I suspect many "legacy" devices would be moving to this even if = there was no need to deal with the browser like devices. I also think = that allowing this type of multiplexing will make firewall traversal = easier where a device can configure a firewall to open just one = specified port and use it for RTP.=20 The number places where RSVP is usable does not really overlap with = places one uses ICE so it does not bother me in the slightest that RSVP = won't work with this. It's pretty easy to imagine an extension to RSVP = to support reservations based on SSRC inside the flow. Diff Serv based = qos will work which is what more commonly used in situations where we = are using NATs.=20 The primary reason I want multiplexing is the time to set up all the ICE = connections. The fact of the matter is that NATs limit how quickly you = can create new flows. If all you need is something simple with just 2 = flows, one for audio and one for video, this is workable. But as soon as = you move to trying to have a transition strategy from V4 to V6 and = multiple person video or even just multi screen video, the user = experience goes downhill rapidly.=20 Much of the IETF thinking around ICE was done on the assumption that ICE = could be done before ringing started or during ringing but the = deployments I am seeing are moving more towards not doing ICE until = after a call is answered. There are many reasons for this but one of = them is that if Alice calls Bob, and Bob is on a mobile internet device, = you don't want to reveal Bob's location to Alice before Bob even decides = to answer the call. Given an IP address more or less reveals location = these days that a bit of issues to do ICE before answering. This puts = more pressure on being able to do ICE quickly for a good user = experience.=20 Cullen On Jul 19, 2011, at 7:28 , Magnus Westerlund wrote: > Hi, >=20 > This email is as an individual contributor. >=20 > I want to get started on the discussion of the Multiplexing of the > various protocols over single lower layer transport flow, such as a = UDP > flow. I will attempt to split up the questions into different emails. >=20 > The first question I think is reasonably easy to get answered, but I > think it is time we determine if my belief in the answer is correct or = not. >=20 > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: >=20 > a) MUST be sent as Individual flows for each component. >=20 > b) MUST be multiplexed into a single transport flow. >=20 > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. >=20 > I would love if people can indicate their choice or preferences. >=20 > I personally prefer A as it it is simplest in all aspect except the = NAT > traversal. > - It allows for flow based QoS. > - It is the what the implementation that exist mostly do > - Signaling protocols that exist support it, no extra functionality > - People are used to the concept > - It minimizes the difference to legacy. >=20 > Thus it is the quickest road to define something with the least formal > push back and concern over maturity of any solution. >=20 > The downside with B and C is that we do have to solve the multiplexing > and get an agreement that gets through all the hurdles. >=20 > Of these two opens I do prefer C. Although it results in the extra > complexities of having both alternatives, it will give us both a > fallback, flow based QoS and better legacy support. >=20 > Now it is your time to make your opinion heard! >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dzonatas@gmail.com Tue Jul 19 17:33: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 ECDE821F84FB for ; Tue, 19 Jul 2011 17:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFadaH-acxhY for ; Tue, 19 Jul 2011 17:33:30 -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 AECD621F84F9 for ; Tue, 19 Jul 2011 17:33:30 -0700 (PDT) Received: by iye7 with SMTP id 7so4943610iye.31 for ; Tue, 19 Jul 2011 17:33:30 -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=w0fG6Q8tG39kvyo0bQ4z/80mUzZ50O3Nd26N+Ny6meg=; b=cGHCdUC4C+eqk+V7NrJXI/n7t9DqBNCa73M8HQ0ubuWZQneMN+7fck1hVnNV0NQ2FQ Z4sI4KZiMPfkOJMZW1V0X1U8Lxxq89cbjxSPlcYZTeVoLbZxF0ugko8R5hqbuflAGSvf FODaTb3BxjQdsvaT5S3xyLQHbrDKfy7h3BeBo= Received: by 10.231.117.79 with SMTP id p15mr7760646ibq.29.1311122010208; Tue, 19 Jul 2011 17:33:30 -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 er13sm1739368ibb.2.2011.07.19.17.33.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 17:33:29 -0700 (PDT) Message-ID: <4E262260.3000706@gmail.com> Date: Tue, 19 Jul 2011 17:33: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: <4E259484.20509@ericsson.com> <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> In-Reply-To: <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 00:33:36 -0000 On 07/19/2011 05:05 PM, Cullen Jennings wrote: > I'd like to see it that devices MUST support multiplexing and I'd probably be in favor of also MUST support non multiplexed flows. The multiplexing is a big advantage for any device that needs to deal with NATs so I suspect many "legacy" devices would be moving to this even if there was no need to deal with the browser like devices. I also think that allowing this type of multiplexing will make firewall traversal easier where a device can configure a firewall to open just one specified port and use it for RTP. > > The number places where RSVP is usable does not really overlap with places one uses ICE so it does not bother me in the slightest that RSVP won't work with this. It's pretty easy to imagine an extension to RSVP to support reservations based on SSRC inside the flow. Diff Serv based qos will work which is what more commonly used in situations where we are using NATs. > > The primary reason I want multiplexing is the time to set up all the ICE connections. The fact of the matter is that NATs limit how quickly you can create new flows. If all you need is something simple with just 2 flows, one for audio and one for video, this is workable. But as soon as you move to trying to have a transition strategy from V4 to V6 and multiple person video or even just multi screen video, the user experience goes downhill rapidly. > V9 is quick, yet the impression gives the vaporware experience because it is solid state less-than-best solution. For real-time, probably best to just expose if V4 is fast or slow, and we can assume the opposite about V6. > Much of the IETF thinking around ICE was done on the assumption that ICE could be done before ringing started or during ringing but the deployments I am seeing are moving more towards not doing ICE until after a call is answered. There are many reasons for this but one of them is that if Alice calls Bob, and Bob is on a mobile internet device, you don't want to reveal Bob's location to Alice before Bob even decides to answer the call. Given an IP address more or less reveals location these days that a bit of issues to do ICE before answering. This puts more pressure on being able to do ICE quickly for a good user experience. > V9 crystallization technique simply wants to know if anything changed while 'do ICE quickly' is done. Consider that quality of service for dynamic-compilers, especially those that need what weight of energy before any real-time process is done. If we know the process and data does not contain any location, sex, or age, then pressure relief exists with that process and data. I see three flows for ICE, not 2, and one separate individual flow. Safe to multiplex those flows? Not by these standards in this WG. > Cullen > > On Jul 19, 2011, at 7:28 , Magnus Westerlund wrote: > > >> Hi, >> >> This email is as an individual contributor. >> >> I want to get started on the discussion of the Multiplexing of the >> various protocols over single lower layer transport flow, such as a UDP >> flow. I will attempt to split up the questions into different emails. >> >> The first question I think is reasonably easy to get answered, but I >> think it is time we determine if my belief in the answer is correct or not. >> >> The traffic between two RTCWEB peers from the various components, such >> as RTP sessions, datagram service: >> >> a) MUST be sent as Individual flows for each component. >> >> b) MUST be multiplexed into a single transport flow. >> >> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB >> peer MUST be able to send them as individual flows. >> >> I would love if people can indicate their choice or preferences. >> >> I personally prefer A as it it is simplest in all aspect except the NAT >> traversal. >> - It allows for flow based QoS. >> - It is the what the implementation that exist mostly do >> - Signaling protocols that exist support it, no extra functionality >> - People are used to the concept >> - It minimizes the difference to legacy. >> >> Thus it is the quickest road to define something with the least formal >> push back and concern over maturity of any solution. >> >> The downside with B and C is that we do have to solve the multiplexing >> and get an agreement that gets through all the hurdles. >> >> Of these two opens I do prefer C. Although it results in the extra >> complexities of having both alternatives, it will give us both a >> fallback, flow based QoS and better legacy support. >> >> Now it is your time to make your opinion heard! >> >> 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 >> > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > 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 fluffy@cisco.com Tue Jul 19 17:43: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 11FAD21F85E2 for ; Tue, 19 Jul 2011 17:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.054 X-Spam-Level: X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, 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 59JdUnPsywNY for ; Tue, 19 Jul 2011 17:43:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5DF21F85B1 for ; Tue, 19 Jul 2011 17:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5126; q=dns/txt; s=iport; t=1311122619; x=1312332219; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ygHJCXzFogQdk+pTW/INaJGtcePi/uoopo6cNOMcDHE=; b=HUvzF9TyWhqstqKURwB/PnaDjNj3bYtBgMbmBV3Ep7u6a11DhVtZRA83 /UyZSAKl8DV4XDgrpCviuNU2UOCJDi43GFsR7ncVxsSxtMURMwUgmUvxv Oj1HzXy8FPnt7UoV0ocmsY3ld2F96+2y8ksOZf7hUxbaYGWKI6gqOHJi7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABMkJk6rRDoG/2dsb2JhbABGDqdbd4h8pWKeTIMjgjpfBIdUixSFBIt2 X-IronPort-AV: E=Sophos;i="4.67,231,1309737600"; d="scan'208";a="4545046" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2011 00:43:38 +0000 Received: from [10.21.86.37] ([10.21.86.37]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6K0hbCN028506; Wed, 20 Jul 2011 00:43:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E259EAD.3060505@ericsson.com> Date: Tue, 19 Jul 2011 17:43:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E259EAD.3060505@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 00:43:43 -0000 inline ... On Jul 19, 2011, at 8:11 , Magnus Westerlund wrote: > WG, >=20 > As individual contributor. >=20 > I would recommend that people read both > = https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/?include_te= xt=3D1 > and > = https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_t= ext=3D1 > before getting into this debate. >=20 > Assuming that the consensus of "To multiplex or not!" thread is either > of the options requiring multiplexing we get to the question of how to > do the multiplexing. >=20 > Lets start with a very fundamental question: >=20 > Explicit vs Implicit multiplexing >=20 > So the explicit is when something in the received packets has the > explicit purpose to identifies a context that resolves the protocol, = the > session context etc. >=20 > Implicit is when we have no such explicit field, instead we have to = rely > on that investigating values of particular bits in the payload of the > packet. For example trying to identify RTP based on the first byte of > the RTP header where the version two bits shall be 10b. >=20 > I am strongly arguing against implicit identifying the protocol for = the > following reasons. >=20 > 1. We have 4 or more protocols (The possible set of protocols include: > STUN, RTP/RTCP, Datagram, and DTLS-SRTP. There is likely future > extensions, like reliable protocol) that needs to be identified and > demultiplexed. A single extension in one of these protocols can cause > the whole house of cards to come tumbling down. Uh, we already demux STUN, RTP/RTC, DTLS-SRTP based on first byte and = this is no big deal and is sort of water under the bridge at this point. = But this first byte multiplex issues is a red herring to this topic, = what happens with the demux of these protocols does not really have much = to do with how to demux the different RTP sessions.=20 >=20 > 2. It will require one to find an RTP internal session multiplexing > mechanism. This is likely not easy or causes a fork of RTP into two > non-compatible versions. In addition such a mechanism needs defining > which takes time, likely substantial time as there is quite a lot of = RTP > mechanisms to consider. A bunch of us our proposing SSRC. We not seeing any problems with it. I = rather having this discussion be concrete around the specific proposal = on the table and not just some abstract it might be hard to find = something.=20 >=20 > 3. We likely need a multiplexing layer anyway if we want a fall back > over WebSockets or HTTP. Not really - I think this is best done by making another TURN like = protocol that is compatible uses WebSockets or HTTP as the underling = transport. An architecture like this means that that protocol is = selected unilateral by the endpoint and used to get through that = endpoints firewalls. Both clients don't have to agree to do the same = thing - just like If I am using a TURN and you are not, we can still = have a call. Avoid a bilateral solution where possible make it much = easier to roll out.=20 >=20 > Thus we see this a very fragile mechanism that creates additional work > overhead and large uncertainties in when it would be available. This all sounds sort of doom and gloom but lets talk about real = problems.=20 >=20 > We have in our draft: > https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ = looked > at two possible suggestions for explicit multiplexing. Either a thin > shim layer primarily consisting of a identifier that through = negotiation > is bound to a context, like an particular RTP session or a datagram > channel. The problem with this is that if you are talking to a device that does = not support this you forever have to go through some intermediary = gateway that strips the byte. Just like turns servers, this reduces the = user experience by adding latency and jitter and is expensive to run due = to the bandwidth required.=20 >=20 > The other alternative we considered was using DCCP over UDP for RTP = and > datagram. That way we got a complete port space for multiplexing > different purposes for flows. We also got a transport framework with = its > own negotiation, congestion control, a several other features. This has the same problem as above with the added problem of I am not = aware of a good (meaning widely tested) DCCP implementation in user land = and to be deployable this pretty much needs to be all user land.=20 >=20 > We invite people to consider these proposals or suggest better > alternatives of explicit multiplexing. But I hope we can avoid a = serious > mistake and select implicit multiplexing. I'd like people to start talking about what the actual serious mistakes = of implicit multiplexing as specified in the SSRC proposal are. Ok, Have = I thrown the gauntlet down enough :-) Really, I'm just not getting what = the problems are - if I understood the problems, I might have a = different view point on this.=20 Cullen = From fluffy@cisco.com Tue Jul 19 18:13: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 0DBB711E8095 for ; Tue, 19 Jul 2011 18:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.023 X-Spam-Level: X-Spam-Status: No, score=-104.023 tagged_above=-999 required=5 tests=[AWL=-1.424, 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 ZXbp4-1Dg657 for ; Tue, 19 Jul 2011 18:13:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0D611E808B for ; Tue, 19 Jul 2011 18:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1085; q=dns/txt; s=iport; t=1311124432; x=1312334032; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=itZYBMtdw1ft+LeH7C8b6CPjFCNw+w7ou/4phnxGEus=; b=UsLUpeT/r/8Fs/Qc3j/QzxBE/bHkec/hBuL+46kCwq9TK/IL9Y7LX/Jx J1onjOkYC9q4XtSzY9C9U9b1EY4LSCu89kJJ5hCHa9Ij4g9mUBwW+f6p3 TZYlttGqBDm1onG5LhONCCS6kRJGERWETeQ6MTy61vNqKTuYXF9ZcTTJM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHkrJk6rRDoI/2dsb2JhbABUp1t3iHylY55IhV1fBIdUixSFBIt2 X-IronPort-AV: E=Sophos;i="4.67,231,1309737600"; d="scan'208";a="4548887" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jul 2011 01:13:51 +0000 Received: from [10.21.86.37] ([10.21.86.37]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6K1DoZj010091; Wed, 20 Jul 2011 01:13:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E24AF7C.4080604@jesup.org> Date: Tue, 19 Jul 2011 18:13:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 01:13:53 -0000 On Jul 18, 2011, at 15:11 , Randell Jesup wrote: > All that said - yes, there are complexity issues to consider, which = was why I was suggesting leveraging > an existing tunneled protocol like SCTP or even TCP-over-UDP. I agree with bunch of what you are saying but the previous several times = I've seen the use SCTP over UDP conversation, it usually ends about the = point the we ask for a user land implementation. Whatever we do more or = less has to be user land or already exist in the OS that people run = browsers on.=20 If someone has a user land implementation of SCTP or TCP, I imagine that = might change the outcome a bit from previous times. I have not looked at = the TCP over UPD library Justin mentioned but, at casual glance, I = noticed is around 400 lines of code which is very small, which is cool. = But given the lines of code in say the BSD TCP stack, it does make me = wonder what's missing. That said, I don't think we need something with = the perforce of the BSD TCP stack as long as what is there is TCP = friendly and robust.=20 From fluffy@cisco.com Tue Jul 19 18:21: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 B4DB611E809A for ; Tue, 19 Jul 2011 18:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.994 X-Spam-Level: X-Spam-Status: No, score=-103.994 tagged_above=-999 required=5 tests=[AWL=-1.395, 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 7d5S7AqIdwSP for ; Tue, 19 Jul 2011 18:21:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id F025C11E8098 for ; Tue, 19 Jul 2011 18:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1627; q=dns/txt; s=iport; t=1311124862; x=1312334462; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=95QzZghETRLB2OEkkCWFt5UfMOVPdgZvchH53dUUF0k=; b=YotADSPNoK4bcPorJ8s/KuE6RJ7MeIXD2SkEtl7x/DSNuVcgngMFkkc/ H1BkilCvslKHArYMEAPqsEKWc3qxEdtjL1EPzEpFM5Ip0Y1nS0C15/V+y vKdHWXekhQXyinwDZ4y4ybvJcm8V3GJnNZS4Z6hzOGeqELNaqpSPIye7Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOAsJk6rRDoJ/2dsb2JhbABUp1t3iHymBZ5GhV1fBIdUixSFBIt2 X-IronPort-AV: E=Sophos;i="4.67,231,1309737600"; d="scan'208";a="4550224" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jul 2011 01:21:01 +0000 Received: from [10.21.86.37] ([10.21.86.37]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6K1L0oU013337; Wed, 20 Jul 2011 01:21:00 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <930E44D5-D72A-4F60-B28B-9DD8F3B49BAC@phonefromhere.com> Date: Tue, 19 Jul 2011 18:20:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <67C8DD4F-7DA7-4D28-B4E3-845FFD1B7273@cisco.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <930E44D5-D72A-4F60-B28B-9DD8F3B49BAC@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 01:21:02 -0000 On Jul 18, 2011, at 2:28 , Tim Panton wrote: > I understand the pushback on supporting reliable datagrams from = Cullen, Silvia, Serge and others. >=20 > I'm pushing for it simply because I've had it in our browser rt-audio = component, and used it extensively. > Without the ability to transport reliable datagrams in 'near realtime' = the projects=20 > we have done would have been far less compelling for the user. The = Datagrams are often the=20 > key to providing a special user experience, beyond conventional = telephony. If we don't provide this, > we risk producing the tools for a round of browser based deskphone = emulators. We can do better. >=20 > As an example, the demo I show in this blog would have been much = harder and less responsive without > realtime data coming back up the RFC 5456 channel : >=20 > = https://babyis60.wordpress.com/2009/10/24/my-astricon-googlewave-ibook-sky= pe-demo/ >=20 cool - I had not seen that before=20 > So I guess I am asking: Are we aiming for browser based deskphone = emulators or a new sort of > rich media experience for browser users?=20 Hey, I just want my black phone :-) Ok, I'm sold that a reliable data = mechanisms be used and if people build their own, many of them will be = bad.=20 >=20 > I know what I want. >=20 > Tim. >=20 >=20 >=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 stefan.lk.hakansson@ericsson.com Tue Jul 19 23:36: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 16BFF21F8453 for ; Tue, 19 Jul 2011 23:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.059, 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 IIFtsGY+I8Ff for ; Tue, 19 Jul 2011 23:36:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 592AC21F8B2F for ; Tue, 19 Jul 2011 23:36:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-54-4e26775519b5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 01.6E.09774.557762E4; Wed, 20 Jul 2011 08:36:05 +0200 (CEST) Received: from [150.132.141.68] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Jul 2011 08:36:04 +0200 Message-ID: <4E267750.50101@ericsson.com> Date: Wed, 20 Jul 2011 08:36:00 +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 References: <4E259484.20509@ericsson.com> <4E25B37D.9080404@skype.net> In-Reply-To: <4E25B37D.9080404@skype.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 06:36:07 -0000 On 2011-07-19 18:40, Matthew Kaufman wrote: > On 7/19/2011 7:28 AM, Magnus Westerlund wrote: >> a) MUST be sent as Individual flows for each component. >> >> b) MUST be multiplexed into a single transport flow. >> >> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB >> peer MUST be able to send them as individual flows. >> >> I would love if people can indicate their choice or preferences. > > C. But I'm not sure that the "must" needs to be anything more than "you > just make two peer connection objects, one for each". (In other words, > any API that allows for multiplexing almost certainly allows for > non-multiplexing)... this assumes that the multiplexing is implicit, of > course. With explicit multiplexing it is even harder... the API needs to > support turning on and off the multiplexing shim as well, something I'm > not in favor of. The APIs being discussed now deal with "MediaStreams" that contain both audio (zero to many) and video (zero to many). This has been found to be a reasonable level of abstraction for the web app developer. The web app developer would have difficulties to understand how many RTP streams a MediaStream would generate. So it is not so simple to deal with this by creating several peer conn objects. Besides, it has been discussed that A/V synch should be maintained within a MediaStream. This is something you would lose if you split it up and transport it using separate peer conn objects. Stefan > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Wed Jul 20 00:44: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 529A321F8A71 for ; Wed, 20 Jul 2011 00:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 pC0iq1YTH1MR for ; Wed, 20 Jul 2011 00:44:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 814B721F8A56 for ; Wed, 20 Jul 2011 00:44:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-cd-4e2687424853 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 61.9F.20773.247862E4; Wed, 20 Jul 2011 09:44:02 +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, 20 Jul 2011 09:44:02 +0200 Message-ID: <4E268741.408@ericsson.com> Date: Wed, 20 Jul 2011 09:44:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Matthew Kaufman References: <4E259484.20509@ericsson.com> <4E25B37D.9080404@skype.net> In-Reply-To: <4E25B37D.9080404@skype.net> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 07:44:04 -0000 On 2011-07-19 18:40, Matthew Kaufman wrote: > On 7/19/2011 7:28 AM, Magnus Westerlund wrote: >> a) MUST be sent as Individual flows for each component. >> >> b) MUST be multiplexed into a single transport flow. >> >> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB >> peer MUST be able to send them as individual flows. >> >> I would love if people can indicate their choice or preferences. > > C. But I'm not sure that the "must" needs to be anything more than "you > just make two peer connection objects, one for each". (In other words, > any API that allows for multiplexing almost certainly allows for > non-multiplexing)... this assumes that the multiplexing is implicit, of > course. With explicit multiplexing it is even harder... the API needs to > support turning on and off the multiplexing shim as well, something I'm > not in favor of. I am far from certain that it is that simple. First of all, two different RTP sessions, one for audio and one for video that goes over different UDP flows, still has an association, for example the used CNAME to indicate that these flows can be synchronized and are from the same end-point. If the API definition is such that a stream object implies a synchronization context when sending, then moving the streams to two different objects fails to have that separation in semantics. I think the MUST is important in the aspect that it is a clear agreement to get this to work. How, that is for us to work out together with W3C. Thus, I wouldn't rule out that actual need for some option that you can set to get non-multiplexed. It might be conceptually much simpler for a developer than to actually understand how you need to spit streams and then add additional binding properties to these media streams which could be an alternative design. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gonzalo.camarillo@ericsson.com Wed Jul 20 00:52: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 A0A5621F84BF for ; Wed, 20 Jul 2011 00:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 tHKlC4Fx1av2 for ; Wed, 20 Jul 2011 00:52:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 282F421F847C for ; Wed, 20 Jul 2011 00:51:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-2f-4e2688f01eb2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 00.A0.20773.0F8862E4; Wed, 20 Jul 2011 09:51:12 +0200 (CEST) Received: from [131.160.126.141] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Jul 2011 09:51:12 +0200 Message-ID: <4E2688F0.8090403@ericsson.com> Date: Wed, 20 Jul 2011 10:51:12 +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: rtcweb@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] RTP architecture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 07:52:27 -0000 Folks, as you know if you are following this WG, there have been discussions on multiplexing RTP sessions and how that would affect legacy RTP systems. Those discussions have not concluded yet. Nevertheless, note that changes to the RTP architecture and other fundamental changes to RTP (should you require any) would need to be made in AVTCORE, which is where the RTP expertise is. The RTCWeb charter says the following: > If there is identification of missing protocols or > functionalities, such work can be requested to be done in another > working group with a suitable charter or by requests for chartering it > in this WG or another WG Cheers, Gonzalo From stefan.lk.hakansson@ericsson.com Wed Jul 20 02:37: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 A6DD221F861A for ; Wed, 20 Jul 2011 02:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.053, 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 72S7239BBNBn for ; Wed, 20 Jul 2011 02:37: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 16D3621F85B8 for ; Wed, 20 Jul 2011 02:37:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f7-4e26a1bceed4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B9.AA.09774.CB1A62E4; Wed, 20 Jul 2011 11:37:00 +0200 (CEST) Received: from [150.132.141.68] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Jul 2011 11:37:00 +0200 Message-ID: <4E26A1BB.8020403@ericsson.com> Date: Wed, 20 Jul 2011 11:36:59 +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 References: <4E259484.20509@ericsson.com> In-Reply-To: <4E259484.20509@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 09:37:07 -0000 FWIW I'm in camp A (but of course C is fine as well). Flow based QoS is part of modern cellular networks, and I would like rtcweb to work well on them (our experience is also that when the throughput is reduced you prefer the video to be degraded rather than having the audio being chopped - so you would need them to be individual flows). Stefan On 2011-07-19 16:28, Magnus Westerlund wrote: > Hi, > > This email is as an individual contributor. > > I want to get started on the discussion of the Multiplexing of the > various protocols over single lower layer transport flow, such as a UDP > flow. I will attempt to split up the questions into different emails. > > The first question I think is reasonably easy to get answered, but I > think it is time we determine if my belief in the answer is correct or not. > > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: > > a) MUST be sent as Individual flows for each component. > > b) MUST be multiplexed into a single transport flow. > > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. > > I would love if people can indicate their choice or preferences. > > I personally prefer A as it it is simplest in all aspect except the NAT > traversal. > - It allows for flow based QoS. > - It is the what the implementation that exist mostly do > - Signaling protocols that exist support it, no extra functionality > - People are used to the concept > - It minimizes the difference to legacy. > > Thus it is the quickest road to define something with the least formal > push back and concern over maturity of any solution. > > The downside with B and C is that we do have to solve the multiplexing > and get an agreement that gets through all the hurdles. > > Of these two opens I do prefer C. Although it results in the extra > complexities of having both alternatives, it will give us both a > fallback, flow based QoS and better legacy support. > > Now it is your time to make your opinion heard! > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Wed Jul 20 02:43: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 8B58A21F86E8 for ; Wed, 20 Jul 2011 02:43:54 -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=-0.252, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 O+I1GyZmZ2BE for ; Wed, 20 Jul 2011 02:43:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 516B621F86E9 for ; Wed, 20 Jul 2011 02:43:50 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1f-4e26a3557998 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.13.20773.553A62E4; Wed, 20 Jul 2011 11:43:49 +0200 (CEST) Received: from [150.132.141.68] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Jul 2011 11:43:48 +0200 Message-ID: <4E26A354.2020306@ericsson.com> Date: Wed, 20 Jul 2011 11:43:48 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= 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: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 09:43:54 -0000 On 2011-07-19 19:09, Serge Lachapelle wrote: > There are many very established ways to transfer files from a web > browser. Dropbox, Google Docs, yousendit, mobileme, not counting the > media specific ways, such as Flickr, Spotify, Youtube, etc... All > offering great APIs for uploads, ACLs, etc... > > Seems like re-inventing the wheel. I tend to agree. What the data channel of rtcweb could provide is shorter latency - but to me that does not seem relevant for a file transfer. > > /Serge > > On Tue, Jul 19, 2011 at 19:02, Emil Ivov > wrote: > > > > На 19.07.11 18:37, Randell Jesup написа: > > On 7/19/2011 11:58 AM, Justin Uberti wrote: > >> At Google, we created a TCP/ICE-UDP layering to solve this exact > >> problem, using a user-mode implementation of TCP. It has some rough > >> edges, but has worked well in practice, and the code is freely > available. > > > > Right; pretty much what I'd anticipate > > +1 most definitely. Again, I have yet to see a massively used RTC > application that doesn't have file transfer. So if this is not part of > RTCWEB we will basically be asking developers to reimplement Pseudo TCP > in JavaScript. > > Emil > > >, and working open code is good. > > SCTP as mentioned is a good choice too, and there exist (it appears) > > SCTP-over-UDP implementations, which may ease things. Also the > > TCP-over-UDP library I pointed to. > > > >> We know people will want/need a reliable messaging mechanism for p2p > >> data. While we can debate the details of this mechanism at length, I > >> suspect anything we choose will result in a better end-state than if > >> we require application developers to implement their own. > > > > As is obvious from my other messages, I agree wholeheartedly. > > > >> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich > >> > >> wrote: > >> > >> +1 > >> Maybe it would be useful for the proponents of this and many > other > >> “desirable” features to think from the perspective if they would > >> have to pay themselves for such developments and also make the > >> code freely available. > >> Cullen at least will make his code available. > >> > > > > See above. No one here wants to develop *another* reliable > protocol if > > we can avoid it. I understand your reluctance. > > > > The goal is to produce something that will meet the needs and get > used. > > If we don't meet the > > needs of the prospective users it's either an total waste of time (if > > they ignore this effort and stick > > with Flash/plugins/etc) or we get all sorts of > > hack/bad/problematic/incompatible implementations > > by individual developers using the UDP (or RTP!) streams we open as a > > base transport. > > > > To your point, another way this effort could fail is by biting > off too > > much or taking too long to > > converge, which is a real danger. That's one reason to leverage > > existing protocols. > > > > -- > 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 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Serge Lachapelle | Product Manager |sergel@google.com > |+46 732 01 22 32 > > Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880 > > Apparently, this footer is required in Europe. Apologies. This email may > be confidential or privileged. If you received this communication by > mistake, please don't forward it to anyone else,please erase all copies > and attachments, and please let me know that it went to the wrong > person. Thanks. From harald@alvestrand.no Wed Jul 20 02:49: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 1C00821F87ED for ; Wed, 20 Jul 2011 02:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 5XMyzcUjAVHH for ; Wed, 20 Jul 2011 02:49:24 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3FD21F8788 for ; Wed, 20 Jul 2011 02:49:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C686539E0FE; Wed, 20 Jul 2011 11:48:17 +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 8xLKA3JqazJT; Wed, 20 Jul 2011 11:48:14 +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 046D039E072; Wed, 20 Jul 2011 11:48:14 +0200 (CEST) Message-ID: <4E26A49F.1070700@alvestrand.no> Date: Wed, 20 Jul 2011 11:49:19 +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: Magnus Westerlund References: <4E259484.20509@ericsson.com> In-Reply-To: <4E259484.20509@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 09:49:25 -0000 Magnus, I cannot parse your list of choices. In the case where you have Sender A Recipient B Three video streams going from A to B Three audio streams going from A to B One video stream going from B to A One audio stream going from B to A with the application not requiring the network to treat the packets any=20 differently, and with the application using the CNAME mechanism to match = audio streams with corresponding video streams it is completely unclear to me whether your choice A) requires 8=20 transport flows, 4 transport flows or 2 transport flows, and it is=20 completely unclear to me what C) actually means. (I assume "transport=20 flow" =3D "RTP sessions" here) Please - can you clarify what your question is intended to mean? Harald On 07/19/11 16:28, Magnus Westerlund wrote: > Hi, > > This email is as an individual contributor. > > I want to get started on the discussion of the Multiplexing of the > various protocols over single lower layer transport flow, such as a UDP= > flow. I will attempt to split up the questions into different emails. > > The first question I think is reasonably easy to get answered, but I > think it is time we determine if my belief in the answer is correct or = not. > > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: > > a) MUST be sent as Individual flows for each component. > > b) MUST be multiplexed into a single transport flow. > > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. > > I would love if people can indicate their choice or preferences. > > I personally prefer A as it it is simplest in all aspect except the NAT= > traversal. > - It allows for flow based QoS. > - It is the what the implementation that exist mostly do > - Signaling protocols that exist support it, no extra functionality > - People are used to the concept > - It minimizes the difference to legacy. > > Thus it is the quickest road to define something with the least formal > push back and concern over maturity of any solution. > > The downside with B and C is that we do have to solve the multiplexing > and get an agreement that gets through all the hurdles. > > Of these two opens I do prefer C. Although it results in the extra > complexities of having both alternatives, it will give us both a > fallback, flow based QoS and better legacy support. > > Now it is your time to make your opinion heard! > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From emil@sip-communicator.org Wed Jul 20 04:08: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 C932D21F8A66 for ; Wed, 20 Jul 2011 04:08:59 -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 yHwsEK1Ykb8D for ; Wed, 20 Jul 2011 04:08:54 -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 3DC9821F86A1 for ; Wed, 20 Jul 2011 04:08:54 -0700 (PDT) Received: by wyj26 with SMTP id 26so94996wyj.31 for ; Wed, 20 Jul 2011 04:08:53 -0700 (PDT) Received: by 10.216.79.5 with SMTP id h5mr7233021wee.110.1311160132767; Wed, 20 Jul 2011 04:08:52 -0700 (PDT) Received: from porcinet.u-strasbg.fr ([2001:660:4701:1001:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id m38sm85405weq.21.2011.07.20.04.08.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 04:08:51 -0700 (PDT) Message-ID: <4E26B742.6050606@jitsi.org> Date: Wed, 20 Jul 2011 13:08:50 +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: Cullen Jennings References: <4E259484.20509@ericsson.com> <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> In-Reply-To: <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 11:08:59 -0000 =D0=9D=D0=B0 20.07.11 02:05, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > I'd like to see it that devices MUST support multiplexing and I'd > probably be in favor of also MUST support non multiplexed flows. The > multiplexing is a big advantage for any device that needs to deal > with NATs so I suspect many "legacy" devices would be moving to this > even if there was no need to deal with the browser like devices. I > also think that allowing this type of multiplexing will make firewall > traversal easier where a device can configure a firewall to open just > one specified port and use it for RTP. I don't really agree with this part. Devices would still need to handle candidates that come from STUN, TURN, UPnP, host IPv4, host IPv6, and potentially VPN, MIPv6 and other tunnelling mechanisms. Whether or not this only happens for a single component/stream doesn't really simplify code does it? According to my personal experience with our work on ice4j.org, managing multiple checklists was far less resource consuming than implementing TURN tunnels and persmissions, STUN multiplexing, synchronisation and even getting pacing right. > The primary reason I want multiplexing is the time to set up all the > ICE connections. The fact of the matter is that NATs limit how > quickly you can create new flows. If all you need is something simple > with just 2 flows, one for audio and one for video, this is workable. > But as soon as you move to trying to have a transition strategy from > V4 to V6 and multiple person video or even just multi screen video, > the user experience goes downhill rapidly. I agree more with this argument, although freezing candidates significantly brings down the overhead incurred by having multiple streams and components and I am not sure that the actual win here would be good enough to pay for implementing multiplexing and for breaking interoperability with those that don't have it. > Much of the IETF thinking around ICE was done on the assumption that > ICE could be done before ringing started or during ringing but the > deployments I am seeing are moving more towards not doing ICE until > after a call is answered. There are many reasons for this but one of > them is that if Alice calls Bob, and Bob is on a mobile internet > device, you don't want to reveal Bob's location to Alice before Bob > even decides to answer the call. Given an IP address more or less > reveals location these days that a bit of issues to do ICE before > answering. This puts more pressure on being able to do ICE quickly > for a good user experience. Agreed, but is multiplexing the only way of bringing the time down? The XMPP crowd for example has been using a mechanism that allows candidates to be sent as they become available rather than wait for all harvesting to complete. Maybe this is worth exploring and integrating in the official ICE (although I don't see how it would work with SIP). Cheers, Emil >=20 > Cullen >=20 > On Jul 19, 2011, at 7:28 , Magnus Westerlund wrote: >=20 >> Hi, >>=20 >> This email is as an individual contributor. >>=20 >> I want to get started on the discussion of the Multiplexing of the=20 >> various protocols over single lower layer transport flow, such as a >> UDP flow. I will attempt to split up the questions into different >> emails. >>=20 >> The first question I think is reasonably easy to get answered, but >> I think it is time we determine if my belief in the answer is >> correct or not. >>=20 >> The traffic between two RTCWEB peers from the various components, >> such as RTP sessions, datagram service: >>=20 >> a) MUST be sent as Individual flows for each component. >>=20 >> b) MUST be multiplexed into a single transport flow. >>=20 >> c) SHOULD be multiplexed into a single transport flow, but the >> RTCWEB peer MUST be able to send them as individual flows. >>=20 >> I would love if people can indicate their choice or preferences. >>=20 >> I personally prefer A as it it is simplest in all aspect except the >> NAT traversal. - It allows for flow based QoS. - It is the what the >> implementation that exist mostly do - Signaling protocols that >> exist support it, no extra functionality - People are used to the >> concept - It minimizes the difference to legacy. >>=20 >> Thus it is the quickest road to define something with the least >> formal push back and concern over maturity of any solution. >>=20 >> The downside with B and C is that we do have to solve the >> multiplexing and get an agreement that gets through all the >> hurdles. >>=20 >> Of these two opens I do prefer C. Although it results in the >> extra complexities of having both alternatives, it will give us >> both a fallback, flow based QoS and better legacy support. >>=20 >> Now it is your time to make your opinion heard! >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> ----------------------------------------------------------------------= >> >>=20 Multimedia Technologies, Ericsson Research EAB/TVM >> ----------------------------------------------------------------------= >> >>=20 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 _______________________________________________ >> rtcweb mailing list rtcweb@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > Cullen Jennings For corporate legal information go to:=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ rtcweb mailing list=20 > 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 emil@sip-communicator.org Wed Jul 20 04:09: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 5D9DB21F8A7A for ; Wed, 20 Jul 2011 04:09:04 -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 4Up2ZKh5eI-H for ; Wed, 20 Jul 2011 04:09:00 -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 A0B9521F8A62 for ; Wed, 20 Jul 2011 04:08:59 -0700 (PDT) Received: by mail-wy0-f172.google.com with SMTP id 26so94996wyj.31 for ; Wed, 20 Jul 2011 04:08:59 -0700 (PDT) Received: by 10.227.201.207 with SMTP id fb15mr1738795wbb.113.1311160137440; Wed, 20 Jul 2011 04:08:57 -0700 (PDT) Received: from porcinet.u-strasbg.fr ([2001:660:4701:1001:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id gg16sm103308wbb.17.2011.07.20.04.08.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 04:08:56 -0700 (PDT) Message-ID: <4E26B747.2010003@jitsi.org> Date: Wed, 20 Jul 2011 13:08:55 +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: Cullen Jennings References: <4E259EAD.3060505@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 11:09:04 -0000 =D0=9D=D0=B0 20.07.11 02:43, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: >>> We have in our draft:=20 >>> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ >>> looked at two possible suggestions for explicit multiplexing. >>> Either a thin shim layer primarily consisting of a identifier >>> that through negotiation is bound to a context, like an >>> particular RTP session or a datagram channel. > > The problem with this is that if you are talking to a device that > does not support this you forever have to go through some > intermediary gateway that strips the byte. Just like turns servers, > this reduces the user experience by adding latency and jitter and is > expensive to run due to the bandwidth required. How is this different from implicit multiplexing and talking to devices that don't support it? Emil --=20 http://jitsi.org From emil@sip-communicator.org Wed Jul 20 04:09: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 DEE9521F8A7E for ; Wed, 20 Jul 2011 04:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXwqnOs8Z+Ch for ; Wed, 20 Jul 2011 04:09:03 -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 7909021F8A71 for ; Wed, 20 Jul 2011 04:09:02 -0700 (PDT) Received: by wwe5 with SMTP id 5so82721wwe.13 for ; Wed, 20 Jul 2011 04:09:01 -0700 (PDT) Received: by 10.227.174.73 with SMTP id s9mr6200655wbz.75.1311160141520; Wed, 20 Jul 2011 04:09:01 -0700 (PDT) Received: from porcinet.u-strasbg.fr ([2001:660:4701:1001:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id p14sm100630wbh.30.2011.07.20.04.09.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 04:09:00 -0700 (PDT) Message-ID: <4E26B74B.3050501@jitsi.org> Date: Wed, 20 Jul 2011 13:08:59 +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: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= References: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> <4E26A354.2020306@ericsson.com> In-Reply-To: <4E26A354.2020306@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 11:09:07 -0000 =D0=9D=D0=B0 20.07.11 11:43, Stefan H=C3=A5kansson LK =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: > On 2011-07-19 19:09, Serge Lachapelle wrote: >> There are many very established ways to transfer files from a web >> browser. Dropbox, Google Docs, yousendit, mobileme, not counting the >> media specific ways, such as Flickr, Spotify, Youtube, etc... All >> offering great APIs for uploads, ACLs, etc... >> >> Seems like re-inventing the wheel. > I tend to agree. What the data channel of rtcweb could provide is=20 > shorter latency - but to me that does not seem relevant for a file tran= sfer. I am not so sure about that. Transferring a file directly between you and your peer is often way faster than relaying through the servers of well known services. The time necessary to transfer several tens of megs can very greatly ... from a couple of minutes to an hour or more. Users are definitely very sensitive to this. Besides, this is not only about the latency. It's mostly about the reources that such relayed transfers require on the server side. Most providers want to bring those to a minimum. So much so, that some even put relatively low caps on the traffic you can send through the signalling channel. For example, the desktop sharing implementation we have in Jitsi uses signalling (SIP or XMPP) to convey key and mouse events. When using Google's XMPP service users would regularly experience blockages caused by the Google service dropping XMPP IQs when they go above a certain frequency. And this is in no way a criticism for the service itself ... it is however definitely a reason to have a reliable means of communicating directly between peers (or at least as directly as possible= ). Emil >> >> /Serge >> >> On Tue, Jul 19, 2011 at 19:02, Emil Ivov > > wrote: >> >> >> >> =D0=9D=D0=B0 19.07.11 18:37, Randell Jesup =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0: >> > On 7/19/2011 11:58 AM, Justin Uberti wrote: >> >> At Google, we created a TCP/ICE-UDP layering to solve this exa= ct >> >> problem, using a user-mode implementation of TCP. It has some = rough >> >> edges, but has worked well in practice, and the code is freely= >> available. >> > >> > Right; pretty much what I'd anticipate >> >> +1 most definitely. Again, I have yet to see a massively used RTC >> application that doesn't have file transfer. So if this is not par= t of >> RTCWEB we will basically be asking developers to reimplement Pseud= o TCP >> in JavaScript. >> >> Emil >> >> >, and working open code is good. >> > SCTP as mentioned is a good choice too, and there exist (it app= ears) >> > SCTP-over-UDP implementations, which may ease things. Also the= >> > TCP-over-UDP library I pointed to. >> > >> >> We know people will want/need a reliable messaging mechanism f= or p2p >> >> data. While we can debate the details of this mechanism at len= gth, I >> >> suspect anything we choose will result in a better end-state t= han if >> >> we require application developers to implement their own. >> > >> > As is obvious from my other messages, I agree wholeheartedly. >> > >> >> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich >> >> >> > >> wrote: >> >> >> >> +1 >> >> Maybe it would be useful for the proponents of this and ma= ny >> other >> >> =E2=80=9Cdesirable=E2=80=9D features to think from the per= spective if they would >> >> have to pay themselves for such developments and also make= the >> >> code freely available. >> >> Cullen at least will make his code available. >> >> >> > >> > See above. No one here wants to develop *another* reliable >> protocol if >> > we can avoid it. I understand your reluctance. >> > >> > The goal is to produce something that will meet the needs and g= et >> used. >> > If we don't meet the >> > needs of the prospective users it's either an total waste of ti= me (if >> > they ignore this effort and stick >> > with Flash/plugins/etc) or we get all sorts of >> > hack/bad/problematic/incompatible implementations >> > by individual developers using the UDP (or RTP!) streams we ope= n as a >> > base transport. >> > >> > To your point, another way this effort could fail is by biting >> off too >> > much or taking too long to >> > converge, which is a real danger. That's one reason to leverag= e >> > existing protocols. >> > >> >> -- >> 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 >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> -- >> Serge Lachapelle | Product Manager |sergel@google.com >> |+46 732 01 22 32 >> >> Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-= 6880 >> >> Apparently, this footer is required in Europe. Apologies. This email m= ay >> be confidential or privileged. If you received this communication by >> mistake, please don't forward it to anyone else,please erase all copie= s >> and attachments, and please let me know that it went to the wrong >> person. Thanks. >=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 magnus.westerlund@ericsson.com Wed Jul 20 04:10: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 2EB1E21F8A70 for ; Wed, 20 Jul 2011 04:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.522 X-Spam-Level: X-Spam-Status: No, score=-106.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 U7JIXgnTUqZQ for ; Wed, 20 Jul 2011 04:10:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8DB21F8A66 for ; Wed, 20 Jul 2011 04:10:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4c-4e26b78ba4c0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 59.40.20773.B87B62E4; Wed, 20 Jul 2011 13:10:03 +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; Wed, 20 Jul 2011 13:10:03 +0200 Message-ID: <4E26B78A.7040609@ericsson.com> Date: Wed, 20 Jul 2011 13:10:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Harald Alvestrand References: <4E259484.20509@ericsson.com> <4E26A49F.1070700@alvestrand.no> In-Reply-To: <4E26A49F.1070700@alvestrand.no> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 11:10:13 -0000 On 2011-07-20 11:49, Harald Alvestrand wrote: > Magnus, I cannot parse your list of choices. > > In the case where you have > > Sender A > Recipient B > Three video streams going from A to B > Three audio streams going from A to B > One video stream going from B to A > One audio stream going from B to A > > with the application not requiring the network to treat the packets any > differently, and with the application using the CNAME mechanism to match > audio streams with corresponding video streams > > it is completely unclear to me whether your choice A) requires 8 > transport flows, 4 transport flows or 2 transport flows, and it is > completely unclear to me what C) actually means. (I assume "transport > flow" = "RTP sessions" here) > > Please - can you clarify what your question is intended to mean? With choice A I do mean that one for each RTP session use one UDP flow in each direction. And that these two UDP flows will be symmetric, i.e. a bi-directional UDP flow. This in contrast to B and C when you use some multiplexing to map all RTP sessions, independently of how many you have onto one bi-directional UDP flow. The above example you give is at least two RTP sessions, one for audio and one for video. It might be more than these two if the reason you are sending multiple video streams is because the streams should be differently treated, for example in a RTP mixer. Where you perform composition of video streams of the participants and simply switch a demonstration camera. Or it may be that entity A above is transport relay and it is forwarding the camera from three different conference participants and all video streams are the same RTP session. It is the application that has do make these choices about if it needs more than one RTP session or not. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jul 20 05:11: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 6ED2521F8713 for ; Wed, 20 Jul 2011 05:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Sc8lJ0nn6lsh for ; Wed, 20 Jul 2011 05:11:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CF13D21F8747 for ; Wed, 20 Jul 2011 05:11:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-54-4e26c5d355db Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 08.E8.20773.3D5C62E4; Wed, 20 Jul 2011 14:10:59 +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, 20 Jul 2011 14:10:58 +0200 Message-ID: <4E26C5CF.1080007@ericsson.com> Date: Wed, 20 Jul 2011 14:10:55 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Cullen Jennings References: <4E259EAD.3060505@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 12:11:02 -0000 As an Individual Follow up inline On 2011-07-20 02:43, Cullen Jennings wrote: > On Jul 19, 2011, at 8:11 , Magnus Westerlund wrote: >> >> 1. We have 4 or more protocols (The possible set of protocols >> include: STUN, RTP/RTCP, Datagram, and DTLS-SRTP. There is likely >> future extensions, like reliable protocol) that needs to be >> identified and demultiplexed. A single extension in one of these >> protocols can cause the whole house of cards to come tumbling >> down. > > Uh, we already demux STUN, RTP/RTC, DTLS-SRTP based on first byte and > this is no big deal and is sort of water under the bridge at this > point. But this first byte multiplex issues is a red herring to this > topic, what happens with the demux of these protocols does not really > have much to do with how to demux the different RTP sessions. I agree that we currently have a design that multiplex the three above protocols onto the same lower layer when one uses ICE and DTSL-SRTP. However, the proposal in the WG is pilling on to this, but suggesting to add at least one protocol to the mix, maybe more if we do reliable in the future. The more independent protocols there is in the mix the bigger the risk is that we get a failure in the demultiplexing. >From my perspective this is not a red-herring at all. It is about good and future proof design. Both this issue and the RTP session multiplexing needs to be considered. > >> >> 2. It will require one to find an RTP internal session >> multiplexing mechanism. This is likely not easy or causes a fork of >> RTP into two non-compatible versions. In addition such a mechanism >> needs defining which takes time, likely substantial time as there >> is quite a lot of RTP mechanisms to consider. > > A bunch of us our proposing SSRC. We not seeing any problems with it. > I rather having this discussion be concrete around the specific > proposal on the table and not just some abstract it might be hard to > find something. The proposal on the table is to change the semantics of the SSRC field. So that it contains one part that is session identifier and another that is stream identifier. This have substantial impact on the RTP/RTCP specification and the implementation. To the degree where what you have is not any longer compatible with RFC 3550. It looks like RTP/RTCP but it isn't any more. We have documented the impacts of your proposal in Sections 2.2.1 and 3.3.1 of https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1 So from my perspective the proposal on the table is a complete no-go. And I have been thinking trying to find a proposal that wouldn't result in all these issues and still be internal to RTP. And I haven't found one yet. That is why I flag this. If there is a solution that doesn't have as serious impact I do want AVTCORE to standardize it. > >> >> 3. We likely need a multiplexing layer anyway if we want a fall >> back over WebSockets or HTTP. > > Not really - I think this is best done by making another TURN like > protocol that is compatible uses WebSockets or HTTP as the underling > transport. An architecture like this means that that protocol is > selected unilateral by the endpoint and used to get through that > endpoints firewalls. Both clients don't have to agree to do the same > thing - just like If I am using a TURN and you are not, we can still > have a call. Avoid a bilateral solution where possible make it much > easier to roll out. Well, it still needs to put out compatible flows. And if we have a multiplexing layer that becomes equally easy. > >> >> Thus we see this a very fragile mechanism that creates additional >> work overhead and large uncertainties in when it would be >> available. > > This all sounds sort of doom and gloom but lets talk about real > problems. > Timing is a real problem. If we want to do multiplexing in RTCWEB 1.0 we need to pick what is ready and available. We can't go around proposing new things that are complicated. Changing the SSRC field semantics in RTP/RTCP is a complicated thing. We will have tons of discussion of what the requirements really are for a more generally applicable solution. Not one that barely meets RTCWEBs needs, when we know the minute this goes out the door a lot of other RTP using services and applications would like to use it. The teleprecense work in CLUE is just one example. There will be a bunch. Thus AVTCORE needs to have a serious discussion of what the requirements are. Then we will discuss what the architectural implications are of any proposal. Review what existing functionality we are ready to break and likely need to replace. What the issues are with gatewaying between old and new semantics. Cullen, you are an experienced IETF, you have been an AD for RAI. What do think the probability is that this discussion has concluded and resulted in an IESG approved specification before December 2012? >> >> We have in our draft: >> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ >> looked at two possible suggestions for explicit multiplexing. >> Either a thin shim layer primarily consisting of a identifier that >> through negotiation is bound to a context, like an particular RTP >> session or a datagram channel. > > The problem with this is that if you are talking to a device that > does not support this you forever have to go through some > intermediary gateway that strips the byte. Just like turns servers, > this reduces the user experience by adding latency and jitter and is > expensive to run due to the bandwidth required. Isn't that gateway going to be present anyway in most case. I think the ICE connectivity checks are one thing that will force a gateway in many cases. In the cases it isn't needed, then you can skip the multiplexing in that case to reach the legacy. Would it not be better to have a clean explicit design for how to multiplex protocols between peers that can be used in RTCWEB and other future applications that doesn't drag our past mistakes into the design and forever prevent simple expansion with new functionality. The cost, a low one from my perspective is to say that legacy don't get the benefits of multiplexing. A feature they anyway are not going to get unless they use a gateway or are updated to be RTCWEB compliant. > >> >> The other alternative we considered was using DCCP over UDP for RTP >> and datagram. That way we got a complete port space for >> multiplexing different purposes for flows. We also got a transport >> framework with its own negotiation, congestion control, a several >> other features. > > This has the same problem as above with the added problem of I am not > aware of a good (meaning widely tested) DCCP implementation in user > land and to be deployable this pretty much needs to be all user land. Yes, I do agree that it needs to be a user-land implementation in the browser until DCCP becomes available in the OSes. But that is true also for all the alternatives that so far been discussed. TFRC in RTP will be as much user-land as DCCP over UDP with TFRC. The big difference is that we either have a well reviewed and by the community and IESG approved specification in DCCP. Or we create something our selves that needs to go through all that review and will be even less tested than DCCP is. > > >> >> We invite people to consider these proposals or suggest better >> alternatives of explicit multiplexing. But I hope we can avoid a >> serious mistake and select implicit multiplexing. > > I'd like people to start talking about what the actual serious > mistakes of implicit multiplexing as specified in the SSRC proposal > are. Ok, Have I thrown the gauntlet down enough :-) Really, I'm just > not getting what the problems are - if I understood the problems, I > might have a different view point on this. > Please do read the latest version of https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1 We have expanded on the discussion, both about the particular proposal and the general issues with multiplexing is RTP. If you can give some hint what in that argumentation you don't understand we can try to explain in some other way. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Wed Jul 20 05:58: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 0CD8821F88DD for ; Wed, 20 Jul 2011 05:58:22 -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 ufbkEsyztBl3 for ; Wed, 20 Jul 2011 05:58:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D595321F88A5 for ; Wed, 20 Jul 2011 05:58:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0084B39E0FE; Wed, 20 Jul 2011 14:57:14 +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 07pcNVPxasa8; Wed, 20 Jul 2011 14:57:09 +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 C7B3B39E072; Wed, 20 Jul 2011 14:57:09 +0200 (CEST) Message-ID: <4E26D0E6.3080605@alvestrand.no> Date: Wed, 20 Jul 2011 14:58:14 +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: Magnus Westerlund References: <4E259484.20509@ericsson.com> <4E26A49F.1070700@alvestrand.no> <4E26B78A.7040609@ericsson.com> In-Reply-To: <4E26B78A.7040609@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 12:58:22 -0000 On 07/20/11 13:10, Magnus Westerlund wrote: > On 2011-07-20 11:49, Harald Alvestrand wrote: >> Magnus, I cannot parse your list of choices. >> >> In the case where you have >> >> Sender A >> Recipient B >> Three video streams going from A to B >> Three audio streams going from A to B >> One video stream going from B to A >> One audio stream going from B to A >> >> with the application not requiring the network to treat the packets an= y >> differently, and with the application using the CNAME mechanism to mat= ch >> audio streams with corresponding video streams >> >> it is completely unclear to me whether your choice A) requires 8 >> transport flows, 4 transport flows or 2 transport flows, and it is >> completely unclear to me what C) actually means. (I assume "transport >> flow" =3D "RTP sessions" here) >> >> Please - can you clarify what your question is intended to mean? > With choice A I do mean that one for each RTP session use one UDP flow > in each direction. And that these two UDP flows will be symmetric, i.e.= > a bi-directional UDP flow. > > This in contrast to B and C when you use some multiplexing to map all > RTP sessions, independently of how many you have onto one bi-directiona= l > UDP flow. > > The above example you give is at least two RTP sessions, one for audio > and one for video. It might be more than these two if the reason you ar= e > sending multiple video streams is because the streams should be > differently treated, for example in a RTP mixer. Where you perform > composition of video streams of the participants and simply switch a > demonstration camera. Or it may be that entity A above is transport > relay and it is forwarding the camera from three different conference > participants and all video streams are the same RTP session. > > It is the application that has do make these choices about if it needs > more than one RTP session or not. Magnus, if the number of UDP flows is constant (even if it's slightly=20 larger than 1) when the number of video streams changes under your=20 solution A, I think this is a viable option. If the number of UDP flows was linear with the number of video streams,=20 I believe that a number of scenarios we want RTCWEB to support,=20 including stuff like the Google+ Hangouts, would be basically unsustainab= le. So - with the understanding that an application is going to put as many=20 video streams it wants down one RTP session if that's appropriate for=20 the purposes of the application - I am in favour of the "no=20 multiplexing" solution. Harald > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From harald@alvestrand.no Wed Jul 20 06:15: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 AC95021F87C2 for ; Wed, 20 Jul 2011 06:15:11 -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 omf3a7V87HeO for ; Wed, 20 Jul 2011 06:15:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 70BFA21F877D for ; Wed, 20 Jul 2011 06:15:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C58A239E0FE for ; Wed, 20 Jul 2011 15:14:02 +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 gsL7F1XdYscm for ; Wed, 20 Jul 2011 15:13:58 +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 1239B39E072 for ; Wed, 20 Jul 2011 15:13:58 +0200 (CEST) Message-ID: <4E26D4D6.3020602@alvestrand.no> Date: Wed, 20 Jul 2011 15:15:02 +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: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 13:15:11 -0000 On 07/20/11 03:13, Cullen Jennings wrote: > On Jul 18, 2011, at 15:11 , Randell Jesup wrote: > >> All that said - yes, there are complexity issues to consider, which was why I was suggesting leveraging >> an existing tunneled protocol like SCTP or even TCP-over-UDP. > I agree with bunch of what you are saying but the previous several times I've seen the use SCTP over UDP conversation, it usually ends about the point the we ask for a user land implementation. Whatever we do more or less has to be user land or already exist in the OS that people run browsers on. > > If someone has a user land implementation of SCTP or TCP, I imagine that might change the outcome a bit from previous times. I have not looked at the TCP over UPD library Justin mentioned but, at casual glance, I noticed is around 400 lines of code which is very small, which is cool. But given the lines of code in say the BSD TCP stack, it does make me wonder what's missing. That said, I don't think we need something with the perforce of the BSD TCP stack as long as what is there is TCP friendly and robust. I believe this is the current URL: http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc (500 or so lines). The real protocol implementation is here: http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.cc which is another 1000 lines (not counting the various .h files). We're not THAT good at writing compact code :-) > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From prvs=175d5c863=tterriberry@mozilla.com Wed Jul 20 06:58: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 3366C21F85EA for ; Wed, 20 Jul 2011 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.157, 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 3fAqIo2qNLQX for ; Wed, 20 Jul 2011 06:58:29 -0700 (PDT) Received: from mxip2i.isis.unc.edu (mxip2i.isis.unc.edu [152.2.2.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29221F85A8 for ; Wed, 20 Jul 2011 06:58:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAMbeJk6sGgRS/2dsb2JhbABTpnWBZIh8wEuGPQSHVZARD4t2 X-IronPort-AV: E=Sophos;i="4.67,235,1309752000"; d="scan'208";a="119495598" Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip2o.isis.unc.edu with ESMTP; 20 Jul 2011 09:58:28 -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 p6KDwQ3m013388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Jul 2011 09:58:27 -0400 (EDT) Message-ID: <4E26DF02.5010202@mozilla.com> Date: Wed, 20 Jul 2011 06:58:26 -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: <4E259484.20509@ericsson.com> <4E25B37D.9080404@skype.net> <4E267750.50101@ericsson.com> In-Reply-To: <4E267750.50101@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 13:58:30 -0000 > Besides, it has been discussed that A/V synch should be maintained > within a MediaStream. This is something you would lose if you split it > up and transport it using separate peer conn objects. Actually, one of the major design goals of the MediaStream API is to allow the synchronization of multiple, separate MediaStreams, and I've been working with roc to ensure that this is, in fact, relatively straightforward to do. Which is not an argument against a more explicit API for dealing with multiplexing (that argument belongs on a different list anyway). From fluffy@cisco.com Wed Jul 20 07:11: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 7DEB721F84D9 for ; Wed, 20 Jul 2011 07:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.938 X-Spam-Level: X-Spam-Status: No, score=-103.938 tagged_above=-999 required=5 tests=[AWL=-1.339, 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 H8qaloik+cnU for ; Wed, 20 Jul 2011 07:11:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2B021F8880 for ; Wed, 20 Jul 2011 07:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=8840; q=dns/txt; s=iport; t=1311171065; x=1312380665; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ON24osNGuUukow/bzp2HTzBvs3qYOfPB3lXhuViBADI=; b=JKgxOp/RLV3KK1grm9G6UhlgvhtlQ7XDNy1carCgrKmmYapIaMD2NaD6 TylOLjgUnewaMlXAKyiqKUQd8CU+IIfcdPK3M7ShXH9wHP+YnV+aaLuVi 1G6v7aTj+fgquiNzqaIKa80c0WKDYCfMxwTYdH1xpeKd3YFZS5aePVX8p o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABzhJk6rRDoH/2dsb2JhbABThARGoxl3iHyiFY0ekRECgSmEAzBfBIdVixmFB4t2 X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208";a="4728541" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 20 Jul 2011 14:11:04 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6KEB3Qa030838; Wed, 20 Jul 2011 14:11:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Cullen Jennings In-Reply-To: <4E26B742.6050606@jitsi.org> Date: Wed, 20 Jul 2011 07:11:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> References: <4E259484.20509@ericsson.com> <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> <4E26B742.6050606@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 14:11:10 -0000 On Jul 20, 2011, at 4:08 , Emil Ivov wrote: > =D0=9D=D0=B0 20.07.11 02:05, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >> I'd like to see it that devices MUST support multiplexing and I'd >> probably be in favor of also MUST support non multiplexed flows. The >> multiplexing is a big advantage for any device that needs to deal >> with NATs so I suspect many "legacy" devices would be moving to this >> even if there was no need to deal with the browser like devices. I >> also think that allowing this type of multiplexing will make firewall >> traversal easier where a device can configure a firewall to open just >> one specified port and use it for RTP. >=20 > I don't really agree with this part. Devices would still need to = handle > candidates that come from STUN, TURN, UPnP, host IPv4, host IPv6, and > potentially VPN, MIPv6 and other tunnelling mechanisms. Whether or not > this only happens for a single component/stream doesn't really = simplify > code does it? >=20 > According to my personal experience with our work on ice4j.org, = managing > multiple checklists was far less resource consuming than implementing > TURN tunnels and persmissions, STUN multiplexing, synchronisation and > even getting pacing right. Ahh, I think we have come to the key issues here - perhaps I have not = been explaining myself very well. So in your experience roughly how long = does it take to set up a for two scenarios using ICE as is today.=20 First scenario: I have two devices that want to set up a single audio = stream and they each have the candidates from: local v4 IP address, v4 = stun, v4 turn, local v6, turn v6. Obviously they could have a lot more = but that seems like a reasonable starting point.=20 Second scenario: same as first address wise but instead of a single = audio stream they want to set up a single audio stream to a conference = bridge plus 7 video streams for the video from the 5 people on the = bridge plus a presentation stream and stream of video from active = speaker. I don't really care much about the scenario other than there = are 8 streams being set up. But this type of scenario is becoming very = common for multi party video chat as it allows you to see perhaps small = versions of everyone plus a large version of active speaker.=20 My experience is the answer to the first scenario is not as quick as you = would like and the answer to how long the second takes is about 8 times = longer than the first one. You might do a bit better than that depending = on how clever your implementation is but it still a lot longer.=20 I totally agree with you that multiplexing may not hugely simplify the = code and you still have to deal with the hard parts to implement. WHat = is helps with is it makes the second scenario take exactly the same time = as the first scenario because instead of taking 8 times a long. It's = purely a user experience thing. Does that make sense?=20 >=20 > >=20 >> The primary reason I want multiplexing is the time to set up all the >> ICE connections. The fact of the matter is that NATs limit how >> quickly you can create new flows. If all you need is something simple >> with just 2 flows, one for audio and one for video, this is workable. >> But as soon as you move to trying to have a transition strategy from >> V4 to V6 and multiple person video or even just multi screen video, >> the user experience goes downhill rapidly. >=20 > I agree more with this argument, although freezing candidates > significantly brings down the overhead incurred by having multiple > streams and components and I am not sure that the actual win here = would > be good enough to pay for implementing multiplexing and for breaking > interoperability with those that don't have it. Use multiplexing would be negotiated over the SDP, just like rtcp/rtp = mux is negotiated today, so it would not break interoperability with = stuff that did not support it.=20 >=20 >> Much of the IETF thinking around ICE was done on the assumption that >> ICE could be done before ringing started or during ringing but the >> deployments I am seeing are moving more towards not doing ICE until >> after a call is answered. There are many reasons for this but one of >> them is that if Alice calls Bob, and Bob is on a mobile internet >> device, you don't want to reveal Bob's location to Alice before Bob >> even decides to answer the call. Given an IP address more or less >> reveals location these days that a bit of issues to do ICE before >> answering. This puts more pressure on being able to do ICE quickly >> for a good user experience. >=20 > Agreed, but is multiplexing the only way of bringing the time down? = The > XMPP crowd for example has been using a mechanism that allows = candidates > to be sent as they become available rather than wait for all = harvesting > to complete. Maybe this is worth exploring and integrating in the > official ICE (although I don't see how it would work with SIP). I am a fan of sending candidates as they become available but I don't = think this helps much as most devices can gather the addresses before = the user even initiates a call and the gather it typically very quick = relative to the rest of the ICE process.=20 >=20 > Cheers, > Emil >=20 >>=20 >> Cullen >>=20 >> On Jul 19, 2011, at 7:28 , Magnus Westerlund wrote: >>=20 >>> Hi, >>>=20 >>> This email is as an individual contributor. >>>=20 >>> I want to get started on the discussion of the Multiplexing of the=20= >>> various protocols over single lower layer transport flow, such as a >>> UDP flow. I will attempt to split up the questions into different >>> emails. >>>=20 >>> The first question I think is reasonably easy to get answered, but >>> I think it is time we determine if my belief in the answer is >>> correct or not. >>>=20 >>> The traffic between two RTCWEB peers from the various components, >>> such as RTP sessions, datagram service: >>>=20 >>> a) MUST be sent as Individual flows for each component. >>>=20 >>> b) MUST be multiplexed into a single transport flow. >>>=20 >>> c) SHOULD be multiplexed into a single transport flow, but the >>> RTCWEB peer MUST be able to send them as individual flows. >>>=20 >>> I would love if people can indicate their choice or preferences. >>>=20 >>> I personally prefer A as it it is simplest in all aspect except the >>> NAT traversal. - It allows for flow based QoS. - It is the what the >>> implementation that exist mostly do - Signaling protocols that >>> exist support it, no extra functionality - People are used to the >>> concept - It minimizes the difference to legacy. >>>=20 >>> Thus it is the quickest road to define something with the least >>> formal push back and concern over maturity of any solution. >>>=20 >>> The downside with B and C is that we do have to solve the >>> multiplexing and get an agreement that gets through all the >>> hurdles. >>>=20 >>> Of these two opens I do prefer C. Although it results in the >>> extra complexities of having both alternatives, it will give us >>> both a fallback, flow based QoS and better legacy support. >>>=20 >>> Now it is your time to make your opinion heard! >>>=20 >>> Cheers >>>=20 >>> Magnus Westerlund >>>=20 >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 > Multimedia Technologies, Ericsson Research EAB/TVM >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 > 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=20 >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >> Cullen Jennings For corporate legal information go to:=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >> _______________________________________________ rtcweb mailing list=20= >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=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 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 20 07:12: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 2E41B21F85A8 for ; Wed, 20 Jul 2011 07:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.912 X-Spam-Level: X-Spam-Status: No, score=-103.912 tagged_above=-999 required=5 tests=[AWL=-1.313, 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 mHjRReZB7EeP for ; Wed, 20 Jul 2011 07:12:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8821F86A2 for ; Wed, 20 Jul 2011 07:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1038; q=dns/txt; s=iport; t=1311171119; x=1312380719; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=p2RHoLz+21htj6KXqkPPu2Vpkbw+3cGwOV/XDQ9fVO0=; b=kz3cItlADCmut5MsBidOorSijf1GflyTOQoLSAjHIaZK23kwQ3b5ft4c so7GCoSRiAke5xoTEFivf3QUz9uswJfjvtq1mNmqRA9X93o++qYhZtkjN g7eDhRKMIws4sIr+UMYhYpBGekClds0e/xoop36RPQoCfM8sOm7dALkyP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGDhJk6rRDoH/2dsb2JhbABThEqjGXerEo0ekRGBK4QDMF8Eh1WLGYUHi3Y X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208";a="4732488" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 20 Jul 2011 14:11:55 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6KEB3Qb030838; Wed, 20 Jul 2011 14:11:54 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Cullen Jennings In-Reply-To: <4E26B747.2010003@jitsi.org> Date: Wed, 20 Jul 2011 07:11:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6ECA0CE8-4043-4E6A-A15D-8A6C3AE33CFE@cisco.com> References: <4E259EAD.3060505@ericsson.com> <4E26B747.2010003@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 14:12:05 -0000 On Jul 20, 2011, at 4:08 , Emil Ivov wrote: > =D0=9D=D0=B0 20.07.11 02:43, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >>>> We have in our draft:=20 >>>> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ >>>> looked at two possible suggestions for explicit multiplexing. >>>> Either a thin shim layer primarily consisting of a identifier >>>> that through negotiation is bound to a context, like an >>>> particular RTP session or a datagram channel. >>=20 >> The problem with this is that if you are talking to a device that >> does not support this you forever have to go through some >> intermediary gateway that strips the byte. Just like turns servers, >> this reduces the user experience by adding latency and jitter and is >> expensive to run due to the bandwidth required. >=20 > How is this different from implicit multiplexing and talking to = devices > that don't support it? Sorry, I should have been clear that I think the multiplexing has to be = negotiated with SDP=20= From bernard_aboba@hotmail.com Wed Jul 20 07:18: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 B2F3521F86A8 for ; Wed, 20 Jul 2011 07:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, 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 nW8-7okbZVEE for ; Wed, 20 Jul 2011 07:18:30 -0700 (PDT) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8AF21F86A2 for ; Wed, 20 Jul 2011 07:18:30 -0700 (PDT) Received: from BLU152-W54 ([65.55.116.74]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 07:18:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bfe8aeb3-9649-4be3-9406-d16b0a6699cc_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Magnus Westerlund , Date: Wed, 20 Jul 2011 07:18:29 -0700 Importance: Normal In-Reply-To: <4E26C5CF.1080007@ericsson.com> References: <4E259EAD.3060505@ericsson.com>, , <4E26C5CF.1080007@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2011 14:18:29.0636 (UTC) FILETIME=[E5F57440:01CC46E7] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 14:18:30 -0000 --_bfe8aeb3-9649-4be3-9406-d16b0a6699cc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Timing is a real problem. If we want to do multiplexing in RTCWEB 1.0 we > need to pick what is ready and available. We can't go around proposing > new things that are complicated. Changing the SSRC field semantics in > RTP/RTCP is a complicated thing. [BA] We need to ask ourselves "Does this really need to be in the critical = path for RTCWEB 1.0"? =20 As I understand it=2C this would be a negotiated feature=2C and presumably = all implementations would be required to support RTP/RTCP as defined in RFC 3550 and suitable p= rofiles.=20 So from my perspective=2C I'd prefer to see this handled as an extension on= its own path=2C not a=20 mandatory-to-implement feature in 1.0. =20 > Isn't that gateway going to be present anyway in most case. I think the > ICE connectivity checks are one thing that will force a gateway in many > cases. In the cases it isn't needed=2C then you can skip the multiplexing > in that case to reach the legacy. [BA] Just because we're likely to require a gateway doesn't mean we should heap more and more things on the camel's back. We're already talking about ICE=2C shims=2C transcoding=2C changes to RFC 3550.... that's a lot of fun= ctionality for the "gateway". So I agree with Jonathan about the disadvantages of a s= him (or DCCP for that matter).=20 > The big difference is that we either have a well reviewed and by the > community and IESG approved specification in DCCP. Or we create > something our selves that needs to go through all that review and will > be even less tested than DCCP is. [BA] Deployment counts=2C too. How widely deployed is DCCP for realtime us= es?=20 = --_bfe8aeb3-9649-4be3-9406-d16b0a6699cc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B Timing is a real problem. If we want to do multiplexing in = RTCWEB 1.0 we
>=3B need to pick what is ready and available. We can't = go around proposing
>=3B new things that are complicated. Changing the= SSRC field semantics in
>=3B RTP/RTCP is a complicated thing.

= [BA] We need to ask ourselves "Does this really need to be in the critical = path for RTCWEB 1.0"? =3B
As I understand it=2C this would be a neg= otiated feature=2C and presumably all implementations
would be required = to support RTP/RTCP as defined in RFC 3550 and suitable profiles.
So fr= om my perspective=2C I'd prefer to see this handled as an extension on its = own path=2C not a
mandatory-to-implement feature in 1.0. =3B = =3B


>=3B Isn't that gateway going to be present anyway in mos= t case. I think the
>=3B ICE connectivity checks are one thing that wi= ll force a gateway in many
>=3B cases. In the cases it isn't needed=2C= then you can skip the multiplexing
>=3B in that case to reach the leg= acy.

[BA] Just because we're likely to require a gateway doesn't mea= n we should
heap more and more things on the camel's back. =3B We're= already talking about
ICE=2C shims=2C transcoding=2C changes to RFC 355= 0.... =3B that's a lot of functionality
for the "gateway". =3B S= o I agree with Jonathan about the disadvantages of a shim
(or DCCP for t= hat matter).


>=3B The big difference is that we either have a= well reviewed and by the
>=3B community and IESG approved specificati= on in DCCP. Or we create
>=3B something our selves that needs to go th= rough all that review and will
>=3B be even less tested than DCCP is.<= br>
[BA] Deployment counts=2C too. =3B How widely deployed is DCCP f= or realtime uses?


= --_bfe8aeb3-9649-4be3-9406-d16b0a6699cc_-- From bernard_aboba@hotmail.com Wed Jul 20 07:24: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 3BFDA21F86A2 for ; Wed, 20 Jul 2011 07:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.058, 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 oeuQcKFvgx1m for ; Wed, 20 Jul 2011 07:24:26 -0700 (PDT) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by ietfa.amsl.com (Postfix) with ESMTP id 97E2621F863A for ; Wed, 20 Jul 2011 07:24:26 -0700 (PDT) Received: from BLU152-W38 ([65.55.111.137]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 07:24:26 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_be1e7d73-1113-40ee-8bd4-59bc1e85d987_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Date: Wed, 20 Jul 2011 07:24:25 -0700 Importance: Normal In-Reply-To: <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2011 14:24:26.0272 (UTC) FILETIME=[BA87CA00:01CC46E8] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 14:24:27 -0000 --_be1e7d73-1113-40ee-8bd4-59bc1e85d987_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Ahh=2C I think we have come to the key issues here - perhaps I have not b= een explaining myself very well. So in your experience roughly how long doe= s it take to set up a for two scenarios using ICE as is today.=20 >=20 > First scenario: I have two devices that want to set up a single audio str= eam and they each have the candidates from: local v4 IP address=2C v4 stun= =2C v4 turn=2C local v6=2C turn v6. Obviously they could have a lot more bu= t that seems like a reasonable starting point.=20 >=20 > Second scenario: same as first address wise but instead of a single audio= stream they want to set up a single audio stream to a conference bridge p= lus 7 video streams for the video from the 5 people on the bridge plus a pr= esentation stream and stream of video from active speaker. I don't really c= are much about the scenario other than there are 8 streams being set up. Bu= t this type of scenario is becoming very common for multi party video chat = as it allows you to see perhaps small versions of everyone plus a large ver= sion of active speaker.=20 >=20 > My experience is the answer to the first scenario is not as quick as you = would like and the answer to how long the second takes is about 8 times lon= ger than the first one. You might do a bit better than that depending on ho= w clever your implementation is but it still a lot longer.=20 [BA] Yes=2C that is correct. However at the moment I'd characterize that a= s a "high quality problem"=2C since it isn't even clear that the current WH= ATWG API can handle that case=2C due to glare and ICE timing issues. =20 = --_be1e7d73-1113-40ee-8bd4-59bc1e85d987_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B Ahh=2C I think we have come to the key issues here - perhap= s I have not been explaining myself very well. So in your experience roughl= y how long does it take to set up a for two scenarios using ICE as is today= .
>=3B
>=3B First scenario: I have two devices that want to set= up a single audio stream and they each have the candidates from: local v4 = IP address=2C v4 stun=2C v4 turn=2C local v6=2C turn v6. Obviously they cou= ld have a lot more but that seems like a reasonable starting point.
>= =3B
>=3B Second scenario: same as first address wise but instead of a= single audio stream they want to set up a single audio stream to a confer= ence bridge plus 7 video streams for the video from the 5 people on the bri= dge plus a presentation stream and stream of video from active speaker. I d= on't really care much about the scenario other than there are 8 streams bei= ng set up. But this type of scenario is becoming very common for multi part= y video chat as it allows you to see perhaps small versions of everyone plu= s a large version of active speaker.
>=3B
>=3B My experience is= the answer to the first scenario is not as quick as you would like and the= answer to how long the second takes is about 8 times longer than the first= one. You might do a bit better than that depending on how clever your impl= ementation is but it still a lot longer.

[BA] Yes=2C that is correc= t. =3B However at the moment I'd characterize that as a "high quality p= roblem"=2C since it isn't even clear that the current WHATWG API can handle= that case=2C due to glare and ICE timing issues. =3B
=
= --_be1e7d73-1113-40ee-8bd4-59bc1e85d987_-- From fluffy@cisco.com Wed Jul 20 07:40: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 A2A3E21F8A70 for ; Wed, 20 Jul 2011 07:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.862 X-Spam-Level: X-Spam-Status: No, score=-103.862 tagged_above=-999 required=5 tests=[AWL=-1.263, 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 C7XLQ45-Iqaq for ; Wed, 20 Jul 2011 07:40:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5EE21F85F5 for ; Wed, 20 Jul 2011 07:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1790; q=dns/txt; s=iport; t=1311172808; x=1312382408; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=U+NA90Acvx5Y2N6tRhR5X565y8iAKdx/H9XXzoSjRr8=; b=SDQZ0vGmgssnefjFLSD3jhu0/NqFeVcT/KLi55xk5NLmAxeksHGG5eKC uws5tCkN9XOeePCXtiUIkXKvzW5lDTMmrtSIt0onuN0jnA2OiyaNDr6Dr s8Mabf/5O9y6eLEd7IOvfkD2DRcOk/iIY64LMck2hcp5okwDuEngmVcHs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKznJk6rRDoJ/2dsb2JhbABTp2N3iHyhdJ4uhV5fBIdVixmFB4t2 X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208";a="4740304" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2011 14:40:07 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6KEe6TA003050; Wed, 20 Jul 2011 14:40:07 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 20 Jul 2011 07:40:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 14:40:12 -0000 On Jul 20, 2011, at 7:24 , Bernard Aboba wrote: >=20 > > Ahh, I think we have come to the key issues here - perhaps I have = not been explaining myself very well. So in your experience roughly how = long does it take to set up a for two scenarios using ICE as is today.=20= > >=20 > > First scenario: I have two devices that want to set up a single = audio stream and they each have the candidates from: local v4 IP = address, v4 stun, v4 turn, local v6, turn v6. Obviously they could have = a lot more but that seems like a reasonable starting point.=20 > >=20 > > Second scenario: same as first address wise but instead of a single = audio stream they want to set up a single audio stream to a conference = bridge plus 7 video streams for the video from the 5 people on the = bridge plus a presentation stream and stream of video from active = speaker. I don't really care much about the scenario other than there = are 8 streams being set up. But this type of scenario is becoming very = common for multi party video chat as it allows you to see perhaps small = versions of everyone plus a large version of active speaker.=20 > >=20 > > My experience is the answer to the first scenario is not as quick as = you would like and the answer to how long the second takes is about 8 = times longer than the first one. You might do a bit better than that = depending on how clever your implementation is but it still a lot = longer.=20 >=20 > [BA] Yes, that is correct. However at the moment I'd characterize = that as a "high quality problem", since it isn't even clear that the = current WHATWG API can handle that case, due to glare and ICE timing = issues. =20 Agree - but I think we need to fix that regardless of what we decide = with this. =20 From dzonatas@gmail.com Wed Jul 20 07:53: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 B56B121F859E for ; Wed, 20 Jul 2011 07:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.266 X-Spam-Level: X-Spam-Status: No, score=-4.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 NlL0zgpFFHnp for ; Wed, 20 Jul 2011 07:53:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE0A21F859C for ; Wed, 20 Jul 2011 07:53:50 -0700 (PDT) Received: by iwn39 with SMTP id 39so308955iwn.31 for ; Wed, 20 Jul 2011 07:53:49 -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=3fQATj7tBxrmXrCbcA2harTgnBSLBeOrO+2gjHm8apc=; b=jjUBPyUic8co/ZtGM0PoYPW8AwqimajdprmAL7iTNXTu6UWEMm6X8l7bNp5hMLtmz/ gzDi4ib7XhLipmtpYIS4SscfdT/+Xc5CIfbBs2naNofkuDl29/zsYQuMuy8cSyfnwMHW vTtR7HEzWaDsQU8rk9aVDX+DoRPm4IP9V+wOI= Received: by 10.231.180.156 with SMTP id bu28mr7738868ibb.134.1311173629773; Wed, 20 Jul 2011 07:53:49 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id az3sm418058icb.12.2011.07.20.07.53.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 07:53:48 -0700 (PDT) Message-ID: <4E26EC05.30703@gmail.com> Date: Wed, 20 Jul 2011 07:53:57 -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: <4E259484.20509@ericsson.com> <4E25A31A.8010103@gmail.com> In-Reply-To: <4E25A31A.8010103@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 14:53:54 -0000 I found the answer through the continued discussion in other messages sent to this WG list. There is no semantics between spectral modes and multiplex modes. In fact, news yesterday reveals "they're getting it" now, so I may not seem so much like a pest... "A team of researchers at the Oak Ridge National Laboratory have found that it's hydrogen rather than carbon which plays a fundamental part in creating a uniform crystalline form." Read more: http://www.techeye.net/science/graphene-discovery-points-to-large-scale-production#ixzz1SelXjqyn Yes, we have been thinking in light ("spectral" crystal ICs) and hydrogen economy for years (stateful vs stateless protocols), and realized many do not, were stuck, or haven't yet realized this much at this level because their trained to think in unlimited resources. Practicality and duplication is near-term now. ...well, a resource-pest around standards to determine sustainable technology. Real-time and dates are always an issue with assets. If the above still doesn't make think, realize that generally hydrogen has no shape ("nobody"/nothing holds it), therefore considered unreliable for transport, until now... Thanks. On 07/19/2011 08:30 AM, Dzonatas Sol wrote: > On 07/19/2011 07:28 AM, Magnus Westerlund wrote: >> a) MUST be sent as Individual flows for each component. >> >> b) MUST be multiplexed into a single transport flow. >> >> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB >> peer MUST be able to send them as individual flows. >> > > One clarification please, if there are known ranges of A as one > spectrum, does this WG still consider that multiplexed? IPv6, for > example, allows us to multiplex in a TCP-less way, simply by > fulfillment of the flows to more than one individual address. Those > addresses could constitute one spectrum in a stateful manner, or not. > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From randell1@jesup.org Wed Jul 20 08: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 28D5021F8610 for ; Wed, 20 Jul 2011 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 CzkqSRVJlonW for ; Wed, 20 Jul 2011 08:30:34 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 678C021F85CD for ; Wed, 20 Jul 2011 08:30:34 -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 1QjYjJ-0002jZ-9i for rtcweb@ietf.org; Wed, 20 Jul 2011 10:30:33 -0500 Message-ID: <4E26F460.3080007@jesup.org> Date: Wed, 20 Jul 2011 11:29:36 -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: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> <4E26A354.2020306@ericsson.com> In-Reply-To: <4E26A354.2020306@ericsson.com> Content-Type: text/plain; charset=UTF-8; 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] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 15:30:35 -0000 On 7/20/2011 5:43 AM, Stefan Håkansson LK wrote: > On 2011-07-19 19:09, Serge Lachapelle wrote: >> There are many very established ways to transfer files from a web >> browser. Dropbox, Google Docs, yousendit, mobileme, not counting the >> media specific ways, such as Flickr, Spotify, Youtube, etc... All >> offering great APIs for uploads, ACLs, etc... >> >> Seems like re-inventing the wheel. > I tend to agree. What the data channel of rtcweb could provide is > shorter latency - but to me that does not seem relevant for a file > transfer. For some use-cases that's important (shorter on average, not guaranteed) - for example games. Others like the Google Wave demo Tim posted (https://babyis60.wordpress.com/2009/10/24/my-astricon-googlewave-ibook-skype-demo/) would be painful (and hurt usability) to implement using drop-box like transfers. For other cases (file xfer), yes you can use those - but the problem is that when you want to transfer to the person you're chatting with, you would need to use another service, agree on it, deal with the semantics/accounts/limits/etc for that service, etc. A horrible user experience. Even if it was "hidden" by the application, it would be problematic and subject to breakage continually. -- Randell Jesup randell-ietf@jesup.org From juberti@google.com Wed Jul 20 08:37: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 89D9B21F8797 for ; Wed, 20 Jul 2011 08:37:40 -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, 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 WAVu-Ke0MY9y for ; Wed, 20 Jul 2011 08:37:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A414821F8757 for ; Wed, 20 Jul 2011 08:37:35 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p6KFbYSh016909 for ; Wed, 20 Jul 2011 08:37:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311176254; bh=nbKtaSPLQIDedP+h6EcSNvWqnSU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BEmE3tsExD2ZM2YBPsNxCGpYb5isKAG/5KN7feJbbCDMcwYY4UDrYSgBzDAedFE2F F4NIfbOQjLigIbbLZzkkA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=EdW2IetpBMm318pK77IM3GifjHSx107f7iJ1IRejqWuTxkwsmrfIzOc/2z35eNR52 kdD4Tp1RoJMdFiJKMOLQQ== Received: from iyb14 (iyb14.prod.google.com [10.241.49.78]) by kpbe20.cbf.corp.google.com with ESMTP id p6KFbKMB011565 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 08:37:32 -0700 Received: by iyb14 with SMTP id 14so367520iyb.0 for ; Wed, 20 Jul 2011 08:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cCgNzdsMLIISjtul4LQoGwvh7q2T/1uweMqWVdrt2HM=; b=FkgRu5KNo5+LhH6D/6Db+qIEwwlyLYLyBZB7pQJi5NPHegA3dCAVI7MD1jvWL6K0Ly fsPIIVLYU74G8UQ/cRbg== Received: by 10.231.73.138 with SMTP id q10mr8269946ibj.13.1311176252241; Wed, 20 Jul 2011 08:37:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.35.4 with HTTP; Wed, 20 Jul 2011 08:37:12 -0700 (PDT) In-Reply-To: <4E26D4D6.3020602@alvestrand.no> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> From: Justin Uberti Date: Wed, 20 Jul 2011 11:37:12 -0400 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=000e0cd56f26c0b79004a8820279 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 15:37:40 -0000 --000e0cd56f26c0b79004a8820279 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand wrote: > On 07/20/11 03:13, Cullen Jennings wrote: > >> On Jul 18, 2011, at 15:11 , Randell Jesup wrote: >> >> All that said - yes, there are complexity issues to consider, which was >>> why I was suggesting leveraging >>> an existing tunneled protocol like SCTP or even TCP-over-UDP. >>> >> I agree with bunch of what you are saying but the previous several times >> I've seen the use SCTP over UDP conversation, it usually ends about the >> point the we ask for a user land implementation. Whatever we do more or less >> has to be user land or already exist in the OS that people run browsers on. >> >> If someone has a user land implementation of SCTP or TCP, I imagine that >> might change the outcome a bit from previous times. I have not looked at the >> TCP over UPD library Justin mentioned but, at casual glance, I noticed is >> around 400 lines of code which is very small, which is cool. But given the >> lines of code in say the BSD TCP stack, it does make me wonder what's >> missing. That said, I don't think we need something with the perforce of the >> BSD TCP stack as long as what is there is TCP friendly and robust. >> > I believe this is the current URL: > > http://code.google.com/p/**libjingle/source/browse/trunk/** > talk/session/tunnel/**pseudotcpchannel.cc(500 or so lines). > > The real protocol implementation is here: > http://code.google.com/p/**libjingle/source/browse/trunk/** > talk/p2p/base/pseudotcp.cc > which is another 1000 lines (not counting the various .h files). > > We're not THAT good at writing compact code :-) > Yes, I was going to send a similar email. There are some deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do path MTU discovery, no checksum, no OOB data - but it is based on TCP and implements slow start and other congestion avoidance mechanisms, and is actively used by a number of applications where reliable transfer is important, such as file transfer and remote desktop applications. > >> >> >> >> ______________________________**_________________ >> 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 > --000e0cd56f26c0b79004a8820279 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2011 at 9:15 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
On 07/20/11 03:13, Cullen Jennings wrote:
On Jul 18, 2011, at 15:11 , Randell Jesup wrote:

All that said - yes, there are complexity issues to consider, which was why= I was suggesting leveraging
an existing tunneled protocol like SCTP or even TCP-over-UDP.
I agree with bunch of what you are saying but the previous several times I&= #39;ve seen the use SCTP over UDP conversation, it usually ends about the p= oint the we ask for a user land implementation. Whatever we do more or less= has to be user land or already exist in the OS that people run browsers on= .

If someone has a user land implementation of SCTP or TCP, I imagine that mi= ght change the outcome a bit from previous times. I have not looked at the = TCP over UPD library Justin mentioned but, at casual glance, I noticed is a= round 400 lines of code which is very small, which is cool. But given the l= ines of code in say the BSD TCP stack, it does make me wonder what's mi= ssing. That said, I don't think we need something with the perforce of = the BSD TCP stack as long as what is there is TCP friendly and robust.
I believe this is the current URL:

http://code.google.com/p/= libjingle/source/browse/trunk/talk/session/tunnel/pseu= dotcpchannel.cc (500 or so lines).

The real protocol implementation is here:
http://code.google.com/p/libjin= gle/source/browse/trunk/talk/p2p/base/pseudotcp.cc
which is another 1000 lines (not counting the various .h files).

We're not THAT good at writing compact code :-)
Yes, I was going to send a similar email. There are some defic= iencies/optimizations for the fact it runs over ICE-UDP - doesn't do pa= th MTU discovery, no checksum, no OOB data - but it is based on TCP and imp= lements slow start and other congestion avoidance mechanisms, and is active= ly used by a number of applications where reliable transfer is important, s= uch as file transfer and remote desktop applications.
=C2=A0




_______________________________________________
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

--000e0cd56f26c0b79004a8820279-- From john.elwell@siemens-enterprise.com Wed Jul 20 08:38: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 A72A321F8797 for ; Wed, 20 Jul 2011 08:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.287 X-Spam-Level: X-Spam-Status: No, score=-104.287 tagged_above=-999 required=5 tests=[AWL=-1.688, 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 g61dQYIy8o0r for ; Wed, 20 Jul 2011 08:38:32 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 012EB21F899F for ; Wed, 20 Jul 2011 08:38:32 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 379211EB8434; Wed, 20 Jul 2011 17:38:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 20 Jul 2011 17:38:31 +0200 From: "Elwell, John" To: Magnus Westerlund , "rtcweb@ietf.org" Date: Wed, 20 Jul 2011 17:38:30 +0200 Thread-Topic: [rtcweb] To multiplex or not! Thread-Index: AcxGIB/v150z8iXwRzGRZkWngNnr9QA0e8Vg Message-ID: References: <4E259484.20509@ericsson.com> In-Reply-To: <4E259484.20509@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 15:38:36 -0000 =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: 19 July 2011 15:28 > To: rtcweb@ietf.org > Subject: [rtcweb] To multiplex or not! >=20 > Hi, >=20 > This email is as an individual contributor. >=20 > I want to get started on the discussion of the Multiplexing of the > various protocols over single lower layer transport flow,=20 > such as a UDP > flow. I will attempt to split up the questions into different emails. >=20 > The first question I think is reasonably easy to get answered, but I > think it is time we determine if my belief in the answer is=20 > correct or not. >=20 > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: >=20 > a) MUST be sent as Individual flows for each component. >=20 > b) MUST be multiplexed into a single transport flow. >=20 > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. [JRE] As soon as we start talking about what an RTCWEB peer MUST support, t= he question arises whether this applies to the browser, the script or both.= For example, a browser might implement each PeerConnection object over sep= arate transports, but if the script chooses to use a single PeerConnection = object for both audio and video it might not be interoperable with a peer t= hat doesn't support multiplexing. So whilst I agree that picking something along the lines of c) might be pos= sible, we would need to define more precisely what we mean before coming to= such an agreement. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > I would love if people can indicate their choice or preferences. >=20 > I personally prefer A as it it is simplest in all aspect=20 > except the NAT > traversal. > - It allows for flow based QoS. > - It is the what the implementation that exist mostly do > - Signaling protocols that exist support it, no extra functionality > - People are used to the concept > - It minimizes the difference to legacy. >=20 > Thus it is the quickest road to define something with the least formal > push back and concern over maturity of any solution. >=20 > The downside with B and C is that we do have to solve the multiplexing > and get an agreement that gets through all the hurdles. >=20 > Of these two opens I do prefer C. Although it results in the extra > complexities of having both alternatives, it will give us both a > fallback, flow based QoS and better legacy support. >=20 > Now it is your time to make your opinion heard! >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From harald@alvestrand.no Wed Jul 20 08:50: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 A48D621F8A66 for ; Wed, 20 Jul 2011 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 lDCZ3VPQS1aL for ; Wed, 20 Jul 2011 08:50:27 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7447F21F899F for ; Wed, 20 Jul 2011 08:50:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F06F939E0FE for ; Wed, 20 Jul 2011 17:49:20 +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 n01mk3l28PFJ for ; Wed, 20 Jul 2011 17:49: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 6509439E072 for ; Wed, 20 Jul 2011 17:49:16 +0200 (CEST) Message-ID: <4E26F93D.8040604@alvestrand.no> Date: Wed, 20 Jul 2011 17:50:21 +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: <4E259484.20509@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 15:50:31 -0000 On 07/20/11 17:38, Elwell, John wrote: > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: 19 July 2011 15:28 >> To: rtcweb@ietf.org >> Subject: [rtcweb] To multiplex or not! >> >> Hi, >> >> This email is as an individual contributor. >> >> I want to get started on the discussion of the Multiplexing of the >> various protocols over single lower layer transport flow, >> such as a UDP >> flow. I will attempt to split up the questions into different emails. >> >> The first question I think is reasonably easy to get answered, but I >> think it is time we determine if my belief in the answer is >> correct or not. >> >> The traffic between two RTCWEB peers from the various components, such= >> as RTP sessions, datagram service: >> >> a) MUST be sent as Individual flows for each component. >> >> b) MUST be multiplexed into a single transport flow. >> >> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB >> peer MUST be able to send them as individual flows. > [JRE] As soon as we start talking about what an RTCWEB peer MUST suppor= t, the question arises whether this applies to the browser, the script or= both. For example, a browser might implement each PeerConnection object = over separate transports, but if the script chooses to use a single PeerC= onnection object for both audio and video it might not be interoperable w= ith a peer that doesn't support multiplexing. It's not at all obvious to me how we map PeerConnection objects to RTP=20 sessions. It might be that there can only be a single PeerConnection=20 object to a specific remote peer, and that the PeerConnection object=20 decides internally how to map media streams to RTP sessions (for=20 instance). Or indeed where that mapping ought to be specified. In the IETF, we may want to concentrate on what the packets should be on = the wire; in the W3C, we may want to concentrate on making the API=20 powerful enough and easy enough to use - sooner or later, all the pieces = have to match up, though. > So whilst I agree that picking something along the lines of c) might be= possible, we would need to define more precisely what we mean before com= ing to such an agreement. > > John > > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0= DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of Si= emens AG. > > > >> I would love if people can indicate their choice or preferences. >> >> I personally prefer A as it it is simplest in all aspect >> except the NAT >> traversal. >> - It allows for flow based QoS. >> - It is the what the implementation that exist mostly do >> - Signaling protocols that exist support it, no extra functionality >> - People are used to the concept >> - It minimizes the difference to legacy. >> >> Thus it is the quickest road to define something with the least formal= >> push back and concern over maturity of any solution. >> >> The downside with B and C is that we do have to solve the multiplexing= >> and get an agreement that gets through all the hurdles. >> >> Of these two opens I do prefer C. Although it results in the extra >> complexities of having both alternatives, it will give us both a >> fallback, flow based QoS and better legacy support. >> >> Now it is your time to make your opinion heard! >> >> Cheers >> >> Magnus Westerlund >> >> ----------------------------------------------------------------------= >> Multimedia Technologies, Ericsson Research EAB/TVM >> ----------------------------------------------------------------------= >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ----------------------------------------------------------------------= >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From bernard_aboba@hotmail.com Wed Jul 20 08: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 A93A321F89C1 for ; Wed, 20 Jul 2011 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBGjklWHrcjn for ; Wed, 20 Jul 2011 08:53:20 -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 B46F021F86B9 for ; Wed, 20 Jul 2011 08:53:20 -0700 (PDT) Received: from BLU152-W34 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 08:53:20 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0e6491f5-f097-4c25-a02d-2326213cd974_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Magnus Westerlund , Date: Wed, 20 Jul 2011 08:53:19 -0700 Importance: Normal In-Reply-To: References: <4E259484.20509@ericsson.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2011 15:53:20.0260 (UTC) FILETIME=[25D5C440:01CC46F5] Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 15:53:21 -0000 --_0e6491f5-f097-4c25-a02d-2326213cd974_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > c) SHOULD be multiplexed into a single transport flow=2C but the RTCWEB > > peer MUST be able to send them as individual flows. > [JRE] As soon as we start talking about what an RTCWEB peer MUST support= =2C the question arises whether this applies to the browser=2C the script o= r both. For example=2C a browser might implement each PeerConnection object= over separate transports=2C but if the script chooses to use a single Peer= Connection object for both audio and video it might not be interoperable wi= th a peer that doesn't support multiplexing. >=20 > So whilst I agree that picking something along the lines of c) might be p= ossible=2C we would need to define more precisely what we mean before comin= g to such an agreement. [BA] .MUST support sending as individual flows makes sense to me=2C but mak= ing normative statements about multiplexing onto a single transport doesn't= . If both sides support multiplexing into a single transport flow=2C then= it can be negotiated and used.=20 = --_0e6491f5-f097-4c25-a02d-2326213cd974_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B >=3B c) SHOULD be multiplexed into a single transport flo= w=2C but the RTCWEB
>=3B >=3B peer MUST be able to send them as indi= vidual flows.
>=3B [JRE] As soon as we start talking about what an RTC= WEB peer MUST support=2C the question arises whether this applies to the br= owser=2C the script or both. For example=2C a browser might implement each = PeerConnection object over separate transports=2C but if the script chooses= to use a single PeerConnection object for both audio and video it might no= t be interoperable with a peer that doesn't support multiplexing.
>=3B=
>=3B So whilst I agree that picking something along the lines of c) = might be possible=2C we would need to define more precisely what we mean be= fore coming to such an agreement.

[BA] .MUST support sending as indi= vidual flows makes sense to me=2C but making normative statements about mul= tiplexing onto a single transport doesn't. =3B =3B If both sides su= pport multiplexing into a single transport flow=2C then it can be negotiate= d and used.
= --_0e6491f5-f097-4c25-a02d-2326213cd974_-- From fluffy@cisco.com Wed Jul 20 10:59: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 B20F421F8B28 for ; Wed, 20 Jul 2011 10:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.839 X-Spam-Level: X-Spam-Status: No, score=-103.839 tagged_above=-999 required=5 tests=[AWL=-1.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 UwfKF1C7gN4b for ; Wed, 20 Jul 2011 10:59:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6F14321F8B0D for ; Wed, 20 Jul 2011 10:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=305; q=dns/txt; s=iport; t=1311184774; x=1312394374; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=cP3abptTRzZWO0hxlg5Wc2IQsV5BxjCTXoTOBcvKE7s=; b=kCyfiLwvur36b0GhFww8bBz9t5Si8+Pv085ros3wCfJk5GKQrRNFEFRF L6Rhpz/d/ZEXQqNWPu3znjh9V2m6nFjzE01oXZtyJVXk4Vhfhx8vio9/f bRS6aQU5ZhrSOUg5ZymQATfgtLtyN2Lcw1vw6CMYvUurT5mxTKI6H9fs2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowHAJoWJ06rRDoJ/2dsb2JhbABTmF+PB3eqFIEjniyFXl8Eh1WLGYUHi3Y X-IronPort-AV: E=Sophos;i="4.67,236,1309737600"; d="scan'208";a="4815584" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 20 Jul 2011 17:59:34 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6KHxXm8032700 for ; Wed, 20 Jul 2011 17:59:33 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 10:59:32 -0700 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 17:59:46 -0000 Many home NATs support DSCP based QoS and it does help. I think that the = IETF should recommend that some default DSCP for audio and video from = the browser as well as suggest there should be an API to set the DSCP = for different media steam.=20 Cullen From dzonatas@gmail.com Wed Jul 20 11:34: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 C202121F8B1C for ; Wed, 20 Jul 2011 11:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[AWL=-1.248, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1COObrc5I13 for ; Wed, 20 Jul 2011 11:34:49 -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 8CA2C21F8A1A for ; Wed, 20 Jul 2011 11:34:49 -0700 (PDT) Received: by pvh18 with SMTP id 18so578888pvh.31 for ; Wed, 20 Jul 2011 11:34:49 -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=GVIa+Y3k+EUhDa4MN/t6mV9xKajEn6p8nj91Zf/+LFI=; b=b3D6CngYa3AlKoymRgKuKRISbdNPmkoQdZJHvTLQ5Fn4hinR5JXMNalaB5Oj+vrPZt lg8jzqmWcJ1MnntYYgQXZO9M9mcdaatbH8mncW9D427M7BbOsbA2M8+t67XZxaaZfOim vGztIdNPO6ZhCsnd9WppGXQOTnvh2U/vFmouo= Received: by 10.68.6.138 with SMTP id b10mr1020727pba.160.1311186889224; Wed, 20 Jul 2011 11:34:49 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id d1sm280062pbj.8.2011.07.20.11.34.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 11:34:48 -0700 (PDT) Message-ID: <4E271FD0.4080208@gmail.com> Date: Wed, 20 Jul 2011 11:34:56 -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] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 18:34:53 -0000 On 07/20/2011 10:59 AM, Cullen Jennings wrote: > Many home NATs support DSCP based QoS and it does help. I think that the IETF should recommend that some default DSCP for audio and video from the browser as well as suggest there should be an API to set the DSCP for different media steam. > > Cullen > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > XML entities with DNA-like name sequences, I knew there was some use for these non-aspects. If DSCP is t.co or G.co aware, then &co.G.sequence...; is possible for speedy QoS. I haven't found any reason for AOT and JIT namespaces to conflict in such entities. It's just not as automated as some desire, yet could be universally coincidental. No need to make these "far" synopsis any harder for internationalization of such namespaces. Glad ICE continues to support direct IPv4 override, hypervisors still need this mode for games. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From sergel@google.com Wed Jul 20 12:11: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 25DAE21F86DC for ; Wed, 20 Jul 2011 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.300, 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 lxwhR+DLN4rH for ; Wed, 20 Jul 2011 12:11: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 4B58121F86D1 for ; Wed, 20 Jul 2011 12:11:49 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p6KJBmHg014927 for ; Wed, 20 Jul 2011 12:11:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311189108; bh=hSmMcVDZZ8nPnB09f9apriX7y9o=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=XcCbQFuSl54TvBb+4NipXsthxO4cS3odwZdrd5uthpglsmeTORS82HWyPZjCOznAJ AeBpWVk1lmZacKr5LXfCA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=xmCyHcYKrEq01CcjpvL7IM1jhF7Keyd4V9KAv2zs0i5JAwnnHlvqpnzpVdxaP443j VryW8R7NTxnO8MQDBmmSA== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by wpaz13.hot.corp.google.com with ESMTP id p6KJB1v6010518 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 12:11:47 -0700 Received: by yxl11 with SMTP id 11so342696yxl.35 for ; Wed, 20 Jul 2011 12:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mJGYCAsL3dq916PPc4T9XsZax0YGaRkuyD4BlmhXJNc=; b=mLMUAGbTyqTeSl4xcuVLVKCIrPXiZ1LdZoJ6GbmthVJV6TGmDFFS20pvjI7vEuonyj rdDSmxS8Pi0YH3XMieFw== Received: by 10.150.200.19 with SMTP id x19mr8250762ybf.264.1311189107240; Wed, 20 Jul 2011 12:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.201.18 with HTTP; Wed, 20 Jul 2011 12:11:17 -0700 (PDT) In-Reply-To: <4E26F460.3080007@jesup.org> References: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> <4E26A354.2020306@ericsson.com> <4E26F460.3080007@jesup.org> From: Serge Lachapelle Date: Wed, 20 Jul 2011 21:11:17 +0200 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=000e0cd348baf86d5504a885006f X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 19:11:50 -0000 --000e0cd348baf86d5504a885006f Content-Type: text/plain; charset=ISO-8859-1 > > > For other cases (file xfer), yes you can use those - but the problem is > that when you want to transfer to the person you're chatting with, you would > need to use another service, agree on it, deal with the > semantics/accounts/limits/etc for that service, etc. A horrible user > experience. Even if it was "hidden" by the application, it would be > problematic and subject to breakage continually. If I am building a 1:1 or hangout style application connecting my users, I would simply integrate it or add the functionality in the web UI I am building. This is very easy to do with web services these days. /Serge --000e0cd348baf86d5504a885006f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

For other cases (file xfer), yes you can use those - but the problem is tha= t when you want to transfer to the person you're chatting with, you wou= ld need to use another service, agree on it, deal with the semantics/accoun= ts/limits/etc for that service, etc. =A0A horrible user experience. =A0Even= if it was "hidden" by the application, it would be problematic a= nd subject to breakage continually.

If I am building a 1:1 or hangout style application con= necting my users, I would simply integrate it or add the functionality in t= he web UI I am building. This is very easy to do with web services these da= ys.

/Serge
--000e0cd348baf86d5504a885006f-- From juberti@google.com Wed Jul 20 12:39: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 9D8C121F8AD6 for ; Wed, 20 Jul 2011 12:39:26 -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 tRbd4pWIf+W2 for ; Wed, 20 Jul 2011 12:39:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0B31321F8ACC for ; Wed, 20 Jul 2011 12:39:25 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p6KJdPfq013993 for ; Wed, 20 Jul 2011 12:39:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311190765; bh=dp2Ondibz6qGFEnHDoLr+KJFQ6w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bAvIcktOkTL1MhhYxASqSEIk/dxYiTO2Dcop7+LwNftbkjCih9thg/JSh+0cASCLD /DYFXAyF3D7aBtM7yWIxg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=rgRFqk1acukUy4QrgeVKx+gn9a2Rn2rmFRak2rf5FmLWzWvCn28megOh5XLLpuoYi Vp5AV30QMcUFC0z+W9dpg== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by wpaz37.hot.corp.google.com with ESMTP id p6KJc2p4010268 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 12:39:24 -0700 Received: by qyk30 with SMTP id 30so3346018qyk.13 for ; Wed, 20 Jul 2011 12:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UpMfwbq5GqV0vNwBiPrdD1lx7baXgu4z8/TYNDyWO1U=; b=LT/d9dfxR0ODNyZAzlaV4KQkVz3NVL/it3gHvcfyFMNtrp68T2p91qx4pFNXi6B21T yz/cWb6qGCjBe1UHRQRQ== Received: by 10.229.77.38 with SMTP id e38mr5665109qck.151.1311190764146; Wed, 20 Jul 2011 12:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.81 with HTTP; Wed, 20 Jul 2011 12:39:04 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 20 Jul 2011 15:39:04 -0400 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=00235447193cbacfd004a885633a X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 19:39:26 -0000 --00235447193cbacfd004a885633a Content-Type: text/plain; charset=UTF-8 Can you go into more detail about what these NATs do with the DSCP markings? I'm not convinced we want to expose a generic API for this (too easy to misuse), but I think it definitely makes sense for implementations to set appropriate markings on audio and video packets, including different levels on individual video packets when using hierarchical prediction structures. On Wed, Jul 20, 2011 at 1:59 PM, Cullen Jennings wrote: > > Many home NATs support DSCP based QoS and it does help. I think that the > IETF should recommend that some default DSCP for audio and video from the > browser as well as suggest there should be an API to set the DSCP for > different media steam. > > Cullen > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00235447193cbacfd004a885633a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you go into more detail about what these NATs do with the DSCP markings= ?

I'm not convinced we want to expose a generic API = for this (too easy to misuse), but I think it definitely makes sense for im= plementations to set appropriate markings on audio and video packets, inclu= ding different levels on individual video packets when using hierarchical p= rediction structures.

On Wed, Jul 20, 2011 at 1:59 PM, Cullen Jenn= ings <fluffy@cisco= .com> wrote:

Many home NATs support DSCP based QoS and it does help. I think that the IE= TF should recommend that some default DSCP for audio and video from the bro= wser as well as suggest there should be an API to set the DSCP for differen= t media steam.

Cullen <with my individual contributor hat on>

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

--00235447193cbacfd004a885633a-- From juberti@google.com Wed Jul 20 12:46: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 9286E21F8A62 for ; Wed, 20 Jul 2011 12:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.559 X-Spam-Level: X-Spam-Status: No, score=-105.559 tagged_above=-999 required=5 tests=[AWL=0.417, 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 h112umendrvR for ; Wed, 20 Jul 2011 12:46:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9EC21F86D1 for ; Wed, 20 Jul 2011 12:46:49 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p6KJkmiU003724 for ; Wed, 20 Jul 2011 12:46:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311191208; bh=mDT652UmAqoceShNXfTuaK4luOc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZQ0bfmGRy/tuV2gV8Hh+QGiu56OpY+Z8O2GXP//abnm8fmL6FI6LrNPRbjXsNEFNE Bf4coZUgxa/85U97Dj4Wg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=bJvzJWZZGDUiycW+TRC3Yxi7v6B5j4IXyqABiQo0t5TlYCSfzHJD3alAEttrLaXJO uXUKv7gHyeWv5U4T+Atvg== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by hpaq7.eem.corp.google.com with ESMTP id p6KJkkYc012448 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 12:46:47 -0700 Received: by qyk9 with SMTP id 9so3740756qyk.10 for ; Wed, 20 Jul 2011 12:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CGOjBKJYAduiUrnltqwhakgIzU4Qny0yZZX11coL3yQ=; b=uHT1c4S4WoYf/g1QJPDZRqGxDKRgauUHpCpaj/2/LEhasZpkpGtrkB1+4GXoTHv+9a L6QKO+q+N1O1vZQXJwDA== Received: by 10.229.250.203 with SMTP id mp11mr7330039qcb.37.1311191206219; Wed, 20 Jul 2011 12:46:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.81 with HTTP; Wed, 20 Jul 2011 12:46:26 -0700 (PDT) In-Reply-To: References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> From: Justin Uberti Date: Wed, 20 Jul 2011 15:46:26 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=0016364ec992144f4704a8857e3b X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 19:46:50 -0000 --0016364ec992144f4704a8857e3b Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2011 at 10:18 AM, Bernard Aboba wrote: > > > Timing is a real problem. If we want to do multiplexing in RTCWEB 1.0 we > > need to pick what is ready and available. We can't go around proposing > > new things that are complicated. Changing the SSRC field semantics in > > RTP/RTCP is a complicated thing. > > [BA] We need to ask ourselves "Does this really need to be in the critical > path for RTCWEB 1.0"? > As I understand it, this would be a negotiated feature, and presumably all > implementations > would be required to support RTP/RTCP as defined in RFC 3550 and suitable > profiles. > So from my perspective, I'd prefer to see this handled as an extension on > its own path, not a > mandatory-to-implement feature in 1.0. > This is where I've ended up on this topic. We can easily multiplex multiple RTP sources (of the same type) over a single RTP session using SSRC. We can also mux RTCP over the RTP session using RTCP mux. So, for an arbitrary video call, we have just 2 RTP sessions/NAT bindings. Is it worth going the extra mile to get down to 1 in v1.0, given the lack of consensus that exists right now? Is there even a compelling argument to do so? > > > > Isn't that gateway going to be present anyway in most case. I think the > > ICE connectivity checks are one thing that will force a gateway in many > > cases. In the cases it isn't needed, then you can skip the multiplexing > > in that case to reach the legacy. > > [BA] Just because we're likely to require a gateway doesn't mean we should > heap more and more things on the camel's back. We're already talking about > ICE, shims, transcoding, changes to RFC 3550.... that's a lot of > functionality > for the "gateway". So I agree with Jonathan about the disadvantages of a > shim > (or DCCP for that matter). > > > > The big difference is that we either have a well reviewed and by the > > community and IESG approved specification in DCCP. Or we create > > something our selves that needs to go through all that review and will > > be even less tested than DCCP is. > > [BA] Deployment counts, too. How widely deployed is DCCP for realtime > uses? > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0016364ec992144f4704a8857e3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2011 at 10:18 AM, Bernar= d Aboba <bernard_aboba@hotmail.com> wrote:

> Timing is a real problem. If we want to do multiplexing = in RTCWEB 1.0 we
> need to pick what is ready and available. We can&#= 39;t go around proposing
> new things that are complicated. Changing = the SSRC field semantics in
> RTP/RTCP is a complicated thing.

[BA] We need to ask ours= elves "Does this really need to be in the critical path for RTCWEB 1.0= "?=C2=A0
As I understand it, this would be a negotiated feature, a= nd presumably all implementations
would be required to support RTP/RTCP as defined in RFC 3550 and suitable p= rofiles.
So from my perspective, I'd prefer to see this handled as = an extension on its own path, not a
mandatory-to-implement feature in 1= .0.=C2=A0=C2=A0

This is where I've e= nded up on this topic. We can easily multiplex multiple RTP sources (of the= same type) over a single RTP session using SSRC. We can also mux RTCP over= the RTP session using RTCP mux. So, for an arbitrary video call, we have j= ust 2 RTP sessions/NAT bindings.=C2=A0

Is it worth going the extra mile to get down to 1 in v1= .0, given the lack of consensus that exists right now? Is there even a comp= elling argument to do so?


> Isn't that gateway going t= o be present anyway in most case. I think the
> ICE connectivity chec= ks are one thing that will force a gateway in many
> cases. In the ca= ses it isn't needed, then you can skip the multiplexing
> in that case to reach the legacy.

[BA] Just because we= 9;re likely to require a gateway doesn't mean we should
heap more an= d more things on the camel's back.=C2=A0 We're already talking abou= t
ICE, shims, transcoding, changes to RFC 3550....=C2=A0 that's a lot of = functionality
for the "gateway".=C2=A0 So I agree with Jonatha= n about the disadvantages of a shim
(or DCCP for that matter).


> The big difference is that we either have a well reviewed and = by the
> community and IESG approved specification in DCCP. Or we cre= ate
> something our selves that needs to go through all that review a= nd will
> be even less tested than DCCP is.

[BA] Deployment counts,= too.=C2=A0 How widely deployed is DCCP for realtime uses?



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


--0016364ec992144f4704a8857e3b-- From matthew.kaufman@skype.net Wed Jul 20 12:51: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 E44D121F86D7 for ; Wed, 20 Jul 2011 12:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 HBID1w8uSwpS for ; Wed, 20 Jul 2011 12:51:18 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF921F86D6 for ; Wed, 20 Jul 2011 12:51:17 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 966CD1708; Wed, 20 Jul 2011 21:51:16 +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=iK 49D8pS+ll8uzgGf2qJcFSq67Y=; b=ZvVOkNoT2H6kcmfCrWc5gZ2hR8GRkpDaln 1TdSO9R4lc/jUa0f9OugEaLdsJIc1LP6zhl4sfbm3ZmBtFompihcbH1Vz73VYmR5 akfhdUzuGZsTJ+BJgKe7O/cIs9yW+Z06ZaTmhepovyPigH4gmfFXvXhM0RG89wMA 4ixeD9rF0= 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=N47oXiQFqGcQcRu3QtXnQn cOHs7fIRcwA3XVSDgszXWExhlnzpjagTwQ07GpxZVYlm3yssh/dZo4hVhz7ELCvl a8IbUcRknEcriHYmYN7bGKBMgYeVjsInQZyresi4lDmc7zqLQYA02OGfpgvjHAQB nJtIy10mYCixin9u7fjDA= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 94C597FC; Wed, 20 Jul 2011 21:51:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 6DD1135080C2; Wed, 20 Jul 2011 21:51:16 +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 jPdQLJ+PGkIE; Wed, 20 Jul 2011 21:51:15 +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 2BD6C3507E96; Wed, 20 Jul 2011 21:51:15 +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, 20 Jul 2011 12:51:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> To: Justin Uberti X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 19:51:22 -0000 On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote: >=20 > This is where I've ended up on this topic. We can easily multiplex = multiple RTP sources (of the same type) over a single RTP session using = SSRC. We can also mux RTCP over the RTP session using RTCP mux. So, for = an arbitrary video call, we have just 2 RTP sessions/NAT bindings.=20 >=20 > Is it worth going the extra mile to get down to 1 in v1.0, given the = lack of consensus that exists right now? Is there even a compelling = argument to do so? Yes and yes. I really can't understand why, if we can multiplex 3 totally different = types of video streams over the same RTP session using SSRC (with wildly = different bit-rates, inter-packet times, etc.) we can't also multiplex = audio and video. Not a single argument that has been presented has = convinced me, and getting from 2 to 1 is a *50%* reduction in NAT port = utilization. (And a significant reduction in the number of "strange" = failure modes, where one traversal worked and the other didn't.) Matthew Kaufman From juberti@google.com Wed Jul 20 12: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 83E1721F8AF0 for ; Wed, 20 Jul 2011 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.698 X-Spam-Level: X-Spam-Status: No, score=-105.698 tagged_above=-999 required=5 tests=[AWL=0.278, 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 cxl5ttTnQabE for ; Wed, 20 Jul 2011 12:59:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5312F21F8880 for ; Wed, 20 Jul 2011 12:59:41 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p6KJxeXY015062 for ; Wed, 20 Jul 2011 12:59:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311191980; bh=CMa8RSo3zBIWR6vvX/0ZZkQ2A18=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nQXnXQQ4BjgYA3xdiK9TBPmrCLYoReeNjvoHgkkwkeATcNlRT0CDKOlLLJGmj2PAr si6ge09LGhEfmwMZIYUcQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=FKRwbCl228mjHflQPEf5WehPx8ggJyanlXg/1LJDkiYq7wf95MfYlQzMn97taTdbi IejNAo1wtlw9kGeiCzzIw== Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by hpaq1.eem.corp.google.com with ESMTP id p6KJxcDQ005423 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 12:59:39 -0700 Received: by qyk32 with SMTP id 32so3557510qyk.14 for ; Wed, 20 Jul 2011 12:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7UipEC62w2V3thvCjUDXgD5klwahLMKI8EYfaXteJlQ=; b=MqoLa2pmrPVyQielWIwIlmxRdbkABf0Zko8lxOGWvLBUfUswRJgVYaT/RKlKAlPdzA yO+mpjVFo0dLP5/dJGwg== Received: by 10.229.77.38 with SMTP id e38mr5683947qck.151.1311191978134; Wed, 20 Jul 2011 12:59:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.81 with HTTP; Wed, 20 Jul 2011 12:59:18 -0700 (PDT) In-Reply-To: <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> From: Justin Uberti Date: Wed, 20 Jul 2011 15:59:18 -0400 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=00235447193c16cea904a885acff X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 19:59:42 -0000 --00235447193c16cea904a885acff Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2011 at 3:51 PM, Matthew Kaufman wrote: > > On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote: > > > > > This is where I've ended up on this topic. We can easily multiplex > multiple RTP sources (of the same type) over a single RTP session using > SSRC. We can also mux RTCP over the RTP session using RTCP mux. So, for an > arbitrary video call, we have just 2 RTP sessions/NAT bindings. > > > > Is it worth going the extra mile to get down to 1 in v1.0, given the lack > of consensus that exists right now? Is there even a compelling argument to > do so? > > Yes and yes. > > I really can't understand why, if we can multiplex 3 totally different > types of video streams over the same RTP session using SSRC (with wildly > different bit-rates, inter-packet times, etc.) we can't also multiplex audio > and video. Not a single argument that has been presented has convinced me, > and getting from 2 to 1 is a *50%* reduction in NAT port utilization. (And a > significant reduction in the number of "strange" failure modes, where one > traversal worked and the other didn't.) > Clearly we can, but we need to do additional work to get there. This work will take time and delay v1.0, so we need a pretty convincing rationale to do so. I concur that solving strange failure modes is significant. But with regard to NAT port utilization, this ignores the utilization by the browser for HTTP; 50% reduction seems possible in theory only. (Here I am essentially restating 2.2.2 from https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1, which I haven't yet seen a clear response to.) > Matthew Kaufman > > --00235447193c16cea904a885acff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2011 at 3:51 PM, Matthew= Kaufman <matthew.kaufman@skype.net> wrote:

On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote:

>
> This is where I've ended up on this topic. We can easily multiplex= multiple RTP sources (of the same type) over a single RTP session using SS= RC. We can also mux RTCP over the RTP session using RTCP mux. So, for an ar= bitrary video call, we have just 2 RTP sessions/NAT bindings.
>
> Is it worth going the extra mile to get down to 1 in v1.0, given the l= ack of consensus that exists right now? Is there even a compelling argument= to do so?

Yes and yes.

I really can't understand why, if we can multiplex 3 totally different = types of video streams over the same RTP session using SSRC (with wildly di= fferent bit-rates, inter-packet times, etc.) we can't also multiplex au= dio and video. Not a single argument that has been presented has convinced = me, and getting from 2 to 1 is a *50%* reduction in NAT port utilization. (= And a significant reduction in the number of "strange" failure mo= des, where one traversal worked and the other didn't.)

Clearly we can, but we need to do addition= al work to get there. This work will take time and delay v1.0, so we need a= pretty convincing rationale to do so.

I concur th= at solving strange failure modes is significant. But with regard to NAT por= t utilization, this ignores the utilization by the browser for HTTP; 50% re= duction seems possible in theory only. (Here I am essentially restating 2.2= .2 from=C2=A0https://datatracker.ietf.org/doc/draft-perk= ins-rtcweb-rtp-usage/?include_text=3D1, which I haven't yet seen a = clear response to.)





Matthew Kaufman


--00235447193c16cea904a885acff-- From sergel@google.com Wed Jul 20 13:01: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 41FD021F84E4 for ; Wed, 20 Jul 2011 13:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 rnRe76LB9V-6 for ; Wed, 20 Jul 2011 13:01:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1195D21F87D3 for ; Wed, 20 Jul 2011 13:01:05 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p6KK14Jc014368 for ; Wed, 20 Jul 2011 13:01:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311192065; bh=pxYvVGdXRt/47rk+emWzgIDoorg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pKIK93pKu8OSaVdP6uV5/DY63+iQpT3x7GEgvJCYeIY1S8F1E/ptS5TWaAuCWAtnd mH3owz5GGfotTHORwnTzg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ZdfeHrSN+Y3GkHQH/EYkOjt5BKW14IJPnxQTlGFbtsZ1irvjRrWgYDEJLEmWvq1rI gTFj2VTHyYeXkNSjnrUqA== Received: from gyh20 (gyh20.prod.google.com [10.243.50.212]) by kpbe11.cbf.corp.google.com with ESMTP id p6KK12GU016095 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 13:01:03 -0700 Received: by gyh20 with SMTP id 20so291052gyh.30 for ; Wed, 20 Jul 2011 13:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yS231gCgB6W+OibqbGWrYY+k+9svneUuyF2gpZRBXIQ=; b=Ek2QfoVSWy666cQYcQdg2PLU1egoEA3JvCbRZNF1QUGpZm+tP/wcaEH20vjVRrA7ko o4XDrkTCyU55KmJ15heg== Received: by 10.150.150.40 with SMTP id x40mr7651173ybd.207.1311192062335; Wed, 20 Jul 2011 13:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.201.18 with HTTP; Wed, 20 Jul 2011 13:00:32 -0700 (PDT) In-Reply-To: References: <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org> <4E26A354.2020306@ericsson.com> <4E26F460.3080007@jesup.org> From: Serge Lachapelle Date: Wed, 20 Jul 2011 22:00:32 +0200 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=000e0cd6cf081b9a8804a885b11a X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 20:01:11 -0000 --000e0cd6cf081b9a8804a885b11a Content-Type: text/plain; charset=ISO-8859-1 Just to put the file transfer debate to bed from my end, I am not against reliable channels, in fact, a ton of innovation can come from it when made available to browsers. I just want to avoid any re-engineering of what browsers offer today as much as possible. /Serge On Wed, Jul 20, 2011 at 21:11, Serge Lachapelle wrote: > >> For other cases (file xfer), yes you can use those - but the problem is >> that when you want to transfer to the person you're chatting with, you would >> need to use another service, agree on it, deal with the >> semantics/accounts/limits/etc for that service, etc. A horrible user >> experience. Even if it was "hidden" by the application, it would be >> problematic and subject to breakage continually. > > > If I am building a 1:1 or hangout style application connecting my users, I > would simply integrate it or add the functionality in the web UI I am > building. This is very easy to do with web services these days. > > /Serge > -- Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32 Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880 Apparently, this footer is required in Europe. Apologies. This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else,please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks. --000e0cd6cf081b9a8804a885b11a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to put the file transfer debate to bed from my end, I am not against r= eliable channels, in fact, a ton of innovation can come from it when made a= vailable to browsers.

I just want to avoid any re-engine= ering of what browsers offer today as much as possible.

/Serge

On Wed, Jul 20= , 2011 at 21:11, Serge Lachapelle <sergel@google.com> wrote:

For other cases (file xfer), yes you can use those - but the problem is tha= t when you want to transfer to the person you're chatting with, you wou= ld need to use another service, agree on it, deal with the semantics/accoun= ts/limits/etc for that service, etc. =A0A horrible user experience. =A0Even= if it was "hidden" by the application, it would be problematic a= nd subject to breakage continually.

If I am building a 1:1 or hangout style applicati= on connecting my users, I would simply integrate it or add the functionalit= y in the web UI I am building. This is very easy to do with web services th= ese days.

/Serge



--
Serge Lachapelle=A0|=A0Product Manager=A0|= =A0sergel@google.com= =A0|=A0+46 732 01 22 32
Google = Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880=A0

App= arently, this footer is required in Europe. Apologies. This email may be co= nfidential or privileged. =A0If you received this communication by mistake,= please don't forward it to anyone else,please erase all copies and att= achments, and please let me know that it went to the wrong person. =A0Thank= s.
--000e0cd6cf081b9a8804a885b11a-- From bernard_aboba@hotmail.com Wed Jul 20 13:37: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 E639A21F8511 for ; Wed, 20 Jul 2011 13:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 m7koYPsDG7x8 for ; Wed, 20 Jul 2011 13:37:40 -0700 (PDT) Received: from blu0-omc4-s3.blu0.hotmail.com (blu0-omc4-s3.blu0.hotmail.com [65.55.111.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3817421F8500 for ; Wed, 20 Jul 2011 13:37:40 -0700 (PDT) Received: from BLU152-W15 ([65.55.111.137]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 13:37:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6c07b856-6875-4b21-a8e4-840099774aef_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Wed, 20 Jul 2011 13:37:39 -0700 Importance: Normal In-Reply-To: References: , , , <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org>, , <4E26A354.2020306@ericsson.com> <4E26F460.3080007@jesup.org>, , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2011 20:37:39.0711 (UTC) FILETIME=[DE0F68F0:01CC471C] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 20:37:41 -0000 --_6c07b856-6875-4b21-a8e4-840099774aef_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agreed.=20 To make this a bit more concrete. From your perspective=2C what is the pre= ferred mechanism for file transfer in XMPP=2C and what would it take to sup= port this in a browser?=20 From: sergel@google.com Date: Wed=2C 20 Jul 2011 22:00:32 +0200 To: randell1@jesup.org CC: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service Just to put the file transfer debate to bed from my end=2C I am not against= reliable channels=2C in fact=2C a ton of innovation can come from it when = made available to browsers. I just want to avoid any re-engineering of what browsers offer today as muc= h as possible. /Serge On Wed=2C Jul 20=2C 2011 at 21:11=2C Serge Lachapelle w= rote: For other cases (file xfer)=2C yes you can use those - but the problem is t= hat when you want to transfer to the person you're chatting with=2C you wou= ld need to use another service=2C agree on it=2C deal with the semantics/ac= counts/limits/etc for that service=2C etc. A horrible user experience. Ev= en if it was "hidden" by the application=2C it would be problematic and sub= ject to breakage continually. If I am building a 1:1 or hangout style application connecting my users=2C = I would simply integrate it or add the functionality in the web UI I am bui= lding. This is very easy to do with web services these days. /Serge --=20 Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32 Google Sweden AB | Kungsbron 2=2C SE-111 22 Stockholm | Org. nr. 556656-688= 0=20 Apparently=2C this footer is required in Europe. Apologies. This email may = be confidential or privileged. If you received this communication by mista= ke=2C please don't forward it to anyone else=2Cplease erase all copies and = attachments=2C and please let me know that it went to the wrong person. Th= anks. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --_6c07b856-6875-4b21-a8e4-840099774aef_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Agreed.

To make this a bit more concrete. =3B From your perspec= tive=2C what is the preferred mechanism for file transfer in XMPP=2C and wh= at would it take to support this in a browser?

From: sergel@google.com
Date: Wed=2C 20 Jul 2011 22:00:32 +0200=
To: randell1@jesup.org
CC: rtcweb@ietf.org
Subject: Re: [rtcweb] = realiable data service

Just to put the file transfer debate to bed f= rom my end=2C I am not against reliable channels=2C in fact=2C a ton of inn= ovation can come from it when made available to browsers.

I just want to avoid any re-engineering of what browsers offer today as m= uch as possible.

/Serge

On Wed=2C J= ul 20=2C 2011 at 21:11=2C Serge Lachapelle <=3Bsergel@google.com>=3B wrote:
=

For other cases (file xfer)=2C yes you can use those - but the problem is t= hat when you want to transfer to the person you're chatting with=2C you wou= ld need to use another service=2C agree on it=2C deal with the semantics/ac= counts/limits/etc for that service=2C etc.  =3BA horrible user experien= ce.  =3BEven if it was "hidden" by the application=2C it would be probl= ematic and subject to breakage continually.

If I am building a 1:1 or hangout style applicati= on connecting my users=2C I would simply integrate it or add the functional= ity in the web UI I am building. This is very easy to do with web services = these days.

/Serge



--
Serge Lachapelle =3B| =3BProduct Manager =3B| =3Bsergel@google.com&n= bsp=3B| =3B+46 732 01 22 32
Goog= le Sweden AB | Kungsbron 2=2C SE-111 22 Stockholm | Org. nr. 556656-6880&nb= sp=3B

Apparently=2C this footer is required in Europe. Apologies. This = email may be confidential or privileged.  =3BIf you received this commu= nication by mistake=2C please don't forward it to anyone else=2Cplease eras= e all copies and attachments=2C and please let me know that it went to the = wrong person.  =3BThanks.

_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
= --_6c07b856-6875-4b21-a8e4-840099774aef_-- From bernard_aboba@hotmail.com Wed Jul 20 13:43: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 7329021F862F for ; Wed, 20 Jul 2011 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, 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 Og2tEwOUvTv1 for ; Wed, 20 Jul 2011 13:43:05 -0700 (PDT) Received: from blu0-omc1-s29.blu0.hotmail.com (blu0-omc1-s29.blu0.hotmail.com [65.55.116.40]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CA21F85F3 for ; Wed, 20 Jul 2011 13:43:05 -0700 (PDT) Received: from BLU152-W25 ([65.55.116.9]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 13:43:05 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_af88799b-417d-40e8-95f9-e104fdc23fb8_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Date: Wed, 20 Jul 2011 13:43:04 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2011 20:43:05.0214 (UTC) FILETIME=[A01339E0:01CC471D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 20:43:09 -0000 --_af88799b-417d-40e8-95f9-e104fdc23fb8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think we're talking about things like support of WFA WMM. Not a NAT func= tion per se.=20 Some info on how this is implemented in the OS is available here.=20 Whether this actually accomplishes anything in practice is a subject of deb= ate.=20 From: juberti@google.com Date: Wed=2C 20 Jul 2011 15:39:04 -0400 To: fluffy@cisco.com CC: rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media Can you go into more detail about what these NATs do with the DSCP markings= ? I'm not convinced we want to expose a generic API for this (too easy to mis= use)=2C but I think it definitely makes sense for implementations to set ap= propriate markings on audio and video packets=2C including different levels= on individual video packets when using hierarchical prediction structures. On Wed=2C Jul 20=2C 2011 at 1:59 PM=2C Cullen Jennings w= rote: Many home NATs support DSCP based QoS and it does help. I think that the IE= TF should recommend that some default DSCP for audio and video from the bro= wser as well as suggest there should be an API to set the DSCP for differen= t media steam. Cullen _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --_af88799b-417d-40e8-95f9-e104fdc23fb8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think we're talking about things like support of WFA WMM. =3B Not a N= AT function per se.

Some info on how this is implemented in the OS = is available here.

Whether this actually accomplishes anything in = practice is = a subject of debate.

From: juberti= @google.com
Date: Wed=2C 20 Jul 2011 15:39:04 -0400
To: fluffy@cisco.= com
CC: rtcweb@ietf.org
Subject: Re: [rtcweb] DSCP and media

C= an you go into more detail about what these NATs do with the DSCP markings?=

I'm not convinced we want to expose a generic API for t= his (too easy to misuse)=2C but I think it definitely makes sense for imple= mentations to set appropriate markings on audio and video packets=2C includ= ing different levels on individual video packets when using hierarchical pr= ediction structures.

On Wed=2C Jul 20=2C 2011 at 1:59 PM=2C Cu= llen Jennings <=3Bf= luffy@cisco.com>=3B wrote:

Many home NATs support DSCP based QoS and it does help. I think that the IE= TF should recommend that some default DSCP for audio and video from the bro= wser as well as suggest there should be an API to set the DSCP for differen= t media steam.

Cullen <=3Bwith my individual contributor hat on>=3B

_______________________________________________
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
= --_af88799b-417d-40e8-95f9-e104fdc23fb8_-- From Bala@vidyo.com Wed Jul 20 13:57: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 8B34D21F863E for ; Wed, 20 Jul 2011 13:57:41 -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 sXZZ8w7IeZPV for ; Wed, 20 Jul 2011 13:57:37 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id C574521F8640 for ; Wed, 20 Jul 2011 13:57:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2D97A8BDF0F; Wed, 20 Jul 2011 16:57:30 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 558198BD742; Wed, 20 Jul 2011 16:57:29 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 20 Jul 2011 16:57:29 -0400 From: Bala Pitchandi To: Matthew Kaufman , Justin Uberti Date: Wed, 20 Jul 2011 16:57:27 -0400 Thread-Topic: [rtcweb] How to multiplex between peers Thread-Index: AcxHFm8iYJmUn9EcSWSJzGCuGQeVWgACOqoQ Message-ID: <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> In-Reply-To: <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@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] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 20:57:41 -0000 +1 for sending audio & video (and any other type of media, for that matter)= on a single RTP session. With RTCP mux, that means all media can be sent o= n a single UDP port.=20 -- Bala -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Matthew Kaufman Sent: Wednesday, July 20, 2011 3:51 PM To: Justin Uberti Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote: >=20 > This is where I've ended up on this topic. We can easily multiplex multip= le RTP sources (of the same type) over a single RTP session using SSRC. We = can also mux RTCP over the RTP session using RTCP mux. So, for an arbitrary= video call, we have just 2 RTP sessions/NAT bindings.=20 >=20 > Is it worth going the extra mile to get down to 1 in v1.0, given the lack= of consensus that exists right now? Is there even a compelling argument to= do so? Yes and yes. I really can't understand why, if we can multiplex 3 totally different type= s of video streams over the same RTP session using SSRC (with wildly differ= ent bit-rates, inter-packet times, etc.) we can't also multiplex audio and = video. Not a single argument that has been presented has convinced me, and = getting from 2 to 1 is a *50%* reduction in NAT port utilization. (And a si= gnificant reduction in the number of "strange" failure modes, where one tra= versal worked and the other didn't.) Matthew Kaufman _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Wed Jul 20 14:10: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 ACB3D21F8A6F for ; Wed, 20 Jul 2011 14:10:11 -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 hsNT8ECdc7jK for ; Wed, 20 Jul 2011 14:10:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEA621F8A64 for ; Wed, 20 Jul 2011 14:10:07 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p6KL9tP2024600 for ; Wed, 20 Jul 2011 14:09:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311196196; bh=kRLtt02+DrLbwzYtF78owYPui7Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cndNIiB7QDQs/1zWkEXwyklOzyMlByP7/HOOQMpmJ0OIM83gogTjvP5ptwxby8/fY emb4XOz9WihJ4iNRg0Y/g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=o0XW7Ff05dYPt5PEZAJBXj1w+70GjmdLT+M3vanjg+0HHEywnRqTwONKcu7L/Zd9F EOSDuuENzgLdBgwb+Jd6A== Received: from qwi4 (qwi4.prod.google.com [10.241.195.4]) by kpbe18.cbf.corp.google.com with ESMTP id p6KL9XcA016858 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 14:09:54 -0700 Received: by qwi4 with SMTP id 4so366963qwi.29 for ; Wed, 20 Jul 2011 14:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zTYTmT1TK8CeJTCGaQfZ3F6x7Ygqj7k+MQsrfJZA2gg=; b=Z5gvdB1nQFWzR2fN+Qqkup4UMqbKJiaATea9gYAPfr+v0HNfVgXzXp3ElRKlqSkH7u Pe8gUEf+AbwSNe2J6zEw== Received: by 10.229.77.38 with SMTP id e38mr5745841qck.151.1311196194168; Wed, 20 Jul 2011 14:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.81 with HTTP; Wed, 20 Jul 2011 14:09:34 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 20 Jul 2011 17:09:34 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=00235447193c625e9d04a886a7b2 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 21:10:11 -0000 --00235447193c625e9d04a886a7b2 Content-Type: text/plain; charset=UTF-8 OK, that's what I suspected. Ensuring that this is handled properly by the RTCWEB platform can only help things. On Wed, Jul 20, 2011 at 4:43 PM, Bernard Aboba wrote: > I think we're talking about things like support of WFA WMM. Not a NAT > function per se. > > Some info on how this is implemented in the OS is available here. > > > Whether this actually accomplishes anything in practice is a subject of > debate. > > > ------------------------------ > From: juberti@google.com > Date: Wed, 20 Jul 2011 15:39:04 -0400 > To: fluffy@cisco.com > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] DSCP and media > > > Can you go into more detail about what these NATs do with the DSCP > markings? > > I'm not convinced we want to expose a generic API for this (too easy to > misuse), but I think it definitely makes sense for implementations to set > appropriate markings on audio and video packets, including different levels > on individual video packets when using hierarchical prediction structures. > > On Wed, Jul 20, 2011 at 1:59 PM, Cullen Jennings wrote: > > > Many home NATs support DSCP based QoS and it does help. I think that the > IETF should recommend that some default DSCP for audio and video from the > browser as well as suggest there should be an API to set the DSCP for > different media steam. > > Cullen > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > --00235447193c625e9d04a886a7b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, that's what I suspected.

Ensuring that this is h= andled properly by the RTCWEB platform can only help things.

On Wed, Jul 20, 2011 at 4:43 PM, Bernard Aboba <bernard_aboba@ho= tmail.com> wrote:
I think we're talking about things like support of WFA WMM.=C2=A0 Not a= NAT function per se.

Some info on how this is implemented in the O= S is available here.

Whether this actually accomplishes anything in practice is a subj= ect of debate.

From: = juberti@google.com
Date: Wed, 20 Jul 2011 15:39:04 -0400
To: fluffy@cisco.com
C= C: rtcweb@ietf.org=
Subject: Re: [rtcweb] DSCP and media

<= br>Can you go into more detail about what these NATs do with the DSCP marki= ngs?

I'm not convinced we want to expose a generic A= PI for this (too easy to misuse), but I think it definitely makes sense for= implementations to set appropriate markings on audio and video packets, in= cluding different levels on individual video packets when using hierarchica= l prediction structures.

On Wed, Jul 20, 2011 at 1:59 PM, Cullen Jennings <fluffy@cisco.com= > wrote:

Many home NATs support DSCP based QoS and it does help. I think that the IE= TF should recommend that some default DSCP for audio and video from the bro= wser as well as suggest there should be an API to set the DSCP for differen= t media steam.

Cullen <with my individual contributor hat on>

_______________________________________________
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

--00235447193c625e9d04a886a7b2-- From juberti@google.com Wed Jul 20 14:15: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 9F2E821F87C7 for ; Wed, 20 Jul 2011 14:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.768 X-Spam-Level: X-Spam-Status: No, score=-105.768 tagged_above=-999 required=5 tests=[AWL=0.208, 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 VnfB39Bsjq4D for ; Wed, 20 Jul 2011 14:15:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED7F21F858D for ; Wed, 20 Jul 2011 14:15:54 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p6KLFqKO023872 for ; Wed, 20 Jul 2011 14:15:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311196553; bh=q1DUf/mulT4FRaapkfqzRZrggNM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=liCfWx9T1YcJUSSZZ0z4bhIiceGa8eizWd1AUeWNQQHMAQtJtbvnTVCxoy5xEBcdO Smt+KnZUQdWi72MmLU4mQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=DyXpZtIEy8tRjvryHKwu/ezsQd5VuhQU9IRnpMxjZlDCgZqbjdlpKGUGJb/+0tpvT ylkPXRceTi2y80VLG3imA== Received: from qwc23 (qwc23.prod.google.com [10.241.193.151]) by wpaz24.hot.corp.google.com with ESMTP id p6KLFexB020782 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 14:15:51 -0700 Received: by qwc23 with SMTP id 23so338932qwc.3 for ; Wed, 20 Jul 2011 14:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5F3YEu44tKdd3YwGuWIKPvkDcud6xPSxkM6BHETtvig=; b=hKewOUBI6BBC1FoEE+knoR6nE/tccgs2E4c+ahLWvxSR2EOL4Ml1GF7lme+xVcbaR4 tbO9fRGVexw0OmBMo7kg== Received: by 10.229.106.30 with SMTP id v30mr384866qco.113.1311196551503; Wed, 20 Jul 2011 14:15:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.81 with HTTP; Wed, 20 Jul 2011 14:15:31 -0700 (PDT) In-Reply-To: References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> From: Justin Uberti Date: Wed, 20 Jul 2011 17:15:31 -0400 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=00235429d1d4aedf5704a886bce7 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 21:15:55 -0000 --00235429d1d4aedf5704a886bce7 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2011 at 3:59 PM, Justin Uberti wrote: > > > On Wed, Jul 20, 2011 at 3:51 PM, Matthew Kaufman < > matthew.kaufman@skype.net> wrote: > >> >> On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote: >> >> > >> > This is where I've ended up on this topic. We can easily multiplex >> multiple RTP sources (of the same type) over a single RTP session using >> SSRC. We can also mux RTCP over the RTP session using RTCP mux. So, for an >> arbitrary video call, we have just 2 RTP sessions/NAT bindings. >> > >> > Is it worth going the extra mile to get down to 1 in v1.0, given the >> lack of consensus that exists right now? Is there even a compelling argument >> to do so? >> >> Yes and yes. >> >> I really can't understand why, if we can multiplex 3 totally different >> types of video streams over the same RTP session using SSRC (with wildly >> different bit-rates, inter-packet times, etc.) we can't also multiplex audio >> and video. Not a single argument that has been presented has convinced me, >> and getting from 2 to 1 is a *50%* reduction in NAT port utilization. (And a >> significant reduction in the number of "strange" failure modes, where one >> traversal worked and the other didn't.) >> > > Clearly we can, but we need to do additional work to get there. This work > will take time and delay v1.0, so we need a pretty convincing rationale to > do so. > > I concur that solving strange failure modes is significant. But with regard > to NAT port utilization, this ignores the utilization by the browser for > HTTP; 50% reduction seems possible in theory only. (Here I am essentially > restating 2.2.2 from > https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1, > which I haven't yet seen a clear response to.) > Also: when falling back to send media over TCP/WebSockets, a lost packet may cause a momentary audio dropout as the transport stalls while the packet is retransmitted. I expect that this will occur more frequently if video and audio are combined on the same TCP connection, if for no other reason than the much higher packet rate. > > > > >> Matthew Kaufman >> >> > --00235429d1d4aedf5704a886bce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2011 at 3:59 PM, Justin = Uberti <juberti@= google.com> wrote:


On Wed= , Jul 20, 2011 at 3:51 PM, Matthew Kaufman <matthew.kaufman@skype.= net> wrote:

On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote:

>
> This is where I've ended up on this topic. We can easily multiplex= multiple RTP sources (of the same type) over a single RTP session using SS= RC. We can also mux RTCP over the RTP session using RTCP mux. So, for an ar= bitrary video call, we have just 2 RTP sessions/NAT bindings.
>
> Is it worth going the extra mile to get down to 1 in v1.0, given the l= ack of consensus that exists right now? Is there even a compelling argument= to do so?

Yes and yes.

I really can't understand why, if we can multiplex 3 totally different = types of video streams over the same RTP session using SSRC (with wildly di= fferent bit-rates, inter-packet times, etc.) we can't also multiplex au= dio and video. Not a single argument that has been presented has convinced = me, and getting from 2 to 1 is a *50%* reduction in NAT port utilization. (= And a significant reduction in the number of "strange" failure mo= des, where one traversal worked and the other didn't.)

Clearly we can, but we need to= do additional work to get there. This work will take time and delay v1.0, = so we need a pretty convincing rationale to do so.

I concur that solving strange failure modes is significant. But with r= egard to NAT port utilization, this ignores the utilization by the browser = for HTTP; 50% reduction seems possible in theory only. (Here I am essential= ly restating 2.2.2 from=C2=A0https://d= atatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=3D1, which I haven't yet seen a clear response to.)







Matthew Kaufman



--00235429d1d4aedf5704a886bce7-- From arosenberg@logitech.com Wed Jul 20 14: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 24BAE21F8547 for ; Wed, 20 Jul 2011 14:16:19 -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 PKCbhqqNDT14 for ; Wed, 20 Jul 2011 14:16:18 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with SMTP id 4B20321F8546 for ; Wed, 20 Jul 2011 14:16:18 -0700 (PDT) Received: from mail-yi0-f42.google.com ([209.85.218.42]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTidFobYulEanf6U4xxUh1H2JokOb2vYp@postini.com; Wed, 20 Jul 2011 14:16:18 PDT Received: by yih10 with SMTP id 10so345607yih.29 for ; Wed, 20 Jul 2011 14:16:17 -0700 (PDT) Received: by 10.236.184.131 with SMTP id s3mr6526325yhm.323.1311196577070; Wed, 20 Jul 2011 14:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.136.135 with HTTP; Wed, 20 Jul 2011 14:15:57 -0700 (PDT) In-Reply-To: <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> From: Aron Rosenberg Date: Wed, 20 Jul 2011 14:15:57 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=20cf3040e40e34fd0e04a886be8e Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 21:16:19 -0000 --20cf3040e40e34fd0e04a886be8e Content-Type: text/plain; charset=ISO-8859-1 Another +1 for multiplexing everything together. My only worry is that the base spec for RTCP doesn't mandate that SSRC is included in every RTCP message type, and thus you could end up with the multiplexing layer needing to understand every RTCP messaged used for video (TMMBR, TMMBN, etc) --20cf3040e40e34fd0e04a886be8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another +1 for multiplexing everything together. My only worry is that the = base spec for RTCP doesn't mandate that SSRC is included in every RTCP = message type, and thus you could end up with the multiplexing layer needing= to understand every =A0RTCP messaged used for video (TMMBR, TMMBN, etc)

--20cf3040e40e34fd0e04a886be8e-- From fluffy@cisco.com Wed Jul 20 14:25: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 45DD021F874F for ; Wed, 20 Jul 2011 14:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.816 X-Spam-Level: X-Spam-Status: No, score=-103.816 tagged_above=-999 required=5 tests=[AWL=-1.217, 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 9bt8XvZcLJTV for ; Wed, 20 Jul 2011 14:25:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5A78F21F869D for ; Wed, 20 Jul 2011 14:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3899; q=dns/txt; s=iport; t=1311197118; x=1312406718; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZEQY9KPFI/kKm62HmJ5pdss9LnXMSaCXPLLWxhmOu2o=; b=IkOwkqcmMvc9+CVbhpEA8Ldy5i6JM5MQOVpa+GFphFkS0Xxd/6UaCF1p sO/Ac+qvdDxJGc7mtiqvB+na0gA6EyaJn8nDa6UExfPz8GNVez8qxeB63 621BPqFByg25N7ACw63tkXhwlyLUQHu5CrflVXz9IvtsvUWI9EDZXcgOh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOJGJ06rRDoI/2dsb2JhbABTp2R3iHyfGJ4dhV5fBIdVixmFB4t2 X-IronPort-AV: E=Sophos;i="4.67,237,1309737600"; d="scan'208";a="4880570" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2011 21:25:17 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6KLPGgM030191; Wed, 20 Jul 2011 21:25:17 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 20 Jul 2011 14:25:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> References: To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 21:25:22 -0000 As Bernard points out there is the qos marking for the wireless networks = and local networks but what I am mostly interested in is the device = (typically an NAT) that is sequencing the packets on to the broadband = uplink from my home to my ISP. Lots of NATs support some simple set of = priorities and send the higher priority packets ahead of the lower = priority. My view is this was largely done for the online gaming people = but in many cases it does help voip. Many of the voip devices do take = advantage of it - there is pretty much no downside for setting the DSCP. = The cases where I see it helping are things like the following: I have a = 128Kbps uplink, I am trying to send an 80Kbps audio stream, and at the = same time I email a 25 MB powerpoint file. With QoS, typically the audio = gets it's 80k and email gets the rest. WIthout QOS, the audio gets = packet loss. It helps in cases where the uplink is the congested part = of the network. It does not help if your downlink is the problem. Keep = in mind most people have much faster downlink than uplink. It's easy to = run your own experiments and try this out - just get a nat with support = and turn it on and off and see how things go. It also helps with = wireless but I have not done a lot of experimenting with that - my = wireless is so much faster than my broadband that it has not been a = problem but I heard rumors that it can help file transfer over the lan = not impact voip - I just don't know as much about this sort of use case.=20= To your point about too risky to expose a generic API. I'm on the fence. = You could be right but it's sort of hard to decide why if it too risking = to let some JS send an packet with higher priority, that it is OK to let = is send normal priority ones. It would be interesting to talk about the = risk, and what we might do to mitigate them. One point of view is that = rate shaping and policing of packets can never be done by the endpoint = and needs to be done by network router and switches. The people that buy = into this don't see it as any worse that the JS can set the DSCP than = the fact that a think app on my notebook computer can set the DSCP. =20 The other issue is that it is not clear what values you should set the = DSCP to. If you read the appropriate RFCs, you will come to the = conclusion that they are pretty confused on the topic. If you look at = the values being used by Cisco, the mapping from 802.11, and Microsoft, = you would notice they are not the same and there may be some uh "gaming = the system" going on. One of the things this WG could do would be to = come up with some clear guidance on what values to use for browsers and = when to use them.=20 On Jul 20, 2011, at 12:39 , Justin Uberti wrote: > Can you go into more detail about what these NATs do with the DSCP = markings? >=20 > I'm not convinced we want to expose a generic API for this (too easy = to misuse), but I think it definitely makes sense for implementations to = set appropriate markings on audio and video packets, including different = levels on individual video packets when using hierarchical prediction = structures. >=20 > On Wed, Jul 20, 2011 at 1:59 PM, Cullen Jennings = wrote: >=20 > Many home NATs support DSCP based QoS and it does help. I think that = the IETF should recommend that some default DSCP for audio and video = from the browser as well as suggest there should be an API to set the = DSCP for different media steam. >=20 > Cullen >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From bernard_aboba@hotmail.com Wed Jul 20 14:37: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 A24B821F8786 for ; Wed, 20 Jul 2011 14:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObMfDHRNdxAZ for ; Wed, 20 Jul 2011 14:37:26 -0700 (PDT) Received: from blu0-omc4-s33.blu0.hotmail.com (blu0-omc4-s33.blu0.hotmail.com [65.55.111.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5E21F8906 for ; Wed, 20 Jul 2011 14:37:26 -0700 (PDT) Received: from BLU152-W47 ([65.55.111.136]) by blu0-omc4-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 14:37:25 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_889ff884-2858-4d74-9f4a-e5952f036ed9_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Date: Wed, 20 Jul 2011 14:37:25 -0700 Importance: Normal In-Reply-To: <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> References: , , <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2011 21:37:25.0981 (UTC) FILETIME=[37A4C8D0:01CC4725] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 21:37:30 -0000 --_889ff884-2858-4d74-9f4a-e5952f036ed9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As I recall=2C there was some conflict between the DSCP mappings defined wi= thin WMM and those recommended in RFC 4594. There was some discussion of h= ow to fix this in WFA and DLNA. Fred would probably know the current statu= s. AFAIK this is still an issue.=20 > From: fluffy@cisco.com > Date: Wed=2C 20 Jul 2011 14:25:16 -0700 > To: juberti@google.com > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] DSCP and media >=20 >=20 > As Bernard points out there is the qos marking for the wireless networks = and local networks but what I am mostly interested in is the device (typica= lly an NAT) that is sequencing the packets on to the broadband uplink from = my home to my ISP. Lots of NATs support some simple set of priorities and s= end the higher priority packets ahead of the lower priority. My view is thi= s was largely done for the online gaming people but in many cases it does h= elp voip. Many of the voip devices do take advantage of it - there is prett= y much no downside for setting the DSCP. The cases where I see it helping a= re things like the following: I have a 128Kbps uplink=2C I am trying to sen= d an 80Kbps audio stream=2C and at the same time I email a 25 MB powerpoint= file. With QoS=2C typically the audio gets it's 80k and email gets the res= t. WIthout QOS=2C the audio gets packet loss. It helps in cases where the = uplink is the congested part of the network. It does not help if your downl= ink is the problem. Keep=20 > in mind most people have much faster downlink than uplink. It's easy to = run your own experiments and try this out - just get a nat with support and= turn it on and off and see how things go. It also helps with wireless but = I have not done a lot of experimenting with that - my wireless is so much f= aster than my broadband that it has not been a problem but I heard rumors t= hat it can help file transfer over the lan not impact voip - I just don't k= now as much about this sort of use case.=20 >=20 > To your point about too risky to expose a generic API. I'm on the fence. = You could be right but it's sort of hard to decide why if it too risking to= let some JS send an packet with higher priority=2C that it is OK to let is= send normal priority ones. It would be interesting to talk about the risk= =2C and what we might do to mitigate them. One point of view is that rate s= haping and policing of packets can never be done by the endpoint and needs = to be done by network router and switches. The people that buy into this do= n't see it as any worse that the JS can set the DSCP than the fact that a t= hink app on my notebook computer can set the DSCP. =20 >=20 > The other issue is that it is not clear what values you should set the DS= CP to. If you read the appropriate RFCs=2C you will come to the conclusion = that they are pretty confused on the topic. If you look at the values being= used by Cisco=2C the mapping from 802.11=2C and Microsoft=2C you would not= ice they are not the same and there may be some uh "gaming the system" goin= g on. One of the things this WG could do would be to come up with some clea= r guidance on what values to use for browsers and when to use them.=20 >=20 >=20 >=20 > On Jul 20=2C 2011=2C at 12:39 =2C Justin Uberti wrote: >=20 > > Can you go into more detail about what these NATs do with the DSCP mark= ings? > >=20 > > I'm not convinced we want to expose a generic API for this (too easy to= misuse)=2C but I think it definitely makes sense for implementations to se= t appropriate markings on audio and video packets=2C including different le= vels on individual video packets when using hierarchical prediction structu= res. > >=20 > > On Wed=2C Jul 20=2C 2011 at 1:59 PM=2C Cullen Jennings wrote: > >=20 > > Many home NATs support DSCP based QoS and it does help. I think that th= e IETF should recommend that some default DSCP for audio and video from the= browser as well as suggest there should be an API to set the DSCP for diff= erent media steam. > >=20 > > Cullen > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > >=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_889ff884-2858-4d74-9f4a-e5952f036ed9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As I recall=2C there was some conflict between the DSCP mappings defined wi= thin WMM and those recommended in RFC 4594. =3B There was some discussi= on of how to fix this in WFA and DLNA. =3B Fred would probably know the= current status. AFAIK this is still an issue.

>=3B From: fl= uffy@cisco.com
>=3B Date: Wed=2C 20 Jul 2011 14:25:16 -0700
>=3B = To: juberti@google.com
>=3B CC: rtcweb@ietf.org
>=3B Subject: Re:= [rtcweb] DSCP and media
>=3B
>=3B
>=3B As Bernard points = out there is the qos marking for the wireless networks and local networks b= ut what I am mostly interested in is the device (typically an NAT) that is = sequencing the packets on to the broadband uplink from my home to my ISP. L= ots of NATs support some simple set of priorities and send the higher prior= ity packets ahead of the lower priority. My view is this was largely done f= or the online gaming people but in many cases it does help voip. Many of th= e voip devices do take advantage of it - there is pretty much no downside f= or setting the DSCP. The cases where I see it helping are things like the f= ollowing: I have a 128Kbps uplink=2C I am trying to send an 80Kbps audio st= ream=2C and at the same time I email a 25 MB powerpoint file. With QoS=2C t= ypically the audio gets it's 80k and email gets the rest. WIthout QOS=2C th= e audio gets packet loss. It helps in cases where the uplink is the conges= ted part of the network. It does not help if your downlink is the problem. = Keep
>=3B in mind most people have much faster downlink than uplink.= It's easy to run your own experiments and try this out - just get a nat wi= th support and turn it on and off and see how things go. It also helps with= wireless but I have not done a lot of experimenting with that - my wireles= s is so much faster than my broadband that it has not been a problem but I = heard rumors that it can help file transfer over the lan not impact voip - = I just don't know as much about this sort of use case.
>=3B
>= =3B To your point about too risky to expose a generic API. I'm on the fence= . You could be right but it's sort of hard to decide why if it too risking = to let some JS send an packet with higher priority=2C that it is OK to let = is send normal priority ones. It would be interesting to talk about the ris= k=2C and what we might do to mitigate them. One point of view is that rate = shaping and policing of packets can never be done by the endpoint and needs= to be done by network router and switches. The people that buy into this d= on't see it as any worse that the JS can set the DSCP than the fact that a = think app on my notebook computer can set the DSCP.
>=3B
>=3B = The other issue is that it is not clear what values you should set the DSCP= to. If you read the appropriate RFCs=2C you will come to the conclusion th= at they are pretty confused on the topic. If you look at the values being u= sed by Cisco=2C the mapping from 802.11=2C and Microsoft=2C you would notic= e they are not the same and there may be some uh "gaming the system" going = on. One of the things this WG could do would be to come up with some clear = guidance on what values to use for browsers and when to use them.
>= =3B
>=3B
>=3B
>=3B On Jul 20=2C 2011=2C at 12:39 =2C Just= in Uberti wrote:
>=3B
>=3B >=3B Can you go into more detail ab= out what these NATs do with the DSCP markings?
>=3B >=3B
>=3B = >=3B I'm not convinced we want to expose a generic API for this (too easy= to misuse)=2C but I think it definitely makes sense for implementations to= set appropriate markings on audio and video packets=2C including different= levels on individual video packets when using hierarchical prediction stru= ctures.
>=3B >=3B
>=3B >=3B On Wed=2C Jul 20=2C 2011 at 1:59= PM=2C Cullen Jennings <=3Bfluffy@cisco.com>=3B wrote:
>=3B >=3B=
>=3B >=3B Many home NATs support DSCP based QoS and it does help. = I think that the IETF should recommend that some default DSCP for audio and= video from the browser as well as suggest there should be an API to set th= e DSCP for different media steam.
>=3B >=3B
>=3B >=3B Cullen= <=3Bwith my individual contributor hat on>=3B
>=3B >=3B
>= =3B >=3B _______________________________________________
>=3B >=3B= rtcweb mailing list
>=3B >=3B rtcweb@ietf.org
>=3B >=3B http= s://www.ietf.org/mailman/listinfo/rtcweb
>=3B >=3B
>=3B
&g= t=3B
>=3B Cullen Jennings
>=3B For corporate legal information g= o to:
>=3B http://www.cisco.com/web/about/doing_business/legal/cri/ind= ex.html
>=3B
>=3B
>=3B ___________________________________= ____________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
>= =3B https://www.ietf.org/mailman/listinfo/rtcweb
= --_889ff884-2858-4d74-9f4a-e5952f036ed9_-- From fluffy@cisco.com Wed Jul 20 14:39: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 719A521F8888 for ; Wed, 20 Jul 2011 14:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.795 X-Spam-Level: X-Spam-Status: No, score=-103.795 tagged_above=-999 required=5 tests=[AWL=-1.196, 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 K4f5VakqSGBY for ; Wed, 20 Jul 2011 14:39:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D2CAB21F8786 for ; Wed, 20 Jul 2011 14:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=391; q=dns/txt; s=iport; t=1311197968; x=1312407568; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+mRwfjf063hyKYiu7z06nkPUnLuuTX8DlbqSO9wX3OM=; b=L5cVJFh5fq7X2HX7ST6x+3zqWrtXyiLHPREPHoiTo6kUBvqQ5UEwHhGF qFxWQpuR39Sq5S5YNj5jkFPCDSvaqaUiOsBXdoqVF9Yq/kw/7GKV4ArSM ho4LrcB/T1pM64lvelWKFyJ4u4xYla61S4UpBIu7qcLaTgGFuotcM6m/s E=; X-IronPort-AV: E=Sophos;i="4.67,237,1309737600"; d="scan'208";a="4884311" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2011 21:39:28 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6KLdQxb010342; Wed, 20 Jul 2011 21:39:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 20 Jul 2011 14:39:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4975F8F1-C435-4D56-84B2-FD341069B729@cisco.com> References: , , <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> To: Fred Baker , James M Polk X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 21:39:29 -0000 On Jul 20, 2011, at 14:37 , Bernard Aboba wrote: > As I recall, there was some conflict between the DSCP mappings defined = within WMM and those recommended in RFC 4594. There was some discussion = of how to fix this in WFA and DLNA. Fred would probably know the = current status. AFAIK this is still an issue.=20 Fred, James - do you guys know status of mapping DSCP to WMM ? From csp@csperkins.org Wed Jul 20 15:21: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 678A121F84EB for ; Wed, 20 Jul 2011 15:21:08 -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 Az8f53eQzOP2 for ; Wed, 20 Jul 2011 15:21:04 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 280C021F8AB9 for ; Wed, 20 Jul 2011 15:21:04 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Qjf8Z-0001D5-mS; Wed, 20 Jul 2011 22:21:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Colin Perkins In-Reply-To: <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> Date: Wed, 20 Jul 2011 23:21:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1CA6A176-B5F1-47F0-839D-D595CE023B57@csperkins.org> References: <4E259484.20509@ericsson.com> <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> <4E26B742.6050606@jitsi.org> <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:21:08 -0000 On 20 Jul 2011, at 15:11, Cullen Jennings wrote: > On Jul 20, 2011, at 4:08 , Emil Ivov wrote: >> =D0=9D=D0=B0 20.07.11 02:05, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >>> I'd like to see it that devices MUST support multiplexing and I'd = probably be in favor of also MUST support non multiplexed flows. The = multiplexing is a big advantage for any device that needs to deal with = NATs so I suspect many "legacy" devices would be moving to this even if = there was no need to deal with the browser like devices. I also think = that allowing this type of multiplexing will make firewall traversal = easier where a device can configure a firewall to open just one = specified port and use it for RTP. >>=20 >> I don't really agree with this part. Devices would still need to = handle candidates that come from STUN, TURN, UPnP, host IPv4, host = IPv6, and potentially VPN, MIPv6 and other tunnelling mechanisms. = Whether or not this only happens for a single component/stream doesn't = really simplify code does it? >>=20 >> According to my personal experience with our work on ice4j.org, = managing multiple checklists was far less resource consuming than = implementing TURN tunnels and persmissions, STUN multiplexing, = synchronisation and even getting pacing right. >=20 > Ahh, I think we have come to the key issues here - perhaps I have not = been explaining myself very well. So in your experience roughly how long = does it take to set up a for two scenarios using ICE as is today.=20 >=20 > First scenario: I have two devices that want to set up a single audio = stream and they each have the candidates from: local v4 IP address, v4 = stun, v4 turn, local v6, turn v6. Obviously they could have a lot more = but that seems like a reasonable starting point.=20 >=20 > Second scenario: same as first address wise but instead of a single = audio stream they want to set up a single audio stream to a conference = bridge plus 7 video streams for the video from the 5 people on the = bridge plus a presentation stream and stream of video from active = speaker. I don't really care much about the scenario other than there = are 8 streams being set up. But this type of scenario is becoming very = common for multi party video chat as it allows you to see perhaps small = versions of everyone plus a large version of active speaker.=20 >=20 > My experience is the answer to the first scenario is not as quick as = you would like and the answer to how long the second takes is about 8 = times longer than the first one. You might do a bit better than that = depending on how clever your implementation is but it still a lot = longer.=20 I may be misunderstanding, but why would this take 8 times as long to = set up? Wouldn't you implement it as one UDP flow for the RTP audio, = plus one UDP flow for the RTP video (with the 7 video streams = multiplexed by SSRC, since RTP has always allowed multiparty flows of = the same media type in a single RTP session)? This might take twice as = long to setup as a single audio flow in the worst case, but not eight = times as long. Cheers, Colin From csp@csperkins.org Wed Jul 20 15:24: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 9A94421F8531 for ; Wed, 20 Jul 2011 15:24:55 -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 fuQDOf3O5TJc for ; Wed, 20 Jul 2011 15:24:51 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id ABC1121F852E for ; Wed, 20 Jul 2011 15:24:51 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QjfCE-0001sZ-nX; Wed, 20 Jul 2011 22:24:51 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4E26A49F.1070700@alvestrand.no> Date: Wed, 20 Jul 2011 23:24:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C89D269-6EFC-46C6-8716-776289A87C28@csperkins.org> References: <4E259484.20509@ericsson.com> <4E26A49F.1070700@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:24:55 -0000 If you're not doing network-based QoS to prioritise certain flows, then = this is requires two bidirectional UDP flows: one for the audio and one = for video, using the standard RTP mechanisms (which is what I understand = Magnus' option A to be). Colin On 20 Jul 2011, at 10:49, Harald Alvestrand wrote: > Magnus, I cannot parse your list of choices. >=20 > In the case where you have >=20 > Sender A > Recipient B > Three video streams going from A to B > Three audio streams going from A to B > One video stream going from B to A > One audio stream going from B to A >=20 > with the application not requiring the network to treat the packets = any differently, and with the application using the CNAME mechanism to = match audio streams with corresponding video streams >=20 > it is completely unclear to me whether your choice A) requires 8 = transport flows, 4 transport flows or 2 transport flows, and it is = completely unclear to me what C) actually means. (I assume "transport = flow" =3D "RTP sessions" here) >=20 > Please - can you clarify what your question is intended to mean? >=20 > Harald >=20 >=20 > On 07/19/11 16:28, Magnus Westerlund wrote: >> Hi, >>=20 >> This email is as an individual contributor. >>=20 >> I want to get started on the discussion of the Multiplexing of the >> various protocols over single lower layer transport flow, such as a = UDP >> flow. I will attempt to split up the questions into different emails. >>=20 >> The first question I think is reasonably easy to get answered, but I >> think it is time we determine if my belief in the answer is correct = or not. >>=20 >> The traffic between two RTCWEB peers from the various components, = such >> as RTP sessions, datagram service: >>=20 >> a) MUST be sent as Individual flows for each component. >>=20 >> b) MUST be multiplexed into a single transport flow. >>=20 >> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB >> peer MUST be able to send them as individual flows. >>=20 >> I would love if people can indicate their choice or preferences. >>=20 >> I personally prefer A as it it is simplest in all aspect except the = NAT >> traversal. >> - It allows for flow based QoS. >> - It is the what the implementation that exist mostly do >> - Signaling protocols that exist support it, no extra functionality >> - People are used to the concept >> - It minimizes the difference to legacy. >>=20 >> Thus it is the quickest road to define something with the least = formal >> push back and concern over maturity of any solution. >>=20 >> The downside with B and C is that we do have to solve the = multiplexing >> and get an agreement that gets through all the hurdles. >>=20 >> Of these two opens I do prefer C. Although it results in the extra >> complexities of having both alternatives, it will give us both a >> fallback, flow based QoS and better legacy support. >>=20 >> Now it is your time to make your opinion heard! >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From fluffy@cisco.com Wed Jul 20 15:25: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 DF80821F8538 for ; Wed, 20 Jul 2011 15:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.774 X-Spam-Level: X-Spam-Status: No, score=-103.774 tagged_above=-999 required=5 tests=[AWL=-1.175, 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 o4vgF48GDh1E for ; Wed, 20 Jul 2011 15:25:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6308621F8531 for ; Wed, 20 Jul 2011 15:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=878; q=dns/txt; s=iport; t=1311200751; x=1312410351; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=n1jwBe+N9Hqnv9TG6WMne6x2k+d2ByIb+jyufP5ckrU=; b=NJ5YNN6yk7ErCcU25s+jEpp6Et6Ea+3npPjbXzrFzAiZ7YspgcZ5gyxS 9ykQuZnqMK+keBusqWvPBcoxAayH4g7ZnKZbl83kDIBPqYns/w9R1cC3S Wd2/EjygBHq3nTa9RM24ZJnMwxfq5MlMSjDnWav0vvnvjRSDFmwHyJaSE s=; X-IronPort-AV: E=Sophos;i="4.67,238,1309737600"; d="scan'208";a="4895484" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2011 22:25:50 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6KMPnUB020833; Wed, 20 Jul 2011 22:25:50 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <1C193136-83C2-419E-BFCB-DC30EF41ACDC@cisco.com> Date: Wed, 20 Jul 2011 15:25:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B511E40-4121-484C-AC46-74AE698AB265@cisco.com> References: , , <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> <4975F8F1-C435-4D56-84B2-FD341069B729@cisco.com> <1C193136-83C2-419E-BFCB-DC30EF41ACDC@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: James M Polk , rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:25:52 -0000 On Jul 20, 2011, at 15:13 , Fred Baker wrote: >=20 > On Jul 20, 2011, at 2:39 PM, Cullen Jennings wrote: >=20 >>=20 >> On Jul 20, 2011, at 14:37 , Bernard Aboba wrote: >>=20 >>> As I recall, there was some conflict between the DSCP mappings = defined within WMM and those recommended in RFC 4594. There was some = discussion of how to fix this in WFA and DLNA. Fred would probably know = the current status. AFAIK this is still an issue.=20 >>=20 >> Fred, James - do you guys know status of mapping DSCP to WMM ? >=20 > Define "WMM"? The "Wireless Multimedia Extensions from Wi-FI. It's been awhile since I = looked at this but I seem to recall that 802.11e had four levels of = priority, something like voice, video, background, and best effort. And = 802.1p had 8 levels, and some confusion on status of mapping between = them and DSCP.=20 =20= From csp@csperkins.org Wed Jul 20 15:31: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 7D35621F865F for ; Wed, 20 Jul 2011 15:31:22 -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 LDtW37DpSKBz for ; Wed, 20 Jul 2011 15:31:22 -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 BBA3D21F863A for ; Wed, 20 Jul 2011 15:31:21 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QjfIW-0006no-l9; Wed, 20 Jul 2011 22:31:20 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> Date: Wed, 20 Jul 2011 23:31:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> To: Bala Pitchandi X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:31:22 -0000 Except that it doesn't work in all cases: please read the discussion in = draft-perkins-rtpweb-rtp-usage-02. You may argue that you don't think = the breakage is important, but there *is* breakage in doing this, and it = is not backwards compatible. Colin On 20 Jul 2011, at 21:57, Bala Pitchandi wrote: > +1 for sending audio & video (and any other type of media, for that = matter) on a single RTP session. With RTCP mux, that means all media can = be sent on a single UDP port.=20 >=20 > -- Bala >=20 >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Matthew Kaufman > Sent: Wednesday, July 20, 2011 3:51 PM > To: Justin Uberti > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] How to multiplex between peers >=20 >=20 > On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote: >=20 >>=20 >> This is where I've ended up on this topic. We can easily multiplex = multiple RTP sources (of the same type) over a single RTP session using = SSRC. We can also mux RTCP over the RTP session using RTCP mux. So, for = an arbitrary video call, we have just 2 RTP sessions/NAT bindings.=20 >>=20 >> Is it worth going the extra mile to get down to 1 in v1.0, given the = lack of consensus that exists right now? Is there even a compelling = argument to do so? >=20 > Yes and yes. >=20 > I really can't understand why, if we can multiplex 3 totally different = types of video streams over the same RTP session using SSRC (with wildly = different bit-rates, inter-packet times, etc.) we can't also multiplex = audio and video. Not a single argument that has been presented has = convinced me, and getting from 2 to 1 is a *50%* reduction in NAT port = utilization. (And a significant reduction in the number of "strange" = failure modes, where one traversal worked and the other didn't.) >=20 > Matthew Kaufman >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Jul 20 15:32: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 7E6E921F8ABE for ; Wed, 20 Jul 2011 15:32:11 -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=[AWL=-0.001, 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 ah2bVvW2neNi for ; Wed, 20 Jul 2011 15:32:11 -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 5C3C121F8555 for ; Wed, 20 Jul 2011 15:32:04 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QjfJB-0006no-jW; Wed, 20 Jul 2011 22:32:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-33951676 From: Colin Perkins In-Reply-To: Date: Wed, 20 Jul 2011 23:31:56 +0100 Message-Id: References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> To: Aron Rosenberg X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:32:11 -0000 --Apple-Mail-11-33951676 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Jul 2011, at 22:15, Aron Rosenberg wrote: > Another +1 for multiplexing everything together. My only worry is that = the base spec for RTCP doesn't mandate that SSRC is included in every = RTCP message type, and thus you could end up with the multiplexing layer = needing to understand every RTCP messaged used for video (TMMBR, TMMBN, = etc) ...which is another reason why this doesn't work in all cases, in = addition to the reasons we document in draft-perkins-rtcweb-rtp-usage-02 --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-11-33951676 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Another +1 for multiplexing = everything together. My only worry is that the base spec for RTCP = doesn't mandate that SSRC is included in every RTCP message type, and = thus you could end up with the multiplexing layer needing to understand = every  RTCP messaged used for video (TMMBR, TMMBN, etc)

...which is another reason why this doesn't = work in all cases, in addition to the reasons we document in = draft-perkins-rtcweb-rtp-usage-02


-- 
Colin Perkins



= --Apple-Mail-11-33951676-- From bernard_aboba@hotmail.com Wed Jul 20 15:32: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 8581D21F8599 for ; Wed, 20 Jul 2011 15:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3evPU+u0MI8E for ; Wed, 20 Jul 2011 15:32:48 -0700 (PDT) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by ietfa.amsl.com (Postfix) with ESMTP id CA3D621F8559 for ; Wed, 20 Jul 2011 15:32:47 -0700 (PDT) Received: from BLU152-W61 ([65.55.111.136]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 15:32:47 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_fb66c488-5808-4618-9c01-4789b74e4c64_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Fred Baker Date: Wed, 20 Jul 2011 15:32:46 -0700 Importance: Normal In-Reply-To: <6B511E40-4121-484C-AC46-74AE698AB265@cisco.com> References: , , <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> <4975F8F1-C435-4D56-84B2-FD341069B729@cisco.com> <1C193136-83C2-419E-BFCB-DC30EF41ACDC@cisco.com>, <6B511E40-4121-484C-AC46-74AE698AB265@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2011 22:32:47.0583 (UTC) FILETIME=[F37906F0:01CC472C] Cc: jmpolk@cisco.com, rtcweb@ietf.org Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:32:48 -0000 --_fb66c488-5808-4618-9c01-4789b74e4c64_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The specific issue was the mapping between IEEE 802.1p and DSCP included in= the WMM appendix. This wasn't included in IEEE 802.11e (thankfully). The= appendix was included prior to publication of RFC 4594=2C and was incompat= ible with it. As I recall=2C the WMM mapping was as follows: PJLIB Traffic Type IP DSCP WMM 802.1p =20 BEST_EFFORT 0x00 BE (Bulk Effort) 0 =20 BACKGROUND 0x08 BK (Bulk) 2 =20 VIDEO 0x28 VI (Video) 5 =20 VOICE 0x30 VO (Voice) 6 =20 CONTROL 0x38 VO (Voice) 7 =20 > Subject: Re: [rtcweb] DSCP and media > From: fluffy@cisco.com > Date: Wed=2C 20 Jul 2011 15:25:49 -0700 > CC: jmpolk@cisco.com=3B juberti@google.com=3B bernard_aboba@hotmail.com= =3B rtcweb@ietf.org > To: fred@cisco.com >=20 >=20 > On Jul 20=2C 2011=2C at 15:13 =2C Fred Baker wrote: >=20 > >=20 > > On Jul 20=2C 2011=2C at 2:39 PM=2C Cullen Jennings wrote: > >=20 > >>=20 > >> On Jul 20=2C 2011=2C at 14:37 =2C Bernard Aboba wrote: > >>=20 > >>> As I recall=2C there was some conflict between the DSCP mappings defi= ned within WMM and those recommended in RFC 4594. There was some discussio= n of how to fix this in WFA and DLNA. Fred would probably know the current= status. AFAIK this is still an issue.=20 > >>=20 > >> Fred=2C James - do you guys know status of mapping DSCP to WMM ? > >=20 > > Define "WMM"? >=20 > The "Wireless Multimedia Extensions from Wi-FI. It's been awhile since I = looked at this but I seem to recall that 802.11e had four levels of priorit= y=2C something like voice=2C video=2C background=2C and best effort. And 80= 2.1p had 8 levels=2C and some confusion on status of mapping between them a= nd DSCP.=20 >=20 > =20 = --_fb66c488-5808-4618-9c01-4789b74e4c64_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The specific issue was the mapping between IEEE 802.1p and DSCP included in= the WMM appendix. =3B This wasn't included in IEEE 802.11e (thankfully= ). =3B The appendix was included prior to publication of RFC 4594=2C an= d was incompatible with it. =3B As I recall=2C the WMM mapping was as f= ollows:

=
PJLIB Traffic Type <= /td> IP DSCP WMM 802.1p =20
BEST_EFFORT 0x00 BE (Bulk Effort)= 0 =20
BACKGROUND 0x08 BK (Bulk) 2 =20
VIDEO 0x28 VI (Video) 5 =20
VOICE 0x30 VO (Voice) 6 =20
CONTROL 0x38 VO (Voice) 7 =20



>=3B Subject: Re: [rtcweb] DSC= P and media
>=3B From: fluffy@cisco.com
>=3B Date: Wed=2C 20 Jul = 2011 15:25:49 -0700
>=3B CC: jmpolk@cisco.com=3B juberti@google.com=3B= bernard_aboba@hotmail.com=3B rtcweb@ietf.org
>=3B To: fred@cisco.com<= br>>=3B
>=3B
>=3B On Jul 20=2C 2011=2C at 15:13 =2C Fred Bake= r wrote:
>=3B
>=3B >=3B
>=3B >=3B On Jul 20=2C 2011=2C= at 2:39 PM=2C Cullen Jennings wrote:
>=3B >=3B
>=3B >=3B>= =3B
>=3B >=3B>=3B On Jul 20=2C 2011=2C at 14:37 =2C Bernard Aboba= wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B>=3B As I recall=2C= there was some conflict between the DSCP mappings defined within WMM and t= hose recommended in RFC 4594. There was some discussion of how to fix this= in WFA and DLNA. Fred would probably know the current status. AFAIK this = is still an issue.
>=3B >=3B>=3B
>=3B >=3B>=3B Fred=2C = James - do you guys know status of mapping DSCP to WMM ?
>=3B >=3B <= br>>=3B >=3B Define "WMM"?
>=3B
>=3B The "Wireless Multimedi= a Extensions from Wi-FI. It's been awhile since I looked at this but I seem= to recall that 802.11e had four levels of priority=2C something like voice= =2C video=2C background=2C and best effort. And 802.1p had 8 levels=2C and = some confusion on status of mapping between them and DSCP.
>=3B
&= gt=3B
= --_fb66c488-5808-4618-9c01-4789b74e4c64_-- From csp@csperkins.org Wed Jul 20 15:39: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 8D18221F8AD8 for ; Wed, 20 Jul 2011 15:39:05 -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=[AWL=0.000, 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 sterkZfzZv3B for ; Wed, 20 Jul 2011 15:39:04 -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 AC13921F8AD6 for ; Wed, 20 Jul 2011 15:39:04 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QjfPz-0002Y7-bC; Wed, 20 Jul 2011 22:39:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4E259484.20509@ericsson.com> Date: Wed, 20 Jul 2011 23:39:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E259484.20509@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:39:05 -0000 My preference is for option A: send each RTP session on a separate lower = layer flow (e.g., a separate UDP flow). Yes, this means that your = typical multiparty audio/video conference uses two UDP ports rather than = 1, but I do not believe this is a significant problem, since most = browsers open far more than 2 TCP ports simultaneously when fetching web = resources. That said, I understand the desire to reduce ICE negotiation times. If = this is a real concern (and I'm not convinced it should be, since I = don't see that this adds more than 1 RTT to the negotiation in the usual = case), then some means of explicitly multiplexing RTP sessions might be = useful to develop. I do not believe SSRC-based multiplexing of RTP = sessions works though: we would need to develop a multiplexing mechanism = that conforms to RTP semantics, or get AVTCORE to agree to a change in = RTP with all the backwards compatibility issues that raises. Colin On 19 Jul 2011, at 15:28, Magnus Westerlund wrote: > Hi, >=20 > This email is as an individual contributor. >=20 > I want to get started on the discussion of the Multiplexing of the > various protocols over single lower layer transport flow, such as a = UDP > flow. I will attempt to split up the questions into different emails. >=20 > The first question I think is reasonably easy to get answered, but I > think it is time we determine if my belief in the answer is correct or = not. >=20 > The traffic between two RTCWEB peers from the various components, such > as RTP sessions, datagram service: >=20 > a) MUST be sent as Individual flows for each component. >=20 > b) MUST be multiplexed into a single transport flow. >=20 > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB > peer MUST be able to send them as individual flows. >=20 > I would love if people can indicate their choice or preferences. >=20 > I personally prefer A as it it is simplest in all aspect except the = NAT > traversal. > - It allows for flow based QoS. > - It is the what the implementation that exist mostly do > - Signaling protocols that exist support it, no extra functionality > - People are used to the concept > - It minimizes the difference to legacy. >=20 > Thus it is the quickest road to define something with the least formal > push back and concern over maturity of any solution. >=20 > The downside with B and C is that we do have to solve the multiplexing > and get an agreement that gets through all the hurdles. >=20 > Of these two opens I do prefer C. Although it results in the extra > complexities of having both alternatives, it will give us both a > fallback, flow based QoS and better legacy support. >=20 > Now it is your time to make your opinion heard! >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From matthew.kaufman@skype.net Wed Jul 20 15:39: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 AFBE521F8AEC for ; Wed, 20 Jul 2011 15:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oysM6Nh6OYWY for ; Wed, 20 Jul 2011 15:39:08 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8D32F21F8AEA for ; Wed, 20 Jul 2011 15:39:08 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 8BD32170D; Thu, 21 Jul 2011 00:39:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=6XzXe4m6RZd4+Z IAh5unJ39vTTs=; b=lkHA7MXjd/MZ9E4Xg2V0GLlqd25z8AyXhlsC1XCKgVGyvt jrQx27KjTfLSHJ5ZMXIID3R8IAbEYoh6Vu6mB1F/DXJ0K7mw7sA5y8QmB7wG3wJo gPAn5GE8cNfVOVjG1qZOZIIQRcraoE+1a7E+VzNjlXLJC0x+prvOEpAMkwTbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=gAlWSO69BrDgtrom9GhyM/ pKd3xh6UeMWMAkX52tnm2b7lX/5+LQrZF2G0sXXL0GQC9AOs0BH3AdJDljkIoCsY +3X1hFqMjyAJ2Pf4/jtYOqbzzRwz3bfzq8X0QXgVUv53rbI6qa0eR3Ptmm9zkIO9 IuKKiYjqQ1ihY7E7rHtfc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 8A5CD7F6; Thu, 21 Jul 2011 00:39:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 691653507EB5; Thu, 21 Jul 2011 00:39:07 +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 RdvSMxwfjbvO; Thu, 21 Jul 2011 00:39:06 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 0229B3508191; Thu, 21 Jul 2011 00:39:05 +0200 (CEST) Message-ID: <4E275900.1@skype.net> Date: Wed, 20 Jul 2011 15:38:56 -0700 From: Matthew Kaufman 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: Colin Perkins References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:39:12 -0000 On 7/20/2011 3:31 PM, Colin Perkins wrote: > On 20 Jul 2011, at 22:15, Aron Rosenberg wrote: >> Another +1 for multiplexing everything together. My only worry is >> that the base spec for RTCP doesn't mandate that SSRC is included in >> every RTCP message type, and thus you could end up with the >> multiplexing layer needing to understand every RTCP messaged used >> for video (TMMBR, TMMBN, etc) > > ...which is another reason why this doesn't work in all cases, in > addition to the reasons we document in draft-perkins-rtcweb-rtp-usage-02 > So let me get this straight... RTP and RTCP is broken and inflexible and therefore we must use it, and use it in the broken and inflexible way? If anything this is an argument for ignoring RTP and RTCP and doing something entirely new that is actually appropriate for what we're trying to build, not living with crap just because there's an RFC for it. Matthew Kaufman From matthew.kaufman@skype.net Wed Jul 20 15:40: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 0A01E21F8AE4 for ; Wed, 20 Jul 2011 15:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 VR6vb57AQPZ1 for ; Wed, 20 Jul 2011 15:40:49 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id F29CD21F8AD8 for ; Wed, 20 Jul 2011 15:40:48 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id F33CF170D; Thu, 21 Jul 2011 00:40:47 +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=aA nUG+u3pYWbbO11ew0Oj3RycP0=; b=YBOjNP+zb52C3hyWCwIIpiWHX5+sglnBCb V+J8SGj/aehul422gYk7zD3i4uDkyGT9YSAYP5EMU9J2zHBJthHoXC2cfEomvEpj posqd8qOx6EQebw3kxGuqjCdOIdsXFXpGocLALKYcnjhzENbacxPQ4fFTpJGXRIp WK+z7YZek= 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=MUvyxLdSsv1X9Kh8enzfDB yxRN7OFTqsKMHFVkw/mJL2uherBuAEDAoz2fH/2KPprHLHxfYJBVzOVMevv11h1E x/4ymibO8p+2KskDzX4AhHFHr196H2cFvTTrmOglq1BvY8XGxQ7WiFZyb2fffo1y VzHKIlcXQX5tl7BEIUpjI= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id F15EE7F6; Thu, 21 Jul 2011 00:40:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CECD13508162; Thu, 21 Jul 2011 00:40:47 +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 OVe9NbQOb+cs; Thu, 21 Jul 2011 00:40:47 +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 A52B935080DD; Thu, 21 Jul 2011 00:40:46 +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, 20 Jul 2011 15:40:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32B70422-26ED-4B52-88BD-32EFEF8A2368@skype.net> References: <4E259484.20509@ericsson.com> To: Colin Perkins X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:40:53 -0000 On Jul 20, 2011, at 3:39 PM, Colin Perkins wrote: > we would need to develop a multiplexing mechanism that conforms to RTP = semantics, or get AVTCORE to agree to a change in RTP with all the = backwards compatibility issues that raises. Or decide that RTP is old and broken and not use it at all. Matthew Kaufman= From csp@csperkins.org Wed Jul 20 15:48: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 8644921F8509 for ; Wed, 20 Jul 2011 15:48:22 -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=[AWL=0.000, 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 5Q1RfOEc5FiS for ; Wed, 20 Jul 2011 15:48:18 -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 55F4921F8AEA for ; Wed, 20 Jul 2011 15:48:18 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QjfYv-00025b-X1; Wed, 20 Jul 2011 22:48:17 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4E275900.1@skype.net> Date: Wed, 20 Jul 2011 23:48:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <4E275900.1@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:48:22 -0000 On 20 Jul 2011, at 23:38, Matthew Kaufman wrote: > On 7/20/2011 3:31 PM, Colin Perkins wrote: >> On 20 Jul 2011, at 22:15, Aron Rosenberg wrote: >>> Another +1 for multiplexing everything together. My only worry is = that the base spec for RTCP doesn't mandate that SSRC is included in = every RTCP message type, and thus you could end up with the multiplexing = layer needing to understand every RTCP messaged used for video (TMMBR, = TMMBN, etc) >>=20 >> ...which is another reason why this doesn't work in all cases, in = addition to the reasons we document in draft-perkins-rtcweb-rtp-usage-02 >>=20 >=20 > So let me get this straight... RTP and RTCP is broken and inflexible = and therefore we must use it, and use it in the broken and inflexible = way? >=20 > If anything this is an argument for ignoring RTP and RTCP and doing = something entirely new that is actually appropriate for what we're = trying to build, not living with crap just because there's an RFC for = it. You're free to re-invent that wheel, if you wish. However, if you want = to use RTP for RTCWeb, then you need to accept that doing so has both = some advantages and some disadvantages. One of those disadvantages, for = this application domain, is that it requires an explicit demultiplexing = layer for distinct RTP sessions. Whether that demultiplexing layer is = UDP, or some yet-to-be defined shim layer is a question for this working = group, but something is needed if RTP is used. --=20 Colin Perkins http://csperkins.org/ From matthew.kaufman@skype.net Wed Jul 20 15:55: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 092C821F8AF1 for ; Wed, 20 Jul 2011 15:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 y3J0Ze0t65oR for ; Wed, 20 Jul 2011 15:55:11 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB021F8AEC for ; Wed, 20 Jul 2011 15:55:11 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A01F7170B; Thu, 21 Jul 2011 00:55:10 +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=0/ 3K6SX6ZRwdMrRqlWKrqyl3TFY=; b=hVthpXr25p6txly0Fql8iA7+eX+uqIG9hw e1HSh1QRrcY/UeUO7a3J2aQY7E5vnriR6sCsKncgcD0dDooCbM2NziO1Z8wmCaZK ATPtmF/Rix0z3Gr4GXKel6ekhY6Vo8ujNF4nNoqdgz0/7KysrK74yv76rDE//d+r Io/BarbPs= 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=SWQuzEEYABd/gJJoIt+KSQ ELPE4g/O+HLH0AxAMcyi/1i3QIYoczAx9ea9/EQwirITYbF7qzTUjwM8UaW7ebuD cRTLo/uNnOYGIOsB82CLY9CGxjasxBt48Hp0rjtH6O0CMIlETJv/IyQBCEOxkN/B qFOq0edM7DaSIQPQPmg4U= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 9EC637F6; Thu, 21 Jul 2011 00:55:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 6DD0735081EB; Thu, 21 Jul 2011 00:55:10 +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 UtHTKb8nYnDs; Thu, 21 Jul 2011 00:55:09 +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 43F0035081E4; Thu, 21 Jul 2011 00:55:09 +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, 20 Jul 2011 15:50:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FF53197-3F9F-4324-BDDE-8A5B1F002C25@skype.net> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <4E275900.1@skype.net> To: Colin Perkins X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 22:55:12 -0000 On Jul 20, 2011, at 3:48 PM, Colin Perkins wrote: >=20 >=20 > You're free to re-invent that wheel, if you wish. However, if you want = to use RTP for RTCWeb, then you need to accept that doing so has both = some advantages and some disadvantages. I believe we've managed to demonstrate that the disadvantages are = sufficient to argue against using RTP for RTCWeb. Too bad, because it = seems otherwise like such a good choice. Matthew Kaufman From matthew.kaufman@skype.net Wed Jul 20 16:15: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 F3C7221F8A80 for ; Wed, 20 Jul 2011 16:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 Jtb6I5-UA1QO for ; Wed, 20 Jul 2011 16:15:11 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id DE4D621F8A4E for ; Wed, 20 Jul 2011 16:15:10 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 83B11170B; Thu, 21 Jul 2011 01:15:09 +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=eX PF3Q4OFGP5oE7Vswdjupu9uxs=; b=QdTiD23U7LHaw3fu7c76IqWjslbzd1Beih W8AoxozK7f1zrjzlTOsRR48OCTS6Cp4yo3qLRDsKkbgTGBRTpUZPtzeBZFEZ1CBg O+XVR91KPZ9T5rR3EQD+v94X35XA3Qgck2Qa5MCil3BLkJMdu6XxpnPuISAVz2nu pcGSkRhzY= 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=B1vK7G7G5MvNqHE75m7NPB hbeyvPq/SJk62r8Czmv4tjhy5P7l85MfhE1+ZDGX3Wn8CAl4ecFAmFHVgDJW3Pr6 ElrSDqSTiVWVv24IyNq9LLNUJA4eVCcHL4/KiX8WjL+BBT9ckZIIVC0NgUk2V/8i B+ywCLmwl4Kvp6yrkZykc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 820E87F6; Thu, 21 Jul 2011 01:15:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 1E91835074D8; Thu, 21 Jul 2011 01:15:07 +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 QCs0iaJGlgO5; Thu, 21 Jul 2011 01:15:07 +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 4BCDB350796D; Thu, 21 Jul 2011 01:15:02 +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, 20 Jul 2011 16:15:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03887CB7-98FE-47F0-ACEF-105B3E7917A6@skype.net> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> To: Colin Perkins X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 23:15:15 -0000 On Jul 20, 2011, at 3:31 PM, Colin Perkins wrote: > Except that it doesn't work in all cases: please read the discussion = in draft-perkins-rtpweb-rtp-usage-02. You may argue that you don't think = the breakage is important, but there *is* breakage in doing this, and it = is not backwards compatible. >=20 It doesn't need to be "backwards compatible" in order for two RTCWEB = endpoints to communicate. And the muxing can be disabled in order to = talk to a legacy endpoint. Could we confine the claims about breakage to only ones that are NOT = backwards compatibility issues? Matthew Kaufman From jonathan@vidyo.com Wed Jul 20 16:24: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 36FF821F8AE6 for ; Wed, 20 Jul 2011 16:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45Up+EesUrB4 for ; Wed, 20 Jul 2011 16:24:12 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id A312E21F89C2 for ; Wed, 20 Jul 2011 16:24:12 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 362AB416F6D; Wed, 20 Jul 2011 19:24:12 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB014.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CF9F7416E2F; Wed, 20 Jul 2011 19:24:11 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB014.mail.lan ([10.110.17.14]) with mapi; Wed, 20 Jul 2011 19:23:58 -0400 From: Jonathan Lennox To: Colin Perkins Date: Wed, 20 Jul 2011 19:24:10 -0400 Thread-Topic: [rtcweb] How to multiplex between peers Thread-Index: AcxHNCDem8vzVoXCQPCih8EI7JSZuA== Message-ID: <42CD13B5-C0DB-457B-9131-6081DD795832@vidyo.com> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2011 23:24:13 -0000 > On 20 Jul 2011, at 21:57, Bala Pitchandi wrote: >> +1 for sending audio & video (and any other type of media, for that matt= er) on a single RTP session. With RTCP mux, that means all media can be sen= t on a single UDP port.=20 On Jul 20, 2011, at 6:31 PM, Colin Perkins wrote: > Except that it doesn't work in all cases: please read the discussion in d= raft-perkins-rtpweb-rtp-usage-02. You may argue that you don't think the br= eakage is important, but there *is* breakage in doing this, and it is not b= ackwards compatible. Hi, Colin, I've read draft-perkins-rtcweb-rtp-usage-02, and I still don't understand w= hat you're claiming SSRC-muxing would break. Running audio and video (and FEC, and RTX, and simulcast video, and Real-Ti= me Text, and etc. etc.) in a single RTP session does, not, as far as I've b= een able to tell (after a lot of thought), break anything in RTP. To be sure, it's not backward compatible with RTP endpoints that assume a s= ingle source per session. It would also be hard to retrofit SDP to describ= e and negotiate it. And for some use cases it requires some source-level s= ignaling, as in RFC 5576. But the RTP model, per se, is perfectly amenable= to it, as far as I can tell. I do, very much, dislike the proposal in draft-rosenberg-rtcweb-rtpmux of e= ncoding a magic number into the RTP SSRC -- I think that *does* break a fai= r amount of the RTP model. But this isn't an essential feature of that pro= posal, as far as I can tell; it's just a convenience for deep packet inspec= tors. (Deep packet inspectors already have to use heuristics to distinguis= h audio vs. video RTP flows today, if they can't see signaling; and those t= hat *can* see signaling can just use payload types to distinguish media typ= es in the mux'ed case.) -- Jonathan Lennox jonathan@vidyo.com From henry.sinnreich@gmail.com Wed Jul 20 17:41: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 E3BE421F8AC3 for ; Wed, 20 Jul 2011 17:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=1.104, 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 Bmkv3xRvRxlf for ; Wed, 20 Jul 2011 17:41:44 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53EBE21F8784 for ; Wed, 20 Jul 2011 17:41:44 -0700 (PDT) Received: by gwb20 with SMTP id 20so799306gwb.31 for ; Wed, 20 Jul 2011 17:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=dp7Sc8nkCYX2zNkdnwNW/eazaYQuUuq50yc1Nmrd4kg=; b=NKtNXhRplPPA29A7N313ySR86Qg6Li7bRjJ9kKkUl9rUJ75MfUKSP8AWhU/MhyeUk2 uPqzc6w3CTo6EGI08yWXp3tUbc6WfpfKswVbDtjFhhzfaf3qPUvw0Xcu8+PejMTcgHTX kgbIOrP4lsptxTy9KFeibRrR7z/aXQejmOe3U= Received: by 10.236.190.73 with SMTP id d49mr12704556yhn.517.1311208902432; Wed, 20 Jul 2011 17:41:42 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-164.tx.res.rr.com [76.184.227.164]) by mx.google.com with ESMTPS id z28sm717772yhn.49.2011.07.20.17.41.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 17:41:40 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 20 Jul 2011 19:41:38 -0500 From: Henry Sinnreich To: Matthew Kaufman , Colin Perkins Message-ID: Thread-Topic: [rtcweb] How to multiplex between peers Thread-Index: AcxHPvMpuemYMqiwdkasvGYxXZeuhQ== In-Reply-To: <4E275900.1@skype.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 00:41:45 -0000 +1 > If anything this is an argument for ignoring RTP and RTCP and doing > something entirely new that is actually appropriate for what we're > trying to build, not living with crap just because there's an RFC for it. Not to forget disposing of ancient SDP as well. Use standard metadata instead, since it is equally usable for all apps, not only for RTC apps. Thanks, Henry On 7/20/11 5:38 PM, "Matthew Kaufman" wrote: > On 7/20/2011 3:31 PM, Colin Perkins wrote: >> On 20 Jul 2011, at 22:15, Aron Rosenberg wrote: >>> Another +1 for multiplexing everything together. My only worry is >>> that the base spec for RTCP doesn't mandate that SSRC is included in >>> every RTCP message type, and thus you could end up with the >>> multiplexing layer needing to understand every RTCP messaged used >>> for video (TMMBR, TMMBN, etc) >> >> ...which is another reason why this doesn't work in all cases, in >> addition to the reasons we document in draft-perkins-rtcweb-rtp-usage-02 >> > > So let me get this straight... RTP and RTCP is broken and inflexible and > therefore we must use it, and use it in the broken and inflexible way? > > If anything this is an argument for ignoring RTP and RTCP and doing > something entirely new that is actually appropriate for what we're > trying to build, not living with crap just because there's an RFC for it. > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Wed Jul 20 19:21: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 4EBBC21F8556 for ; Wed, 20 Jul 2011 19:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[AWL=-0.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 BAJ+bJ7ZHeUZ for ; Wed, 20 Jul 2011 19:21:23 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25F21F8550 for ; Wed, 20 Jul 2011 19:21:23 -0700 (PDT) Received: by gwb20 with SMTP id 20so838852gwb.31 for ; Wed, 20 Jul 2011 19:21:22 -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=hMPHGTOHdU9eEBcUx7DTATb0hfH8exY6BR5XKgu/O/4=; b=qzZu8ez+oVk5+6N+iWgnhIXf9c5nQEIIzU3fvHIrVPYYk98XM+jjLpS/ttfZ+YbcsO WmJLKIWhahQldViLbv0KYcAt8XEKACoj6oyAtpUt0dc0vv1Edv7sgt5le12Gqa9VdQVj qt0WEIEXaDSl0Qxz7xFJ2lohAmKYQ6ArfqtAE= Received: by 10.151.21.17 with SMTP id y17mr56946ybi.13.1311214882616; Wed, 20 Jul 2011 19:21:22 -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 h6sm1126676icy.1.2011.07.20.19.21.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 19:21:21 -0700 (PDT) Message-ID: <4E278D2A.4060505@gmail.com> Date: Wed, 20 Jul 2011 19:21:30 -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: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <4E275900.1@skype.net> <9FF53197-3F9F-4324-BDDE-8A5B1F002C25@skype.net> In-Reply-To: <9FF53197-3F9F-4324-BDDE-8A5B1F002C25@skype.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 02:21:27 -0000 On 07/20/2011 03:50 PM, Matthew Kaufman wrote: > On Jul 20, 2011, at 3:48 PM, Colin Perkins wrote: > > >> >> You're free to re-invent that wheel, if you wish. However, if you want to use RTP for RTCWeb, then you need to accept that doing so has both some advantages and some disadvantages. >> > I believe we've managed to demonstrate that the disadvantages are sufficient to argue against using RTP for RTCWeb. Too bad, because it seems otherwise like such a good choice. > > If we digress to rhinophytophilia use-cases, which the step-by-step process exploits good flows in breath analyzers, in RTP sense, then I think this would be the focus to weigh advantages and disadvantages. Not everybody breaths syllables into the net online, imagine some terrified already of such analytics. Maybe someday we can predict this kind of discussion and prepare for the colossal mix of schemes, yet for now there is the coined bit of "no a/s/l". Sane? Certain safety. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From stpeter@stpeter.im Wed Jul 20 19:35: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 A529121F8AF1 for ; Wed, 20 Jul 2011 19:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 RlcO3i8qMHL2 for ; Wed, 20 Jul 2011 19:35:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9921F86D6 for ; Wed, 20 Jul 2011 19:35:12 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3C715410EE; Wed, 20 Jul 2011 20:35:55 -0600 (MDT) Message-ID: <4E27905E.3010608@stpeter.im> Date: Wed, 20 Jul 2011 20:35:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bernard Aboba References: , , , <4E25B2BA.8000004@jesup.org> <4E25B893.6010200@jitsi.org>, , <4E26A354.2020306@ericsson.com> <4E26F460.3080007@jesup.org>, , In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] realiable data service X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 02:35:12 -0000 On 7/20/11 2:37 PM, Bernard Aboba wrote: > Agreed. > > To make this a bit more concrete. From your perspective, what is the > preferred mechanism for file transfer in XMPP, and what would it take to > support this in a browser? The great thing about file transfer mechanisms in XMPP is that there are so many to choose from. :) The most reliable mechanism is "in-band bytestreams", a simple chunking method that uses the XMPP channel itself. That's not the fastest method but it's the most reliable. Clearly it would be faster to set up a direct connection, or if that fails because of NATs to use a relay. We have a technology for that, too, but we don't have a lot of relays deployed on the network. Then there's the pseudo-tcp stuff that Google uses in Google Talk. Or you can upload the file somewhere and just send a URL (which makes a lot of sense if you're using BOSH instead of the traditional TCP connection method). I'm not yet convinced that any of those methods is quite right for RTCWEB, but I haven't studied the problem intensively. Peter From igor.faynberg@alcatel-lucent.com Wed Jul 20 20:34: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 530FC21F888A for ; Wed, 20 Jul 2011 20:34:11 -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 P1MUC+IdiZpw for ; Wed, 20 Jul 2011 20:34:10 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D521F8877 for ; Wed, 20 Jul 2011 20:34:10 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6L3Y9Sk001500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Jul 2011 22:34:09 -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 p6L3Y9ip030290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Jul 2011 22:34:09 -0500 Received: from [135.244.34.25] (faynberg.lra.lucent.com [135.244.34.25]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p6L3Y85H026970; Wed, 20 Jul 2011 22:34:09 -0500 (CDT) Message-ID: <4E279E30.40604@alcatel-lucent.com> Date: Wed, 20 Jul 2011 23:34:08 -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: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <03887CB7-98FE-47F0-ACEF-105B3E7917A6@skype.net> In-Reply-To: <03887CB7-98FE-47F0-ACEF-105B3E7917A6@skype.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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] How to multiplex between peers 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, 21 Jul 2011 03:34:11 -0000 Maybe, at some point. At the moment though I am not convinced that this is the right answer. It always looks easier to re-design everything, but this approach more often than not ends up in a standard (and implementations) full of bugs. Looking at what has transpired in Transport (now RAI) in the past 15 years, one would easily find examples. I think the decision on whether to ignore backward compatibility ought to be made when there is an agreement on core use cases and it is understood that none of them would be broken by lack of backward compatibility. (It is not at all that I am against re-design on principle. Quite the opposite! But I believe that re-design is the research issue; here, we write a standard, and a standard needs to take into account a plethora of issues that the research phase may and should ignore.) Igor On 7/20/2011 7:15 PM, Matthew Kaufman wrote: > ... > > Could we confine the claims about breakage to only ones that are NOT backwards compatibility issues? > > ... From matthew.kaufman@skype.net Wed Jul 20 21:06: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 78F8321F85C7 for ; Wed, 20 Jul 2011 21:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwqZT5XFJohR for ; Wed, 20 Jul 2011 21:06:19 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 41ABA21F85C4 for ; Wed, 20 Jul 2011 21:06:19 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 2D3C6170C; Thu, 21 Jul 2011 06:06:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=KnksLI/VShSJ0m flwitI/2kToUY=; b=xC9epDjQ+fUBKK6fZMVJN5CXePBGgo3oK3lQ01sOrZ4xZI ruxsYzUXU1wp7nbct7qzpQNjzzSorS1/xWVUoWewuRFrN9Kc/pwbpFtMJTV4xhqr sieCyrBOmVMXBJFZ9jzDP929nqDhdxG15JhcnusWkL0wVn0LkhiaGKeF0Wqb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=XeAs3PMAkc0/JezdeFq0iX ewMc/evUvs3tx/t60NOVB2lcyniaRkxdHCB/sYCNYOlzu1eG+aXuXjuFPvB/Bl1n Eec4ejZvZwj+OQ7Qrw5vxCEels9JGcDvY75X3MUbhbDxbB9Kdyp5Fow7ycjyULnx WGIPXsOCrIM1rubmEzGo8= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 2BB7C7FC; Thu, 21 Jul 2011 06:06:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 0C1C435078B1; Thu, 21 Jul 2011 06:06: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 xKyi9cA+QDXb; Thu, 21 Jul 2011 06:06:17 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 0236C3507895; Thu, 21 Jul 2011 06:06:16 +0200 (CEST) Message-ID: <4E27A5AF.3010009@skype.net> Date: Wed, 20 Jul 2011 21:06:07 -0700 From: Matthew Kaufman 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: igor.faynberg@alcatel-lucent.com References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <03887CB7-98FE-47F0-ACEF-105B3E7917A6@skype.net> <4E279E30.40604@alcatel-lucent.com> In-Reply-To: <4E279E30.40604@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 to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 04:06:23 -0000 On 7/20/2011 8:34 PM, Igor Faynberg wrote: > > I think the decision on whether to ignore backward compatibility ought > to be made when there is an agreement on core use cases and it is > understood that none of them would be broken by lack of backward > compatibility. It is trivial to demonstrate that an RTCWEB endpoint talking to another RTCWEB endpoint has no issues with backward compatibility. The deceptive conflation of (possible) real issues with using SSRC as a multiplexing point for A+V over RTP for RTCWEB to RTCWEB and the class of issues that are ONLY relevant when talking RTCWEB to something that requires backwards compatibility is taking us farther, rather than closer, to a resolution on this issue. Once we agree to RTCWEB to Legacy will not use SSRC for multiplexing, there is no need, whatsoever, to bring up the potential backwards compatibility issues again. Matthew Kaufman From ron.even.tlv@gmail.com Wed Jul 20 22:12: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 4368C21F888A for ; Wed, 20 Jul 2011 22:12:40 -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 8RVhgpqeRjgN for ; Wed, 20 Jul 2011 22:12:37 -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 6D2E421F8AFA for ; Wed, 20 Jul 2011 22:12:37 -0700 (PDT) Received: by wwe5 with SMTP id 5so592258wwe.13 for ; Wed, 20 Jul 2011 22:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=Q5c2q4EJqpt0lR92MFYT/2y+S+AsYDkyWdgrhvP1rU8=; b=FETsTsTPR+wdxL2QIOfXtlJRWxEzEzTSMvCzQvnGyhEoanLZHULjaivRfXVGA436Rv rN8JAHAq9U2Omm2tW/DEu+j/h/m3A3hhRw7rUbKacN4f5DPOQQOy3P7nr7vXysfX0e/5 61vPi/PyLwl2S9sB+jv5sz+//Ho+DIRY4Sfpg= Received: by 10.216.66.149 with SMTP id h21mr7929481wed.103.1311225156128; Wed, 20 Jul 2011 22:12:36 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-21-130.red.bezeqint.net [79.183.21.130]) by mx.google.com with ESMTPS id a63sm581805wed.32.2011.07.20.22.12.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 22:12:33 -0700 (PDT) From: "Roni Even" To: "'Aron Rosenberg'" , References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> In-Reply-To: Date: Thu, 21 Jul 2011 08:09:54 +0300 Message-ID: <4e27b541.d53fd80a.1cc4.2e34@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CB_01CC477D.94BE8620" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxHIkzP15ie8RGMQCClem0hO0S8rAAQTz+Q Content-Language: en-us Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 05:12:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01CB_01CC477D.94BE8620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am not sure about your claim. The SSRC of the media sender is always there , otherwise how can RTCP report or request action on a media stream. It is true that for some of the RTCP messages like TMMBR it is inside the FCI part of the message but it is there. As for understanding all RTCP messages, it is not required today and the support is negotiated in SDP. For video streams I assume that RTCweb will mandate the support of controls like FIR and TMBBR. Regards Roni Even From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Aron Rosenberg Sent: Thursday, July 21, 2011 12:16 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers Another +1 for multiplexing everything together. My only worry is that the base spec for RTCP doesn't mandate that SSRC is included in every RTCP message type, and thus you could end up with the multiplexing layer needing to understand every RTCP messaged used for video (TMMBR, TMMBN, etc) ------=_NextPart_000_01CB_01CC477D.94BE8620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am not sure about your claim. The SSRC of the media sender is = always there , otherwise how can RTCP report or request action on a = media stream. It is true that for some of the RTCP messages like TMMBR = it is inside the FCI part of the message but it is there. As for = understanding all RTCP messages, it is not required today and the = support is negotiated in SDP.

For video streams I assume that RTCweb will mandate the support of = controls like FIR and TMBBR.

 

Regards

Roni Even

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Aron Rosenberg
Sent: Thursday, July 21, 2011 12:16 = AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] How to = multiplex between peers

 

Another +1 = for multiplexing everything together. My only worry is that the base = spec for RTCP doesn't mandate that SSRC is included in every RTCP = message type, and thus you could end up with the multiplexing layer = needing to understand every  RTCP messaged used for video (TMMBR, = TMMBN, etc)

 

------=_NextPart_000_01CB_01CC477D.94BE8620-- From stefan.lk.hakansson@ericsson.com Wed Jul 20 22:49: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 05FF321F8AF0 for ; Wed, 20 Jul 2011 22:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.069, 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 NUrc5Z6skBLs for ; Wed, 20 Jul 2011 22:49:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4FF21F8AE6 for ; Wed, 20 Jul 2011 22:49:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-61-4e27be04713b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 02.5C.20773.40EB72E4; Thu, 21 Jul 2011 07:49:56 +0200 (CEST) Received: from [150.132.141.68] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 21 Jul 2011 07:49:55 +0200 Message-ID: <4E27BE02.7090606@ericsson.com> Date: Thu, 21 Jul 2011 07:49: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.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 05:49:58 -0000 On 2011-07-20 16:24, Bernard Aboba wrote: > > > My experience is the answer to the first scenario is not as quick as > you would like and the answer to how long the second takes is about 8 > times longer than the first one. You might do a bit better than that > depending on how clever your implementation is but it still a lot longer. (I think Colin concluded it would be 2 not 8) > > [BA] Yes, that is correct. However at the moment I'd characterize that > as a "high quality problem", since it isn't even clear that the current > WHATWG API can handle that case, due to glare and ICE timing issues. Not sure what you're meaning. We've made an experimental implementation, and do not see glare or ICE timing issues. From csp@csperkins.org Wed Jul 20 23:52: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 44BFE21F84C9 for ; Wed, 20 Jul 2011 23:52:02 -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=[AWL=0.000, 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 ZV4TQtnbM97o for ; Wed, 20 Jul 2011 23:51:58 -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 0B80221F84C5 for ; Wed, 20 Jul 2011 23:51:58 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Qjn6y-0003U2-cS; Thu, 21 Jul 2011 06:51:57 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <42CD13B5-C0DB-457B-9131-6081DD795832@vidyo.com> Date: Thu, 21 Jul 2011 07:51:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <42CD13B5-C0DB-457B-9131-6081DD795832@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 06:52:02 -0000 On 21 Jul 2011, at 00:24, Jonathan Lennox wrote: ... > I've read draft-perkins-rtcweb-rtp-usage-02, and I still don't = understand what you're claiming SSRC-muxing would break. >=20 > Running audio and video (and FEC, and RTX, and simulcast video, and = Real-Time Text, and etc. etc.) in a single RTP session does, not, as far = as I've been able to tell (after a lot of thought), break anything in = RTP. >=20 > To be sure, it's not backward compatible with RTP endpoints that = assume a single source per session. It would also be hard to retrofit = SDP to describe and negotiate it. And for some use cases it requires = some source-level signaling, as in RFC 5576. But the RTP model, per se, = is perfectly amenable to it, as far as I can tell. Section 2.2.1 of draft-perkins-rtcweb-rtp-usage-02 lists several = problems that occur when multiplexing RTP sessions onto a single = lower-level flow.=20 There are clearly some limitations caused: separate endpoints, quality = of service, limitations with mixers and translators, retransmission, = FEC, sampling group membership, and so on. There is also some breakage = when several sessions are multiplexed: RTCP is problematic with several = clock rates per session, SSRC allocation is broken, and the RTCP = reporting interval and timing rules are broken. You may not think some of these are important. Some can be avoided by = the use of appropriate signalling. Some can be mitigated by allowing = multiple different media types in an RTP session, or by splitting the = SSRC space. I'm not arguing that there aren't ways to fix this problem, = or ignore it in some cases, but they cause various degrees of change to = RTP, and need to be carefully evaluated by AVTCORE if they're to be = done.=20 --=20 Colin Perkins http://csperkins.org/ From stewe@stewe.org Thu Jul 21 00:43: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 E319621F8B24 for ; Thu, 21 Jul 2011 00:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 9cTk-TwyAgpg for ; Thu, 21 Jul 2011 00:43:19 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 56B0421F8B1E for ; Thu, 21 Jul 2011 00:43:19 -0700 (PDT) Received: from [172.20.12.62] (unverified [130.192.232.10]) by stewe.org (SurgeMail 3.9e) with ESMTP id 15567-1743317 for multiple; Thu, 21 Jul 2011 09:43:18 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 21 Jul 2011 00:43:10 -0700 From: Stephan Wenger To: Colin Perkins , Jonathan Lennox Message-ID: Thread-Topic: [rtcweb] How to multiplex between peers In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 130.192.232.10 X-Authenticated-User: stewe@stewe.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 07:43:21 -0000 Hi Colin, On 7.20.2011 23:51 , "Colin Perkins" wrote: >On 21 Jul 2011, at 00:24, Jonathan Lennox wrote: >... >> I've read draft-perkins-rtcweb-rtp-usage-02, and I still don't >>understand what you're claiming SSRC-muxing would break. >> >> Running audio and video (and FEC, and RTX, and simulcast video, and >>Real-Time Text, and etc. etc.) in a single RTP session does, not, as far >>as I've been able to tell (after a lot of thought), break anything in >>RTP. >> >> To be sure, it's not backward compatible with RTP endpoints that assume >>a single source per session. It would also be hard to retrofit SDP to >>describe and negotiate it. And for some use cases it requires some >>source-level signaling, as in RFC 5576. But the RTP model, per se, is >>perfectly amenable to it, as far as I can tell. > > >Section 2.2.1 of draft-perkins-rtcweb-rtp-usage-02 lists several problems >that occur when multiplexing RTP sessions onto a single lower-level flow. > >There are clearly some limitations caused: separate endpoints, quality of >service, limitations with mixers and translators, retransmission, FEC, >sampling group membership, and so on. There is also some breakage when >several sessions are multiplexed: RTCP is problematic with several clock >rates per session, SSRC allocation is broken, and the RTCP reporting >interval and timing rules are broken. > >You may not think some of these are important. Some can be avoided by the >use of appropriate signalling. Some can be mitigated by allowing multiple >different media types in an RTP session, or by splitting the SSRC space. >I'm not arguing that there aren't ways to fix this problem, or ignore it >in some cases, but they cause various degrees of change to RTP, and need >to be carefully evaluated by AVTCORE if they're to be done. Rtcweb is working towards what I would call a "system" specification--something, the IETF (or at least RAI) is not usually involved in. Outside the IETF, it's not uncommon that "system" specifications effectively modify an underlying base specification--RTP in this case. Such modifications can as easily remove functionality deemed unnecessary as add new one. Speaking about session multiplexing as an example, I would guess that a lot of people here are implicitly arguing removal of functionality of RTP not needed for the application--namely multicast support. SSRC (re-)allocation) may be broken, but since there should not be any need for it (no multicast), who cares? RTCP reporting intervals and timing rules are broken: again, who cares if the RTP/RTCP communication relationship is either endpoint-endpoint or endpoint-MCU (and RTCP is not being forwarded to all endpoints)? RTCP-Terminating MCU and not Mixer in RFC 5117 namespace? We will not see network flooding or something with RTCP RRs in point-to-point RTP communication relationships... I have not thought about RTCP's issues with multiple clock rates, but those difficulties are probably not insurmountable, either, because, while there may be multiple clock rates, those ought to be a finite, and small, set. Now to my key point: you argue these things need to be "carefully evaluated" in AVTCORE. IMO, while it may be desirable for AVTCORE experts to chip in (as they do on this very thread already:-), it is by no means necessary. Neither formally, not practically. And certainly AVTCORE should not assume a "blocking" position. This puts IETF system level specification at a disadvantage to system level specification work elsewhere (where it happens on a daily basis, see ITU, see 3GPP), and where no one asks for AVTCORE's permission to re-use RTP data structures without re-using all of RTP. Tinkering with the multicast functionally of RTP is not new, there is a lot of implementation experience in the field, and for once we can indeed rely on "running code" answers. I advocate pragmatism. (And, heretic as I am, in the long term we should think about RTPv3, dumping multicast. Have I said this before? :-) Regards, Stephan P.s.: I haven't though much about shim layers or other techniques that multiplex RTP sessions on a single low level flow. If any of these ideas were implemented only to preserve RTP functionalities not needed for the application in question, then I would argue that being a silly idea. > > >-- >Colin Perkins >http://csperkins.org/ > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From csp@csperkins.org Thu Jul 21 01:25: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 B9E3F21F8B75 for ; Thu, 21 Jul 2011 01:25:09 -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=[AWL=0.000, 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 GtdBR7tMsRBw for ; Thu, 21 Jul 2011 01:25:09 -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 0F22321F85E3 for ; Thu, 21 Jul 2011 01:25:09 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QjoZA-0002Hp-WG; Thu, 21 Jul 2011 08:25:08 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Thu, 21 Jul 2011 09:25:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephan Wenger X-Mailer: Apple Mail (2.1084) Cc: Jonathan Lennox , rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 08:25:09 -0000 On 21 Jul 2011, at 08:43, Stephan Wenger wrote: > On 7.20.2011 23:51 , "Colin Perkins" wrote: >> On 21 Jul 2011, at 00:24, Jonathan Lennox wrote: >> ... > Rtcweb is working towards what I would call a "system" = specification--something, the IETF (or at least RAI) is not usually = involved in. Outside the IETF, it's not uncommon that "system" = specifications effectively modify an underlying base specification--RTP = in this case. Such modifications can as easily remove functionality = deemed unnecessary as add new one. >=20 > Speaking about session multiplexing as an example, I would guess that = a lot of people here are implicitly arguing removal of functionality of = RTP not needed for the application--namely multicast support. SSRC = (re-)allocation) may be broken, but since there should not be any need = for it (no multicast), who cares? RTCP reporting intervals and timing = rules are broken: again, who cares if the RTP/RTCP communication = relationship is either endpoint-endpoint or endpoint-MCU (and RTCP is = not being forwarded to all endpoints)? RTCP-Terminating MCU and not = Mixer in RFC 5117 namespace? We will not see network flooding or = something with RTCP RRs in point-to-point RTP communication = relationships... I have not thought about RTCP's issues with multiple = clock rates, but those difficulties are probably not insurmountable, = either, because, while there may be multiple clock rates, those ought to = be a finite, and small, set. I don't think anyone is arguing that there difficulties cannot be = solved. Of course they can. What's being argued is that the result is = different to RTP, is not backwards compatible, and is difficult to = gateway into a standard RTP environment.=20 Some of us believe that there's benefit to being able to reuse the RTP = infrastructure, and to easily interoperate with existing systems. I do = not believe the benefit of saving a small number of UDP ports, in a = browser environment that regularly uses dozens of TCP ports, outweighs = the loss of compatibility with other systems. > Now to my key point: you argue these things need to be "carefully = evaluated" in AVTCORE. IMO, while it may be desirable for AVTCORE = experts to chip in (as they do on this very thread already:-), it is by = no means necessary. Neither formally, not practically. And certainly = AVTCORE should not assume a "blocking" position. This puts IETF system = level specification at a disadvantage to system level specification work = elsewhere (where it happens on a daily basis, see ITU, see 3GPP), and = where no one asks for AVTCORE's permission to re-use RTP data structures = without re-using all of RTP. Tinkering with the multicast functionally = of RTP is not new, there is a lot of implementation experience in the = field, and for once we can indeed rely on "running code" answers. >=20 > I advocate pragmatism. (And, heretic as I am, in the long term we = should think about RTPv3, dumping multicast. Have I said this before? = :-) You have, of course. Many people have. What's not clear to be is how you = would remove multicast support from RTP without also removing multiparty = support? I see lots of RTP features that are there to support group = communication, very few that are specific to multicast. And, besides, I can certainly envisage scenarios where one might want a = browser-based RTP implementation to watch the multicast IPTV flows that = ISPs are now offering.=20 Colin= From harald@alvestrand.no Thu Jul 21 02:16: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 6DD2521F89C1 for ; Thu, 21 Jul 2011 02:16:40 -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 MEfAuM2gTVOk for ; Thu, 21 Jul 2011 02:16:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 679D621F88DC for ; Thu, 21 Jul 2011 02:16:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 457F739E0FC for ; Thu, 21 Jul 2011 11:15:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pRVQz6ZWf5Q for ; Thu, 21 Jul 2011 11:15:25 +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 31EBA39E0FA for ; Thu, 21 Jul 2011 11:15:25 +0200 (CEST) Message-ID: <4E27EE6E.30600@alvestrand.no> Date: Thu, 21 Jul 2011 11:16:30 +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] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 09:16:40 -0000 On 07/21/11 02:41, Henry Sinnreich wrote: > +1 > >> If anything this is an argument for ignoring RTP and RTCP and doing >> something entirely new that is actually appropriate for what we're >> trying to build, not living with crap just because there's an RFC for it. > Not to forget disposing of ancient SDP as well. > Use standard metadata instead, since it is equally usable for all apps, not > only for RTC apps. Henry, which standard? http://www.xkcd.com/927/ applies to metadata too, I think. > Thanks, Henry > > > On 7/20/11 5:38 PM, "Matthew Kaufman" wrote: > >> On 7/20/2011 3:31 PM, Colin Perkins wrote: >>> On 20 Jul 2011, at 22:15, Aron Rosenberg wrote: >>>> Another +1 for multiplexing everything together. My only worry is >>>> that the base spec for RTCP doesn't mandate that SSRC is included in >>>> every RTCP message type, and thus you could end up with the >>>> multiplexing layer needing to understand every RTCP messaged used >>>> for video (TMMBR, TMMBN, etc) >>> ...which is another reason why this doesn't work in all cases, in >>> addition to the reasons we document in draft-perkins-rtcweb-rtp-usage-02 >>> >> So let me get this straight... RTP and RTCP is broken and inflexible and >> therefore we must use it, and use it in the broken and inflexible way? >> >> If anything this is an argument for ignoring RTP and RTCP and doing >> something entirely new that is actually appropriate for what we're >> trying to build, not living with crap just because there's an RFC for it. >> >> Matthew Kaufman >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From stewe@stewe.org Thu Jul 21 02:18: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 2308421F8B76 for ; Thu, 21 Jul 2011 02:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 2BoqZWLCd173 for ; Thu, 21 Jul 2011 02:18:40 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0021621F88DC for ; Thu, 21 Jul 2011 02:18:39 -0700 (PDT) Received: from [172.20.50.58] (unverified [130.192.232.17]) by stewe.org (SurgeMail 3.9e) with ESMTP id 15594-1743317 for multiple; Thu, 21 Jul 2011 11:18:38 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 21 Jul 2011 02:01:31 -0700 From: Stephan Wenger To: Colin Perkins Message-ID: Thread-Topic: [rtcweb] How to multiplex between peers In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 130.192.232.17 X-Authenticated-User: stewe@stewe.org Cc: Jonathan Lennox , rtcweb@ietf.org Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 09:18:41 -0000 Hi Colin, On 7.21.2011 01:25 , "Colin Perkins" wrote: >[...] > >> Now to my key point: you argue these things need to be "carefully >>evaluated" in AVTCORE. IMO, while it may be desirable for AVTCORE >>experts to chip in (as they do on this very thread already:-), it is by >>no means necessary. Neither formally, not practically. And certainly >>AVTCORE should not assume a "blocking" position. This puts IETF system >>level specification at a disadvantage to system level specification work >>elsewhere (where it happens on a daily basis, see ITU, see 3GPP), and >>where no one asks for AVTCORE's permission to re-use RTP data structures >>without re-using all of RTP. Tinkering with the multicast functionally >>of RTP is not new, there is a lot of implementation experience in the >>field, and for once we can indeed rely on "running code" answers. >> >> I advocate pragmatism. (And, heretic as I am, in the long term we >>should think about RTPv3, dumping multicast. Have I said this before? >>:-) > >You have, of course. Many people have. What's not clear to be is how you >would remove multicast support from RTP without also removing multiparty >support? I see lots of RTP features that are there to support group >communication, very few that are specific to multicast. Remove multiparty support, then. Terminology glitch on my side. > >And, besides, I can certainly envisage scenarios where one might want a >browser-based RTP implementation to watch the multicast IPTV flows that >ISPs are now offering. There is no reason why RTPv2 and RTPv3 couldn't co-exist, in a browser or elsewhere. They do, today, if you have a videoconferencing software and an IPTV software on the same box. It would be stupid to deprecate RTPv2 including multiparty support; no one I know is arguing in favor of that. Problem is, AVT (and, admittedly, the industry at large) did not act on the RTPv3 idea. Instead, application spec profiling continued with many (dozens? I lost count a long time ago) of non-interoperabile solutions for the optimized-for-point-to-point RTP space. (To a certain extent that even happens in the multiparty case with different IPTV standards.) We are about to create one more P2P RTP flavor here. That's sad, but (I fear) now unavoidable. From what I gather, people don't think we can wait half a decade for an RTPv3 proposal to make it through an AVT-to-be-named WG. Stephan > > >Colin From keith.drage@alcatel-lucent.com Thu Jul 21 03:44: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 388DE21F8B14 for ; Thu, 21 Jul 2011 03:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v4mLnbrm8ob for ; Thu, 21 Jul 2011 03:44:45 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F53A21F8B16 for ; Thu, 21 Jul 2011 03:44:44 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6LAieLn002402 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Jul 2011 12:44:40 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 21 Jul 2011 12:44:40 +0200 From: "DRAGE, Keith (Keith)" To: Stephan Wenger , Colin Perkins , Jonathan Lennox Date: Thu, 21 Jul 2011 12:44:38 +0200 Thread-Topic: [rtcweb] How to multiplex between peers Thread-Index: AcxHeeE7Tg1Gpm9tSIO//vLcVKVhtAAGNCLQ 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 10:44:49 -0000 This discussion seems to be hovering in some sort of middle ground. Either 1) It has not decided what transport to use for real time data, in which case = it should document the requirements for such a transport protocol, and then= evaluate whether existing solutions meet those requirements, versus develo= ping an entirely new protocol. Or 2) I has decided that RTP should be used, in which case it should identify the= shortcomings (i.e. a set of requirements on how it needs to be further dev= eloped) and send these to the AVTCORE working group. Neither of those seem to be happening at the moment. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Stephan Wenger > Sent: 21 July 2011 08:43 > To: Colin Perkins; Jonathan Lennox > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] How to multiplex between peers >=20 > Hi Colin, >=20 > On 7.20.2011 23:51 , "Colin Perkins" wrote: >=20 > >On 21 Jul 2011, at 00:24, Jonathan Lennox wrote: > >... > >> I've read draft-perkins-rtcweb-rtp-usage-02, and I still don't > >>understand what you're claiming SSRC-muxing would break. > >> > >> Running audio and video (and FEC, and RTX, and simulcast video, and > >>Real-Time Text, and etc. etc.) in a single RTP session does, not, as fa= r > >>as I've been able to tell (after a lot of thought), break anything in > >>RTP. > >> > >> To be sure, it's not backward compatible with RTP endpoints that assum= e > >>a single source per session. It would also be hard to retrofit SDP to > >>describe and negotiate it. And for some use cases it requires some > >>source-level signaling, as in RFC 5576. But the RTP model, per se, is > >>perfectly amenable to it, as far as I can tell. > > > > > >Section 2.2.1 of draft-perkins-rtcweb-rtp-usage-02 lists several problem= s > >that occur when multiplexing RTP sessions onto a single lower-level flow= . > > > >There are clearly some limitations caused: separate endpoints, quality o= f > >service, limitations with mixers and translators, retransmission, FEC, > >sampling group membership, and so on. There is also some breakage when > >several sessions are multiplexed: RTCP is problematic with several clock > >rates per session, SSRC allocation is broken, and the RTCP reporting > >interval and timing rules are broken. > > > >You may not think some of these are important. Some can be avoided by th= e > >use of appropriate signalling. Some can be mitigated by allowing multipl= e > >different media types in an RTP session, or by splitting the SSRC space. > >I'm not arguing that there aren't ways to fix this problem, or ignore it > >in some cases, but they cause various degrees of change to RTP, and need > >to be carefully evaluated by AVTCORE if they're to be done. >=20 > Rtcweb is working towards what I would call a "system" > specification--something, the IETF (or at least RAI) is not usually > involved in. Outside the IETF, it's not uncommon that "system" > specifications effectively modify an underlying base specification--RTP i= n > this case. Such modifications can as easily remove functionality deemed > unnecessary as add new one. >=20 > Speaking about session multiplexing as an example, I would guess that a > lot of people here are implicitly arguing removal of functionality of RTP > not needed for the application--namely multicast support. SSRC > (re-)allocation) may be broken, but since there should not be any need fo= r > it (no multicast), who cares? RTCP reporting intervals and timing rules > are broken: again, who cares if the RTP/RTCP communication relationship i= s > either endpoint-endpoint or endpoint-MCU (and RTCP is not being forwarded > to all endpoints)? RTCP-Terminating MCU and not Mixer in RFC 5117 > namespace? We will not see network flooding or something with RTCP RRs i= n > point-to-point RTP communication relationships... I have not thought abou= t > RTCP's issues with multiple clock rates, but those difficulties are > probably not insurmountable, either, because, while there may be multiple > clock rates, those ought to be a finite, and small, set. >=20 > Now to my key point: you argue these things need to be "carefully > evaluated" in AVTCORE. > IMO, while it may be desirable for AVTCORE experts to chip in (as they do > on this very thread already:-), it is by no means necessary. Neither > formally, not practically. And certainly AVTCORE should not assume a > "blocking" position. This puts IETF system level specification at a > disadvantage to system level specification work elsewhere (where it > happens on a daily basis, see ITU, see 3GPP), and where no one asks for > AVTCORE's permission to re-use RTP data structures without re-using all o= f > RTP. Tinkering with the multicast functionally of RTP is not new, there > is a lot of implementation experience in the field, and for once we can > indeed rely on "running code" answers. >=20 > I advocate pragmatism. > (And, heretic as I am, in the long term we should think about RTPv3, > dumping multicast. Have I said this before? :-) >=20 > Regards, > Stephan >=20 > P.s.: I haven't though much about shim layers or other techniques that > multiplex RTP sessions on a single low level flow. If any of these ideas > were implemented only to preserve RTP functionalities not needed for the > application in question, then I would argue that being a silly idea. >=20 > > > > > >-- > >Colin Perkins > >http://csperkins.org/ > > > > > > > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Jul 21 04:05: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 2910121F8B0A for ; Thu, 21 Jul 2011 04:05:33 -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 KDVX4uL-S4DL for ; Thu, 21 Jul 2011 04:05:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 878E721F8A4E for ; Thu, 21 Jul 2011 04:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D662D39E13B for ; Thu, 21 Jul 2011 13:04:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84vOC53FBXDb for ; Thu, 21 Jul 2011 13:04:25 +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 45E7E39E0FC for ; Thu, 21 Jul 2011 13:04:25 +0200 (CEST) Message-ID: <4E2807FA.7020405@alvestrand.no> Date: Thu, 21 Jul 2011 13:05:30 +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] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 11:05:33 -0000 On 07/21/11 12:44, DRAGE, Keith (Keith) wrote: > This discussion seems to be hovering in some sort of middle ground. > > Either 1) > > It has not decided what transport to use for real time data, in which case it should document the requirements for such a transport protocol, and then evaluate whether existing solutions meet those requirements, versus developing an entirely new protocol. > > Or 2) > > I has decided that RTP should be used, in which case it should identify the shortcomings (i.e. a set of requirements on how it needs to be further developed) and send these to the AVTCORE working group. Don't forget 3) It has decided that RTP should be used, with no changes and no new extensions, and is going through the ritual of swearing at the resulting shortcomings while figuring out which parts of RTP it can say "we don't need them, so it's OK to do things that mean we can't use them" to. If this group gets lined up behind an 1-year dependency on another group before it can deliver its initial work products, this group is going to be irrelevant. Harald From keith.drage@alcatel-lucent.com Thu Jul 21 04:56: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 8FA1521F85EA for ; Thu, 21 Jul 2011 04:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV7rdjIGeVFD for ; Thu, 21 Jul 2011 04:56:14 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id C035E21F85B5 for ; Thu, 21 Jul 2011 04:56:13 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6LBtMcs021114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Jul 2011 13:56:09 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 21 Jul 2011 13:56:01 +0200 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 21 Jul 2011 13:56:00 +0200 Thread-Topic: [rtcweb] How to multiplex between peers Thread-Index: AcxHliJl+AJ+ysq2Tqm2CvyVdi8f9wABs29A Message-ID: References: <4E2807FA.7020405@alvestrand.no> In-Reply-To: <4E2807FA.7020405@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 11:56:14 -0000 Agreed. 3 options. I'd rephrase the third as package only what is available= amongst existing protocol, and document what it doesn't do as a result. But the current discussion is still in middle ground between all of them wi= th no clear direction forward as to which it wants to do. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Harald Alvestrand > Sent: 21 July 2011 12:06 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] How to multiplex between peers >=20 > On 07/21/11 12:44, DRAGE, Keith (Keith) wrote: > > This discussion seems to be hovering in some sort of middle ground. > > > > Either 1) > > > > It has not decided what transport to use for real time data, in which > case it should document the requirements for such a transport protocol, > and then evaluate whether existing solutions meet those requirements, > versus developing an entirely new protocol. > > > > Or 2) > > > > I has decided that RTP should be used, in which case it should identify > the shortcomings (i.e. a set of requirements on how it needs to be furthe= r > developed) and send these to the AVTCORE working group. > Don't forget >=20 > 3) >=20 > It has decided that RTP should be used, with no changes and no new > extensions, and is going through the ritual of swearing at the resulting > shortcomings while figuring out which parts of RTP it can say "we don't > need them, so it's OK to do things that mean we can't use them" to. >=20 > If this group gets lined up behind an 1-year dependency on another group > before it can deliver its initial work products, this group is going to > be irrelevant. >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Thu Jul 21 07:28: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 5001021F880C for ; Thu, 21 Jul 2011 07:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[AWL=-0.597, 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 5I0N+MaE8WyD for ; Thu, 21 Jul 2011 07:28:10 -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 66C8921F8779 for ; Thu, 21 Jul 2011 07:28:10 -0700 (PDT) Received: by pvh18 with SMTP id 18so1634306pvh.31 for ; Thu, 21 Jul 2011 07:28:09 -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=Osi/7Fg/bZiDm+PrDq0TPjG8DaYgDt0V3s8KAhcNwdw=; b=fvf5n9abN7hoPQWnEXQUGAjezruwIkhn/bmo7hwO6QlZa/OQH3bdT4evhwTmv5QZoC kzVTVp9qqGiDP+gtGpcj80AH/7csScApXpj8blX5WhzAeB8XidrHl8ZGh2elFgOT2pFs KzRs8Bh28xbn8d+WV655Xwrm3MhKEZ+gg3/yY= Received: by 10.68.46.200 with SMTP id x8mr398185pbm.87.1311258476659; Thu, 21 Jul 2011 07:27:56 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id d1sm922668pbj.56.2011.07.21.07.27.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jul 2011 07:27:54 -0700 (PDT) Message-ID: <4E283775.7090300@gmail.com> Date: Thu, 21 Jul 2011 07:28:05 -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: <4E2807FA.7020405@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 14:28:14 -0000 Yes, and note that the issue experienced is more wide-spread than this WG. This is clearly evident when protocols attempt to sustain stateful connections and virtualization later proves false security. Keep this in mind before thinking to toss RTP and UDP. I can't even uphold SSL as sustainable anymore. On 07/21/2011 04:56 AM, DRAGE, Keith (Keith) wrote: > Agreed. 3 options. I'd rephrase the third as package only what is available amongst existing protocol, and document what it doesn't do as a result. > > But the current discussion is still in middle ground between all of them with no clear direction forward as to which it wants to do. > > Regards > > Keith > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Harald Alvestrand >> Sent: 21 July 2011 12:06 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] How to multiplex between peers >> >> On 07/21/11 12:44, DRAGE, Keith (Keith) wrote: >> >>> This discussion seems to be hovering in some sort of middle ground. >>> >>> Either 1) >>> >>> It has not decided what transport to use for real time data, in which >>> >> case it should document the requirements for such a transport protocol, >> and then evaluate whether existing solutions meet those requirements, >> versus developing an entirely new protocol. >> >>> Or 2) >>> >>> I has decided that RTP should be used, in which case it should identify >>> >> the shortcomings (i.e. a set of requirements on how it needs to be further >> developed) and send these to the AVTCORE working group. >> Don't forget >> >> 3) >> >> It has decided that RTP should be used, with no changes and no new >> extensions, and is going through the ritual of swearing at the resulting >> shortcomings while figuring out which parts of RTP it can say "we don't >> need them, so it's OK to do things that mean we can't use them" to. >> >> If this group gets lined up behind an 1-year dependency on another group >> before it can deliver its initial work products, this group is going to >> be irrelevant. >> >> Harald >> >> _______________________________________________ >> 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 > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From henry.sinnreich@gmail.com Thu Jul 21 08: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 BB6E321F85B9 for ; Thu, 21 Jul 2011 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=0.828, 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 RSUEwcsnCBYq for ; Thu, 21 Jul 2011 08:36:32 -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 7C80221F858D for ; Thu, 21 Jul 2011 08:36:32 -0700 (PDT) Received: by yxp4 with SMTP id 4so818244yxp.31 for ; Thu, 21 Jul 2011 08:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=pKD6bq9kaiHdjz0CAxASLIOdLrR3XExhFomeg3Jktbo=; b=J7mXd+wj5cZRwAURoq8G/IGfGwqgZv8yB0Gc3+GDwjA2G/MBe2Za+qu83RZGc6clBq 1wD46Ddn59fILdhEZPNyGuKZo39AWwnFD1f1AdS8AJXQjKurnS9r21pthVWTJ2lHjQVA 30/at+uNRzRNZZyoBqYBpayJKHgCnYS7FLoOQ= Received: by 10.101.145.19 with SMTP id x19mr411273ann.152.1311262589990; Thu, 21 Jul 2011 08:36:29 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-164.tx.res.rr.com [76.184.227.164]) by mx.google.com with ESMTPS id h31sm1710967ann.5.2011.07.21.08.36.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jul 2011 08:36:28 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 21 Jul 2011 10:36:22 -0500 From: Henry Sinnreich To: Harald Alvestrand , Message-ID: Thread-Topic: [rtcweb] How to multiplex between peers Thread-Index: AcxHu/FRSSToPlSK2U6fFTu4hW90pQ== In-Reply-To: <4E27EE6E.30600@alvestrand.no> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 15:36:36 -0000 > Henry, which standard? Thanks for the good question Harald! A good start for metadata standards to replace SDP and thus applicable across any web apps is http://dublincore.org/metadata-basics/ Such metadata is actually implemented in successful RAI products, but I would rather not go there on this post. Henry On 7/21/11 4:16 AM, "Harald Alvestrand" wrote: > On 07/21/11 02:41, Henry Sinnreich wrote: >> +1 >> >>> If anything this is an argument for ignoring RTP and RTCP and doing >>> something entirely new that is actually appropriate for what we're >>> trying to build, not living with crap just because there's an RFC for it. >> Not to forget disposing of ancient SDP as well. >> Use standard metadata instead, since it is equally usable for all apps, not >> only for RTC apps. > Henry, which standard? > http://www.xkcd.com/927/ applies to metadata too, I think. > >> Thanks, Henry >> >> >> On 7/20/11 5:38 PM, "Matthew Kaufman" wrote: >> >>> On 7/20/2011 3:31 PM, Colin Perkins wrote: >>>> On 20 Jul 2011, at 22:15, Aron Rosenberg wrote: >>>>> Another +1 for multiplexing everything together. My only worry is >>>>> that the base spec for RTCP doesn't mandate that SSRC is included in >>>>> every RTCP message type, and thus you could end up with the >>>>> multiplexing layer needing to understand every RTCP messaged used >>>>> for video (TMMBR, TMMBN, etc) >>>> ...which is another reason why this doesn't work in all cases, in >>>> addition to the reasons we document in draft-perkins-rtcweb-rtp-usage-02 >>>> >>> So let me get this straight... RTP and RTCP is broken and inflexible and >>> therefore we must use it, and use it in the broken and inflexible way? >>> >>> If anything this is an argument for ignoring RTP and RTCP and doing >>> something entirely new that is actually appropriate for what we're >>> trying to build, not living with crap just because there's an RFC for it. >>> >>> Matthew Kaufman >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From jonathan@vidyo.com Thu Jul 21 08:59: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 2377521F88A5 for ; Thu, 21 Jul 2011 08:59:36 -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 mIOOKfuD3mbu for ; Thu, 21 Jul 2011 08:59:35 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 695FF21F88A0 for ; Thu, 21 Jul 2011 08:59:35 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 83ADA8BF083; Thu, 21 Jul 2011 11:59:34 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id C9AEE8BF07D; Thu, 21 Jul 2011 11:59:30 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Thu, 21 Jul 2011 11:59:30 -0400 From: Jonathan Lennox To: Colin Perkins Date: Thu, 21 Jul 2011 11:59:29 -0400 Thread-Topic: [rtcweb] How to multiplex between peers Thread-Index: AcxHvyyYPaXxM6UoQcu5AVt+CTFOqQ== Message-ID: <0AB1DB80-7C10-4C84-ABCC-358A3E49640F@vidyo.com> References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <42CD13B5-C0DB-457B-9131-6081DD795832@vidyo.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2011 15:59:36 -0000 On Jul 21, 2011, at 2:51 AM, Colin Perkins wrote: > On 21 Jul 2011, at 00:24, Jonathan Lennox wrote: > ... >> I've read draft-perkins-rtcweb-rtp-usage-02, and I still don't understan= d what you're claiming SSRC-muxing would break. >>=20 >> Running audio and video (and FEC, and RTX, and simulcast video, and Real= -Time Text, and etc. etc.) in a single RTP session does, not, as far as I'v= e been able to tell (after a lot of thought), break anything in RTP. >>=20 >> To be sure, it's not backward compatible with RTP endpoints that assume = a single source per session. It would also be hard to retrofit SDP to desc= ribe and negotiate it. And for some use cases it requires some source-leve= l signaling, as in RFC 5576. But the RTP model, per se, is perfectly amena= ble to it, as far as I can tell. >=20 >=20 > Section 2.2.1 of draft-perkins-rtcweb-rtp-usage-02 lists several problems= that occur when multiplexing RTP sessions onto a single lower-level flow.= =20 >=20 > There are clearly some limitations caused: separate endpoints, quality of= service, limitations with mixers and translators, retransmission, FEC, sam= pling group membership, and so on. There is also some breakage when several= sessions are multiplexed: RTCP is problematic with several clock rates per= session, SSRC allocation is broken, and the RTCP reporting interval and ti= ming rules are broken. >=20 > You may not think some of these are important. Some can be avoided by the= use of appropriate signalling. Some can be mitigated by allowing multiple = different media types in an RTP session, or by splitting the SSRC space. I'= m not arguing that there aren't ways to fix this problem, or ignore it in s= ome cases, but they cause various degrees of change to RTP, and need to be = carefully evaluated by AVTCORE if they're to be done.=20 I absolutely agree that multiplexing several RTP sessions into a single low= er-level flow could break things, but that's not what I'm advocating. Inst= ead, I'm only advocating relaxing the rule that every source in a *single* = RTP session -- a session which follows all the RFC 3550 rules -- must have = the same top-level media type. Since RTP was defined to allow up to 2^32-1 distinct sources in a session, = all the rules of RFC 3550 seem to follow naturally, as do other RTP-family = specs except those whose designers forgot to take RTP's group-communication= nature into account. It may be useful to relax *more* rules, for the topological cases that Step= han mentioned (endpoint-endpoint or RTCP-terminating-MCU) -- particularly s= ince a lot of RTP's (or specifically, RTCP's) existing timing rules don't m= ake a lot of sense in scenarios where you have widely asymmetric bandwidths= . This might need to formally be a new RTP profile, though I'd rather avoi= d that if possible. But the starting point should be, I think, assuming a = single RTP session with arbitrarily many distinct sources, and see if the R= FC 3550 rules lead us somewhere bad *in that scenario*. -- Jonathan Lennox jonathan@vidyo.com From dzonatas@gmail.com Fri Jul 22 15:18: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 97DAA21F8B69 for ; Fri, 22 Jul 2011 15:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.18 X-Spam-Level: X-Spam-Status: No, score=-4.18 tagged_above=-999 required=5 tests=[AWL=-0.581, 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 1J3h2Un1FyFb for ; Fri, 22 Jul 2011 15:18:52 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id E133521F8B67 for ; Fri, 22 Jul 2011 15:18:51 -0700 (PDT) Received: by pzk6 with SMTP id 6so4034765pzk.26 for ; Fri, 22 Jul 2011 15:18:51 -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=lFCoyFADgVDFqzO1KuafhfqIvTP8ADk4ZFUCrgpEFrA=; b=SaGTcX9J100Kl1O5oFFdCLQXRYPXEgrVUqJy66sbKXv8oqdJt+ZZjxl+u8vyMPTiX3 QF24sWVz8T46Beww5ueoHGH8C+gnxd4Yi5/699Zmo3FsrJkM6aXn1GAmMGKWOWMlrhLA vlAQKW3HdhMEGMA6df0m2lPAUtErptCeeHwoE= Received: by 10.68.6.33 with SMTP id x1mr2867717pbx.268.1311373131444; Fri, 22 Jul 2011 15:18:51 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id k3sm861939pbj.93.2011.07.22.15.18.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 15:18:49 -0700 (PDT) Message-ID: <4E29F756.1030500@gmail.com> Date: Fri, 22 Jul 2011 15:19:02 -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: <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> In-Reply-To: <9567940E-FB6D-4541-AC38-DEDF335983EE@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] DSCP and media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jul 2011 22:18:52 -0000 Chair, I claimed yesterday that I wouldn't post here today, this date, unless there was something included to spend at-least one trillion worth of transient dollars. Found one. [...QoS...] On 07/20/2011 02:25 PM, Cullen Jennings wrote: > The other issue is that it is not clear what values you should set the DSCP to. If you read the appropriate RFCs, you will come to the conclusion that they are pretty confused on the topic. If you look at the values being used by Cisco, the mapping from 802.11, and Microsoft, you would notice they are not the same and there may be some uh "gaming the system" going on. One of the things this WG could do would be to come up with some clear guidance on what values to use for browsers and when to use them. > Silverlight/Moonlight crashes or hangs in Crome/book. This means the "browser based run-time tests" are unfair. I could finger if I was a judge, yet I am clearly not one. I can define "stupid" simply by [A-Z]+pyramidal-shape found, and I have already declared that elsewhere for good causes. If judges want to use graphene or the silver pen is their choice on the minutes, yet I seen why some question anti-truth/anti-trust when that choice is already tainted. I doubt anything like "auto-jury" is any game, yet still looks stupid like "Gaming the system." Tax the debt makes sense to me. Any clue? Or two? Filed: Friday. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From magnus.westerlund@ericsson.com Sat Jul 23 03:58: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 1B97E21F873F for ; Sat, 23 Jul 2011 03:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.025 X-Spam-Level: X-Spam-Status: No, score=-106.025 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 O10zeQ8ZZC1l for ; Sat, 23 Jul 2011 03:58:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D21D721F8733 for ; Sat, 23 Jul 2011 03:58:33 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f3-4e2aa959f9a9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 56.CA.20773.959AA2E4; Sat, 23 Jul 2011 12:58: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; Sat, 23 Jul 2011 12:58:32 +0200 Message-ID: <4E297522.5020500@ericsson.com> Date: Fri, 22 Jul 2011 15:03:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Colin Perkins References: <4E259484.20509@ericsson.com> <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com> <4E26B742.6050606@jitsi.org> <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <1CA6A176-B5F1-47F0-839D-D595CE023B57@csperkins.org> In-Reply-To: <1CA6A176-B5F1-47F0-839D-D595CE023B57@csperkins.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] To multiplex or not! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 10:58:35 -0000 Cullen, I mostly agree with Colin here. But looking at the advanced use case this might be considered, and a bit on the control hierachy around it I would say that this is either 2, 3 or 4 RTP Sessions. It is primarily about how you would write your application and what type of RTP conference mixer you have and what behavior it has. For an application that has over the top labeling of the streams and where the RTP mixer also can handle these streams appropriate it can be only two RTP sessions. One for audio and one for video using SSRC multiplexing to mux all the video streams. In case you have your 5 participants being composited together in the mixer and delivered as one stream, or some other behavior in the central node you likely need to have one RTP session for that behavior. The Active speaker and the presentation could simply be relayed as equal SSRC multiplexed streams in one RTP session. Thus giving us one audio and two video. In worst case from a session perspective, the application writer has decided that it is simplest to put map the stream semantics to the RTP sessions, thus creating one Video for conference participants, one for the presentation, and one for the active speaker(presenter) video. Thus resulting in four streams. There is two main things affecting the RTP session usage in an particular application. The need of the application itself, and the capabilities of any central node to perform the behavior desired by the application. Yes, I know that RTP Sessions appear a difficult concept. But, I would recommend that everyone remembers that: - An application can contain any number of RTP sessions. - An RTP session can carry multiple media streams of the same type - Multiple RTP sessions for the same media type can be used to separate streams of different usages/behavior/processing in the applications or any central node. Cheers Magnus On 2011-07-21 00:21, Colin Perkins wrote: > On 20 Jul 2011, at 15:11, Cullen Jennings wrote: >> Second scenario: same as first address wise but instead of a single >> audio stream they want to set up a single audio stream to a >> conference bridge plus 7 video streams for the video from the 5 >> people on the bridge plus a presentation stream and stream of video >> from active speaker. I don't really care much about the scenario >> other than there are 8 streams being set up. But this type of >> scenario is becoming very common for multi party video chat as it >> allows you to see perhaps small versions of everyone plus a large >> version of active speaker. >> >> My experience is the answer to the first scenario is not as quick >> as you would like and the answer to how long the second takes is >> about 8 times longer than the first one. You might do a bit better >> than that depending on how clever your implementation is but it >> still a lot longer. > > I may be misunderstanding, but why would this take 8 times as long to > set up? Wouldn't you implement it as one UDP flow for the RTP audio, > plus one UDP flow for the RTP video (with the 7 video streams > multiplexed by SSRC, since RTP has always allowed multiparty flows of > the same media type in a single RTP session)? This might take twice > as long to setup as a single audio flow in the worst case, but not > eight times as long. > -- 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 Sat Jul 23 03:58: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 9F64B21F8749 for ; Sat, 23 Jul 2011 03:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.017 X-Spam-Level: X-Spam-Status: No, score=-106.017 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 XRkq3ksDAlQp for ; Sat, 23 Jul 2011 03:58:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42421F8748 for ; Sat, 23 Jul 2011 03:58:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-a8-4e2aa95c216a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 24.A6.09774.C59AA2E4; Sat, 23 Jul 2011 12:58:36 +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; Sat, 23 Jul 2011 12:58:35 +0200 Message-ID: <4E29787F.4050908@ericsson.com> Date: Fri, 22 Jul 2011 15:17:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Lennox , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 10:58:38 -0000 On 2011-07-21 11:01, Stephan Wenger wrote: > Remove multiparty support, then. Terminology glitch on my side. So you argue for removing multi-party support the fact that RTCWEB have clear multi-party use cases in our use case document? Even you make arguments in your layered coding pitch using functions which is based on the multi-party functions of RTP. So I don't see how that match up. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Sat Jul 23 03:58: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 042F621F874F for ; Sat, 23 Jul 2011 03:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.009 X-Spam-Level: X-Spam-Status: No, score=-106.009 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 B+l-Zyj4Heb1 for ; Sat, 23 Jul 2011 03:58:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA721F86C0 for ; Sat, 23 Jul 2011 03:58:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ac-4e2aa95fec65 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D4.A6.09774.F59AA2E4; Sat, 23 Jul 2011 12:58:39 +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, 23 Jul 2011 12:58:38 +0200 Message-ID: <4E297A46.8030401@ericsson.com> Date: Fri, 22 Jul 2011 15:25:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Matthew Kaufman References: <4E259EAD.3060505@ericsson.com> <4E26C5CF.1080007@ericsson.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <4E275900.1@skype.net> In-Reply-To: <4E275900.1@skype.net> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 10:58:41 -0000 On 2011-07-21 00:38, Matthew Kaufman wrote: > On 7/20/2011 3:31 PM, Colin Perkins wrote: >> On 20 Jul 2011, at 22:15, Aron Rosenberg wrote: > > So let me get this straight... RTP and RTCP is broken and inflexible and > therefore we must use it, and use it in the broken and inflexible way? And Matthew we haven't argued against attempting to fix the big issue you see with it, namely that it requires a lower layer to separate RTP sessions. We just don't see it happing quickly or in the way you proposed. But I think we are going to very seriously consider attempting to do something about the short coming in AVTCORE. > > If anything this is an argument for ignoring RTP and RTCP and doing > something entirely new that is actually appropriate for what we're > trying to build, not living with crap just because there's an RFC for it. I don't think we have an realistic alternative of doing something new. I would love to develop a new real-time media transport protocol. I just think that it will take 3 years before we are close to having something published. I also fear that it might suffer from second system syndrome and be hellishly complex. I also don't think it helps the people that want to gateway to their legacy systems. Do you have any other well defined media transport alternative for us to use? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@cisco.com Sat Jul 23 05:33: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 0F12721F876F for ; Sat, 23 Jul 2011 05:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.178 X-Spam-Level: X-Spam-Status: No, score=-103.178 tagged_above=-999 required=5 tests=[AWL=-1.648, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 mkAoRVdYgF-g for ; Sat, 23 Jul 2011 05:33:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB7421F8760 for ; Sat, 23 Jul 2011 05:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3039; q=dns/txt; s=iport; t=1311424409; x=1312634009; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ptwBVV4+1qjT+TvCGaivW8Btl1zRFfQMQImNf3tSFiI=; b=MVwzzm0ZFW+DSDhEM8l/w/ncUPBMOjoLG8s2iozXPHxHoq+lZ5jug++z NRieFvbAWPL5bdn70UVBc5QvIzIvredS+74kEY7uMC7RZkNG3zWE9gPHV 4HcDgoBIvvfybRKVlUV/FNWBarzEw9sbPFvKwsys+/EpHV3WNkSskcMRZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUGAAe/Kk6rRDoI/2dsb2JhbAA1AQEBAQIBFAErRREMDgo6FAdKBwsMJxCnIneIfAShLJ11hWBfBIdVixuRAA X-IronPort-AV: E=Sophos;i="4.67,252,1309737600"; d="scan'208";a="5750429" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jul 2011 12:33:28 +0000 Received: from sjc-vpn4-935.cisco.com (sjc-vpn4-935.cisco.com [10.21.83.166]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6NCXJhW026065; Sat, 23 Jul 2011 12:33:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 22 Jul 2011 19:33:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 12:33:30 -0000 On Jul 20, 2011, at 8:37 , Justin Uberti wrote: >=20 >=20 > On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand = wrote: > On 07/20/11 03:13, Cullen Jennings wrote: > On Jul 18, 2011, at 15:11 , Randell Jesup wrote: >=20 > All that said - yes, there are complexity issues to consider, which = was why I was suggesting leveraging > an existing tunneled protocol like SCTP or even TCP-over-UDP. > I agree with bunch of what you are saying but the previous several = times I've seen the use SCTP over UDP conversation, it usually ends = about the point the we ask for a user land implementation. Whatever we = do more or less has to be user land or already exist in the OS that = people run browsers on. >=20 > If someone has a user land implementation of SCTP or TCP, I imagine = that might change the outcome a bit from previous times. I have not = looked at the TCP over UPD library Justin mentioned but, at casual = glance, I noticed is around 400 lines of code which is very small, which = is cool. But given the lines of code in say the BSD TCP stack, it does = make me wonder what's missing. That said, I don't think we need = something with the perforce of the BSD TCP stack as long as what is = there is TCP friendly and robust. > I believe this is the current URL: >=20 > = http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel= /pseudotcpchannel.cc (500 or so lines). >=20 > The real protocol implementation is here: > = http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseud= otcp.cc > which is another 1000 lines (not counting the various .h files). >=20 > We're not THAT good at writing compact code :-) >=20 > Yes, I was going to send a similar email. There are some = deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't = do path MTU discovery, no checksum, no OOB data - but it is based on TCP = and implements slow start and other congestion avoidance mechanisms, and = is actively used by a number of applications where reliable transfer is = important, such as file transfer and remote desktop applications. > =20 >=20 It would be really interesting to see someone write a draft that subsets = TCP to make it=20 1) still be congestion safe and TCP friendly=20 2) be valid TCP from point of view nats and firewalls 3) match an implementation like the one you have here.=20 Most our use cases do not need OOB data. A subset protocol that was = missing something like path MTU discovery might be slower than full = blown modern TCP but again, most out use cases would still work just = fine. As much as the IETF hates sub setting protocols, having something = concrete and in hand like this would be a pretty useful thing. As well = as being useful for the wwebrtc work, something like this would be = useful for very constrained systems such very cheap sensor networks. I'm = seeing lots of really minimal subset of TCP being done for these very = low end system.=20 From tim@phonefromhere.com Sat Jul 23 05:51: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 A529D21F899F for ; Sat, 23 Jul 2011 05:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVH7v1-bUG12 for ; Sat, 23 Jul 2011 05:51:00 -0700 (PDT) Received: from zimbra.f1f9.com (zimbra.f1f9.com [192.67.4.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7196121F899D for ; Sat, 23 Jul 2011 05:51:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.f1f9.com (Postfix) with ESMTP id 5D6CA4AC003; Sat, 23 Jul 2011 13:50:51 +0100 (BST) X-Virus-Scanned: amavisd-new at zimbra.f1f9.com Received: from zimbra.f1f9.com ([127.0.0.1]) by localhost (zimbra.f1f9.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wip6yNurWTB; Sat, 23 Jul 2011 13:50:30 +0100 (BST) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.f1f9.com (Postfix) with ESMTPSA id B942D4AC002; Sat, 23 Jul 2011 13:50:29 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_C392BC58-FEB5-4886-B7C5-CAF8005B11F8" From: Tim Panton In-Reply-To: <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> Date: Sat, 23 Jul 2011 13:50:29 +0100 Message-Id: <4A87F081-90D0-4BAC-97C0-B75686AFF758@phonefromhere.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 12:51:01 -0000 --Apple-Mail=_C392BC58-FEB5-4886-B7C5-CAF8005B11F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Jul 2011, at 03:33, Cullen Jennings wrote: >=20 > On Jul 20, 2011, at 8:37 , Justin Uberti wrote: >>=20 >> Yes, I was going to send a similar email. There are some = deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't = do path MTU discovery, no checksum, no OOB data - but it is based on TCP = and implements slow start and other congestion avoidance mechanisms, and = is actively used by a number of applications where reliable transfer is = important, such as file transfer and remote desktop applications. >>=20 >>=20 >=20 > It would be really interesting to see someone write a draft that = subsets TCP to make it=20 >=20 I just want to flag that TCP isn't an especially good fit here, = datagrams delivered in events are a very useful abstraction in JavaScript, which doesn't really do streams of data very = well.=20 I know we can do datagrams over TCP, but it seems wasteful to de-packetize in the TCP layer, just to try and = re-packetize it a couple of layers further up. If there is a reliable datagram protocol as opposed to a reliable = stream, I'd go for the datagram every time. Tim. --Apple-Mail=_C392BC58-FEB5-4886-B7C5-CAF8005B11F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 20, 2011, at 8:37 , Justin Uberti = wrote:

Yes, = I was going to send a similar email. There are some = deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't = do path MTU discovery, no checksum, no OOB data - but it is based on TCP = and implements slow start and other congestion avoidance mechanisms, and = is actively used by a number of applications where reliable transfer is = important, such as file transfer and remote desktop = applications.



It would be really interesting to see = someone write a draft that subsets TCP to make it =


I just want to flag that TCP = isn't an especially good fit here, datagrams delivered in events are a = very useful
abstraction in JavaScript, which doesn't really do = streams of data very well. 

I know we can = do datagrams over TCP,  but
it seems wasteful to = de-packetize in the TCP layer, just to try and re-packetize it a couple = of layers further up.

If there is a reliable = datagram protocol as opposed to a reliable stream, I'd go for the = datagram every = time.

Tim.

= --Apple-Mail=_C392BC58-FEB5-4886-B7C5-CAF8005B11F8-- From emil@sip-communicator.org Sat Jul 23 08:26: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 C6F4621F85AC for ; Sat, 23 Jul 2011 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 SxWWCGTcP21E for ; Sat, 23 Jul 2011 08:26:37 -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 C781921F8581 for ; Sat, 23 Jul 2011 08:26:36 -0700 (PDT) Received: by wyj26 with SMTP id 26so2322257wyj.31 for ; Sat, 23 Jul 2011 08:26:35 -0700 (PDT) Received: by 10.227.137.208 with SMTP id x16mr2337036wbt.81.1311434795865; Sat, 23 Jul 2011 08:26:35 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id fe4sm2788912wbb.28.2011.07.23.08.26.34 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jul 2011 08:26:34 -0700 (PDT) Message-ID: <4E2AE828.2060204@jitsi.org> Date: Sat, 23 Jul 2011 17:26:32 +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: Cullen Jennings References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> In-Reply-To: <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 15:26:37 -0000 =D0=9D=D0=B0 23.07.11 04:33, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > It would be really interesting to see someone write a draft that subset= s TCP to make it=20 >=20 > 1) still be congestion safe and TCP friendly=20 >=20 > 2) be valid TCP from point of view nats and firewalls Why does it need to be valid TCP? What NATs and firewalls will see is valid UDP which is the whole point, isn't it? The fact that the protocol carried in the datagrams is TCP-like only matters to the application. Emil -- http://jitsi.org From fd@w3.org Sat Jul 23 08:52: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 725BD21F898F for ; Sat, 23 Jul 2011 08:52:22 -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 GHPjB7PVsDit for ; Sat, 23 Jul 2011 08:52:22 -0700 (PDT) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by ietfa.amsl.com (Postfix) with ESMTP id E093121F86BC for ; Sat, 23 Jul 2011 08:52:21 -0700 (PDT) Received: from modemcable082.5-176-173.mc.videotron.ca ([173.176.5.82] helo=[192.168.10.197]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QkeUv-0003g0-7N for rtcweb@ietf.org; Sat, 23 Jul 2011 15:52:13 +0000 Message-ID: <4E2AEE2B.9000008@w3.org> Date: Sat, 23 Jul 2011 17:52:11 +0200 From: Francois Daoust User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 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 Subject: [rtcweb] Logistics info on W3C WebRTC meeting - Saturday 23 July X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 15:52:22 -0000 Hi, For those of you who were planning to attend the W3C Web Real-Time Communications Working Group meeting this afternoon, here are latest logistics info. Location: Quebec City Convention Center (same location as IETF meeting) Room: room 2103 (seems like finding the room is not trivial, allow for enough time!) Time: from 14:00 to 18:00 Agenda: http://www.w3.org/2011/04/webrtc/wiki/July_23_2011 IRC: #webrtc channel on irc.w3.org, port 6665 (a Web interface is available at: http://irc.w3.org ) Francois Daoust, W3C Staff Contact for the W3C Web RTC WG. From stewe@stewe.org Sat Jul 23 14:13: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 2A38F21F8C42 for ; Sat, 23 Jul 2011 14:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.586, 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 FmH2gytobzlv for ; Sat, 23 Jul 2011 14:13:12 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFE221F8C3E for ; Sat, 23 Jul 2011 14:13:08 -0700 (PDT) Received: from [192.168.1.104] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 16554-1743317 for multiple; Sat, 23 Jul 2011 23:13:07 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Sat, 23 Jul 2011 14:12:55 -0700 From: Stephan Wenger To: Magnus Westerlund Message-ID: Thread-Topic: [rtcweb] How to multiplex between peers In-Reply-To: <4E29787F.4050908@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 Cc: Jonathan Lennox , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Jul 2011 21:13:13 -0000 Hi Magnus, Not sure you got the context right here. The "removal of multiparty support" was related to my suggestion for a feature list of what I called RTPv3, which would need to co-exist with RTPv2 (that includes multiparty support). That said, if I'm not completely mistaken, you can implement the multiparty use cases using the "RTCP terminating MCU" topology of RFC 5117. This is common implementation practice in video conferencing. If you do so, the multiparty support of RTPv2 is neither exercised nor needed in a multiparty video conference. Stephan On 7.22.2011 06:17 , "Magnus Westerlund" wrote: >On 2011-07-21 11:01, Stephan Wenger wrote: > >> Remove multiparty support, then. Terminology glitch on my side. > >So you argue for removing multi-party support the fact that RTCWEB have >clear multi-party use cases in our use case document? Even you make >arguments in your layered coding pitch using functions which is based on >the multi-party functions of RTP. So I don't see how that match up. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From juberti@google.com Sun Jul 24 07:40: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 913D021F88B7 for ; Sun, 24 Jul 2011 07:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.809 X-Spam-Level: X-Spam-Status: No, score=-105.809 tagged_above=-999 required=5 tests=[AWL=0.167, 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 Y1G6j1XLL2FX for ; Sun, 24 Jul 2011 07:40:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7321F87ED for ; Sun, 24 Jul 2011 07:40:49 -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 p6OEemeG017980 for ; Sun, 24 Jul 2011 07:40:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311518448; bh=THr84GdjkQdMnhruI7rghFzXICI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IlWtbVIuRia3A0ZMbXHKg3wbV4VBGLCVbMMENfZWz1DmEuLXTxJiuG2f2BE8d5jdg m7j08Ey11agx7xxIBjlUg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=qauc91bkOqTLWvTcoqFuPqq30CqbUvBID3TVMHFfRXrKvJsopKLgDvC4tEN3ak3C5 NWFB/+257P7OFyiTSvfaw== Received: from iyf40 (iyf40.prod.google.com [10.241.50.104]) by wpaz1.hot.corp.google.com with ESMTP id p6OEekAe004229 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 24 Jul 2011 07:40:47 -0700 Received: by iyf40 with SMTP id 40so4399955iyf.12 for ; Sun, 24 Jul 2011 07:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kno58WhdelMVc1Xxla4CzLpE6yd5F3oetZ9H49QDR04=; b=u4h5zY+4CKwmyAgd4bUI6OhfZzkxuFo2OtVaydfdD2KwtUuGvGhNOU68JshydxXyNQ 6lNHYttOebcHrTaUkZqA== Received: by 10.231.53.208 with SMTP id n16mr1368464ibg.13.1311518446491; Sun, 24 Jul 2011 07:40:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.197 with HTTP; Sun, 24 Jul 2011 07:40:25 -0700 (PDT) In-Reply-To: <4A87F081-90D0-4BAC-97C0-B75686AFF758@phonefromhere.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> <4A87F081-90D0-4BAC-97C0-B75686AFF758@phonefromhere.com> From: Justin Uberti Date: Sun, 24 Jul 2011 07:40:25 -0700 Message-ID: To: Tim Panton Content-Type: multipart/alternative; boundary=0022150485071e97f604a8d1af32 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Jul 2011 14:40:50 -0000 --0022150485071e97f604a8d1af32 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 23, 2011 at 5:50 AM, Tim Panton wrote: > > On 23 Jul 2011, at 03:33, Cullen Jennings wrote: > > > On Jul 20, 2011, at 8:37 , Justin Uberti wrote: > > > Yes, I was going to send a similar email. There are some > deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do > path MTU discovery, no checksum, no OOB data - but it is based on TCP and > implements slow start and other congestion avoidance mechanisms, and is > actively used by a number of applications where reliable transfer is > important, such as file transfer and remote desktop applications. > > > > > It would be really interesting to see someone write a draft that subsets > TCP to make it > > > I just want to flag that TCP isn't an especially good fit here, datagrams > delivered in events are a very useful > abstraction in JavaScript, which doesn't really do streams of data very > well. > > I know we can do datagrams over TCP, but > it seems wasteful to de-packetize in the TCP layer, just to try and > re-packetize it a couple of layers further up. > > If there is a reliable datagram protocol as opposed to a reliable stream, > I'd go for the datagram every time. > Yes, the API here will be datagram-oriented, just like WebSockets. Ideally, the API for this would match WebSockets exactly, so that code in higher layers can be agnostic about exactly how the data is being sent. Even as a "datagram" service, I think TCP is still the best fit. The fact that it is well-understood and has countless working implementations is far more significant than any cost of framing (which will likely be trivial). > > Tim. > > --0022150485071e97f604a8d1af32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Jul 23, 2011 at 5:50 AM, Tim Pan= ton <tim@phon= efromhere.com> wrote:

On 23 J= ul 2011, at 03:33, Cullen Jennings wrote:


On Jul 20, 2011, at 8:37 , Justin Uber= ti wrote:

<= /div>
Yes, I was going to send a= similar email. There are some deficiencies/optimizations for the fact it r= uns over ICE-UDP - doesn't do path MTU discovery, no checksum, no OOB d= ata - but it is based on TCP and implements slow start and other congestion= avoidance mechanisms, and is actively used by a number of applications whe= re reliable transfer is important, such as file transfer and remote desktop= applications.



It would be really interesting to see someone w= rite a draft that subsets TCP to make it


I just want to flag that TCP isn't an especially good fit he= re, datagrams delivered in events are a very useful
abstraction i= n JavaScript, which doesn't really do streams of data very well.=C2=A0<= /div>

I know we can do datagrams over TCP, =C2=A0but
it seems wasteful to de-packetize in the TCP layer, just to try and re-pa= cketize it a couple of layers further up.

If there= is a reliable datagram protocol as opposed to a reliable stream, I'd g= o for the datagram every time.

Yes, the API here will be datagram-o= riented, just like WebSockets. Ideally, the API for this would match WebSoc= kets exactly, so that code in higher layers can be agnostic about exactly h= ow the data is being sent.

Even as a "datagram" service, I think TCP is = still the best fit. The fact that it is well-understood and has countless w= orking implementations is far more significant than any cost of framing (wh= ich will likely be trivial).
Tim.


--0022150485071e97f604a8d1af32-- From fluffy@cisco.com Sun Jul 24 07:49: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 5789421F8745 for ; Sun, 24 Jul 2011 07:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.668 X-Spam-Level: X-Spam-Status: No, score=-103.668 tagged_above=-999 required=5 tests=[AWL=-1.069, 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 CAcYBABw96hC for ; Sun, 24 Jul 2011 07:49:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7BD21F84F0 for ; Sun, 24 Jul 2011 07:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1547; q=dns/txt; s=iport; t=1311518945; x=1312728545; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OCTZRZKBvzVHbStngKyOaYbxgj9m47lxPV9awq5utjE=; b=WI7yfGJU7e+t9rXfLdkH4nC7zMWhOgsoHmF9EuCFVxMNaHHPT09xn2bt V7dHEixX4tinXbHgk5VQHbWA6zakqi+upol7AxdXTod3qwVjT0ovZFqty OqPh6arLRBZLdJJPRAVCA8I7HWV4GjDrmjtMwPiGjvJiHuew+qBd6dqTK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALswLE6rRDoG/2dsb2JhbAA1AQEBAQIBFAEUShIRCgIODAIyAgIUUQc+hC+ifXeIfASdb40jkAOBK4QFMF8EknCFB4t1 X-IronPort-AV: E=Sophos;i="4.67,256,1309737600"; d="scan'208";a="5902554" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jul 2011 14:49:03 +0000 Received: from [10.21.119.151] ([10.21.119.151]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6OEn2f5010182; Sun, 24 Jul 2011 14:49:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Cullen Jennings In-Reply-To: <4E2AE828.2060204@jitsi.org> Date: Sun, 24 Jul 2011 10:49:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> <4E2AE828.2060204@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Jul 2011 14:49:06 -0000 agree on the high level API you want something datagram oriented... I = was just thinking about the congestion control / reliability approach of = TCP and fine if a reliable , in order, datagram is put on top of that.=20= inline ... On Jul 23, 2011, at 11:26 , Emil Ivov wrote: > =D0=9D=D0=B0 23.07.11 04:33, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >> It would be really interesting to see someone write a draft that = subsets TCP to make it=20 >>=20 >> 1) still be congestion safe and TCP friendly=20 >>=20 >> 2) be valid TCP from point of view nats and firewalls >=20 > Why does it need to be valid TCP? What NATs and firewalls will see is > valid UDP which is the whole point, isn't it? I should not have put nats you are right - I'm so used to typing nats = and fws :-) On the firewalls that do protocol inspection, they may very = well want to be able to parse this layer and even the things inside it. = I suspect that code that is there is already valid TCP from the point of = view of firewalls so I doubt this requirement really changes anything = one way or the other.=20 >=20 > The fact that the protocol carried in the datagrams is TCP-like only > matters to the application. Sort of, lots of firewalls are configured not to allow UDP packets to = pass unless they understand what is in them. >=20 > Emil >=20 > -- > http://jitsi.org >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From juberti@google.com Sun Jul 24 08:03: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 5991A21F874B for ; Sun, 24 Jul 2011 08:03:36 -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 13ESMXb2nbbY for ; Sun, 24 Jul 2011 08:03:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 485A221F86F6 for ; Sun, 24 Jul 2011 08:03:34 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p6OF3Xip015663 for ; Sun, 24 Jul 2011 08:03:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311519814; bh=RPDQzo3cFEFOC1OT/2+9a46uFGU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=MvhlR709Bz7+NeBnYzqknYzoFwBhOTLAO759qibW1qFTsTtVosGQ5D6J5bp1kEmFr dUggOWGyh2/PEXaaYFbvg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=GSJ9tWjyUvT7O/Yceywk5S+BYsatVczcBaXnSEElVcvff/sHH3kwI2E0yBhb7In+n +Q+iVb+BT5e00AzxfjusA== Received: from iyh42 (iyh42.prod.google.com [10.241.50.234]) by wpaz29.hot.corp.google.com with ESMTP id p6OF3Wtw013847 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 24 Jul 2011 08:03:33 -0700 Received: by iyh42 with SMTP id 42so5155951iyh.25 for ; Sun, 24 Jul 2011 08:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nL4zkH/oyUnBX5oWs/wYTRyHWQux7RvtMZep5L1O1is=; b=mHU5Ee3DOC0p3ubQvlNDtGDgIOeFk80j0LKGBP8awp8bjKZT3EMjC7jeIy9u2EAd+t l+ihkeayzlIPwjujNzQw== Received: by 10.231.64.67 with SMTP id d3mr3641260ibi.113.1311519812419; Sun, 24 Jul 2011 08:03:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.197 with HTTP; Sun, 24 Jul 2011 08:03:12 -0700 (PDT) In-Reply-To: <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> From: Justin Uberti Date: Sun, 24 Jul 2011 08:03:12 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=000e0cd4b4228901e704a8d200d9 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Jul 2011 15:03:36 -0000 --000e0cd4b4228901e704a8d200d9 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 22, 2011 at 7:33 PM, Cullen Jennings wrote: > > On Jul 20, 2011, at 8:37 , Justin Uberti wrote: > > > > > > > On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand > wrote: > > On 07/20/11 03:13, Cullen Jennings wrote: > > On Jul 18, 2011, at 15:11 , Randell Jesup wrote: > > > > All that said - yes, there are complexity issues to consider, which was > why I was suggesting leveraging > > an existing tunneled protocol like SCTP or even TCP-over-UDP. > > I agree with bunch of what you are saying but the previous several times > I've seen the use SCTP over UDP conversation, it usually ends about the > point the we ask for a user land implementation. Whatever we do more or less > has to be user land or already exist in the OS that people run browsers on. > > > > If someone has a user land implementation of SCTP or TCP, I imagine that > might change the outcome a bit from previous times. I have not looked at the > TCP over UPD library Justin mentioned but, at casual glance, I noticed is > around 400 lines of code which is very small, which is cool. But given the > lines of code in say the BSD TCP stack, it does make me wonder what's > missing. That said, I don't think we need something with the perforce of the > BSD TCP stack as long as what is there is TCP friendly and robust. > > I believe this is the current URL: > > > > > http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc(500 or so lines). > > > > The real protocol implementation is here: > > > http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.cc > > which is another 1000 lines (not counting the various .h files). > > > > We're not THAT good at writing compact code :-) > > > > Yes, I was going to send a similar email. There are some > deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do > path MTU discovery, no checksum, no OOB data - but it is based on TCP and > implements slow start and other congestion avoidance mechanisms, and is > actively used by a number of applications where reliable transfer is > important, such as file transfer and remote desktop applications. > > > > > > It would be really interesting to see someone write a draft that subsets > TCP to make it > > 1) still be congestion safe and TCP friendly > > 2) be valid TCP from point of view nats and firewalls > > 3) match an implementation like the one you have here. > > Most our use cases do not need OOB data. A subset protocol that was missing > something like path MTU discovery might be slower than full blown modern TCP > but again, most out use cases would still work just fine. As much as the > IETF hates sub setting protocols, having something concrete and in hand like > this would be a pretty useful thing. As well as being useful for the wwebrtc > work, something like this would be useful for very constrained systems such > very cheap sensor networks. I'm seeing lots of really minimal subset of TCP > being done for these very low end system. > Interesting. From the webrtc context, the requirements are a little different - e.g. when we're running as TCP/UDP, we don't need the port or checksum, as those are handled by the UDP layer. So the goal would become two specs: (1) minimal subset of TCP (2) adaptation of #1 to run over UDP instead of IP Who can speak to what requirements/RFCs should constitute #1? We could certainly make a proposal based on what we've implemented, but if it's going to be used more broadly, I'm guessing a LOT of folks will care about these details. For #2, in addition to the work we've done with what we call PseudoTcp, I've noticed these two other drafts on TCP/UDP, which are very similar to PseudoTcp. The first gives a very good treatment (in Section 8) of why a PseudoTcp-like approach is the best way for reliable p2p data transfer. http://tools.ietf.org/html/draft-baset-tsvwg-tcp-over-udp-01 http://tools.ietf.org/html/ draft-denis-udp-transport-00 --000e0cd4b4228901e704a8d200d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 22, 2011 at 7:33 PM, Cullen = Jennings <fluffy@c= isco.com> wrote:

On Jul 20, 2011, at 8:37 , Justin Uberti wrote:

>
>
> On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 07/20/11 03:13, Cullen Jennings wrote:
> On Jul 18, 2011, at 15:11 , Randell Jesup wrote:
>
> All that said - yes, there are complexity issues to consider, which wa= s why I was suggesting leveraging
> an existing tunneled protocol like SCTP or even TCP-over-UDP.
> I agree with bunch of what you are saying but the previous several tim= es I've seen the use SCTP over UDP conversation, it usually ends about = the point the we ask for a user land implementation. Whatever we do more or= less has to be user land or already exist in the OS that people run browse= rs on.
>
> If someone has a user land implementation of SCTP or TCP, I imagine th= at might change the outcome a bit from previous times. I have not looked at= the TCP over UPD library Justin mentioned but, at casual glance, I noticed= is around 400 lines of code which is very small, which is cool. But given = the lines of code in say the BSD TCP stack, it does make me wonder what'= ;s missing. That said, I don't think we need something with the perforc= e of the BSD TCP stack as long as what is there is TCP friendly and robust.=
> I believe this is the current URL:
>
> http://code.google.c= om/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc<= /a> (500 or so lines).
>
> The real protocol implementation is here:
> http://code.google.com/p/libjingl= e/source/browse/trunk/talk/p2p/base/pseudotcp.cc
> which is another 1000 lines (not counting the various .h files).
>
> We're not THAT good at writing compact code :-)
>
> Yes, I was going to send a similar email. There are some deficiencies/= optimizations for the fact it runs over ICE-UDP - doesn't do path MTU d= iscovery, no checksum, no OOB data - but it is based on TCP and implements = slow start and other congestion avoidance mechanisms, and is actively used = by a number of applications where reliable transfer is important, such as f= ile transfer and remote desktop applications.
>
>

It would be really interesting to see someone write a draft that subs= ets TCP to make it

1) still be congestion safe and TCP friendly

2) be valid TCP from point of view nats and firewalls

3) match an implementation like the one you have here.

Most our use cases do not need OOB data. A subset protocol that was missing= something like path MTU discovery might be slower than full blown modern T= CP but again, most out use cases would still work just fine. As much as the= IETF hates sub setting protocols, having something concrete and in hand li= ke this would be a pretty useful thing. As well as being useful for the wwe= brtc work, something like this would be useful for very constrained systems= such very cheap sensor networks. I'm seeing lots of really minimal sub= set of TCP being done for these very low end system.

Interesting. From the webrtc context, the = requirements are a little different - e.g. when we're running as TCP/UD= P, we don't need the port or checksum, as those are handled by the UDP = layer.=C2=A0

So the goal would become two specs:
(1) minim= al subset of TCP
(2) adaptation of #1 to run over UDP instead of = IP

Who can speak to what requirements/RFCs should = constitute #1? We could certainly make a proposal based on what we've i= mplemented, but if it's going to be used more broadly, I'm guessing= a LOT of folks will care about these details.

For #2, in addition to the work we've done with wha= t we call PseudoTcp, I've noticed these two other drafts on TCP/UDP, wh= ich are very similar to PseudoTcp. The first gives a very good treatment (i= n Section 8) of why a PseudoTcp-like approach is the best way for reliable = p2p data transfer.
--000e0cd4b4228901e704a8d200d9-- From harald@alvestrand.no Sun Jul 24 08:21: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 3EB5521F8A64 for ; Sun, 24 Jul 2011 08:21:01 -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 3zfcKh+D3dd4 for ; Sun, 24 Jul 2011 08:21:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 457B021F8A62 for ; Sun, 24 Jul 2011 08:21:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59BB539E119; Sun, 24 Jul 2011 17: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 0mpHkFU1-4Ja; Sun, 24 Jul 2011 17:19:51 +0200 (CEST) Received: from [130.129.22.244] (unknown [130.129.22.244]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 88BEB39E03C; Sun, 24 Jul 2011 17:19:50 +0200 (CEST) Message-ID: <4E2C3859.3090102@alvestrand.no> Date: Sun, 24 Jul 2011 11:20:57 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> In-Reply-To: <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Jul 2011 15:21:01 -0000 On 07/22/11 22:33, Cullen Jennings wrote: > On Jul 20, 2011, at 8:37 , Justin Uberti wrote: > >> >> On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand wrote: >> On 07/20/11 03:13, Cullen Jennings wrote: >> On Jul 18, 2011, at 15:11 , Randell Jesup wrote: >> >> All that said - yes, there are complexity issues to consider, which was why I was suggesting leveraging >> an existing tunneled protocol like SCTP or even TCP-over-UDP. >> I agree with bunch of what you are saying but the previous several times I've seen the use SCTP over UDP conversation, it usually ends about the point the we ask for a user land implementation. Whatever we do more or less has to be user land or already exist in the OS that people run browsers on. >> >> If someone has a user land implementation of SCTP or TCP, I imagine that might change the outcome a bit from previous times. I have not looked at the TCP over UPD library Justin mentioned but, at casual glance, I noticed is around 400 lines of code which is very small, which is cool. But given the lines of code in say the BSD TCP stack, it does make me wonder what's missing. That said, I don't think we need something with the perforce of the BSD TCP stack as long as what is there is TCP friendly and robust. >> I believe this is the current URL: >> >> http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc (500 or so lines). >> >> The real protocol implementation is here: >> http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.cc >> which is another 1000 lines (not counting the various .h files). >> >> We're not THAT good at writing compact code :-) >> >> Yes, I was going to send a similar email. There are some deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do path MTU discovery, no checksum, no OOB data - but it is based on TCP and implements slow start and other congestion avoidance mechanisms, and is actively used by a number of applications where reliable transfer is important, such as file transfer and remote desktop applications. >> >> > It would be really interesting to see someone write a draft that subsets TCP to make it > > 1) still be congestion safe and TCP friendly > > 2) be valid TCP from point of view nats and firewalls > > 3) match an implementation like the one you have here. > > Most our use cases do not need OOB data. A subset protocol that was missing something like path MTU discovery might be slower than full blown modern TCP but again, most out use cases would still work just fine. As much as the IETF hates sub setting protocols, having something concrete and in hand like this would be a pretty useful thing. As well as being useful for the wwebrtc work, something like this would be useful for very constrained systems such very cheap sensor networks. I'm seeing lots of really minimal subset of TCP being done for these very low end system. ObNitpick: TCP doesn't have OOB data. What it has is an "urgent data downstream" pointer, which the Unix implementors used to pick the byte pointed to out of the data stream and deliver it "urgently" as if it was OOB data. I exchanged mail with Jon Postel about this in 1984, and he confirmed that if a TCP protocol stack gets 2 TCP segments with different URG pointers, a TCP implementation can merge them and only deliver the latest URG pointer - which means that delivery of the OOB data is unreliable if you have more than 1 in flight at any one time; you might get the byte inband, and you might get it out of band. This conflict of viewpoints between the protocol design and the API design has, I believe, rendered the TCP URG pointer useless for all practical purposes. Returning to more relevant stuff: I think we need to handle PMTU issues somehow. This may be hard. Harald From juberti@google.com Sun Jul 24 08:27: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 6763321F88B6 for ; Sun, 24 Jul 2011 08:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.837 X-Spam-Level: X-Spam-Status: No, score=-105.837 tagged_above=-999 required=5 tests=[AWL=0.139, 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 PTlZ-UFwYCuB for ; Sun, 24 Jul 2011 08:27:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 30E7021F84ED for ; Sun, 24 Jul 2011 08:27:32 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p6OFRUJb004760 for ; Sun, 24 Jul 2011 08:27:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311521251; bh=3deVWOYCBVuv7GhX6sps3hmggX8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=V8xBNAckzrF6sQWX1sAYOPNWedZ185yGeXS5f+4Ka6JSP5fCtQ/SHZdjBndkLGmEe QquW49YmHrqLtE0jdIDwQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=t9ICgoSzmevPPR2dH/9a5gJApK/bWM+0i2D2Xfv9uUnAc3pLpdrVIrfUJwnMGAoaR aRLrJ2olVCy5cNNCDIekw== Received: from iym1 (iym1.prod.google.com [10.241.52.1]) by wpaz29.hot.corp.google.com with ESMTP id p6OFRTR1027916 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 24 Jul 2011 08:27:29 -0700 Received: by iym1 with SMTP id 1so4088637iym.29 for ; Sun, 24 Jul 2011 08:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UOwjWQODR+aeJAmkpBkHOLmGVaOjflztA5D1AEXFFgU=; b=ysd44EppYnmjbzKFmsfzc4UcHMLpAALgob0jdjazr94ocBdBVIh/NMmTpbzH9J9t22 E6XNSiWtEMhuRB5LD7UQ== Received: by 10.231.211.199 with SMTP id gp7mr3554667ibb.188.1311521249124; Sun, 24 Jul 2011 08:27:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.197 with HTTP; Sun, 24 Jul 2011 08:27:09 -0700 (PDT) In-Reply-To: <4E2C3859.3090102@alvestrand.no> References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <4E26D4D6.3020602@alvestrand.no> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com> <4E2C3859.3090102@alvestrand.no> From: Justin Uberti Date: Sun, 24 Jul 2011 08:27:09 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=0016369c8dda2b629a04a8d25699 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PseudoTCP implementation (Re: realiable data service) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Jul 2011 15:27:33 -0000 --0016369c8dda2b629a04a8d25699 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 24, 2011 at 8:20 AM, Harald Alvestrand wrote: > On 07/22/11 22:33, Cullen Jennings wrote: > >> On Jul 20, 2011, at 8:37 , Justin Uberti wrote: >> >> >>> On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand>> no > wrote: >>> On 07/20/11 03:13, Cullen Jennings wrote: >>> On Jul 18, 2011, at 15:11 , Randell Jesup wrote: >>> >>> All that said - yes, there are complexity issues to consider, which was >>> why I was suggesting leveraging >>> an existing tunneled protocol like SCTP or even TCP-over-UDP. >>> I agree with bunch of what you are saying but the previous several times >>> I've seen the use SCTP over UDP conversation, it usually ends about the >>> point the we ask for a user land implementation. Whatever we do more or less >>> has to be user land or already exist in the OS that people run browsers on. >>> >>> If someone has a user land implementation of SCTP or TCP, I imagine that >>> might change the outcome a bit from previous times. I have not looked at the >>> TCP over UPD library Justin mentioned but, at casual glance, I noticed is >>> around 400 lines of code which is very small, which is cool. But given the >>> lines of code in say the BSD TCP stack, it does make me wonder what's >>> missing. That said, I don't think we need something with the perforce of the >>> BSD TCP stack as long as what is there is TCP friendly and robust. >>> I believe this is the current URL: >>> >>> http://code.google.com/p/**libjingle/source/browse/trunk/** >>> talk/session/tunnel/**pseudotcpchannel.cc(500 or so lines). >>> >>> The real protocol implementation is here: >>> http://code.google.com/p/**libjingle/source/browse/trunk/** >>> talk/p2p/base/pseudotcp.cc >>> which is another 1000 lines (not counting the various .h files). >>> >>> We're not THAT good at writing compact code :-) >>> >>> Yes, I was going to send a similar email. There are some >>> deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do >>> path MTU discovery, no checksum, no OOB data - but it is based on TCP and >>> implements slow start and other congestion avoidance mechanisms, and is >>> actively used by a number of applications where reliable transfer is >>> important, such as file transfer and remote desktop applications. >>> >>> >>> It would be really interesting to see someone write a draft that subsets >> TCP to make it >> >> 1) still be congestion safe and TCP friendly >> >> 2) be valid TCP from point of view nats and firewalls >> >> 3) match an implementation like the one you have here. >> >> Most our use cases do not need OOB data. A subset protocol that was >> missing something like path MTU discovery might be slower than full blown >> modern TCP but again, most out use cases would still work just fine. As much >> as the IETF hates sub setting protocols, having something concrete and in >> hand like this would be a pretty useful thing. As well as being useful for >> the wwebrtc work, something like this would be useful for very constrained >> systems such very cheap sensor networks. I'm seeing lots of really minimal >> subset of TCP being done for these very low end system. >> > ObNitpick: TCP doesn't have OOB data. > > What it has is an "urgent data downstream" pointer, which the Unix > implementors used to pick the byte pointed to out of the data stream and > deliver it "urgently" as if it was OOB data. > I exchanged mail with Jon Postel about this in 1984, and he confirmed that > if a TCP protocol stack gets 2 TCP segments with different URG pointers, a > TCP implementation can merge them and only deliver the latest URG pointer - > which means that delivery of the OOB data is unreliable if you have more > than 1 in flight at any one time; you might get the byte inband, and you > might get it out of band. > > This conflict of viewpoints between the protocol design and the API design > has, I believe, rendered the TCP URG pointer useless for all practical > purposes. > > Returning to more relevant stuff: I think we need to handle PMTU issues > somehow. This may be hard. > The easy way may be to do what we're likely to do for RTP data: assume a MTU of 1280 (IPv6 minimum MTU) and packetize as such, leaving PMTU discovery as a future optimization. > > Harald > > > --0016369c8dda2b629a04a8d25699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 24, 2011 at 8:20 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
On 07/22/11 22:33, Cullen Jennings wrote:=
On Jul 20, 2011, at 8:37 , Justin Uberti wrote:


On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand<harald@alvestrand.no> = =C2=A0wrote:
On 07/20/11 03:13, Cullen Jennings wrote:
On Jul 18, 2011, at 15:11 , Randell Jesup wrote:

All that said - yes, there are complexity issues to consider, which was why= I was suggesting leveraging
an existing tunneled protocol like SCTP or even TCP-over-UDP.
I agree with bunch of what you are saying but the previous several times I&= #39;ve seen the use SCTP over UDP conversation, it usually ends about the p= oint the we ask for a user land implementation. Whatever we do more or less= has to be user land or already exist in the OS that people run browsers on= .

If someone has a user land implementation of SCTP or TCP, I imagine that mi= ght change the outcome a bit from previous times. I have not looked at the = TCP over UPD library Justin mentioned but, at casual glance, I noticed is a= round 400 lines of code which is very small, which is cool. But given the l= ines of code in say the BSD TCP stack, it does make me wonder what's mi= ssing. That said, I don't think we need something with the perforce of = the BSD TCP stack as long as what is there is TCP friendly and robust.
I believe this is the current URL:

http://code.google.com/p/= libjingle/source/browse/trunk/talk/session/tunnel/pseu= dotcpchannel.cc (500 or so lines).

The real protocol implementation is here:
http://code.google.com/p/libjin= gle/source/browse/trunk/talk/p2p/base/pseudotcp.cc
which is another 1000 lines (not counting the various .h files).

We're not THAT good at writing compact code :-)

Yes, I was going to send a similar email. There are some deficiencies/optim= izations for the fact it runs over ICE-UDP - doesn't do path MTU discov= ery, no checksum, no OOB data - but it is based on TCP and implements slow = start and other congestion avoidance mechanisms, and is actively used by a = number of applications where reliable transfer is important, such as file t= ransfer and remote desktop applications.


It would be really interesting to see someone write a draft that subsets TC= P to make it

1) still be congestion safe and TCP friendly

2) be valid TCP from point of view nats and firewalls

3) match an implementation like the one you have here.

Most our use cases do not need OOB data. A subset protocol that was missing= something like path MTU discovery might be slower than full blown modern T= CP but again, most out use cases would still work just fine. As much as the= IETF hates sub setting protocols, having something concrete and in hand li= ke this would be a pretty useful thing. As well as being useful for the wwe= brtc work, something like this would be useful for very constrained systems= such very cheap sensor networks. I'm seeing lots of really minimal sub= set of TCP being done for these very low end system.
ObNitpick: TCP doesn't have OOB data.

What it has is an "urgent data downstream" pointer, which the Uni= x implementors used to pick the byte pointed to out of the data stream and = deliver it "urgently" as if it was OOB data.
I exchanged mail with Jon Postel about this in 1984, and he confirmed that = if a TCP protocol stack gets 2 TCP segments with different URG pointers, a = TCP implementation can merge them and only deliver the latest URG pointer -= which means that delivery of the OOB data is unreliable if you have more t= han 1 in flight at any one time; you might get the byte inband, and you mig= ht get it out of band.

This conflict of viewpoints between the protocol design and the API design = has, I believe, rendered the TCP URG pointer useless for all practical purp= oses.

Returning to more relevant stuff: I think we need to handle PMTU issues som= ehow. This may be hard.

The easy way ma= y be to do what we're likely to do for RTP data: assume a MTU of 1280 (= IPv6 minimum MTU) and packetize as such, leaving PMTU discovery as a future= optimization.
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Harald



--0016369c8dda2b629a04a8d25699-- From matthew.kaufman@skype.net Sun Jul 24 13:45: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 5AB1D21F8745 for ; Sun, 24 Jul 2011 13:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BqCOItWewJwI for ; Sun, 24 Jul 2011 13:45:28 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6A12021F873F for ; Sun, 24 Jul 2011 13:45:27 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 9DC1716F7 for ; Sun, 24 Jul 2011 22:45:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; s=mx; bh=zj 4olQXZpvO2Gosimz9FNfsQmaM=; b=cDI0vCENXLWBWJUv15zVa0CuTFAvHd+Hn/ SnuHHzk858HTZeqLDRWAnSrI7g1VZpBwrfol6NkWPXStO8lMTOlPNmE7/Y45n0NF lQxDDCsU2to93TOldMYm6+x9AcFXdpqENzL+PGayosCT9vkI/dSaKUXvFVaG3ycx gWeoPXZAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; q=dns; s=mx ; b=ex+8KL6tm7iKVDkvXhYl5Sd1dkCPrpfkvnNxbN2eTIPec3gNSS84/FYaNz0o R/ziY0Me8wOakRsVdRPCb+2qIY9uyBTBOoGhgOlEyvzCir5fR1n8WBrApLbMLuj+ Dj+b/YSMs15IBcMypMr5ieY++hexMvZSnHnQc25jISyeulM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 9C5D97F6 for ; Sun, 24 Jul 2011 22:45:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 54C3735088E5 for ; Sun, 24 Jul 2011 22:45: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 Qo-RB05Dauph for ; Sun, 24 Jul 2011 22:44:57 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (unknown [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id 12A7F35088F9 for ; Sun, 24 Jul 2011 22:44:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Matthew Kaufman In-Reply-To: <4E123C54.10405@jdrosen.net> Date: Sun, 24 Jul 2011 16:44:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> References: <4E123C54.10405@jdrosen.net> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 24 Jul 2011 20:45:29 -0000 I've been looking for technical reasons and/or hard requirements that = would argue against doing RTP multiplexing as proposed in this draft. So far my conclusion is that the RTP specifications recommend against = this, but do not prohibit it. Supporting evidence: RFC 3550 Section 2.2 notes that multiplexing A&V together may be a = problem if you want to receive one and not together (presumably in the = multicast case) and refers to Section 5.2 for more support. RFC 3550 Section 5.2 says "Separate audio and video streams SHOULD NOT = be carried in a single RTP session and demultiplexed based on the = payload type or SSRC fields." and provides five reasons. Note the = "SHOULD NOT" as opposed to "MUST NOT". The same section says that the five reasons apply to multiplexing on = payload type, only the last two apply to multiplexing on SSRC. These = remaining reasons are: 4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. Not relevant to the RTCWEB peer-to-peer case as the browser is not an = RTP mixer. Also not relevant to any RTCWEB use cases that I can = identify. And, if an RTP mixer at one end it can simply not agree to use = multiplexing. 5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; Appears to not be relevant to the RTCWEB case where a unicast path will = be negotiated using ICE. reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; Appears to not be relevant to anything but the multicast cases. Any = unicast case, including RTCWEB, can simply not have that component of = the stream sent to it. and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. Appears to not be relevant to the RTCWEB use case. Additionally, if it = is necessary for there to be separate processes or even devices at the = far end this can be solved by again simply not agreeing to use = multiplexing. In all my reading today I have not been able to find anything more = concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow = up if you are aware of any other relevant specifications that would = argue against using SSRC to multiplex audio and video streams over a = single RTP session between a pair of compatible endpoints that agree to = do so. Matthew Kaufman =20= From randell1@jesup.org Sun Jul 24 17:16: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 75F1B21F84F8 for ; Sun, 24 Jul 2011 17:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 SNJklUN6rT03 for ; Sun, 24 Jul 2011 17:16:09 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id D19C921F84E2 for ; Sun, 24 Jul 2011 17:16:09 -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 1Ql8q9-00008q-32 for rtcweb@ietf.org; Sun, 24 Jul 2011 19:16:09 -0500 Message-ID: <4E2CB584.2030405@jesup.org> Date: Sun, 24 Jul 2011 20:15:00 -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: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> In-Reply-To: <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.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] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 00:16:10 -0000 On 7/24/2011 4:44 PM, Matthew Kaufman wrote: > RFC 3550 Section 5.2 says "Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields." and provides five reasons. Note the "SHOULD NOT" as opposed to "MUST NOT". > > The same section says that the five reasons apply to multiplexing on payload type, only the last two apply to multiplexing on SSRC. These remaining reasons are: > > 4. An RTP mixer would not be able to combine interleaved streams of > incompatible media into one stream. > > Not relevant to the RTCWEB peer-to-peer case as the browser is not an RTP mixer. Also not relevant to any RTCWEB use cases that I can identify. And, if an RTP mixer at one end it can simply not agree to use multiplexing. Well, there's no reason a browser using rtcweb couldn't be acting as a mixer for sessions with multiple other rtcweb clients/browsers. However, a) it could disable multiplexing (if we provide a control for that), and b) I'm not sure that I agree with the reasoning in 4) above. Perhaps someone could explain why that would be a problem (not having played with mixers much, I can't think of a reason off the top of my head). > 5. Carrying multiple media in one RTP session precludes: the use of > different network paths or network resource allocations if > appropriate; > > Appears to not be relevant to the RTCWEB case where a unicast path will be negotiated using ICE. Well, 5) is relevant, though you can decide you don't care. For example the concern raised about network-applied QOS to different streams from/to a client. The different network paths isn't important here. > reception of a subset of the media if desired, for > example just audio if video would exceed the available bandwidth; > > Appears to not be relevant to anything but the multicast cases. Any unicast case, including RTCWEB, can simply not have that component of the stream sent to it. Right, and no bandwidth will be saved unless you stop them from sending the stream. Given offer/answer/etc this issue is moot. > and receiver implementations that use separate processes for the > different media, whereas using separate RTP sessions permits > either single- or multiple-process implementations. > > Appears to not be relevant to the RTCWEB use case. Additionally, if it is necessary for there to be separate processes or even devices at the far end this can be solved by again simply not agreeing to use multiplexing. Agreed, not relevant to our case. > In all my reading today I have not been able to find anything more concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up if you are aware of any other relevant specifications that would argue against using SSRC to multiplex audio and video streams over a single RTP session between a pair of compatible endpoints that agree to do so. People certainly have done it, and people have also (though perhaps inadvisedly) had clients that would have several sessions with different clients terminating at the same port -- though people having done it doesn't mean it's good. -- Randell Jesup randell-ietf@jesup.org From magnus.westerlund@ericsson.com Mon Jul 25 04:53: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 41DB121F8B56 for ; Mon, 25 Jul 2011 04:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 a5teykr5Mh1A for ; Mon, 25 Jul 2011 04:53:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7221F86C3 for ; Mon, 25 Jul 2011 03:31:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-42-4e2d45e2e9cd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D8.E1.20773.2E54D2E4; Mon, 25 Jul 2011 12:30:59 +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; Mon, 25 Jul 2011 12:30:58 +0200 Message-ID: <4E2D45D0.5050103@ericsson.com> Date: Mon, 25 Jul 2011 06:30:40 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Lennox , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Jul 2011 11:53:37 -0000 On 2011-07-23 17:12, Stephan Wenger wrote: > Hi Magnus, > > Not sure you got the context right here. The "removal of multiparty > support" was related to my suggestion for a feature list of what I called > RTPv3, which would need to co-exist with RTPv2 (that includes multiparty > support). Ok, I misunderstood that. > > That said, if I'm not completely mistaken, you can implement the > multiparty use cases using the "RTCP terminating MCU" topology of RFC > 5117. This is common implementation practice in video conferencing. If > you do so, the multiparty support of RTPv2 is neither exercised nor needed > in a multiparty video conference. First of all if you do that you loose functionality as discussed in RFC 5117. For example the indication of who actually sent a packet originally or contribute to the mix can't be provided unless you let the SSRC or CSRC plus CNAMES be forwarded across the Mixer/MCU. In addition it forces the central unit into one particular implementation, instead of allowing to use what it most appropriate. An RTP mixer when you want something that has functionality and application enhancing behavior and the cost is more complexity. Or you use an relay which simply copies a packet from one entity to all the others. That is the simplest central node you can build and it will have no media processing at all. Also, in any gateway case to existing legacy you don't want to have to implement additional gatewaying functions just because one want to use non standard RTP. For me it is clear that ensuring that RTCWEBs RTP usage is vanilla will help us avoid a lot of problems down the road. If we are going to multiplex this mechanism needs to have a behavior that doesn't change the core behaviors of RTP. If we can do that the multiplexing becomes much less a hot topic. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Mon Jul 25 05:07: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 21E3821F84D4 for ; Mon, 25 Jul 2011 05:07:17 -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 Jt5-gVqdR+7z for ; Mon, 25 Jul 2011 05:07:16 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47321F84DC for ; Mon, 25 Jul 2011 05:07:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 29BCC39E148 for ; Mon, 25 Jul 2011 14:06:03 +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 KJk9SyjfGSF8 for ; Mon, 25 Jul 2011 14:06:02 +0200 (CEST) Received: from [10.255.254.216] (unknown [70.25.120.2]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7681A39E03C for ; Mon, 25 Jul 2011 14:06:01 +0200 (CEST) Message-ID: <4E2D5C5D.6060402@alvestrand.no> Date: Mon, 25 Jul 2011 08:06:53 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> In-Reply-To: <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:07:17 -0000 On 07/24/11 16:44, Matthew Kaufman wrote: > In all my reading today I have not been able to find anything more concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up if you are aware of any other relevant specifications that would argue against using SSRC to multiplex audio and video streams over a single RTP session between a pair of compatible endpoints that agree to do so. I have found *one* reason not mentioned in the draft: An RTP session with both "audio" and "video" media types cannot be represented by an SDP description, since SDP ties RTP sessions 1-1 to the "m" line of the description, which contains the top-level type, and the codec descriptions omit the top-level type in their codec naming. I've said elsewhere that I consider this to be a design mistake for entirely different reasons, but this debate has reinforced my opinion that it is. Harald From emil@sip-communicator.org Mon Jul 25 05:17: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 E041821F84BC for ; Mon, 25 Jul 2011 05:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 9yd4bSKWWVRS for ; Mon, 25 Jul 2011 05:17:29 -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 B5FAF21F844F for ; Mon, 25 Jul 2011 05:17:28 -0700 (PDT) Received: by wwe5 with SMTP id 5so2698604wwe.13 for ; Mon, 25 Jul 2011 05:17:27 -0700 (PDT) Received: by 10.216.237.205 with SMTP id y55mr468529weq.49.1311596247644; Mon, 25 Jul 2011 05:17:27 -0700 (PDT) Received: from porcinet.u-strasbg.fr ([2001:660:4701:1001:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id b13sm4277798wbh.24.2011.07.25.05.17.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 05:17:26 -0700 (PDT) Message-ID: <4E2D5ED5.5060706@jitsi.org> Date: Mon, 25 Jul 2011 14:17:25 +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: Harald Alvestrand References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> In-Reply-To: <4E2D5C5D.6060402@alvestrand.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:17:30 -0000 =D0=9D=D0=B0 25.07.11 14:06, Harald Alvestrand =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > On 07/24/11 16:44, Matthew Kaufman wrote: >> In all my reading today I have not been able to find anything more con= crete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up i= f you are aware of any other relevant specifications that would argue aga= inst using SSRC to multiplex audio and video streams over a single RTP se= ssion between a pair of compatible endpoints that agree to do so. > I have found *one* reason not mentioned in the draft: >=20 > An RTP session with both "audio" and "video" media types cannot be=20 > represented by an SDP description, since SDP ties RTP sessions 1-1 to=20 > the "m" line of the description, which contains the top-level type, and= =20 > the codec descriptions omit the top-level type in their codec naming. I am not sure I understand this. Why would one need to use the same "m" line? What would be the consequences of using two different "m" lines? Personally, I am still not convinced that multiplexing brings significant improvement over the status quo but if we accept it then it definitely needs to keep separate "m" lines for tons of reasons. Emil --=20 http://jitsi.org From harald@alvestrand.no Mon Jul 25 05:30: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 B768F21F867E for ; Mon, 25 Jul 2011 05:30:26 -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 P3Gw2iB0qrHK for ; Mon, 25 Jul 2011 05:30:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A55621F85EE for ; Mon, 25 Jul 2011 05:30:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E11339E148; Mon, 25 Jul 2011 14:29:18 +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 15eOii+W8Yl6; Mon, 25 Jul 2011 14:29:17 +0200 (CEST) Received: from [10.255.254.216] (unknown [70.25.120.2]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CE7B839E03C; Mon, 25 Jul 2011 14:29:16 +0200 (CEST) Message-ID: <4E2D61DC.1040305@alvestrand.no> Date: Mon, 25 Jul 2011 08:30:20 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Emil Ivov References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> <4E2D5ED5.5060706@jitsi.org> In-Reply-To: <4E2D5ED5.5060706@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:30:26 -0000 On 07/25/11 08:17, Emil Ivov wrote: > На 25.07.11 14:06, Harald Alvestrand написа: >> On 07/24/11 16:44, Matthew Kaufman wrote: >>> In all my reading today I have not been able to find anything more concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up if you are aware of any other relevant specifications that would argue against using SSRC to multiplex audio and video streams over a single RTP session between a pair of compatible endpoints that agree to do so. >> I have found *one* reason not mentioned in the draft: >> >> An RTP session with both "audio" and "video" media types cannot be >> represented by an SDP description, since SDP ties RTP sessions 1-1 to >> the "m" line of the description, which contains the top-level type, and >> the codec descriptions omit the top-level type in their codec naming. > I am not sure I understand this. Why would one need to use the same "m" > line? What would be the consequences of using two different "m" lines? > > Personally, I am still not convinced that multiplexing brings > significant improvement over the status quo but if we accept it then it > definitely needs to keep separate "m" lines for tons of reasons. RFC 4566 section 5: An SDP session description consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a "v=" line and continues to the first media-level section. Each media-level section starts with an "m=" line and continues to the next media-level section or end of the whole session description. .... 5.14. Media Descriptions ("m=") m= ... A session description may contain a number of media descriptions. Each media description starts with an "m=" field and is terminated by either the next "m=" field or by the end of the session description. A media field has several sub-fields: is the media type. Currently defined media are "audio", "video", "text", "application", and "message", although this list may be extended in the future (see Section 8). is the transport port to which the media stream is sent. In other words: an "m" line is tied to a port number, and (from RTP) the port number identifies the RTP session. The ICE parameters can override the port number, but they're carried within the "m" block, so they're tied to a single "m" line too. I do not know what would happen if you used the same port number and ICE parameters with two "m" lines. From randell1@jesup.org Mon Jul 25 05:32: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 5520C21F86B1 for ; Mon, 25 Jul 2011 05:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 r4wTGyKB1516 for ; Mon, 25 Jul 2011 05:32:22 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4553521F8686 for ; Mon, 25 Jul 2011 05:32:22 -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 1QlKKb-0002b1-NB for rtcweb@ietf.org; Mon, 25 Jul 2011 07:32:21 -0500 Message-ID: <4E2D620F.5010003@jesup.org> Date: Mon, 25 Jul 2011 08:31:11 -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: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> <4E2D5ED5.5060706@jitsi.org> In-Reply-To: <4E2D5ED5.5060706@jitsi.org> Content-Type: text/plain; charset=UTF-8; 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] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:32:23 -0000 On 7/25/2011 8:17 AM, Emil Ivov wrote: > На 25.07.11 14:06, Harald Alvestrand написа: >> On 07/24/11 16:44, Matthew Kaufman wrote: >>> In all my reading today I have not been able to find anything more concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up if you are aware of any other relevant specifications that would argue against using SSRC to multiplex audio and video streams over a single RTP session between a pair of compatible endpoints that agree to do so. >> I have found *one* reason not mentioned in the draft: >> >> An RTP session with both "audio" and "video" media types cannot be >> represented by an SDP description, since SDP ties RTP sessions 1-1 to >> the "m" line of the description, which contains the top-level type, and >> the codec descriptions omit the top-level type in their codec naming. > I am not sure I understand this. Why would one need to use the same "m" > line? What would be the consequences of using two different "m" lines? > > Personally, I am still not convinced that multiplexing brings > significant improvement over the status quo but if we accept it then it > definitely needs to keep separate "m" lines for tons of reasons. I've been assuming the method of indicating multiplexing would be two m= lines with the same c= destination and the same port specified. This is a mechanism that has been discussed before on the AVT list and/or in drafts (and I'm sure has also been done before). It does require avoiding using the same payload values in the two m= lines, but beyond that it's fairly straightforward. It also allows for the answerer to clearly reject a media type explicitly, instead of an implicit rejection by removing the payloads of a type. -- Randell Jesup randell-ietf@jesup.org From csp@csperkins.org Mon Jul 25 05:35: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 0DC8021F89BA for ; Mon, 25 Jul 2011 05:35:37 -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 Humay3527Lll for ; Mon, 25 Jul 2011 05:35:35 -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 AAF4B21F88DC for ; Mon, 25 Jul 2011 05:35:35 -0700 (PDT) Received: from [70.25.120.2] (helo=[10.255.254.41]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QlKNi-0004Sp-dK; Mon, 25 Jul 2011 12:35:34 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> Date: Mon, 25 Jul 2011 08:35:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9652C099-EFB9-40F1-AF38-ADFBD7B491D7@csperkins.org> References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:35:37 -0000 Section 2.2 of draft-perkins-rtcweb-rtp-usage-02 lists several reasons = why this sort of multiplexing is problematic. I would suggest, again, = that you read that draft.=20 Colin On 24 Jul 2011, at 16:44, Matthew Kaufman wrote: > I've been looking for technical reasons and/or hard requirements that = would argue against doing RTP multiplexing as proposed in this draft. >=20 > So far my conclusion is that the RTP specifications recommend against = this, but do not prohibit it. >=20 > Supporting evidence: > RFC 3550 Section 2.2 notes that multiplexing A&V together may be a = problem if you want to receive one and not together (presumably in the = multicast case) and refers to Section 5.2 for more support. >=20 > RFC 3550 Section 5.2 says "Separate audio and video streams SHOULD NOT = be carried in a single RTP session and demultiplexed based on the = payload type or SSRC fields." and provides five reasons. Note the = "SHOULD NOT" as opposed to "MUST NOT". >=20 > The same section says that the five reasons apply to multiplexing on = payload type, only the last two apply to multiplexing on SSRC. These = remaining reasons are: >=20 > 4. An RTP mixer would not be able to combine interleaved streams of > incompatible media into one stream. >=20 > Not relevant to the RTCWEB peer-to-peer case as the browser is not an = RTP mixer. Also not relevant to any RTCWEB use cases that I can = identify. And, if an RTP mixer at one end it can simply not agree to use = multiplexing. >=20 > 5. Carrying multiple media in one RTP session precludes: the use of > different network paths or network resource allocations if > appropriate; >=20 > Appears to not be relevant to the RTCWEB case where a unicast path = will be negotiated using ICE. >=20 > reception of a subset of the media if desired, for > example just audio if video would exceed the available bandwidth; >=20 > Appears to not be relevant to anything but the multicast cases. Any = unicast case, including RTCWEB, can simply not have that component of = the stream sent to it. >=20 > and receiver implementations that use separate processes for the > different media, whereas using separate RTP sessions permits > either single- or multiple-process implementations. >=20 > Appears to not be relevant to the RTCWEB use case. Additionally, if it = is necessary for there to be separate processes or even devices at the = far end this can be solved by again simply not agreeing to use = multiplexing. >=20 > In all my reading today I have not been able to find anything more = concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow = up if you are aware of any other relevant specifications that would = argue against using SSRC to multiplex audio and video streams over a = single RTP session between a pair of compatible endpoints that agree to = do so. >=20 > Matthew Kaufman >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From emil@sip-communicator.org Mon Jul 25 05:46: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 4777A21F8569 for ; Mon, 25 Jul 2011 05:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 emTn3gF9I8ju for ; Mon, 25 Jul 2011 05:46:08 -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 3B77921F8574 for ; Mon, 25 Jul 2011 05:46:08 -0700 (PDT) Received: by wyj26 with SMTP id 26so3154897wyj.31 for ; Mon, 25 Jul 2011 05:46:07 -0700 (PDT) Received: by 10.216.59.129 with SMTP id s1mr47493wec.86.1311597966459; Mon, 25 Jul 2011 05:46:06 -0700 (PDT) Received: from porcinet.u-strasbg.fr ([2001:660:4701:1001:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id a43sm1006795wed.28.2011.07.25.05.46.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 05:46:05 -0700 (PDT) Message-ID: <4E2D658B.3010600@jitsi.org> Date: Mon, 25 Jul 2011 14:46:03 +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: Harald Alvestrand References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> <4E2D5ED5.5060706@jitsi.org> <4E2D61DC.1040305@alvestrand.no> In-Reply-To: <4E2D61DC.1040305@alvestrand.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:46:09 -0000 =D0=9D=D0=B0 25.07.11 14:30, Harald Alvestrand =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > On 07/25/11 08:17, Emil Ivov wrote: >> =D0=9D=D0=B0 25.07.11 14:06, Harald Alvestrand =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0: >>> On 07/24/11 16:44, Matthew Kaufman wrote: >>>> In all my reading today I have not been able to find anything more c= oncrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up= if you are aware of any other relevant specifications that would argue a= gainst using SSRC to multiplex audio and video streams over a single RTP = session between a pair of compatible endpoints that agree to do so. >>> I have found *one* reason not mentioned in the draft: >>> >>> An RTP session with both "audio" and "video" media types cannot be >>> represented by an SDP description, since SDP ties RTP sessions 1-1 to= >>> the "m" line of the description, which contains the top-level type, a= nd >>> the codec descriptions omit the top-level type in their codec naming.= >> I am not sure I understand this. Why would one need to use the same "m= " >> line? What would be the consequences of using two different "m" lines?= >> >> Personally, I am still not convinced that multiplexing brings >> significant improvement over the status quo but if we accept it then i= t >> definitely needs to keep separate "m" lines for tons of reasons. > RFC 4566 section 5: >=20 > An SDP session description consists of a session-level section > followed by zero or more media-level sections. The session-level > part starts with a "v=3D" line and continues to the first media-lev= el > section. Each media-level section starts with an "m=3D" line and > continues to the next media-level section or end of the whole sessi= on > description. >=20 > .... >=20 > 5.14. Media Descriptions ("m=3D") >=20 > m=3D ... >=20 > A session description may contain a number of media descriptions. > Each media description starts with an "m=3D" field and is terminate= d by > either the next "m=3D" field or by the end of the session descripti= on. > A media field has several sub-fields: >=20 > is the media type. Currently defined media are "audio", > "video", "text", "application", and "message", although this lis= t > may be extended in the future (see Section 8). >=20 > is the transport port to which the media stream is sent. >=20 > In other words: an "m" line is tied to a port number, and (from RTP) th= e=20 > port number identifies the RTP session. The ICE parameters can override= =20 > the port number, but they're carried within the "m" block, so they're=20 > tied to a single "m" line too. OK, but this simply brings the discussion back to whether or not we can have audio and video on the same port. I still don't understand how it adds extra constraints and why two m-lines with the same port would be prohibited by SDP itself. > I do not know what would happen if you used the same port number and IC= E=20 > parameters with two "m" lines. Aha! Right! ICE itself would be able to handle this based on the user credentials. However, having two sets of ICE candidates in both media descriptions would simply trigger ICE processing for both of them. Given that the whole idea behind multiplexing is to simplify ICE signalling, I suppose this kind of kills it indeed. Emil --=20 http://jitsi.org From csp@csperkins.org Mon Jul 25 05:50: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 2F3CB21F88DD for ; Mon, 25 Jul 2011 05:50:48 -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 LKFMnwE0JEXG for ; Mon, 25 Jul 2011 05:50:46 -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 8296821F874C for ; Mon, 25 Jul 2011 05:50:46 -0700 (PDT) Received: from [70.25.120.2] (helo=[10.255.254.41]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QlKcO-0002mk-hz; Mon, 25 Jul 2011 12:50:45 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> Date: Mon, 25 Jul 2011 08:50:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <32ADCB9C-8303-46B8-AE6B-CDE5772FFBA5@csperkins.org> References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:50:48 -0000 On 24 Jul 2011, at 16:44, Matthew Kaufman wrote: > I've been looking for technical reasons and/or hard requirements that = would argue against doing RTP multiplexing as proposed in this draft. >=20 > So far my conclusion is that the RTP specifications recommend against = this, but do not prohibit it. >=20 > Supporting evidence: > RFC 3550 Section 2.2 notes that multiplexing A&V together may be a = problem if you want to receive one and not together (presumably in the = multicast case) and refers to Section 5.2 for more support. >=20 > RFC 3550 Section 5.2 says "Separate audio and video streams SHOULD NOT = be carried in a single RTP session and demultiplexed based on the = payload type or SSRC fields." and provides five reasons. Note the = "SHOULD NOT" as opposed to "MUST NOT". >=20 > The same section says that the five reasons apply to multiplexing on = payload type, only the last two apply to multiplexing on SSRC. These = remaining reasons are: >=20 > 4. An RTP mixer would not be able to combine interleaved streams of > incompatible media into one stream. >=20 > Not relevant to the RTCWEB peer-to-peer case as the browser is not an = RTP mixer. Also not relevant to any RTCWEB use cases that I can = identify. And, if an RTP mixer at one end it can simply not agree to use = multiplexing. This would work if you are directly talking to a mixer. It precludes the = cases where you are talking indirectly to a mixer via a gateway, unless = you define additional signalling to determine that there is a mixer on = the remote side of the gateway.=20 > 5. Carrying multiple media in one RTP session precludes: the use of > different network paths or network resource allocations if > appropriate; >=20 > Appears to not be relevant to the RTCWEB case where a unicast path = will be negotiated using ICE. An RTCWeb client using ICE could negotiate different network paths for = the audio and video flows, and could use network-based QoS mechanisms, = if flows were sent separately. Those mechanisms work just fine in = unicast. > reception of a subset of the media if desired, for > example just audio if video would exceed the available bandwidth; >=20 > Appears to not be relevant to anything but the multicast cases. Any = unicast case, including RTCWEB, can simply not have that component of = the stream sent to it. Relevant for proxies which do in-network adaptation. > and receiver implementations that use separate processes for the > different media, whereas using separate RTP sessions permits > either single- or multiple-process implementations. >=20 > Appears to not be relevant to the RTCWEB use case. Additionally, if it = is necessary for there to be separate processes or even devices at the = far end this can be solved by again simply not agreeing to use = multiplexing. >=20 > In all my reading today I have not been able to find anything more = concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow = up if you are aware of any other relevant specifications that would = argue against using SSRC to multiplex audio and video streams over a = single RTP session between a pair of compatible endpoints that agree to = do so. Timing and Sequence Number Space: An RTP SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss. Using multiple clock rates in a single RTP session is problematic, as discussed in [I-D.ietf-avtext-multiple-clock-rates]. This can be avoided by partitioning the SSRC space between the two sessions, but that causes other problems as discussed below. RTCP Reception Reports: RTCP sender reports and receiver reports can only describe one timing and sequence number space per SSRC, and do not carry a payload type field. Multiplexing sessions based on the payload type breaks RTCP. This can be avoided by partitioning the SSRC space between the two sessions, but that causes other problems as discussed below. Scalability: RTP was built with media scalability in consideration. The simplest way of achieving separation between different scalability layers is placing them in different RTP sessions, and using the same SSRC and CNAME in each session to bind them together. This is most commonly done in multicast, and not particularly applicable to RTC-Web, but gatewaying of such a session would then require more alterations and likely stateful translation. RTP Retransmission in Session Multiplexing mode: RTP Retransmission [RFC4588] does have a mode for session multiplexing. This would not be the main mode used in RTC-Web, but for interoperability and reduced cost in translation support for different RTP Sessions are beneficial. Forward Error Correction: The "An RTP Payload Format for Generic Forward Error Correction" [RFC2733] and its update [RFC5109] can only be used on media formats that produce RTP packets that are smaller than half the MTU if the FEC flow and media flow being protected are to be sent in the same RTP session, this is due to "RTP Payload for Redundant Audio Data" [RFC2198]. This is because the SSRC value of the original flow is recovered from the FEC packets SSRC field. So for anything that desires to use these format with RTP payloads that are close to MTU needs to put the FEC data in a separate RTP session compared to the original transmissions. The usage of this type of FEC data has not been decided on in RTCWEB. SSRC Allocation and Collision: The SSRC identifier is a random 32- bit number that is required to be globally unique within an RTP session, and that is reallocated to a new random value if an SSRC collision occurs between participants. If two or more RTP sessions share a transport layer flow, there is no guarantee that their choice of SSRC values will be distinct, and there is no way in standard RTP to signal which SSRC values are used by which RTP session. RTP is explicitly a group-based communication protocol, and new participants can join an RTP session at any time; these new participants may chose SSRC values that conflict with the SSRC values used in any of the multiplexed RTP sessions. This problem can be avoided by partitioning the SSRC space, and signalling how the space is to be subdivided, but this is not backwards compatible with any existing RTP system. In addition, subdividing the SSRC space makes it difficult to gateway between multiplexed RTP sessions and standard RTP sessions: the standard sessions may use parts of the SSRC space reserved in the multiplexed RTP sessions, requiring the gateway to rewrite RTCP packets, as well as the SSRC and CSRC list in RTP data packets. Rewriting RTCP is a difficult task, especially when one considers extensions such as RTCP XR. Conflicting RTCP Report Types: The extension mechanisms used in RTCP depend on separation of RTP sessions for different media types. For example, the RTCP Extended Report block for VoIP is suitable for conversational audio, but clearly not useful for Video. This may cause unusable or unwanted reports to be generated for some streams, wasting capacity and confusing monitoring systems. While this is problem may be unlikely for VoIP reports, it may be an issue for the more detailed media agnostic reports which are sometimes be used for different media types. Also, this makes the implementation of RTCP more complex, since partitioning the SSRC space by media type needs not only to be one the media processing side, but also on the RTCP reporting RTCP Reporting and Scheduling: The RTCP reporting interval and its packet scheduling will be affected if several RTP sessions are multiplexed onto the same transport layer flow. The reporting interval is determined by the session bandwidth, and the reporting interval chosen for a high-rate video session will be different to the interval chosen by a low-rate VoIP session. If such sessions are multiplexed, then participants in one session will see the SSRC values of the other session. This will cause them to overestimate the number of participants in the session by a factor of two, thus doubling their RTCP reporting interval, and making their feedback less timely. In the worst case, when an RTP session with very low RTCP bandwidth is multiplexed with an RTP session with high RTCP bandwidth, this may cause repeated RTCP timer reconsideration, leading to the members of the low bandwidth session timing out. Participants in an RTP session configured with high bandwidth (and short RTCP reporting interval) will see RTCP reports from participants in the low bandwidth session much less often than expected, potentially causing them to repeatedly timeout and re-create state for those participants. The split of RTCP bandwidth between senders and receivers (where at least 25% of the RTCP bandwidth is allocated to senders) will be disrupted if a session with few senders (e.g., a VoIP session) is multiplexed with a session with many senders (e.g., a video session). These issues can be resolved if the partition of the SSRC is signalled, but this is not backwards compatible with any existing RTP system. The partition would require re-implementing large part of the RTCP processing to take the individual sessions into account. Sampling Group Membership: The mechanism defined in RFC2762 to sample the group membership, allowing participants to keep less state, assumes a single flat 32-bit SSRC space, and breaks if the SSRC space is shared between several RTP sessions. --=20 Colin Perkins http://csperkins.org/ From mperumal@cisco.com Mon Jul 25 05:57: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 5F1FD21F881C for ; Mon, 25 Jul 2011 05:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, 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 Qrzwgp3QdzvZ for ; Mon, 25 Jul 2011 05:57:42 -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 C2B1721F8453 for ; Mon, 25 Jul 2011 05:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=7956; q=dns/txt; s=iport; t=1311598661; x=1312808261; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=i9P+13zyjfmA05LkFM8f3KFsNp2u1yMBI1nbp5mV8ls=; b=JU7fyYPvJSZ3WB7hhMgOAjHVwXKhvjSD7OFS8CkH0OPeyUBsEZq3SS1O hQMxFEf4YEdFx/J2CDeZJMW2ltKkPiCk0DBW97fcmh0y3CRe1Q4pe1BMj 7bJipIdTsdrcYbn8Ind2B3VhiMfEz9X2rRu/DXybxwwBNDu/WbZB9jTcy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugAAH5nLU5Io8UR/2dsb2JhbAA0AQEBAQMBAQERARQNBEAXBQIBBwIRBAEBAwIGBh8EAQICAgEBEhgjDggBAQUBCwsMG4QvkyyOVn93iQCiM40jkE6BK4QFMF8Eh1OQLYtY X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="104173167" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2011 12:57:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PCvcta003477; Mon, 25 Jul 2011 12:57:38 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 18:27:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 25 Jul 2011 18:27:34 +0530 Message-ID: <1D062974A4845E4D8A343C653804920205F72BDC@XMB-BGL-414.cisco.com> In-Reply-To: <4E2D620F.5010003@jesup.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt) Thread-Index: AcxKxvNsKdI6415PTseSX5ZDxOKSvgAAbxOw References: <4E123C54.10405@jdrosen.net><8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net><4E2D5C5D.6060402@alvestrand.no> <4E2D5ED5.5060706@jitsi.org> <4E2D620F.5010003@jesup.org> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Randell Jesup" , X-OriginalArrivalTime: 25 Jul 2011 12:57:37.0933 (UTC) FILETIME=[6E2F13D0:01CC4ACA] Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 12:57:43 -0000 QSBmZXcgb3B0aW9ucyB0byBpbmRpY2F0ZSB0aGlzIG11bHRpcGxleGluZyBpbiBTRFAgYW5kIGJl aW5nIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBsZWdhY3kgaW1wbGVtZW50YXRpb25zOg0KDQox KSBUaGUgc2ltcGxlc3Qgb3B0aW9uIGlzIHRvIHVzZSB0aGUgc2FtZSBwb3J0IHZhbHVlIGFjcm9z cyBtdWx0aXBsZSAibT0iIGxpbmVzIGluIHRoZSBTRFAuIFVuZm9ydHVuYXRlbHksIHRoYXQgd29u J3QgYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbnMgYmVj YXVzZSBvZiBSRkMtNDU2NiBzZWN0aW9uIDUuMTQ6DQo8c25pcD4NCiAgIFRoZSBzZW1hbnRpY3Mg b2YgbXVsdGlwbGUgIm09IiBsaW5lcyB1c2luZyB0aGUgc2FtZSB0cmFuc3BvcnQgYWRkcmVzcyBh cmUgdW5kZWZpbmVkLg0KPC9zbmlwPg0KDQpTbywgaWYgYSBsZWdhY3kgaW1wbGVtZW50YXRpb24g cmVjZWl2ZXMgc3VjaCBhbiBvZmZlciwgdGhlIGJlaGF2aW9yIHdvdWxkIGJlIHVucHJlZGljdGFi bGUuDQoNCjIpIEFub3RoZXIgb3B0aW9uIGlzIHRvIHNpbXBseSBsaXN0IGFsbCB0aGUgKGF1ZGlv L3ZpZGVvKSBjb2RlcyBpbiBhIHNpbmdsZSAibT0iIGxpbmUgYW5kIGRlZmluZSBhIG5ldyAob3B0 aW9uYWwpIFNEUCBhdHRyaWJ1dGUgdG8gaW5kaWNhdGUgbXVsdGlwbGV4aW5nLiBUaGlzIGFsc28g aXMgbm8gd2F5IGdvaW5nIHRvIGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBsZWdhY3kgaW1w bGVtZW50YXRpb25zLCBzaW5jZSBhIGxlZ2FjeSBlbmRwb2ludCBtaWdodCB0eXBpY2FsbHkgc2Vu ZCBhbiBhbnN3ZXIgd2l0aCBhIHNpbmdsZSBjb2RlYywgcmVzdWx0aW5nIGluIGFuIGF1ZGlvLW9u bHkvdmlkZW8tb25seSBjYWxsLCB3aGVuIGF1ZGlvICsgdmlkZW8gd2FzIGludGVuZGVkLg0KDQoz KSBBbm90aGVyIG9wdGlvbnMgaXMgU0RQIGdyb3VwaW5nLiBVbmZvcnR1bmF0ZWx5LCBSRkMtMzM4 OCBzZWN0aW9uIDcuNS4zIGZvcmJpZHMgZ3JvdXBpbmcgbXVsdGlwbGUgIm09IiBsaW5lcyB1c2lu ZyB0aGUgc2FtZSB0cmFuc3BvcnQgYWRkcmVzczoNCjxzbmlwPg0KICAgSWYgc2V2ZXJhbCBjb2Rl Y3MgaGF2ZSB0byBiZSBzZW50IHRvIHRoZSBzYW1lIElQIGFkZHJlc3MgYW5kIHBvcnQsDQogICB0 aGUgdHJhZGl0aW9uYWwgU0RQIHN5bnRheCBvZiBsaXN0aW5nIHNldmVyYWwgY29kZWNzIGluIHRo ZSBzYW1lICJtIg0KICAgbGluZSBNVVNUIGJlIHVzZWQuICBGSUQgTVVTVCBOT1QgYmUgdXNlZCB0 byBncm91cCAibSIgbGluZXMgd2l0aCB0aGUNCiAgIHNhbWUgSVAgYWRkcmVzcy9wb3J0LiAgVGhl cmVmb3JlLCBhbiBTRFAgbGlrZSB0aGUgb25lIGJlbG93IE1VU1QgTk9UDQogICBiZSBnZW5lcmF0 ZWQuDQoNCiAgICAgICB2PTANCiAgICAgICBvPUxhdXJhIDI4OTA4MzEyNCAyODkwODMxMjQgSU4g SVA0IHNpeC5leGFtcGxlLmNvbQ0KICAgICAgIHQ9MCAwDQogICAgICAgYz1JTiBJUDQgMTMxLjE2 MC4xLjExMg0KICAgICAgIGE9Z3JvdXA6RklEIDEgMg0KICAgICAgIG09YXVkaW8gMzAwMDAgUlRQ L0FWUCAwDQogICAgICAgYT1taWQ6MQ0KICAgICAgIG09YXVkaW8gMzAwMDAgUlRQL0FWUCA4DQog ICAgICAgYT1taWQ6Mg0KDQogICBUaGUgY29ycmVjdCBTRFAgZm9yIHRoZSBzZXNzaW9uIGFib3Zl IHdvdWxkIGJlIHRoZSBmb2xsb3dpbmcgb25lOg0KDQogICAgICAgdj0wDQogICAgICAgbz1MYXVy YSAyODkwODMxMjQgMjg5MDgzMTI0IElOIElQNCBzaXguZXhhbXBsZS5jb20NCiAgICAgICB0PTAg MA0KICAgICAgIGM9SU4gSVA0IDEzMS4xNjAuMS4xMTINCiAgICAgICBtPWF1ZGlvIDMwMDAwIFJU UC9BVlAgMCA4DQoNCiAgIElmIHR3byAibSIgbGluZXMgYXJlIGdyb3VwZWQgdXNpbmcgRklEIHRo ZXkgTVVTVCBkaWZmZXIgaW4gdGhlaXINCiAgIHRyYW5zcG9ydCBhZGRyZXNzZXMgKGkuZS4sIElQ IGFkZHJlc3MgcGx1cyBwb3J0KS4NCjwvc25pcD4NCg0KSW4gYWRkaXRpb24sIHVzaW5nIHRoZSB0 cmFuc3BvcnQgYWRkcmVzcyBhY3Jvc3MgbXVsdGlwbGUgIm09IiBsaW5lcyBieSBpdHNlbGYgZG9l c24ndCBkZWZpbmUgYSBuZXcgZ3JvdXAuIFNvLCB1c2luZyBncm91cGluZyBkb2Vzbid0IGxvb2sg cmlnaHQuDQoNCjQpIFRoZSBiZXN0IG9wdGlvbiBJIGNhbiB0aGluayBvZiBpcyB0byBkZWZpbmUg YSBuZXcgbWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0ZSAoc2F5LCBhPW11eHBvcnQ6IDxwb3J0Pikg dGhhdCBpbmRpY2F0ZXMgYSBtdWx0aXBsZXhlZCBwb3J0IHdoZXJlIHRoZSBvZmZlcmVyL2Fuc3dl cmVyIGlzIHdpbGxpbmcgdG8gcmVjZWl2ZSBtZWRpYSBzdHJlYW1zLCBpbi1hZGRpdGlvbiB0byB0 aGUgcG9ydCBpbmRpY2F0ZWQgaW4gdGhlICJtPSIgbGluZXMuDQoNClNvLCB0aGUgb2ZmZXIgY291 bGQgbG9vayBsaWtlIHRoaXM6DQogICAgICBtPWF1ZGlvIDQ5MTcwIFJUUC9BVlAgMCA4IDk3DQog ICAgICBhPXJ0cG1hcDowIFBDTVUvODAwMA0KICAgICAgYT1ydHBtYXA6OCBQQ01BLzgwMDANCiAg ICAgIGE9cnRwbWFwOjk3IGlMQkMvODAwMA0KICAgICAgYT1tdXhwb3J0OjUwMDAgDQogICAgICBt PXZpZGVvIDUxMzcyIFJUUC9BVlAgMzEgMzINCiAgICAgIGE9cnRwbWFwOjMxIEgyNjEvOTAwMDAN CiAgICAgIGE9cnRwbWFwOjMyIE1QVi85MDAwMA0KICAgICAgYT1tdXhwb3J0OjUwMDANCg0KQW4g ZW5kcG9pbnQgdGhhdCBkb2Vzbid0IHN1cHBvcnQgbXVsdGlwbGV4aW5nIHdvdWxkIGlnbm9yZSBh PW11eHBvcnQgYW5kIHNlbmQgYSBhbnN3ZXIgbGlrZSB0aGlzOg0KICAgICAgbT1hdWRpbyA0OTE3 NCBSVFAvQVZQIDANCiAgICAgIGE9cnRwbWFwOjAgUENNVS84MDAwDQogICAgICBtPXZpZGVvIDQ5 MTcwIFJUUC9BVlAgMzINCiAgICAgIGE9cnRwbWFwOjMyIE1QVi85MDAwMA0KDQpXaGVyZWFzIGFu IGVuZHBvaW50IHRoYXQgdW5kZXJzdGFuZCBtdWx0aXBsZXhpbmcgd291bGQgdW5kZXJzdGFuZCBh PW11eHBvcnQgYW5kIHNlbmQgYW4gYW5zd2VyIGxpa2UgdGhpczoNCiAgICAgIG09YXVkaW8gNDAw MDAgUlRQL0FWUCAwDQogICAgICBhPXJ0cG1hcDowIFBDTVUvODAwMA0KICAgICAgYT1tdXhwb3J0 OjQwMDANCiAgICAgIG09dmlkZW8gNDAwMDAgUlRQL0FWUCAzMg0KICAgICAgYT1ydHBtYXA6MzIg TVBWLzkwMDAwDQogICAgICBhPW11eHBvcnQ6NDAwMA0KDQpIb3dldmVyLCB0aGUgb3ZlcmhlYWQg Zm9yIG5ldyBpbXBsZW1lbnRhdGlvbnMgaXMgdGhhdCBpdCBuZWVkcyB0byBsaXN0ZW4gb24gYm90 aCB0aGUgcG9ydCBsaXN0ZWQgaW4gdGhlICJtPSIgbGluZXMgYW5kIHRoZSBwb3J0IHNwZWNpZmll ZCBpbiBhPW11eHBvcnQsIGluIGFkZGl0aW9uIHRvIGdhdGhlcmluZyBib3RoIGNhbmRpZGF0ZXMg Zm9yIElDRSwgdGlsbCBpdCByZWNlaXZlcyB0aGUgYW5zd2VyLiBJZiBpdCB3YW50cyB0byBiZSBi YWNrd2FyZCBjb21wYXRpYmxlIHdpdGggbGVnYWN5IGltcGxhbnRhdGlvbnMsIGl0IG5lZWRzIHRv IHBheSBmb3IgaXQsIGFueXdheS4uDQoNCk11dGh1DQoNCnwtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KfEZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSYW5kZWxsIEplc3VwDQp8U2VudDogTW9uZGF5LCBK dWx5IDI1LCAyMDExIDY6MDEgUE0NCnxUbzogcnRjd2ViQGlldGYub3JnDQp8U3ViamVjdDogUmU6 IFtydGN3ZWJdIFJlYXNvbnMgbm90IHRvIG11bHRpcGxleCBhdWRpbyB3aXRoIHZpZGVvIChSZTog RndkOiBJLUQgQWN0aW9uOiBkcmFmdC1yb3NlbmJlcmctDQp8cnRjd2ViLXJ0cG11eC0wMC50eHQp DQp8DQp8T24gNy8yNS8yMDExIDg6MTcgQU0sIEVtaWwgSXZvdiB3cm90ZToNCnw+INCd0LAgMjUu MDcuMTEgMTQ6MDYsIEhhcmFsZCBBbHZlc3RyYW5kINC90LDQv9C40YHQsDoNCnw+PiBPbiAwNy8y NC8xMSAxNjo0NCwgTWF0dGhldyBLYXVmbWFuIHdyb3RlOg0KfD4+PiBJbiBhbGwgbXkgcmVhZGlu ZyB0b2RheSBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBmaW5kIGFueXRoaW5nIG1vcmUgY29uY3Jl dGUgdGhhbiB0aGUgIlNIT1VMRCBOT1QiDQp8aW4gc2VjdGlvbiA1LjIgb2YgUkZDMzU1MC4gUExF QVNFIGZvbGxvdyB1cCBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBvdGhlciByZWxldmFudCBzcGVj aWZpY2F0aW9ucyB0aGF0DQp8d291bGQgYXJndWUgYWdhaW5zdCB1c2luZyBTU1JDIHRvIG11bHRp cGxleCBhdWRpbyBhbmQgdmlkZW8gc3RyZWFtcyBvdmVyIGEgc2luZ2xlIFJUUCBzZXNzaW9uIGJl dHdlZW4NCnxhIHBhaXIgb2YgY29tcGF0aWJsZSBlbmRwb2ludHMgdGhhdCBhZ3JlZSB0byBkbyBz by4NCnw+PiBJIGhhdmUgZm91bmQgKm9uZSogcmVhc29uIG5vdCBtZW50aW9uZWQgaW4gdGhlIGRy YWZ0Og0KfD4+DQp8Pj4gQW4gUlRQIHNlc3Npb24gd2l0aCBib3RoICJhdWRpbyIgYW5kICJ2aWRl byIgbWVkaWEgdHlwZXMgY2Fubm90IGJlDQp8Pj4gcmVwcmVzZW50ZWQgYnkgYW4gU0RQIGRlc2Ny aXB0aW9uLCBzaW5jZSBTRFAgdGllcyBSVFAgc2Vzc2lvbnMgMS0xIHRvDQp8Pj4gdGhlICJtIiBs aW5lIG9mIHRoZSBkZXNjcmlwdGlvbiwgd2hpY2ggY29udGFpbnMgdGhlIHRvcC1sZXZlbCB0eXBl LCBhbmQNCnw+PiB0aGUgY29kZWMgZGVzY3JpcHRpb25zIG9taXQgdGhlIHRvcC1sZXZlbCB0eXBl IGluIHRoZWlyIGNvZGVjIG5hbWluZy4NCnw+IEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRo aXMuIFdoeSB3b3VsZCBvbmUgbmVlZCB0byB1c2UgdGhlIHNhbWUgIm0iDQp8PiBsaW5lPyBXaGF0 IHdvdWxkIGJlIHRoZSBjb25zZXF1ZW5jZXMgb2YgdXNpbmcgdHdvIGRpZmZlcmVudCAibSIgbGlu ZXM/DQp8Pg0KfD4gUGVyc29uYWxseSwgSSBhbSBzdGlsbCBub3QgY29udmluY2VkIHRoYXQgbXVs dGlwbGV4aW5nIGJyaW5ncw0KfD4gc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnQgb3ZlciB0aGUgc3Rh dHVzIHF1byBidXQgaWYgd2UgYWNjZXB0IGl0IHRoZW4gaXQNCnw+IGRlZmluaXRlbHkgbmVlZHMg dG8ga2VlcCBzZXBhcmF0ZSAibSIgbGluZXMgZm9yIHRvbnMgb2YgcmVhc29ucy4NCnwNCnxJJ3Zl IGJlZW4gYXNzdW1pbmcgdGhlIG1ldGhvZCBvZiBpbmRpY2F0aW5nIG11bHRpcGxleGluZyB3b3Vs ZCBiZSB0d28gbT0NCnxsaW5lcyB3aXRoDQp8dGhlIHNhbWUgYz0gZGVzdGluYXRpb24gYW5kIHRo ZSBzYW1lIHBvcnQgc3BlY2lmaWVkLiAgVGhpcyBpcyBhDQp8bWVjaGFuaXNtIHRoYXQgaGFzDQp8 YmVlbiBkaXNjdXNzZWQgYmVmb3JlIG9uIHRoZSBBVlQgbGlzdCBhbmQvb3IgaW4gZHJhZnRzIChh bmQgSSdtIHN1cmUgaGFzDQp8YWxzbyBiZWVuDQp8ZG9uZSBiZWZvcmUpLiAgSXQgZG9lcyByZXF1 aXJlIGF2b2lkaW5nIHVzaW5nIHRoZSBzYW1lIHBheWxvYWQgdmFsdWVzIGluDQp8dGhlIHR3byBt PSBsaW5lcywNCnxidXQgYmV5b25kIHRoYXQgaXQncyBmYWlybHkgc3RyYWlnaHRmb3J3YXJkLiAg SXQgYWxzbyBhbGxvd3MgZm9yIHRoZQ0KfGFuc3dlcmVyIHRvIGNsZWFybHkgcmVqZWN0IGENCnxt ZWRpYSB0eXBlIGV4cGxpY2l0bHksIGluc3RlYWQgb2YgYW4gaW1wbGljaXQgcmVqZWN0aW9uIGJ5 IHJlbW92aW5nIHRoZQ0KfHBheWxvYWRzIG9mIGEgdHlwZS4NCnwNCnwtLQ0KfFJhbmRlbGwgSmVz dXANCnxyYW5kZWxsLWlldGZAamVzdXAub3JnDQp8DQp8X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnxydGN3ZWIgbWFpbGluZyBsaXN0DQp8cnRjd2ViQGll dGYub3JnDQp8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From matthew.kaufman@skype.net Mon Jul 25 06:05: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 8EA2C21F8793 for ; Mon, 25 Jul 2011 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJCU5+1C6LjC for ; Mon, 25 Jul 2011 06:05:02 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9270421F89A1 for ; Mon, 25 Jul 2011 06:05:02 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 50FB11700; Mon, 25 Jul 2011 15:05:01 +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=mN URpvF7m359sfGm7h+z9Rl9oh4=; b=IM9buQiWYGClENTFh5cxtw12MkEhzIGBxs AI0ZyWYsFOS2Gi51T81KWd/QsK71ZAlmIFmDsQ/a0noD4IteBAFq333j8Inw9Ivi TPUq9sEY3CKrIlN/0ote5WU4JclX9YQ/SXwdCjy/nFFIVMWoJBy2tdbCgIR7UczT BQsWyq7lw= 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=C1bT78usXdHgF+o8mzyb70 v1vviY1KQsLMOi50r7c5X8N839cMUwrmv7pmbvgxQGr42/wTlVadPlqHGeb276ZO oLbQgEVYD+LlSIQwVbeaYkjfpx9u70NfufLbYck8mSJsHZKXErVmTJtt53v8NU3X jUPCdG+J4l12kmTnb3p9g= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 4F8C37F8; Mon, 25 Jul 2011 15:05:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 1F8AC3508A12; Mon, 25 Jul 2011 15:05:01 +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 BmydfdhIFQxt; Mon, 25 Jul 2011 15:05:00 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (unknown [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id E5E5835080FE; Mon, 25 Jul 2011 15:04:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <4E2D5C5D.6060402@alvestrand.no> Date: Mon, 25 Jul 2011 09:04:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 13:05:03 -0000 On Jul 25, 2011, at 8:06 AM, Harald Alvestrand wrote: > On 07/24/11 16:44, Matthew Kaufman wrote: >> In all my reading today I have not been able to find anything more = concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow = up if you are aware of any other relevant specifications that would = argue against using SSRC to multiplex audio and video streams over a = single RTP session between a pair of compatible endpoints that agree to = do so. > I have found *one* reason not mentioned in the draft: >=20 > An RTP session with both "audio" and "video" media types cannot be = represented by an SDP description, since SDP ties RTP sessions 1-1 to = the "m" line of the description, which contains the top-level type, and = the codec descriptions omit the top-level type in their codec naming. >=20 > I've said elsewhere that I consider this to be a design mistake for = entirely different reasons, but this debate has reinforced my opinion = that it is. Good point, but perhaps it just argues for either A) not using SDP or B) = extending SDP if we use it for RTCWEB (we probably need to do that = anyway if we use SDP, given all the discussion about "hints" that we = want to send from one end to the other) Matthew Kaufman= From mperumal@cisco.com Mon Jul 25 06:36: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 4A22621F861A for ; Mon, 25 Jul 2011 06:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvqSQ0NGgm29 for ; Mon, 25 Jul 2011 06:36:21 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 864D821F85CE for ; Mon, 25 Jul 2011 06:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2777; q=dns/txt; s=iport; t=1311600980; x=1312810580; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GREFf7rUbLYML0xrSfTKgWKMh6Ayk/Z0oYANVUsY5FM=; b=D55V/oLZ8rYdiOFxL2NZPWdfuv1EazGik8lWHIDpu77p5nMxZqlUryff 9zNd+Plq3aKYhgpSpXhtaoL7X/e43EbJcPtQJZ4D1/Qsq/jk5JmVUIuRh 9UZ1Y2H1wZdnrjVHKAPIG7TO2q+Cn/o8ThVRqb5cU7WbzA6yARPCJTz7r I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAOBwLU5Io8US/2dsb2JhbAA0AQEBAQMBAQERASEKOgsMBQIBCREEAQELBh8EAQYBExgjDggBAQUBCwsMG5dbj1Z3iQCiGp11hWBfBIdTkC2LWA X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="44192633" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 25 Jul 2011 13:35:57 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6PDZtwY014434; Mon, 25 Jul 2011 13:35:55 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 19:05:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 19:05:55 +0530 Message-ID: <1D062974A4845E4D8A343C653804920205F72BF7@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt) Thread-Index: AcxKy4FLxHg/t0ZxScurnZzB6EE8BwAAf1/Q References: <4E123C54.10405@jdrosen.net><8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net><4E2D5C5D.6060402@alvestrand.no> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Matthew Kaufman" , "Harald Alvestrand" X-OriginalArrivalTime: 25 Jul 2011 13:35:55.0697 (UTC) FILETIME=[C7C20A10:01CC4ACF] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 13:36:22 -0000 c) Using SDP for legacy interop, but extending STUN, by defining a (comprehension optional) STUN attribute that indicates it is a multiplexed media flow and that the SSRC space has been partitioned to enable DPI. Since rtcweb apps are expected to use STUN, it should be trivial for them to support this STUN attribute. In addition, the software in on-path routers would have to be upgraded anyway to support this king of DPI, so they could also be enhanced to detect STUN and look for this attribute. One another benefit to indicating this in STUN is that even if both rtcweb endpoints said they supported this mechanism via SDP, the routers where QoS, traffic engineering etc are applied to media packets many not be there in the signaling path to understand that it is a multiplexed media flow using the same port, and in particular that the SSRC space has been partitioned as proposed in draft-rosenberg-rtcweb-rtpmux to enable them to perform DPI and figure out the media type (audio/video etc). Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Matthew Kaufman |Sent: Monday, July 25, 2011 6:35 PM |To: Harald Alvestrand |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg- |rtcweb-rtpmux-00.txt) | | |On Jul 25, 2011, at 8:06 AM, Harald Alvestrand wrote: | |> On 07/24/11 16:44, Matthew Kaufman wrote: |>> In all my reading today I have not been able to find anything more concrete than the "SHOULD NOT" |in section 5.2 of RFC3550. PLEASE follow up if you are aware of any other relevant specifications that |would argue against using SSRC to multiplex audio and video streams over a single RTP session between |a pair of compatible endpoints that agree to do so. |> I have found *one* reason not mentioned in the draft: |> |> An RTP session with both "audio" and "video" media types cannot be represented by an SDP |description, since SDP ties RTP sessions 1-1 to the "m" line of the description, which contains the |top-level type, and the codec descriptions omit the top-level type in their codec naming. |> |> I've said elsewhere that I consider this to be a design mistake for entirely different reasons, but |this debate has reinforced my opinion that it is. | |Good point, but perhaps it just argues for either A) not using SDP or B) extending SDP if we use it |for RTCWEB (we probably need to do that anyway if we use SDP, given all the discussion about "hints" |that we want to send from one end to the other) | |Matthew Kaufman |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Jul 25 06:50: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 DC54621F84D4 for ; Mon, 25 Jul 2011 06:50:20 -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 75sEn72SZqb4 for ; Mon, 25 Jul 2011 06:50:20 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E19F821F84D1 for ; Mon, 25 Jul 2011 06:50:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A5F439E148; Mon, 25 Jul 2011 15:49:11 +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 b4wO1OjBPBBd; Mon, 25 Jul 2011 15:49:10 +0200 (CEST) Received: from [130.129.22.244] (unknown [130.129.22.244]) by eikenes.alvestrand.no (Postfix) with ESMTPS id ECE2139E03C; Mon, 25 Jul 2011 15:49:09 +0200 (CEST) Message-ID: <4E2D749D.9000406@alvestrand.no> Date: Mon, 25 Jul 2011 09:50:21 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <4E123C54.10405@jdrosen.net><8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net><4E2D5C5D.6060402@alvestrand.no> <1D062974A4845E4D8A343C653804920205F72BF7@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920205F72BF7@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 13:50:21 -0000 On 07/25/11 09:35, Muthu Arul Mozhi Perumal (mperumal) wrote: > c) Using SDP for legacy interop, but extending STUN, by defining a > (comprehension optional) STUN attribute that indicates it is a > multiplexed media flow and that the SSRC space has been partitioned to > enable DPI. I think that's a layering violation. STUN has no references to RTP; there is no assumption in STUN that the content of the flow will be RTP. I think we should keep it that way. > Since rtcweb apps are expected to use STUN, it should be > trivial for them to support this STUN attribute. In addition, the > software in on-path routers would have to be upgraded anyway to support > this king of DPI, so they could also be enhanced to detect STUN and look > for this attribute. > > One another benefit to indicating this in STUN is that even if both > rtcweb endpoints said they supported this mechanism via SDP, the routers > where QoS, traffic engineering etc are applied to media packets many not > be there in the signaling path to understand that it is a multiplexed > media flow using the same port, and in particular that the SSRC space > has been partitioned as proposed in draft-rosenberg-rtcweb-rtpmux to > enable them to perform DPI and figure out the media type (audio/video > etc). > > Muthu > > |-----Original Message----- > |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Matthew Kaufman > |Sent: Monday, July 25, 2011 6:35 PM > |To: Harald Alvestrand > |Cc: rtcweb@ietf.org > |Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: > Fwd:I-D Action: draft-rosenberg- > |rtcweb-rtpmux-00.txt) > | > | > |On Jul 25, 2011, at 8:06 AM, Harald Alvestrand wrote: > | > |> On 07/24/11 16:44, Matthew Kaufman wrote: > |>> In all my reading today I have not been able to find anything more > concrete than the "SHOULD NOT" > |in section 5.2 of RFC3550. PLEASE follow up if you are aware of any > other relevant specifications that > |would argue against using SSRC to multiplex audio and video streams > over a single RTP session between > |a pair of compatible endpoints that agree to do so. > |> I have found *one* reason not mentioned in the draft: > |> > |> An RTP session with both "audio" and "video" media types cannot be > represented by an SDP > |description, since SDP ties RTP sessions 1-1 to the "m" line of the > description, which contains the > |top-level type, and the codec descriptions omit the top-level type in > their codec naming. > |> > |> I've said elsewhere that I consider this to be a design mistake for > entirely different reasons, but > |this debate has reinforced my opinion that it is. > | > |Good point, but perhaps it just argues for either A) not using SDP or > B) extending SDP if we use it > |for RTCWEB (we probably need to do that anyway if we use SDP, given all > the discussion about "hints" > |that we want to send from one end to the other) > | > |Matthew Kaufman > |_______________________________________________ > |rtcweb mailing list > |rtcweb@ietf.org > |https://www.ietf.org/mailman/listinfo/rtcweb > From matthew.kaufman@skype.net Mon Jul 25 09:12: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 8EAB311E812B for ; Mon, 25 Jul 2011 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7J3NFaJxKZM for ; Mon, 25 Jul 2011 09:12:00 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id EBB8821F8C9D for ; Mon, 25 Jul 2011 07:45:59 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id F157B1702; Mon, 25 Jul 2011 16:45:58 +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=eo LMIKI11qZzNu64pdjaGghsoQs=; b=GeMrNAY0d+fikwOoYbNXDG3Pjp9iBrMfQR vU5vMcc6BqR+fyFNd9/nwzY0fxwV6tX6op30600TnQxnCCaZw72lfDCpZTbcC/yd otfSt40p4h/Fgw+L9h1/igm+3zuVyKL8OReWQzNMspiuu+I67TdLxRAy3mN7E5ox xLHcZWgf8= 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=QoXaGAGjPiyztsHRxhDbze VVT4DtyD/dR8ta86yYAH94MGCfZdFXiHzg1DVHi7fw5bPSQbQkMBEerYVoMQ7FZJ /B0t5KjSSYfvIw0ZF/VIKC80n3j+PSKqOIg7vBF+8LMVMiBY6/E5lD6aN4ca+wIV nIvRCsIBoRAr3FXD6t85U= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id EFF297F8; Mon, 25 Jul 2011 16:45:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id C2A121672689; Mon, 25 Jul 2011 16:45:58 +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 MceYFYZ9gPCZ; Mon, 25 Jul 2011 16:45:57 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (unknown [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id 614861672681; Mon, 25 Jul 2011 16:45:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <1D062974A4845E4D8A343C653804920205F72BF7@XMB-BGL-414.cisco.com> Date: Mon, 25 Jul 2011 10:45:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E123C54.10405@jdrosen.net><8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net><4E2D5C5D.6060402@alvestrand.no> <1D062974A4845E4D8A343C653804920205F72BF7@XMB-BGL-414.cisco.com> To: Muthu Arul Mozhi Perumal (mperumal) X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 16:12:02 -0000 On Jul 25, 2011, at 9:35 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > c) Using SDP for legacy interop, but extending STUN, by defining a > (comprehension optional) STUN attribute that indicates it is a > multiplexed media flow and that the SSRC space has been partitioned to > enable DPI. Since rtcweb apps are expected to use STUN, it should be > trivial for them to support this STUN attribute. In addition, the > software in on-path routers would have to be upgraded anyway to = support > this king of DPI, so they could also be enhanced to detect STUN and = look > for this attribute. Agree with Harald that this is a layering violation, but I would not be = averse to putting a hint in STUN for this, or indeed a hint in STUN (as = a non-mandatory attribute) saying that we're doing other RTCWEB things, = for devices that can only see the RTP/RTCP/STUN packets. That'd get yet another WG into the mix, of course. Matthew Kaufman= From jonathan@vidyo.com Mon Jul 25 10:34: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 5F65A5E800A for ; Mon, 25 Jul 2011 10:34:53 -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 bDkSkTHUBn4D for ; Mon, 25 Jul 2011 10:34:52 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id AC1765E8009 for ; Mon, 25 Jul 2011 10:34:49 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C53A3416DC8; Mon, 25 Jul 2011 13:34:48 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 51703416F0B; Mon, 25 Jul 2011 13:34:48 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 25 Jul 2011 13:34:45 -0400 From: Jonathan Lennox To: Colin Perkins Date: Mon, 25 Jul 2011 13:34:46 -0400 Thread-Topic: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt Thread-Index: AcxK8SX9sktW71+ARViHeCOAGFiRfQ== Message-ID: <7F46E1D2-5BF5-4E72-98F1-BD9CDFD08E68@vidyo.com> References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <32ADCB9C-8303-46B8-AE6B-CDE5772FFBA5@csperkins.org> In-Reply-To: <32ADCB9C-8303-46B8-AE6B-CDE5772FFBA5@csperkins.org> 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] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 17:34:53 -0000 On Jul 25, 2011, at 8:50 AM, Colin Perkins wrote: > On 24 Jul 2011, at 16:44, Matthew Kaufman wrote: >> 4. An RTP mixer would not be able to combine interleaved streams of >> incompatible media into one stream. >>=20 >> Not relevant to the RTCWEB peer-to-peer case as the browser is not an RT= P mixer. Also not relevant to any RTCWEB use cases that I can identify. And= , if an RTP mixer at one end it can simply not agree to use multiplexing. >=20 > This would work if you are directly talking to a mixer. It precludes the = cases where you are talking indirectly to a mixer via a gateway, unless you= define additional signalling to determine that there is a mixer on the rem= ote side of the gateway. Clearly, the gateway which is talking to the mixer needs to perform signali= ng negotiation with it, so it understands the RTP sessions at all, and so i= t will know if the mixer understands muxing or not. >> 5. Carrying multiple media in one RTP session precludes: the use of >> different network paths or network resource allocations if >> appropriate; >>=20 >> Appears to not be relevant to the RTCWEB case where a unicast path will = be negotiated using ICE. >=20 > An RTCWeb client using ICE could negotiate different network paths for th= e audio and video flows, and could use network-based QoS mechanisms, if flo= ws were sent separately. Those mechanisms work just fine in unicast. Yes, it could use these mechanisms, if they're appropriate. If it's not ap= propriate, it wouldn't need to. >> In all my reading today I have not been able to find anything more concr= ete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up if yo= u are aware of any other relevant specifications that would argue against u= sing SSRC to multiplex audio and video streams over a single RTP session be= tween a pair of compatible endpoints that agree to do so. [Quote from Colin's draft omitted] A lot of these are responses to the ideas of doing PT muxing, or muxing sev= eral distinct RTP sessions onto a single transport flow. They don't seem, = mostly, to be addressing muxing RTP audio and video sources onto a single (= proper) RTP session, i.e. with a single SSRC space, single (global) RTCP ba= ndwidth value, single value for RTCP timing intervals, etc. It's clearly the case that audio's share of 0.05 * (audio bw + video bw) is= going to be much greater than 0.05 * (audio bw), so you're going to be sen= ding audio RTCP a lot more frequently with mux'ed media than you would in a= n audio-only RTP session, whereas you'll send video RTCP slightly less freq= uently than a video-only session. But this isn't, as far as I can tell, a = problem, especially if you set a sensible value for trr_int (assuming AVPF)= . In SSRC-muxing, RTX and FEC require a way of binding together original and = repair streams, but RFC 5576 already defines a mechanism (ssrc-group) for d= oing this in SDP, and Magnus's SRCNAME proposal could alternately do it in = RTCP. I admit to not understanding the XRBlocks well enough to say whether it exp= ects to send VoIP feedback reports for every source in a session that it th= inks is audio, but presumably a monitoring device that's monitoring a VoIP = RTP session already needs to be told whether the session it's monitoring is= audio, video, or other, and would be able to (or have to) ignore a mux'd s= ession. -- Jonathan Lennox jonathan@vidyo.com From jonathan@vidyo.com Mon Jul 25 10:54: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 DE50921F8B93 for ; Mon, 25 Jul 2011 10:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMvdivlG034y for ; Mon, 25 Jul 2011 10:54:19 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6964A21F8B92 for ; Mon, 25 Jul 2011 10:54:19 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1B4227917E6; Mon, 25 Jul 2011 13:54:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9ECB879180D; Mon, 25 Jul 2011 13:54:18 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 25 Jul 2011 13:54:15 -0400 From: Jonathan Lennox To: "Muthu Arul Mozhi Perumal (mperumal)" Date: Mon, 25 Jul 2011 13:54:14 -0400 Thread-Topic: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt) Thread-Index: AcxK893u3EuF8nkbReyvJjOmufqtUA== Message-ID: <5C5B257E-CDBC-40AF-BB7F-E275585AE3B4@vidyo.com> References: <4E123C54.10405@jdrosen.net><8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net><4E2D5C5D.6060402@alvestrand.no> <4E2D5ED5.5060706@jitsi.org> <4E2D620F.5010003@jesup.org> <1D062974A4845E4D8A343C653804920205F72BDC@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920205F72BDC@XMB-BGL-414.cisco.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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-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, 25 Jul 2011 17:54:20 -0000 On Jul 25, 2011, at 8:57 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > A few options to indicate this multiplexing in SDP and being backward com= patible with legacy implementations: Unfortunately, I think the "correct" way to do this would be SDP media capa= bility negotiation -- you'd offer an alternative of either two m=3D lines (= one audio and one video), or else a single, mux'd m=3D line. Anything else= means that your SDP is, effectively, lying about what it's actually doing,= and I'm really worried about how that would interact with other SDP extens= ions. I'm certainly not crazy about this suggestion, though, because SDP Capabili= ty Negotiation is pretty ugly, and requires an additional offer/answer exch= ange to converge. For RTCWeb proper, the need not to have worry about compatibility with lega= cy implementations means that much of this could potentially be avoided. -- Jonathan Lennox jonathan@vidyo.com From stewe@stewe.org Mon Jul 25 12:26: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 14718228011 for ; Mon, 25 Jul 2011 12:26: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=[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 A-fPKIzCmeJr for ; Mon, 25 Jul 2011 12:26:04 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9222800F for ; Mon, 25 Jul 2011 12:26:03 -0700 (PDT) Received: from [192.168.1.108] (unverified [130.129.70.28]) by stewe.org (SurgeMail 3.9e) with ESMTP id 17252-1743317 for multiple; Mon, 25 Jul 2011 20:07:37 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 25 Jul 2011 14:03:49 -0700 From: Stephan Wenger To: Magnus Westerlund Message-ID: Thread-Topic: [rtcweb] How to multiplex between peers In-Reply-To: <4E2D45D0.5050103@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 130.129.70.28 X-Authenticated-User: stewe@stewe.org Cc: Jonathan Lennox , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] How to multiplex between peers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Jul 2011 19:26:05 -0000 Hi Magnus, On 7.25.2011 03:30 , "Magnus Westerlund" wrote: >[...] > >> >> That said, if I'm not completely mistaken, you can implement the >> multiparty use cases using the "RTCP terminating MCU" topology of RFC >> 5117. This is common implementation practice in video conferencing. If >> you do so, the multiparty support of RTPv2 is neither exercised nor >>needed >> in a multiparty video conference. > >First of all if you do that you loose functionality as discussed in RFC >5117. For example the indication of who actually sent a packet >originally or contribute to the mix can't be provided unless you let the >SSRC or CSRC plus CNAMES be forwarded across the Mixer/MCU. Correct. So what? There is such a thing as a signaling plane. In all practical commercial systems I'm aware of, the signaling plane information is the ONLY information that is used for the identification of participants (including mixed participants). Unfortunately, this information is most often conveyed using nonstandard means. No one in video conferencing that I'm aware of relies on the SSRC/CSRC + CNAME mechanism. Let me know if I'm wrong. I'm not saying that this design choice is necessarily the best possible for rtcweb. But I'm claiming that the practical implementation experience speaks in favor of it. So the burden of proof of requiring its use (which may break other aspects that have been identified by many here as critical, such as minimizing the number of ports), should be on you, not on me. =20 >In addition it forces the central unit into one particular >implementation, instead of allowing to use what it most appropriate. > >An RTP mixer when you want something that has functionality and >application enhancing behavior and the cost is more complexity. > >Or you use an relay which simply copies a packet from one entity to all >the others. That is the simplest central node you can build and it will >have no media processing at all. Sorry, I wasn't able to follow this train of thought. If this was related to implementation complexity of media plane signaling of mixed media streams vs. signaling plane signaling of similar information, I would argue that the majority of the implementers, so far, appear to have sided with signaling plane rather than media plane=8A I'm sure that they had a reason. =20 > >Also, in any gateway case to existing legacy you don't want to have to >implement additional gatewaying functions just because one want to use >non standard RTP. That's also my understanding. Is it strong enough an argument, given the (many, I believe) other issues a gateway may need to worry about? > >For me it is clear that ensuring that RTCWEBs RTP usage is vanilla will >help us avoid a lot of problems down the road. I'm arguing the same thing as you, but we define "vanilla" differently. You seem to define it as "use of RTP as specified in both language and intent of the standard, and following the 1990 generation of understanding of the standard". I define it "use RTP in the way it has been implemented in the industry relevant here (video conferencing industry) over the last decade or so." > >If we are going to multiplex this mechanism needs to have a behavior >that doesn't change the core behaviors of RTP. If we can do that the >multiplexing becomes much less a hot topic. > Again, we agree, perhaps except for the interpretation of "core behavior". In my view, "core behavior" does not include mechanisms such as CC, CSRC, as they are AFAIK not practiced in most real-world systems. It may include, though, include mechanisms such as SSRC multiplexing, as this mechanism IS deployed in millions of systems, with no known adverse effects on the operation of the Internet as a whole, or the RTPish things that are part of the Internet. Cheers, Stephan =20 > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From henry.sinnreich@gmail.com Mon Jul 25 18:40: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 04B5011E8098 for ; Mon, 25 Jul 2011 18:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=0.662, 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 Ja5qGY91TWIU for ; Mon, 25 Jul 2011 18:40:52 -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 790DF11E8071 for ; Mon, 25 Jul 2011 18:40:52 -0700 (PDT) Received: by ywp31 with SMTP id 31so3020808ywp.31 for ; Mon, 25 Jul 2011 18:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=2tbMcevEBxXISMaLjJ9fKD32p3fbt1qftVMOh1PELHE=; b=uAbBQkpS+zdL3sAWY4XxKeD0StLYGfvJS+wZxq20w8iaKSAV6G/pdPgwB40B2w9g5X 3Xljga6OkcvKF1/xy9aLAY5qBX/ppI/E0f72YI3JYBYAPVCgjf6ybG/SxajrpFyn+Uwa s9XyMDIPiRNnKlnq/pbYoTQ3un+Xi0KxUwk0k= Received: by 10.236.182.225 with SMTP id o61mr6796589yhm.257.1311644451723; Mon, 25 Jul 2011 18:40:51 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-164.tx.res.rr.com [76.184.227.164]) by mx.google.com with ESMTPS id j9sm2505760yhn.39.2011.07.25.18.40.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 18:40:50 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 25 Jul 2011 20:40:48 -0500 From: Henry Sinnreich To: Harald Alvestrand , Message-ID: Thread-Topic: Back to the drawing board? Thread-Index: AcxLNQswVus5nHSUA0i1wO1spcgZQg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [rtcweb] Back to the drawing board? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 01:40:53 -0000 On Jul 25, 2011, at 8:06 AM, Harald Alvestrand wrote: > An RTP session with both "audio" and "video" media types cannot be > represented by an SDP description, since SDP ties RTP sessions 1-1 to the "m" > line of the description, which contains the top-level type, and the codec > descriptions omit the top-level type in their codec naming. > > I've said elsewhere that I consider this to be a design mistake for entirely > different reasons, but this debate has reinforced my opinion that it is. This about sums it up why both SDP and RTP from VoIP of the early 1990's is just not adequate. There are plenty of better solutions, such as metadata standards for the app description data to replace stale SDP and app level framing over UDP for RT media to replace RTP (a protocol build with media mixing intermediaries/servers in mind). Solutions without both SDP and RTP are widely deployed in dominant Internet and Web RT communications products, albeit proprietary. And we want a standard instead. Avoiding telephony style VoIP and telecom multimedia usage scenarios and their associated protocols is required to produce a successful standard for webrtc, much preferable to the dominant proprietary products of today, excellent as they may be. Back to the drawing board? It is not too late. Thanks, Henry From Ranjit.Avasarala@Polycom.com Mon Jul 25 22:28: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 9085D21F8853 for ; Mon, 25 Jul 2011 22:28: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 k3CxaidQGlOV for ; Mon, 25 Jul 2011 22:28:58 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id D0F8A21F884E for ; Mon, 25 Jul 2011 22:28:57 -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; Tue, 26 Jul 2011 13:28:56 +0800 From: "Avasarala, Ranjit" To: "rtcweb@ietf.org" Date: Tue, 26 Jul 2011 13:28:54 +0800 Thread-Topic: Support for websockets Thread-Index: AcxHagwuIQJzP4FkTo6IV577gJ8GDwD6rpJg Message-ID: <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> In-Reply-To: <4E27BE02.7090606@ericsson.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: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 05:28:58 -0000 Hi all By when can we expect WebRTC code (Google code) to support Websockets? Regards Ranjit From ekr@rtfm.com Tue Jul 26 03:34: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 6CA2721F8BE6 for ; Tue, 26 Jul 2011 03:34:01 -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=[AWL=-0.000, 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 LtjsgdmV9HAe for ; Tue, 26 Jul 2011 03:34:00 -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 915A421F8B68 for ; Tue, 26 Jul 2011 03:34:00 -0700 (PDT) Received: by wyj26 with SMTP id 26so68289wyj.31 for ; Tue, 26 Jul 2011 03:33:59 -0700 (PDT) Received: by 10.227.196.208 with SMTP id eh16mr4847995wbb.37.1311676439092; Tue, 26 Jul 2011 03:33:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Tue, 26 Jul 2011 03:33:39 -0700 (PDT) From: Eric Rescorla Date: Tue, 26 Jul 2011 06:33:39 -0400 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 10:34:01 -0000 Sorry, sent to wrong list so some of you may not have it. Hi Folks, This is very late, but here is my attempted summary of the discussion about COMSEC choices at the interim. I'm not saying that this captures everyone's position, but the following positions are the ones that in my view have significant levels of support. Alternative A: [DTLS MUST, NO SDES, NO RTP] An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for media, without support for either SRTP with supplied keying material (SDES-style) AND plain RTP. DTLS-SRTP provides for end-to-end key negotation between the two RTCWEB clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection profile and the DTLS cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA in that it mandates support for Diffie-Hellman key exchange in order to provide Perfect Forward Secrecy. An RTCWEB client MUST provide its user with the ability to to see keying material information sufficient to allow indepent verification of their peer's identity. (REF draft-kaufman-rtcweb-security-ui). The primary drawback of this alternative is the lack of backwards compatibility with devices and software that only support plain RTP, but the requirement for a handshake makes interoperation with these devices not completely trivial anyway. Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST] An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP provides for end-to-end key negotation between the two RTCWEB clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection profile and the DTLS cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA in that it mandates support for Diffie-Hellman key exchange in order to provide Perfect Forward Secrecy. This MUST be the default mode of operation. An RTCWEB client MAY support SRTP with the keying material supplied via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80 protection profile. In the case of a web browser client, the keying material should be supplied via a Javascript API. DTLS-SRTP, with its end-to-end keying and authentication capability is preferred over SDES-style [RFC4568] keying. However, the additional API overhead required to add support for a way to force a particular key is low. In addition, once plain RTP is to be supported the arguments against the lower security level provided by SDES-style keying are no longer relevant. Also there are a small number of potential use cases where interoperability with existing SDES-keyed software or devices may be achieved if the RTCWEB endpoint supports this mode of keying. An RTCWEB client MUST support RTP. This provides no privacy but maximizes interoperability. Note that SRTP with a Null cipher has equivalent security but does not meet the interoperability requirement. Plain RTP provides no protection for the media, and so is discouraged as a mode of operation for RTCWEB. However, support for RTP is required in order to provide interoperability with legacy RTP devices and software that do not support encryption. In addition, some use cases such as high-volume PSTN or PBX gateways within an organization may scale more readily without the overhead of media encryption. An RTCWEB client MUST provide its user with the ability to know whether or not the media they are sending is protected by encryption and with the ability to see keying material information sufficient to allow indepent verification of their peer's identity. (REF draft-kaufman-rtcweb-security-ui). Note that this user interface element is much more critical---and hence much more problematic than with alternative A. If DTLS-SRTP is always used, then the user knows what security mechanisms are provided. As soon as multiple alternatives with widely varying security (or no security in the case of RTP) are provided, then users need to actually verify that the security level is satisfactory, which is inherently problematic given typical user behavior. I expect to leave time for discussion of this during my slot tomorrow. I look forward to a good discussion. Best, -Ekr From harald@alvestrand.no Tue Jul 26 05:50: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 557C821F8C52 for ; Tue, 26 Jul 2011 05:50:50 -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 KBwmKlH9+eZs for ; Tue, 26 Jul 2011 05:50:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96421F8B72 for ; Tue, 26 Jul 2011 05:50:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C39AD39E091 for ; Tue, 26 Jul 2011 14:49:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G9Ld2wOqz1A for ; Tue, 26 Jul 2011 14:49:39 +0200 (CEST) Received: from [130.129.103.155] (unknown [130.129.103.155]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A7F5F39E082 for ; Tue, 26 Jul 2011 14:49:39 +0200 (CEST) Message-ID: <4E2EB82C.30709@alvestrand.no> Date: Tue, 26 Jul 2011 08:50:52 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> In-Reply-To: <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> Content-Type: multipart/alternative; boundary="------------010501050708030800080804" Subject: Re: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 12:50:50 -0000 This is a multi-part message in MIME format. --------------010501050708030800080804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/26/11 01:28, Avasarala, Ranjit wrote: > Hi all > > By when can we expect WebRTC code (Google code) to support Websockets? Implementation issues with the Google WebRTC code should be addressed to the Google WebRTC implementation support mailing list: discuss-webrtc@googlegroups.com In this forum, it may be appropriate to describe exactly how you see Websockets fitting in with the RTCWEB specification suite; so far, it's seemed to be not very closely related. > Regards > Ranjit > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------010501050708030800080804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/26/11 01:28, Avasarala, Ranjit wrote: 
Hi all

By when can we expect WebRTC code (Google code) to support Websockets?
Implementation issues with the Google WebRTC code should be addressed to the Google WebRTC implementation support mailing list: discuss-webrtc@googlegroups.com

In this forum, it may be appropriate to describe exactly how you see Websockets fitting in with the RTCWEB specification suite; so far, it's seemed to be not very closely related.
 
Regards
Ranjit
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------010501050708030800080804-- From bernard_aboba@hotmail.com Tue Jul 26 06:18: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 2D83B21F893C for ; Tue, 26 Jul 2011 06:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.914 X-Spam-Level: X-Spam-Status: No, score=-100.914 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_40=-0.185, 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 DEV2fC3-64aI for ; Tue, 26 Jul 2011 06:18:34 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB3D21F889F for ; Tue, 26 Jul 2011 06:18:34 -0700 (PDT) Received: from BLU152-W7 ([65.55.116.73]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 06:18:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6e70b9bb-0ed5-4ee1-bfbd-2e76a0c99498_" X-Originating-IP: [130.129.18.21] From: Bernard Aboba To: Date: Tue, 26 Jul 2011 06:18:29 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jul 2011 13:18:30.0257 (UTC) FILETIME=[830A4E10:01CC4B96] Subject: Re: [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: Tue, 26 Jul 2011 13:18:35 -0000 --_6e70b9bb-0ed5-4ee1-bfbd-2e76a0c99498_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Do we have minutes of the meeting available? Cullen Jennings said: Here are the recordings from the last interim meeting. The first half of th= e 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 wi= ll 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 = --_6e70b9bb-0ed5-4ee1-bfbd-2e76a0c99498_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] Do we have minutes of the meeting available?

Cullen Jennin=
gs said:

Here are the recordings from the last interim meeting. The =
first half of the meeting before the break is in the "PartA" files while th=
e 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 wi=
ndows 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


= --_6e70b9bb-0ed5-4ee1-bfbd-2e76a0c99498_-- From ted.ietf@gmail.com Tue Jul 26 06:30: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 9E59A21F8C37 for ; Tue, 26 Jul 2011 06:30:06 -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=[AWL=-0.000, 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 c5j50Y3zBIcl for ; Tue, 26 Jul 2011 06:30:05 -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 AAF8E21F8C2E for ; Tue, 26 Jul 2011 06:30:05 -0700 (PDT) Received: by yxp4 with SMTP id 4so314845yxp.31 for ; Tue, 26 Jul 2011 06:30:05 -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=iZH5pJg7ag2ct//XIgyJl3XC9OXUHM742tUJTqEodbg=; b=cxbY8ELud+rR8SOkxiYytsBkmr3Zey3i2jsMBKDh0Ua38Tj9RcvvhTIqjGDClJvx9b 739LYVyDWjOeBMreje2/mUQS8gS0V28N/FCay2NKxwQVXRjS5xfQ+B8ErEw+lSSdr8bz lp+krJ9LGC9qNFNdSGVvlhvL2qpXSgekk2sik= MIME-Version: 1.0 Received: by 10.236.154.169 with SMTP id h29mr7569495yhk.279.1311687003572; Tue, 26 Jul 2011 06:30:03 -0700 (PDT) Received: by 10.236.105.133 with HTTP; Tue, 26 Jul 2011 06:30:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jul 2011 09:30:03 -0400 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf303f671ae787f304a8f8edf8 Cc: rtcweb@ietf.org Subject: Re: [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: Tue, 26 Jul 2011 13:30:06 -0000 --20cf303f671ae787f304a8f8edf8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You should find them in the proceedings. See: http://www.ietf.org/proceedings/80/interim/rtcweb-interim-2011-06-08.txt regards, Ted On Tue, Jul 26, 2011 at 9:18 AM, Bernard Aboba w= rote: > [BA] Do we have minutes of the meeting available? > > Cullen Jennings said: > > 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 wi= ll probably do better with the .mp4 files. > http://dl.dropbox.com/u/17089001/IETF-RTCWeb-80.5-PartA.movhttp://dl.drop= box.com/u/17089001/IETF-RTCWeb-80.5-PartA.mp4 > http://dl.dropbox.com/u/17089001/IETF-RTCWeb-80.5-partB.movhttp://dl.drop= box.com/u/17089001/IETF-RTCWeb-80.5-partB.mp4 > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf303f671ae787f304a8f8edf8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You should find them in the proceedings. =A0See:

regards,

Ted
=
On Tue, Jul 26, 2011 at 9:18 AM, Bernard Abo= ba <bernard_aboba@hotmail.com> wrote:
[BA] Do we have minutes of the meeting available?

Cullen Jennin=
gs said:

Here are the recordings from the last interim meeting. The =
first half of the meeting before the break is in the "PartA" file=
s while the second half of the meeting after the break is in the "Part=
B" 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-RTCWe=
b-80.5-PartA.mov
http://dl.dropbox.com/u/17089001/IETF-RTCWe=
b-80.5-PartA.mp4

http://dl.dropbox.com/u/17089001/IETF-RTCWe=
b-80.5-partB.mov
http://dl.dropbox.com/u/17089001/IETF-RTCWe=
b-80.5-partB.mp4



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


--20cf303f671ae787f304a8f8edf8-- From D.Malas@cablelabs.com Tue Jul 26 06: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 7FB2D21F8BB9 for ; Tue, 26 Jul 2011 06:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 WrCh9qFtORMx for ; Tue, 26 Jul 2011 06:58:04 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B933F21F884F for ; Tue, 26 Jul 2011 06:58:04 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p6QDw2FC011296; Tue, 26 Jul 2011 07:58:02 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 26 Jul 2011 07:58:02 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 26 Jul 2011 07:58:03 -0600 From: Daryl Malas To: Eric Rescorla , "rtcweb@ietf.org" Date: Tue, 26 Jul 2011 07:58:01 -0600 Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying Thread-Index: AcxLnAlVbogs3HaWSNKjH3eaee65xQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 13:58:05 -0000 Ekr et al, I support Alternative B, and the reason is the support for plain RTP. My first reaction was Alternative A, and someone would be foolish to use plain RTP over the Internet (unless they live in Hollywood and love to have their phone calls recorded and played back on TMZ). I think some enterprises will want this level of support for interoperability with their "older" IP-PBX/Media Gateway, and they will require their users to use a VPN for using the web application within the enterprise (assuming a enterprise web application for remote users), hence encrypting the media anyway. This will save them on additional costs they don't want to incur for encryption/decryption. Regards, Daryl On 7/26/11 6:33 AM, "Eric Rescorla" wrote: >Sorry, sent to wrong list so some of you may not have it. > >Hi Folks, > >This is very late, but here is my attempted summary of the discussion >about COMSEC choices at the interim. I'm not saying that this captures >everyone's position, but the following positions are the ones that in >my view have significant levels of support. > > >Alternative A: [DTLS MUST, NO SDES, NO RTP] > > An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for > media, without support for either SRTP with supplied keying > material (SDES-style) AND plain RTP. DTLS-SRTP provides for > end-to-end key negotation between the two RTCWEB clients. The > client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection > profile and the DTLS cipher suite > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA > in that it mandates support for Diffie-Hellman key exchange in > order to provide Perfect Forward Secrecy. > > An RTCWEB client MUST provide its user with the ability to to see > keying material information sufficient to allow indepent > verification of their peer's identity. (REF > draft-kaufman-rtcweb-security-ui). > > The primary drawback of this alternative is the lack of backwards > compatibility with devices and software that only support plain > RTP, but the requirement for a handshake makes interoperation with > these devices not completely trivial anyway. > > > >Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST] > > An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP > provides for end-to-end key negotation between the two RTCWEB > clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 > protection profile and the DTLS cipher suite > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA > in that it mandates support for Diffie-Hellman key exchange in > order to provide Perfect Forward Secrecy. This MUST be the default > mode of operation. > > An RTCWEB client MAY support SRTP with the keying material supplied > via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80 > protection profile. In the case of a web browser client, the > keying material should be supplied via a Javascript API. > DTLS-SRTP, with its end-to-end keying and authentication capability > is preferred over SDES-style [RFC4568] keying. However, the > additional API overhead required to add support for a way to force > a particular key is low. In addition, once plain RTP is to be > supported the arguments against the lower security level provided > by SDES-style keying are no longer relevant. Also there are a > small number of potential use cases where interoperability with > existing SDES-keyed software or devices may be achieved if the > RTCWEB endpoint supports this mode of keying. > > An RTCWEB client MUST support RTP. This provides no privacy but > maximizes interoperability. Note that SRTP with a Null cipher has > equivalent security but does not meet the interoperability > requirement. Plain RTP provides no protection for the media, and > so is discouraged as a mode of operation for RTCWEB. However, > support for RTP is required in order to provide interoperability > with legacy RTP devices and software that do not support > encryption. In addition, some use cases such as high-volume PSTN > or PBX gateways within an organization may scale more readily > without the overhead of media encryption. > > An RTCWEB client MUST provide its user with the ability to know > whether or not the media they are sending is protected by encryption > and with the ability to see keying material information sufficient > to allow indepent verification of their peer's identity. > (REF draft-kaufman-rtcweb-security-ui). Note that this user > interface element is much more critical---and hence much more > problematic than with alternative A. If DTLS-SRTP is always > used, then the user knows what security mechanisms are provided. > As soon as multiple alternatives with widely varying security > (or no security in the case of RTP) are provided, then users > need to actually verify that the security level is satisfactory, > which is inherently problematic given typical user behavior. > >I expect to leave time for discussion of this during my slot tomorrow. >I look forward to a good discussion. > >Best, >-Ekr >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Tue Jul 26 07:53: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 9896711E80CC for ; Tue, 26 Jul 2011 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 pEsA1BlmjpDv for ; Tue, 26 Jul 2011 07:53: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 B12D311E80C1 for ; Tue, 26 Jul 2011 07:53:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-98-4e2ed4f46345 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 05.20.20773.4F4DE2E4; Tue, 26 Jul 2011 16:53:40 +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, 26 Jul 2011 16:53:40 +0200 Message-ID: <4E2ED4F0.10809@ericsson.com> Date: Tue, 26 Jul 2011 10:53:36 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] IETF 81 Tuesday meeting material X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 14:53:42 -0000 Hi, All meeting material for today's session is now available: https://datatracker.ietf.org/meeting/81/materials.html Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ietf@meetecho.com Tue Jul 26 09:07: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 270CD11E80D8 for ; Tue, 26 Jul 2011 09:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXKi8a15XlGW for ; Tue, 26 Jul 2011 09:07:06 -0700 (PDT) Received: from smtplqs02.aruba.it (smtplqs-out48.aruba.it [62.149.158.88]) by ietfa.amsl.com (Postfix) with SMTP id 1BB3811E807B for ; Tue, 26 Jul 2011 09:07:05 -0700 (PDT) Received: (qmail 22326 invoked by uid 89); 26 Jul 2011 16:07:02 -0000 Received: from unknown (HELO smtpw2.aruba.it) (62.149.128.188) by smtplqs02.aruba.it with SMTP; 26 Jul 2011 16:07:02 -0000 Received: (qmail 19225 invoked by uid 89); 26 Jul 2011 16:07:02 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 26 Jul 2011 16:07:02 -0000 Date: Tue, 26 Jul 2011 18:07:02 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: rtcweb@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs02.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] Meetecho support for RTCWEB WG meeting session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 16:07:07 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system. =0A= =0AAccess to the on-line session (including audio and video streams) will= be available from 12:50 at:=0Ahttp://www.meetecho.com/ietf81/rtcweb=0A=0A= The Meetecho session automatically logs you into the standard IETF jabber= room. So, from there, you can have an integrated experience involving al= l media and allowing you to interact with the room.=0A=0AA tutorial of in= teractivity features of the tool can be found at:=0Ahttp://www.meetecho.c= om/ietf81/tutorials=0A=0AFor further information you can contact us at ie= tf-support@meetecho.com.=0A=0ACheers,=0Athe Meetecho Team From mperumal@cisco.com Tue Jul 26 09:25: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 B6DE621F88A0 for ; Tue, 26 Jul 2011 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJQluxG8KV7J for ; Tue, 26 Jul 2011 09:25:22 -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 867EB21F889F for ; Tue, 26 Jul 2011 09:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2962; q=dns/txt; s=iport; t=1311697522; x=1312907122; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=HdIoz8fVfmxUPPJfyf7jWqsx6dtO7WogXdE/lPjnQKU=; b=YH/L8VY6RFqvSOBU0jh1Nj1dMQkk9xjenJvpwdLSqADO2dGkuvhIkW/f rwBe69RqBmD1YSRtp5gGqYAOuH3O3ax0sHDJNj1r8t1IVTmTAN73QBTl+ pyDt8BudptXNgp/JAKv/31p0iHSLODm6ppB6enBj9ztjscEEBjxkAkyZ3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAEPqLk5Io8UR/2dsb2JhbAA2AQEBAQMUASEKRQwFAgEJEQQBAQsGHwQBBgETOw4IAQEFDAsMG5dUj1p3rB2eZYVhXwSHVZAti1g X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="104396142" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 26 Jul 2011 16:25:19 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QGPIke012373; Tue, 26 Jul 2011 16:25:18 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 21:55:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 21:55:14 +0530 Message-ID: <1D062974A4845E4D8A343C653804920205F72F7B@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt) Thread-Index: AcxK2Z4HiCeprPBrSK+zmam2QTyx4QAzFDSw References: <4E123C54.10405@jdrosen.net><8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net><4E2D5C5D.6060402@alvestrand.no> <1D062974A4845E4D8A343C653804920205F72BF7@XMB-BGL-414.cisco.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Matthew Kaufman" X-OriginalArrivalTime: 26 Jul 2011 16:25:17.0693 (UTC) FILETIME=[9B3152D0:01CC4BB0] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 16:25:23 -0000 First refinement: Define a new SDP attribute "a=3Dmuxed-candidate" that is similar to the "a=3Dcandidate" attribute defined by ICE, except that the same muxed-candidate can appear under multiple media stream descriptions in SDP. The muxed-candidate identifies the transport address where the RTCWEB endpoint would like to receive all these (multiplexed) media streams. Non-RTCWEB endpoints would ignore this attribute. Define a new comprehension-optional STUN attribute MUXED-CANDIDATE (similar to the USE-CANDIDATE attribute). This attribute has no content (the Length field of the attribute is zero) -- it serves as a flag. It has an attribute value of 0x802C (the first unassigned value from the first half of the comprehension-optional range). It can be present in the STUN connectivity check(s) sent when ICE concludes (i.e those STUN Binding requests that contain the USE-CANDIDATE attribute) and serves as an indication to routers and firewalls that any media stream that flows between the selected pair of candidates is a multiplexed media stream -- for RTP it means that the SSRC space has been partitioned as described in draft-rosenberg-rtcweb-rtpmux to enable DPI. IMO, this isn't a layer violation per se, since we aren't carrying any RTP stuff in STUN, rather just providing an indication for a particular RTP usage. Once issue, though -- comprehension-optional STUN attribute aren't protected by STUN MESSAGE-INTEGRITY. So, MUXED-CANDIDATE would have to protect itself or a new comprehension-optional STUN needs to be defined that protects other comprehension-optional STUN attributes. Muthu |-----Original Message----- |From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] |Sent: Monday, July 25, 2011 8:16 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: Harald Alvestrand; rtcweb@ietf.org |Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg- |rtcweb-rtpmux-00.txt) | | |On Jul 25, 2011, at 9:35 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: | |> c) Using SDP for legacy interop, but extending STUN, by defining a |> (comprehension optional) STUN attribute that indicates it is a |> multiplexed media flow and that the SSRC space has been partitioned to |> enable DPI. Since rtcweb apps are expected to use STUN, it should be |> trivial for them to support this STUN attribute. In addition, the |> software in on-path routers would have to be upgraded anyway to support |> this king of DPI, so they could also be enhanced to detect STUN and look |> for this attribute. | |Agree with Harald that this is a layering violation, but I would not be averse to putting a hint in |STUN for this, or indeed a hint in STUN (as a non-mandatory attribute) saying that we're doing other |RTCWEB things, for devices that can only see the RTP/RTCP/STUN packets. | |That'd get yet another WG into the mix, of course. | |Matthew Kaufman From matthew.kaufman@skype.net Tue Jul 26 10:49: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 3D9FA21F8987 for ; Tue, 26 Jul 2011 10:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZTgIvo14zQc for ; Tue, 26 Jul 2011 10:49:36 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 73FF421F893E for ; Tue, 26 Jul 2011 10:49:36 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 980FE170E for ; Tue, 26 Jul 2011 19:49:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=from :content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; s=mx; bh=aD+VDgGa4K/hhcLR8IDZr0YHgs8=; b=OzKbo TepxiYIdP+Z7nA/+2xxPX+7zq01BEltTeLdPF3sCuQyzZOUO3bKKbZ5pt2obsD84 cZ8+/bNqqkKJfGuJ6yDSk4qqSfZVPz6Qo4eA/0EomokeTit/Sf1kxtF0L3KP78pm xJE9v5p+xHz/tPOccBU6gWNryckEQXG2xTgGbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=from:content-type :content-transfer-encoding:subject:date:message-id:to: mime-version; q=dns; s=mx; b=eZ37t8owHwwh/vn4qv0ws3V7iIVoFdGRBg+ Kvm2NtRaZXSyYHKdyvSofShZQ4TSL1/pcf9WxyAd+oEeDnoJpWO23ZbDy5B84YHk lEsYbeHhZKN23z8fy+VcODqqTK7qGIyoe7A+3Mg/V7CnFtW1+pHP50D6jphVWYDk oOkWWOyk= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 96C097F6 for ; Tue, 26 Jul 2011 19:49:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7963D3507F30 for ; Tue, 26 Jul 2011 19:49: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 noYMKqDXbkea for ; Tue, 26 Jul 2011 19:49:33 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (unknown [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id A85183507AC3 for ; Tue, 26 Jul 2011 19:49:33 +0200 (CEST) From: Matthew Kaufman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 13:49:31 -0400 Message-Id: <6FC8E819-F05B-48E7-A488-24F675C9E0CD@skype.net> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [rtcweb] NAT / firewall use cases X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 17:49:37 -0000 We have something in there with a NAT... but I don't think we have a use = case that covers the situation where one or both users is behind a NAT = or firewall that blocks UDP entirely (which fortunately also covers some = of the NAT cases where ICE doesn't succeed). This would require media = over TCP... something that I believe some of the implementations have = already tackled in different ways, but there's no use case and no drafts = proposing which solution to choose either. Matthew Kaufman= From ron.even.tlv@gmail.com Tue Jul 26 10:51: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 E84E921F8A96 for ; Tue, 26 Jul 2011 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=2.631, 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 amY1YbbhJJDo for ; Tue, 26 Jul 2011 10:51:03 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB2BA21F8A91 for ; Tue, 26 Jul 2011 10:50:57 -0700 (PDT) Received: by gwb20 with SMTP id 20so541532gwb.31 for ; Tue, 26 Jul 2011 10:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=goJXulJMluUCnP2FFRw5L0rdQgQnGzPK6GCH3GmlBIU=; b=taXjbSZtoOZzkieD7A8COAmmCidgEAgpZ9bS130zQucAg+fkFjIsYipQVozvmFgklG DdH0OS5RQsLNVUjP0SASsLs/SSc8zTYq43Zi1KUutv63uuk6kOZSH32F64I+X4qqfwlj x497/hIZSaWNB6nIfjNUd/W+U02fqh99l4Itc= Received: by 10.68.44.129 with SMTP id e1mr10230151pbm.113.1311702655228; Tue, 26 Jul 2011 10:50:55 -0700 (PDT) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by mx.google.com with ESMTPS id i9sm780191pbk.36.2011.07.26.10.50.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 10:50:54 -0700 (PDT) From: "Roni Even" To: Date: Tue, 26 Jul 2011 20:48:13 +0300 Message-ID: <4e2efe7e.c926440a.7012.4a6e@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01CC4BD5.57E870B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcxLvDB7q7Dcgn5JSsS0ApveiFoLpw== Content-Language: en-us Subject: [rtcweb] use cases for realtime communications in other WGs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 17:51:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01CC4BD5.57E870B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, For other IETF WG use cases: The CLUE WG is working on use-cases for high quality video conferencing (telepresence) it may be interesting to the use cases in RTCweb http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-01 On conferencing requirements and scenarios done in SIPPING and XCON WGs are in http://tools.ietf.org/html/rfc4245 and http://tools.ietf.org/html/rfc4597 Roni Even ------=_NextPart_000_0034_01CC4BD5.57E870B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

For other IETF = WG use cases:

 

The CLUE WG is working on use-cases for high quality = video conferencing (telepresence) it may be interesting to the use cases = in RTCweb

http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-01=

 

On conferencing requirements and scenarios done in = SIPPING and XCON WGs are in http://tools.ietf.org/html/rf= c4245 and http://tools.ietf.org/html/rf= c4597

 

Roni Even

------=_NextPart_000_0034_01CC4BD5.57E870B0-- From bernard_aboba@hotmail.com Tue Jul 26 11:24: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 C8EF221F8696 for ; Tue, 26 Jul 2011 11:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.156 X-Spam-Level: X-Spam-Status: No, score=-101.156 tagged_above=-999 required=5 tests=[AWL=-0.416, 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 SGRVHE6b-zoa for ; Tue, 26 Jul 2011 11:24:25 -0700 (PDT) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2971321F8686 for ; Tue, 26 Jul 2011 11:24:25 -0700 (PDT) Received: from BLU0-SMTP93 ([65.55.116.74]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 11:24:24 -0700 X-Originating-IP: [130.129.19.47] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Received: from localhost ([130.129.19.47]) by BLU0-SMTP93.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 11:24:24 -0700 Date: Tue, 26 Jul 2011 14:24:24 -0400 From: Bernard Aboba To: Matthew Kaufman , rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 26 Jul 2011 18:24:24.0303 (UTC) FILETIME=[3EE777F0:01CC4BC1] Subject: Re: [rtcweb] NAT / firewall use cases X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 18:24:25 -0000 VGhpcyBpcyBpbmRlZWQgYSByZWFsIHVzZSBjYXNlLgoKTWF0dGhldyBLYXVmbWFuIDxtYXR0aGV3 LmthdWZtYW5Ac2t5cGUubmV0PiB3cm90ZToKCj5XZSBoYXZlIHNvbWV0aGluZyBpbiB0aGVyZSB3 aXRoIGEgTkFULi4uIGJ1dCBJIGRvbid0IHRoaW5rIHdlIGhhdmUgYSB1c2UgY2FzZSB0aGF0IGNv dmVycyB0aGUgc2l0dWF0aW9uIHdoZXJlIG9uZSBvciBib3RoIHVzZXJzIGlzIGJlaGluZCBhIE5B VCBvciBmaXJld2FsbCB0aGF0IGJsb2NrcyBVRFAgZW50aXJlbHkgKHdoaWNoIGZvcnR1bmF0ZWx5 IGFsc28gY292ZXJzIHNvbWUgb2YgdGhlIE5BVCBjYXNlcyB3aGVyZSBJQ0UgZG9lc24ndCBzdWNj ZWVkKS4gVGhpcyB3b3VsZCByZXF1aXJlIG1lZGlhIG92ZXIgVENQLi4uIHNvbWV0aGluZyB0aGF0 IEkgYmVsaWV2ZSBzb21lIG9mIHRoZSBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBhbHJlYWR5IHRhY2ts ZWQgaW4gZGlmZmVyZW50IHdheXMsIGJ1dCB0aGVyZSdzIG5vIHVzZSBjYXNlIGFuZCBubyBkcmFm dHMgcHJvcG9zaW5nIHdoaWNoIHNvbHV0aW9uIHRvIGNob29zZSBlaXRoZXIuCj4KPk1hdHRoZXcg S2F1Zm1hbgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K PnJ0Y3dlYiBtYWlsaW5nIGxpc3QKPnJ0Y3dlYkBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIKPgo= From emcho@sip-communicator.org Tue Jul 26 11:31: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 4AB7821F8A91 for ; Tue, 26 Jul 2011 11:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.016 X-Spam-Level: X-Spam-Status: No, score=-3.016 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 FRiUtdTpYrUz for ; Tue, 26 Jul 2011 11:31:55 -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 9BDBA21F8A80 for ; Tue, 26 Jul 2011 11:31:55 -0700 (PDT) Received: by vws12 with SMTP id 12so673496vws.31 for ; Tue, 26 Jul 2011 11:31:55 -0700 (PDT) Received: by 10.52.110.103 with SMTP id hz7mr5236522vdb.313.1311705115038; Tue, 26 Jul 2011 11:31:55 -0700 (PDT) Received: from mail-vx0-f172.google.com ([209.85.220.172]) by mx.google.com with ESMTPS id cg6sm359075vdc.17.2011.07.26.11.31.53 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 11:31:54 -0700 (PDT) Received: by vxi40 with SMTP id 40so697260vxi.31 for ; Tue, 26 Jul 2011 11:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.72 with SMTP id ha8mr5491698vdb.455.1311705112788; Tue, 26 Jul 2011 11:31:52 -0700 (PDT) Received: by 10.52.157.8 with HTTP; Tue, 26 Jul 2011 11:31:52 -0700 (PDT) Received: by 10.52.157.8 with HTTP; Tue, 26 Jul 2011 11:31:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jul 2011 20:31:52 +0200 Message-ID: From: Emil Ivov To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec547c74b4c3d9a04a8fd25dd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] NAT / firewall use cases X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 18:31:56 -0000 --bcaec547c74b4c3d9a04a8fd25dd Content-Type: text/plain; charset=ISO-8859-1 +1 Emil -- sent from my mobile On Jul 26, 2011 8:24 PM, "Bernard Aboba" wrote: > > This is indeed a real use case. > > Matthew Kaufman wrote: > > >We have something in there with a NAT... but I don't think we have a use case that covers the situation where one or both users is behind a NAT or firewall that blocks UDP entirely (which fortunately also covers some of the NAT cases where ICE doesn't succeed). This would require media over TCP... something that I believe some of the implementations have already tackled in different ways, but there's no use case and no drafts proposing which solution to choose either. > > > >Matthew Kaufman > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --bcaec547c74b4c3d9a04a8fd25dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1

Emil

-- sent from my mobile
On Jul 26, 2011 8:24 PM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:
>
> This is indeed a real use case.
>
> Matthew Kaufman <matth= ew.kaufman@skype.net> wrote:
>
> >We have something in there with a NAT... but I don't think we = have a use case that covers the situation where one or both users is behind= a NAT or firewall that blocks UDP entirely (which fortunately also covers = some of the NAT cases where ICE doesn't succeed). This would require me= dia over TCP... something that I believe some of the implementations have a= lready tackled in different ways, but there's no use case and no drafts= proposing which solution to choose either.
> >
> >Matthew Kaufman
> >_______________________________________________
> >rtcweb mailing list
> >rtcweb@ietf.org
> >https://w= ww.ietf.org/mailman/listinfo/rtcweb
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--bcaec547c74b4c3d9a04a8fd25dd-- From john.elwell@siemens-enterprise.com Tue Jul 26 13:14: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 F248C11E80A7 for ; Tue, 26 Jul 2011 13:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.79 X-Spam-Level: X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[AWL=-1.191, 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 xza9iEF-NWX4 for ; Tue, 26 Jul 2011 13:14:33 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 06E4C11E8095 for ; Tue, 26 Jul 2011 13:14:33 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1C7C523F043E for ; Tue, 26 Jul 2011 22:14:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 26 Jul 2011 22:14:31 +0200 From: "Elwell, John" To: "rtcweb@ietf.org" Date: Tue, 26 Jul 2011 22:14:29 +0200 Thread-Topic: Possible new use case Thread-Index: AcxL0J/zCRj4YbfDSkqYoi0HHxuLMw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Possible new 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, 26 Jul 2011 20:14:34 -0000 (Not sure whether this should go to the W3C list, but trying the IETF list= to start with) I raised this during the WEBRTC session on Saturday. Does anyone have any interest in adding a use case concerning recording of = real-time media at a remote recorder? I noticed something on local recordin= g in the proposed APIs, but remote recording might have other impacts, e.g.= , - taking a stream from a capture device (mic, camera) and sending it not on= ly to the remote browser but also to a remote recorder; - taking a stream from the remote browser and sending it to a remote record= er (as well as rendering locally); - possibly mixing the two streams (in case of audio) and sending as a singl= e mixed stream to the recording device. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. = From rsf@ns.live555.com Tue Jul 26 13:55: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 C01D021F867F for ; Tue, 26 Jul 2011 13:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_55=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 aN9F0zyuSNXM for ; Tue, 26 Jul 2011 13:55:46 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 22D1321F861E for ; Tue, 26 Jul 2011 13:55:46 -0700 (PDT) Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id p6QKtj0v090719 for ; Tue, 26 Jul 2011 13:55:45 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.14.4/8.14.4/Submit) id p6QKtjmU090716; Tue, 26 Jul 2011 13:55:45 -0700 (PDT) (envelope-from rsf) Mime-Version: 1.0 Message-Id: In-Reply-To: <4E2D5C5D.6060402@alvestrand.no> References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> Date: Tue, 26 Jul 2011 16:55:32 -0400 To: rtcweb@ietf.org From: Ross Finlayson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [rtcweb] Reasons (not?) to multiplex audio with video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 20:55:46 -0000 When I first started thinking about the 'multiplexing' question, I tended to support Colin's point-of-view. Carrying audio and video on separate ports gives a system more flexibility, is compatible with existing implementations (including mine :-), and is in line with long-standing assumptions about the use of the SSRC, RTCP etc. But over time I have become increasingly sympathetic to Jonathan's arguments - especially regarding NAT traversal - in particular, setup time, use of resources (# of ports), and failure modes. We have to assume that many, if not most users of RTCWEB systems will be on unsophisticated, heavily NATed IPv4 home (or hotel, or coffee shop etc.) networks. As IPv4 addresses become scarcer, this situation will likely only get worse. However, as someone noted (in the context of "security") during today's RTCWEB session, we're not the first people to be designing a (hopefully) widely-deployed consumer-oriented peer-to-peer A/V chat system. There are several existing systems out there, so it might be instructive to look at how they address the 'media multiplexing' issue - in particular: 1/ Apple's "FaceTime". OK, this is not browser-based (although with a bit of work it probably could have been), but it does use RTP. Is it using separate ports for audio and video (and two more for RTCP)? If so, has NAT traversal been a problem, and would it have been beneficial to have been able to reduce the number of ports used? (Is Dave Singer on this mailing list?) 2/ Facebook's new video chat. OK, this uses Skype, and thus presumably not RTP (at least, not now). But does this multiplex audio+video on a single port? (And if so, did this help motivate Jonathan's point-of-view?) 3/ Google Plus "Hangouts". Similar question to 1/. 4/ Any others (whether RTP-based or not)? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matthew.kaufman@skype.net Tue Jul 26 14:34: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 6181B11E80BF for ; Tue, 26 Jul 2011 14:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_74=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 BYIAl1IkvWpU for ; Tue, 26 Jul 2011 14:34:51 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD011E80AF for ; Tue, 26 Jul 2011 14:34:51 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 5CA561711; Tue, 26 Jul 2011 23:34:46 +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=diLm+XVqKZScgzfdzh8HNtYwAw8=; b=ARdu20T 0TMRmFQV4QOHOIqMLx7IeexktDVJ2Hh7Vpbc563QPnFov/TBBuMK/afwoxR7UWde VbsdDv8mqN2sVguI3nWbOuPJlnwUEsJIm8lvdrTICOsFGV8tMrrbXUErksL+XOuQ ociRFUuRY9jclVM0GhLzlodSifyxiJg2yMnQ= 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=G+khsaTqOOYlFrzlOvSCVEA8+1fPEtyn+N38fQyvbhRsjuDH wFQaf9IbmbzM4THd9hLK3vSjhx9b5S64AyILUE3/tFLEYdqUYNZPctEcZxl+yLW9 FtYPTPLaot4goEazy2wd86FGT/HfyfymOfmeJYWbLVyTGMtYs3gTqZ9JBOE= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 5B03F7F6; Tue, 26 Jul 2011 23:34:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 21F7235079BA; Tue, 26 Jul 2011 23:34:46 +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 CJ8kf9B-JOyy; Tue, 26 Jul 2011 23:34:45 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id D3C503508A8C; Tue, 26 Jul 2011 23:34:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-20-548917979 From: Matthew Kaufman In-Reply-To: Date: Tue, 26 Jul 2011 17:34:43 -0400 Message-Id: References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> To: Ross Finlayson X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reasons (not?) to multiplex audio with video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 21:34:52 -0000 --Apple-Mail-20-548917979 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 26, 2011, at 4:55 PM, Ross Finlayson wrote: >=20 > 2/ Facebook's new video chat. OK, this uses Skype, and thus = presumably not RTP (at least, not now). But does this multiplex = audio+video on a single port? Yes. > (And if so, did this help motivate Jonathan's point-of-view?) I can't answer this. >=20 >=20 > 4/ Any others (whether RTP-based or not)? All systems that use Flash Player's RTMFP for peer-to-peer audio/video = communication (an early example was Chatroulette) multiplex audio+video = on a single port *and* in fact use that single port to talk to all the = other participants in the multi-party cases. (So for instance, when you = "next" someone in Chatroulette, your local address+port are the same as = they were for the last guy.) Matthew Kaufman --Apple-Mail-20-548917979 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

2/ Facebook's = new video chat.  OK, this uses Skype, and thus presumably not RTP = (at least, not now).  But does this multiplex audio+video on a = single = port?

Yes.

 (And if so, did this help motivate Jonathan's = point-of-view?)

I can't answer = this.



4/ Any others = (whether RTP-based or not)?

All = systems that use Flash Player's RTMFP for peer-to-peer audio/video = communication (an early example was Chatroulette) multiplex audio+video = on a single port *and* in fact use that single port to talk to all the = other participants in the multi-party cases. (So for instance, when you = "next" someone in Chatroulette, your local address+port are the same as = they were for the last guy.)

Matthew = Kaufman

= --Apple-Mail-20-548917979-- From harald@alvestrand.no Tue Jul 26 14:46: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 888FB21F8793 for ; Tue, 26 Jul 2011 14:46:01 -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 Jsbatm6Hgcnw for ; Tue, 26 Jul 2011 14:46:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EFA4E21F8797 for ; Tue, 26 Jul 2011 14:46:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 415F839E091 for ; Tue, 26 Jul 2011 23:44: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 4kiPj4mq3I4T for ; Tue, 26 Jul 2011 23:44:51 +0200 (CEST) Received: from [130.129.22.244] (dhcp-16f4.meeting.ietf.org [130.129.22.244]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BD72839E082 for ; Tue, 26 Jul 2011 23:44:50 +0200 (CEST) Message-ID: <4E2F359C.8060100@alvestrand.no> Date: Tue, 26 Jul 2011 17:46:04 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Reasons (not?) to multiplex audio with video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 21:46:01 -0000 On 07/26/11 16:55, Ross Finlayson wrote: > > 3/ Google Plus "Hangouts". Similar question to 1/. Google+ Hangouts uses SRTP, with one port for video and one port for audio. Many audio and video channels (multiplexed by SSRC) in the server->client direction. We multiplex RTCP onto the RTP port as specified in the relevant RFC. Harald From Bala@vidyo.com Tue Jul 26 14:48: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 335DF21F87ED for ; Tue, 26 Jul 2011 14:48: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=[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 JpqW3lIYSPiX for ; Tue, 26 Jul 2011 14:48:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 81BF221F8793 for ; Tue, 26 Jul 2011 14:48:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id AB322553E63; Tue, 26 Jul 2011 17:48:32 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 33075553FC3; Tue, 26 Jul 2011 17:48:32 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Tue, 26 Jul 2011 17:48:32 -0400 From: Bala Pitchandi To: Ross Finlayson , "rtcweb@ietf.org" Date: Tue, 26 Jul 2011 17:48:30 -0400 Thread-Topic: [rtcweb] Reasons (not?) to multiplex audio with video Thread-Index: AcxL1m+vV2DP64IPQFySkLDUsiCHNQABspew Message-ID: <38DF8F00ABAB77498A75469448CB081B3AE69BF4AA@BE235.mail.lan> References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Reasons (not?) to multiplex audio with video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 21:48:34 -0000 > 1/ Apple's "FaceTime". OK, this is not browser-based (although with a bi= t of work it probably could have been), but it does use RTP. Is it using s= eparate ports for audio and video (and two more for RTCP)?=20 > If so, has NAT traversal been a problem, and would it have been beneficia= l to have been able to reduce the number of ports used? (Is Dave Singer on= this mailing list?) I believe FaceTime multiplexes audio & video on to the same port. In fact, = it even multiplexes the signaling on to the same port. See: http://blog.roy= chowdhury.org/2010/06/25/facetime-on-iphone-4-vanilla-unencrypted-stun-and-= sip/ -- Bala From arosenberg@logitech.com Tue Jul 26 14:58: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 0B0C811E80B7 for ; Tue, 26 Jul 2011 14:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glAQRYiGfFFF for ; Tue, 26 Jul 2011 14:58:33 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with SMTP id B082411E80B3 for ; Tue, 26 Jul 2011 14:58:32 -0700 (PDT) Received: from mail-gx0-f173.google.com ([209.85.161.173]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTi84h2uEpndR5FdIfbOFkuSIPbyT0da2@postini.com; Tue, 26 Jul 2011 14:58:32 PDT Received: by mail-gx0-f173.google.com with SMTP id 26so900774gxk.18 for ; Tue, 26 Jul 2011 14:58:31 -0700 (PDT) Received: by 10.236.176.194 with SMTP id b42mr7743439yhm.524.1311717511094; Tue, 26 Jul 2011 14:58:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.42.196 with HTTP; Tue, 26 Jul 2011 14:58:11 -0700 (PDT) In-Reply-To: <38DF8F00ABAB77498A75469448CB081B3AE69BF4AA@BE235.mail.lan> References: <4E123C54.10405@jdrosen.net> <8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net> <4E2D5C5D.6060402@alvestrand.no> <38DF8F00ABAB77498A75469448CB081B3AE69BF4AA@BE235.mail.lan> From: Aron Rosenberg Date: Tue, 26 Jul 2011 14:58:11 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=20cf305b12824b60bd04a900083f Subject: Re: [rtcweb] Reasons (not?) to multiplex audio with video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jul 2011 21:58:34 -0000 --20cf305b12824b60bd04a900083f Content-Type: text/plain; charset=ISO-8859-1 Facetime muxes everything onto the same port using RTP SSRC and signals that in SDP using an a=rtpID attribute inside each m= line. Each m= line has the same value. -Aron On Tue, Jul 26, 2011 at 2:48 PM, Bala Pitchandi wrote: > > 1/ Apple's "FaceTime". OK, this is not browser-based (although with a > bit of work it probably could have been), but it does use RTP. Is it using > separate ports for audio and video (and two more for RTCP)? > > If so, has NAT traversal been a problem, and would it have been > beneficial to have been able to reduce the number of ports used? (Is Dave > Singer on this mailing list?) > > I believe FaceTime multiplexes audio & video on to the same port. In fact, > it even multiplexes the signaling on to the same port. See: > http://blog.roychowdhury.org/2010/06/25/facetime-on-iphone-4-vanilla-unencrypted-stun-and-sip/ > > -- Bala > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf305b12824b60bd04a900083f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Facetime muxes everything onto the same port using RTP SSRC and signals tha= t in SDP using an a=3DrtpID attribute inside each m=3D line. Each m=3D line= has the same <port> value.

-Aro= n

On Tue, Jul 26, 2011 at 2:48 PM, Bala Pitcha= ndi <Bala@vidyo.com<= /a>> wrote:
> 1/ Apple's "FaceTime". =A0OK, this is = not browser-based (although with a bit of work it probably could have been)= , but it does use RTP. =A0Is it using separate ports for audio and video (a= nd two more for RTCP)?
> If so, has NAT traversal been a problem, and would it have been benefi= cial to have been able to reduce the number of ports used? =A0(Is Dave Sing= er on this mailing list?)

I believe FaceTime multiplexes audio & video on to the same port.= In fact, it even multiplexes the signaling on to the same port. See: http://blog.roychowdhury.org/2= 010/06/25/facetime-on-iphone-4-vanilla-unencrypted-stun-and-sip/

-- Bala

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

--20cf305b12824b60bd04a900083f-- From bernard_aboba@hotmail.com Tue Jul 26 17:01: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 159305E8008 for ; Tue, 26 Jul 2011 17:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.826 X-Spam-Level: X-Spam-Status: No, score=-100.826 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_40=-0.185, 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 7DYZep+YRWxF for ; Tue, 26 Jul 2011 17:01:49 -0700 (PDT) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id 85D335E8005 for ; Tue, 26 Jul 2011 17:01:49 -0700 (PDT) Received: from BLU152-W36 ([65.55.116.73]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 17:01:49 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_008a9b44-395c-4cfb-86eb-dcb73b1344eb_" X-Originating-IP: [130.129.64.90] From: Bernard Aboba To: Date: Tue, 26 Jul 2011 17:01:48 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2011 00:01:49.0194 (UTC) FILETIME=[61CCAEA0:01CC4BF0] Subject: [rtcweb] E911 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, 27 Jul 2011 00:01:50 -0000 --_008a9b44-395c-4cfb-86eb-dcb73b1344eb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I thought I would put forward a potential E911 use case for consideration b= y the group: * Emergency Access for the disabled. An individual who is speech and/or h= earing impaired and is fluent in ASL needs to make an emergency call. The= call will support location conveyance as well as video (to accommodate ASL= interpretation) and an audio stream (which might be only one-way) and will= terminate on an ESInet conferencing system as described in NENA i3 stage 3= . The conferencing system will automatically bridge in an ASL interpreter = who will provide an audio stream and the mixed audio as well as video strea= m will be provided to the dispatcher=2C along with the caller location info= rmation.=20 = --_008a9b44-395c-4cfb-86eb-dcb73b1344eb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I thought I would put forward a potential E911 use case for consideration b= y the group:

* Emergency Access for the disabled. =3B =3B An= individual who is speech and/or hearing impaired and is fluent in ASL need= s to make an emergency call. =3B =3B The call will support location= conveyance as well as video (to accommodate ASL interpretation) and an aud= io stream (which might be only one-way) and will terminate on an ESInet con= ferencing system as described in NENA i3 stage 3. =3B The conferencing = system will automatically bridge in an ASL interpreter who will provide an = audio stream and the mixed audio as well as video stream will be provided t= o the dispatcher=2C along with the caller location information.

= --_008a9b44-395c-4cfb-86eb-dcb73b1344eb_-- From ietf@meetecho.com Wed Jul 27 08:10: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 DDAB021F85B2 for ; Wed, 27 Jul 2011 08:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 gnnFo7AdglSp for ; Wed, 27 Jul 2011 08:10:50 -0700 (PDT) Received: from smtplqs02.aruba.it (smtplqs-out48.aruba.it [62.149.158.88]) by ietfa.amsl.com (Postfix) with SMTP id E6E2F21F850F for ; Wed, 27 Jul 2011 08:10:37 -0700 (PDT) Received: (qmail 28859 invoked by uid 89); 27 Jul 2011 15:10:25 -0000 Received: from unknown (HELO smtpw1.aruba.it) (62.149.128.188) by smtplqs02.aruba.it with SMTP; 27 Jul 2011 15:10:25 -0000 Received: (qmail 11251 invoked by uid 89); 27 Jul 2011 15:10:25 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 27 Jul 2011 15:10:25 -0000 Date: Wed, 27 Jul 2011 17:10:24 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1311779425.2A.747026.42.27022.52.42.007.1309547597" From: "Meetecho IETF support" To: rtcweb@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 70.81.226.194 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs02.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] RTCWEB recording available X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Jul 2011 15:10:52 -0000 --_=__=_XaM3_.1311779425.2A.747026.42.27022.52.42.007.1309547597 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,the full recording (synchronized video, audio, slides and jabber= room) of yesterday's RTCWEB session is available at the following URL:ht= tp://www.meetecho.com/ietf81/recordingsFor the chair(s): please feel free= to put the link to the recording in the minutes, if you think this might= be useful.In case of problems with the playout, just drop an e-mail to i= etf-support@meetecho.com.Cheers,the Meetecho Team --_=__=_XaM3_.1311779425.2A.747026.42.27022.52.42.007.1309547597 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A
=0A
Dear all,

the full recording (synchronized v= ideo, audio, slides and jabber room)
of yesterday's RTCWEB session is= available at the following URL:

http://www.meetecho.com/ietf81/re= cordings

For the chair(s): please feel free to put the link to the= recording in the minutes, if you think this might be useful.

In c= ase of problems with the playout, just drop an e-mail to
ietf-support= @meetecho.com.

Cheers,
the Meetecho Team
=0A
=0A --_=__=_XaM3_.1311779425.2A.747026.42.27022.52.42.007.1309547597-- From ted.ietf@gmail.com Wed Jul 27 13: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 8F96F11E80C8 for ; Wed, 27 Jul 2011 13:22: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=[AWL=0.001, 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 vwi4egiqeAck for ; Wed, 27 Jul 2011 13:22:19 -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 0BAE811E8082 for ; Wed, 27 Jul 2011 13:22:18 -0700 (PDT) Received: by yie30 with SMTP id 30so1626714yie.31 for ; Wed, 27 Jul 2011 13:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=BLS3AAPSH89Lm9/GQiqvbgoAlRPiGxGyoWTiO5LgjXc=; b=XwNhatPGejWhkLrZ31bgXTZ+4kqCrNCFRT8hRVcYmYcaW6WP8qE7pv+trXrdb9y1EY J+1q4Ely/hg6bM7wfulXG94yohtjHadIXmQazSq86Kl5OM3xGUoqCpiSPDr+xNfAHEsC 22wbboy9OHq9fBMNlqOJo1VvC2uJUBWl8nQ6k= MIME-Version: 1.0 Received: by 10.236.154.169 with SMTP id h29mr298031yhk.279.1311798138635; Wed, 27 Jul 2011 13:22:18 -0700 (PDT) Received: by 10.236.105.133 with HTTP; Wed, 27 Jul 2011 13:22:18 -0700 (PDT) Date: Wed, 27 Jul 2011 16:22:18 -0400 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Updated agenda for meeting 2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Jul 2011 20:22:19 -0000 We've updated the agenda for meeting two; it is uploaded and included below for your convenience. thanks, Ted, Cullen, Magnus Agenda Bash & Status Report (Chairs) - 10 min Liaison Report from W3C WebRTC -(WebRTC Chairs) - 10 min - The W3C will have just had a meeting the Saturday before Implementation Experience (Tim, Cary, Harald, Stefan)- 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 - 3 minute updates from four groups Use Cases (Stefan) - 20 min draft-ietf-rtcweb-use-cases-and-requirements Architecture and System Overview (Harald) - 20 min draft-ietf-rtcweb-overview Security (Eric) - 20 min draft-rescorla-rtcweb-security draft-kaufman-rtcweb-security-ui draft-johnston-rtcweb-media-privacy Start of Session two (Chairs) - 5 min Multiplexing * discussion updated during the week Jonathan Lennox and JDRosenberg 20 minutes Negotiation & signaling (Cullen) - 20 min draft-cbran-rtcweb-negotiation Media other than multiplexing (Colin) - 20 min draft-perkins-rtcweb-rtp-usage draft-cbran-rtcweb-media NAT (Matthew/Cary) - 15 min draft-kaufman-rtcweb-traversal draft-cbran-rtcweb-nat Datagram transports (Cary/Matthew) 20 min draft-cbran-rtcweb-data draft-kaufman-rtp-compatible-data Layered Codecs (Stephan) - 10 min draft-wenger-rtcweb-layered-codec Media processing & codec (Cary) - 10 min draft-cbran-rtcweb-codec * focus on requirements for codecs From HKaplan@acmepacket.com Wed Jul 27 23:17: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 1AB0121F8B0E for ; Wed, 27 Jul 2011 23:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 msiWvSG8uWYj for ; Wed, 27 Jul 2011 23:17:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1863021F8B0C for ; Wed, 27 Jul 2011 23:17:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 28 Jul 2011 02:17:43 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 02:17:43 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Date: Thu, 28 Jul 2011 02:17:42 -0400 Thread-Topic: Retransmit: Summary of Alternatives for media keying Thread-Index: AcxM7g9dcIBOmCLeRXOquEWZxmywQg== Message-ID: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.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 X-Brightmail-Tracker: AAAAAQAAAUA= Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 06:17:47 -0000 Well gee that doesn't sound like too hard a choice set to choose from, thou= gh I guess it depends on whether there's a requirement/desire to interop wi= th existing VoIP devices and the PSTN, or not. If we don't expect/desire RTCWEB clients to communicate with existing VoIP = devices or PSTN, then sure we can start with a clean slate. In fact, you c= ould also create a whole new version of SIP for inter-server, since there's= no need to use SIP v2.0 between RTCWEB domains and we've learned things we= could have done better, and for a pure inter-domain server-to-server signa= ling protocol it could be a lot simpler.=20 But anyway... with regards to your alternatives below, you seem to imply th= at using DTLS-SRTP is by itself "secure", such that the UI could display a = lock-icon for example. I was under the impression that DTLS-SRTP provided = no guarantee of anything without the humans on both ends verifying they're = using the same keying material/SAS/etc. Is that not the case? (okay yes it= requires being a MitM to subvert, but that's not a high enough bar to clai= m anything) Assuming that's true, and given how few humans would actually know to perfo= rm manual verification of dtls-srtp, I think this topic isn't as cut-and-dr= ied as choosing between "secure" vs. "insecure". Both alternatives are cap= able of being secure or insecure, and it's up to the human to do something = to figure it out in either case. There is no real alternative which is inh= erently "secure", afaict. -hadriel Recently EKR wrote: > This is very late, but here is my attempted summary of the discussion > about COMSEC choices at the interim. I'm not saying that this captures > everyone's position, but the following positions are the ones that in > my view have significant levels of support. >=20 >=20 > Alternative A: [DTLS MUST, NO SDES, NO RTP] >=20 > An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for > media, without support for either SRTP with supplied keying > material (SDES-style) AND plain RTP. DTLS-SRTP provides for > end-to-end key negotation between the two RTCWEB clients. The > client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection > profile and the DTLS cipher suite > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA > in that it mandates support for Diffie-Hellman key exchange in > order to provide Perfect Forward Secrecy. >=20 > An RTCWEB client MUST provide its user with the ability to to see > keying material information sufficient to allow indepent > verification of their peer's identity. (REF > draft-kaufman-rtcweb-security-ui). >=20 > The primary drawback of this alternative is the lack of backwards > compatibility with devices and software that only support plain > RTP, but the requirement for a handshake makes interoperation with > these devices not completely trivial anyway. >=20 >=20 >=20 > Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST] >=20 > An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP > provides for end-to-end key negotation between the two RTCWEB > clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 > protection profile and the DTLS cipher suite > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA > in that it mandates support for Diffie-Hellman key exchange in > order to provide Perfect Forward Secrecy. This MUST be the default > mode of operation. >=20 > An RTCWEB client MAY support SRTP with the keying material supplied > via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80 > protection profile. In the case of a web browser client, the > keying material should be supplied via a Javascript API. > DTLS-SRTP, with its end-to-end keying and authentication capability > is preferred over SDES-style [RFC4568] keying. However, the > additional API overhead required to add support for a way to force > a particular key is low. In addition, once plain RTP is to be > supported the arguments against the lower security level provided > by SDES-style keying are no longer relevant. Also there are a > small number of potential use cases where interoperability with > existing SDES-keyed software or devices may be achieved if the > RTCWEB endpoint supports this mode of keying. >=20 > An RTCWEB client MUST support RTP. This provides no privacy but > maximizes interoperability. Note that SRTP with a Null cipher has > equivalent security but does not meet the interoperability > requirement. Plain RTP provides no protection for the media, and > so is discouraged as a mode of operation for RTCWEB. However, > support for RTP is required in order to provide interoperability > with legacy RTP devices and software that do not support > encryption. In addition, some use cases such as high-volume PSTN > or PBX gateways within an organization may scale more readily > without the overhead of media encryption. >=20 > An RTCWEB client MUST provide its user with the ability to know > whether or not the media they are sending is protected by encryption > and with the ability to see keying material information sufficient > to allow indepent verification of their peer's identity. > (REF draft-kaufman-rtcweb-security-ui). Note that this user > interface element is much more critical---and hence much more > problematic than with alternative A. If DTLS-SRTP is always > used, then the user knows what security mechanisms are provided. > As soon as multiple alternatives with widely varying security > (or no security in the case of RTP) are provided, then users > need to actually verify that the security level is satisfactory, > which is inherently problematic given typical user behavior. >=20 > I expect to leave time for discussion of this during my slot tomorrow. > I look forward to a good discussion. >=20 > Best, > -Ekr >=20 From HKaplan@acmepacket.com Thu Jul 28 00:52: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 B871521F8C13 for ; Thu, 28 Jul 2011 00:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 uyd0I+GuyZSp for ; Thu, 28 Jul 2011 00:52:27 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 111C321F8C11 for ; Thu, 28 Jul 2011 00:52:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 03:52:23 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 03:52:23 -0400 From: Hadriel Kaplan To: "rtcweb@ietf.org" Date: Thu, 28 Jul 2011 03:52:20 -0400 Thread-Topic: Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxM+0gr6MSbGksHRW+4C5EDW5aSMg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFU Subject: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 07:52:27 -0000 Howdy, With regard to mandating ICE, such that an RTCWEB browser cannot send RTP w= ithout doing ICE successfully first... is that restriction purely to preven= t the voice-hammer attacks? If so, then it's unfortunate because obviously= it would seriously reduce interop with non-RTCWEB VoIP devices. But I thi= nk there's a way to prevent the hammer attack without using ICE, and withou= t requiring legacy VoIP devices to change whatsoever. One way would be to use the receipt of RTP as an indicator the far-end expe= cts to receive it from you. So have the browser generate RTP/RTCP packets,= at a relatively slow rate, for a short duration (e.g., use the same rate/r= etransmit timers of STUN connectivity checks in ICE). If the browser recei= ves RTP/RTCP packets, then the far-end expected to receive them as well and= the browser can do normal RTP from then on. If this was a hammer attack, this doesn't generate any more load on the tar= get than ICE, since ICE would have sent X number of STUN packets for Y time= as well, and I'm suggesting the X and Y be the same values for the initial= RTP packets during the "check" phase. The major weakness of this approach is that a malicious web-server trying t= o get your browser to do the voice hammer could send RTP to your browser, s= ince it knows the address/ports of both sides, codec payload types, etc. (i= .e., it can spoof being the attack target to make your browser think it's o= k to do normal RTP) But we could probably play games with RTCP SR/RR or ev= en just require continued RTP receipt to send RTP, in order to mitigate thi= s weakness or make it of low value to exploit. Does anyone else care about interop-ing with legacy non-RTCWEB voip devices= ? I checked draft-ietf-rtcweb-use-cases-and-requirements-01 and I don't se= e it, so I'm not sure. -hadriel From bernard_aboba@hotmail.com Thu Jul 28 03:48: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 6708E21F8C08 for ; Thu, 28 Jul 2011 03:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.431, 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 KdMAidwPuKyH for ; Thu, 28 Jul 2011 03:48:21 -0700 (PDT) Received: from blu0-omc2-s13.blu0.hotmail.com (blu0-omc2-s13.blu0.hotmail.com [65.55.111.88]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5E21F8C06 for ; Thu, 28 Jul 2011 03:48:20 -0700 (PDT) Received: from BLU152-W17 ([65.55.111.72]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 03:48:20 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d5c994ac-d408-471d-a07f-c6d498b943a1_" X-Originating-IP: [130.129.70.124] From: Bernard Aboba To: , Date: Thu, 28 Jul 2011 03:48:20 -0700 Importance: Normal In-Reply-To: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jul 2011 10:48:20.0864 (UTC) FILETIME=[DDD98800:01CC4D13] Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 10:48:22 -0000 --_d5c994ac-d408-471d-a07f-c6d498b943a1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree that the "clean slate" approach is not very appealing. "Since we req= uire ICE=2C we can also require X=2C Y=2C Z" is flawed logic=2C not only fr= om a deployment/interoperability point of view=2C but also from a regulator= y point of view. The definitions of interconnected/non-interconnected VOIP= and the associated regulatory requirements do not have a browser exemption= .=20 > From: HKaplan@acmepacket.com > To: rtcweb@ietf.org > Date: Thu=2C 28 Jul 2011 02:17:42 -0400 > Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keyin= g >=20 >=20 > Well gee that doesn't sound like too hard a choice set to choose from=2C = though I guess it depends on whether there's a requirement/desire to intero= p with existing VoIP devices and the PSTN=2C or not. >=20 > If we don't expect/desire RTCWEB clients to communicate with existing VoI= P devices or PSTN=2C then sure we can start with a clean slate. In fact=2C= you could also create a whole new version of SIP for inter-server=2C since= there's no need to use SIP v2.0 between RTCWEB domains and we've learned t= hings we could have done better=2C and for a pure inter-domain server-to-se= rver signaling protocol it could be a lot simpler.=20 >=20 > But anyway... with regards to your alternatives below=2C you seem to impl= y that using DTLS-SRTP is by itself "secure"=2C such that the UI could disp= lay a lock-icon for example. I was under the impression that DTLS-SRTP pro= vided no guarantee of anything without the humans on both ends verifying th= ey're using the same keying material/SAS/etc. Is that not the case? (okay = yes it requires being a MitM to subvert=2C but that's not a high enough bar= to claim anything) >=20 > Assuming that's true=2C and given how few humans would actually know to p= erform manual verification of dtls-srtp=2C I think this topic isn't as cut-= and-dried as choosing between "secure" vs. "insecure". Both alternatives a= re capable of being secure or insecure=2C and it's up to the human to do so= mething to figure it out in either case. There is no real alternative whic= h is inherently "secure"=2C afaict. >=20 > -hadriel >=20 >=20 > Recently EKR wrote: > > This is very late=2C but here is my attempted summary of the discussion > > about COMSEC choices at the interim. I'm not saying that this captures > > everyone's position=2C but the following positions are the ones that in > > my view have significant levels of support. > >=20 > >=20 > > Alternative A: [DTLS MUST=2C NO SDES=2C NO RTP] > >=20 > > An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for > > media=2C without support for either SRTP with supplied keying > > material (SDES-style) AND plain RTP. DTLS-SRTP provides for > > end-to-end key negotation between the two RTCWEB clients. The > > client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection > > profile and the DTLS cipher suite > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > > differs from the current TLS default=2C TLS_RSA_WITH_AES_128_CBC_SHA > > in that it mandates support for Diffie-Hellman key exchange in > > order to provide Perfect Forward Secrecy. > >=20 > > An RTCWEB client MUST provide its user with the ability to to see > > keying material information sufficient to allow indepent > > verification of their peer's identity. (REF > > draft-kaufman-rtcweb-security-ui). > >=20 > > The primary drawback of this alternative is the lack of backwards > > compatibility with devices and software that only support plain > > RTP=2C but the requirement for a handshake makes interoperation with > > these devices not completely trivial anyway. > >=20 > >=20 > >=20 > > Alternative B: [DTLS-SRTP MUST=2C SDES MAY=2C RTP MUST] > >=20 > > An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP > > provides for end-to-end key negotation between the two RTCWEB > > clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 > > protection profile and the DTLS cipher suite > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > > differs from the current TLS default=2C TLS_RSA_WITH_AES_128_CBC_SHA > > in that it mandates support for Diffie-Hellman key exchange in > > order to provide Perfect Forward Secrecy. This MUST be the default > > mode of operation. > >=20 > > An RTCWEB client MAY support SRTP with the keying material supplied > > via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80 > > protection profile. In the case of a web browser client=2C the > > keying material should be supplied via a Javascript API. > > DTLS-SRTP=2C with its end-to-end keying and authentication capabilit= y > > is preferred over SDES-style [RFC4568] keying. However=2C the > > additional API overhead required to add support for a way to force > > a particular key is low. In addition=2C once plain RTP is to be > > supported the arguments against the lower security level provided > > by SDES-style keying are no longer relevant. Also there are a > > small number of potential use cases where interoperability with > > existing SDES-keyed software or devices may be achieved if the > > RTCWEB endpoint supports this mode of keying. > >=20 > > An RTCWEB client MUST support RTP. This provides no privacy but > > maximizes interoperability. Note that SRTP with a Null cipher has > > equivalent security but does not meet the interoperability > > requirement. Plain RTP provides no protection for the media=2C and > > so is discouraged as a mode of operation for RTCWEB. However=2C > > support for RTP is required in order to provide interoperability > > with legacy RTP devices and software that do not support > > encryption. In addition=2C some use cases such as high-volume PSTN > > or PBX gateways within an organization may scale more readily > > without the overhead of media encryption. > >=20 > > An RTCWEB client MUST provide its user with the ability to know > > whether or not the media they are sending is protected by encryption > > and with the ability to see keying material information sufficient > > to allow indepent verification of their peer's identity. > > (REF draft-kaufman-rtcweb-security-ui). Note that this user > > interface element is much more critical---and hence much more > > problematic than with alternative A. If DTLS-SRTP is always > > used=2C then the user knows what security mechanisms are provided. > > As soon as multiple alternatives with widely varying security > > (or no security in the case of RTP) are provided=2C then users > > need to actually verify that the security level is satisfactory=2C > > which is inherently problematic given typical user behavior. > >=20 > > I expect to leave time for discussion of this during my slot tomorrow. > > I look forward to a good discussion. > >=20 > > Best=2C > > -Ekr > >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_d5c994ac-d408-471d-a07f-c6d498b943a1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Agree that the "clean slate" approach is not very appealing. =3B "Since= we require ICE=2C we can also require X=2C Y=2C Z" is flawed logic=2C not = only from a deployment/interoperability point of view=2C but also from a re= gulatory point of view. =3B The definitions of interconnected/non-inter= connected VOIP and the associated regulatory requirements do not have a bro= wser exemption.

>=3B From: HKaplan@acmepacket.com
>=3B = To: rtcweb@ietf.org
>=3B Date: Thu=2C 28 Jul 2011 02:17:42 -0400
&g= t=3B Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media ke= ying
>=3B
>=3B
>=3B Well gee that doesn't sound like too h= ard a choice set to choose from=2C though I guess it depends on whether the= re's a requirement/desire to interop with existing VoIP devices and the PST= N=2C or not.
>=3B
>=3B If we don't expect/desire RTCWEB clients = to communicate with existing VoIP devices or PSTN=2C then sure we can start= with a clean slate. In fact=2C you could also create a whole new version = of SIP for inter-server=2C since there's no need to use SIP v2.0 between RT= CWEB domains and we've learned things we could have done better=2C and for = a pure inter-domain server-to-server signaling protocol it could be a lot s= impler.
>=3B
>=3B But anyway... with regards to your alternativ= es below=2C you seem to imply that using DTLS-SRTP is by itself "secure"=2C= such that the UI could display a lock-icon for example. I was under the i= mpression that DTLS-SRTP provided no guarantee of anything without the huma= ns on both ends verifying they're using the same keying material/SAS/etc. = Is that not the case? (okay yes it requires being a MitM to subvert=2C but = that's not a high enough bar to claim anything)
>=3B
>=3B Assumi= ng that's true=2C and given how few humans would actually know to perform m= anual verification of dtls-srtp=2C I think this topic isn't as cut-and-drie= d as choosing between "secure" vs. "insecure". Both alternatives are capab= le of being secure or insecure=2C and it's up to the human to do something = to figure it out in either case. There is no real alternative which is inh= erently "secure"=2C afaict.
>=3B
>=3B -hadriel
>=3B
>= =3B
>=3B Recently EKR wrote:
>=3B >=3B This is very late=2C bu= t here is my attempted summary of the discussion
>=3B >=3B about COM= SEC choices at the interim. I'm not saying that this captures
>=3B >= =3B everyone's position=2C but the following positions are the ones that in=
>=3B >=3B my view have significant levels of support.
>=3B >= =3B
>=3B >=3B
>=3B >=3B Alternative A: [DTLS MUST=2C NO SDE= S=2C NO RTP]
>=3B >=3B
>=3B >=3B An RTC-Web client MUST s= upport DTLS-SRTP and ONLY DTLS-SRTP for
>=3B >=3B media=2C withou= t support for either SRTP with supplied keying
>=3B >=3B material= (SDES-style) AND plain RTP. DTLS-SRTP provides for
>=3B >=3B end= -to-end key negotation between the two RTCWEB clients. The
>=3B >=3B= client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection
>= =3B >=3B profile and the DTLS cipher suite
>=3B >=3B TLS_DHE= _RSA_WITH_AES_128_CBC_SHA. Note that this requirement
>=3B >=3B d= iffers from the current TLS default=2C TLS_RSA_WITH_AES_128_CBC_SHA
>= =3B >=3B in that it mandates support for Diffie-Hellman key exchange i= n
>=3B >=3B order to provide Perfect Forward Secrecy.
>=3B &= gt=3B
>=3B >=3B An RTCWEB client MUST provide its user with the = ability to to see
>=3B >=3B keying material information sufficien= t to allow indepent
>=3B >=3B verification of their peer's identi= ty. (REF
>=3B >=3B draft-kaufman-rtcweb-security-ui).
>=3B = >=3B
>=3B >=3B The primary drawback of this alternative is the= lack of backwards
>=3B >=3B compatibility with devices and softw= are that only support plain
>=3B >=3B RTP=2C but the requirement = for a handshake makes interoperation with
>=3B >=3B these devices= not completely trivial anyway.
>=3B >=3B
>=3B >=3B
>= =3B >=3B
>=3B >=3B Alternative B: [DTLS-SRTP MUST=2C SDES MAY=2C = RTP MUST]
>=3B >=3B
>=3B >=3B An RTC-Web client MUST supp= ort DTLS-SRTP for media. DTLS-SRTP
>=3B >=3B provides for end-to-= end key negotation between the two RTCWEB
>=3B >=3B clients. The= client MUST support the SRTP_AES128_CM_HMAC_SHA1_80
>=3B >=3B pr= otection profile and the DTLS cipher suite
>=3B >=3B TLS_DHE_RSA_= WITH_AES_128_CBC_SHA. Note that this requirement
>=3B >=3B differ= s from the current TLS default=2C TLS_RSA_WITH_AES_128_CBC_SHA
>=3B &g= t=3B in that it mandates support for Diffie-Hellman key exchange in
&= gt=3B >=3B order to provide Perfect Forward Secrecy. This MUST be the = default
>=3B >=3B mode of operation.
>=3B >=3B
>=3B = >=3B An RTCWEB client MAY support SRTP with the keying material suppli= ed
>=3B >=3B via the signaling channel with the SRTP_AES128_CM_HM= AC_SHA1_80
>=3B >=3B protection profile. In the case of a web br= owser client=2C the
>=3B >=3B keying material should be supplied = via a Javascript API.
>=3B >=3B DTLS-SRTP=2C with its end-to-end = keying and authentication capability
>=3B >=3B is preferred over = SDES-style [RFC4568] keying. However=2C the
>=3B >=3B additional= API overhead required to add support for a way to force
>=3B >=3B = a particular key is low. In addition=2C once plain RTP is to be
>= =3B >=3B supported the arguments against the lower security level prov= ided
>=3B >=3B by SDES-style keying are no longer relevant. Also= there are a
>=3B >=3B small number of potential use cases where = interoperability with
>=3B >=3B existing SDES-keyed software or d= evices may be achieved if the
>=3B >=3B RTCWEB endpoint supports = this mode of keying.
>=3B >=3B
>=3B >=3B An RTCWEB client= MUST support RTP. This provides no privacy but
>=3B >=3B maximi= zes interoperability. Note that SRTP with a Null cipher has
>=3B >= =3B equivalent security but does not meet the interoperability
>=3B= >=3B requirement. Plain RTP provides no protection for the media=2C = and
>=3B >=3B so is discouraged as a mode of operation for RTCWEB= . However=2C
>=3B >=3B support for RTP is required in order to p= rovide interoperability
>=3B >=3B with legacy RTP devices and sof= tware that do not support
>=3B >=3B encryption. In addition=2C s= ome use cases such as high-volume PSTN
>=3B >=3B or PBX gateways = within an organization may scale more readily
>=3B >=3B without t= he overhead of media encryption.
>=3B >=3B
>=3B >=3B An R= TCWEB client MUST provide its user with the ability to know
>=3B >= =3B whether or not the media they are sending is protected by encryption=
>=3B >=3B and with the ability to see keying material informatio= n sufficient
>=3B >=3B to allow indepent verification of their pe= er's identity.
>=3B >=3B (REF draft-kaufman-rtcweb-security-ui). = Note that this user
>=3B >=3B interface element is much more crit= ical---and hence much more
>=3B >=3B problematic than with altern= ative A. If DTLS-SRTP is always
>=3B >=3B used=2C then the user k= nows what security mechanisms are provided.
>=3B >=3B As soon as = multiple alternatives with widely varying security
>=3B >=3B (or = no security in the case of RTP) are provided=2C then users
>=3B >=3B= need to actually verify that the security level is satisfactory=2C
&= gt=3B >=3B which is inherently problematic given typical user behavior= .
>=3B >=3B
>=3B >=3B I expect to leave time for discussion = of this during my slot tomorrow.
>=3B >=3B I look forward to a good = discussion.
>=3B >=3B
>=3B >=3B Best=2C
>=3B >=3B -Ek= r
>=3B >=3B
>=3B
>=3B __________________________________= _____________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
&g= t=3B https://www.ietf.org/mailman/listinfo/rtcweb
= --_d5c994ac-d408-471d-a07f-c6d498b943a1_-- From matthew.kaufman@skype.net Thu Jul 28 04:38: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 AF66521F8BD6 for ; Thu, 28 Jul 2011 04:38:18 -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 dKE80ZVc22F1 for ; Thu, 28 Jul 2011 04:38:17 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7F21F88A6 for ; Thu, 28 Jul 2011 04:38:17 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B3E2016E2; Thu, 28 Jul 2011 13:38:13 +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=Qr 1U7uMY2q2HFlg9hvUKRXSPg2w=; b=OyMA0Gbsp8e5FnU6wfpkh/if456kim2uIx dw8ohVTB9BcCjX5ccbjthIBv2k4nxM5Ez06yOtQrbgGADKogSUtDe4sKIA13pPox Ve/ZUfIVzuiXQq0AaGj6aULYFZzEkHvicHaK33LDEZHNjVyF5KQCuBJ108ZAEXbd zW2+Ougts= 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=Tyb8/XAyfURLp5DD92sNJR H/8TliMFA+qZczT2kvyq3E7aArtXQ1SYMH7ccqlLwwyZT+EsdFrhajf44D0dC93V mo2Y+ey1gXE4xTEbceRIAhx5yloH/YrN0OyjAAdKuuB1DZiWt9d23tqKZcYxDI6Y 3gLfElSNjJm4AU4GX+bkE= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B23427F8; Thu, 28 Jul 2011 13:38:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 997253507E77; Thu, 28 Jul 2011 13:38:13 +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 GU0K20H82gN8; Thu, 28 Jul 2011 13:38:12 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (dhcp-4649.meeting.ietf.org [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id 333EB3507E39; Thu, 28 Jul 2011 13:38:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Thu, 28 Jul 2011 07:38:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D6E4E5F-E1E4-47FB-8D8D-F3D9976AC29E@skype.net> References: To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 11:38:18 -0000 On Jul 28, 2011, at 3:52 AM, Hadriel Kaplan wrote: > Howdy, > With regard to mandating ICE, such that an RTCWEB browser cannot send = RTP without doing ICE successfully first... is that restriction purely = to prevent the voice-hammer attacks? If so, then it's unfortunate = because obviously it would seriously reduce interop with non-RTCWEB VoIP = devices. Agree that it limits interoperability. > But I think there's a way to prevent the hammer attack without using = ICE, and without requiring legacy VoIP devices to change whatsoever. >=20 > One way would be to use the receipt of RTP as an indicator the far-end = expects to receive it from you. So have the browser generate RTP/RTCP = packets, at a relatively slow rate, for a short duration (e.g., use the = same rate/retransmit timers of STUN connectivity checks in ICE). If the = browser receives RTP/RTCP packets, then the far-end expected to receive = them as well and the browser can do normal RTP from then on. This is not as safe. There are devices/software that do things upon = receipt of RTP packets (like play them out through loudspeakers, or = initiate ringing of the softphone), and more important RTP packets are = not carefully designed to avoid imitating other types of traffic such as = SNMP, whereas STUN packets contain a relatively large header with a = magic number that makes them much less likely to be misinterpreted by = other protocols. Additionally the STUN connectivity check used for ICE contains = short-term credentials and a transaction ID that is unknown to the = signaling layer (or Javascript) that ensure that you are in fact = conducting a pairwise negotiation with the far end that you are thinking = of. With RTP/RTCP packets alone you can create attacks both from the = browser (by sending RTP/RTCP and using something else to spoof enough = replies that the test passes) or on the browser (by sending it RTP from = somewhere else). And of course ICE, or something like it, is required anyway for doing = NAT traversal. >=20 > If this was a hammer attack, this doesn't generate any more load on = the target than ICE, since ICE would have sent X number of STUN packets = for Y time as well, and I'm suggesting the X and Y be the same values = for the initial RTP packets during the "check" phase. Problem is that it isn't just load. Another class of attack is sending = packets to things like SNMP servers behind a firewall. No matter how = slow the rate, if one of the packets causes bad things to happen then = you have a security problem. >=20 > The major weakness of this approach is that a malicious web-server = trying to get your browser to do the voice hammer could send RTP to your = browser, since it knows the address/ports of both sides, codec payload = types, etc. (i.e., it can spoof being the attack target to make your = browser think it's ok to do normal RTP) Indeed. See above. > But we could probably play games with RTCP SR/RR or even just require = continued RTP receipt to send RTP, in order to mitigate this weakness or = make it of low value to exploit. I don't believe this is the case. There's so many cases where one side = sends A+V but the other side sends audio only, and sending HD-video-rate = traffic to an unsuspecting endpoint is unacceptable. This is even worse if we allow arbitrary datagrams with a relatively = short header, as these will be even easier to craft into attacks on = other protocols if there isn't confirmed consent. >=20 > Does anyone else care about interop-ing with legacy non-RTCWEB voip = devices? I checked draft-ietf-rtcweb-use-cases-and-requirements-01 and = I don't see it, so I'm not sure. I care, but I think that the legacy devices are going to need a way to = consent. At one of our first meetings prior to forming the WG I came up = with additional terminology to describe devices which are legacy and = cannot be upgraded vs. devices which are legacy but which can be = upgraded sufficiently to add the ICE handshake... we should probably = bring that back for convenience. Matthew Kaufman From matthew.kaufman@skype.net Thu Jul 28 04: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 CE8F221F88DD for ; Thu, 28 Jul 2011 04:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 Ws0E-tfv-rAw for ; Thu, 28 Jul 2011 04:52:56 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id AE91421F869C for ; Thu, 28 Jul 2011 04:52:55 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 3143316F0; Thu, 28 Jul 2011 13:52:54 +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=HD Q5I49TEd1lHLg0j+fDaCGqfl8=; b=HJlTKqcGTDdnzh6fNsqtQILMsa1IRa1Lit ilesK4ja44yRjsig0/ltZdFb1daBWEW/5hpGvxBcNycQ8BhyQG1CcsXKwXa/zlRM 9Yos5KeaC7rB+wgZ6H85n9IPE8TxbjMCk4tF9J+da9j6Znp4bmdsXCuLqoUlYv6v 6xbFwm8QA= 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=LIwIqOPNv86a+YmOTS+fwu A1k7WE/Yy8apJOjkjg/1AdnXVtVWKX4W9s7aqysfKPnE79zD3pVmbnwl/yBI6LFc bP+pSX/XQ07tFiYZWLMt+KgkF5dW7dhebhulG53D4Ir/rJAcdCqplAJCnhFPESms 19f7MbqV1db2e2LgrRwR0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 2FD1B7F8; Thu, 28 Jul 2011 13:52:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 12C323508071; Thu, 28 Jul 2011 13:52:54 +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 UE7J7QGZqWx7; Thu, 28 Jul 2011 13:52:53 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (dhcp-4649.meeting.ietf.org [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id 97D40350805C; Thu, 28 Jul 2011 13:52:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> Date: Thu, 28 Jul 2011 07:52:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 11:52:56 -0000 On Jul 28, 2011, at 2:17 AM, Hadriel Kaplan wrote: >=20 > Well gee that doesn't sound like too hard a choice set to choose from, = though I guess it depends on whether there's a requirement/desire to = interop with existing VoIP devices and the PSTN, or not. There is a requirement to interop with existing VoIP devices and the = PSTN, however other requirements (like ICE for consent to send media) = will impose additional requirements that limit which existing VoIP = devices are or can be made compatible. >=20 > If we don't expect/desire RTCWEB clients to communicate with existing = VoIP devices or PSTN, then sure we can start with a clean slate. There is a desire for the media to be transported in RTP for a variety = of reasons, including the ability to easily terminate the traffic in = PSTN gateways, reuse of existing RTP stacks for building both browsers = and interoperable devices, and middlebox awareness of what the traffic = might be. > In fact, you could also create a whole new version of SIP for = inter-server, since there's no need to use SIP v2.0 between RTCWEB = domains and we've learned things we could have done better, and for a = pure inter-domain server-to-server signaling protocol it could be a lot = simpler.=20 >=20 You could. In fact, for inter-domain federation you are probably free to = use whatever you and the other domain agree to use. However, again for software reuse reasons, you're likely to pick SIP. > But anyway... with regards to your alternatives below, you seem to = imply that using DTLS-SRTP is by itself "secure", such that the UI could = display a lock-icon for example. I was under the impression that = DTLS-SRTP provided no guarantee of anything without the humans on both = ends verifying they're using the same keying material/SAS/etc. Is that = not the case? (okay yes it requires being a MitM to subvert, but that's = not a high enough bar to claim anything) Plain RTP - can be intercepted by both MitM attackers and passive = observers. No perfect forward secrecy (in fact, no secrecy at all).=20 SRTP w/SDES-style keying - both MitM attackers and passive observers can = record the traffic but not play it out until they obtain key. The key is = provided by the server and is likely recorded in server logs. Protection = of the key on the wire requires HTTPS or similar signaling. Impossible = to provide perfect forward secrecy. DTLS-SRTP (or any other end-to-end keying) - assuming the use of DH key = agreement, both MitM attackers and passive observers can record the = traffic, however ONLY MitM attackers are able to participate in the key = agreement algorithm, and so ONLY MitM attackers would ever be able to = play out the contents. The key agreement occurs between the two = endpoints (assuming no MitM attacker, of course) and is not recorded = anywhere else and is not available to the signaling server. Provides = perfect forward secrecy. MitM attacks be avoided if you trust the = signaling service and exchange fingerprints between the two ends for = authentication OR if you use a user interface that lets you examine the = fingerprints and verify them out-of-band OR if you use additional = software that you trust (along with a 3rd party that you trust) to = examine the fingerprints automatically and alert you in the case of = mismatch. All of these statements of course only apply between you and whatever is = terminating the session. If it is a gateway to another protocol, the = security provided stops at that point and is only continued if the far = end of the gateway is also secure *and* you trust both that security and = the gateway. >=20 > Assuming that's true, and given how few humans would actually know to = perform manual verification of dtls-srtp, I think this topic isn't as = cut-and-dried as choosing between "secure" vs. "insecure". Both = alternatives are capable of being secure or insecure, and it's up to the = human to do something to figure it out in either case. There is no real = alternative which is inherently "secure", afaict. There are gradations of security that are provided by default, depending = on the choices made. If the browser is able to send plain RTP at all, then you need a way for = the user to tell if it is sending plain RTP or encrypted RTP. If it can = only send encrypted RTP, then this requirement goes away. For some = threat models (for instance passive observers watching your unencrypted = wifi traffic), any encryption at all is better than plain RTP. For = others (passive observers that can record the traffic and also have = future access to the server logs), encryption + end-to-end keying is far = superior to any of the other choices. But, like all security arguments, you are correct. It is never black and = white, so you can never say "this is secure". But you can certainly say = "this ISN'T secure" for some of them (like plain RTP, or even the = ability for the browser to switch you from SRTP to RTP without making it = clear to the user). Think of the threat models you are likely to experience yourself... then = tell me which level of protection YOU want. Matthew Kaufman From john.elwell@siemens-enterprise.com Thu Jul 28 05:04: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 0FDAE21F8C1F for ; Thu, 28 Jul 2011 05:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=-0.988, 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 cQ+yMAHX4B1m for ; Thu, 28 Jul 2011 05:04:14 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7A21F8C19 for ; Thu, 28 Jul 2011 05:04:13 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CD50A1EB849B; Thu, 28 Jul 2011 14:04:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jul 2011 14:04:12 +0200 From: "Elwell, John" To: Hadriel Kaplan , "rtcweb@ietf.org" Date: Thu, 28 Jul 2011 14:04:10 +0200 Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying Thread-Index: AcxM7g9dcIBOmCLeRXOquEWZxmywQgALnXxg Message-ID: References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> In-Reply-To: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.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] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 12:04:15 -0000 > But anyway... with regards to your alternatives below, you=20 > seem to imply that using DTLS-SRTP is by itself "secure",=20 > such that the UI could display a lock-icon for example. I=20 > was under the impression that DTLS-SRTP provided no guarantee=20 > of anything without the humans on both ends verifying they're=20 > using the same keying material/SAS/etc. Is that not the=20 > case? (okay yes it requires being a MitM to subvert, but=20 > that's not a high enough bar to claim anything) >=20 > Assuming that's true, and given how few humans would actually=20 > know to perform manual verification of dtls-srtp, I think=20 > this topic isn't as cut-and-dried as choosing between=20 > "secure" vs. "insecure". Both alternatives are capable of=20 > being secure or insecure, and it's up to the human to do=20 > something to figure it out in either case. There is no real=20 > alternative which is inherently "secure", afaict. [JRE] I agree with Hadriel's concern. DTLS-SRTP itself, if using only self-= signed certs at the endpoints, requires other means (signalling path or hum= an-assisted) to provide strong guarantees that you are talking to the pers= on or organization you expect. For SIP, the (theoretical) solution is to se= nd a fingerprint of the certificate and have that bound to authenticated id= entity in accordance with RFC 4474, although not feasible in most deployed = SIP environments. Although RTC-Web is not specifying signalling, clearly it= needs to say something about the problem, and can't just indicate to the u= ser that communication is secure just because DTLS-SRTP is used. Secondly, if interworking with legacy SIP, where DTLS-SRTP (or whatever we = select) is terminated at a gateway, there is a real problem ensuring that t= he user knows the call is not necessarily secure end-to-end. Perhaps this a= rgues towards option B, since if DTLS-SRTP is not used from browser to gate= way, at least the browser should know to indicate a lesser level of securit= y to the user. The whole issue of the browser knowing what it can tell the user concerning= the security posture of a communication is a really difficult problem. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > -hadriel >=20 >=20 > Recently EKR wrote: > > This is very late, but here is my attempted summary of the=20 > discussion > > about COMSEC choices at the interim. I'm not saying that=20 > this captures > > everyone's position, but the following positions are the=20 > ones that in > > my view have significant levels of support. > >=20 > >=20 > > Alternative A: [DTLS MUST, NO SDES, NO RTP] > >=20 > > An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for > > media, without support for either SRTP with supplied keying > > material (SDES-style) AND plain RTP. DTLS-SRTP provides for > > end-to-end key negotation between the two RTCWEB clients. The > > client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection > > profile and the DTLS cipher suite > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > > differs from the current TLS default,=20 > TLS_RSA_WITH_AES_128_CBC_SHA > > in that it mandates support for Diffie-Hellman key exchange in > > order to provide Perfect Forward Secrecy. > >=20 > > An RTCWEB client MUST provide its user with the ability to to see > > keying material information sufficient to allow indepent > > verification of their peer's identity. (REF > > draft-kaufman-rtcweb-security-ui). > >=20 > > The primary drawback of this alternative is the lack of backwards > > compatibility with devices and software that only support plain > > RTP, but the requirement for a handshake makes=20 > interoperation with > > these devices not completely trivial anyway. > >=20 > >=20 > >=20 > > Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST] > >=20 > > An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP > > provides for end-to-end key negotation between the two RTCWEB > > clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 > > protection profile and the DTLS cipher suite > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement > > differs from the current TLS default,=20 > TLS_RSA_WITH_AES_128_CBC_SHA > > in that it mandates support for Diffie-Hellman key exchange in > > order to provide Perfect Forward Secrecy. This MUST be=20 > the default > > mode of operation. > >=20 > > An RTCWEB client MAY support SRTP with the keying=20 > material supplied > > via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80 > > protection profile. In the case of a web browser client, the > > keying material should be supplied via a Javascript API. > > DTLS-SRTP, with its end-to-end keying and authentication=20 > capability > > is preferred over SDES-style [RFC4568] keying. However, the > > additional API overhead required to add support for a=20 > way to force > > a particular key is low. In addition, once plain RTP is to be > > supported the arguments against the lower security level provided > > by SDES-style keying are no longer relevant. Also there are a > > small number of potential use cases where interoperability with > > existing SDES-keyed software or devices may be achieved if the > > RTCWEB endpoint supports this mode of keying. > >=20 > > An RTCWEB client MUST support RTP. This provides no privacy but > > maximizes interoperability. Note that SRTP with a Null=20 > cipher has > > equivalent security but does not meet the interoperability > > requirement. Plain RTP provides no protection for the media, and > > so is discouraged as a mode of operation for RTCWEB. However, > > support for RTP is required in order to provide interoperability > > with legacy RTP devices and software that do not support > > encryption. In addition, some use cases such as high-volume PSTN > > or PBX gateways within an organization may scale more readily > > without the overhead of media encryption. > >=20 > > An RTCWEB client MUST provide its user with the ability to know > > whether or not the media they are sending is protected=20 > by encryption > > and with the ability to see keying material information=20 > sufficient > > to allow indepent verification of their peer's identity. > > (REF draft-kaufman-rtcweb-security-ui). Note that this user > > interface element is much more critical---and hence much more > > problematic than with alternative A. If DTLS-SRTP is always > > used, then the user knows what security mechanisms are provided. > > As soon as multiple alternatives with widely varying security > > (or no security in the case of RTP) are provided, then users > > need to actually verify that the security level is satisfactory, > > which is inherently problematic given typical user behavior. > >=20 > > I expect to leave time for discussion of this during my=20 > slot tomorrow. > > I look forward to a good discussion. > >=20 > > Best, > > -Ekr > >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From john.elwell@siemens-enterprise.com Thu Jul 28 05:10: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 978C321F85EE for ; Thu, 28 Jul 2011 05:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=-0.976, 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 aUxm5E+609pX for ; Thu, 28 Jul 2011 05:10:28 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3221F8514 for ; Thu, 28 Jul 2011 05:10:28 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 8AD721EB842D; Thu, 28 Jul 2011 14:10:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jul 2011 14:10:19 +0200 From: "Elwell, John" To: Hadriel Kaplan , "rtcweb@ietf.org" Date: Thu, 28 Jul 2011 14:10:17 +0200 Thread-Topic: Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxM+0gr6MSbGksHRW+4C5EDW5aSMgAI3yIw 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 12:10:29 -0000 =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 28 July 2011 08:52 > To: rtcweb@ietf.org > Subject: [rtcweb] Strawman for how to prevent voice-hammer without ICE >=20 > Howdy, > With regard to mandating ICE, such that an RTCWEB browser=20 > cannot send RTP without doing ICE successfully first... is=20 > that restriction purely to prevent the voice-hammer attacks? =20 > If so, then it's unfortunate because obviously it would=20 > seriously reduce interop with non-RTCWEB VoIP devices. But I=20 > think there's a way to prevent the hammer attack without=20 > using ICE, and without requiring legacy VoIP devices to=20 > change whatsoever. >=20 > One way would be to use the receipt of RTP as an indicator=20 > the far-end expects to receive it from you. So have the=20 > browser generate RTP/RTCP packets, at a relatively slow rate,=20 > for a short duration (e.g., use the same rate/retransmit=20 > timers of STUN connectivity checks in ICE). If the browser=20 > receives RTP/RTCP packets, then the far-end expected to=20 > receive them as well and the browser can do normal RTP from then on. >=20 > If this was a hammer attack, this doesn't generate any more=20 > load on the target than ICE, since ICE would have sent X=20 > number of STUN packets for Y time as well, and I'm suggesting=20 > the X and Y be the same values for the initial RTP packets=20 > during the "check" phase. >=20 > The major weakness of this approach is that a malicious=20 > web-server trying to get your browser to do the voice hammer=20 > could send RTP to your browser, since it knows the=20 > address/ports of both sides, codec payload types, etc. (i.e.,=20 > it can spoof being the attack target to make your browser=20 > think it's ok to do normal RTP) But we could probably play=20 > games with RTCP SR/RR or even just require continued RTP=20 > receipt to send RTP, in order to mitigate this weakness or=20 > make it of low value to exploit. [JRE] The problem with requiring continued RTP receipt (or even ANY RTP rec= eipt) is sessions where RTP is one-way, e.g., when mic muted, camera off. W= ith many asymmetric possibilities coming out of the CLUE work, this could b= e a problem, although it perhaps goes away if everything is multiplexed ont= o the same port. It depends whether we can expect all legacy devices to beh= ave in a way that would make this work. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > Does anyone else care about interop-ing with legacy=20 > non-RTCWEB voip devices? I checked=20 > draft-ietf-rtcweb-use-cases-and-requirements-01 and I don't=20 > see it, so I'm not sure. >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From matthew.kaufman@skype.net Thu Jul 28 05:25: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 81F3621F874A for ; Thu, 28 Jul 2011 05:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 al0fM87XlBFm for ; Thu, 28 Jul 2011 05:25:18 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id A386A21F8551 for ; Thu, 28 Jul 2011 05:25:18 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id ECE2516E2; Thu, 28 Jul 2011 14:25: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 :content-transfer-encoding:message-id:references:to; s=mx; bh=UV AvVEr16a+IfBNzYrUY0wCcGyI=; b=LCLSXRP1RKRjFXdnnt1bjGEaM7VBbGTiz7 b+f7UrdNb0vlus5Yq2n/E9IqNG47it6CCiAMGMNjUPY2iorZinq9fP7JnD6twYJO jJoQErGJJS6YbluKepwb+uCujTd/y6Nlc9ZjuoMvNtDfyEAXi3QV7hihfc4biqIy 4NXvKXmM4= 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=D03WqHwrIHmFtFlyuk8CAe 67B8q7QKLcTnTwqsVJlEDIwbyvQgCEdJcLepKDd+Ljer3esU3g/MAEepNU9jIKdf gaGjT+bRyzmHTxkEZ5vYBPb4LJKcFwSy4GNxM4r2OChF4FhgVlZ3Wb1IREOzlB0z cSIdarZZFFhaGlPsm5yPc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id EB4CA7F8; Thu, 28 Jul 2011 14:25:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D1841350806F; Thu, 28 Jul 2011 14:25: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 SLCg8rEZSP9P; Thu, 28 Jul 2011 14:25:17 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (dhcp-4649.meeting.ietf.org [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id 61160350805C; Thu, 28 Jul 2011 14:25:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Thu, 28 Jul 2011 08:25:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 12:25:19 -0000 On Jul 28, 2011, at 8:04 AM, Elwell, John wrote: > [JRE] I agree with Hadriel's concern. DTLS-SRTP itself, if using only = self-signed certs at the endpoints, requires other means (signalling = path or human-assisted) to provide strong guarantees that you are = talking to the person or organization you expect. Agreed. However there are weaker guarantees of properties that are certainly = favorable as compared to, for instance, plain RTP or even server-keyed = SRTP. (See my previous email.) > For SIP, the (theoretical) solution is to send a fingerprint of the = certificate and have that bound to authenticated identity in accordance = with RFC 4474, although not feasible in most deployed SIP environments. = Although RTC-Web is not specifying signalling, clearly it needs to say = something about the problem, and can't just indicate to the user that = communication is secure just because DTLS-SRTP is used. Correct. >=20 > Secondly, if interworking with legacy SIP, where DTLS-SRTP (or = whatever we select) is terminated at a gateway, there is a real problem = ensuring that the user knows the call is not necessarily secure = end-to-end. Perhaps this argues towards option B, since if DTLS-SRTP is = not used from browser to gateway, at least the browser should know to = indicate a lesser level of security to the user. If you are sitting in an Internet cafe using someone else's unencrypted = wifi and a telephony service provider you trust would you rather 1) use = DTLS-SRTP between you and the telephony provider and plain RTP past = their gateway inside their internal network, or 2) use plain RTP on the = wifi network and all the way to the telephony provider? I agree that we can't display "this connection is secured everywhere" to = the user... but look, HTTPS is the same. When I see a lock icon on my = screen and click to see that yes, I'm really talking to who it says in = the address bar, I still can't tell if they're terminating my HTTPS = session in a front-end box and then using HTTP beyond it, or if the = HTTPS really goes all the way to the server. And when I use HTTPS to = talk to Gmail, there's no way to tell if an email I send will be sent = over a TLS channel or if it'll just be plain SMTP from Gmail to my = recipient. >=20 > The whole issue of the browser knowing what it can tell the user = concerning the security posture of a communication is a really difficult = problem. It isn't a difficult problem if what the user is told is confined to = what is provably true. (See my previous Gmail example.) Matthew Kaufman From HKaplan@acmepacket.com Thu Jul 28 07:48: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 4E89021F8CB8 for ; Thu, 28 Jul 2011 07:48:12 -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 JciJ-PqxgfES for ; Thu, 28 Jul 2011 07:48:11 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4C62F21F8CB4 for ; Thu, 28 Jul 2011 07:48:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 10:47:09 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 10:48:09 -0400 From: Hadriel Kaplan To: "Elwell, John" Date: Thu, 28 Jul 2011 10:48:07 -0400 Thread-Topic: Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxNNV1zFnPAe+pkSveuLg9KTGFoZQ== Message-ID: <464DADBD-EEBE-43C8-8552-EAA40FBB610D@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:48:12 -0000 On Jul 28, 2011, at 8:10 AM, Elwell, John wrote: > [JRE] The problem with requiring continued RTP receipt (or even ANY RTP r= eceipt) is sessions where RTP is one-way, e.g., when mic muted, camera off.= With many asymmetric possibilities coming out of the CLUE work, this could= be a problem, although it perhaps goes away if everything is multiplexed o= nto the same port. It depends whether we can expect all legacy devices to b= ehave in a way that would make this work. Yes, but they don't turn off RTCP (assuming they do RTCP). I'm not suggest= ing that it's a 1:1 mechanism of receipt/send, nor that it even be very dyn= amic/real-time. But sure there will be some cases that it won't work. But= that's no worse than the current state of things, since it won't work to b= egin with for such devices if ICE is mandated. We can't achieve 100% inter= op regardless - I'm just trying for as much as possible. With regards to CLUE, I don't consider their devices "legacy". They'll be = upgrading to handle CLUE's final spec, so they can be "redeemed". -hadriel From HKaplan@acmepacket.com Thu Jul 28 08:13: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 5C3FB21F873D for ; Thu, 28 Jul 2011 08:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5H5kP87XzQU for ; Thu, 28 Jul 2011 08:13:55 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7367A21F8C75 for ; Thu, 28 Jul 2011 08:13:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 11:10:49 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 11:13:54 -0400 From: Hadriel Kaplan To: Matthew Kaufman Date: Thu, 28 Jul 2011 11:13:53 -0400 Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying Thread-Index: AcxNOPbmkhEDoRpNSYuByH2zbrOCng== Message-ID: References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> In-Reply-To: <2E6CBDE0-DA10-4792-8059-A01F554DB370@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 X-Brightmail-Tracker: AAAAAgAAAUAAAAFU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 15:13:56 -0000 On Jul 28, 2011, at 8:25 AM, Matthew Kaufman wrote: >> Secondly, if interworking with legacy SIP, where DTLS-SRTP (or whatever = we select) is terminated at a gateway, there is a real problem ensuring tha= t the user knows the call is not necessarily secure end-to-end. Perhaps thi= s argues towards option B, since if DTLS-SRTP is not used from browser to g= ateway, at least the browser should know to indicate a lesser level of secu= rity to the user. >=20 > If you are sitting in an Internet cafe using someone else's unencrypted w= ifi and a telephony service provider you trust would you rather 1) use DTLS= -SRTP between you and the telephony provider and plain RTP past their gatew= ay inside their internal network, or 2) use plain RTP on the wifi network a= nd all the way to the telephony provider? I would be perfectly happy with using sdes-based SRTP. But if the call wou= ld otherwise fail altogether, I'd like the option to make the call no matte= r what (ie, even if it ends up being cleartext). (And since you're sitting in an Internet cafe in hearing distance of everyo= ne, any sense of privacy is gone anyway. ;) > I agree that we can't display "this connection is secured everywhere" to = the user... but look, HTTPS is the same. When I see a lock icon on my scree= n and click to see that yes, I'm really talking to who it says in the addre= ss bar, I still can't tell if they're terminating my HTTPS session in a fro= nt-end box and then using HTTP beyond it, or if the HTTPS really goes all t= he way to the server. But the browser ties the identity of the name I typed in the address bar to= the cert, so that if I typed "https://mybank.com", I know it's secure to m= ybank.com. Of course it could be cleartext after whomever has a cert for m= ybank.com, and may even end up triggering protocols that exit mybank.com an= d go to evil.com, but I implicitly trust mybank.com to be careful with bank= info. That's not the same for DTLS-SRTP; until and unless the human being= verifies the keys/SAS with the far end, nothing is known. The DTLS-SRTP m= ay only reach the NAT-router in the Internet Cafe, for example, be terminat= ed by it and a separate DTLS-SRTP between it and the bank. And if I'm talk= ing to an IVR system (as one frequently does with banks), there is no human= to verify the keys/SAS with. -hadriel From john.elwell@siemens-enterprise.com Thu Jul 28 08:14: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 93EAD21F8C0B for ; Thu, 28 Jul 2011 08:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=-0.942, 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 7ub+W88mNKWD for ; Thu, 28 Jul 2011 08:14:46 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id D37FF21F873D for ; Thu, 28 Jul 2011 08:14:45 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id DBFB423F059A; Thu, 28 Jul 2011 17:14:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jul 2011 17:14:44 +0200 From: "Elwell, John" To: Hadriel Kaplan Date: Thu, 28 Jul 2011 17:14:42 +0200 Thread-Topic: Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxNNV1zFnPAe+pkSveuLg9KTGFoZQAAbApQ Message-ID: References: <464DADBD-EEBE-43C8-8552-EAA40FBB610D@acmepacket.com> In-Reply-To: <464DADBD-EEBE-43C8-8552-EAA40FBB610D@acmepacket.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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:14:46 -0000 =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 28 July 2011 15:48 > To: Elwell, John > Cc: rtcweb@ietf.org > Subject: Re: Strawman for how to prevent voice-hammer without ICE >=20 >=20 > On Jul 28, 2011, at 8:10 AM, Elwell, John wrote: >=20 > > [JRE] The problem with requiring continued RTP receipt (or=20 > even ANY RTP receipt) is sessions where RTP is one-way, e.g.,=20 > when mic muted, camera off. With many asymmetric=20 > possibilities coming out of the CLUE work, this could be a=20 > problem, although it perhaps goes away if everything is=20 > multiplexed onto the same port. It depends whether we can=20 > expect all legacy devices to behave in a way that would make=20 > this work. >=20 > Yes, but they don't turn off RTCP (assuming they do RTCP). =20 > I'm not suggesting that it's a 1:1 mechanism of receipt/send,=20 > nor that it even be very dynamic/real-time. But sure there=20 > will be some cases that it won't work. But that's no worse=20 > than the current state of things, since it won't work to=20 > begin with for such devices if ICE is mandated. We can't=20 > achieve 100% interop regardless - I'm just trying for as much=20 > as possible. [JRE] This assumes RTP-RTCP multiplexing, which not many current devices su= pport. There are so many things that RTC-Web is proposing to use that are n= ot widely supported on existing devices that some sort of gateway looks ine= vitable. Eliminating one particular instance of incompatibility might reduc= e the amount of adaptation the gateway needs to perform, but it looks incre= asingly unlikely that all adaptation can be eliminated. So is there any rea= l value in trying to eliminate one aspect if others can't be eliminated? Pr= obably yes, but not if it introduces other compromises, e.g., security. I t= hink it is worth exploring this further. John >=20 > With regards to CLUE, I don't consider their devices=20 > "legacy". They'll be upgrading to handle CLUE's final spec,=20 > so they can be "redeemed". >=20 > -hadriel >=20 > = From HKaplan@acmepacket.com Thu Jul 28 08:30: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 6600B21F8B39 for ; Thu, 28 Jul 2011 08:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 1OZbQZtDicRu for ; Thu, 28 Jul 2011 08:30:31 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id C2AFD21F886A for ; Thu, 28 Jul 2011 08:30:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 11:27:26 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 11:30:30 -0400 From: Hadriel Kaplan To: "Elwell, John" Date: Thu, 28 Jul 2011 11:30:30 -0400 Thread-Topic: Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxNO0ioZYET1fWMReOTEY+QHVeOlQ== Message-ID: <818C0CB4-CB51-490B-B023-549E5C6F4364@acmepacket.com> References: <464DADBD-EEBE-43C8-8552-EAA40FBB610D@acmepacket.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:30:32 -0000 On Jul 28, 2011, at 11:14 AM, Elwell, John wrote: > [JRE] This assumes RTP-RTCP multiplexing, which not many current devices = support. No, I didn't mean to assume multiplexing. Sorry if it was confusing. I me= ant if you're worried about using RTP reception to allow transmission becau= se in some cases RTP isn't sent from the far end for periods of time, then = one could use the reception of RTCP on the odd port to allow the sending of= RTP on the even. =20 I was already assuming multiplexing would not likely be used with legacy vo= ip devices, since none of them do it today. -hadriel From HKaplan@acmepacket.com Thu Jul 28 08:58: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 9B24921F8C73 for ; Thu, 28 Jul 2011 08:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 LpGfTqN3t0Ar for ; Thu, 28 Jul 2011 08:58:18 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id DF49421F8BE9 for ; Thu, 28 Jul 2011 08:58:17 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 11:58:16 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 11:58:16 -0400 From: Hadriel Kaplan To: Matthew Kaufman Date: Thu, 28 Jul 2011 11:58:15 -0400 Thread-Topic: [rtcweb] Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxNPynIGvHx+dzKQd24z3TDKEV3RA== Message-ID: References: <8D6E4E5F-E1E4-47FB-8D8D-F3D9976AC29E@skype.net> In-Reply-To: <8D6E4E5F-E1E4-47FB-8D8D-F3D9976AC29E@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 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:58:18 -0000 On Jul 28, 2011, at 7:38 AM, Matthew Kaufman wrote: >=20 >> But I think there's a way to prevent the hammer attack without using ICE= , and without requiring legacy VoIP devices to change whatsoever. >>=20 >> One way would be to use the receipt of RTP as an indicator the far-end e= xpects to receive it from you. So have the browser generate RTP/RTCP packe= ts, at a relatively slow rate, for a short duration (e.g., use the same rat= e/retransmit timers of STUN connectivity checks in ICE). If the browser re= ceives RTP/RTCP packets, then the far-end expected to receive them as well = and the browser can do normal RTP from then on. >=20 > This is not as safe. There are devices/software that do things upon recei= pt of RTP packets (like play them out through loudspeakers, or initiate rin= ging of the softphone), and more important RTP packets are not carefully de= signed to avoid imitating other types of traffic such as SNMP, whereas STUN= packets contain a relatively large header with a magic number that makes t= hem much less likely to be misinterpreted by other protocols. No it's not as "safe", but it may be safe enough. =20 With regards to being misinterpreted by others, since the web server javasc= ript cannot define the actual payload of the RTP (correct?), and things lik= e sequence numbers would also be randomly chosen by the browser, so it's no= t like the javascript can purposefully craft an RTP packet to immitate othe= r protocols. For example it would be an astronmoical coincidence for any g= iven RTP packet to be parsable as SNMP BER for a given ASN.1 dictionary. (Also as an aside, if I recall correctly SNMP is actually distinguishable f= rom RTP by the first byte) > Additionally the STUN connectivity check used for ICE contains short-term= credentials and a transaction ID that is unknown to the signaling layer (o= r Javascript) that ensure that you are in fact conducting a pairwise negoti= ation with the far end that you are thinking of. With RTP/RTCP packets alon= e you can create attacks both from the browser (by sending RTP/RTCP and usi= ng something else to spoof enough replies that the test passes) or on the b= rowser (by sending it RTP from somewhere else). If we used RTCP as part of the check, the reports contain a last received s= equence number which would not be known to the javascript. (it's a hack to= be sure, but if we want to handle non-RTCWEB devices, a hack's better than= nothing) > And of course ICE, or something like it, is required anyway for doing NAT= traversal. Not when communicating with legacy voip devices and the PSTN. > I don't believe this is the case. There's so many cases where one side se= nds A+V but the other side sends audio only, and sending HD-video-rate traf= fic to an unsuspecting endpoint is unacceptable. I should probably write it up in a draft to be much more clear, but to the = above point that's not an issue. I'm not suggesting the browser be allowed= to do this RTP-based verification for any and all use-cases. I'm only sug= gesting it to handle the large population of legacy VoIP devices, including= to the PSTN. Video without audio, or any future data-type streams, would = not apply and we don't need to handle them this way and can restrict the br= owser from allowing it. -hadriel From jdrosen@jdrosen.net Thu Jul 28 09:58: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 C44F721F8BB4 for ; Thu, 28 Jul 2011 09:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, 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 csM0H5NILwLV for ; Thu, 28 Jul 2011 09:58:07 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.48.15]) by ietfa.amsl.com (Postfix) with ESMTP id 14CC321F8BB3 for ; Thu, 28 Jul 2011 09:58:07 -0700 (PDT) Received: from dhcp-133f.meeting.ietf.org ([130.129.19.63]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QmTuQ-0008WU-Ea for rtcweb@ietf.org; Thu, 28 Jul 2011 12:58:06 -0400 Message-ID: <4E31951E.1080108@jdrosen.net> Date: Thu, 28 Jul 2011 12:58:06 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:58:07 -0000 Let me suggest a variation on this.. The rtcweb client can send RTP packet, voice-only, for a brief period of time (say, 2x the RTCP interval). It waits to receive an RTCP packet. The RTCP packet should have an RR which reflects back the SSRC sent by the client, if it does, the rtcweb client continues. If not, it stops sending. The purpose of the RTCP SSRC check is to emulate what the STUN transaction ID provides; that there is something on the media path which is expecting this RTP packet. Not as good as STUN which also has the short term credential, but its something. Thanks, Jonathan R. On 7/28/11 3:52 AM, Hadriel Kaplan wrote: > Howdy, > With regard to mandating ICE, such that an RTCWEB browser cannot send RTP without doing ICE successfully first... is that restriction purely to prevent the voice-hammer attacks? If so, then it's unfortunate because obviously it would seriously reduce interop with non-RTCWEB VoIP devices. But I think there's a way to prevent the hammer attack without using ICE, and without requiring legacy VoIP devices to change whatsoever. > > One way would be to use the receipt of RTP as an indicator the far-end expects to receive it from you. So have the browser generate RTP/RTCP packets, at a relatively slow rate, for a short duration (e.g., use the same rate/retransmit timers of STUN connectivity checks in ICE). If the browser receives RTP/RTCP packets, then the far-end expected to receive them as well and the browser can do normal RTP from then on. > > If this was a hammer attack, this doesn't generate any more load on the target than ICE, since ICE would have sent X number of STUN packets for Y time as well, and I'm suggesting the X and Y be the same values for the initial RTP packets during the "check" phase. > > The major weakness of this approach is that a malicious web-server trying to get your browser to do the voice hammer could send RTP to your browser, since it knows the address/ports of both sides, codec payload types, etc. (i.e., it can spoof being the attack target to make your browser think it's ok to do normal RTP) But we could probably play games with RTCP SR/RR or even just require continued RTP receipt to send RTP, in order to mitigate this weakness or make it of low value to exploit. > > Does anyone else care about interop-ing with legacy non-RTCWEB voip devices? I checked draft-ietf-rtcweb-use-cases-and-requirements-01 and I don't see it, so I'm not sure. > > -hadriel > > _______________________________________________ > 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 HKaplan@acmepacket.com Thu Jul 28 10:07: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 8F3CD11E8095 for ; Thu, 28 Jul 2011 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7eCnxUqfzwa for ; Thu, 28 Jul 2011 10:07:40 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1731821F880C for ; Thu, 28 Jul 2011 10:07:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 13:07:49 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 13:07:38 -0400 From: Hadriel Kaplan To: Jonathan Rosenberg Date: Thu, 28 Jul 2011 13:07:36 -0400 Thread-Topic: [rtcweb] Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxNSNnONZ06rkPvRrW1HW4ZbnH0Zw== Message-ID: <445CB6A5-F1B6-4553-9E95-16F7D4CF8C4D@acmepacket.com> References: <4E31951E.1080108@jdrosen.net> In-Reply-To: <4E31951E.1080108@jdrosen.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 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:07:40 -0000 On Jul 28, 2011, at 12:58 PM, Jonathan Rosenberg wrote: > Let me suggest a variation on this.. >=20 > The rtcweb client can send RTP packet, voice-only, for a brief period of= =20 > time (say, 2x the RTCP interval). It waits to receive an RTCP packet.=20 > The RTCP packet should have an RR which reflects back the SSRC sent by=20 > the client, if it does, the rtcweb client continues. If not, it stops=20 > sending. >=20 > The purpose of the RTCP SSRC check is to emulate what the STUN=20 > transaction ID provides; that there is something on the media path which= =20 > is expecting this RTP packet. Not as good as STUN which also has the=20 > short term credential, but its something. >=20 I had considered using the SSRC before, but I think you're gonna have to le= t the javascript know the SSRC to handle some SIP/SDP usages (since there's= an SSRC attribute for SDP, I assume someone needs it). No? -hadriel From matthew.kaufman@skype.net Thu Jul 28 10:18: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 95A6711E80D4 for ; Thu, 28 Jul 2011 10:18:57 -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 HHm5c-AAO1RS for ; Thu, 28 Jul 2011 10:18:56 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEC411E80D0 for ; Thu, 28 Jul 2011 10:18:56 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B6ED416E2; Thu, 28 Jul 2011 19:18:55 +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=b4 jgXFunRhwSQ+xWEg+1m0iwA2I=; b=xL8NhgKbYsypBV3H3pCGhHYPOqqDnduYdz DDPZ7dPNTSrpkm2a/B+0Lh7KeIjksN+Q0DXhZTJe68x6m/LlcK344T1H1jEQ7wA7 fkVID4/YCOj4W2vy+BvK1EKm1oI4VBMgPauLNJ0xtrDpZGmTlKsaD3+efP+oJ6sY SukwpC9Ng= 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=Gmh38z+4FY9zr09xgL/WHu t/8Ke3dsu1wFdMAuwxvvqRnuYkkNigI8HfR1ta+VM0MPkOSGNbm7UTv6rNav6tg/ Y6RktLwWfjwJTnH8k5N4Surp+ZjzgubcgQZsJzkX4l/duzQN9VaOJZHIS/pE4dCT 54O8ZKR4grUfaUr84KWxY= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id AC3017FC; Thu, 28 Jul 2011 19:18:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 922C9350811F; Thu, 28 Jul 2011 19:18:55 +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 dQ65xMTUL18G; Thu, 28 Jul 2011 19:18:54 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id 1307A3508130; Thu, 28 Jul 2011 19:18:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Thu, 28 Jul 2011 13:18:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 17:18:57 -0000 On Jul 28, 2011, at 11:13 AM, Hadriel Kaplan wrote: >=20 > On Jul 28, 2011, at 8:25 AM, Matthew Kaufman wrote: >=20 >>> Secondly, if interworking with legacy SIP, where DTLS-SRTP (or = whatever we select) is terminated at a gateway, there is a real problem = ensuring that the user knows the call is not necessarily secure = end-to-end. Perhaps this argues towards option B, since if DTLS-SRTP is = not used from browser to gateway, at least the browser should know to = indicate a lesser level of security to the user. >>=20 >> If you are sitting in an Internet cafe using someone else's = unencrypted wifi and a telephony service provider you trust would you = rather 1) use DTLS-SRTP between you and the telephony provider and plain = RTP past their gateway inside their internal network, or 2) use plain = RTP on the wifi network and all the way to the telephony provider? >=20 > I would be perfectly happy with using sdes-based SRTP. But if the = call would otherwise fail altogether, I'd like the option to make the = call no matter what (ie, even if it ends up being cleartext). Why would the call "otherwise fail altogether"? >=20 > (And since you're sitting in an Internet cafe in hearing distance of = everyone, any sense of privacy is gone anyway. ;) >=20 Have you ever called into a conference call from a public place, with = your microphone muted? >=20 >> I agree that we can't display "this connection is secured everywhere" = to the user... but look, HTTPS is the same. When I see a lock icon on my = screen and click to see that yes, I'm really talking to who it says in = the address bar, I still can't tell if they're terminating my HTTPS = session in a front-end box and then using HTTP beyond it, or if the = HTTPS really goes all the way to the server. >=20 > But the browser ties the identity of the name I typed in the address = bar to the cert, so that if I typed "https://mybank.com", I know it's = secure to mybank.com. Of course it could be cleartext after whomever = has a cert for mybank.com, and may even end up triggering protocols that = exit mybank.com and go to evil.com, but I implicitly trust mybank.com to = be careful with bank info. =20 Ok, so you trust your "banking service". > That's not the same for DTLS-SRTP; until and unless the human being = verifies the keys/SAS with the far end, nothing is known. If you trust your "calling service" (and are connected to it with HTTPS) = then you can use that trusted service to exchange the fingerprints and = verify the keys of the far end to prevent MITM. (You can also add a browser extension that uses a service that you trust = but that isn't your calling service, and when you're calling other = people with the same extension you can check the fingerprints in an = automated way using that.) If you *don't* trust your "calling service", then that's just like not = trusting your banking service when you type in passwords. > The DTLS-SRTP may only reach the NAT-router in the Internet Cafe, for = example, be terminated by it and a separate DTLS-SRTP between it and the = bank. And if I'm talking to an IVR system (as one frequently does with = banks), there is no human to verify the keys/SAS with. Correct. But there is a signaling channel, and if you trust it you can = assure that there is no router doing MITM at the cafe. Perhaps you'll = even be calling your bank's IVR using *their* calling service... Matthew Kaufman From harald@alvestrand.no Thu Jul 28 10:22: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 375FD21F8BA2 for ; Thu, 28 Jul 2011 10:22:11 -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 LM3kNLAeKOcJ for ; Thu, 28 Jul 2011 10:22:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4F721F8B17 for ; Thu, 28 Jul 2011 10:22:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E85039E173 for ; Thu, 28 Jul 2011 19:20:59 +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 851egv0blJ-0 for ; Thu, 28 Jul 2011 19:20:59 +0200 (CEST) Received: from [130.129.103.155] (dhcp-679b.meeting.ietf.org [130.129.103.155]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D3ADD39E13B for ; Thu, 28 Jul 2011 19:20:58 +0200 (CEST) Message-ID: <4E319ABD.9070604@alvestrand.no> Date: Thu, 28 Jul 2011 13:22:05 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> In-Reply-To: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 17:22:11 -0000 Question that I could probably answer if I understood the DH key exchange thing: Is it possible for anyone with packet-replacement access to the media path to perform a MITM attack against DH? If so: Is it possible to deliver some token by the "high path" (where the SDES keys would go) that ensures that the DH key exchange is with someone possessing that token? That would limit MITM attacks to attackers who had access to both the "high path" and the media path. Harald From ekr@rtfm.com Thu Jul 28 10: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 75D3611E80FB for ; Thu, 28 Jul 2011 10:28:17 -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=[AWL=-0.000, 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 JYfIOCrQCIGN for ; Thu, 28 Jul 2011 10:28:17 -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 2462911E80E5 for ; Thu, 28 Jul 2011 10:28:14 -0700 (PDT) Received: by wwe5 with SMTP id 5so1831944wwe.13 for ; Thu, 28 Jul 2011 10:28:14 -0700 (PDT) Received: by 10.227.208.197 with SMTP id gd5mr358234wbb.22.1311874094153; Thu, 28 Jul 2011 10:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 10:27:54 -0700 (PDT) In-Reply-To: <4E319ABD.9070604@alvestrand.no> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <4E319ABD.9070604@alvestrand.no> From: Eric Rescorla Date: Thu, 28 Jul 2011 13:27:54 -0400 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 17:28:17 -0000 That's effectively what DTLS-SRTP does. -Ekr On Thu, Jul 28, 2011 at 1:22 PM, Harald Alvestrand w= rote: > Question that I could probably answer if I understood the DH key exchange > thing: > > Is it possible for anyone with packet-replacement access to the media pat= h > to perform a MITM attack against DH? > > If so: Is it possible to deliver some token by the "high path" (where the > SDES keys would go) that ensures that the DH key exchange is with someone > possessing that token? > > That would limit MITM attacks to attackers who had access to both the "hi= gh > path" and the media path. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From matthew.kaufman@skype.net Thu Jul 28 10:29: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 98C1E11E80FC for ; Thu, 28 Jul 2011 10:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDPTNiS+oCzO for ; Thu, 28 Jul 2011 10:29:38 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id A905D11E80D0 for ; Thu, 28 Jul 2011 10:29:37 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EF8F016FF; Thu, 28 Jul 2011 19:29:36 +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=Sa 6CS9AAijbSy3JryAkLTG10p/k=; b=df9jzDKfvBvRaHcePe5R1y7PQqJfre4PIo mtJRTDYDO8C8SByP+u+HX0G+yFS9ckrba4W/vmTXJxfaZl47RZFG34cFACvBDtOJ 6dPOMbHOcbi+apCk2LVWtltx6iXT09kEe4GW8CguVerhqe//9QuDU/DXwOkG1Mbo bVQAOUJEE= 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=H2tWe3kgKz4mVVWGtD4BNi tflINOXGMNf8zfe63C3ClLvBEzFUsugZf9IK91/Z6iHHSeWaoYBwR96jOthMgryv UX+4m7sCdKk/kzsBsyoBWBR1HOf96/6cvuExWM0B1K4Oha28rqURs0Acnkd04ibx GXOJMfhOQOMumem/3agZk= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E4A397F8; Thu, 28 Jul 2011 19:29:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CA7F23508109; Thu, 28 Jul 2011 19:29:36 +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 8JRLCE83pyIH; Thu, 28 Jul 2011 19:29:36 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id 882113508113; Thu, 28 Jul 2011 19:29:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Thu, 28 Jul 2011 13:29:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D6E4E5F-E1E4-47FB-8D8D-F3D9976AC29E@skype.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:29:38 -0000 On Jul 28, 2011, at 11:58 AM, Hadriel Kaplan wrote: >=20 > On Jul 28, 2011, at 7:38 AM, Matthew Kaufman wrote: >=20 >>=20 >> This is not as safe. There are devices/software that do things upon = receipt of RTP packets (like play them out through loudspeakers, or = initiate ringing of the softphone), and more important RTP packets are = not carefully designed to avoid imitating other types of traffic such as = SNMP, whereas STUN packets contain a relatively large header with a = magic number that makes them much less likely to be misinterpreted by = other protocols. >=20 > No it's not as "safe", but it may be safe enough. =20 I disagree. You need both 1) a large number of bits of transaction ID = (on the order of the 128 bits provided by STUN), and 2) a shared secret = passed out of band between the two ends (for example, the short term = credentials used by STUN connectivity checks). Failing to provide both of the above opens possibilities for attacks = that I believe will not be acceptable to browser vendors due to the = relative danger of exposing this capability "behind the firewall." > With regards to being misinterpreted by others, since the web server = javascript cannot define the actual payload of the RTP (correct?) If datagrams are also allowed, a remarkable amount of the data being = sent can be chosen from the Javascript. The datagram proposals assume = that ICE is used to get consent ahead of time. > , and things like sequence numbers would also be randomly chosen by = the browser, so it's not like the javascript can purposefully craft an = RTP packet to immitate other protocols. For example it would be an = astronmoical coincidence for any given RTP packet to be parsable as SNMP = BER for a given ASN.1 dictionary. > (Also as an aside, if I recall correctly SNMP is actually = distinguishable from RTP by the first byte) >=20 >=20 >> Additionally the STUN connectivity check used for ICE contains = short-term credentials and a transaction ID that is unknown to the = signaling layer (or Javascript) that ensure that you are in fact = conducting a pairwise negotiation with the far end that you are thinking = of. With RTP/RTCP packets alone you can create attacks both from the = browser (by sending RTP/RTCP and using something else to spoof enough = replies that the test passes) or on the browser (by sending it RTP from = somewhere else). >=20 > If we used RTCP as part of the check, the reports contain a last = received sequence number which would not be known to the javascript. = (it's a hack to be sure, but if we want to handle non-RTCWEB devices, a = hack's better than nothing) I don't believe this is enough bits, and it lacks the shared secret = mechanism. >=20 >=20 >> And of course ICE, or something like it, is required anyway for doing = NAT traversal. >=20 > Not when communicating with legacy voip devices and the PSTN. Correct, but my point is that the ICE implementation must exist. >=20 >=20 >> I don't believe this is the case. There's so many cases where one = side sends A+V but the other side sends audio only, and sending = HD-video-rate traffic to an unsuspecting endpoint is unacceptable. >=20 > I should probably write it up in a draft to be much more clear, but to = the above point that's not an issue. I'm not suggesting the browser be = allowed to do this RTP-based verification for any and all use-cases. = I'm only suggesting it to handle the large population of legacy VoIP = devices, including to the PSTN. Video without audio, or any future = data-type streams, would not apply and we don't need to handle them this = way and can restrict the browser from allowing it. Again, I don't think it provides adequate protection to the other = devices on the network behind the firewall that the browser is on. But = do please write your proposal up in more detail. Matthew Kaufman From matthew.kaufman@skype.net Thu Jul 28 10:30: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 0AD4621F8B6A for ; Thu, 28 Jul 2011 10:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyEXdqc5gyy3 for ; Thu, 28 Jul 2011 10:30:40 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8300A21F8B6E for ; Thu, 28 Jul 2011 10:30:40 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id CA6751711; Thu, 28 Jul 2011 19:30:39 +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=7r uzpW1QlUwv+gANpR9BFWRSLSs=; b=WFFC8Fg9KsfAFjKDFTSLCKFeqyg+kzxAxC MjTumPtylcej+66d7xubCvq/q4anvHUhjXm9kEmLe0SxvutfjY0UzkpN/ze3vEjw 9N5F5x1LsAxtZevl/yqBWfcHfRaSAiJeHT1dl2TcSX/hKJtgjnW/GnvFv083LsbO vPAwQavPE= 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=BM6D5d8+kAx4czr7oaPK64 WIYld1Jkw2xR+RXLe3dGVWv6VLy5d30glXaoA0fFP31g+vXLwkb/683RRCMtVjxd UIVXLb5e9a7a8Wt7SLTKoMdyiFIxXN4Q78Ufch/OTM1uMAWs32DgqbLEQB5MRzfk 3bK2FgWoB/nSD1nrtl5AY= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C8FC47F8; Thu, 28 Jul 2011 19:30:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B177A3508145; Thu, 28 Jul 2011 19:30:39 +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 YEvCQ8PbypHQ; Thu, 28 Jul 2011 19:30:39 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id B97FF3508138; Thu, 28 Jul 2011 19:30:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <4E31951E.1080108@jdrosen.net> Date: Thu, 28 Jul 2011 13:30:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <92DE2A51-4E57-4B5F-A65A-DAB5C7317D08@skype.net> References: <4E31951E.1080108@jdrosen.net> To: Jonathan Rosenberg X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:30:41 -0000 On Jul 28, 2011, at 12:58 PM, Jonathan Rosenberg wrote: > Let me suggest a variation on this.. >=20 > The rtcweb client can send RTP packet, voice-only, for a brief period = of time (say, 2x the RTCP interval). It waits to receive an RTCP packet. = The RTCP packet should have an RR which reflects back the SSRC sent by = the client, if it does, the rtcweb client continues. If not, it stops = sending. >=20 > The purpose of the RTCP SSRC check is to emulate what the STUN = transaction ID provides; that there is something on the media path which = is expecting this RTP packet. Not as good as STUN which also has the = short term credential, but its something. Lacks both the short term credential and is not enough bits to protect = against attackers who can generate a flurry of forged RTCP packets. See = my previous email. Matthew Kaufman From matthew.kaufman@skype.net Thu Jul 28 10:32: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 6E00421F8C17 for ; Thu, 28 Jul 2011 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 kTN+F++JK-qa for ; Thu, 28 Jul 2011 10:32:21 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id BFACD21F8C13 for ; Thu, 28 Jul 2011 10:32:21 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 138D216E2; Thu, 28 Jul 2011 19:32:21 +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=JW p4vrnyTazwqzY8qzEljB1czDI=; b=YKZtudvKrq858EYtIQY+oae0GiEe6AcQjs 8P//taZVFekFeGwVlRHxfmLxNsa+vs5KPL52h9o6khL7VIBXbiqNL6ZQIYwRMp8V mWV4frBaCZ7k7/DR6yDNXA5KPJrDUUhnmJgv7CFOq+RGMTtk+7VGrhXOmNJ4b4sI T2ig9+l3g= 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=XwmN+1LUgrz6//wz+axb5n uZUKPE4rewTChQz8sho5tICEBwMB+gWm5sKEsaZvzTFwHE/hBOxE6lfH8F9Daqm8 IGzkoVVBleIWbxMZgdO9ot2sXakXOIeFyNCvPrnUc9goGuSi8lZhEGLddIV31DAr LYkXFzUTOgwWl5B8c/yJg= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 122D87F8; Thu, 28 Jul 2011 19:32:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E2E7735080C3; Thu, 28 Jul 2011 19:32:20 +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 fS3Mld2NZcFt; Thu, 28 Jul 2011 19:32:20 +0200 (CEST) Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id C2EE63507F82; Thu, 28 Jul 2011 19:32:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <4E319ABD.9070604@alvestrand.no> Date: Thu, 28 Jul 2011 13:32:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15AFE3C5-8F77-435B-B6DB-E0D081BA9ED2@skype.net> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <4E319ABD.9070604@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 17:32:22 -0000 On Jul 28, 2011, at 1:22 PM, Harald Alvestrand wrote: > Question that I could probably answer if I understood the DH key = exchange thing: >=20 > Is it possible for anyone with packet-replacement access to the media = path to perform a MITM attack against DH? Yes. >=20 > If so: Is it possible to deliver some token by the "high path" (where = the SDES keys would go) that ensures that the DH key exchange is with = someone possessing that token? You can do that, or you can check the fingerprints via the high path to = authenticate each end and prove that there's no MITM on the media path. >=20 > That would limit MITM attacks to attackers who had access to both the = "high path" and the media path. >=20 Correct. And the high path can be protected with HTTPS and the = associated PKI. Matthew Kaufman From stewe@stewe.org Thu Jul 28 12:54: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 69CF711E814D for ; Thu, 28 Jul 2011 12:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_20=-0.74, 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 Le8HowH7SQEh for ; Thu, 28 Jul 2011 12:54:04 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 554FE11E811A for ; Thu, 28 Jul 2011 12:54:02 -0700 (PDT) Received: from [130.129.70.103] (unverified [130.129.70.103]) by stewe.org (SurgeMail 3.9e) with ESMTP id 18796-1743317 for ; Thu, 28 Jul 2011 21:54:00 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Jul 2011 15:53:54 -0400 From: Stephan Wenger To: "rtcweb@ietf.org" Message-ID: Thread-Topic: VP8 royalty free? Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3394713240_1517471" X-Originating-IP: 130.129.70.103 X-Authenticated-User: stewe@stewe.org Subject: [rtcweb] VP8 royalty free? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 19:54:04 -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_3394713240_1517471 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, In today's session, someone characterized VP8 as "royalty free". On this subject, some of you may find the linked blog post (and the article linked therein) interesting. It was posted today, during our session. To summarize, DOJ probe or not, MPEG-LA continues its efforts to form an (presumably royalty-bearing) patent pool for VP8, they had initial pool member meeting sometime in June, and talk about 12 potential member companies. http://fosspatents.blogspot.com/2011/07/googles-webm-vp8-allegedly-infringes .html Regards, Stephan --B_3394713240_1517471 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,
= In today's session, someone characterized VP8 as "royalty free".  On th= is subject, some of you may find the linked blog post (and the article linke= d therein) interesting.  It was posted today, during our session.  = ;To summarize, DOJ probe or not, MPEG-LA continues its efforts to form an (p= resumably royalty-bearing) patent pool for VP8, they had initial pool member= meeting sometime in June, and talk about 12 potential member companies.
http://fossp= atents.blogspot.com/2011/07/googles-webm-vp8-allegedly-infringes.html=
Regards,
Stephan

--B_3394713240_1517471-- From harald@alvestrand.no Thu Jul 28 13:49: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 BCEB921F8AEE for ; Thu, 28 Jul 2011 13:49:49 -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 avu63rAUNEY1 for ; Thu, 28 Jul 2011 13:49:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D695F21F8AC9 for ; Thu, 28 Jul 2011 13:49:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1141E39E173 for ; Thu, 28 Jul 2011 22:48:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxGWMVIHuFmp for ; Thu, 28 Jul 2011 22:48:39 +0200 (CEST) Received: from [130.129.103.155] (dhcp-679b.meeting.ietf.org [130.129.103.155]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E28E139E13B for ; Thu, 28 Jul 2011 22:48:38 +0200 (CEST) Message-ID: <4E31CB69.7020006@alvestrand.no> Date: Thu, 28 Jul 2011 16:49:45 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 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] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:49:49 -0000 On 07/28/11 03:52, Hadriel Kaplan wrote: > Howdy, > With regard to mandating ICE, such that an RTCWEB browser cannot send RTP without doing ICE successfully first... is that restriction purely to prevent the voice-hammer attacks? If so, then it's unfortunate because obviously it would seriously reduce interop with non-RTCWEB VoIP devices. But I think there's a way to prevent the hammer attack without using ICE, and without requiring legacy VoIP devices to change whatsoever. > > One way would be to use the receipt of RTP as an indicator the far-end expects to receive it from you. So have the browser generate RTP/RTCP packets, at a relatively slow rate, for a short duration (e.g., use the same rate/retransmit timers of STUN connectivity checks in ICE). If the browser receives RTP/RTCP packets, then the far-end expected to receive them as well and the browser can do normal RTP from then on. > > If this was a hammer attack, this doesn't generate any more load on the target than ICE, since ICE would have sent X number of STUN packets for Y time as well, and I'm suggesting the X and Y be the same values for the initial RTP packets during the "check" phase. > > The major weakness of this approach is that a malicious web-server trying to get your browser to do the voice hammer could send RTP to your browser, since it knows the address/ports of both sides, codec payload types, etc. (i.e., it can spoof being the attack target to make your browser think it's ok to do normal RTP) But we could probably play games with RTCP SR/RR or even just require continued RTP receipt to send RTP, in order to mitigate this weakness or make it of low value to exploit. I think this approach is not paranoid enough. The attacker will negotiate a channel claiming that you can reach him on 10.0.0.2 (your server that he wants to voice-hammer), and then send you the five or so RTP packets you expect with a fake source address of 10.0.0.2. Then you, having seen exactly the packets that "authorize" sending traffic to 10.0.0.2, will be performing the voice-hammer attack against the server that the attacker otherwise couldn't reach. You would have to send RTP packets yourself (which will correctly be dropped on the floor by 10.0.0.2) until the time at which you can start wondering about there being no RTCP packets from 10.0.0.2 in order to have a 2-way handshake - and that only works if the RTCP RR contains enough stuff the attacker can't predict that he can't just generate the RTCP too. (This doesn't work with ICE, because the ICE handshake involves the recipient replying to your packet with some parameters that can only be found in the request, not in the negotiation). > Does anyone else care about interop-ing with legacy non-RTCWEB voip devices? I checked draft-ietf-rtcweb-use-cases-and-requirements-01 and I don't see it, so I'm not sure. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From randell1@jesup.org Thu Jul 28 14:56: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 C468211E807E for ; Thu, 28 Jul 2011 14:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XC769hWaKuL for ; Thu, 28 Jul 2011 14:56:09 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id D846721F8658 for ; Thu, 28 Jul 2011 14:56:09 -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 1QmYYr-0006Mr-E2 for rtcweb@ietf.org; Thu, 28 Jul 2011 16:56:09 -0500 Message-ID: <4E31DAAB.5030606@jesup.org> Date: Thu, 28 Jul 2011 17:54:51 -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: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> In-Reply-To: <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.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] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 21:56:10 -0000 On 7/28/2011 1:18 PM, Matthew Kaufman wrote: > we can't display "this connection is secured everywhere" to the user... but look, HTTPS is the same. When I see a lock icon on my screen and click to see that yes, I'm really talking to who it says in the address bar, I still can't tell if they're terminating my HTTPS session in a front-end box and then using HTTP beyond it, or if the HTTPS really goes all the way to the server. >> But the browser ties the identity of the name I typed in the address bar to the cert, so that if I typed "https://mybank.com", I know it's secure to mybank.com. Of course it could be cleartext after whomever has a cert for mybank.com, and may even end up triggering protocols that exit mybank.com and go to evil.com, but I implicitly trust mybank.com to be careful with bank info. > Ok, so you trust your "banking service". And more to the point, you trust the chain of certificates incorporated into the browser to verify it's actually the entity that owns mybank.com (and EV certs come into play here too). Overall, that's a "good" chain of trust, though no such chain is perfect. >> That's not the same for DTLS-SRTP; until and unless the human being verifies the keys/SAS with the far end, nothing is known. > If you trust your "calling service" (and are connected to it with HTTPS) then you can use that trusted service to exchange the fingerprints and verify the keys of the far end to prevent MITM. Right, this is trusting that not only they are who they say they are, but also trusting that they haven't been compromised. And one may not have the same level of trust in that that you have (have to have) in your bank. > (You can also add a browser extension that uses a service that you trust but that isn't your calling service, and when you're calling other people with the same extension you can check the fingerprints in an automated way using that.) Definitely possible, and adds another largely-independent layer of trust. > If you *don't* trust your "calling service", then that's just like not trusting your banking service when you type in passwords. I may trust my calling service to connect me (to someone), but I may not trust them to not MITM me themselves (read CALEA or other national security services), and I may not trust them not to be compromised, since they have a far smaller monetary stake in avoiding it compared to a bank. Another idea related to identity: as mentioned, the cert trust chain in a browser verifies that you're talking to mybank.com or myprovider.com. This can be leveraged to provide authentication by cert that you're talking to someone who's part of mybank.com, even if you went through myprovider.com to get there and myprovider.com might be compromised. It doesn't directly help verify you're talking to Joe Your Neighbor, but other services can help with that (as mentioned - extensions, etc). Effectively, for a fairly large subset of the net, we have a deployed PKI of a form. It's not perfect (DNSSEC anyone; recent todo with bogus certs because a CA snafu) but for most uses that it covers it's pretty good. Getting it to cover identifying the destination as a dependent of the primary cert may be an issue for many companies, however. In any case, there may be a way to leverage this existing trust chain, both to authenticate who's calling you and who you're calling, for a subset of possible destinations. -- Randell Jesup randell-ietf@jesup.org From randell1@jesup.org Thu Jul 28 15: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 5A72221F885C for ; Thu, 28 Jul 2011 15:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 qqObUzC8VSaN for ; Thu, 28 Jul 2011 15:17:01 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id CB35321F87BC for ; Thu, 28 Jul 2011 15:17:01 -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 1QmYt3-0000dZ-4q for rtcweb@ietf.org; Thu, 28 Jul 2011 17:17:01 -0500 Message-ID: <4E31DF8E.6060602@jesup.org> Date: Thu, 28 Jul 2011 18:15:42 -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: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> <4E31DAAB.5030606@jesup.org> In-Reply-To: <4E31DAAB.5030606@jesup.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] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 22:17:02 -0000 On 7/28/2011 5:54 PM, Randell Jesup wrote: >> (You can also add a browser extension that uses a service that you >> trust but that isn't your calling service, and when you're calling >> other people with the same extension you can check the fingerprints >> in an automated way using that.) > > Definitely possible, and adds another largely-independent layer of trust. > Replying to myself with something the Mozilla team was thinking about (we may come back with more on this later, after talking to the people here about it): an example of an independent layer of identity trust would be the just-announced BrowserID initiative: https://browserid.org/ The plan is to move this into the browser itself. Also see http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in Perhaps the browserid data could be used to facilitate authentication of SAS data, for example. -- Randell Jesup randell-ietf@jesup.org From eckelcu@cisco.com Thu Jul 28 15:24: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 625CA5E8036 for ; Thu, 28 Jul 2011 15:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=-0.283, 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 1o45pbA0H9oH for ; Thu, 28 Jul 2011 15:24:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 47B245E8007 for ; Thu, 28 Jul 2011 15:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1702; q=dns/txt; s=iport; t=1311891893; x=1313101493; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=eiYpffmamegykLIxVtVynt38t2b9Ka+BpQHZFFnRjiw=; b=AdIuJl+BUUHbx0HmuT+hwExWHDURheufaBF7bWDUuAY2iOp+MKcNp/o0 cacRbTyBNpM/gQwerl+ju46CwYiAZf/3nRvOAMYujrz85RFD9ByfLAipm xHI2GP602EJsbeSWLbI/9muwyzW1+CC6S3oX4VtHoQ7QRjU8d9fSUJJCM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAAIPgMU6rRDoG/2dsb2JhbAA1AQEBAQMBAQERASEKOhcFAgEJEQQBAQsGIwEGARMYIw4IAQEFARYMG5drj0p3iQCkSZ47hWJfBIdZkDCLdA X-IronPort-AV: E=Sophos;i="4.67,284,1309737600"; d="scan'208";a="7570384" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jul 2011 22:24:52 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SMOqgp029616; Thu, 28 Jul 2011 22:24:52 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 15:24:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 15:24:44 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Possible new use case Thread-Index: AcxL0J/zCRj4YbfDSkqYoi0HHxuLMwBpFevg References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 28 Jul 2011 22:24:46.0900 (UTC) FILETIME=[28449F40:01CC4D75] Subject: Re: [rtcweb] Possible new 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: Thu, 28 Jul 2011 22:24:54 -0000 Hi John, I am interested in this use case and would be interested in seeing it added. Cheers, Charles > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, July 26, 2011 4:14 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Possible new use case >=20 > (Not sure whether this should go to the W3C list, but trying the IETF list to start with) >=20 > I raised this during the WEBRTC session on Saturday. >=20 > Does anyone have any interest in adding a use case concerning recording of real-time media at a remote > recorder? I noticed something on local recording in the proposed APIs, but remote recording might have > other impacts, e.g., > - taking a stream from a capture device (mic, camera) and sending it not only to the remote browser > but also to a remote recorder; > - taking a stream from the remote browser and sending it to a remote recorder (as well as rendering > locally); > - possibly mixing the two streams (in case of audio) and sending as a single mixed stream to the > recording device. >=20 > John >=20 >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Thu Jul 28 15:33: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 6F21B21F8B46 for ; Thu, 28 Jul 2011 15:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 8G9GhkJlZZIE for ; Thu, 28 Jul 2011 15:33:29 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 74B1921F8B44 for ; Thu, 28 Jul 2011 15:33:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 18:33:24 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 18:33:25 -0400 From: Hadriel Kaplan To: Matthew Kaufman Date: Thu, 28 Jul 2011 18:33:25 -0400 Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying Thread-Index: AcxNdl0UBQd2oD5YRaqoISnq52DJjQ== Message-ID: References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <4E319ABD.9070604@alvestrand.no> <15AFE3C5-8F77-435B-B6DB-E0D081BA9ED2@skype.net> In-Reply-To: <15AFE3C5-8F77-435B-B6DB-E0D081BA9ED2@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 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 22:33:39 -0000 On Jul 28, 2011, at 1:32 PM, Matthew Kaufman wrote: >=20 > On Jul 28, 2011, at 1:22 PM, Harald Alvestrand wrote: >=20 >> Question that I could probably answer if I understood the DH key exchang= e thing: >>=20 >> Is it possible for anyone with packet-replacement access to the media pa= th to perform a MITM attack against DH? >=20 > Yes. >=20 >>=20 >> If so: Is it possible to deliver some token by the "high path" (where th= e SDES keys would go) that ensures that the DH key exchange is with someone= possessing that token? >=20 > You can do that, or you can check the fingerprints via the high path to a= uthenticate each end and prove that there's no MITM on the media path. That's assuming the high path itself is secure end-to-end. Since this grou= p has already agreed to allow HTTP rather than mandate HTTPS, and since it = can go from your web service to SIP and beyond, such a guarantee is hard to= enforce. -hadriel From HKaplan@acmepacket.com Thu Jul 28 15:44: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 8B1BB21F8BC6 for ; Thu, 28 Jul 2011 15:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 TifTTYSdRfFJ for ; Thu, 28 Jul 2011 15:44:44 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7321F8BAE for ; Thu, 28 Jul 2011 15:44:44 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 18:44:42 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 18:44:41 -0400 From: Hadriel Kaplan To: Matthew Kaufman Date: Thu, 28 Jul 2011 18:44:40 -0400 Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying Thread-Index: AcxNd++lpPrqtkVhTlO9eGXXsWSGuQ== Message-ID: References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> In-Reply-To: <55C78CA7-292C-4E0E-901B-83B7614C2F32@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 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 22:44:45 -0000 On Jul 28, 2011, at 1:18 PM, Matthew Kaufman wrote: >=20 > On Jul 28, 2011, at 11:13 AM, Hadriel Kaplan wrote: >=20 >> I would be perfectly happy with using sdes-based SRTP. But if the call = would otherwise fail altogether, I'd like the option to make the call no ma= tter what (ie, even if it ends up being cleartext). >=20 > Why would the call "otherwise fail altogether"? Because I'm calling someone who has a legacy VoIP device or is on the PSTN,= and they're not going to support DTLS-SRTP. Of course we could require the RTCWEB service to deploy "gateways" in order= to terminate DTLS-SRTP and do SDES-based SRTP or cleartext RTP to non-RTCW= EB, but that's expensive and complex. Not to mention its mis-leading - the= media is not secure end-to-end, and again the lock-icon model won't work. > Have you ever called into a conference call from a public place, with you= r microphone muted? Nah, I talk too much. ;) -hadriel p.s. Of course I'm speaking as an individual - my employer would probably b= e ecstatic with requiring such gateways.=20 From HKaplan@acmepacket.com Thu Jul 28 15:55: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 2215F21F874E for ; Thu, 28 Jul 2011 15:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 hPNYs1xqXtvO for ; Thu, 28 Jul 2011 15:55:48 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8075821F8733 for ; Thu, 28 Jul 2011 15:55:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Jul 2011 18:55:47 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jul 2011 18:55:47 -0400 From: Hadriel Kaplan To: Harald Alvestrand Date: Thu, 28 Jul 2011 18:55:46 -0400 Thread-Topic: [rtcweb] Strawman for how to prevent voice-hammer without ICE Thread-Index: AcxNeXyEnTpPz/k9Q9efSDP7yQ3IHA== Message-ID: <1109B9FB-5432-4256-8A12-6DBABA048278@acmepacket.com> References: <4E31CB69.7020006@alvestrand.no> In-Reply-To: <4E31CB69.7020006@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 22:55:49 -0000 On Jul 28, 2011, at 4:49 PM, Harald Alvestrand wrote: > I think this approach is not paranoid enough. >=20 > The attacker will negotiate a channel claiming that you can reach him on= =20 > 10.0.0.2 (your server that he wants to voice-hammer), and then send you=20 > the five or so RTP packets you expect with a fake source address of=20 > 10.0.0.2. >=20 > Then you, having seen exactly the packets that "authorize" sending=20 > traffic to 10.0.0.2, will be performing the voice-hammer attack against=20 > the server that the attacker otherwise couldn't reach. Yes, that was the weakness of the model as I described in my original email= : that the malicious web-server can spoof the RTP from the device being att= acked. And I proposed that instead of it being a single "authorization" phase at t= he beginning of the call, it could even be continuous/periodic. Of course = the web-server could continuously send spoofed RTP to the browser, but at t= hat point it might as well do the attack directly spoofing the browser. (in= other words, the malicious website isn't gaining a very useful botnet of a= ttackers, since I assume that's the concern) > (This doesn't work with ICE, because the ICE handshake involves the=20 > recipient replying to your packet with some parameters that can only be=20 > found in the request, not in the negotiation). Yes I know ICE solves this, but since ICE doesn't exist for legacy VoIP and= PSTN, a non-existent solution isn't very useful. -hadriel From yuepeiyu@huawei.com Thu Jul 28 16:01: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 1BA3E5E8004 for ; Thu, 28 Jul 2011 16:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 SWiuVDn9q49d for ; Thu, 28 Jul 2011 16:01:43 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3621F88D9 for ; Thu, 28 Jul 2011 16:01:43 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200273FYTR7@szxga05-in.huawei.com> for rtcweb@ietf.org; Fri, 29 Jul 2011 07:01:41 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200LT2FYSML@szxga05-in.huawei.com> for rtcweb@ietf.org; Fri, 29 Jul 2011 07:01:41 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR48063; Fri, 29 Jul 2011 07:01:40 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 07:01:33 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 07:01:39 +0800 Date: Thu, 28 Jul 2011 23:01:38 +0000 From: "Roy Yue(PeiYu)" In-reply-to: X-Originating-IP: [172.24.2.41] To: "Charles Eckel (eckelcu)" , "Elwell, John" , "rtcweb@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [rtcweb] Possible new use case Thread-index: AcxL0J/zCRj4YbfDSkqYoi0HHxuLMwBpFevgAAFM54A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [rtcweb] Possible new 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: Thu, 28 Jul 2011 23:01:44 -0000 SGkgZm9sa3MsDQoNCisxDQpJIGFtIGFsc28gaW50ZXJlc3RlZCBpbiBzdWNoIHVzZSBjYXNlcy4N Cg0KUmVnYXJkcywNClJveQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFtydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBDaGFybGVzIEVja2VsIChlY2tlbGN1KSBbZWNrZWxjdUBjaXNjby5jb21dDQq3 osvNyrG85DogMjAxMcTqN9TCMjnI1SA2OjI0DQq1vTogRWx3ZWxsLCBKb2huOyBydGN3ZWJAaWV0 Zi5vcmcNCtb3zOI6IFJlOiBbcnRjd2ViXSBQb3NzaWJsZSBuZXcgdXNlIGNhc2UNCg0KSGkgSm9o biwNCg0KSSBhbSBpbnRlcmVzdGVkIGluIHRoaXMgdXNlIGNhc2UgYW5kIHdvdWxkIGJlIGludGVy ZXN0ZWQgaW4gc2VlaW5nIGl0DQphZGRlZC4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQpCZWhhbGYgT2YgRWx3ZWxsLCBKb2hu DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjYsIDIwMTEgNDoxNCBQTQ0KPiBUbzogcnRjd2ViQGll dGYub3JnDQo+IFN1YmplY3Q6IFtydGN3ZWJdIFBvc3NpYmxlIG5ldyB1c2UgY2FzZQ0KPg0KPiAo Tm90IHN1cmUgd2hldGhlciB0aGlzIHNob3VsZCBnbyB0byB0aGUgVzNDIGxpc3QsICBidXQgdHJ5 aW5nIHRoZSBJRVRGDQpsaXN0IHRvIHN0YXJ0IHdpdGgpDQo+DQo+IEkgcmFpc2VkIHRoaXMgZHVy aW5nIHRoZSBXRUJSVEMgc2Vzc2lvbiBvbiBTYXR1cmRheS4NCj4NCj4gRG9lcyBhbnlvbmUgaGF2 ZSBhbnkgaW50ZXJlc3QgaW4gYWRkaW5nIGEgdXNlIGNhc2UgY29uY2VybmluZw0KcmVjb3JkaW5n IG9mIHJlYWwtdGltZSBtZWRpYSBhdCBhIHJlbW90ZQ0KPiByZWNvcmRlcj8gSSBub3RpY2VkIHNv bWV0aGluZyBvbiBsb2NhbCByZWNvcmRpbmcgaW4gdGhlIHByb3Bvc2VkIEFQSXMsDQpidXQgcmVt b3RlIHJlY29yZGluZyBtaWdodCBoYXZlDQo+IG90aGVyIGltcGFjdHMsIGUuZy4sDQo+IC0gdGFr aW5nIGEgc3RyZWFtIGZyb20gYSBjYXB0dXJlIGRldmljZSAobWljLCBjYW1lcmEpIGFuZCBzZW5k aW5nIGl0DQpub3Qgb25seSB0byB0aGUgcmVtb3RlIGJyb3dzZXINCj4gYnV0IGFsc28gdG8gYSBy ZW1vdGUgcmVjb3JkZXI7DQo+IC0gdGFraW5nIGEgc3RyZWFtIGZyb20gdGhlIHJlbW90ZSBicm93 c2VyIGFuZCBzZW5kaW5nIGl0IHRvIGEgcmVtb3RlDQpyZWNvcmRlciAoYXMgd2VsbCBhcyByZW5k ZXJpbmcNCj4gbG9jYWxseSk7DQo+IC0gcG9zc2libHkgbWl4aW5nIHRoZSB0d28gc3RyZWFtcyAo aW4gY2FzZSBvZiBhdWRpbykgYW5kIHNlbmRpbmcgYXMgYQ0Kc2luZ2xlIG1peGVkIHN0cmVhbSB0 byB0aGUNCj4gcmVjb3JkaW5nIGRldmljZS4NCj4NCj4gSm9obg0KPg0KPg0KPiBKb2huIEVsd2Vs bA0KPiBUZWw6ICs0NCAxOTA4IDgxNzgwMSAob2ZmaWNlIGFuZCBtb2JpbGUpDQo+IEVtYWlsOiBq b2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tDQo+IGh0dHA6Ly93d3cuc2llbWVucy1l bnRlcnByaXNlLmNvbS91ay8NCj4NCj4gU2llbWVucyBFbnRlcnByaXNlIENvbW11bmljYXRpb25z IExpbWl0ZWQuDQo+IFJlZ2lzdGVyZWQgb2ZmaWNlOiBCcmlja2hpbGwgU3RyZWV0LCBXaWxsZW4g TGFrZSwgTWlsdG9uIEtleW5lcywgTUsxNQ0KMERKLg0KPiBSZWdpc3RlcmVkIE5vOiA1OTAzNzE0 LCBFbmdsYW5kLg0KPg0KPiBTaWVtZW5zIEVudGVycHJpc2UgQ29tbXVuaWNhdGlvbnMgTGltaXRl ZCBpcyBhIFRyYWRlbWFyayBMaWNlbnNlZSBvZg0KU2llbWVucyBBRy4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcg bGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi From stewe@stewe.org Thu Jul 28 16:08: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 CD91511E810A for ; Thu, 28 Jul 2011 16:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.824 X-Spam-Level: X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[AWL=0.378, 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 KNVSOg-DunmZ for ; Thu, 28 Jul 2011 16:08:37 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7C11E8082 for ; Thu, 28 Jul 2011 16:08:36 -0700 (PDT) Received: from [130.129.21.150] (unverified [130.129.21.150]) by stewe.org (SurgeMail 3.9e) with ESMTP id 18853-1743317 for ; Fri, 29 Jul 2011 01:08:31 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Jul 2011 19:08:24 -0400 From: Stephan Wenger To: "rtcweb@ietf.org" Message-ID: Thread-Topic: VP8 royalty free? In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3394724910_2191743" X-Originating-IP: 130.129.21.150 X-Authenticated-User: stewe@stewe.org Subject: Re: [rtcweb] VP8 royalty free? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jul 2011 23:08:37 -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_3394724910_2191743 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I was told that the blog has disappeared. The cached version is still available: http://webcache.googleusercontent.com/search?q=cache:IEfA8rZjUWsJ:fosspatent s.blogspot.com/+fosspatents&cd=1&hl=en&ct=clnk&source=www.google.com There's also the cited article: http://www.streamingmedia.com/Articles/News/Featured-News/WebM-Patent-Fight- Ahead-for-Google-76781.aspx Stephan From: Stephan Wenger Date: Thu, 28 Jul 2011 15:53:54 -0400 To: "rtcweb@ietf.org" Subject: VP8 royalty free? Hi, In today's session, someone characterized VP8 as "royalty free". On this subject, some of you may find the linked blog post (and the article linked therein) interesting. It was posted today, during our session. To summarize, DOJ probe or not, MPEG-LA continues its efforts to form an (presumably royalty-bearing) patent pool for VP8, they had initial pool member meeting sometime in June, and talk about 12 potential member companies. http://fosspatents.blogspot.com/2011/07/googles-webm-vp8-allegedly-infringes .html Regards, Stephan --B_3394724910_2191743 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I was told that the blog has= disappeared. 
The cached version is still available: http://webcache.googleusercontent.com/search?q=3Dcache:IEfA8r= ZjUWsJ:fosspatents.blogspot.com/+fosspatents&cd=3D1&hl=3Den&ct=3Dclnk&= amp;source=3Dwww.google.com
=
Stephan

From: S= tephan Wenger <stewe@stewe.org>Date: Thu, 28 Jul 2011 15:53:54 -04= 00
To: "rtcweb@ietf.org" <rtcweb@ietf= .org>
Subject: VP8 royalty = free?

Hi,
In today's session, someone characterized VP8 as "royalty free= ".  On this subject, some of you may find the linked blog post (and the= article linked therein) interesting.  It was posted today, during our = session.  To summarize, DOJ probe or not, MPEG-LA continues its efforts= to form an (presumably royalty-bearing) patent pool for VP8, they had initi= al pool member meeting sometime in June, and talk about 12 potential member = companies.
Regards,
St= ephan

--B_3394724910_2191743-- From duerst@it.aoyama.ac.jp Thu Jul 28 17:43: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 33BF011E8170 for ; Thu, 28 Jul 2011 17:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.862 X-Spam-Level: X-Spam-Status: No, score=-99.862 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 NBnkE76dpSNR for ; Thu, 28 Jul 2011 17:43:01 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8592911E816F for ; Thu, 28 Jul 2011 17:43:00 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p6T0gqxw028493 for ; Fri, 29 Jul 2011 09:42:52 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 60bf_0ca1_b137ff50_b97b_11e0_813b_001d096c566a; Fri, 29 Jul 2011 09:42:52 +0900 Received: from [IPv6:::1] ([133.2.210.5]:55808) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 29 Jul 2011 09:42:48 +0900 Message-ID: <4E3201FD.6050408@it.aoyama.ac.jp> Date: Fri, 29 Jul 2011 09:42:37 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] VP8 royalty free? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 00:43:02 -0000 I get: "Blog has been removed Sorry, the blog at fosspatents.blogspot.com has been removed. This address is not available for new blogs." (and same for http://fosspatents.blogspot.com/). Do you have a better address? Regards, Martin. On 2011/07/29 4:53, Stephan Wenger wrote: > Hi, > In today's session, someone characterized VP8 as "royalty free". On this > subject, some of you may find the linked blog post (and the article linked > therein) interesting. It was posted today, during our session. To > summarize, DOJ probe or not, MPEG-LA continues its efforts to form an > (presumably royalty-bearing) patent pool for VP8, they had initial pool > member meeting sometime in June, and talk about 12 potential member > companies. > http://fosspatents.blogspot.com/2011/07/googles-webm-vp8-allegedly-infringes > .html > Regards, > Stephan > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gettysjim@gmail.com Thu Jul 28 19:40: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 BE93E21F86AF for ; Thu, 28 Jul 2011 19:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeaHZ4peOjqj for ; Thu, 28 Jul 2011 19:40:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCB521F86AD for ; Thu, 28 Jul 2011 19:40:39 -0700 (PDT) Received: by qyk9 with SMTP id 9so3491940qyk.10 for ; Thu, 28 Jul 2011 19:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=d7+J6HRazocfNOW/YP1s+OOxutkgWYtPInEG3MhOjbU=; b=QkiXmPShwLthDxXoXygC9Db80WlKYE/asq8ZGtg+MBIQgIVpV5eBCqaMkexNSql42k 2Ck9JiOdhEDutV1mIy45OAmjH8kWYw4fUeiYxJkR3AVW+6NHNuYsUcdTHhna4SG8ud1k Kr4lxD+qBg9jmg9Ue7hpiGqQUi3jxElyiT0JY= Received: by 10.224.200.132 with SMTP id ew4mr571566qab.340.1311907238543; Thu, 28 Jul 2011 19:40:38 -0700 (PDT) Received: from [192.168.0.155] (modemcable027.202-70-69.static.videotron.ca [69.70.202.27]) by mx.google.com with ESMTPS id w18sm721312qac.11.2011.07.28.19.40.36 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 19:40:37 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E321DA3.5040005@freedesktop.org> Date: Thu, 28 Jul 2011 22:40:35 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4E3201FD.6050408@it.aoyama.ac.jp> In-Reply-To: <4E3201FD.6050408@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] VP8 royalty free? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 02:40:39 -0000 I recommend taking blog postings and other press from this particular person (Florian Mueller) with (more than a pinch) of salt. His batting average on both knowledge of the law and prior art has been very poor and he repeatedly has been portraying himself as an expert at such matters. (If you watch Groklaw, you'll know what I mean). - Jim On 07/28/2011 08:42 PM, "Martin J. Drst" wrote: > I get: > > "Blog has been removed > > Sorry, the blog at fosspatents.blogspot.com has been removed. This > address is not available for new blogs." > > (and same for http://fosspatents.blogspot.com/). Do you have a better > address? > > Regards, Martin. > > On 2011/07/29 4:53, Stephan Wenger wrote: >> Hi, >> In today's session, someone characterized VP8 as "royalty free". On >> this >> subject, some of you may find the linked blog post (and the article >> linked >> therein) interesting. It was posted today, during our session. To >> summarize, DOJ probe or not, MPEG-LA continues its efforts to form an >> (presumably royalty-bearing) patent pool for VP8, they had initial pool >> member meeting sometime in June, and talk about 12 potential member >> companies. >> http://fosspatents.blogspot.com/2011/07/googles-webm-vp8-allegedly-infringes >> >> .html >> Regards, >> Stephan >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Thu Jul 28 20:12: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 921CF21F8877 for ; Thu, 28 Jul 2011 20:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unwWM-+2RSqR for ; Thu, 28 Jul 2011 20:12:45 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5E21F8865 for ; Thu, 28 Jul 2011 20:12:43 -0700 (PDT) Received: from [130.129.70.103] (unverified [130.129.70.103]) by stewe.org (SurgeMail 3.9e) with ESMTP id 18905-1743317 for multiple; Fri, 29 Jul 2011 05:12:42 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Jul 2011 23:12:27 -0400 From: Stephan Wenger To: Jim Gettys , "Martin J. =?ISO-8859-1?B?RPxyc3Q=?=" Message-ID: Thread-Topic: [rtcweb] VP8 royalty free? In-Reply-To: <4E321DA3.5040005@freedesktop.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 130.129.70.103 X-Authenticated-User: stewe@stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] VP8 royalty free? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 03:12:46 -0000 I will refrain from expressing an opinion of Mr. Mueller's views (as I would when it comes to Groklaw), but please note that the blog post did contain a link to another document from a different source that contains quotes of Larry Horn, MPEG-LA's CEO. I posted that link in a follow up to this list. Stephan On 7.28.2011 22:40 , "Jim Gettys" wrote: >I recommend taking blog postings and other press from this particular >person (Florian Mueller) with (more than a pinch) of salt. > >His batting average on both knowledge of the law and prior art has been >very poor and he repeatedly has been portraying himself as an expert at >such matters. (If you watch Groklaw, you'll know what I mean). > - Jim > > >On 07/28/2011 08:42 PM, "Martin J. D=FCrst" wrote: >> I get: >> >> "Blog has been removed >> >> Sorry, the blog at fosspatents.blogspot.com has been removed. This >> address is not available for new blogs." >> >> (and same for http://fosspatents.blogspot.com/). Do you have a better >> address? >> >> Regards, Martin. >> >> On 2011/07/29 4:53, Stephan Wenger wrote: >>> Hi, >>> In today's session, someone characterized VP8 as "royalty free". On >>> this >>> subject, some of you may find the linked blog post (and the article >>> linked >>> therein) interesting. It was posted today, during our session. To >>> summarize, DOJ probe or not, MPEG-LA continues its efforts to form an >>> (presumably royalty-bearing) patent pool for VP8, they had initial pool >>> member meeting sometime in June, and talk about 12 potential member >>> companies. >>>=20 >>>http://fosspatents.blogspot.com/2011/07/googles-webm-vp8-allegedly-infri >>>nges >>> >>> .html >>> Regards, >>> Stephan >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From matthew.kaufman@skype.net Thu Jul 28 22:13: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 0E3C611E8075 for ; Thu, 28 Jul 2011 22:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 tH87MZ1TZPbN for ; Thu, 28 Jul 2011 22:12:59 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id B6A3021F87C2 for ; Thu, 28 Jul 2011 22:12:58 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id CA74816E2; Fri, 29 Jul 2011 07:12:56 +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=Lw I+uWDH2pLj5MoVELyav5r8EhQ=; b=c0bD0Jf1lYzhceTpRF0pG5ufhBd2oEN3vM 7ZaKlblnNCn8DYhSf+64v40AcMgfH8v1COFAVmEQE1qy6l1ghAu/t+DMhg4F4uCy o9OgWs/ZM6JQGlk/QzpjL43Ky7sc8ggI0REatUDX4jj7GuQtKipkX9chTxuC4GHW uWQambcEo= 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=CAT6xutBLYnIVZc6A+Hcf8 Y4go4idY3NXK9mlBgwq+0VhuorVmiNgaFaVnxObHePlUXJqO/xthSK1Dyc0w87wz 6Pa6CrsbNhZ9gLd7AAKHa+UtKVIpvFVOawXKm5YAXuEDh4U8j8u/Ub4wlOCbApL2 ZbisyrQSI0Cy/ApMlhb60= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C915E7FC; Fri, 29 Jul 2011 07:12:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id AAA223507028; Fri, 29 Jul 2011 07:12:56 +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 Y-OYMaWWTlPs; Fri, 29 Jul 2011 07:12:55 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (dhcp-4649.meeting.ietf.org [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id 098203507364; Fri, 29 Jul 2011 07:12:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <4E31DAAB.5030606@jesup.org> Date: Fri, 29 Jul 2011 01:12:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2BE95AAB-722C-472C-B624-CF91AE7D75EF@skype.net> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> <4E31DAAB.5030606@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1082) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 05:13:00 -0000 On Jul 28, 2011, at 5:54 PM, Randell Jesup wrote: > On 7/28/2011 1:18 PM, Matthew Kaufman wrote: >> we can't display "this connection is secured everywhere" to the = user... but look, HTTPS is the same. When I see a lock icon on my screen = and click to see that yes, I'm really talking to who it says in the = address bar, I still can't tell if they're terminating my HTTPS session = in a front-end box and then using HTTP beyond it, or if the HTTPS really = goes all the way to the server. >>> But the browser ties the identity of the name I typed in the address = bar to the cert, so that if I typed "https://mybank.com", I know it's = secure to mybank.com. Of course it could be cleartext after whomever = has a cert for mybank.com, and may even end up triggering protocols that = exit mybank.com and go to evil.com, but I implicitly trust mybank.com to = be careful with bank info. >> Ok, so you trust your "banking service". >=20 > And more to the point, you trust the chain of certificates = incorporated into the browser to verify it's actually the entity that = owns mybank.com (and EV certs come into play here too). Overall, that's = a "good" chain of trust, though no such chain is perfect. It appears to be "good enough" for people to do banking using their web = browser, which is pretty amazing if you think about it. >=20 >>> That's not the same for DTLS-SRTP; until and unless the human being = verifies the keys/SAS with the far end, nothing is known. >> If you trust your "calling service" (and are connected to it with = HTTPS) then you can use that trusted service to exchange the = fingerprints and verify the keys of the far end to prevent MITM. >=20 > Right, this is trusting that not only they are who they say they are, = but also trusting that they haven't been compromised. And one may not = have the same level of trust in that that you have (have to have) in = your bank. I'm not sure how this is any different from any other type of calling = scenario. You always need to trust the person at the far end to not reveal the = call, and trust the equipment they (and you) are using. >> (You can also add a browser extension that uses a service that you = trust but that isn't your calling service, and when you're calling other = people with the same extension you can check the fingerprints in an = automated way using that.) >=20 > Definitely possible, and adds another largely-independent layer of = trust. Yes, but independent layers of trust are a feature, not a bug. And what are you arguing here? My claim is that DTLS-SRTP is often = *more* secure than SDES-style keying, and certainly no worse. This is one of the things that backs up my claim. I still haven't heard = why SDES or plain RTP would be superior from a security point of view. >=20 >> If you *don't* trust your "calling service", then that's just like = not trusting your banking service when you type in passwords. >=20 > I may trust my calling service to connect me (to someone), but I may = not trust them to not MITM me themselves (read CALEA or other national = security services), and I may not trust them not to be compromised, = since they have a far smaller monetary stake in avoiding it compared to = a bank. Sure, but again all of these things are EASIER if they use SDES. They = can MITM you themselves by letting anyone get a copy of the traffic from = anywhere and sending that person the keys, even after the fact. (Both = passive attacks like this and getting the key later are prevented with = DTLS-SRTP and DH key agreement). >=20 > Another idea related to identity: as mentioned, the cert trust chain = in a browser verifies that you're talking to mybank.com or = myprovider.com. This can be leveraged to provide authentication by cert = that you're talking to someone who's part of mybank.com, even if you = went through myprovider.com to get there and myprovider.com might be = compromised. It doesn't directly help verify you're talking to Joe Your = Neighbor, but other services can help with that (as mentioned - = extensions, etc). Yes, all good ideas, but built upon DTLS-SRTP, and not SDES or plain = RTP. >=20 > Effectively, for a fairly large subset of the net, we have a deployed = PKI of a form. It's not perfect (DNSSEC anyone; recent todo with bogus = certs because a CA snafu) but for most uses that it covers it's pretty = good. Getting it to cover identifying the destination as a dependent of = the primary cert may be an issue for many companies, however. I doubt it, but perhaps. >=20 > In any case, there may be a way to leverage this existing trust chain, = both to authenticate who's calling you and who you're calling, for a = subset of possible destinations. Almost certainly. Matthew Kaufman From matthew.kaufman@skype.net Thu Jul 28 22:14: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 114A011E808E for ; Thu, 28 Jul 2011 22:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.152, 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 PhyAO4vVSWQv for ; Thu, 28 Jul 2011 22:14:39 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4331511E807F for ; Thu, 28 Jul 2011 22:14:39 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 82ABE16E2; Fri, 29 Jul 2011 07:14:38 +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=5hb1GGWZVl+ChkSDeP5RrX4o99Q=; b=Mnl2evX cQDSW/ZgagTZyFi8hf1KCtFQv/6pjBz0E6q8AvSKuEfZZFRYnnLCHkal6b06xjr2 lVx4L+7tQ+sDDSC+C1LLSWZEBo7KTzLRP5ozTGdGTIvfXBf5tL/DK28Ixl7G+aKs Rmmz3hAVpuFDlGUJwB7ZaHdCdTNd7MT3WutU= 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=EbUtm8kM2Mp/9tvA4p7HwRAg0MLghRPoytfwPItRvDM3bUiv DzyntKOj6MgLuGasxPYX6nuUD/CJ18tlJHNKni3q2H1iUpPBO48zI9I2dDnuxU2W 1sj7kpDolNUH2pgwVrLcF2Bez0erfuZXJx9QMfCyK78HIQkXXhYCe2yE/Dc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 73CED7FC; Fri, 29 Jul 2011 07:14:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 50D4D3507183; Fri, 29 Jul 2011 07:14:38 +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 HFkbOnXIxTR5; Fri, 29 Jul 2011 07:14:37 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (dhcp-4649.meeting.ietf.org [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id 030A43506E10; Fri, 29 Jul 2011 07:14:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1-749310136 From: Matthew Kaufman In-Reply-To: Date: Fri, 29 Jul 2011 01:14:35 -0400 Message-Id: <91AFB52E-2C41-4218-BFD6-BE2ACCA861C6@skype.net> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <4E319ABD.9070604@alvestrand.no> <15AFE3C5-8F77-435B-B6DB-E0D081BA9ED2@skype.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 05:14:40 -0000 --Apple-Mail-1-749310136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 28, 2011, at 6:33 PM, Hadriel Kaplan wrote: >=20 > On Jul 28, 2011, at 1:32 PM, Matthew Kaufman wrote: >>=20 >> You can do that, or you can check the fingerprints via the high path = to authenticate each end and prove that there's no MITM on the media = path. >=20 > That's assuming the high path itself is secure end-to-end. Since this = group has already agreed to allow HTTP rather than mandate HTTPS, and = since it can go from your web service to SIP and beyond, such a = guarantee is hard to enforce. I don't believe we had complete consensus to allow HTTP rather than = HTTPS... and of course you are free to not use calling services that = aren't using HTTPS, just as you're free to not use web-based email = providers or web-based social networking sites that don't require the = use of HTTPS. The guarantee of what happens beyond the service is difficult. The = guarantee of what happens within the service goes as far as you can = trust the service. Matthew Kaufman --Apple-Mail-1-749310136 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 28, 2011, at 1:32 PM, Matthew Kaufman = wrote:

You = can do that, or you can check the fingerprints via the high path to = authenticate each end and prove that there's no MITM on the media = path.

That's assuming the high path itself is secure = end-to-end.  Since this group has already agreed to allow HTTP = rather than mandate HTTPS, and since it can go from your web service to = SIP and beyond, such a guarantee is hard to = enforce.


I don't = believe we had complete consensus to allow HTTP rather than HTTPS... and = of course you are free to not use calling services that aren't using = HTTPS, just as you're free to not use web-based email providers or = web-based social networking sites that don't require the use of = HTTPS.

The guarantee of what happens beyond the = service is difficult. The guarantee of what happens within the service = goes as far as you can trust the = service.

Matthew = Kaufman

= --Apple-Mail-1-749310136-- From matthew.kaufman@skype.net Thu Jul 28 22:17: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 971F721F8B8B for ; Thu, 28 Jul 2011 22:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 C7eWRyWeQRh6 for ; Thu, 28 Jul 2011 22:17:47 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8253A21F8B0D for ; Thu, 28 Jul 2011 22:17:47 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C497E16E2; Fri, 29 Jul 2011 07:17:46 +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=Uq SfGpIyoL5GH4VCHgmc3mZv9Cs=; b=tt3qeHGDd2PRiTHaZyqAmlzo3eofPlmB1d LzYvehGiw4iCdbxzhZUI/vxobEX3AevjNYFmYbqtLSFZ2Lc8A0OzRIw2L+hQEa4a +w1QZfu9e2YPKV5kFE/vwh6Gk2/qn0xcazvspaW4yLAMB+c7zplBffEyDQ7zm1dO H66dY3hbA= 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=vy7AcgoAHdDCakNlVktvxl JDHIC7RtOnbm3VGsFr2U5zEUgzlejt5/a533TgLeoND4FM4U9DyKJLcri/BEgziK MzaMIJPA/RV+a38SzkqGSK6D6fPMqBBVP77mTXx4RDQcENUnsXFOMbGevVfvbsr2 6BoBvadZ0Mo83MOd3QLZQ= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C1EE77FC; Fri, 29 Jul 2011 07:17:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id AAF2F3507389; Fri, 29 Jul 2011 07:17:46 +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 48ayoQKSF1SP; Fri, 29 Jul 2011 07:17:45 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (dhcp-4649.meeting.ietf.org [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id E7F953507183; Fri, 29 Jul 2011 07:17:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: Date: Fri, 29 Jul 2011 01:17:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 05:17:48 -0000 On Jul 28, 2011, at 6:44 PM, Hadriel Kaplan wrote: >=20 > On Jul 28, 2011, at 1:18 PM, Matthew Kaufman wrote: >=20 >>=20 >> On Jul 28, 2011, at 11:13 AM, Hadriel Kaplan wrote: >>=20 >>> I would be perfectly happy with using sdes-based SRTP. But if the = call would otherwise fail altogether, I'd like the option to make the = call no matter what (ie, even if it ends up being cleartext). >>=20 >> Why would the call "otherwise fail altogether"? >=20 > Because I'm calling someone who has a legacy VoIP device or is on the = PSTN, and they're not going to support DTLS-SRTP. I'm confused... do you want maximum security (because DTLS-SRTP is = probably the best path to that of the choices) or maximum interoperation = with legacy (because plain RTP is probably the easiest way to get that) > Of course we could require the RTCWEB service to deploy "gateways" in = order to terminate DTLS-SRTP and do SDES-based SRTP or cleartext RTP to = non-RTCWEB, but that's expensive and complex. Expensive? Maybe. Complex? Not really. > Not to mention its mis-leading - the media is not secure end-to-end, = and again the lock-icon model won't work. The lock icon model works just as well as the lock icon works on Gmail = to indicate that your interaction with Gmail is protected but the email = you send might be going via plain SMTP. It might even be better than this, if we do a good job of sending = requirements to W3C. >=20 >=20 >> Have you ever called into a conference call from a public place, with = your microphone muted? >=20 > Nah, I talk too much. ;) Even so, you'd probably rather not be recorded by a 3rd party using the = microphone in your headset if you can avoid it. Matthew Kaufman From ietf@meetecho.com Thu Jul 28 23:51: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 B11EE11E808A for ; Thu, 28 Jul 2011 23:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLjwiMFyGp11 for ; Thu, 28 Jul 2011 23:51:57 -0700 (PDT) Received: from smtplqs02.aruba.it (smtplqs-out48.aruba.it [62.149.158.88]) by ietfa.amsl.com (Postfix) with SMTP id A092F11E8098 for ; Thu, 28 Jul 2011 23:51:56 -0700 (PDT) Received: (qmail 22185 invoked by uid 89); 29 Jul 2011 06:51:54 -0000 Received: from unknown (HELO smtpw2.aruba.it) (62.149.128.188) by smtplqs02.aruba.it with SMTP; 29 Jul 2011 06:51:54 -0000 Received: (qmail 8066 invoked by uid 89); 29 Jul 2011 06:51:54 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 29 Jul 2011 06:51:54 -0000 Date: Fri, 29 Jul 2011 08:51:54 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: rtcweb@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 70.81.226.194 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs02.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] RTCWEB recording available X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 06:51:57 -0000 Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room) =0Aof yesterday's RTCWEB session is available.=0A=0AYou can = watch it by either clicking the proper link on the remote participation p= age (http://www.ietf.org/meeting/81/remote-participation.html#Meetecho), = or by directly accessing the following URL:=0Ahttp://www.meetecho.com/iet= f81/recordings=0A=0AFor the chair(s): please feel free to put the link to= the recording in the minutes, if you think this might be useful.=0A=0AIn= case of problems with the playout, just drop an e-mail to =0Aietf-suppor= t@meetecho.com.=0A=0ACheers,=0Athe Meetecho Team From bernard_aboba@hotmail.com Fri Jul 29 05:45:24 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 806E021F8BBA for ; Fri, 29 Jul 2011 05:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=0.402, 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 Ykt5O1xydHNr for ; Fri, 29 Jul 2011 05:45:24 -0700 (PDT) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by ietfa.amsl.com (Postfix) with ESMTP id E292E21F8BB9 for ; Fri, 29 Jul 2011 05:45:23 -0700 (PDT) Received: from BLU152-W47 ([65.55.116.73]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 05:45:23 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b3df2268-24ac-4fe7-b703-d9d5ea885170_" X-Originating-IP: [130.129.17.34] From: Bernard Aboba To: , Date: Fri, 29 Jul 2011 05:45:23 -0700 Importance: Normal In-Reply-To: References: , , <464DADBD-EEBE-43C8-8552-EAA40FBB610D@acmepacket.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jul 2011 12:45:23.0942 (UTC) FILETIME=[6257F060:01CC4DED] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 12:45:24 -0000 --_b3df2268-24ac-4fe7-b703-d9d5ea885170_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Agree that it's worth exploring further=2C if only to document what th= e security requirements are=2C and what is required to meet them. The prob= lem with the gateway argument is that it can be extended too far -- it is o= ne thing to require a gateway for signaling=2C and quite another to require= transcoding of media=2C for example. As long as we have legacy interop us= e cases=2C and aren't asserting that RTCWEB represents a "singularity"=2C t= hen we need to be able to handle them.=20 > [JRE] This assumes RTP-RTCP multiplexing=2C which not many current device= s support. There are so many things that RTC-Web is proposing to use that a= re not widely supported on existing devices that some sort of gateway looks= inevitable. Eliminating one particular instance of incompatibility might r= educe the amount of adaptation the gateway needs to perform=2C but it looks= increasingly unlikely that all adaptation can be eliminated. So is there a= ny real value in trying to eliminate one aspect if others can't be eliminat= ed? Probably yes=2C but not if it introduces other compromises=2C e.g.=2C s= ecurity. I think it is worth exploring this further. = --_b3df2268-24ac-4fe7-b703-d9d5ea885170_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] Agree that it's worth exploring further=2C if only to document what th= e security requirements are=2C and what is required to meet them. =3B T= he problem with the gateway argument is that it can be extended too far -- = it is one thing to require a gateway for signaling=2C and quite another to = require transcoding of media=2C for example. =3B As long as we have leg= acy interop use cases=2C and aren't asserting that RTCWEB represents a "sin= gularity"=2C then we need to be able to handle them.


>= =3B [JRE] This assumes RTP-RTCP multiplexing=2C which not many current devi= ces support. There are so many things that RTC-Web is proposing to use that= are not widely supported on existing devices that some sort of gateway loo= ks inevitable. Eliminating one particular instance of incompatibility might= reduce the amount of adaptation the gateway needs to perform=2C but it loo= ks increasingly unlikely that all adaptation can be eliminated. So is there= any real value in trying to eliminate one aspect if others can't be elimin= ated? Probably yes=2C but not if it introduces other compromises=2C e.g.=2C= security. I think it is worth exploring this further.

=
= --_b3df2268-24ac-4fe7-b703-d9d5ea885170_-- From randell1@jesup.org Fri Jul 29 06:01: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 D622B21F86A8 for ; Fri, 29 Jul 2011 06:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 6GuzuttLpLL9 for ; Fri, 29 Jul 2011 06:01:10 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3821F86A1 for ; Fri, 29 Jul 2011 06:01:09 -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 1Qmmgf-0000hS-4I; Fri, 29 Jul 2011 08:01:09 -0500 Message-ID: <4E32AEC3.8080804@jesup.org> Date: Fri, 29 Jul 2011 08:59:47 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> <4E31DAAB.5030606@jesup.org> <2BE95AAB-722C-472C-B624-CF91AE7D75EF@skype.net> In-Reply-To: <2BE95AAB-722C-472C-B624-CF91AE7D75EF@skype.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] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 13:01:11 -0000 On 7/29/2011 1:12 AM, Matthew Kaufman wrote: >>> (You can also add a browser extension that uses a service that you trust but that isn't your calling service, and when you're calling other people with the same extension you can check the fingerprints in an automated way using that.) >> Definitely possible, and adds another largely-independent layer of trust. > Yes, but independent layers of trust are a feature, not a bug. > > And what are you arguing here? My claim is that DTLS-SRTP is often *more* secure than SDES-style keying, and certainly no worse. No disagreement at all. I'm discussing that DTLS-SRTP is vulnerable (to a degree) to MITM attacks, which is well-known, if you don't have a known-secure signaling channel. I'm not making the argument that Hadriel is. >>> If you *don't* trust your "calling service", then that's just like not trusting your banking service when you type in passwords. >> I may trust my calling service to connect me (to someone), but I may not trust them to not MITM me themselves (read CALEA or other national security services), and I may not trust them not to be compromised, since they have a far smaller monetary stake in avoiding it compared to a bank. > Sure, but again all of these things are EASIER if they use SDES. They can MITM you themselves by letting anyone get a copy of the traffic from anywhere and sending that person the keys, even after the fact. (Both passive attacks like this and getting the key later are prevented with DTLS-SRTP and DH key agreement). Absolutely. > Another idea related to identity: as mentioned, the cert trust chain in a browser verifies that you're talking to mybank.com or myprovider.com. This can be leveraged to provide authentication by cert that you're talking to someone who's part of mybank.com, even if you went through myprovider.com to get there and myprovider.com might be compromised. It doesn't directly help verify you're talking to Joe Your Neighbor, but other services can help with that (as mentioned - extensions, etc). > Yes, all good ideas, but built upon DTLS-SRTP, and not SDES or plain RTP. Yes, that's the idea. >> Effectively, for a fairly large subset of the net, we have a deployed PKI of a form. It's not perfect (DNSSEC anyone; recent todo with bogus certs because a CA snafu) but for most uses that it covers it's pretty good. Getting it to cover identifying the destination as a dependent of the primary cert may be an issue for many companies, however. > I doubt it, but perhaps. My concern was getting companies to deploy subsidiary certs to the browsers of call center agents, etc (especially as these functions are often out-sourced). >> In any case, there may be a way to leverage this existing trust chain, both to authenticate who's calling you and who you're calling, for a subset of possible destinations. > Almost certainly. Good! -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Fri Jul 29 07:18: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 33F9C21F8639 for ; Fri, 29 Jul 2011 07:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 FmPPZFZPuJj4 for ; Fri, 29 Jul 2011 07:17:59 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 95A5E21F861E for ; Fri, 29 Jul 2011 07:17:59 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 29 Jul 2011 10:17:58 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 29 Jul 2011 10:17:58 -0400 From: Hadriel Kaplan To: Randell Jesup Date: Fri, 29 Jul 2011 10:17:57 -0400 Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying Thread-Index: AcxN+lDkxDcFJyDmQVGHT1fTiucesw== Message-ID: <32007816-40BF-49AA-9275-0A9A4B51B52D@acmepacket.com> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> <4E31DAAB.5030606@jesup.org> <2BE95AAB-722C-472C-B624-CF91AE7D75EF@skype.net> <4E32AEC3.8080804@jesup.org> In-Reply-To: <4E32AEC3.8080804@jesup.org> 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: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 14:18:00 -0000 On Jul 29, 2011, at 8:59 AM, Randell Jesup wrote: > No disagreement at all. I'm discussing that DTLS-SRTP is vulnerable=20 > (to a degree) to MITM > attacks, which is well-known, if you don't have a known-secure signaling= =20 > channel. I'm not making the > argument that Hadriel is. >=20 But that *is* the argument I was making. (or at least trying to :) =20 I certainly wasn't claiming SDES nor RTP are as secure as DTLS-SRTP could b= e. What I said to start this whole thing was: the two alternatives should not = be described as choosing between secure and insecure. BOTH alternatives re= quire the user to verify something for the call to be secure. BOTH alterna= tives have the potential to be very secure. That is all. BTW, I am assuming of course that even if we choose the alternative of DTLS= +SDES+RTP, that DTLS would always be preferred, and if the peer cannot do i= t then SDES, and if the peer can't do that then RTP. (assuming the human ha= s set whatever browser knobs are necessary to enable/disable this stuff) So between two RTCWEB browsers it would always be DTLS-SRTP. -hadriel From matthew.kaufman@skype.net Fri Jul 29 07:30: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 0F04D21F8560 for ; Fri, 29 Jul 2011 07:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 bBtg0l8m9MtQ for ; Fri, 29 Jul 2011 07:30:39 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id F17E921F855C for ; Fri, 29 Jul 2011 07:30:38 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 45B737FD; Fri, 29 Jul 2011 16:30:38 +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=ts 42jUUThoflSW/QHopRyU4bveE=; b=k8GkLg6KHsoTqwBjRHepf48HvTa4DUkoPI USLv7Tqccz4zvVAtLfhAouokgWopGPClrt8oZ6fi+AABvb0IW5DPRv2XguOQtDVp 9B17TthgLKi16eDIlE/ftwFN103h72hUg/b6c278SjGjWVABE4JJLhdxIbe1XGIJ Ry+/m9Fcc= 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=bbIDR4RsUUN0Hm8bw8lZng uaMvmATkDy8N140fNLqDLKugN9AXFgZyX1hLYj11m5gSpZVspTRSIuaUuoSLUn32 +hvLGmMIL55XdcaaeHQ8xouSkkEeF1P4OzsZo5T90P7E1YI+rIAkiwu6UFx/siog 6DkX7/qGx+oXVvpzjR8iw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 43FB77F8; Fri, 29 Jul 2011 16:30:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 2B67935079F3; Fri, 29 Jul 2011 16:30:38 +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 gSmDN8ZrMedE; Fri, 29 Jul 2011 16:30:37 +0200 (CEST) Received: from dhcp-4649.meeting.ietf.org (dhcp-4649.meeting.ietf.org [130.129.70.73]) by zimbra.skype.net (Postfix) with ESMTPSA id D8DF3350739B; Fri, 29 Jul 2011 16:30:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <32007816-40BF-49AA-9275-0A9A4B51B52D@acmepacket.com> Date: Fri, 29 Jul 2011 10:30:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CC0E354-685D-47BB-9426-AE5B4CC9DD4F@skype.net> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> <4E31DAAB.5030606@jesup.org> <2BE95AAB-722C-472C-B624-CF91AE7D75EF@skype.net> <4E32AEC3.8080804@jesup.org> <32007816-40BF-49AA-9275-0A9A4B51B52D@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: "rtcweb@ietf.org" , Randell Jesup Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 14:30:40 -0000 On Jul 29, 2011, at 10:17 AM, Hadriel Kaplan wrote: >=20 > On Jul 29, 2011, at 8:59 AM, Randell Jesup wrote: >=20 >> No disagreement at all. I'm discussing that DTLS-SRTP is vulnerable=20= >> (to a degree) to MITM >> attacks, which is well-known, if you don't have a known-secure = signaling=20 >> channel. I'm not making the >> argument that Hadriel is. >>=20 >=20 > But that *is* the argument I was making. (or at least trying to :) =20 > I certainly wasn't claiming SDES nor RTP are as secure as DTLS-SRTP = could be. We agree here. >=20 > What I said to start this whole thing was: the two alternatives should = not be described as choosing between secure and insecure. BOTH = alternatives require the user to verify something for the call to be = secure. BOTH alternatives have the potential to be very secure. That = is all. I suppose that depends on what you mean by "the potential to be very = secure"... certainly plain RTP *might* be secure, if it never leaves = your desktop. DTLS-SRTP + a security inspection UI gives the user a way to verify = something *independently of the service provider* to see if the call is = secure. SDES does not. The only way to be sure the service provider = isn't colluding with someone to tap your call when you use SDES is to = agree with the other party to mangle the key you receive from the = service provider. (The "pessimist" approach to trust in this = environment.) >=20 > BTW, I am assuming of course that even if we choose the alternative of = DTLS+SDES+RTP, that DTLS would always be preferred, and if the peer = cannot do it then SDES, and if the peer can't do that then RTP. = (assuming the human has set whatever browser knobs are necessary to = enable/disable this stuff) Agree. Though the human needs to be able to see a lot more about what is = going on if we allow all three. > So between two RTCWEB browsers it would always be DTLS-SRTP. Agree. Matthew Kaufman From HKaplan@acmepacket.com Fri Jul 29 07:53: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 CB8ED21F8C50 for ; Fri, 29 Jul 2011 07:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 sRdfD3CUpVgq for ; Fri, 29 Jul 2011 07:53:00 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8E721F8C46 for ; Fri, 29 Jul 2011 07:52:59 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 29 Jul 2011 10:52:56 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 29 Jul 2011 10:52:55 -0400 From: Hadriel Kaplan To: Matthew Kaufman Date: Fri, 29 Jul 2011 10:52:53 -0400 Thread-Topic: [rtcweb] Retransmit: Summary of Alternatives for media keying Thread-Index: AcxN/zL2Q3Y98d4WQHOGIN8Jq2qF9Q== Message-ID: <35B25C39-9813-4A1A-8990-74D536D3DBC1@acmepacket.com> References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> <4E31DAAB.5030606@jesup.org> <2BE95AAB-722C-472C-B624-CF91AE7D75EF@skype.net> <4E32AEC3.8080804@jesup.org> <32007816-40BF-49AA-9275-0A9A4B51B52D@acmepacket.com> <7CC0E354-685D-47BB-9426-AE5B4CC9DD4F@skype.net> In-Reply-To: <7CC0E354-685D-47BB-9426-AE5B4CC9DD4F@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 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "rtcweb@ietf.org" , Randell Jesup Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 14:53:01 -0000 On Jul 29, 2011, at 10:30 AM, Matthew Kaufman wrote: >> What I said to start this whole thing was: the two alternatives should n= ot be described as choosing between secure and insecure. BOTH alternatives= require the user to verify something for the call to be secure. BOTH alte= rnatives have the potential to be very secure. That is all. >=20 > I suppose that depends on what you mean by "the potential to be very secu= re"... certainly plain RTP *might* be secure, if it never leaves your deskt= op. Yeah I should have clarified. I meant since the alternative of DTLS+SDES+R= TP includes DTLS-SRTP, and the human can verify it, and I assume DTLS-SRTP = would always be preferred... then it has the potential to be very secure. (= namely if DTLS-SRTP is used and the human verifies it) In other words, both Alternative A and B have the ability to use DTLS-SRTP = in the same way. The only difference is Alternative A (DTLS only) would fa= il if trying to talk to someone who can't do DTLS-SRTP. Alternative B woul= d still succeed in letting people talk. -hadriel From randell-ietf@jesup.org Fri Jul 29 08:08: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 F178C21F8C80 for ; Fri, 29 Jul 2011 08:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 q8sSmPgveb9N for ; Fri, 29 Jul 2011 08:08:09 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6896321F8C7B for ; Fri, 29 Jul 2011 08:08:09 -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 1QmofW-00064E-33 for rtcweb@ietf.org; Fri, 29 Jul 2011 10:08:06 -0500 Message-ID: <4E32CC80.3030504@jesup.org> Date: Fri, 29 Jul 2011 11:06:40 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <2E6CBDE0-DA10-4792-8059-A01F554DB370@skype.net> <55C78CA7-292C-4E0E-901B-83B7614C2F32@skype.net> <4E31DAAB.5030606@jesup.org> <2BE95AAB-722C-472C-B624-CF91AE7D75EF@skype.net> <4E32AEC3.8080804@jesup.org> <32007816-40BF-49AA-9275-0A9A4B51B52D@acmepacket.com> <7CC0E354-685D-47BB-9426-AE5B4CC9DD4F@skype.net> In-Reply-To: <7CC0E354-685D-47BB-9426-AE5B4CC9DD4F@skype.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] Retransmit: Summary of Alternatives for media keying X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jul 2011 15:08:10 -0000 On 7/29/2011 10:30 AM, Matthew Kaufman wrote: > What I said to start this whole thing was: the two alternatives should not be described as choosing between secure and insecure. BOTH alternatives require the user to verify something for the call to be secure. BOTH alternatives have the potential to be very secure. That is all. > I suppose that depends on what you mean by "the potential to be very secure"... certainly plain RTP *might* be secure, if it never leaves your desktop. > > DTLS-SRTP + a security inspection UI gives the user a way to verify something *independently of the service provider* to see if the call is secure. SDES does not. The only way to be sure the service provider isn't colluding with someone to tap your call when you use SDES is to agree with the other party to mangle the key you receive from the service provider. (The "pessimist" approach to trust in this environment.) This is where there's an opening for browser extensions, potentially (mangling the agreed-to-by-protocol keys, such as by using a pre-shared secret) - though that would require some level of external interaction with the keying from JS/etc code. That may be worth exposing to the W3/JS layer, perhaps. (Should the JS layer have access to the keys? Be able to modify them (per above)? Security implications? What if it wants to implement an "answering-machine" function via recording packets for later replay? Or will it have access to decoded packets, or will it only have access to decoded media and have to re-encode it for "answering-machine" use?) If the user and the person they're talking to has the option of using an extension (or the app) to modify the keys at both ends, that allows for perfect(*) security via pre-shared secrets of whatever form. * Nothing is perfect >> BTW, I am assuming of course that even if we choose the alternative of DTLS+SDES+RTP, that DTLS would always be preferred, and if the peer cannot do it then SDES, and if the peer can't do that then RTP. (assuming the human has set whatever browser knobs are necessary to enable/disable this stuff) > Agree. Though the human needs to be able to see a lot more about what is going on if we allow all three. Mostly that the user be allowed to see it, and that if one does put up any sort of Lock icon it would only be for the "most" secure. (Though this is a security-UI issue, not a technical one.) You could even not put up anything about the security level unless the protocol detected an attack or unless the user's 3rd-party verification tool agreed it was secure by some independent channel. >> So between two RTCWEB browsers it would always be DTLS-SRTP. > Agree. Ditto -- Randell Jesup randell-ietf@jesup.org From paulbeaumont.ietf@gmail.com Sat Jul 30 04:03: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 8381621F84DD for ; Sat, 30 Jul 2011 04:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 I1-KghSdpw81 for ; Sat, 30 Jul 2011 04:03:58 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D82B21F861E for ; Sat, 30 Jul 2011 04:03:54 -0700 (PDT) Received: by fxe6 with SMTP id 6so3498498fxe.31 for ; Sat, 30 Jul 2011 04:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=1qTzyjHLxzx2UC2fxyS4W4KOs9+OEt6wa7cdXQtgi58=; b=IVuQtgsHUO2tSNA5SldBYyqjWOi9AzDHMB3u8xhKoeW7Pq89rEvhA/7RBE7T0uuE3x 25ZLOQF4vZmIp1MLp37nc+h6Q8RsaTamAfyelYu6bm8nHzi3oznXfnt5z5G3Dn+yL+kk ZYe9dUfITT8R/H2P8H2H+WgRilYDFAh3PyNfo= Received: by 10.204.5.206 with SMTP id 14mr670727bkw.181.1312023834071; Sat, 30 Jul 2011 04:03:54 -0700 (PDT) Received: from [10.101.1.222] (static-93.158.79.70.got.public.icomera.com [93.158.79.70]) by mx.google.com with ESMTPS id n11sm794616bkd.14.2011.07.30.04.03.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 04:03:53 -0700 (PDT) From: Paul Beaumont Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (8J2) Message-Id: <9EF49A9D-7F17-4E92-AECA-55BC7ABC7339@gmail.com> Date: Sat, 30 Jul 2011 12:03:09 +0100 To: IETF - RTCWeb Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8J2) Subject: [rtcweb] Possible New Cases - Emergency Services Call & Text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jul 2011 11:03:58 -0000 This was mentioned is the initial RTCWeb session at IETF 81 but just to make= sure it has been captured and understood. (1) Please can a separate use case be added for an Emergency Services teleph= ony call (eg 999 in UK, 112 in EU, 911 in NA, etc).=20 (2) Please can a further separate use case be added for an Emergency Service= s real time text (eg 18000 in UK, via TextDirect operator to ES operator for= hearing impaired persons). FYI today this is a low speed in-band voice band= data call on the text leg. Presumably the replacement would be some kind of= Presence/Messaging replacement with assured delivery or similar. Please note these are treated differently today in current networks and I wo= uld suggest we aim to preserve the capabilities - subject to discussion in t= he community, in the right WG - eg ECRIT. These are, using legacy terminolog= y ... A). Prioritisation in processing of Emergency Services calls above Ordinary C= alls, particularly when server in overload. B). Marking of Emergency Services calls to a specific A-/Calling Party Categ= ory to allow them to be identified downstream. C). Release control modified to B-/Called Party Control with changed RTCWeb b= rowser client behaviour along with indication as to "Off Hook" and "On Hook"= . Paul= From henry.sinnreich@gmail.com Sat Jul 30 05:27: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 2BDC121F8751 for ; Sat, 30 Jul 2011 05:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=0.552, 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 gAarmGB+MvmF for ; Sat, 30 Jul 2011 05:27:24 -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 7968021F863C for ; Sat, 30 Jul 2011 05:27:24 -0700 (PDT) Received: by ywm21 with SMTP id 21so240156ywm.31 for ; Sat, 30 Jul 2011 05:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=5dsJCvjYHKymYDv8AY8rkt6BactC8GUyUPsSUda7ims=; b=HKw6cEFG/1eykbzTXwQklPy/dueATowgFJADY5XIENq1TLEL0jHhd2NmkcdZovl9v6 9BqacER0HtyfcSSLTC8nDU3GP4XRty6H7vhE28QGAMUYWTDi3e0OCXQEEJZDG6xbt8cd RNNPoZLZdhXKNVm6VK7Gobj65ngxTw0TeJVsg= Received: by 10.91.20.22 with SMTP id x22mr2000006agi.157.1312028773283; Sat, 30 Jul 2011 05:26:13 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-249.tx.res.rr.com [76.184.227.249]) by mx.google.com with ESMTPS id l38sm3011682ani.44.2011.07.30.05.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 05:26:12 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 30 Jul 2011 07:26:09 -0500 From: Henry Sinnreich To: Paul Beaumont , IETF - RTCWeb Message-ID: Thread-Topic: [rtcweb] Possible New Cases - Emergency Services Call & Text Thread-Index: AcxOs9xbinlP/0p7K06jz9oBHvwA0w== In-Reply-To: <9EF49A9D-7F17-4E92-AECA-55BC7ABC7339@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [rtcweb] Possible New Cases - Emergency Services Call & Text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jul 2011 12:27:25 -0000 Scratching my head why you did not even mention the SOS URL, http://www.ietf.org/rfc/rfc5031.txt > Please note these are treated differently today in current networks and I > would suggest we aim to preserve the capabilities - subject to discussion in > the community, in the right WG - eg ECRIT. These are, using legacy terminology > ... Subject to discussion in yet another WG? Henry On 7/30/11 6:03 AM, "Paul Beaumont" wrote: > This was mentioned is the initial RTCWeb session at IETF 81 but just to make > sure it has been captured and understood. > > (1) Please can a separate use case be added for an Emergency Services > telephony call (eg 999 in UK, 112 in EU, 911 in NA, etc). > > (2) Please can a further separate use case be added for an Emergency Services > real time text (eg 18000 in UK, via TextDirect operator to ES operator for > hearing impaired persons). FYI today this is a low speed in-band voice band > data call on the text leg. Presumably the replacement would be some kind of > Presence/Messaging replacement with assured delivery or similar. > > Please note these are treated differently today in current networks and I > would suggest we aim to preserve the capabilities - subject to discussion in > the community, in the right WG - eg ECRIT. These are, using legacy terminology > ... > > A). Prioritisation in processing of Emergency Services calls above Ordinary > Calls, particularly when server in overload. > > B). Marking of Emergency Services calls to a specific A-/Calling Party > Category to allow them to be identified downstream. > > C). Release control modified to B-/Called Party Control with changed RTCWeb > browser client behaviour along with indication as to "Off Hook" and "On Hook". > > Paul > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Sun Jul 31 05:31: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 C982D21F8593 for ; Sun, 31 Jul 2011 05:31:42 -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 9+k2VbSM2kxr for ; Sun, 31 Jul 2011 05:31:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2E45621F8588 for ; Sun, 31 Jul 2011 05:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E098F39E0FA for ; Sun, 31 Jul 2011 14:30:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okAomQHS531B for ; Sun, 31 Jul 2011 14:30:32 +0200 (CEST) Received: from [172.16.1.228] (173-167-136-97-illinois.hfc.comcastbusiness.net [173.167.136.97]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B90FB39E0F5 for ; Sun, 31 Jul 2011 14:30:31 +0200 (CEST) Message-ID: <4E354B2C.2040505@alvestrand.no> Date: Sun, 31 Jul 2011 08:31:40 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9EF49A9D-7F17-4E92-AECA-55BC7ABC7339@gmail.com> In-Reply-To: <9EF49A9D-7F17-4E92-AECA-55BC7ABC7339@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Possible New Cases - Emergency Services Call & Text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2011 12:31:42 -0000 On 07/30/11 07:03, Paul Beaumont wrote: > This was mentioned is the initial RTCWeb session at IETF 81 but just to make sure it has been captured and understood. > > (1) Please can a separate use case be added for an Emergency Services telephony call (eg 999 in UK, 112 in EU, 911 in NA, etc). I am skeptical to adding this use case. The most important issues and complications that ES brings to the table are with call setup, which I believe is outside of what RTCWEB should be focusing on. As long as there is nothing special about the media plane issues here, I would prefer not to take it on. > (2) Please can a further separate use case be added for an Emergency Services real time text (eg 18000 in UK, via TextDirect operator to ES operator for hearing impaired persons). FYI today this is a low speed in-band voice band data call on the text leg. Presumably the replacement would be some kind of Presence/Messaging replacement with assured delivery or similar. > > Please note these are treated differently today in current networks and I would suggest we aim to preserve the capabilities - subject to discussion in the community, in the right WG - eg ECRIT. These are, using legacy terminology ... > > A). Prioritisation in processing of Emergency Services calls above Ordinary Calls, particularly when server in overload. Are you talking about prioritization in the control plane (out of scope) in the media plane, or both? Note that the media plane doesn't necessarily have any servers in it. > B). Marking of Emergency Services calls to a specific A-/Calling Party Category to allow them to be identified downstream. Same question here. > C). Release control modified to B-/Called Party Control with changed RTCWeb browser client behaviour along with indication as to "Off Hook" and "On Hook". Does the "hook" map to anything we currently have in our APIs or concepts? > Paul > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From randell-ietf@jesup.org Sun Jul 31 14:23: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 0592F21F8862 for ; Sun, 31 Jul 2011 14:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 voKbQQAXb-mZ for ; Sun, 31 Jul 2011 14:23:43 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2F221F885C for ; Sun, 31 Jul 2011 14:23:43 -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 1QndUB-00011H-Dv for rtcweb@ietf.org; Sun, 31 Jul 2011 16:23:47 -0500 Message-ID: <4E35C78F.1070402@jesup.org> Date: Sun, 31 Jul 2011 17:22:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9EF49A9D-7F17-4E92-AECA-55BC7ABC7339@gmail.com> <4E354B2C.2040505@alvestrand.no> In-Reply-To: <4E354B2C.2040505@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] Possible New Cases - Emergency Services Call & Text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2011 21:23:44 -0000 On 7/31/2011 8:31 AM, Harald Alvestrand wrote: > On 07/30/11 07:03, Paul Beaumont wrote: >> This was mentioned is the initial RTCWeb session at IETF 81 but just >> to make sure it has been captured and understood. >> >> (1) Please can a separate use case be added for an Emergency Services >> telephony call (eg 999 in UK, 112 in EU, 911 in NA, etc). > I am skeptical to adding this use case. The most important issues and > complications that ES brings to the table are with call setup, which I > believe is outside of what RTCWEB should be focusing on. As long as > there is nothing special about the media plane issues here, I would > prefer not to take it on. The main media-plane issues that we should focus on (as opposed to the services built with it) are ones that involve making capabilities available to the application, such as the aforementioned ability to turn off VAD or to force a change from a "voice" codec to a more "general" codec (and maybe to allow in this case automatic activation of the camera, but that's slightly arguable AND with the one exception of VRS-911 there's no current support for cameras in 911 centers. Most of the rest of the requirements fall on the application/service. -- Randell Jesup randell-ietf@jesup.org