From harald@alvestrand.no Fri Feb 1 01:06:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E594821F87DF for ; Fri, 1 Feb 2013 01:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.404 X-Spam-Level: X-Spam-Status: No, score=-110.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 2r64n48iJ686 for ; Fri, 1 Feb 2013 01:06:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE3D21F87E7 for ; Fri, 1 Feb 2013 01:06:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B255E39E031; Fri, 1 Feb 2013 10:06:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ-LlSyJMgTl; Fri, 1 Feb 2013 10:06:39 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2F00C39E0CE; Fri, 1 Feb 2013 10:06:39 +0100 (CET) Message-ID: <510B859E.9070207@alvestrand.no> Date: Fri, 01 Feb 2013 10:06:38 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Martin Thomson References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@alvestrand.no> <510A63DA.3080301@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 09:06:45 -0000 On 02/01/2013 01:16 AM, Martin Thomson wrote: > On 31 January 2013 21:30, Harald Alvestrand wrote: >> I can think of a reasonably easy test that generates the signal (read a mono >> sound from a file to a mediastream using the MediaSource interface, feed it >> to the WebAudio API, apply spatialization effects using the WebAudio API), >> but I'm not sure how you test whether spatialization is actually performed >> correctly. But writing that test should be a W3C matter. > Maybe I'm reading too much into this, but spatialization effects are > used for several reasons: for arrangements of multiple microphones in > the same room, they can be necessary to get proper stereo audio. In > order to do this based on microphone configuration, you need > signaling. If all you are looking for is the ability to spatially > separate different speakers, that clarification might help. Aha - I was reading the use case as "you want to place different speakers at different positions in the virtual audio space" only - seems that the word "spatialization" means more than that. Thanks! > >>>>> F7 The browser MUST support fast stream switches. > ... >> Specified further (yes) or removed (yes)? > Yes. As in pick one and I care little which that is. > >>>> TURN/TLS will satisfy this requirement. >>> This is not always true :) >> What's the case when it isn't? > Some firewalls use traffic analysis to identify real-time data that > has been tunneled over HTTP CONNECT. Yes, argh :-( - I could argue that these fall outside the use case, or I could argue that the requirement should be described well enough to make it not a MUST to be able to avoid these firewalls. You can't win them all.... and we're not designing the Universal Policy Defeater here. > >> I don't read "make before break" either, but that's obviously preferable. >> Now that I dig further back into my memory, I think ICE restart is supposed >> to support make-before-break; you don't have to turn off the old path before >> the new has checked out usable. > ICE restart can do that, but there is no guarantee that triggering a > restart will result in a change of network interface. Further clarity > on the requirement may be necessary to say that it be *possible* to do > this. I think the normal case is "this interface stopped working, can you find me another one?". The less normal case is "I know both 3G and WiFi are working, but I still want to use 3G". If you can tell which IP address belongs to which interface, ICE restart + keeping control of which candidates you allow through to the other side would enable you to control that (albeit hackishly). From stefan.lk.hakansson@ericsson.com Fri Feb 1 02:12:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659E921F852C for ; Fri, 1 Feb 2013 02:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgkVVPhaBWDF for ; Fri, 1 Feb 2013 02:12:15 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 51B7121F84B2 for ; Fri, 1 Feb 2013 02:12:14 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-e5-510b94fb42e9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BA.B1.19728.BF49B015; Fri, 1 Feb 2013 11:12:11 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Feb 2013 11:12:11 +0100 Message-ID: <510B94FB.8000900@ericsson.com> Date: Fri, 1 Feb 2013 11:12:11 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@alvestrand.no> <510A63DA.3080301@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvre7vKdyBBme2K1ms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOdHrjAWnBWsuPVwMUsDYxdfFyMnh4SAicSXmcdZIWwxiQv3 1rN1MXJxCAmcZJS4PfsmE0hCSGA1o8SULjYQm1dAW6K9eyMjiM0ioCLxYsUNMJtNIFDi+v9f YPWiAlES7682MUPUC0qcnPmEBcQWERCW2PqqF6xGWCBYYuXEL4wQy/YwSaxZ1go2iBNo0PGX e8CamQVsJS7Muc4CYctLbH87hxniIF2Jd6/vsU5gFJiFZMcsJC2zkLQsYGRexciem5iZk15u tIkRGGgHt/xW3cF455zIIUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhij pxz+IpKR/+5AX93JG4Xb3wjHTlKT/O1WvXjHw0nTfX+uSPWusjnmc2j9o9OFPst2HLDyTT+7 /Y3jVAYNwziXFZFt/7qfipt/MDPfNnvykdXmEV/cdhz3ePw411iHof/8Wwv5gJ0XzOX6W6ZP yrwW+/7w+/dr1u849jL11b9H+RfvLmD8E+s1U4mlOCPRUIu5qDgRAMtE8ZACAgAA Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 10:12:16 -0000 On 2013-02-01 01:16, Martin Thomson wrote: > On 31 January 2013 21:30, Harald Alvestrand wrote: >> I can think of a reasonably easy test that generates the signal (read a mono >> sound from a file to a mediastream using the MediaSource interface, feed it >> to the WebAudio API, apply spatialization effects using the WebAudio API), >> but I'm not sure how you test whether spatialization is actually performed >> correctly. But writing that test should be a W3C matter. > > Maybe I'm reading too much into this, but spatialization effects are > used for several reasons: for arrangements of multiple microphones in > the same room, they can be necessary to get proper stereo audio. In > order to do this based on microphone configuration, you need > signaling. If all you are looking for is the ability to spatially > separate different speakers, that clarification might help. I agree, we should clarify. But I think many of the requirements are similar in this respect: just reading the requirement itself is not sufficient, you need to read the use-case from which it was derived to get the context and fully understand. > >>>>> F7 The browser MUST support fast stream switches. > ... >> Specified further (yes) or removed (yes)? > > Yes. As in pick one and I care little which that is. > >>>> TURN/TLS will satisfy this requirement. >>> This is not always true :) >> What's the case when it isn't? > > Some firewalls use traffic analysis to identify real-time data that > has been tunneled over HTTP CONNECT. > >> I don't read "make before break" either, but that's obviously preferable. >> Now that I dig further back into my memory, I think ICE restart is supposed >> to support make-before-break; you don't have to turn off the old path before >> the new has checked out usable. > > ICE restart can do that, but there is no guarantee that triggering a > restart will result in a change of network interface. Further clarity > on the requirement may be necessary to say that it be *possible* to do > this. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From stefan.lk.hakansson@ericsson.com Fri Feb 1 02:19:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B9521F87D7 for ; Fri, 1 Feb 2013 02:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIIOwHAo6DNO for ; Fri, 1 Feb 2013 02:19:20 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6478D21F879D for ; Fri, 1 Feb 2013 02:19:20 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-b5-510b96a7acba Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 91.36.32353.7A69B015; Fri, 1 Feb 2013 11:19:19 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Feb 2013 11:19:19 +0100 Message-ID: <510B96A6.8060605@ericsson.com> Date: Fri, 1 Feb 2013 11:19:18 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bernard Aboba References: <50F97303.4070906@ericsson.com>, , , , <510927C4.60808@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3Vnf5NO5Ag/d/FSz2L7nMbLH2Xzu7 A5PH454zbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4M7uJtWCyVEX7u4OMDYwPRboYOTkkBEwk Pp2+zg5hi0lcuLeerYuRi0NI4CSjxOzJS6Cc1YwSr0+1MIJU8QpoS7TfncIGYrMIqEi0znvO CmKzCQRKXP//iwnEFhWIknh/tYkZol5Q4uTMJyxdjBwcIgK6En+7jEDCzALqEncWnwNbLAxU 3vh1KdSuN4wSr9rngSU4BawlXizvYoFosJW4MOc6lC0vsf3tHLD5QkAz372+xzqBUXAWknWz kLTMQtKygJF5FSN7bmJmTnq5+SZGYFAe3PLbYAfjpvtihxilOViUxHnDXS8ECAmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamAU73Lb9mlLtLaQ9pbF62W7p1Q/l3od8GDWAce8/6opAU9bvyxp eVVrr7dcZuut9cKyH3MqMvhO3334++M1LR4zCzaJvf7sD+2WdD/cH6GhyWW8J+qabsDugpif B+dz7ay4ceGGrJDmau1T/R/iSjTUFwhfX9J8rG/xu7f3LG5f+Xv+YEDuxkU+SizFGYmGWsxF xYkA8IFIQBgCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part I) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 10:19:21 -0000 On 2013-01-30 20:30, Bernard Aboba wrote: > > To me it means that the browser should not congest the network (and this > > is regardless of what the possibly malicious app does). > > [BA] Today we have three potential approaches that might be relevant to > this general concern: > > a. Consent. If a receiver is being inundated, they can refuse to > response to ICE keepalives, thereby causing a compliant sender to stop > sending. > b. Circuit breakers. As I understood it, the goal of this document was > to prevent congestive collapse in a number of situations. However, > circuit breakers aren't a complete solution to congestion control, so > the resulting behavior might not be considered "fair" and also it wasn't > clear to me that high packet loss/low throughput would be avoided in all > situations. > c. Congestion control (RMCAT). This is a solution to the congestion > control problem, not just DDOS or worst-case congestive collapse. Since > it covers more ground it is more of a long-term solution than a or b. > > I would like the requirement to be a bit more specific so that we can be > clear which of a, b and/or c address the concern. Solution a is more > of a response to DDOS issues than congestion control per se. Solution > b is designed to address some worst case outcomes, though not > necessarily all of them. Solution c is the long-term solution, but it > may not be available within the same time frame as a or b. I agree to the above, but could we not let the requirement remain as is? Instead, when we some time in the future compare what the WG has specified as solutions with the requirement we can say that this requirement is initially met by a. and b., and c. will be added in a later release. I am not very keen on keep updating the requirements based on the solutions we discuss/opt for. We then risk to lose sight on the original reason for the requirement. > > > > Please note that the requirements specified in this document are to > > > be used in evaluating... protocol submissions. As such, the > > > requirements language refers to capabilities of these protocols; the > > > protocol documents will specify whether these features are required, > > > recommended, or optional. For example, requiring that a protocol > > > support confidentiality is NOT the same thing as requiring that all > > > protocol traffic be encrypted. > > > > This makes a lot of sense. > > [BA] Feel free to tweak the wording above to the needs of RTCWEB. IETF > Requirements documents are often used for different purposes, so one > size doesn't necessarily fit all. For example, the RFC 2989 language > above was created to provide guidelines for selection between competing > protocol proposals. In that particular situation, meeting more > requirements was "better" but it wasn't necessarily expected that the > "winner" would meet all requirements. Other WGs have created > requirements documents to guide protocol development and enable > identification of missing work. In those situations, it isn't > necessarily expected that an initial document set will cover all the > bases, though there may be an expectation that major holes will get > covered somehow at some point. OK, thanks for this input - it is helpful. From stefan.lk.hakansson@ericsson.com Fri Feb 1 02:34:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D546921F8830 for ; Fri, 1 Feb 2013 02:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO3J9P7Mz7Lt for ; Fri, 1 Feb 2013 02:34:43 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0D21F8835 for ; Fri, 1 Feb 2013 02:34:42 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-73-510b9a41b64c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BC.98.32353.14A9B015; Fri, 1 Feb 2013 11:34:41 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Feb 2013 11:34:41 +0100 Message-ID: <510B9A41.8000804@ericsson.com> Date: Fri, 1 Feb 2013 11:34:41 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bernard Aboba References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VtdxFnegwbmN8hb7l1xmtlj7r53d gcnjcc8ZNo8lS34yBTBFcdmkpOZklqUW6dslcGUcu/6TpeC/c8WkKT/ZGhgfmHQxcnJICJhI LO/dyQJhi0lcuLeerYuRi0NI4CSjRN/SM6wQzmpGiRsd/UwgVbwC2hJ7zh5iBrFZBFQkbj3e zAhiswkESlz//wusRlQgSuL91SZmiHpBiZMznwBt4OAQEdCV+NtlBBJmFlCXuLP4HDuILSwQ LdGz7gbUrgVMEt0PDoDN5BSwllh+cgobRIOtxIU511kgbHmJ7W/ngM0XApr57vU91gmMgrOQ rJuFpGUWkpYFjMyrGNlzEzNz0svNNzECg/Lglt8GOxg33Rc7xCjNwaIkzhvueiFASCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA+P88JR9C5i/zZ1e+6ri1dqgT9/u1+ue2MjrtX9GV8Q2XfvJ C41+zTqqG7h4YY/nLn7b3gV7jrJoeykX/hFSsUj1/tNqvI7rtUtdUmwW+5yy+V/Zd+g+ShTq dW+5v17Luvs213eb/2f7LXqVJibuefFyd3vuKb9VC0wkAr+e+fxvteqp1KylS68qsRRnJBpq MRcVJwIA4cBwZxgCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 10:34:43 -0000 On 2013-01-30 21:02, Bernard Aboba wrote: > > > [BA] Can I assume that the use of the plural implies a requirement > to be able to support multiple sources? > > > > Yes. And in the use-case "Hockey Game Viewer" multiple cameras are used. > > [BA] OK. General question: is this something that needs to be > supported in v1.0 (e.g. we need to figure out how multiple source > negotiation works immediately) or can it wait until later? For me, that > question is helpful in distinguishing MUSTs (things we need to have to > either provide basic capabilities, avoid damage to the Internet, or > attain interoperability) from lesser levels like SHOULD (things it would > be very useful to have, but perhaps are not needed immediately). You're right, we should discuss if this is needed for v1 or not. Personally I think we should have support for multiple sources from v1. > > > > [BA] I am not sure what this means. Is it implying the need for a > strategy to deal with loss in the MTI codec? > > > For example, is this implying a requirement for codec adaption, > > > or FEC or re-transmission? I don't see the purpose of letting the > TBD remain here. > > > > The TBD could go; my interpretation is that at the very least there > should be some PLC implemented. > > [BA] OK. It might be helpful to be a bit more specific about what might > address this requirement, assuming we can come to agreement on it. OK. > > > > [BA] What does "graceful" mean?? Is this referring to the > resilience of the codec and > > > loss-strategy (see above), or to enabling the application to adapt > to loss? > > > > I agree. This is very vague. I think that what was in mind at the time > > was that the browser should not be worse than existing native clients > > during bad network conditions (e.g. strange high level audio sounds that > > comes from decoding erroneous data should not be played). I think this > > req could go. > > [BA] I think that this requirement is probably covered adequately by > other ones so it can be omitted. I agree. > > > > [BA] I really am not sure what is meant here. Are we talking about > the ability of a sender to change > > > transmission rate quickly (e.g. removing a layer in SVC)? Or about > adding/removing a stream? > > > > This requirement is derived from the "Video conferencing system with > > central server" use-case. The intention was to say something like "if > > the central node asks for an intraframe, the browser should insert it". > > > > [BA] Synchronization is not necessarily possible or even desirable > in all circumstances. > > > For example, if the video experiences substantial loss, do you > really want to delay the audio to sync > > > with it? So I can understand why it is desirable to support the > capability, but is this > > > really a MUST? I would not bother to attempt to answer the > question; delete it. > > > > You're right: in some cases it is better to not synchronize. But I still > > think the browser MUST support it (even if not used in certain cases). > > [BA] I agree with the "MUST support" formulation. OK. > > > > ---------------------------------------------------------------- > > > F18 The browser MUST be able to process and mix > > > sound objects (media that is retrieved from > > > another source than the established media > > > stream(s) with the peer(s) with audio streams. > > > > > > [BA] If this is done, isn't it important to make clear to the user > (and perhaps the peer) what is happening? > > > Confusing live and recorded media seems like a potential vector for > mischief. > > > > This is derived from the use-case "Multiparty on-line game with voice > > communication". Are you saying that the browser should inform the user > > that the "boom" sound comes from the explosion on the game scene, while > > the voice comes from his friend that is playing the same game? I don't > > see that need. > > [BA] I agree that it is silly in a game scenario. But in an emergency > call, knowing that the video of a hostage situation isn't live would be > pretty important. I agree, but I feel that we're now starting to put requirements on the service rather than the browser or its APIs. > > > > [BA] "Wiretapping" is too vague a phrase to be of much use. It > might make more sense to > > > talk about security services that should be provided (e.g. > confidentiality of media). > > > > This was discussed a bit, and someone (Harald?) pointed out that > > wiretapping is well defined and can be used. > > [BA] If we can refer to a definition this would be helpful in clarifying > the requirement. I think Harald answered this one; but I agree that we should reference. > > > > ---------------------------------------------------------------- > > > F26 It MUST be possible to move from one network > > > interface to another one > > > [BA] Are we talking about the ability of an application to control > this, or the ability of an application to react to it, or something else? > > > > It is not split up between application, browser, STUN/TURN server, it is > > just a requirement on that it should work. > > [BA] My question is whether existing ICE/STUN/TURN RFCs are sufficient > or whether extensions such as ICE Mobility are required to meet this > requirement. Again, I think we should leave the requirement as is (being a bit vague and generic), let the WG design a solution (which now seems to be ICE/STUN/TURN) and then come back and say that this req is met by that solution, and it gives the following characteristics. > > > > ---------------------------------------------------------------- > > > F35 The browser MUST enable verification, given > > > the right circumstances and by use of other > > > trusted communication, of that streams and > > > data received have not been manipulated by > > > any party. > > > [BA] I do not see how such a verification is possible. > > > > I was under the impression that DTLS allowed this. > > [BA] DTLS/SRTP can verify that there is no man-in-the-middle. But it > doesn't address modification by an endpoint that is a media gateway. Yes, but the browser will (to my understanding) make the fingerprints available to the users (at request), and they can then detect if there are other end-points in the path. So it is possible "under the right circumstances". > Also, there is the replay vs. live issue. Yes, that is one issue. > > > > ---------------------------------------------------------------- > > > F36 The browser MUST reject incoming media and > > > data, either modified, created or injected, > > > by any entity not trusted by the site. > > > > > > [BA] Do we really mean "trusted by the site" or "trusted by the > browser"? > > > > I need to think a bit more about this one. > > [BA] While the security document advises the use of HTTPS for signaling, > it doesn't prohibit use of HTTP. Also, for media there probably will be > scenarios where the client is unauthenticated, even if the server is > authenticated (e.g. DTLS/SRTP with asymmetric trust). My advice is to > reformulate this as a requirement for support of {media, signaling} > authentication/integrity protection, rather than use. We need to look into that. > > One last question, about A25: > > A25 It must be possible for the application to > refrain from exposing the IP address > > [BA] I am assuming we are talking about exposing the originating IP address of media, which can be addressed via TURN. > If so, this is more of a protocol than an API requirement. Since the ICE candidates need to exposed in the API in > order to allow them to be signaled, I am not sure how we can avoid exposing those to the application. Similarly, the > HTTP server can obtain the IP address used by the HTTP client. Even within SIP, there are VIA headers and contact > headers, so it is not easy to avoid disclosure of the IP address to everyone. So I think we need to be more clear > about what we are trying to avoid exposing, and to whom. Personally I would like to get rid of this requirement. The application can always get all candidates. To have a way to let the application ask for _only_ the TURN candidates does not change this - that kind of API is more for convenience (so that the app you trust does not have to remove privacy revealing candidates from the offer, but can instead ask the browser to deliver an offer without them). > > From harald@alvestrand.no Fri Feb 1 02:58:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF321F8644 for ; Fri, 1 Feb 2013 02:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKSX6eobzflb for ; Fri, 1 Feb 2013 02:58:36 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E9B0E21F8639 for ; Fri, 1 Feb 2013 02:58:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9CBF39E0CE for ; Fri, 1 Feb 2013 11:58:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMLCgUXVcLBx for ; Fri, 1 Feb 2013 11:58:32 +0100 (CET) Received: from [10.130.0.44] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9DE1739E031 for ; Fri, 1 Feb 2013 11:58:32 +0100 (CET) Message-ID: <510B9FD8.6000008@alvestrand.no> Date: Fri, 01 Feb 2013 11:58:32 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com> <510B9A41.8000804@ericsson.com> In-Reply-To: <510B9A41.8000804@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 10:58:36 -0000 On 02/01/2013 11:34 AM, Stefan Håkansson LK wrote: >> >> A25 It must be possible for the application to >> refrain from exposing the IP address >> >> [BA] I am assuming we are talking about exposing the originating IP >> address of media, which can be addressed via TURN. >> If so, this is more of a protocol than an API requirement. Since the >> ICE candidates need to exposed in the API in >> order to allow them to be signaled, I am not sure how we can avoid >> exposing those to the application. Similarly, the >> HTTP server can obtain the IP address used by the HTTP client. Even >> within SIP, there are VIA headers and contact >> headers, so it is not easy to avoid disclosure of the IP address to >> everyone. So I think we need to be more clear >> about what we are trying to avoid exposing, and to whom. > > Personally I would like to get rid of this requirement. The > application can always get all candidates. To have a way to let the > application ask for _only_ the TURN candidates does not change this - > that kind of API is more for convenience (so that the app you trust > does not have to remove privacy revealing candidates from the offer, > but can instead ask the browser to deliver an offer without them). I think this requirement is important, but needs reformulation. Should we instead say "It MUST be possible to set up a call between two parties A and B without one party learning the other party's IP address" This doesn't place any requirement that the signalling server should be kept in the dark. From stefan.lk.hakansson@ericsson.com Fri Feb 1 04:09:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449F321F8CB4 for ; Fri, 1 Feb 2013 04:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCjl66iu2hff for ; Fri, 1 Feb 2013 04:09:23 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D72221F89A3 for ; Fri, 1 Feb 2013 04:09:21 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-18-510bb0700d6e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 69.17.32353.070BB015; Fri, 1 Feb 2013 13:09:20 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Feb 2013 13:09:20 +0100 Message-ID: <510BB070.9040602@ericsson.com> Date: Fri, 1 Feb 2013 13:09:20 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com> <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> In-Reply-To: <510B9FD8.6000008@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+JvrW7BBu5Ag8VN2hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/XzRWwFZ/kr7u7fyNzAOJ2ni5GTQ0LAROLFhGYmCFtM4sK9 9WxdjFwcQgInGSVO9J9lh3BWM0r8fXqXEaSKV0Bb4uzRQ8wgNouAisSSaVtZQGw2gUCJ6/9/ gU0SFYiSeH+1iRmiXlDi5MwnYDUiAsISW1/1AtVwcAgLVEisaXWEmP+cSeL2ibnsIDWcAroS XXc3gfUyC9hKXJhznQXClpdo3jobLC4EVPPu9T3WCYwCs5CsmIWkZRaSlgWMzKsY2XMTM3PS y803MQID7eCW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 43Ijo8Uv83k72W+1127Z9Su1V+xN7wLVxz/a009mfSpXaVfY5bHyYnJDn1Kw//ttmjPXHE4V XRm8Iu/xmti374OzAhSPyVc+duXidrHNfHd55jxPHX5ple0OJTHhWkuX2za0/M5cnR2azHDv 8NTMvQoBFQusZok18Nx5uctApzW1k2df8rsbSizFGYmGWsxFxYkAkqfVWwICAAA= Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 12:09:25 -0000 On 2013-02-01 11:58, Harald Alvestrand wrote: > On 02/01/2013 11:34 AM, Stefan Håkansson LK wrote: >>> >>> A25 It must be possible for the application to >>> refrain from exposing the IP address >>> >>> [BA] I am assuming we are talking about exposing the originating IP >>> address of media, which can be addressed via TURN. >>> If so, this is more of a protocol than an API requirement. Since the >>> ICE candidates need to exposed in the API in >>> order to allow them to be signaled, I am not sure how we can avoid >>> exposing those to the application. Similarly, the >>> HTTP server can obtain the IP address used by the HTTP client. Even >>> within SIP, there are VIA headers and contact >>> headers, so it is not easy to avoid disclosure of the IP address to >>> everyone. So I think we need to be more clear >>> about what we are trying to avoid exposing, and to whom. >> >> Personally I would like to get rid of this requirement. The >> application can always get all candidates. To have a way to let the >> application ask for _only_ the TURN candidates does not change this - >> that kind of API is more for convenience (so that the app you trust >> does not have to remove privacy revealing candidates from the offer, >> but can instead ask the browser to deliver an offer without them). > I think this requirement is important, but needs reformulation. > > Should we instead say > > "It MUST be possible to set up a call between two parties A and B > without one party learning the other party's IP address" This requirement is not on the browser (or its APIs) per se, if we go this path it almost belongs into another category than what we currently have. > > This doesn't place any requirement that the signalling server should be > kept in the dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Fri Feb 1 04:14:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3007321F86A9 for ; Fri, 1 Feb 2013 04:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.349, 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 cY594RHMRdNk for ; Fri, 1 Feb 2013 04:14:10 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 55DE221F85CE for ; Fri, 1 Feb 2013 04:14:10 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so2033424eek.34 for ; Fri, 01 Feb 2013 04:14:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Oe96Lzr+rLHI+57YQK2g25TV6i4PF7dEqwudhNXXb/I=; b=LZafxCoHgbgmQEz9AUBdS1ZPGxr7+0TTnYPmi+wVbJLJz8plcDveCe297TgPPzIyOH ZX7gi4LgNzL9r3iB51J06ea5LD44fyVMNUJcmc6VApTbyQ3wjfe3hNUCmJNWYVSAO0vP vGpexxvqmx/y5mMuvNT4EeI0scyWCRhOa++BT+Jg0lCEU9GolcJ2K/16+d4hp/15h53l lTu81FnZH3z7BsisHnluStzAFbaIXs0dqUQVsFjKYdBps23DFr6Tuc7nhpAw0CPvuna8 FVf2HLDkoiUqxhUUczo5xNiA9EPnw1to+TbC5vsrlrOGcl1Aa+YUkgTQV7jfJalhIlEH 7QfA== X-Received: by 10.14.2.5 with SMTP id 5mr38950438eee.30.1359720849249; Fri, 01 Feb 2013 04:14:09 -0800 (PST) Received: from dhcp-guest-bru-peg1-144-254-105-41.cisco.com (dhcp-guest-bru-peg1-144-254-105-41.cisco.com. [144.254.105.41]) by mx.google.com with ESMTPS id f49sm12244390eep.12.2013.02.01.04.14.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 04:14:07 -0800 (PST) Message-ID: <510BB191.4080008@jitsi.org> Date: Fri, 01 Feb 2013 13:14:09 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com> <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> In-Reply-To: <510BB070.9040602@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQntlEqqsfjd6Zl8kug8w2tVGGkY1AfzR5rfQmK9Kw+59M5KM3O1cx2oqiZ8Py2dg7Grwsac Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 12:14:12 -0000 On 01.02.13, 13:09, Stefan H=E5kansson LK wrote: >>> Personally I would like to get rid of this requirement. The >>> application can always get all candidates. To have a way to let the >>> application ask for _only_ the TURN candidates does not change this -= >>> that kind of API is more for convenience (so that the app you trust >>> does not have to remove privacy revealing candidates from the offer, >>> but can instead ask the browser to deliver an offer without them). >> I think this requirement is important, but needs reformulation. >> >> Should we instead say >> >> "It MUST be possible to set up a call between two parties A and B >> without one party learning the other party's IP address" >=20 > This requirement is not on the browser (or its APIs) per se, if we go=20 > this path it almost belongs into another category than what we currentl= y=20 > have. Well, if we agree that we care about the requirement itself, then the browser has to generate SDP with no host addresses and use 0.0.0.0 instea= d. (Unless we are OK with the application parsing and modifying the SDP before sending it) Emil >=20 >=20 >=20 >> >> This doesn't place any requirement that the signalling server should b= e >> kept in the dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 https://jitsi.org From bernard_aboba@hotmail.com Fri Feb 1 04:25:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1734E21F8658 for ; Fri, 1 Feb 2013 04:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 IPXxRXmq1JlX for ; Fri, 1 Feb 2013 04:25:50 -0800 (PST) Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6A14D21F8653 for ; Fri, 1 Feb 2013 04:25:50 -0800 (PST) Received: from BLU403-EAS30 ([65.55.116.72]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Feb 2013 04:25:49 -0800 X-EIP: [fB3nwjtjFMXpgzeClAC+39x/Z5utGRtI] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <50F97303.4070906@ericsson.com> <5109265F.6040106@ericsson.com> <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <510B9FD8.6000008@alvestrand.no> Date: Fri, 1 Feb 2013 04:25:48 -0800 To: Harald Alvestrand X-OriginalArrivalTime: 01 Feb 2013 12:25:49.0371 (UTC) FILETIME=[44AE60B0:01CE0077] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 12:25:51 -0000 VGhpcyByZWZvcm11bGF0aW9uIHNlZW1zIGNsb3NlciB0byB3aGF0IHdlIGFyZSB0cnlpbmcgdG8g ZG8uIA0KDQpPbiBGZWIgMSwgMjAxMywgYXQgMjo1OCBBTSwgIkhhcmFsZCBBbHZlc3RyYW5kIiA8 aGFyYWxkQGFsdmVzdHJhbmQubm8+IHdyb3RlOg0KDQo+IE9uIDAyLzAxLzIwMTMgMTE6MzQgQU0s IFN0ZWZhbiBIw6VrYW5zc29uIExLIHdyb3RlOg0KPj4+IA0KPj4+ICAgIEEyNSAgICAgICAgICAg ICBJdCBtdXN0IGJlIHBvc3NpYmxlIGZvciB0aGUgYXBwbGljYXRpb24gdG8NCj4+PiAgICAgICAg ICAgICAgICAgICAgcmVmcmFpbiBmcm9tIGV4cG9zaW5nIHRoZSBJUCBhZGRyZXNzDQo+Pj4gDQo+ Pj4gW0JBXSBJIGFtIGFzc3VtaW5nIHdlIGFyZSB0YWxraW5nIGFib3V0IGV4cG9zaW5nIHRoZSBv cmlnaW5hdGluZyBJUCBhZGRyZXNzIG9mIG1lZGlhLCB3aGljaCBjYW4gYmUgYWRkcmVzc2VkIHZp YSBUVVJOLg0KPj4+IElmIHNvLCB0aGlzIGlzIG1vcmUgb2YgYSBwcm90b2NvbCB0aGFuIGFuIEFQ SSByZXF1aXJlbWVudC4gU2luY2UgdGhlIElDRSBjYW5kaWRhdGVzIG5lZWQgdG8gZXhwb3NlZCBp biB0aGUgQVBJIGluDQo+Pj4gb3JkZXIgdG8gYWxsb3cgdGhlbSB0byBiZSBzaWduYWxlZCwgSSBh bSBub3Qgc3VyZSBob3cgd2UgY2FuIGF2b2lkIGV4cG9zaW5nIHRob3NlIHRvIHRoZSBhcHBsaWNh dGlvbi4gIFNpbWlsYXJseSwgdGhlDQo+Pj4gSFRUUCBzZXJ2ZXIgY2FuIG9idGFpbiB0aGUgSVAg YWRkcmVzcyB1c2VkIGJ5IHRoZSBIVFRQIGNsaWVudC4gRXZlbiB3aXRoaW4gU0lQLCB0aGVyZSBh cmUgVklBIGhlYWRlcnMgYW5kIGNvbnRhY3QNCj4+PiBoZWFkZXJzLCBzbyBpdCBpcyBub3QgZWFz eSB0byBhdm9pZCBkaXNjbG9zdXJlIG9mIHRoZSBJUCBhZGRyZXNzIHRvIGV2ZXJ5b25lLiAgU28g SSB0aGluayB3ZSBuZWVkIHRvIGJlIG1vcmUgY2xlYXINCj4+PiBhYm91dCB3aGF0IHdlIGFyZSB0 cnlpbmcgdG8gYXZvaWQgZXhwb3NpbmcsIGFuZCB0byB3aG9tLg0KPj4gDQo+PiBQZXJzb25hbGx5 IEkgd291bGQgbGlrZSB0byBnZXQgcmlkIG9mIHRoaXMgcmVxdWlyZW1lbnQuIFRoZSBhcHBsaWNh dGlvbiBjYW4gYWx3YXlzIGdldCBhbGwgY2FuZGlkYXRlcy4gVG8gaGF2ZSBhIHdheSB0byBsZXQg dGhlIGFwcGxpY2F0aW9uIGFzayBmb3IgX29ubHlfIHRoZSBUVVJOIGNhbmRpZGF0ZXMgZG9lcyBu b3QgY2hhbmdlIHRoaXMgLSB0aGF0IGtpbmQgb2YgQVBJIGlzIG1vcmUgZm9yIGNvbnZlbmllbmNl IChzbyB0aGF0IHRoZSBhcHAgeW91IHRydXN0IGRvZXMgbm90IGhhdmUgdG8gcmVtb3ZlIHByaXZh Y3kgcmV2ZWFsaW5nIGNhbmRpZGF0ZXMgZnJvbSB0aGUgb2ZmZXIsIGJ1dCBjYW4gaW5zdGVhZCBh c2sgdGhlIGJyb3dzZXIgdG8gZGVsaXZlciBhbiBvZmZlciB3aXRob3V0IHRoZW0pLg0KPiBJIHRo aW5rIHRoaXMgcmVxdWlyZW1lbnQgaXMgaW1wb3J0YW50LCBidXQgbmVlZHMgcmVmb3JtdWxhdGlv bi4NCj4gDQo+IFNob3VsZCB3ZSBpbnN0ZWFkIHNheQ0KPiANCj4gIkl0IE1VU1QgYmUgcG9zc2li bGUgdG8gc2V0IHVwIGEgY2FsbCBiZXR3ZWVuIHR3byBwYXJ0aWVzIEEgYW5kIEIgd2l0aG91dCBv bmUgcGFydHkgbGVhcm5pbmcgdGhlIG90aGVyIHBhcnR5J3MgSVAgYWRkcmVzcyINCj4gDQo+IFRo aXMgZG9lc24ndCBwbGFjZSBhbnkgcmVxdWlyZW1lbnQgdGhhdCB0aGUgc2lnbmFsbGluZyBzZXJ2 ZXIgc2hvdWxkIGJlIGtlcHQgaW4gdGhlIGRhcmsuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0 Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYg0K From btdingle@gmail.com Fri Feb 1 05:20:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1060721F8C50 for ; Fri, 1 Feb 2013 05:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MANGLED_OFF=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBdHyPFhFm4E for ; Fri, 1 Feb 2013 05:20:04 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id C85D921F8C10 for ; Fri, 1 Feb 2013 05:20:03 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so2922180wer.36 for ; Fri, 01 Feb 2013 05:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uWQEZnW+5sWTfXcbpbdTeqOSDbF6MJKRXWBffBHQksc=; b=qsmWPQzUFi9hNWFKvFVU34QRED8l6+RDZjX2c8yOEyBbGCYbiT47VNTtrCA1AE5dNo lqeEr7RpPIk4rgFWsAPxSe/6U2cZ1qtP42ugzbRhct6mnGqThfQ7qIOxVxST3n4GFGJT Qbq8eAJdO0ecgrFAXW85JIaJpScDD/uqgZzNhvJV62W8uFlg3HzqpM1eXSzaLjXjSMLJ yDCtccnJFjTbU4TghdJEPt2qfsmJFDfsyz073gYk8Xbc+Lqj3NhQrHdbG/xNYMPlbSLy MW82ug0MEz6sQ/wuyF5CxlPtgjWfMiGmskS0LgrQHHHkNOuskH8M21QyJAhzw5rvuC/R FRuQ== X-Received: by 10.180.72.232 with SMTP id g8mr2841530wiv.0.1359724802823; Fri, 01 Feb 2013 05:20:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.82.133 with HTTP; Fri, 1 Feb 2013 05:19:42 -0800 (PST) In-Reply-To: <510AF934.2030800@alvestrand.no> References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se> <510AF934.2030800@alvestrand.no> From: Barry Dingle Date: Sat, 2 Feb 2013 00:19:42 +1100 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d043c8194dd57b104d4a999d0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time 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: Fri, 01 Feb 2013 13:20:06 -0000 --f46d043c8194dd57b104d4a999d0 Content-Type: text/plain; charset=UTF-8 Good point Harald regarding F.700 A.3.2.3 calling up "font support for *all characters* in ISO-10646-1". I suspect that the reference to F.700 was to the service and performance requirements of a range of multimedia services. I am not aware of another 'more suitable' set of Service Requirements document that we can reference. F.700 (and F.703) are frequently referenced - but some people probably quietly ignore the full implications of A.3.2.3. So we need to capture the 'general service requirements' but remove any parts of F.700 (or F.703) that are not applicable. As the proposed additional use-case just adds RTT to the video+audio, I suggest that we just add the (selected) RTT Requirements that suit rtcweb to the use-case and maybe put an informational note to F.700 and F.703. Cheers, /Barry Dingle On Fri, Feb 1, 2013 at 10:07 AM, Harald Alvestrand wrote: > FWIW, I strongly object to a couple of formalities here: > > - I object to making normative reference to F.700 and F.703. > - I object to requiring interworking with emergency services. > > If there's strong support in the WG for including the use case, I'm > willing to go along with that. > > (The reason for not wanting to normatively reference F.700 and F.703 is > that they're very large balls of string, and I have no idea where the > string may lead; for instance, the definition of "Total Conversation" in > section A.3.2.3 of F.700 requires font support for all characters in > ISO-10646-1; I doubt somewhat that the person who wrote that paragraph has > studied the task of providing such font support - I found that particular > linkage in a few minutes of scanning the docs.) > > > On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote: > > 4.2.15. Simple Total Conversation service**** > > 4.2.15.1. Description**** > > ** ** > > This use-case has the audio and video communication of the Simple**** > > Video Communication Service use-case (Section 4.2.1 ).**** > > ** ** > > In addition to this, the users can send and receive real-time text > in the same call.**** While one user types in the real-time text area, it**** > > is nearly immediately presented to the other user. > > By providing these three media together, the Total Conversation > service is provided. > > Interworking with SIP calls with the same media set, and with SIP > based emergency services is also in scope of this use case. **** > > ** ** > > 4.2.15.2. Derived Requirements**** > > ** ** > > F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,**** > > ** ** > > F39,F40, F41**** > > ** ** > > A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27**** > > ** ** > > .............. > > F39 The browser MUST be able to handle text entry**** > > via applications to generate real-time text streams to be included in Total Conversation > calls. Real-time text and Total Conversation > Services are defined in ITU-T F.700 and F.703. **** > > ----------------------------------------------------------------**** > > F40 The browser MUST be able to send real-time text **** > > streams to a peer.**** > > ** ** > > ----------------------------------------------------------------**** > > F41 The browser MUST be able to receive, process and**** > > convey real-time text streams from peers to > applications.**** > > ----------------------------------------------------------------**** > > **** > > ** > > ..... > ** A27 The Web API MUST provide a mechanisms for **** > handling real-time text among the streams.**** > ----------------------------------------------------------------**** > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043c8194dd57b104d4a999d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good point Harald regarding F.700 A.3.2.3 calling up "font support for all characters in ISO-10646-1".

I sus= pect that the reference to F.700 was to the service and performance require= ments of a range of multimedia services. I am not aware of another 'mor= e suitable' set of Service Requirements document that we can reference.= F.700 (and F.703) are frequently referenced - but some people probably qui= etly ignore the full implications of A.3.2.3.

So we need to capture the 'general service requirements' but re= move any parts of F.700 (or F.703) that are not applicable.

As the = proposed additional use-case just adds RTT to the video+audio, I suggest th= at we just add the (selected) RTT Requirements that suit rtcweb to the use-= case and maybe put an informational note to F.700 and F.703.

Cheers,
/Barry Dingle



On Fri, Feb 1, 2013 at 10:07 AM, Harald = Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
FWIW, I strongly object to a couple of formalities here:

- I object to making normative reference to F.700 and F.703.
- I object to requiring interworking with emergency services.

If there's strong support in the WG for including the use case, I'm willing to go along with that.

(The reason for not wanting to normatively reference F.700 and F.703 is that they're very large balls of string, and I have no idea where the string may lead; for instance, the definition of "Total Conversation" in section A.3.2.3 of F.700 requires f= ont support for all characters in ISO-10646-1; I doubt somewhat that the person who wrote that paragraph has studied the task of providing such font support - I found that particular linkage in a few minutes of scanning the docs.)


On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote:
Section 4.2.1). 
=C2=A0
=C2=A0=C2=A0 In addition to this, the users can sen=
d and receive real-time text
   in the same call. While one user types in the=
 real-time text area, it
=C2=A0 =C2=A0is nearly immediately presented to the other=
 user.

   By providing these three media together, the Total Conversation
  =C2=A0service is provided.

   Interworking with SIP calls with the same media set, and with SIP
  =C2=A0based emergency services is also in scope of this use case. =

=C2=A0
4.=
2.15.2.=C2=A0 Derived Requirements
=C2=A0
=C2=A0=C2=A0 F1, F2, F3, F4, F5, =
F6, F8, F9, F10, F20, F21,
=C2=A0
=C2=A0=C2=A0 F39,F40, F41<=
u>
=C2=A0
=C2=A0=C2=A0 A1, A2, A3, A4, A7, =
A8, A9, A10, A11, A12, A27
=C2=A0
..............

=20 
=C2=A0=C2=A0 F39=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The =
browser MUST be able to handle text entry
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 via applications to generate real-time=20
                   text streams to be included in=
 Total Conversation
                   calls. Real-time text and Total Conversation
                   Services are defined in ITU-T F.700 and F.703. 
=C2=A0=C2=A0 --------------------=
--------------------------------------------
=C2=A0=C2=A0 F40=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 The browser MUST be able to send real-time text 
      
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
streams to a peer.

      
=C2=A0

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

      
=C2=A0=C2=A0 F41=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 The browser MUST be able to receive, process and
      
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0convey real-time text streams from peers to=20
                    applications.

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

      
=C2=A0=C2=A0 

      
=C2=A0

.....

=C2=A0=C2=A0 A27=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T=
he Web API MUST provide a mechanisms for =20
 =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=C2=A0=C2=A0=C2=A0=C2=A0 handling real-time text among the str=
eams.=20
=C2=A0--------------------------------------------------------------=
--


     =20
     =20
     =20
     =20
     =20
     =20
     =20
     =20


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


--f46d043c8194dd57b104d4a999d0-- From bernard_aboba@hotmail.com Fri Feb 1 13:15:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706D321E8044 for ; Fri, 1 Feb 2013 13:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkeFoWn-7UYu for ; Fri, 1 Feb 2013 13:15:28 -0800 (PST) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6040B11E809C for ; Fri, 1 Feb 2013 13:15:28 -0800 (PST) Received: from BLU405-EAS308 ([65.55.116.73]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Feb 2013 13:15:28 -0800 X-EIP: [ObKLpk8g51ajZIdzM7QIYjvcmlKrLR99] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: MIME-Version: 1.0 From: Bernard Aboba To: "=?utf-8?Q?rtcweb@ietf.org?=" , =?utf-8?Q?Harald_Alvestrand?= Importance: Normal Date: Fri, 1 Feb 2013 21:15:23 +0000 Content-Type: multipart/alternative; boundary="_752F428E-3C73-44EC-9B21-895C597B5F9C_" X-OriginalArrivalTime: 01 Feb 2013 21:15:28.0415 (UTC) FILETIME=[4277AAF0:01CE00C1] Subject: Re: [rtcweb] =?utf-8?q?2119_language_in_requirements_=28Re=3A_Review_?= =?utf-8?q?of_draft-ietf-rtcweb-use-cases-and-requirements-10_=28Part_I=29?= =?utf-8?q?=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 21:15:29 -0000 --_752F428E-3C73-44EC-9B21-895C597B5F9C_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SSBjYW5ub3QgZmluZCBhbiBSRkMgdGhhdCBkZWFscyB3aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZSBp biByZXF1aXJlbWVudHMgZG9jdW1lbnRzIHNwZWNpZmljYWxseS4gUGFydCBvZiB0aGUgcmVhc29u IGZvciB0aGF0IG1heSBiZSB0aGF0IHJlcXVpcmVtZW50cyBkb2N1bWVudHMgYXJlIGJ5IG5vIG1l YW5zIHVuaWZvcm0uICBTb21lIGFyZSBjcmVhdGVkIHRvIGFzc2lzdCBpbiBtYWtpbmcgYSBzZWxl Y3Rpb24gYmV0d2VlbiBjb21wZXRpbmcgcHJvdG9jb2xzLiAgU29tZSBhcmUganVzdCBjcmVhdGVk IHRvIGluZm9ybSBzdWJzZXF1ZW50IFdHIHByb3RvY29sIGRlc2lnbiBlZmZvcnRzLiAgU29tZXRp bWVzIHRoZSBldmVudHVhbCBvdXRwdXQgaXMgZXZhbHVhdGVkIGFnYWluc3QgdGhlIHJlcXVpcmVt ZW50cywgc29tZXRpbWVzIG5vdC4gIFdpdGggc3VjaCBhIGxldmVsIG9mIHZhcmlhdGlvbiwgaXQg aXMgbm90IGNsZWFyIG1lIHRoYXQg4oCcb25lIHNpemUgZml0cyBhbGzigJ0uICANCg0KIA0KDQpP dmVyYWxsLCBJ4oCZZCBzYXkgaXQgaXMgdXAgdG8gSUVURiBSVENXRUIgKGFuZCBXM0MgV0VCUlRD KSB0byBkZWNpZGUgaG93IGl0IHdhbnRzIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgdG8gYmUg dXNlZCwgYW5kIHRoaXMgaW4gdHVybiB3aWxsIGluZmx1ZW5jZSB3aGF0IHRoZSBub3JtYXRpdmUg bGFuZ3VhZ2Ugd2lsbCBtZWFuLiAgSnVkZ2luZyBieSB0aGUgbnVtYmVyIG9mIGlzc3VlcyB3ZSBo YXZlIGhhZCB3aXRoIHJlcXVpcmVtZW50cyBkb2N1bWVudHMgaW4gdGhlIHBhc3QgKGUuZy4gdHlw aWNhbGx5IHRoZSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBwcm9ibGVtIGV2b2x2ZXMgY29uc2lkZXJh Ymx5IG92ZXIgdGltZSBhbmQgb2Z0ZW4gaW5pdGlhbGx5IHNwZWNpZmllZCByZXF1aXJlbWVudHMg YXJlIOKAnG92ZXJ0YWtlbiBieSBldmVudHPigJ0pLCB3ZSBzaG91bGQgYmUgY2FyZWZ1bCBhYm91 dCBzZXR0aW5nIGV4cGVjdGF0aW9ucyB0b28gaGlnaC4gDQoNCg0KRnJvbTogSGFyYWxkIEFsdmVz dHJhbmQNClNlbnQ6IOKAjkphbnVhcnnigI4g4oCOMzDigI4sIOKAjjIwMTMg4oCOMuKAjjrigI4w MuKAjiDigI5BTQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gMjExOSBs YW5ndWFnZSBpbiByZXF1aXJlbWVudHMgKFJlOiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWIt dXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTAgKFBhcnQgSSkpDQoNCg0KDQpCZXJuYXJkLCB3 aXRoIHlvdXIgSUFCIGhhdCBvbiAtIGRpZG4ndCB3ZSBkbyBhIGRvY3VtZW50IGRlc2NyaWJpbmcg aG93IHRvIGRvIDIxMTkgbGFuZ3VhZ2UgaW4gcmVxdWlyZW1lbnRzIGF0IG9uZSB0aW1lPw0KKFNp bmNlIHRoZSB3b3JkICJyZXF1aXJlbWVudHMiIG9jY3VycyBzbyBvZnRlbiBpbiAyMTE5IGl0c2Vs ZiwgaXQncyBoYXJkIHRvIGdvb2dsZSBmb3IgaXQpDQoNCkZhaWxpbmcgdGhhdCwgSSBzdXBwb3J0 IGFkYXB0aW5nIHRoZSBsYW5ndWFnZSBvZiBSRkMgMjkyOCAobmVlZHMgYWRhcHRpbmcsIGJlY2F1 c2Ugd2UncmUgZXhwZWN0aW5nIHRvIGRldmVsb3AgYSBzaW5nbGUgc3BlY2lmaWNhdGlvbiBzdWl0 ZSByYXRoZXIgdGhhbiBldmFsdWF0aW5nIG11bHRpcGxlIHN1Ym1pc3Npb25zKSBhbmQgaW5zZXJ0 aW5nIGl0IGhlcmUuDQoNCg0KT24gMDEvMjkvMjAxMyAxMTozNiBQTSwgQmVybmFyZCBBYm9iYSB3 cm90ZToNCg0KDQoNCkkgaGF2ZSBhIHZlcnkgZnVuZGFtZW50YWwgcXVlc3Rpb24gYWJvdXQgdGhp cyBkb2N1bWVudDoNCg0KV2hhdCBhcmUgdGhlIEJyb3dzZXIgYW5kIEFQSSByZXF1aXJlbWVudHMg Z29pbmcgdG8gYmUgdXNlZCBmb3I/IA0KDQpJcyB0aGUgZ29hbCB0byBkb2N1bWVudCB0aGluZ3Mg d2UgdGhvdWdodCBtaWdodCBoYXZlIGJlZW4gbmljZSBhdCB0aGUgdGltZT8NCg0KSW4gbWFueSBj YXNlcywgdGhlIHJlcXVpcmVtZW50cyBhcmUgdG9vIHZhZ3VlIHRvIGVhc2lseSBkZXRlcm1pbmUg d2hldGhlciBzdWJzZXF1ZW50IElFVEYNCnByb3RvY29sIHByb2ZpbGVzIG9yIFczQyBBUEkgZG9j dW1lbnRzIGFjdHVhbGx5IHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cy4gIEJ1dCBldmVuIGlmIHRo ZXkgd2VyZQ0KbWFkZSBtb3JlIHNwZWNpZmljLCBpcyB0aGVyZSByZWFsbHkgYW55IGludGVudCB0 byBldmFsdWF0ZSBJRVRGIGFuZCBXM0Mgd29yayBiYXNlZCBvbiB0aGVzZSByZXF1aXJlbWVudHM/ DQoNClNlY3Rpb24gMiBzdGF0ZXMgdGhhdCBub3JtYXRpdmUga2V5d29yZHMgYXJlIHRvIGJlIGlu dGVycHJldHRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkuDQpTaW5jZSB0aGlzIGlzbid0IGEg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwgZG9lcyB0aGF0IHJlYWxseSBtYWtlIHNlbnNlPw0KDQpB cyBhbiBleGFtcGxlLCByZXF1aXJlbWVudCBGMyBzdGF0ZXM6DQoNCiJUcmFuc21pdHRlZCBzdHJl YW1zIGFuZCBkYXRhIE1VU1QgYmUgcmF0ZSBjb250cm9sbGVkLiINCg0KV2hpbGUgdGhlIHN0YXRl bWVudCBhYm92ZSBtaWdodCBtYWtlIHNvbWUgc2Vuc2UgaW4gdGhlIGNvbnRleHQgb2YgdGhlICJj aXJjdWl0IGJyZWFrZXJzIiBkb2N1bWVudCwgb3INCnBlcmhhcHMgb25lIG9mIHRoZSBjb25nZXN0 aW9uIGNvbnRyb2wgZG9jdW1lbnRzLCBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB0aGUgTVVTVCBt ZWFucyBpbiB0aGUgY29udGV4dCBvZg0KdGhpcyBkb2N1bWVudC4gDQoNCkRvZXMgaXQgbWVhbiB0 aGF0IHRoZSBzcGVjaWZpY2F0aW9ucyBhcmUgcmVxdWlyZWQgdG8gZGVmaW5lIGEgcmF0ZSBjb250 cm9sIGZlYXR1cmU/IA0KQXNzdW1pbmcgc3VjaCBhIGZlYXR1cmUgaXMgZGVmaW5lZCwgZG9lcyBp dCBtZWFuIHRoYXQgYnJvd3NlcnMgYXJlIHJlcXVpcmVkIHRvIGltcGxlbWVudCB0aGUgZmVhdHVy ZT8gDQpJZiBpbXBsZW1lbnRhdGlvbiBpcyByZXF1aXJlZCwgaXMgaXQgcmVxdWlyZWQgdGhhdCB0 aGUgZmVhdHVyZSBiZSB1c2VkPyANCg0KUGVyc29uYWxseSwgbXkgZ3Vlc3MgaXMgdGhhdCB0aGUg bWVhbmluZyBwcm9iYWJseSBkb2VzIG5vdCBjb3JyZXNwb25kIHRvIGFueSBvZiB0aGUgYWJvdmUs IGJlY2F1c2UgdGhpcyANCmlzIG9ubHkgYSB1c2UgY2FzZSBkb2N1bWVudCwgbm90IGEgcHJvdG9j b2wgb3IgQVBJIHNwZWNpZmljYXRpb24uDQoNCkJ1dCBpZiB0aGF0IGlzIHRydWUsIHdoeSBwb2lu dCB0byB0aGUgUkZDIDIxMTkgZGVmaW5pdGlvbiBvZiBub3JtYXRpdmUgdGVybXM/IA0KDQpJbiB0 aGUgcGFzdCwgYSBudW1iZXIgb2YgcmVxdWlyZW1lbnRzIGRvY3VtZW50cyBoYXZlIHRhY2tsZWQg dGhpcyBwcm9ibGVtIGJ5IGV4cGxpY2l0bHkNCnN0YXRpbmcgdGhhdCBob3cgbm9ybWF0aXZlIGxh bmd1YWdlIGlzIHRvIGJlIGludGVycHJldHRlZCwgcmF0aGVyIHRoYW4gYmxpbmRseSBpbnNlcnRp bmcgYSANCnJlZmVyZW5jZSB0byBSRkMgMjExOS4gIEZvciBleGFtcGxlLCBSRkMgMjk4OSBzdGF0 ZXM6DQoNCiAgIFBsZWFzZSBub3RlIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBzcGVjaWZpZWQgaW4g dGhpcyBkb2N1bWVudCBhcmUgdG8NCiAgIGJlIHVzZWQgaW4gZXZhbHVhdGluZy4uLiBwcm90b2Nv bCBzdWJtaXNzaW9ucy4gIEFzIHN1Y2gsIHRoZQ0KICAgcmVxdWlyZW1lbnRzIGxhbmd1YWdlIHJl ZmVycyB0byBjYXBhYmlsaXRpZXMgb2YgdGhlc2UgcHJvdG9jb2xzOyB0aGUNCiAgIHByb3RvY29s IGRvY3VtZW50cyB3aWxsIHNwZWNpZnkgd2hldGhlciB0aGVzZSBmZWF0dXJlcyBhcmUgcmVxdWly ZWQsDQogICByZWNvbW1lbmRlZCwgb3Igb3B0aW9uYWwuICBGb3IgZXhhbXBsZSwgcmVxdWlyaW5n IHRoYXQgYSBwcm90b2NvbA0KICAgc3VwcG9ydCBjb25maWRlbnRpYWxpdHkgaXMgTk9UIHRoZSBz YW1lIHRoaW5nIGFzIHJlcXVpcmluZyB0aGF0IGFsbA0KICAgcHJvdG9jb2wgdHJhZmZpYyBiZSBl bmNyeXB0ZWQuDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi --_752F428E-3C73-44EC-9B21-895C597B5F9C_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGhlYWQ+PHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+CnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGggewptYXJn aW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1s ZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKfQoKcC5Nc29MaXN0UGFyYWdyYXBoQ3hT cEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBhcmFncmFw aEN4U3BGaXJzdCwgcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFn cmFwaEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGhDeFNwTGFzdCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwpt YXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0 OwpsaW5lLWhlaWdodDoxMTUlOwp9Cjwvc3R5bGU+PHN0eWxlPjwhLS0KLmhtbWVzc2FnZSBwIHsK bWFyZ2luOjBweDsKcGFkZGluZzowcHg7Cn0KCmJvZHkuaG1tZXNzYWdlIHsKZm9udC1mYW1pbHk6 Q2FsaWJyaTsKZm9udC1zaXplOjEycHQ7Cn0KLS0+PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRpdiBk YXRhLWV4dGVybmFsc3R5bGU9ImZhbHNlIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2Vn b2UgVUknLE1laXJ5bywnTWljcm9zb2Z0IFlhSGVpIFVJJywnTWljcm9zb2Z0IEpoZW5nSGVpIFVJ JywnTWFsZ3VuIEdvdGhpYycsJ0tobWVyIFVJJywnTmlybWFsYSBVSScsVHVuZ2EsJ0xhbyBVSScs RWJyaW1hLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE2cHg7Ij48ZGl2PkkgY2Fubm90IGZpbmQgYW4g UkZDIHRoYXQgZGVhbHMgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gcmVxdWlyZW1lbnRzIGRv Y3VtZW50cyBzcGVjaWZpY2FsbHkuIFBhcnQgb2YgdGhlIHJlYXNvbiBmb3IgdGhhdCBtYXkgYmUg dGhhdCByZXF1aXJlbWVudHMgZG9jdW1lbnRzIGFyZSBieSBubyBtZWFucyB1bmlmb3JtLiZuYnNw OyBTb21lIGFyZSBjcmVhdGVkIHRvIGFzc2lzdCBpbiBtYWtpbmcgYSBzZWxlY3Rpb24gYmV0d2Vl biBjb21wZXRpbmcgcHJvdG9jb2xzLiZuYnNwOyBTb21lIGFyZSBqdXN0IGNyZWF0ZWQgdG8gaW5m b3JtIHN1YnNlcXVlbnQgV0cgcHJvdG9jb2wgZGVzaWduIGVmZm9ydHMuJm5ic3A7IFNvbWV0aW1l cyB0aGUgZXZlbnR1YWwgb3V0cHV0IGlzIGV2YWx1YXRlZCBhZ2FpbnN0IHRoZSByZXF1aXJlbWVu dHMsIHNvbWV0aW1lcyBub3QuJm5ic3A7IFdpdGggc3VjaCBhIGxldmVsIG9mIHZhcmlhdGlvbiwg aXQgaXMgbm90IGNsZWFyIG1lIHRoYXQmbmJzcDvigJxvbmUgc2l6ZSBmaXRzIGFsbOKAnS4mbmJz cDsgPC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1 ZSI+T3ZlcmFsbCwgSeKAmWQgc2F5IGl0IGlzIHVwIHRvIElFVEYgUlRDV0VCIChhbmQgVzNDIFdF QlJUQykmbmJzcDt0byBkZWNpZGUgaG93IGl0IHdhbnRzIHRoZSByZXF1aXJlbWVudHMgZG9jdW1l bnQgdG8gYmUgdXNlZCwgYW5kIHRoaXMgaW4gdHVybiB3aWxsIGluZmx1ZW5jZSB3aGF0IHRoZSBu b3JtYXRpdmUgbGFuZ3VhZ2Ugd2lsbCBtZWFuLiZuYnNwOyBKdWRnaW5nIGJ5IHRoZSBudW1iZXIg b2YgaXNzdWVzIHdlIGhhdmUgaGFkIHdpdGggcmVxdWlyZW1lbnRzIGRvY3VtZW50cyBpbiB0aGUg cGFzdCAoZS5nLiB0eXBpY2FsbHkgdGhlIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHByb2JsZW0gZXZv bHZlcyBjb25zaWRlcmFibHkgb3ZlciB0aW1lIGFuZCBvZnRlbiBpbml0aWFsbHkgc3BlY2lmaWVk IHJlcXVpcmVtZW50cyBhcmUmbmJzcDvigJxvdmVydGFrZW4gYnkgZXZlbnRz4oCdKSwgd2Ugc2hv dWxkIGJlIGNhcmVmdWwgYWJvdXQgc2V0dGluZyBleHBlY3RhdGlvbnMgdG9vIGhpZ2guIDwvZGl2 PjxkaXY+Jm5ic3A7PC9kaXY+CTxkaXYgc3R5bGU9ImJvcmRlci10b3AtY29sb3I6IHJnYigyMjUs IDIyNSwgMjI1KTsgYm9yZGVyLXRvcC13aWR0aDogMXB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xp ZDsiPgkJPHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiZuYnNwO0hhcmFsZCBBbHZlc3RyYW5kPGJyPgkJ PHN0cm9uZz5TZW50Ojwvc3Ryb25nPiZuYnNwO+KAjkphbnVhcnnigI4g4oCOMzDigI4sIOKAjjIw MTMg4oCOMuKAjjrigI4wMuKAjiDigI5BTTxicj4JCTxzdHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7 cnRjd2ViQGlldGYub3JnPGJyPgkJPHN0cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiZuYnNwO1tydGN3 ZWJdIDIxMTkgbGFuZ3VhZ2UgaW4gcmVxdWlyZW1lbnRzIChSZTogUmV2aWV3IG9mIGRyYWZ0LWll dGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTEwIChQYXJ0IEkpKTxicj4JPC9k aXY+CTxkaXY+Jm5ic3A7PC9kaXY+CiAgCiAgICAKICAKICAKICAgIDxkaXYgY2xhc3M9IiBtb3ot Y2l0ZS1wcmVmaXgiPkJlcm5hcmQsIHdpdGggeW91ciBJQUIgaGF0IG9uIC0gZGlkbid0CiAgICAg IHdlIGRvIGEgZG9jdW1lbnQgZGVzY3JpYmluZyBob3cgdG8gZG8gMjExOSBsYW5ndWFnZSBpbgog ICAgICByZXF1aXJlbWVudHMgYXQgb25lIHRpbWU/PGJyPgogICAgICAoU2luY2UgdGhlIHdvcmQg InJlcXVpcmVtZW50cyIgb2NjdXJzIHNvIG9mdGVuIGluIDIxMTkgaXRzZWxmLAogICAgICBpdCdz IGhhcmQgdG8gZ29vZ2xlIGZvciBpdCk8YnI+CiAgICAgIDxicj4KICAgICAgRmFpbGluZyB0aGF0 LCBJIHN1cHBvcnQgYWRhcHRpbmcgdGhlIGxhbmd1YWdlIG9mIFJGQyAyOTI4IChuZWVkcwogICAg ICBhZGFwdGluZywgYmVjYXVzZSB3ZSdyZSBleHBlY3RpbmcgdG8gZGV2ZWxvcCBhIHNpbmdsZQog ICAgICBzcGVjaWZpY2F0aW9uIHN1aXRlIHJhdGhlciB0aGFuIGV2YWx1YXRpbmcgbXVsdGlwbGUg c3VibWlzc2lvbnMpCiAgICAgIGFuZCBpbnNlcnRpbmcgaXQgaGVyZS48YnI+CiAgICAgIDxicj4K ICAgICAgPGJyPgogICAgICBPbiAwMS8yOS8yMDEzIDExOjM2IFBNLCBCZXJuYXJkIEFib2JhIHdy b3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkJMVTAwMi1XMTcw NURDNTQwMDYxMzFCNTVCNDMyQTkzMUYwQHBoeC5nYmwiPgogICAgICAKICAgICAgPGRpdiBkaXI9 Imx0ciI+SSBoYXZlIGEgdmVyeSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBhYm91dCB0aGlzCiAgICAg ICAgZG9jdW1lbnQ6PGJyPgogICAgICAgIDxicj4KICAgICAgICBXaGF0IGFyZSB0aGUgQnJvd3Nl ciBhbmQgQVBJIHJlcXVpcmVtZW50cyBnb2luZyB0byBiZSB1c2VkIGZvcj8KICAgICAgICA8YnI+ CiAgICAgICAgPGJyPgogICAgICAgIElzIHRoZSBnb2FsIHRvIGRvY3VtZW50IHRoaW5ncyB3ZSB0 aG91Z2h0IG1pZ2h0IGhhdmUgYmVlbiBuaWNlCiAgICAgICAgYXQgdGhlIHRpbWU/PGJyPgogICAg ICAgIDxicj4KICAgICAgICBJbiBtYW55IGNhc2VzLCB0aGUgcmVxdWlyZW1lbnRzIGFyZSB0b28g dmFndWUgdG8gZWFzaWx5CiAgICAgICAgZGV0ZXJtaW5lIHdoZXRoZXIgc3Vic2VxdWVudCBJRVRG PGJyPgogICAgICAgIHByb3RvY29sIHByb2ZpbGVzIG9yIFczQyBBUEkgZG9jdW1lbnRzIGFjdHVh bGx5IHNhdGlzZnkgdGhlCiAgICAgICAgcmVxdWlyZW1lbnRzLiZuYnNwOyBCdXQgZXZlbiBpZiB0 aGV5IHdlcmU8YnI+CiAgICAgICAgbWFkZSBtb3JlIHNwZWNpZmljLCBpcyB0aGVyZSByZWFsbHkg YW55IGludGVudCB0byBldmFsdWF0ZSBJRVRGCiAgICAgICAgYW5kIFczQyB3b3JrIGJhc2VkIG9u IHRoZXNlIHJlcXVpcmVtZW50cz88YnI+CiAgICAgICAgPGJyPgogICAgICAgIFNlY3Rpb24gMiBz dGF0ZXMgdGhhdCBub3JtYXRpdmUga2V5d29yZHMgYXJlIHRvIGJlIGludGVycHJldHRlZAogICAg ICAgIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOS48YnI+CiAgICAgICAgU2luY2UgdGhpcyBpc24n dCBhIHByb3RvY29sIHNwZWNpZmljYXRpb24sIGRvZXMgdGhhdCByZWFsbHkgbWFrZQogICAgICAg IHNlbnNlPzxicj4KICAgICAgICA8YnI+CiAgICAgICAgQXMgYW4gZXhhbXBsZSwgcmVxdWlyZW1l bnQgRjMgc3RhdGVzOjxicj4KICAgICAgICA8YnI+CiAgICAgICAgIlRyYW5zbWl0dGVkIHN0cmVh bXMgYW5kIGRhdGEgTVVTVCBiZSByYXRlIGNvbnRyb2xsZWQuIjxicj4KICAgICAgICA8YnI+CiAg ICAgICAgV2hpbGUgdGhlIHN0YXRlbWVudCBhYm92ZSBtaWdodCBtYWtlIHNvbWUgc2Vuc2UgaW4g dGhlIGNvbnRleHQKICAgICAgICBvZiB0aGUgImNpcmN1aXQgYnJlYWtlcnMiIGRvY3VtZW50LCBv cjxicj4KICAgICAgICBwZXJoYXBzIG9uZSBvZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGRvY3Vt ZW50cywgSSBkb24ndAogICAgICAgIHVuZGVyc3RhbmQgd2hhdCB0aGUgTVVTVCBtZWFucyBpbiB0 aGUgY29udGV4dCBvZjxicj4KICAgICAgICB0aGlzIGRvY3VtZW50LiA8YnI+CiAgICAgICAgPGJy PgogICAgICAgIERvZXMgaXQgbWVhbiB0aGF0IHRoZSBzcGVjaWZpY2F0aW9ucyBhcmUgcmVxdWly ZWQgdG8gZGVmaW5lIGEKICAgICAgICByYXRlIGNvbnRyb2wgZmVhdHVyZT8gPGJyPgogICAgICAg IEFzc3VtaW5nIHN1Y2ggYSBmZWF0dXJlIGlzIGRlZmluZWQsIGRvZXMgaXQgbWVhbiB0aGF0IGJy b3dzZXJzCiAgICAgICAgYXJlIHJlcXVpcmVkIHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gPGJy PgogICAgICAgIElmIGltcGxlbWVudGF0aW9uIGlzIHJlcXVpcmVkLCBpcyBpdCByZXF1aXJlZCB0 aGF0IHRoZSBmZWF0dXJlCiAgICAgICAgYmUgdXNlZD8gPGJyPgogICAgICAgIDxicj4KICAgICAg ICBQZXJzb25hbGx5LCBteSBndWVzcyBpcyB0aGF0IHRoZSBtZWFuaW5nIHByb2JhYmx5IGRvZXMg bm90CiAgICAgICAgY29ycmVzcG9uZCB0byBhbnkgb2YgdGhlIGFib3ZlLCBiZWNhdXNlIHRoaXMg PGJyPgogICAgICAgIGlzIG9ubHkgYSB1c2UgY2FzZSBkb2N1bWVudCwgbm90IGEgcHJvdG9jb2wg b3IgQVBJCiAgICAgICAgc3BlY2lmaWNhdGlvbi48YnI+CiAgICAgICAgPGJyPgogICAgICAgIEJ1 dCBpZiB0aGF0IGlzIHRydWUsIHdoeSBwb2ludCB0byB0aGUgUkZDIDIxMTkgZGVmaW5pdGlvbiBv ZgogICAgICAgIG5vcm1hdGl2ZSB0ZXJtcz8gPGJyPgogICAgICAgIDxicj4KICAgICAgICBJbiB0 aGUgcGFzdCwgYSBudW1iZXIgb2YgcmVxdWlyZW1lbnRzIGRvY3VtZW50cyBoYXZlIHRhY2tsZWQK ICAgICAgICB0aGlzIHByb2JsZW0gYnkgZXhwbGljaXRseTxicj4KICAgICAgICBzdGF0aW5nIHRo YXQgaG93IG5vcm1hdGl2ZSBsYW5ndWFnZSBpcyB0byBiZSBpbnRlcnByZXR0ZWQsCiAgICAgICAg cmF0aGVyIHRoYW4gYmxpbmRseSBpbnNlcnRpbmcgYSA8YnI+CiAgICAgICAgcmVmZXJlbmNlIHRv IFJGQyAyMTE5LiZuYnNwOyBGb3IgZXhhbXBsZSwgUkZDIDI5ODkgc3RhdGVzOjxicj4KICAgICAg ICA8YnI+CiAgICAgICAgJm5ic3A7Jm5ic3A7IFBsZWFzZSBub3RlIHRoYXQgdGhlIHJlcXVpcmVt ZW50cyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudAogICAgICAgIGFyZSB0bzxicj4KICAgICAg ICAmbmJzcDsmbmJzcDsgYmUgdXNlZCBpbiBldmFsdWF0aW5nLi4uIHByb3RvY29sIHN1Ym1pc3Np b25zLiZuYnNwOyBBcyBzdWNoLCB0aGU8YnI+CiAgICAgICAgJm5ic3A7Jm5ic3A7IHJlcXVpcmVt ZW50cyBsYW5ndWFnZSByZWZlcnMgdG8gY2FwYWJpbGl0aWVzIG9mIHRoZXNlCiAgICAgICAgcHJv dG9jb2xzOyB0aGU8YnI+CiAgICAgICAgJm5ic3A7Jm5ic3A7IHByb3RvY29sIGRvY3VtZW50cyB3 aWxsIHNwZWNpZnkgd2hldGhlciB0aGVzZSBmZWF0dXJlcyBhcmUKICAgICAgICByZXF1aXJlZCw8 YnI+CiAgICAgICAgJm5ic3A7Jm5ic3A7IHJlY29tbWVuZGVkLCBvciBvcHRpb25hbC4mbmJzcDsg Rm9yIGV4YW1wbGUsIHJlcXVpcmluZyB0aGF0IGEKICAgICAgICBwcm90b2NvbDxicj4KICAgICAg ICAmbmJzcDsmbmJzcDsgc3VwcG9ydCBjb25maWRlbnRpYWxpdHkgaXMgTk9UIHRoZSBzYW1lIHRo aW5nIGFzIHJlcXVpcmluZwogICAgICAgIHRoYXQgYWxsPGJyPgogICAgICAgICZuYnNwOyZuYnNw OyBwcm90b2NvbCB0cmFmZmljIGJlIGVuY3J5cHRlZC48YnI+CiAgICAgICAgPGJyPgogICAgICAg IDxkaXY+PGJyPgogICAgICAgIDwvZGl2PgogICAgICA8L2Rpdj4KICAgICAgPGJyPgogICAgICA8 ZmllbGRzZXQgY2xhc3M9IiBtaW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4KICAgICAg PGJyPgogICAgICA8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCnJ0Y3dlYiBtYWlsaW5nIGxpc3QKPGEgdGFiaW5kZXg9Ii0xIiBjbGFzcz0iIG1vei10 eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2Vi QGlldGYub3JnPC9hPgo8YSB0YWJpbmRleD0iLTEiIGNsYXNzPSIgbW96LXR4dC1saW5rLWZyZWV0 ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+CjwvcHJlPgog ICAgPC9ibG9ja3F1b3RlPgogICAgPGJyPgogIAoKPC9kaXY+PC9ib2R5PjwvaHRtbD4= --_752F428E-3C73-44EC-9B21-895C597B5F9C_-- From worley@shell01.TheWorld.com Fri Feb 1 14:44:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2C221E8050 for ; Fri, 1 Feb 2013 14:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvBGZrgbP5dS for ; Fri, 1 Feb 2013 14:44:09 -0800 (PST) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0870821E804E for ; Fri, 1 Feb 2013 14:44:08 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r11MhncH015679 for ; Fri, 1 Feb 2013 17:43:51 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r11Mhmc2922738 for ; Fri, 1 Feb 2013 17:43:48 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r11MhmTi1016963; Fri, 1 Feb 2013 17:43:48 -0500 (EST) Date: Fri, 1 Feb 2013 17:43:48 -0500 (EST) Message-Id: <201302012243.r11MhmTi1016963@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <510AF934.2030800@alvestrand.no> (harald@alvestrand.no) References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se> <510AF934.2030800@alvestrand.no> Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time 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: Fri, 01 Feb 2013 22:44:09 -0000 > From: Harald Alvestrand > > FWIW, I strongly object to a couple of formalities here: > [...] > - I object to requiring interworking with emergency services. Can you explain this? I suspect that you have a specific meaning, but as I read it, it sounds like "I see no objection if WebRTC does not interwork with emergency services." If WebRTC does not interwork with emergency services, the regulators will crush it. Dale From bernard_aboba@hotmail.com Fri Feb 1 15:26:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A35711E8097 for ; Fri, 1 Feb 2013 15:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.763 X-Spam-Level: X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9+ExDJMyJ+L for ; Fri, 1 Feb 2013 15:26:34 -0800 (PST) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id 8E01921F8D90 for ; Fri, 1 Feb 2013 15:26:34 -0800 (PST) Received: from BLU405-EAS214 ([65.55.116.74]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Feb 2013 15:26:33 -0800 X-EIP: [iCoJA0+Vm0y73KWncoy3JCPcd6Y/tsmO39/UpjtMtGI=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-E7F2D2F5-A8F9-4D49-9C42-42D67B9EEC7A" Content-Transfer-Encoding: 7bit References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se> <510AF934.2030800@alvestrand.no> <201302012243.r11MhmTi1016963@shell01.TheWorld.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <201302012243.r11MhmTi1016963@shell01.TheWorld.com> Date: Fri, 1 Feb 2013 15:28:26 -0800 To: "Dale R. Worley" X-OriginalArrivalTime: 01 Feb 2013 23:26:33.0691 (UTC) FILETIME=[92898AB0:01CE00D3] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Playing regulator X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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 Feb 2013 23:26:35 -0000 --Apple-Mail-E7F2D2F5-A8F9-4D49-9C42-42D67B9EEC7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With regulations in flux, it is not easy to predict the extent of the obliga= tion, beyond what exists for an "interconnected VoIP" service today. For ex= ample, we have a text to 911 proceeding ongoing as well as quite a few other= s. In order to examine what the Issues might be, Martin and I put together t= he following document: http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit Comments welcome. On Feb 1, 2013, at 14:44, "Dale R. Worley" wrote: >=20 > Can you explain this? I suspect that you have a specific meaning, but > as I read it, it sounds like "I see no objection if WebRTC does not > interwork with emergency services." If WebRTC does not interwork with > emergency services, the regulators will crush it. >=20 > Dale > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-E7F2D2F5-A8F9-4D49-9C42-42D67B9EEC7A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+V2l0aCBy ZWd1bGF0aW9ucyBpbiBmbHV4LCBpdCBpcyBub3QgZWFzeSB0byBwcmVkaWN0IHRoZSBleHRlbnQg b2YgdGhlIG9ibGlnYXRpb24sIGJleW9uZCB3aGF0IGV4aXN0cyBmb3IgYW4gImludGVyY29ubmVj dGVkIFZvSVAiIHNlcnZpY2UgdG9kYXkuICZuYnNwO0ZvciBleGFtcGxlLCB3ZSBoYXZlIGEgdGV4 dCB0byA5MTEgcHJvY2VlZGluZyBvbmdvaW5nIGFzIHdlbGwgYXMgcXVpdGUgYSBmZXcgb3RoZXJz LiBJbiBvcmRlciB0byBleGFtaW5lIHdoYXQgdGhlIElzc3VlcyBtaWdodCBiZSwgTWFydGluIGFu ZCBJIHB1dCB0b2dldGhlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50OjwvZGl2PjxkaXY+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDE5cHg7IHdoaXRlLXNwYWNlOiBu b3dyYXA7IC13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xvcjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5 Mjk2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmlsbC1jb2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3 LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEy OCwgMTgwLCAwLjIzMDQ2OSk7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogbm9uZTsgIj48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hYm9iYS1ydGN3ZWItZWNyaXQi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFib2JhLXJ0Y3dlYi1lY3JpdDwvYT48 L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdo dDogMTlweDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9y OiByZ2JhKDI2LCAyNiwgMjYsIDAuMjk2ODc1KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNv bG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1m cmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgLXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBub25lOyAiPjxicj48L3NwYW4+PC9kaXY+PGRpdj5Db21tZW50cyB3ZWxjb21l LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+T24gRmViIDEsIDIwMTMs IGF0IDE0OjQ0LCAiRGFsZSBSLiBXb3JsZXkiICZsdDs8YSBocmVmPSJtYWlsdG86d29ybGV5QGFy aWFkbmUuY29tIj53b3JsZXlAYXJpYWRuZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3Rl PjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+Q2FuIHlvdSBleHBsYWluIHRoaXM/ICZuYnNwO0kgc3Vz cGVjdCB0aGF0IHlvdSBoYXZlIGEgc3BlY2lmaWMgbWVhbmluZywgYnV0PC9zcGFuPjxicj48c3Bh bj5hcyBJIHJlYWQgaXQsIGl0IHNvdW5kcyBsaWtlICJJIHNlZSBubyBvYmplY3Rpb24gaWYgV2Vi UlRDIGRvZXMgbm90PC9zcGFuPjxicj48c3Bhbj5pbnRlcndvcmsgd2l0aCBlbWVyZ2VuY3kgc2Vy dmljZXMuIiAmbmJzcDtJZiBXZWJSVEMgZG9lcyBub3QgaW50ZXJ3b3JrIHdpdGg8L3NwYW4+PGJy PjxzcGFuPmVtZXJnZW5jeSBzZXJ2aWNlcywgdGhlIHJlZ3VsYXRvcnMgd2lsbCBjcnVzaCBpdC48 L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+RGFsZTwvc3Bhbj48YnI+PHNwYW4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxz cGFuPnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpy dGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-E7F2D2F5-A8F9-4D49-9C42-42D67B9EEC7A-- From gunnar.hellstrom@omnitor.se Fri Feb 1 15:39:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F334C1F0C4A for ; Fri, 1 Feb 2013 15:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-2.279, BAYES_00=-2.599, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MANGLED_OFF=2.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 aeuYTXgyhmU3 for ; Fri, 1 Feb 2013 15:39:45 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id A43E921F8FAA for ; Fri, 1 Feb 2013 15:39:44 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 2 Feb 2013 00:39:35 +0100 (CET) Received: from [192.168.2.42] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 7DEFE3A120 for ; Sat, 2 Feb 2013 00:39:34 +0100 (CET) Message-ID: <510C5237.4090302@omnitor.se> Date: Sat, 02 Feb 2013 00:39:35 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se> <510AF934.2030800@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000404080502000200010301" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time 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: Fri, 01 Feb 2013 23:39:47 -0000 This is a multi-part message in MIME format. --------------000404080502000200010301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Harald, You are right, the requirements on audio and video in the rtcweb use cases are not at all at the detail service quality level that F.700/F.703 are. They merely talk about good audio and good video. So, we should align the real-time text and total conversation requirements to something similar to that level, and move details to the RTT or total conversation document. It might be good to include a definition of the concepts of rea-time text and total conversation. Mentioning F.700/F.703 in a note can add further high level explanations as Barry hints. You are also right about the point about not requirig emergency service interoperability only for real-time text or total conversation. That is a general issue that should be considered and mentioned in a way so that real-time text and total conversation access to emergency services are included if emergency service access for video and audio is specified. The requirement for emergency service access was not strictly expressed. It was " Interworking with SIP calls with the same media set, and with SIP based emergency services is also in scope of this use case." I do not see "is in scope" to lead to a "shall" requirement. It rather corresponds to "should be considered". Some voices during the last call process for this document has been for more strict requirements wording. So we need to make it clear what is requirements and what is for information. I realize well that in some applications of RTCWEB, it will be obvious that there cannot be any expectation that it could be used for emergency calls, and for such situations the emergency call requirement should not be applied. It seems to be valid to try to split the requirements in direct technical requirements on rtcweb, and requirements on services made with RTCWEB. Here is an effort to revise the proposed additions. ---------------------------Proposed addition to use cases and requirements ------------------- 3. Definitions Real-time text Text transmitted instantly while it is being typed or created, so that the recipient can read the sender's text as it is written, without waiting. Total conversation An audiovisual conversation service providing bidirectional real-time transfer of motion video, real-time text and audio between users in two or more locations. Note: High level information on real-time text and total conversation can be found in ITU-T F.700 and ITU-T F.703. > 4.2.15.Simple Total Conversation service > > 4.2.15.1.Description > > This use-case has the audio and video communication of the Simple > Video Communication Service use-case (Section 4.2.1 ). > > In addition to this, the users can send and receive real-time text > in the same call. While one user types in the real-time text area, it > is nearly immediately presented to the other user. > > By providing these three media together, the Total Conversation > service is provided. > > 4.2.15.2. Derived Requirements > > F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21, > > F39,F40, F41 > > A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27 > > .............. > > F39 The browser MUST be able to handle text entry > via applications to generate real-time > text streams to be included in Total Conversation > calls. > ---------------------------------------------------------------- > F40 The browser MUST be able to send real-time text > streams to a peer. > > > ---------------------------------------------------------------- > F41 The browser MUST be able to receive, process and > convey real-time text streams from peers to > applications. > ---------------------------------------------------------------- > > > > ..... > > A27 The Web API MUST provide a mechanisms for > handling real-time text among the streams. > ....... 11.2 Informative references [ ] ITU-T Recommendation F.700 Framework Recommendation for multimedia services [ ] ITU-T Recommendation F.703 Multimedia Conversational Services ----------End of proposal-------------------------------------------------------------- /Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-02-01 14:19, Barry Dingle wrote: > Good point Harald regarding F.700 A.3.2.3 calling up "font support for > _all characters_ in ISO-10646-1". > > I suspect that the reference to F.700 was to the service and > performance requirements of a range of multimedia services. I am not > aware of another 'more suitable' set of Service Requirements document > that we can reference. F.700 (and F.703) are frequently referenced - > but some people probably quietly ignore the full implications of A.3.2.3. > > So we need to capture the 'general service requirements' but remove > any parts of F.700 (or F.703) that are not applicable. > > As the proposed additional use-case just adds RTT to the video+audio, > I suggest that we just add the (selected) RTT Requirements that suit > rtcweb to the use-case and maybe put an informational note to F.700 > and F.703. > > Cheers, > /Barry Dingle > > > > On Fri, Feb 1, 2013 at 10:07 AM, Harald Alvestrand > > wrote: > > FWIW, I strongly object to a couple of formalities here: > > - I object to making normative reference to F.700 and F.703. > - I object to requiring interworking with emergency services. > > If there's strong support in the WG for including the use case, > I'm willing to go along with that. > > (The reason for not wanting to normatively reference F.700 and > F.703 is that they're very large balls of string, and I have no > idea where the string may lead; for instance, the definition of > "Total Conversation" in section A.3.2.3 of F.700 requires font > support for all characters in ISO-10646-1; I doubt somewhat that > the person who wrote that paragraph has studied the task of > providing such font support - I found that particular linkage in a > few minutes of scanning the docs.) > > > On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote: >> 4.2.15.Simple Total Conversation service >> >> 4.2.15.1.Description >> >> This use-case has the audio and video communication of the Simple >> Video Communication Service use-case (Section 4.2.1 ). >> >> In addition to this, the users can send and receive real-time text >> in the same call. While one user types in the real-time text area, it >> is nearly immediately presented to the other user. >> >> By providing these three media together, the Total Conversation >> service is provided. >> >> Interworking with SIP calls with the same media set, and with SIP >> based emergency services is also in scope of this use case. >> >> 4.2.15.2. Derived Requirements >> >> F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21, >> >> F39,F40, F41 >> >> A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27 >> >> .............. >> >> F39 The browser MUST be able to handle text entry >> via applications to generate real-time >> text streams to be included in Total Conversation >> calls. Real-time text and Total Conversation >> Services are defined in ITU-T F.700 and F.703. >> ---------------------------------------------------------------- >> F40 The browser MUST be able to send real-time text >> streams to a peer. >> >> ---------------------------------------------------------------- >> F41 The browser MUST be able to receive, process and >> convey real-time text streams from peers to >> applications. >> ---------------------------------------------------------------- >> >> >> >> ..... >> >> A27 The Web API MUST provide a mechanisms for >> handling real-time text among the streams. >> ---------------------------------------------------------------- > > > _______________________________________________ > 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 --------------000404080502000200010301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Harald,

You are right, the requirements on audio and video in the rtcweb use cases are not at all at the detail service quality level that F.700/F.703 are.
They merely talk about good audio and good video. So, we should align the real-time text and total conversation requirements to something similar to that level, and move details to the RTT or total conversation document.


It might be good to include a definition of the concepts of rea-time text and total conversation.

Mentioning F.700/F.703 in a note can add further high level explanations as Barry hints.

You are also right about the point about not requirig emergency service interoperability only for real-time text or total conversation. That is a general issue that should be considered and mentioned in a way so that real-time text and total conversation access to emergency services are included if  emergency service access for video and audio is specified.

The requirement for emergency service access was not strictly expressed. It was "
Interworking with SIP calls with the same media set, and with SIP
   based emergency services is also in scope of this use case."

I do not see "is in scope" to lead to a "shall" requirement. It rather corresponds to "should be considered".

Some voices during the last call process for this document has been for more strict requirements wording. 
So we need to make it clear what is requirements and what is for information.

I realize well that in some applications of RTCWEB, it will be obvious that there cannot be any expectation
that it could be used for emergency calls, and for such situations the emergency call requirement should not
be applied.

It seems to be valid to try to split the requirements in direct technical requirements on rtcweb, and 
requirements on services made with RTCWEB.  


Here is an effort to revise the proposed additions.

---------------------------Proposed addition to use cases and requirements -------------------

3. Definitions

Real-time text 		Text transmitted instantly while it is being typed or created, so that the recipient 
			can read the sender's text as it is written, without waiting.  		
 
Total conversation	An audiovisual conversation service providing bidirectional real-time transfer of
			motion video, real-time text and audio between users in two or more locations.
			Note: High level information on real-time text and total conversation can be found in
			ITU-T F.700 and ITU-T F.703.
4.2.15.  Simple Total Conversation service

4.2.15.1.  Description
 
 
   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).
 
   In addition to this, the users can send and receive real-time text
   in the same call. While one user types in the real-time text area, it
   is nearly immediately presented to the other user.

   By providing these three media together, the Total Conversation
   service is provided.
 

4.2.15.2.  Derived Requirements
 
   F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,
 
   F39,F40, F41
 
   A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27
 
..............

   F39             The browser MUST be able to handle text entry
                   via applications to generate real-time 
                   text streams to be included in Total Conversation
                   calls.      
   ----------------------------------------------------------------
   F40             The browser MUST be able to send real-time text 
                   streams to a peer.
      
 
   ----------------------------------------------------------------
   F41              The browser MUST be able to receive, process and
                    convey real-time text streams from peers to 
                    applications.
   ----------------------------------------------------------------
   
 

.....

   A27             The Web API MUST provide a mechanisms for  
                   handling real-time text among the streams. 
 .......

11.2 Informative references

[ ]    ITU-T Recommendation F.700     Framework Recommendation for multimedia services 

[ ]    ITU-T Recommendation F.703    Multimedia Conversational Services 

      

      
----------End of proposal--------------------------------------------------------------

/Gunnar


      

        

        Gunnar Hellström

        Omnitor

        gunnar.hellstrom@omnitor.se

        +46708204288

      

      On 2013-02-01 14:19, Barry Dingle wrote:

    

    
Good point Harald regarding F.700 A.3.2.3 calling up
      "font support for all characters in ISO-10646-1". 

      

      I suspect that the reference to F.700 was to the service and
      performance requirements of a range of multimedia services. I am
      not aware of another 'more suitable' set of Service Requirements
      document that we can reference. F.700 (and F.703) are frequently
      referenced - but some people probably quietly ignore the full
      implications of A.3.2.3. 

      

      So we need to capture the 'general service requirements' but
      remove any parts of F.700 (or F.703) that are not applicable. 

      

      As the proposed additional use-case just adds RTT to the
      video+audio, I suggest that we just add the (selected) RTT
      Requirements that suit rtcweb to the use-case and maybe put an
      informational note to F.700 and F.703. 

      

      
Cheers,

        /Barry Dingle

        

      

      

      

      
On Fri, Feb 1, 2013 at 10:07 AM, Harald
        Alvestrand <harald@alvestrand.no>
        wrote:

        

          

            
FWIW, I strongly object to a couple of formalities
              here:

              

              - I object to making normative reference to F.700 and
              F.703.

              - I object to requiring interworking with emergency
              services.

              

              If there's strong support in the WG for including the use
              case, I'm willing to go along with that.

              

              (The reason for not wanting to normatively reference F.700
              and F.703 is that they're very large balls of string, and
              I have no idea where the string may lead; for instance,
              the definition of "Total Conversation" in section A.3.2.3
              of F.700 requires font support for all characters in
              ISO-10646-1; I doubt somewhat that the person who wrote
              that paragraph has studied the task of providing such font
              support - I found that particular linkage in a few minutes
              of scanning the docs.)
              

                


                  

                  On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote:

                

              

            

            

              

                
4.2.15.  Simple
                    Total Conversation service

                    

                    4.2.15.1.  Description

                  
                  
 

                  
   This use-case has the audio and video communication of the Simple

                  
   Video Communication Service use-case (Section 4.2.1).

                  
 

                  
   In addition to this, the users can send and receive real-time text
   in the same call. While one user types in the real-time text area, it

                  
   is nearly immediately presented to the other user.

   By providing these three media together, the Total Conversation
   service is provided.

   Interworking with SIP calls with the same media set, and with SIP
   based emergency services is also in scope of this use case. 

                  
 

                  
4.2.15.2.  Derived Requirements

                  
 

                  
   F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,

                  
 

                  
   F39,F40, F41

                  
 

                  
   A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27

                  
 


                  ..............

                  

                  
   F39             The browser MUST be able to handle text entry

                  
                   via applications to generate real-time 
                   text streams to be included in Total Conversation
                   calls. Real-time text and Total Conversation
                   Services are defined in ITU-T F.700 and F.703. 

                  
   ----------------------------------------------------------------

                  
   F40              The browser MUST be able to send real-time text 

                  
                   streams to a peer.

                  
 

                  
   ----------------------------------------------------------------

                  
   F41              The browser MUST be able to receive, process and

                  
                    convey real-time text streams from peers to 
                    applications.

                  
   ----------------------------------------------------------------

                  
   

                  
 

.....

   A27             The Web API MUST provide a mechanisms for  
                   handling real-time text among the streams. 
 ----------------------------------------------------------------


                

                

              

            

          

          

          _______________________________________________

          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


    

    

  


--------------000404080502000200010301--

From gunnar.hellstrom@omnitor.se  Fri Feb  1 16:14:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDA921E808B for ; Fri,  1 Feb 2013 16:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.018
X-Spam-Level: 
X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-0.420, 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 w9sMxS2g-MzP for ; Fri,  1 Feb 2013 16:14:31 -0800 (PST)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 675DF21E805A for ; Fri,  1 Feb 2013 16:14:30 -0800 (PST)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat,  2 Feb 2013 01:13:52 +0100 (CET)
Received: from [192.168.2.42] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 7CDC83A164 for ; Sat,  2 Feb 2013 01:13:52 +0100 (CET)
Message-ID: <510C5A40.6040600@omnitor.se>
Date: Sat, 02 Feb 2013 01:13:52 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se> <510AF934.2030800@alvestrand.no> <201302012243.r11MhmTi1016963@shell01.TheWorld.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000507090300040801030901"
Subject: Re: [rtcweb] Playing regulator
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 00:14:32 -0000

This is a multi-part message in MIME format.
--------------000507090300040801030901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

It is easy to imagine applications of WebRTC where the users will not 
have any expectation that they could use it for emergency services.
E.g. a web page only providing access to a specific company's customer 
service.
So, each application does not need to provide this access.

However, the platform has apparent ambitions to be possible to use for 
telephony like applications, with an opportunity to call by address or 
number,
E.g
4.3.1 
. 
Telephony terminal

In at least that case, there will be an expectation from users, and a 
requirement from regulators in many countries to be able to provide 
emergency service access.

So, the topic belongs here in some way.

I withdrew it from the total conversation addition, because it is a 
general function. I hope it will be possible to find a suitable place 
and general wording for it, and there indicate that it is valid for all 
media, including audio, video and real-time text.

Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-02-02 00:28, Bernard Aboba wrote:
> With regulations in flux, it is not easy to predict the extent of the 
> obligation, beyond what exists for an "interconnected VoIP" service 
> today.  For example, we have a text to 911 proceeding ongoing as well 
> as quite a few others. In order to examine what the Issues might be, 
> Martin and I put together the following document:
> http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit
>
> Comments welcome.
>
>
> On Feb 1, 2013, at 14:44, "Dale R. Worley"  > wrote:
>>>
>>
>> Can you explain this?  I suspect that you have a specific meaning, but
>> as I read it, it sounds like "I see no objection if WebRTC does not
>> interwork with emergency services."  If WebRTC does not interwork with
>> emergency services, the regulators will crush it.
>>
>> Dale
>> _______________________________________________
>> 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


--------------000507090300040801030901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
It is easy to imagine applications of
      WebRTC where the users will not have any expectation that they
      could use it for emergency services. 

      E.g. a web page only providing access to a specific company's
      customer service.

      So, each application does not need to provide this access.

      

      However, the platform has apparent ambitions to be possible to use
      for telephony like applications, with an opportunity to call by
      address or number,

      E.g  

      4.3.1.
      Telephony terminal 

      

      In at least that case, there will be an expectation from users,
      and a requirement from regulators in many countries to be able to
      provide emergency service access.

      

      So, the topic belongs here in some way.

      

      I withdrew it from the total conversation addition, because it is
      a general function. I hope it will be possible to find a suitable
      place and general wording for it, and there indicate that it is
      valid for all media, including audio, video and real-time text.

      

      Gunnar

      

        

        Gunnar Hellström

        Omnitor

        gunnar.hellstrom@omnitor.se

        +46708204288

      

      On 2013-02-02 00:28, Bernard Aboba wrote:

    

    

      
      
With regulations in flux, it is not easy to predict the
        extent of the obligation, beyond what exists for an
        "interconnected VoIP" service today.  For example, we have a
        text to 911 proceeding ongoing as well as quite a few others. In
        order to examine what the Issues might be, Martin and I put
        together the following document:

      
      


        

      
Comments welcome.

      


      

      


      

      
On Feb 1, 2013, at 14:44, "Dale R. Worley" <worley@ariadne.com>
        wrote:

      

        


        

        

        Can you explain this?  I suspect that you have a specific
          meaning, but

        as I read it, it sounds like "I see no objection if WebRTC
          does not

        interwork with emergency services."  If WebRTC does not
          interwork with

        emergency services, the regulators will crush it.

        

        Dale

        _______________________________________________

        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


    

    

  


--------------000507090300040801030901--

From bernard_aboba@hotmail.com  Fri Feb  1 16:39:02 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279E01F0CFE for ; Fri,  1 Feb 2013 16:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.421
X-Spam-Level: 
X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.177, 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 EKJ6OZhyCSfT for ; Fri,  1 Feb 2013 16:39:01 -0800 (PST)
Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 833191F0CFB for ; Fri,  1 Feb 2013 16:39:01 -0800 (PST)
Received: from BLU002-W149 ([65.55.116.73]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 1 Feb 2013 16:39:01 -0800
X-EIP: [3Kk4UlDqqDu8VSqPEjQHd9Y/sHjhldVp]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_88149b80-9ac7-4dd3-895c-e7458a7d3899_"
From: Bernard Aboba 
To: "rtcweb@ietf.org" , "harald@alvestrand.no" 
Date: Fri, 1 Feb 2013 16:39:00 -0800
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Feb 2013 00:39:01.0178 (UTC) FILETIME=[B1D769A0:01CE00DD]
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time 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, 02 Feb 2013 00:39:02 -0000

--_88149b80-9ac7-4dd3-895c-e7458a7d3899_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Harald said:
"I object to requiring interworking with emergency services."

[BA] The concrete question is "what would such a requirement consist of?" b=
eyond the use cases=20
and requirements that are already in the document.=20

Martin and I examined how WebRTC stacks up against PhoneBCP in draft-aboba-=
rtcweb-ecrit=2C=20
and the most obvious gap (location) appears to be more in the balliwick of =
IETF GEOPRIV/W3C=20
location APIs than WebRTC.=20

Lots of stuff that *might* be useful in emergency services (e.g. SIP or XMP=
P-based instant=20
messaging=2C  XMPP or data-channel based realtime text=2C video=2C etc.) lo=
oks like it could be=20
implemented in WebRTC without adding any more native functionality=2C use c=
ases or requirements. =20
Just because we don't have a use case or requirement=2C doesn't mean it can=
't be done.  For
example=2C there is no use case for "playing an imaginary xylophone with yo=
ur fingers" or=20
"projecting a stream on a spinning TV"=2C but it seems to be possible.

 		 	   		  =

--_88149b80-9ac7-4dd3-895c-e7458a7d3899_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Harald said:
"I object t=
o requiring interworking with emergency services."

[BA] The concrete=
 question is "what would such a requirement consist of?" beyond the use cas=
es 
and requirements that are already in the document. 

Martin an=
d I examined how WebRTC stacks up against PhoneBCP in draft-aboba-rtcweb-ec=
rit=2C 
and the most obvious gap (location) appears to be more in the ba=
lliwick of IETF GEOPRIV/W3C 
location APIs than WebRTC. 

Lots of =
stuff that *might* be useful in emergency services (e.g. SIP or XMPP-based =
instant 
messaging=2C  XMPP or data-channel based realtime text=2C video=
=2C etc.) looks like it could be 
implemented in WebRTC without adding a=
ny more native functionality=2C use cases or requirements.  
Just becaus=
e we don't have a use case or requirement=2C doesn't mean it can't be done.=
  For
example=2C there is no use case for "playing an imaginary xylophon=
e with your fingers" or 
"projecting a stream on a spinning TV"=2C but i=
t seems to be possible.

 		 	   		  

=

--_88149b80-9ac7-4dd3-895c-e7458a7d3899_--

From bernard_aboba@hotmail.com  Fri Feb  1 16:54:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E521421F89EF for ; Fri,  1 Feb 2013 16:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.427
X-Spam-Level: 
X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.171, 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 7Y9SV5S5A1f6 for ; Fri,  1 Feb 2013 16:54:39 -0800 (PST)
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 E89FA21F89E9 for ; Fri,  1 Feb 2013 16:54:38 -0800 (PST)
Received: from BLU002-W158 ([65.55.116.73]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 1 Feb 2013 16:54:38 -0800
X-EIP: [K85Hw0Y6rrTny/Xdg8xc3wzalqsh3th4]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_171e8956-a83e-4810-923e-aab8e89852d0_"
From: Bernard Aboba 
To: Gunnar Hellstrom , "rtcweb@ietf.org" 
Date: Fri, 1 Feb 2013 16:54:37 -0800
Importance: Normal
In-Reply-To: <510C5A40.6040600@omnitor.se>
References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se>,<51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se>, <510AF934.2030800@alvestrand.no>, <201302012243.r11MhmTi1016963@shell01.TheWorld.com>, , <510C5A40.6040600@omnitor.se>
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Feb 2013 00:54:38.0369 (UTC) FILETIME=[E0736910:01CE00DF]
Subject: Re: [rtcweb] Playing regulator
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 00:54:40 -0000

--_171e8956-a83e-4810-923e-aab8e89852d0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

While we didn't go into it in any depth in the document=2C there does seem =
to be a distinction between scenarios in which the application developer ha=
s little control over the endpoint (e.g. bring your own device)=2C versus s=
cenarios in which the application developer has some say or influence on wh=
at the capabilities of the endpoints are.

In the former case=2C the application may have to function even in a browse=
r environment where WebRTC is not available=2C whereas in the latter case=
=2C the application developer can ensure that a set of required capabilitie=
s are available.  The "telephony terminal" case seems more in the latter ca=
tegory than the former.=20

For example=2C a vendor developing a "telephony terminal" could choose the =
browser they wanted to embed in the device=2C and might even have access to=
 the browser source code=2C so as to be able to add codecs and other capabi=
lities.   In that case=2C the performance and extensibility of the code bas=
e will be an important consideration=2C since that will determine how much =
work will be involved to add capabilities and what the options are for acco=
mplishing this (e.g. native code required vs. Javascript).=20

Date: Sat=2C 2 Feb 2013 01:13:52 +0100
From: gunnar.hellstrom@omnitor.se
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Playing regulator

=0A=
  =0A=
    =0A=
  =0A=
  =0A=
    It is easy to imagine applications of=0A=
      WebRTC where the users will not have any expectation that they=0A=
      could use it for emergency services.=20
=0A=
      E.g. a web page only providing access to a specific company's=0A=
      customer service.
=0A=
      So=2C each application does not need to provide this access.
=0A=
     =20
=0A=
      However=2C the platform has apparent ambitions to be possible to use=
=0A=
      for telephony like applications=2C with an opportunity to call by=0A=
      address or number=2C
=0A=
      E.g =20
=0A=
      4.3.1.=0A=
      Telephony terminal=20
=0A=
     =20
=0A=
      In at least that case=2C there will be an expectation from users=2C=
=0A=
      and a requirement from regulators in many countries to be able to=0A=
      provide emergency service access.
=0A=
     =20
=0A=
      So=2C the topic belongs here in some way.
=0A=
     =20
=0A=
      I withdrew it from the total conversation addition=2C because it is=
=0A=
      a general function. I hope it will be possible to find a suitable=0A=
      place and general wording for it=2C and there indicate that it is=0A=
      valid for all media=2C including audio=2C video and real-time text.
=0A=
     =20
=0A=
      Gunnar
=0A=
      =0A=
        =0A=
        Gunnar Hellstr=F6m
=0A=
        Omnitor
=0A=
        gunnar.hellstrom@omnitor.se
=0A=
        +46708204288
=0A=
      =0A=
      On 2013-02-02 00:28=2C Bernard Aboba wrote:
=0A=
    =0A=
    =0A=
      =0A=
      With regulations in flux=2C it is not easy to predict the=0A=
        extent of the obligation=2C beyond what exists for an=0A=
        "interconnected VoIP" service today.  For example=2C we have a=0A=
        text to 911 proceeding ongoing as well as quite a few others. In=0A=
        order to examine what the Issues might be=2C Martin and I put=0A=
        together the following document:=0A=
      http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit=0A=
     =20
=0A=
        =0A=
      Comments welcome.=0A=
     =20
=0A=
      =0A=
     =20
=0A=
      =0A=
      On Feb 1=2C 2013=2C at 14:44=2C "Dale R. Worley" =
=0A=
        wrote:=0A=
      =0A=
       =20
=0A=
        =0A=
       =20
=0A=
        Can you explain this?  I suspect that you have a specific=0A=
          meaning=2C but
=0A=
        as I read it=2C it sounds like "I see no objection if WebRTC=0A=
          does not
=0A=
        interwork with emergency services."  If WebRTC does not=0A=
          interwork with
=0A=
        emergency services=2C the regulators will crush it.
=0A=
       =20
=0A=
        Dale
=0A=
        _______________________________________________
=0A=
        rtcweb mailing list
=0A=
        rtcweb@ietf.org
=0A=
        https://www.ietf.org/mailman/listinfo/rtcweb
=0A=
      =0A=
     =20
=0A=
      =0A=
     =20
=0A=
      _______________________________________________=0A=
rtcweb mailing list=0A=
rtcweb@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/rtcweb=0A=
=0A=
    =0A=
   =20
=0A=
  =0A=
=0A=

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

--_171e8956-a83e-4810-923e-aab8e89852d0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





While we didn't go into it in an=
y depth in the document=2C there does seem to be a distinction between scen=
arios in which the application developer has little control over the endpoi=
nt (e.g. bring your own device)=2C versus scenarios in which the applicatio=
n developer has some say or influence on what the capabilities of the endpo=
ints are.

In the former case=2C the application may have to function=
 even in a browser environment where WebRTC is not available=2C whereas in =
the latter case=2C the application developer can ensure that a set of requi=
red capabilities are available. =3B The "telephony terminal" case seems=
 more in the latter category than the former. 

For example=2C a vend=
or developing a "telephony terminal" could choose the browser they wanted t=
o embed in the device=2C and might even have access to the browser source c=
ode=2C so as to be able to add codecs and other capabilities. =3B =
=3B In that case=2C the performance and extensibility of the code base will=
 be an important consideration=2C since that will determine how much work w=
ill be involved to add capabilities and what the options are for accomplish=
ing this (e.g. native code required vs. Javascript). 

Date: Sat=2C 2 Feb 2=
013 01:13:52 +0100
From: gunnar.hellstrom@omnitor.se
To: rtcweb@ietf.=
org
Subject: Re: [rtcweb] Playing regulator

=0A=
  =0A=
    =0A=
  =0A=
  =0A=
    
It is easy to imagine applications of=
=0A=
      WebRTC where the users will not have any expectation that they=0A=
      could use it for emergency services. 
=0A=
      E.g. a web page only providing access to a specific company's=0A=
      customer service.
=0A=
      So=2C each application does not need to provide this access.
=0A=
      
=0A=
      However=2C the platform has apparent ambitions to be possible to use=
=0A=
      for telephony like applications=2C with an opportunity to call by=0A=
      address or number=2C
=0A=
      E.g =3B 
=0A=
      4.3.1.=0A=
      Telephony terminal =3B
=0A=
      
=0A=
      In at least that case=2C there will be an expectation from users=2C=
=0A=
      and a requirement from regulators in many countries to be able to=0A=
      provide emergency service access.
=0A=
      
=0A=
      So=2C the topic belongs here in some way.
=0A=
      
=0A=
      I withdrew it from the total conversation addition=2C because it is=
=0A=
      a general function. I hope it will be possible to find a suitable=0A=
      place and general wording for it=2C and there indicate that it is=0A=
      valid for all media=2C including audio=2C video and real-time text.=0A=
      
=0A=
      Gunnar
=0A=
      
=0A=
        
=0A=
        Gunnar Hellstr=F6m
=0A=
        Omnitor
=0A=
        gunnar.hellstrom@omnitor.se
=0A=
        +46708204288
=0A=
      
=0A=
      On 2013-02-02 00:28=2C Bernard Aboba wrote:
=0A=
    
=0A=
    
=0A=
      =0A=
      
With regulations in flux=2C it is not easy to predict the=0A=
        extent of the obligation=2C beyond what exists for an=0A=
        "interconnected VoIP" service today.  =3BFor example=2C we have=
 a=0A=
        text to 911 proceeding ongoing as well as quite a few others. In=0A=
        order to examine what the Issues might be=2C Martin and I put=0A=
        together the following document:
=0A=
      =0A=
      

=0A=
        
=0A=
      
Comments welcome.
=0A=
      

=0A=
      
=0A=
      

=0A=
      
=0A=
      
On Feb 1=2C 2013=2C at 14:44=2C "Dale R. Worley" <=3Bworley@ariadne.com>=3B=0A=
        wrote:
=0A=
      
=0A=
        

=0A=
        
=0A=
        
=0A=
        Can you explain this?  =3BI suspect that you have a speci=
fic=0A=
          meaning=2C but
=0A=
        as I read it=2C it sounds like "I see no objection if WebRTC=
=0A=
          does not
=0A=
        interwork with emergency services."  =3BIf WebRTC does no=
t=0A=
          interwork with
=0A=
        emergency services=2C the regulators will crush it.=0A=
        
=0A=
        Dale
=0A=
        _______________________________________________
=0A=
        rtcweb mailing list
=0A=
        rtcweb@ietf.org=

=0A=
        https://www.ietf.org/mailman/listinfo/rtcweb
=
=0A=
      
=0A=
      
=0A=
      
=0A=
      
=0A=
      
_______________________________________________=0A=
rtcweb mailing list=0A=
rt=
cweb@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/rt=
cweb=0A=

=0A=
    
=0A=
    
=0A=
  =0A=
=0A=

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

=

--_171e8956-a83e-4810-923e-aab8e89852d0_--

From richard@shockey.us  Fri Feb  1 17:23:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BD51F0CFB for ; Fri,  1 Feb 2013 17:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level: 
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU2uHIo61Tsy for ; Fri,  1 Feb 2013 17:23:10 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 16F371F0CF8 for ; Fri,  1 Feb 2013 17:23:10 -0800 (PST)
Received: (qmail 13958 invoked by uid 0); 2 Feb 2013 01:22:45 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 2 Feb 2013 01:22:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=7m5/pQw2LytCFgx+1CJLcROqBRjGKh9Uw1TiEk2PrxU=;  b=aECUi6MorcrvwIOqzeGw/GZ68S9ujQk2YYZDrWLszV9XuijKAKxbSyF6dHXPGc37mtsLtO9C5T1OBVHV+rOADiVyo6w+N3R7fcxWKSa3zK3/Z8HDoq131ALdzQT9kET3;
Received: from [72.66.111.101] (port=53015 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1U1Rob-0007C6-1t for rtcweb@ietf.org; Fri, 01 Feb 2013 18:22:45 -0700
From: "Richard Shockey" 
To: 
References: <50F97303.4070906@ericsson.com>	<5102FE7E.5000109@omnitor.se>, <51039976.1000600@alvestrand.no>	<51098D5A.4040009@omnitor.se>, <510AF934.2030800@alvestrand.no>, <201302012243.r11MhmTi1016963@shell01.TheWorld.com>, , <510C5A40.6040600@omnitor.se> 
In-Reply-To: 
Date: Fri, 1 Feb 2013 20:22:41 -0500
Message-ID: <000001ce00e3$cca366c0$65ea3440$@us>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CE00B9.E3CD5EC0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4A3+KdjVugvd1gSc2ZFTOqJdpt0AAA0O/A
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.101 authed with richard@shockey.us}
Subject: Re: [rtcweb] Playing regulator
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 01:23:11 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01CE00B9.E3CD5EC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

=20

http://transition.fcc.gov/cgb/dro/cvaa.html

=20

I hope you enjoy being amateur telecom lawyers.  Some of us are getting
pretty good at it.=20

=20

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of
Bernard Aboba
Sent: Friday, February 01, 2013 7:55 PM
To: Gunnar Hellstrom; rtcweb@ietf.org
Subject: Re: [rtcweb] Playing regulator

=20

While we didn't go into it in any depth in the document, there does seem =
to
be a distinction between scenarios in which the application developer =
has
little control over the endpoint (e.g. bring your own device), versus
scenarios in which the application developer has some say or influence =
on
what the capabilities of the endpoints are.

In the former case, the application may have to function even in a =
browser
environment where WebRTC is not available, whereas in the latter case, =
the
application developer can ensure that a set of required capabilities are
available.  The "telephony terminal" case seems more in the latter =
category
than the former.=20

For example, a vendor developing a "telephony terminal" could choose the
browser they wanted to embed in the device, and might even have access =
to
the browser source code, so as to be able to add codecs and other
capabilities.   In that case, the performance and extensibility of the =
code
base will be an important consideration, since that will determine how =
much
work will be involved to add capabilities and what the options are for
accomplishing this (e.g. native code required vs. Javascript).=20

  _____ =20

Date: Sat, 2 Feb 2013 01:13:52 +0100
From: gunnar.hellstrom@omnitor.se
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Playing regulator

It is easy to imagine applications of WebRTC where the users will not =
have
any expectation that they could use it for emergency services.=20
E.g. a web page only providing access to a specific company's customer
service.
So, each application does not need to provide this access.

However, the platform has apparent ambitions to be possible to use for
telephony like applications, with an opportunity to call by address or
number,
E.g =20
=20
 4.3.1. Telephony terminal=20

In at least that case, there will be an expectation from users, and a
requirement from regulators in many countries to be able to provide
emergency service access.

So, the topic belongs here in some way.

I withdrew it from the total conversation addition, because it is a =
general
function. I hope it will be possible to find a suitable place and =
general
wording for it, and there indicate that it is valid for all media, =
including
audio, video and real-time text.

Gunnar

  _____ =20

Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288

On 2013-02-02 00:28, Bernard Aboba wrote:

With regulations in flux, it is not easy to predict the extent of the
obligation, beyond what exists for an "interconnected VoIP" service =
today.
For example, we have a text to 911 proceeding ongoing as well as quite a =
few
others. In order to examine what the Issues might be, Martin and I put
together the following document:

http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit

=20

Comments welcome.

=20

=20

On Feb 1, 2013, at 14:44, "Dale R. Worley"  wrote:

=20


Can you explain this?  I suspect that you have a specific meaning, but
as I read it, it sounds like "I see no objection if WebRTC does not
interwork with emergency services."  If WebRTC does not interwork with
emergency services, the regulators will crush it.

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





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



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


------=_NextPart_000_0001_01CE00B9.E3CD5EC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


+1
 
http://transition.fc=
c.gov/cgb/dro/cvaa.html
 
I hope you enjoy being amateur telecom lawyers.=A0 Some of us are =
getting pretty good at it. 
 
From:=
 =
rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of =
Bernard Aboba
Sent: Friday, February 01, 2013 7:55 =
PM
To: Gunnar Hellstrom; rtcweb@ietf.org
Subject: =
Re: [rtcweb] Playing regulator
 
While we didn't go into it =
in any depth in the document, there does seem to be a distinction =
between scenarios in which the application developer has little control =
over the endpoint (e.g. bring your own device), versus scenarios in =
which the application developer has some say or influence on what the =
capabilities of the endpoints are.

In the former case, the =
application may have to function even in a browser environment where =
WebRTC is not available, whereas in the latter case, the application =
developer can ensure that a set of required capabilities are =
available.  The "telephony terminal" case seems more in =
the latter category than the former. 

For example, a vendor =
developing a "telephony terminal" could choose the browser =
they wanted to embed in the device, and might even have access to the =
browser source code, so as to be able to add codecs and other =
capabilities.   In that case, the performance and =
extensibility of the code base will be an important consideration, since =
that will determine how much work will be involved to add capabilities =
and what the options are for accomplishing this (e.g. native code =
required vs. Javascript). 
Date: Sat, 2 Feb 2013 =
01:13:52 +0100
From: gunnar.hellstrom@omnitor.se
To: rtcweb@ietf.org
Subject: Re: =
[rtcweb] Playing regulator
It =
is easy to imagine applications of WebRTC where the users will not have =
any expectation that they could use it for emergency services. 
E.g. =
a web page only providing access to a specific company's customer =
service.
So, each application does not need to provide this =
access.

However, the platform has apparent ambitions to be =
possible to use for telephony like applications, with an opportunity to =
call by address or number,
E.g  
4.3.1. Telephony =
terminal 

In at least that case, there will be an =
expectation from users, and a requirement from regulators in many =
countries to be able to provide emergency service access.

So, the =
topic belongs here in some way.

I withdrew it from the total =
conversation addition, because it is a general function. I hope it will =
be possible to find a suitable place and general wording for it, and =
there indicate that it is valid for all media, including audio, video =
and real-time text.

Gunnar
Gunnar =
Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-02-02 00:28, =
Bernard Aboba wrote:
=

 
=

Comments =
welcome.
 
=

 
=

On Feb 1, 2013, at 14:44, =
"Dale R. Worley" <worley@ariadne.com> =
wrote:
 
=


Can you explain this? =
 I suspect that you have a specific meaning, but
as I read it, =
it sounds like "I see no objection if WebRTC does not
interwork =
with emergency services."  If WebRTC does not interwork =
with
emergency services, the regulators will crush =
it.

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


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


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

------=_NextPart_000_0001_01CE00B9.E3CD5EC0--


From harald@alvestrand.no  Sat Feb  2 02:31:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1309221F907C for ; Sat,  2 Feb 2013 02:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.424
X-Spam-Level: 
X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+Wnc7LKRj9M for ; Sat,  2 Feb 2013 02:31:29 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1AE21F907A for ; Sat,  2 Feb 2013 02:31:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5E4339E140 for ; Sat,  2 Feb 2013 11:31:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL0St-E2MPH8 for ; Sat,  2 Feb 2013 11:31:26 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:ed70:e47d:914f:d71e] (unknown [IPv6:2001:470:de0a:27:ed70:e47d:914f:d71e]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D05F539E04C for ; Sat,  2 Feb 2013 11:31:25 +0100 (CET)
Message-ID: <510CEAF9.6020509@alvestrand.no>
Date: Sat, 02 Feb 2013 11:31:21 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com>
In-Reply-To: <510BB070.9040602@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 10:31:30 -0000

On 02/01/2013 01:09 PM, Stefan Håkansson LK wrote:
> On 2013-02-01 11:58, Harald Alvestrand wrote:
>> On 02/01/2013 11:34 AM, Stefan Håkansson LK wrote:
>>>>
>>>>     A25             It must be possible for the application to
>>>>                     refrain from exposing the IP address
>>>>
>>>> [BA] I am assuming we are talking about exposing the originating IP
>>>> address of media, which can be addressed via TURN.
>>>> If so, this is more of a protocol than an API requirement. Since the
>>>> ICE candidates need to exposed in the API in
>>>> order to allow them to be signaled, I am not sure how we can avoid
>>>> exposing those to the application.  Similarly, the
>>>> HTTP server can obtain the IP address used by the HTTP client. Even
>>>> within SIP, there are VIA headers and contact
>>>> headers, so it is not easy to avoid disclosure of the IP address to
>>>> everyone.  So I think we need to be more clear
>>>> about what we are trying to avoid exposing, and to whom.
>>>
>>> Personally I would like to get rid of this requirement. The
>>> application can always get all candidates. To have a way to let the
>>> application ask for _only_ the TURN candidates does not change this -
>>> that kind of API is more for convenience (so that the app you trust
>>> does not have to remove privacy revealing candidates from the offer,
>>> but can instead ask the browser to deliver an offer without them).
>> I think this requirement is important, but needs reformulation.
>>
>> Should we instead say
>>
>> "It MUST be possible to set up a call between two parties A and B
>> without one party learning the other party's IP address"
>
> This requirement is not on the browser (or its APIs) per se, if we go 
> this path it almost belongs into another category than what we 
> currently have.

I think it is, actually - the A browser has to be able to send media to 
B without sending IP packets to B, which means that it has to use an 
intermediary, and force B to use an intermediary too. TURN does that, we 
could imagine other solutions (the people who made Tor could probably 
think of many more schemes).

The API requirement is that the application should be able to request 
that functionality.


From stefan.lk.hakansson@ericsson.com  Sat Feb  2 04:56:55 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7621F9069 for ; Sat,  2 Feb 2013 04:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.916
X-Spam-Level: 
X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cjm+ehufCZpp for ; Sat,  2 Feb 2013 04:56:55 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECA121F900E for ; Sat,  2 Feb 2013 04:56:54 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-a9-510d0d153d84
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9F.42.32353.51D0D015; Sat,  2 Feb 2013 13:56:53 +0100 (CET)
Received: from [153.88.52.47] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Sat, 2 Feb 2013 13:56:53 +0100
Message-ID: <510D0D14.4050301@ericsson.com>
Date: Sat, 2 Feb 2013 13:56:52 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no>
In-Reply-To: <510CEAF9.6020509@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvra4oL2+gwfEeWYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fnuZqaCJeIVBzadYG1gnCLUxcjJISFgIrFrwXUWCFtM4sK9 9WxdjFwcQgInGSX2tc9jgnBWMkp8e3WQHaSKV0BbYseuHlYQm0VAReLe924mEJtNIFDi+v9f YLaoQJTE+6tNzBD1ghInZz4B2yAiICyx9VUvUA0Hh7BAhcSaVkeI+SuYJTa3zgKr5xTQldi+ 8TYbiM0sYCtxYQ7EdcwC8hLNW2eD1QgB1bx7fY91AqPALCQrZiFpmYWkZQEj8ypG9tzEzJz0 cvNNjMBAO7jlt8EOxk33xQ4xSnOwKInzhrteCBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA uL99aQFPreVE5hKRT58C9rzVl+yfWnOi89A/xbBdMeEWHaeeT/yappXwo0Yv+Xwvp+Cfpw+E ea+5FhZHizMVKZz/9Pnu/ctpQQ+erVVUrdTpMjEyKlhcY+91em5n6uzOv4zqUZYyfmsSViVX SpY4d0ooBOy08/3xRUTxnw3TYcHtztN/LvusxFKckWioxVxUnAgAur5ZkgICAAA=
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 12:56:55 -0000

On 2013-02-02 11:31, Harald Alvestrand wrote:
> On 02/01/2013 01:09 PM, Stefan Håkansson LK wrote:
>> On 2013-02-01 11:58, Harald Alvestrand wrote:
>>> On 02/01/2013 11:34 AM, Stefan Håkansson LK wrote:
>>>>>
>>>>>     A25             It must be possible for the application to
>>>>>                     refrain from exposing the IP address
>>>>>
>>>>> [BA] I am assuming we are talking about exposing the originating IP
>>>>> address of media, which can be addressed via TURN.
>>>>> If so, this is more of a protocol than an API requirement. Since the
>>>>> ICE candidates need to exposed in the API in
>>>>> order to allow them to be signaled, I am not sure how we can avoid
>>>>> exposing those to the application.  Similarly, the
>>>>> HTTP server can obtain the IP address used by the HTTP client. Even
>>>>> within SIP, there are VIA headers and contact
>>>>> headers, so it is not easy to avoid disclosure of the IP address to
>>>>> everyone.  So I think we need to be more clear
>>>>> about what we are trying to avoid exposing, and to whom.
>>>>
>>>> Personally I would like to get rid of this requirement. The
>>>> application can always get all candidates. To have a way to let the
>>>> application ask for _only_ the TURN candidates does not change this -
>>>> that kind of API is more for convenience (so that the app you trust
>>>> does not have to remove privacy revealing candidates from the offer,
>>>> but can instead ask the browser to deliver an offer without them).
>>> I think this requirement is important, but needs reformulation.
>>>
>>> Should we instead say
>>>
>>> "It MUST be possible to set up a call between two parties A and B
>>> without one party learning the other party's IP address"
>>
>> This requirement is not on the browser (or its APIs) per se, if we go
>> this path it almost belongs into another category than what we
>> currently have.
>
> I think it is, actually - the A browser has to be able to send media to
> B without sending IP packets to B, which means that it has to use an
> intermediary, and force B to use an intermediary too. TURN does that, we
> could imagine other solutions (the people who made Tor could probably
> think of many more schemes).

OK. Here is a shot at it:

Fnn: The browser MUST be able to send streams and                   data 
to a peer in such a fashion that the peer is not (e.g. by inspection of 
packets belonging to the streams or data or any associated signaling 
messages) able to find out the xxxxx IP address used by the browser

There has been some discussion of xxxxx; is it needed, and if so, what 
should it say? "host"? "local"?



>
> The API requirement is that the application should be able to request
> that functionality.

Yes, that is simple if we could get Fnn done...

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


From harald@alvestrand.no  Sat Feb  2 10:51:43 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7FC21F8540 for ; Sat,  2 Feb 2013 10:51:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.176
X-Spam-Level: 
X-Spam-Status: No, score=-110.176 tagged_above=-999 required=5 tests=[AWL=0.123, 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 qj7u91AKy1Xe for ; Sat,  2 Feb 2013 10:51:42 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E78DF21F853E for ; Sat,  2 Feb 2013 10:51:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B259A39E140; Sat,  2 Feb 2013 19:51:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqfIFcFhaO69; Sat,  2 Feb 2013 19:51:38 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1] (unknown [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6C08B39E070; Sat,  2 Feb 2013 19:51:38 +0100 (CET)
Message-ID: <510D6039.3060501@alvestrand.no>
Date: Sat, 02 Feb 2013 19:51:37 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com>
In-Reply-To: <510D0D14.4050301@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 18:51:43 -0000

On 02/02/2013 01:56 PM, Stefan Håkansson LK wrote:
> On 2013-02-02 11:31, Harald Alvestrand wrote:
>> On 02/01/2013 01:09 PM, Stefan Håkansson LK wrote:
>>> On 2013-02-01 11:58, Harald Alvestrand wrote:
>>>> On 02/01/2013 11:34 AM, Stefan Håkansson LK wrote:
>>>>>>
>>>>>>     A25             It must be possible for the application to
>>>>>>                     refrain from exposing the IP address
>>>>>>
>>>>>> [BA] I am assuming we are talking about exposing the originating IP
>>>>>> address of media, which can be addressed via TURN.
>>>>>> If so, this is more of a protocol than an API requirement. Since the
>>>>>> ICE candidates need to exposed in the API in
>>>>>> order to allow them to be signaled, I am not sure how we can avoid
>>>>>> exposing those to the application.  Similarly, the
>>>>>> HTTP server can obtain the IP address used by the HTTP client. Even
>>>>>> within SIP, there are VIA headers and contact
>>>>>> headers, so it is not easy to avoid disclosure of the IP address to
>>>>>> everyone.  So I think we need to be more clear
>>>>>> about what we are trying to avoid exposing, and to whom.
>>>>>
>>>>> Personally I would like to get rid of this requirement. The
>>>>> application can always get all candidates. To have a way to let the
>>>>> application ask for _only_ the TURN candidates does not change this -
>>>>> that kind of API is more for convenience (so that the app you trust
>>>>> does not have to remove privacy revealing candidates from the offer,
>>>>> but can instead ask the browser to deliver an offer without them).
>>>> I think this requirement is important, but needs reformulation.
>>>>
>>>> Should we instead say
>>>>
>>>> "It MUST be possible to set up a call between two parties A and B
>>>> without one party learning the other party's IP address"
>>>
>>> This requirement is not on the browser (or its APIs) per se, if we go
>>> this path it almost belongs into another category than what we
>>> currently have.
>>
>> I think it is, actually - the A browser has to be able to send media to
>> B without sending IP packets to B, which means that it has to use an
>> intermediary, and force B to use an intermediary too. TURN does that, we
>> could imagine other solutions (the people who made Tor could probably
>> think of many more schemes).
>
> OK. Here is a shot at it:
>
> Fnn: The browser MUST be able to send streams and                   
> data to a peer in such a fashion that the peer is not (e.g. by 
> inspection of packets belonging to the streams or data or any 
> associated signaling messages) able to find out the xxxxx IP address 
> used by the browser
>
> There has been some discussion of xxxxx; is it needed, and if so, what 
> should it say? "host"? "local"?

The security property that has most often been expressed is that the 
correspondent should not be able to use the IP address to geolocate the 
user; this means that the most important value of "xxxx" is the globally 
routable IP address that is closest to the user's location.

Some have also mentioned the need to hide local (RFC 1918) IP addresses 
in order to prevent mapping of the user's internal network; I think this 
is usually seen as a less dramatic threat.


>
>
>
>>
>> The API requirement is that the application should be able to request
>> that functionality.
>
> Yes, that is simple if we could get Fnn done...
>
>>
>> _______________________________________________
>> 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 ekr@rtfm.com  Sat Feb  2 12:49:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0821F8599 for ; Sat,  2 Feb 2013 12:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8f4K5izy4Mc for ; Sat,  2 Feb 2013 12:49:37 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD7E21F8584 for ; Sat,  2 Feb 2013 12:49:37 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id o6so5320578oag.4 for ; Sat, 02 Feb 2013 12:49:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=fDW0OQpf7ZGqrsgiqrcHgDkWRKSHpriori3svKuERWE=; b=Ens8CMTh4MO5eXTXNIOgT61OKktOR5+xwsbnCrlx78CMNLR1ZrW6k2Tya2Vy2WyRUt igMlivOvBGSTcd5akyuC7RSQjLw6knAlE+j7FKUkbCcRd1KtfNpHiOCP4hMdWa27k7Yn SDic8aWXa0wsG1AlYZ1MCJa3fHff5nSbOBUtUxPXMj6h17EL/IZafFloZuNYaHS1DEVD PyKyGdccOCjjKPbEqtx93G16k4C+nrQh2tHT0LnZqCuu8efLz6RMleAzwkzjDHVi0L8N bbT9mA+8dE/kdiTi4/WdDad4WjFR7r5BpVADqvvWla20g3K1amU0UK/hiqI0e7qHSov6 QyCw==
X-Received: by 10.182.156.44 with SMTP id wb12mr12055866obb.20.1359838177087;  Sat, 02 Feb 2013 12:49:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.3.106 with HTTP; Sat, 2 Feb 2013 12:48:57 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <510D6039.3060501@alvestrand.no>
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>
From: Eric Rescorla 
Date: Sat, 2 Feb 2013 12:48:57 -0800
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=f46d0444ed377f4fe604d4c3ff6e
X-Gm-Message-State: ALoCoQkA6EqJEtrz2H0KoW74hY1a1d7vVyMepIos5Srq7H77fuSIEIkQy8LGdpPxhc3Y6j/v0dQ3
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:49:38 -0000

--f46d0444ed377f4fe604d4c3ff6e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 2, 2013 at 10:51 AM, Harald Alvestrand wr=
ote:

> On 02/02/2013 01:56 PM, Stefan H=E5kansson LK wrote:
>
>> On 2013-02-02 11:31, Harald Alvestrand wrote:
>>
>>> On 02/01/2013 01:09 PM, Stefan H=E5kansson LK wrote:
>>>
>>>> On 2013-02-01 11:58, Harald Alvestrand wrote:
>>>>
>>>>> On 02/01/2013 11:34 AM, Stefan H=E5kansson LK wrote:
>>>>>
>>>>>>
>>>>>>>     A25             It must be possible for the application to
>>>>>>>                     refrain from exposing the IP address
>>>>>>>
>>>>>>> [BA] I am assuming we are talking about exposing the originating IP
>>>>>>> address of media, which can be addressed via TURN.
>>>>>>> If so, this is more of a protocol than an API requirement. Since th=
e
>>>>>>> ICE candidates need to exposed in the API in
>>>>>>> order to allow them to be signaled, I am not sure how we can avoid
>>>>>>> exposing those to the application.  Similarly, the
>>>>>>> HTTP server can obtain the IP address used by the HTTP client. Even
>>>>>>> within SIP, there are VIA headers and contact
>>>>>>> headers, so it is not easy to avoid disclosure of the IP address to
>>>>>>> everyone.  So I think we need to be more clear
>>>>>>> about what we are trying to avoid exposing, and to whom.
>>>>>>>
>>>>>>
>>>>>> Personally I would like to get rid of this requirement. The
>>>>>> application can always get all candidates. To have a way to let the
>>>>>> application ask for _only_ the TURN candidates does not change this =
-
>>>>>> that kind of API is more for convenience (so that the app you trust
>>>>>> does not have to remove privacy revealing candidates from the offer,
>>>>>> but can instead ask the browser to deliver an offer without them).
>>>>>>
>>>>> I think this requirement is important, but needs reformulation.
>>>>>
>>>>> Should we instead say
>>>>>
>>>>> "It MUST be possible to set up a call between two parties A and B
>>>>> without one party learning the other party's IP address"
>>>>>
>>>>
>>>> This requirement is not on the browser (or its APIs) per se, if we go
>>>> this path it almost belongs into another category than what we
>>>> currently have.
>>>>
>>>
>>> I think it is, actually - the A browser has to be able to send media to
>>> B without sending IP packets to B, which means that it has to use an
>>> intermediary, and force B to use an intermediary too. TURN does that, w=
e
>>> could imagine other solutions (the people who made Tor could probably
>>> think of many more schemes).
>>>
>>
>> OK. Here is a shot at it:
>>
>> Fnn: The browser MUST be able to send streams and                   data
>> to a peer in such a fashion that the peer is not (e.g. by inspection of
>> packets belonging to the streams or data or any associated signaling
>> messages) able to find out the xxxxx IP address used by the browser
>>
>> There has been some discussion of xxxxx; is it needed, and if so, what
>> should it say? "host"? "local"?
>>
>
> The security property that has most often been expressed is that the
> correspondent should not be able to use the IP address to geolocate the
> user; this means that the most important value of "xxxx" is the globally
> routable IP address that is closest to the user's location.
>
> Some have also mentioned the need to hide local (RFC 1918) IP addresses i=
n
> order to prevent mapping of the user's internal network; I think this is
> usually seen as a less dramatic threat.


1. If you don't want the server learning your global IP, you need to use
Tor or the like.
2. I would suggest that it is simplest to divide the world into host
addresses, server/peer
reflexive, and relayed and say that the requirement is that the browser
must be able
to send packets without revealing either of the former two, but that it is
not a requirement
that it be able to do so in the face of an adversarial server.

Note that S 5.4 of the security arch document has some specific
requirements on
implementations phrased in terms of the technologies we have actually
chosen.

-Ekr

--f46d0444ed377f4fe604d4c3ff6e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 2, 2013 at 10:51 AM, Harald Alvestrand <harald@alvestrand.n=
o> wrote:



On 02/02/2013 01:56 PM, Stefan H=E5=
kansson LK wrote:



On 2013-02-02 11:31, Harald Alvestrand wrote:



On 02/01/2013 01:09 PM, Stefan H=E5kansson LK wrote:



On 2013-02-01 11:58, Harald Alvestrand wrote:



On 02/01/2013 11:34 AM, Stefan H=E5kansson LK wrote:





=A0 =A0 A25 =A0 =A0 =A0 =A0 =A0 =A0 It must be possible for the application=
 to

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 refrain from exposing the IP addres=
s



[BA] I am assuming we are talking about exposing the originating IP

address of media, which can be addressed via TURN.

If so, this is more of a protocol than an API requirement. Since the

ICE candidates need to exposed in the API in

order to allow them to be signaled, I am not sure how we can avoid

exposing those to the application. =A0Similarly, the

HTTP server can obtain the IP address used by the HTTP client. Even

within SIP, there are VIA headers and contact

headers, so it is not easy to avoid disclosure of the IP address to

everyone. =A0So I think we need to be more clear

about what we are trying to avoid exposing, and to whom.





Personally I would like to get rid of this requirement. The

application can always get all candidates. To have a way to let the

application ask for _only_ the TURN candidates does not change this -

that kind of API is more for convenience (so that the app you trust

does not have to remove privacy revealing candidates from the offer,

but can instead ask the browser to deliver an offer without them).



I think this requirement is important, but needs reformulation.



Should we instead say



"It MUST be possible to set up a call between two parties A and B

without one party learning the other party's IP address"





This requirement is not on the browser (or its APIs) per se, if we go

this path it almost belongs into another category than what we

currently have.





I think it is, actually - the A browser has to be able to send media to

B without sending IP packets to B, which means that it has to use an

intermediary, and force B to use an intermediary too. TURN does that, we
could imagine other solutions (the people who made Tor could probably

think of many more schemes).





OK. Here is a shot at it:



Fnn: The browser MUST be able to send streams and =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 data to a peer in such a fashion that the peer is not (e.g. by =
inspection of packets belonging to the streams or data or any associated si=
gnaling messages) able to find out the xxxxx IP address used by the browser=






There has been some discussion of xxxxx; is it needed, and if so, what shou=
ld it say? "host"? "local"?





The security property that has most often been expressed is that the corres=
pondent should not be able to use the IP address to geolocate the user; thi=
s means that the most important value of "xxxx" is the globally r=
outable IP address that is closest to the user's location.





Some have also mentioned the need to hide local (RFC 1918) IP addresses in =
order to prevent mapping of the user's internal network; I think this i=
s usually seen as a less dramatic threat.



1. If you don't want the server learning your global IP, you need to us=
e Tor or the like.
2. I would suggest that it is simplest to divi=
de the world into host addresses, server/peer
reflexive, and rela=
yed and say that the requirement is that the browser must be able



to send packets without revealing either of the former two, but that i=
t is not a requirement
that it be able to do so in the face of an=
 adversarial server.

Note that S 5.4 of the securi=
ty arch document has some specific requirements on



implementations phrased in terms of the technologies we have actually =
chosen.

-Ekr




--f46d0444ed377f4fe604d4c3ff6e--

From ted.ietf@gmail.com  Sat Feb  2 18:55:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B321F8477 for ; Sat,  2 Feb 2013 18:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU0217gb0O2d for ; Sat,  2 Feb 2013 18:55:49 -0800 (PST)
Received: from mail-ia0-x234.google.com (ia-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 61BBD21F8446 for ; Sat,  2 Feb 2013 18:55:49 -0800 (PST)
Received: by mail-ia0-f180.google.com with SMTP id f27so6793573iae.39 for ; Sat, 02 Feb 2013 18:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gaIjoJlV/klPACwWLNwgPwr6GTCNdt87bGvH1VwS8sw=; b=pPch9wQmgmrvTlxnw11oGQJN/OWmsPdQmmbMsRjNsgMVwCItjkk2KXh0kELpVjzMhb l+NbN5BI8bbdJYICaQh+P/yoqs7O9LfaX8e02/dTCx8kx5EVSd6rjuTCQwtaqEXBjnvg U8sh64AIl0LQJkySDNgRA/OcL7xw8cw0pZJw6AXxEIv6G/D5TTdYVzO4Crg/fdlNb1Kt KF2wXdxCP+B1tjv3WCZVENuEE849EtDdoB0vxWONilNGOYiJkNPdZmTJKSlTB/yGmgUf MF6rly/X0MhPxnm2EQzIfe8qdDtuvxvptrw3EStNfKwImR9Q2+ZBCVmF0Av+amBe8ZWU DHuA==
MIME-Version: 1.0
X-Received: by 10.50.187.225 with SMTP id fv1mr2235464igc.96.1359860148889; Sat, 02 Feb 2013 18:55:48 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Sat, 2 Feb 2013 18:55:48 -0800 (PST)
In-Reply-To: 
References: 
Date: Sat, 2 Feb 2013 18:55:48 -0800
Message-ID: 
From: Ted Hardie 
To: Bernard Aboba 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time 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, 03 Feb 2013 02:55:50 -0000

On Fri, Feb 1, 2013 at 4:39 PM, Bernard Aboba  wrote:
> Harald said:
>
> "I object to requiring interworking with emergency services."
>
> [BA] The concrete question is "what would such a requirement consist of?"
> beyond the use cases
> and requirements that are already in the document.
>

No, the concrete question is whether the requirement to interwork with
emergency services will constrain the design.  As you are well aware,
emergency services proceeds at a very different pace than much other
work, and imposing that constraint could be very limiting indeed.
Creating *a service* using WebRTC that connects to emergency services
is certainly feasible, because it can mimic other services that
already interwork; requiring that *all* services using WebRTC do so is
a non-starter.

Spoken as a long time watcher of ecrit, geopriv, and rtcweb, but not
as a chair or company rep, just to be clear.

regards,

Ted

From eburger@cs.georgetown.edu  Sun Feb  3 07:32:20 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D2C21F8439 for ; Sun,  3 Feb 2013 07:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8t42pRyk9Qqj for ; Sun,  3 Feb 2013 07:32:13 -0800 (PST)
Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id F2F7621F8431 for ; Sun,  3 Feb 2013 07:32:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 0F72B431BE for ; Sun,  3 Feb 2013 10:32:12 -0500 (EST)
X-Virus-Scanned: by amavisd-new at cs.georgetown.edu
Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrIln8bFXwKE for ; Sun,  3 Feb 2013 10:32:10 -0500 (EST)
Received: from [192.168.5.30] (ip-64-134-45-108.public.wayport.net [64.134.45.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 0C44D431BC for ; Sun,  3 Feb 2013 10:32:06 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Burger Eric 
In-Reply-To: 
Date: Sun, 3 Feb 2013 10:32:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no> 
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.1499)
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:32:20 -0000

Is what we are really asking for is the ability of the protocol to be =
TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in =
one particular anonymity network or another into the RTCweb protocol =
suite.

On the one hand, with my purist hat on, saying it is a requirement to =
make sure we do not need to have end-to-end connectivity smells a bit =
weird.

On the other hand, with my practical hat on, saying it is a requirement =
to make sure the protocol works in situations that are NOT the Internet =
(NATs, a need for an overlay privacy network, etc.) seems like a good =
thing to do.

On Feb 2, 2013, at 3:48 PM, Eric Rescorla  wrote:

> On Sat, Feb 2, 2013 at 10:51 AM, Harald Alvestrand =
 wrote:
> On 02/02/2013 01:56 PM, Stefan H=E5kansson LK wrote:
> On 2013-02-02 11:31, Harald Alvestrand wrote:
> On 02/01/2013 01:09 PM, Stefan H=E5kansson LK wrote:
> On 2013-02-01 11:58, Harald Alvestrand wrote:
> On 02/01/2013 11:34 AM, Stefan H=E5kansson LK wrote:
>=20
>     A25             It must be possible for the application to
>                     refrain from exposing the IP address
>=20
> [BA] I am assuming we are talking about exposing the originating IP
> address of media, which can be addressed via TURN.
> If so, this is more of a protocol than an API requirement. Since the
> ICE candidates need to exposed in the API in
> order to allow them to be signaled, I am not sure how we can avoid
> exposing those to the application.  Similarly, the
> HTTP server can obtain the IP address used by the HTTP client. Even
> within SIP, there are VIA headers and contact
> headers, so it is not easy to avoid disclosure of the IP address to
> everyone.  So I think we need to be more clear
> about what we are trying to avoid exposing, and to whom.
>=20
> Personally I would like to get rid of this requirement. The
> application can always get all candidates. To have a way to let the
> application ask for _only_ the TURN candidates does not change this -
> that kind of API is more for convenience (so that the app you trust
> does not have to remove privacy revealing candidates from the offer,
> but can instead ask the browser to deliver an offer without them).
> I think this requirement is important, but needs reformulation.
>=20
> Should we instead say
>=20
> "It MUST be possible to set up a call between two parties A and B
> without one party learning the other party's IP address"
>=20
> This requirement is not on the browser (or its APIs) per se, if we go
> this path it almost belongs into another category than what we
> currently have.
>=20
> I think it is, actually - the A browser has to be able to send media =
to
> B without sending IP packets to B, which means that it has to use an
> intermediary, and force B to use an intermediary too. TURN does that, =
we
> could imagine other solutions (the people who made Tor could probably
> think of many more schemes).
>=20
> OK. Here is a shot at it:
>=20
> Fnn: The browser MUST be able to send streams and                   =
data to a peer in such a fashion that the peer is not (e.g. by =
inspection of packets belonging to the streams or data or any associated =
signaling messages) able to find out the xxxxx IP address used by the =
browser
>=20
> There has been some discussion of xxxxx; is it needed, and if so, what =
should it say? "host"? "local"?
>=20
> The security property that has most often been expressed is that the =
correspondent should not be able to use the IP address to geolocate the =
user; this means that the most important value of "xxxx" is the globally =
routable IP address that is closest to the user's location.
>=20
> Some have also mentioned the need to hide local (RFC 1918) IP =
addresses in order to prevent mapping of the user's internal network; I =
think this is usually seen as a less dramatic threat.
>=20
> 1. If you don't want the server learning your global IP, you need to =
use Tor or the like.
> 2. I would suggest that it is simplest to divide the world into host =
addresses, server/peer
> reflexive, and relayed and say that the requirement is that the =
browser must be able
> to send packets without revealing either of the former two, but that =
it is not a requirement
> that it be able to do so in the face of an adversarial server.
>=20
> Note that S 5.4 of the security arch document has some specific =
requirements on
> implementations phrased in terms of the technologies we have actually =
chosen.
>=20
> -Ekr
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From eburger@standardstrack.com  Sun Feb  3 07:43:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A23021F8530 for ; Sun,  3 Feb 2013 07:43:32 -0800 (PST)
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 PcvEKaIrMJTq for ; Sun,  3 Feb 2013 07:43:31 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 986A221F86D6 for ; Sun,  3 Feb 2013 07:43:31 -0800 (PST)
Received: from ip-64-134-45-108.public.wayport.net ([64.134.45.108]:51131 helo=[192.168.5.30]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U21io-0003W5-1g for rtcweb@ietf.org; Sun, 03 Feb 2013 07:43:11 -0800
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Eric Burger 
In-Reply-To: 
Date: Sun, 3 Feb 2013 10:43:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <441C91AE-57EF-4B65-823B-0D1D755F00B4@standardstrack.com>
References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se>, <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se>, <510AF934.2030800@alvestrand.no>, <201302012243.r11MhmTi1016963@shell01.TheWorld.com>, , <510C5A40.6040600@omnitor.se> 
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [rtcweb] Playing regulator
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:43:32 -0000

Is the goal to make RTCweb as complex as possible to meet an irrelevant =
use case, while ensuring we bring various regulatory agencies into our =
pants?

Last I looked, RTCweb is about the Web.  Why try to bring legacy =
telco/ecrit requirements into an application that 99.8% of the time has =
no interaction with classic emergency services? If someone will build a =
"telephony terminal," they are already into regulation land, and will =
build this descendant of Zaphod Beeblebrox appropriately. I agree that =
there is no reason to make it harder for someone to build a regulated =
device with RTCweb protocols. However, I also do not see any reason to =
postpone RTCweb by 3-5 more years as we try to second guess regulatory =
requirements. Worse yet, we would be asking for regulators to insert =
themselves into the protocol development process. That is all we need - =
the next thing they will do is require voting by governments on protocol =
components! Might as well move the work to the ITU-T so we do not =
distract people working on the Internet from getting useful work done =
here in the IETF.

On Feb 1, 2013, at 7:54 PM, Bernard Aboba  =
wrote:

> While we didn't go into it in any depth in the document, there does =
seem to be a distinction between scenarios in which the application =
developer has little control over the endpoint (e.g. bring your own =
device), versus scenarios in which the application developer has some =
say or influence on what the capabilities of the endpoints are.
>=20
> In the former case, the application may have to function even in a =
browser environment where WebRTC is not available, whereas in the latter =
case, the application developer can ensure that a set of required =
capabilities are available.  The "telephony terminal" case seems more in =
the latter category than the former.=20
>=20
> For example, a vendor developing a "telephony terminal" could choose =
the browser they wanted to embed in the device, and might even have =
access to the browser source code, so as to be able to add codecs and =
other capabilities.   In that case, the performance and extensibility of =
the code base will be an important consideration, since that will =
determine how much work will be involved to add capabilities and what =
the options are for accomplishing this (e.g. native code required vs. =
Javascript).=20
>=20
> Date: Sat, 2 Feb 2013 01:13:52 +0100
> From: gunnar.hellstrom@omnitor.se
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Playing regulator
>=20
> It is easy to imagine applications of WebRTC where the users will not =
have any expectation that they could use it for emergency services.=20
> E.g. a web page only providing access to a specific company's customer =
service.
> So, each application does not need to provide this access.
>=20
> However, the platform has apparent ambitions to be possible to use for =
telephony like applications, with an opportunity to call by address or =
number,
> E.g =20
> 4.3.1. Telephony terminal=20
>=20
> In at least that case, there will be an expectation from users, and a =
requirement from regulators in many countries to be able to provide =
emergency service access.
>=20
> So, the topic belongs here in some way.
>=20
> I withdrew it from the total conversation addition, because it is a =
general function. I hope it will be possible to find a suitable place =
and general wording for it, and there indicate that it is valid for all =
media, including audio, video and real-time text.
>=20
> Gunnar
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46708204288
> On 2013-02-02 00:28, Bernard Aboba wrote:
> With regulations in flux, it is not easy to predict the extent of the =
obligation, beyond what exists for an "interconnected VoIP" service =
today.  For example, we have a text to 911 proceeding ongoing as well as =
quite a few others. In order to examine what the Issues might be, Martin =
and I put together the following document:
> http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit
>=20
> Comments welcome.
>=20
>=20
> On Feb 1, 2013, at 14:44, "Dale R. Worley"  wrote:
>=20
>=20
> Can you explain this?  I suspect that you have a specific meaning, but
> as I read it, it sounds like "I see no objection if WebRTC does not
> interwork with emergency services."  If WebRTC does not interwork with
> emergency services, the regulators will crush it.
>=20
> Dale
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
> _______________________________________________
> rtcweb mailing list
>=20
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
> _______________________________________________ rtcweb mailing list =
rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From ekr@rtfm.com  Sun Feb  3 10:33:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331EF21F8639 for ; Sun,  3 Feb 2013 10:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt4HxCcYJXoD for ; Sun,  3 Feb 2013 10:33:38 -0800 (PST)
Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 83FE021F8581 for ; Sun,  3 Feb 2013 10:33:38 -0800 (PST)
Received: by mail-oa0-f43.google.com with SMTP id l10so5865621oag.2 for ; Sun, 03 Feb 2013 10:33:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=t+hlnHIK2vuzIjy/sjP3yDwaUJ7ZxmIQUs8g6vsxhAg=; b=XbUEIi0Eq/QClJjBUqyemaBwS2vFZIT7F/2vAgoMBfxD/q2Rfp+g5ZKvx6bCAgVfxp xXO/ukSYH7b//jZ6I0QpX4/fCMy1NYOIYyDAPcdiyUWHCXnXVo80VcUjzoyaPE8NOZn9 DFjzJPJf8WCHNJXNjNoHRWcg5nVgJmc4HX5m6XAxlXFiYQPFAwJyyKR4g5deKEvEEp6E 58hkJmfCdoSue5QD2elS7Hv9xLlWKIbaZjU+w9QH/NQwfwm9SD35t9mN7LLYx0cF09eG pC9bOBl/UWmRCyiJ7eJEvnXdtz2HCvqrL59ojWV9//Nz4ZKQYHoDLPxMjUbIH0cjuEV2 yYTg==
X-Received: by 10.182.156.103 with SMTP id wd7mr13485132obb.33.1359916418024;  Sun, 03 Feb 2013 10:33:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.3.106 with HTTP; Sun, 3 Feb 2013 10:32:57 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>
From: Eric Rescorla 
Date: Sun, 3 Feb 2013 10:32:57 -0800
Message-ID: 
To: Burger Eric 
Content-Type: multipart/alternative; boundary=f46d0444e83505436c04d4d6377f
X-Gm-Message-State: ALoCoQkCWu0unIaeQrrJL4LNYHkGT71kOmNyh4jN33kt8DR+bMrCs0wNn6Px+YjzSL+cSc0KGcLD
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 18:33:39 -0000

--f46d0444e83505436c04d4d6377f
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric wrote:

> Is what we are really asking for is the ability of the protocol to be
> TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one
> particular anonymity network or another into the RTCweb protocol suite.
>

I'm certainly not suggesting that.



> On the one hand, with my purist hat on, saying it is a requirement to make
> sure we do not need to have end-to-end connectivity smells a bit weird.
>

I don't understand this... I don't think anyone is suggesting that.



> On the other hand, with my practical hat on, saying it is a requirement to
> make sure the protocol works in situations that are NOT the Internet (NATs,
> a need for an overlay privacy network, etc.) seems like a good thing to do.


As far as I know, the only novel requirement here is that there be a way
for Web
application to tell the browser to solely use relayed addresses/candidates
(and hopefully thus not reveal the user's actual location) when
communicating
with the peer. There is of course a requirement to be able to work when
behind NATs but that is a functional requirement, not an anonymity one.

WRT to the question of privacy networks such as Tor that isn't a requirement
on the protocol or the browser but rather the answer to the user's question
"how do I surf the net without revealing my IP address and location to
servers?" I.e., that is not a feature we intend to provide via WebRTC, but
rather one that the user needs to obtain for himself.

-Ekr

--f46d0444e83505436c04d4d6377f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric <eburger@cs.georgeto=
wn.edu> wrote:


Is what we are really asking for is the ability of the protocol to be TOR-,=
 TURN-, and mumble-friendly? I am hesitant to suggest we bake in one partic=
ular anonymity network or another into the RTCweb protocol suite.




I'm certainly not suggesting that.

=A0

On the one hand, with my purist hat on, saying it is a requirement to make =
sure we do not need to have end-to-end connectivity smells a bit weird.
=


I don't understand this... I don't=
 think anyone is suggesting that.




=A0

On the other hand, with my practical hat on, saying it is a requirement to =
make sure the protocol works in situations that are NOT the Internet (NATs,=
 a need for an overlay privacy network, etc.) seems like a good thing to do=
.




As far as I know, the only novel requirement here is th=
at there be a way for Web
application to tell the browser to sole=
ly use relayed addresses/candidates
(and hopefully thus not revea=
l the user's actual location) when communicating



with the peer. There is of course a requirement to be able to work whe=
n
behind NATs but that is a functional requirement, not an anonym=
ity one.

WRT to the question of privacy networks s=
uch as Tor that isn't a requirement



on the protocol or the browser but rather the answer to the user's=
 question
"how do I surf the net without revealing my IP add=
ress and location to
servers?" I.e., that is not a feature w=
e intend to provide via WebRTC, but



rather one that the user needs to obtain for himself.

-Ekr



--f46d0444e83505436c04d4d6377f--

From eburger@standardstrack.com  Sun Feb  3 10:56:06 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2E221F8797 for ; Sun,  3 Feb 2013 10:56:06 -0800 (PST)
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 TOCMLHh3DGPw for ; Sun,  3 Feb 2013 10:56:06 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id F278821F874B for ; Sun,  3 Feb 2013 10:56:05 -0800 (PST)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:53696 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U24jB-00083P-6n for rtcweb@ietf.org; Sun, 03 Feb 2013 10:55:45 -0800
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Eric Burger 
In-Reply-To: 
Date: Sun, 3 Feb 2013 13:56:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu> 
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 18:56:06 -0000

To be clear, I think ekr's formulation is the best:
> 1. If you don't want the server learning your global IP, you need to =
use Tor or the like.

To me, this means it is totally orthogonal to RTCweb. If you want to use =
Tor, a TURN server, an ALG, or foo, that is up to you. That does not =
impact the protocol.

> 2. I would suggest that it is simplest to divide the world into host =
addresses, server/peer
> reflexive, and relayed and say that the requirement is that the =
browser must be able
> to send packets without revealing either of the former two, but that =
it is not a requirement
> that it be able to do so in the face of an adversarial server.
And this is the most reasonable. I guess the concern is we will forget =
all of this list discussion, and someone will require hard-coded =
endpoint IP addresses in the protocol, which is what sunk SIP in the =
early days.

Inline=85

On Feb 3, 2013, at 1:32 PM, Eric Rescorla  wrote:

> On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric =
 wrote:
> Is what we are really asking for is the ability of the protocol to be =
TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in =
one particular anonymity network or another into the RTCweb protocol =
suite.
>=20
> I'm certainly not suggesting that.
>=20
> =20
> On the one hand, with my purist hat on, saying it is a requirement to =
make sure we do not need to have end-to-end connectivity smells a bit =
weird.
>=20
>> I don't understand this... I don't think anyone is suggesting that.

Saying we will bake into the protocol the REQUIREMENT that it support =
good or bad boxes in the middle of the network does not sound like the =
end-to-end Internet. It sounds more like IMS.

> On the other hand, with my practical hat on, saying it is a =
requirement to make sure the protocol works in situations that are NOT =
the Internet (NATs, a need for an overlay privacy network, etc.) seems =
like a good thing to do.
>=20
>> As far as I know, the only novel requirement here is that there be a =
way for Web
>> application to tell the browser to solely use relayed =
addresses/candidates
>> (and hopefully thus not reveal the user's actual location) when =
communicating
>> with the peer. There is of course a requirement to be able to work =
when
>> behind NATs but that is a functional requirement, not an anonymity =
one.

That is asking an awful lot of an application. Moreover, as the =
cat-and-mouse game of anonymous application communication is ever =
evolving, I would challenge how meaningful it is to specify a Hidden Bit =
or Anonymous Bit in the protocol. I would offer that will work as well =
as the Evil Bit.

>> WRT to the question of privacy networks such as Tor that isn't a =
requirement
>> on the protocol or the browser but rather the answer to the user's =
question
>> "how do I surf the net without revealing my IP address and location =
to
>> servers?" I.e., that is not a feature we intend to provide via =
WebRTC, but
>> rather one that the user needs to obtain for himself.

Agreed!


From martin.thomson@gmail.com  Sun Feb  3 11:05:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36E921F8A30 for ; Sun,  3 Feb 2013 11:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level: 
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CICT+uYten9 for ; Sun,  3 Feb 2013 11:05:29 -0800 (PST)
Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 976EB21F88A8 for ; Sun,  3 Feb 2013 11:05:28 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id ds1so2591874wgb.0 for ; Sun, 03 Feb 2013 11:05:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eH98mwxCvE4CJ1CoWgkg5V+I1sfB6IzrDDzlK99seow=; b=xZn9TAV9vrqn0R4q5GVMepojkGWJaard3BdsBZBSotrvr6dH+T1YcvPcNk4OsG8fxQ izqrT2qONDt8NRcn09h2+ImABRQyGqB1+nNDB0gDY2F94Lyryv9S3/7XLyWsCQ49c3vk IsIqtBnbndO6QyMHWyXKgiMMXf9nDr6dKHevIKkxrfcELKyJKed14wxMYZs4McVBOzBO wdy+ZG8R8Y9s18t4roG3veF8CUip628nfihKqFOytwBKjkmxY1EJ5cCZpAJMr7n9whNi ScHMIDIhEriNb0G7QvUzp6I9bFrB+zzFWqhdIV05JfdtVmaTN9hezAEcaYX1mtYuRvNR mELg==
MIME-Version: 1.0
X-Received: by 10.194.108.200 with SMTP id hm8mr7174680wjb.21.1359918327458; Sun, 03 Feb 2013 11:05:27 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Sun, 3 Feb 2013 11:05:27 -0800 (PST)
In-Reply-To: 
References:  
Date: Sun, 3 Feb 2013 11:05:27 -0800
Message-ID: 
From: Martin Thomson 
To: Ted Hardie 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time 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, 03 Feb 2013 19:05:29 -0000

On 2 February 2013 18:55, Ted Hardie  wrote:
> No, the concrete question is whether the requirement to interwork with
> emergency services will constrain the design.

I think that Bernard was addressing that question directly.  Namely:
we do not need to constrain the design for it to be possible to
provide emergency services.

Of course, that is the communication needs of emergency service, not
necessarily the letter of regulation.  That might require some
compromise on the part of the emergency services (in the form of
gateways or other changes to how they accept "calls").  I'm highly
sympathetic to the view that emergency services should not be regarded
as special.  The argument goes: "If emergency services are special,
how do I know that the special parts work when I need them?  They
aren't used all the time."

From bernard_aboba@hotmail.com  Sun Feb  3 11:33:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D0021F8A84 for ; Sun,  3 Feb 2013 11:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.433
X-Spam-Level: 
X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 o+oo7XcxCXyH for ; Sun,  3 Feb 2013 11:33:33 -0800 (PST)
Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF721F89DC for ; Sun,  3 Feb 2013 11:33:33 -0800 (PST)
Received: from BLU404-EAS180 ([65.55.116.74]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Feb 2013 11:33:33 -0800
X-EIP: [OaHxjFwDSMrQt3/6ctKZjmRSATx3uslmVHWSNGXzBaM=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
From: Bernard Aboba 
To: "'Martin Thomson'" , "'Ted Hardie'" 
References: 	 
In-Reply-To: 
Date: Sun, 3 Feb 2013 11:33:31 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQABAgME1fHPTStaFOtbvJc4Sj0orACDi3OOAPkA9isAtloMbABT+X2+AEwPz9oA5i3U3wC1D+P8AO218DsA//HdA5vPo6zA
Content-Language: en-us
X-OriginalArrivalTime: 03 Feb 2013 19:33:33.0589 (UTC) FILETIME=[5A92C450:01CE0245]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: bernard_aboba@hotmail.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: Sun, 03 Feb 2013 19:33:34 -0000

Martin said:

"I'm highly sympathetic to the view that emergency services should not =
be regarded as special.  The argument goes: "If emergency services are =
special, how do I know that the special parts work when I need them?  =
They aren't used all the time."

[BA] Exactly.   If all of the emergency services functionality that we =
need isn't already covered by mainstream WebRTC use cases and =
requirements, the answer isn't to change the use cases.   Even use cases =
that we expect to be frequently utilized will have bugs.   So why would =
anyone want to risk their life on non-mainstream use cases that are much =
less likely to be extensively used and tested? =20

From gunnar.hellstrom@omnitor.se  Sun Feb  3 15:15:09 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480CC21F8871 for ; Sun,  3 Feb 2013 15:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=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 TzMBupAJBNhE for ; Sun,  3 Feb 2013 15:15:08 -0800 (PST)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 31C4221F886A for ; Sun,  3 Feb 2013 15:15:06 -0800 (PST)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon,  4 Feb 2013 00:14:28 +0100 (CET)
Received: from [10.220.17.165] (unknown [93.158.48.126]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 8DFA03A0F6 for ; Mon,  4 Feb 2013 00:14:28 +0100 (CET)
Message-ID: <510EEF55.7000902@omnitor.se>
Date: Mon, 04 Feb 2013 00:14:29 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
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] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - emergency service access
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 23:15:09 -0000

> Martin said:
>
> "I'm highly sympathetic to the view that emergency services should not be regarded as special.  The argument goes: "If emergency services are special, how do I know that the special parts work when I need them?  They aren't used all the time."
>
> [BA] Exactly.   If all of the emergency services functionality that we need isn't already covered by mainstream WebRTC use cases and requirements, the answer isn't to change the use cases.   Even use cases that we expect to be frequently utilized will have bugs.   So why would anyone want to risk their life on non-mainstream use cases that are much less likely to be extensively used and tested?
(changed subject line to emergency service access )

Right, the emergency calls need to be as mainstream as possible.
But there are RFCs about how emergency calls are expected to appear, and 
they require a couple of "special" actions from the client and service 
provider.
Since next generation emergency services are now planned based on these 
RFCs it is best to make sure rtcweb based systems can comply.

It is mainly:
-provide location
-use SIP
-use supported codecs for audio, video and real-time text
-either client or server use urn:service:sos.... addressing

In order to test if it really works, a method for testing is specified 
in RFC 6443, requesting automatic loopback of a couple of RTP packets, 
and an opportunity to verify that the right emergency service was reached.
(I am a bit afraid that the load of these test calls will be 
overwhelming for the network resources compared to real calls, and might 
need a rethinking, but they at least do not load any operational human 
call taker. So, the mechanisms you ask for are there.)

It is true with all features in rtcweb that they are not required to be 
used in all application implementations. But they need to be described 
and included in the support from the browsers and APIs.

Thus, for emergency services, I assume that we would need to specify 
protocol elements and API:s for approximately the following:

-Mark call as emergency call ( From application to browser )
-Provide location with the call
-Provide urn: address ( possibly, can also be handled by server )
-Provide call-back address
-Provide user modality and language preferences and capabilities.

This is not much and not much to vary between countries. If variations 
between countries are needed, they should be concentrated in the server.

/Gunnar

From ekr@rtfm.com  Sun Feb  3 15:48:47 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074DD21F8864 for ; Sun,  3 Feb 2013 15:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXUI2eCBvzNT for ; Sun,  3 Feb 2013 15:48:45 -0800 (PST)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id A6D1521F883E for ; Sun,  3 Feb 2013 15:48:45 -0800 (PST)
Received: by mail-ob0-f179.google.com with SMTP id un3so5835348obb.10 for ; Sun, 03 Feb 2013 15:48:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=LoeUcdDG4PUuZcBMLjyVHqIGwkzjkN1t/+EUuheT/CM=; b=aCgkCKCS+q0gl/CMMkG4lnQOwutV1UG/SlZN3hZhc+sevY8X3Ra+dbQJPjbjXD9eNk CC58/lT9hYweLFShgK7a5ukFU66T3J3bS60jKDBvyrltYaAxB2XilEoPT3Fp+7EnTVjj BNpHbBfHMGJ/aLNrBUIettcM07QSi5goVJbg04CPFYt0SIqij65HVz3vTZBbaejePWnb Ey+gn5iiCZFuFbLAF9DvQXMHoJWe9gtlcAhCmE7ycKGywive4pNaMpfzr+nBdh4xMWiS 4sBj+H6JdQHZE4PmJnUzN9BM0ZhkTVXXaduZdcMrpNYGfAWuBcrOUij4pXpnuARRA3wr AMBg==
X-Received: by 10.60.21.104 with SMTP id u8mr2739107oee.99.1359935325155; Sun, 03 Feb 2013 15:48:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.3.106 with HTTP; Sun, 3 Feb 2013 15:48:04 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>  <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>
From: Eric Rescorla 
Date: Sun, 3 Feb 2013 15:48:04 -0800
Message-ID: 
To: Eric Burger 
Content-Type: multipart/alternative; boundary=e89a8ff1c6d6f930ae04d4da9d09
X-Gm-Message-State: ALoCoQlP4YPkh08q0JXB1rdbNCudVZcIipFoWy5PJA7B1qPVLRVFJtSonMu88JgwdSKVlJj+OAM0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 23:48:47 -0000

--e89a8ff1c6d6f930ae04d4da9d09
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger wr=
ote:

> To be clear, I think ekr's formulation is the best:
> > 1. If you don't want the server learning your global IP, you need to us=
e
> Tor or the like.
>
> To me, this means it is totally orthogonal to RTCweb. If you want to use
> Tor, a TURN server, an ALG, or foo, that is up to you. That does not impa=
ct
> the protocol.


That's certainly what I meant to be saying, with the small caveat that
if you are using media relays (e.g., TURN) they are supposed to be
reflected in ICE candidate lines.


> 2. I would suggest that it is simplest to divide the world into host
addresses, server/peer

> > reflexive, and relayed and say that the requirement is that the browser
> must be able
> > to send packets without revealing either of the former two, but that it
> is not a requirement
> > that it be able to do so in the face of an adversarial server.
> And this is the most reasonable. I guess the concern is we will forget al=
l
> of this list discussion, and someone will require hard-coded endpoint IP
> addresses in the protocol, which is what sunk SIP in the early days.
>
> Inline=85
>
> On Feb 3, 2013, at 1:32 PM, Eric Rescorla  wrote:
>
> > On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric 
> wrote:
> > Is what we are really asking for is the ability of the protocol to be
> TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one
> particular anonymity network or another into the RTCweb protocol suite.
> >
> > I'm certainly not suggesting that.
> >
> >
> > On the one hand, with my purist hat on, saying it is a requirement to
> make sure we do not need to have end-to-end connectivity smells a bit wei=
rd.
> >
> >> I don't understand this... I don't think anyone is suggesting that.
>
> Saying we will bake into the protocol the REQUIREMENT that it support goo=
d
> or bad boxes in the middle of the network does not sound like the
> end-to-end Internet. It sounds more like IMS.


Which requirement do you think suggests that? I certainly favor
requirements that we be
able to work in the face of as many known classes of intermediaries (NATs,
firewalls,
etc. as possible.) I mean, isn't that the point of ICE supporting TURN and
other types
of relays?

Is there something wrong with this? Do you think people are suggesting some
other requirement?


 > On the other hand, with my practical hat on, saying it is a requirement
> to make sure the protocol works in situations that are NOT the Internet
> (NATs, a need for an overlay privacy network, etc.) seems like a good thi=
ng
> to do.
> >
> >> As far as I know, the only novel requirement here is that there be a
> way for Web
> >> application to tell the browser to solely use relayed
> addresses/candidates
> >> (and hopefully thus not reveal the user's actual location) when
> communicating
> >> with the peer. There is of course a requirement to be able to work whe=
n
> >> behind NATs but that is a functional requirement, not an anonymity one=
.
>
> That is asking an awful lot of an application. Moreover, as the
> cat-and-mouse game of anonymous application communication is ever evolvin=
g,
> I would challenge how meaningful it is to specify a Hidden Bit or Anonymo=
us
> Bit in the protocol. I would offer that will work as well as the Evil Bit=
.


I really am not following what you are saying here about a "hidden bit"?

There is a very specific requirement being suggested here, namely that
applications
should be able to instruct browsers not to use host or srvflx candidates.
This is
neither a hidden bit, nor an anonymous bit. Rather, it is a mechanism
designed
to allow the site, *if it wishes* to offer a calling service that doesn't
immediately
reveal the caller's location. This isn't a complete anonymity service
against
sophisticated attackers. For that you need something like Tor. Rather, it's
an
easy-to-implement measure that offers location protection against a
(relatively common) class of limited attackers.

What is it you object to about this requirement?

-Ekr

--e89a8ff1c6d6f930ae04d4da9d09
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Sun, Feb 3, 2013 at 10:56 AM, Eric Bu=
rger <eburger@standardstrack.com> wrote:


To be clear, I think ekr's formulation is the best:


> 1. If you don't want the server learning your gl=
obal IP, you need to use Tor or the like.




To me, this means it is totally orthogonal to RTCweb. If you want to =
use Tor, a TURN server, an ALG, or foo, that is up to you. That does not im=
pact the protocol.

That's certainly wha=
t I meant to be saying, with the small caveat that



if you are using media relays (e.g., TURN) they are supposed to be
reflected in ICE candidate lines.


> 2. I would suggest that it is simplest to divide the world into =
host addresses, server/peer




> reflexive, and relayed and say that the requirement is that the browse=
r must be able

> to send packets without revealing either of the former two, but that i=
t is not a requirement

> that it be able to do so in the face of an adversarial server.


And this is the most reasonable. I guess the concern is we will forge=
t all of this list discussion, and someone will require hard-coded endpoint=
 IP addresses in the protocol, which is what sunk SIP in the early days.




Inline=85




On Feb 3, 2013, at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:



> On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric <eburger@cs.georgetown.edu> wrote:

> Is what we are really asking for is the ability of the protocol to be =
TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one p=
articular anonymity network or another into the RTCweb protocol suite.



>

> I'm certainly not suggesting that.

>

>

> On the one hand, with my purist hat on, saying it is a requirement to =
make sure we do not need to have end-to-end connectivity smells a bit weird=
.

>

>> I don't understand this... I don't think anyone is suggest=
ing that.




Saying we will bake into the protocol the REQUIREMENT that it support=
 good or bad boxes in the middle of the network does not sound like the end=
-to-end Internet. It sounds more like IMS.




Which requirement do you think suggests that? I certainly favor requir=
ements that we be
able to work in the face of as many known class=
es of intermediaries (NATs, firewalls,
etc. as possible.) I mean,=
 isn't that the point of ICE supporting TURN and other types



of relays?

Is there something wrong with this=
? Do you think people are suggesting some
other requirement?
<=
br>





> On the other hand, with my practical hat on, saying it is a requiremen=
t to make sure the protocol works in situations that are NOT the Internet (=
NATs, a need for an overlay privacy network, etc.) seems like a good thing =
to do.



>

>> As far as I know, the only novel requirement here is that there be=
 a way for Web

>> application to tell the browser to solely use relayed addresses/ca=
ndidates

>> (and hopefully thus not reveal the user's actual location) whe=
n communicating

>> with the peer. There is of course a requirement to be able to work=
 when

>> behind NATs but that is a functional requirement, not an anonymity=
 one.




That is asking an awful lot of an application. Moreover, as the cat-a=
nd-mouse game of anonymous application communication is ever evolving, I wo=
uld challenge how meaningful it is to specify a Hidden Bit or Anonymous Bit=
 in the protocol. I would offer that will work as well as the Evil Bit.



I really am not following what you are saying here abou=
t a "hidden bit"?

There is a very specif=
ic requirement being suggested here, namely that applications


should be able to instruct browsers not to use host or srvflx candidates. T=
his is
neither a hidden bit, nor an anonymous bit. Rather, it is =
a mechanism designed
to allow the site, *if it wishes* to offer a=
 calling service that doesn't immediately



reveal the caller's location. This isn't a complete anonymity =
service against
sophisticated attackers. For that you need someth=
ing like Tor. Rather, it's an
easy-to-implement measure that =
offers location protection against a=A0



(relatively common) class of limited attackers.

What is it you object to about this requirement?

-Ekr



--e89a8ff1c6d6f930ae04d4da9d09--

From harald@alvestrand.no  Sun Feb  3 19:31:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447521F89D5 for ; Sun,  3 Feb 2013 19:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.664
X-Spam-Level: 
X-Spam-Status: No, score=-108.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llFK0f6XmTUZ for ; Sun,  3 Feb 2013 19:31:34 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3300021F89B2 for ; Sun,  3 Feb 2013 19:31:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C08339E0A7; Mon,  4 Feb 2013 04:31:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsMed4bbWLqx; Mon,  4 Feb 2013 04:31:30 +0100 (CET)
Received: from [10.246.3.243] (244-3-11.connect.netcom.no [176.11.3.244]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8813F39E04C; Mon,  4 Feb 2013 04:31:30 +0100 (CET)
User-Agent: K-9 Mail for Android
In-Reply-To: <510EEF55.7000902@omnitor.se>
References:     <510EEF55.7000902@omnitor.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----C4RI1EBQWQI7PHM6KQVS9L7Z4RHQR7"
From: Harald Alvestrand 
Date: Mon, 04 Feb 2013 04:31:26 +0100
To: Gunnar Hellstrom ,rtcweb@ietf.org
Message-ID: <8bef5302-3bc7-43c6-ba81-d75627c97938@email.android.com>
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - emergency service access
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 03:31:35 -0000

------C4RI1EBQWQI7PHM6KQVS9L7Z4RHQR7
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

All of the mentioned features except loopback belong in signalling, not in rtcweb.

Gunnar Hellstrom  wrote:

>
>> Martin said:
>>
>> "I'm highly sympathetic to the view that emergency services should
>not be regarded as special.  The argument goes: "If emergency services
>are special, how do I know that the special parts work when I need
>them?  They aren't used all the time."
>>
>> [BA] Exactly.   If all of the emergency services functionality that
>we need isn't already covered by mainstream WebRTC use cases and
>requirements, the answer isn't to change the use cases.   Even use
>cases that we expect to be frequently utilized will have bugs.   So why
>would anyone want to risk their life on non-mainstream use cases that
>are much less likely to be extensively used and tested?
>(changed subject line to emergency service access )
>
>Right, the emergency calls need to be as mainstream as possible.
>But there are RFCs about how emergency calls are expected to appear,
>and 
>they require a couple of "special" actions from the client and service 
>provider.
>Since next generation emergency services are now planned based on these
>
>RFCs it is best to make sure rtcweb based systems can comply.
>
>It is mainly:
>-provide location
>-use SIP
>-use supported codecs for audio, video and real-time text
>-either client or server use urn:service:sos.... addressing
>
>In order to test if it really works, a method for testing is specified 
>in RFC 6443, requesting automatic loopback of a couple of RTP packets, 
>and an opportunity to verify that the right emergency service was
>reached.
>(I am a bit afraid that the load of these test calls will be 
>overwhelming for the network resources compared to real calls, and
>might 
>need a rethinking, but they at least do not load any operational human 
>call taker. So, the mechanisms you ask for are there.)
>
>It is true with all features in rtcweb that they are not required to be
>
>used in all application implementations. But they need to be described 
>and included in the support from the browsers and APIs.
>
>Thus, for emergency services, I assume that we would need to specify 
>protocol elements and API:s for approximately the following:
>
>-Mark call as emergency call ( From application to browser )
>-Provide location with the call
>-Provide urn: address ( possibly, can also be handled by server )
>-Provide call-back address
>-Provide user modality and language preferences and capabilities.
>
>This is not much and not much to vary between countries. If variations 
>between countries are needed, they should be concentrated in the
>server.
>
>/Gunnar
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------C4RI1EBQWQI7PHM6KQVS9L7Z4RHQR7
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

All of the mentioned features except loopback belong in signalling, not in rtcweb.

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:



Martin said:

"I'm highly sympathetic to the view that emergency services should not be regarded as special.  The argument goes: "If emergency services are special, how do I know that the special parts work when I need them?  They aren't used all the time."

[BA] Exactly.   If all of the emergency services functionality that we need isn't already covered by mainstream WebRTC use cases and requirements, the answer isn't to change the use cases.   Even use cases that we expect to be frequently utilized will have bugs.   So why would anyone want to risk their life on non-mainstream use cases that are much less likely to be extensively used and tested?
(changed subject line to emergency service access )

Right, th
 e
emergency calls need to be as mainstream as possible.
But there are RFCs about how emergency calls are expected to appear, and 
they require a couple of "special" actions from the client and service 
provider.
Since next generation emergency services are now planned based on these 
RFCs it is best to make sure rtcweb based systems can comply.

It is mainly:
-provide location
-use SIP
-use supported codecs for audio, video and real-time text
-either client or server use urn:service:sos.... addressing

In order to test if it really works, a method for testing is specified 
in RFC 6443, requesting automatic loopback of a couple of RTP packets, 
and an opportunity to verify that the right emergency service was reached.
(I am a bit afraid that the load of these test calls will be 
overwhelming for the network resources compared to real calls, and might 
need a rethinking, but they at least do
  not
load any operational human 
call taker. So, the mechanisms you ask for are there.)

It is true with all features in rtcweb that they are not required to be 
used in all application implementations. But they need to be described 
and included in the support from the browsers and APIs.

Thus, for emergency services, I assume that we would need to specify 
protocol elements and API:s for approximately the following:

-Mark call as emergency call ( From application to browser )
-Provide location with the call
-Provide urn: address ( possibly, can also be handled by server )
-Provide call-back address
-Provide user modality and language preferences and capabilities.

This is not much and not much to vary between countries. If variations 
between countries are needed, they should be concentrated in the server.

/Gunnar

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


-- 

Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------C4RI1EBQWQI7PHM6KQVS9L7Z4RHQR7--


From eburger@standardstrack.com  Mon Feb  4 02:52:33 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA521F8444 for ; Mon,  4 Feb 2013 02:52:33 -0800 (PST)
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 dQP0V4nNe+Ws for ; Mon,  4 Feb 2013 02:52:32 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id A593021F8442 for ; Mon,  4 Feb 2013 02:52:32 -0800 (PST)
Received: from 208.177.47.110.ptr.us.xo.net ([208.177.47.110]:59586 helo=[10.166.71.157]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U2Jek-00086V-71; Mon, 04 Feb 2013 02:52:10 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_30640413-C1C1-485A-B183-8FF5D88551C9"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Eric Burger 
In-Reply-To: 
Date: Mon, 4 Feb 2013 05:52:31 -0500
Message-Id: 
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>  <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 10:52:33 -0000

--Apple-Mail=_30640413-C1C1-485A-B183-8FF5D88551C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Under what circumstances would it be up to the Web server to decide to =
make the client interaction quasi-anonymous? Would that not be a =
entirely up to and the responsibility of the client? By definition, the =
Web server is not anonymous -- the user had to reach it somehow to get =
the page in the first place. Likewise, it is well within the power of =
the server to obfuscate its media address. It is quite likely media is =
NOT coming from the same IP address as the Web page under normal =
circumstances, so the server has built-in opportunities to obfuscate its =
address. Conversely, it is well within the capabilities of the browser =
to figure out how to obfuscate its media address. More importantly, I =
have yet to hear a cogent use case for the server saying, "I want this =
interaction to not have IP addresses *TO PROTECT YOU*." If you are in a =
scenario where you need protection, you cannot depend on the server. You =
must depend on yourself, which means you will have a browser that will =
protect you. Moreover, will not a bad server simply always tell all =
browsers it connects with to open lots of anonymity relays to DDoS the =
relays? Saying we want to build something that is only sometimes useful =
and can only be useful if we trust all sides to do the right thing does =
not sound very useful.

Am I missing something here?

On Feb 3, 2013, at 6:48 PM, Eric Rescorla  wrote:

>=20
>=20
> On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger =
 wrote:
> To be clear, I think ekr's formulation is the best:
> > 1. If you don't want the server learning your global IP, you need to =
use Tor or the like.
>=20
> To me, this means it is totally orthogonal to RTCweb. If you want to =
use Tor, a TURN server, an ALG, or foo, that is up to you. That does not =
impact the protocol.
>=20
> That's certainly what I meant to be saying, with the small caveat that
> if you are using media relays (e.g., TURN) they are supposed to be
> reflected in ICE candidate lines.
>=20
>=20
> > 2. I would suggest that it is simplest to divide the world into host =
addresses, server/peer
> > reflexive, and relayed and say that the requirement is that the =
browser must be able
> > to send packets without revealing either of the former two, but that =
it is not a requirement
> > that it be able to do so in the face of an adversarial server.
> And this is the most reasonable. I guess the concern is we will forget =
all of this list discussion, and someone will require hard-coded =
endpoint IP addresses in the protocol, which is what sunk SIP in the =
early days.
>=20
> Inline=85
>=20
> On Feb 3, 2013, at 1:32 PM, Eric Rescorla  wrote:
>=20
> > On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric =
 wrote:
> > Is what we are really asking for is the ability of the protocol to =
be TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in =
one particular anonymity network or another into the RTCweb protocol =
suite.
> >
> > I'm certainly not suggesting that.
> >
> >
> > On the one hand, with my purist hat on, saying it is a requirement =
to make sure we do not need to have end-to-end connectivity smells a bit =
weird.
> >
> >> I don't understand this... I don't think anyone is suggesting that.
>=20
> Saying we will bake into the protocol the REQUIREMENT that it support =
good or bad boxes in the middle of the network does not sound like the =
end-to-end Internet. It sounds more like IMS.
>=20
> Which requirement do you think suggests that? I certainly favor =
requirements that we be
> able to work in the face of as many known classes of intermediaries =
(NATs, firewalls,
> etc. as possible.) I mean, isn't that the point of ICE supporting TURN =
and other types
> of relays?
>=20
> Is there something wrong with this? Do you think people are suggesting =
some
> other requirement?
>=20
>=20
> > On the other hand, with my practical hat on, saying it is a =
requirement to make sure the protocol works in situations that are NOT =
the Internet (NATs, a need for an overlay privacy network, etc.) seems =
like a good thing to do.
> >
> >> As far as I know, the only novel requirement here is that there be =
a way for Web
> >> application to tell the browser to solely use relayed =
addresses/candidates
> >> (and hopefully thus not reveal the user's actual location) when =
communicating
> >> with the peer. There is of course a requirement to be able to work =
when
> >> behind NATs but that is a functional requirement, not an anonymity =
one.
>=20
> That is asking an awful lot of an application. Moreover, as the =
cat-and-mouse game of anonymous application communication is ever =
evolving, I would challenge how meaningful it is to specify a Hidden Bit =
or Anonymous Bit in the protocol. I would offer that will work as well =
as the Evil Bit.
>=20
> I really am not following what you are saying here about a "hidden =
bit"?
>=20
> There is a very specific requirement being suggested here, namely that =
applications
> should be able to instruct browsers not to use host or srvflx =
candidates. This is
> neither a hidden bit, nor an anonymous bit. Rather, it is a mechanism =
designed
> to allow the site, *if it wishes* to offer a calling service that =
doesn't immediately
> reveal the caller's location. This isn't a complete anonymity service =
against
> sophisticated attackers. For that you need something like Tor. Rather, =
it's an
> easy-to-implement measure that offers location protection against a=20
> (relatively common) class of limited attackers.
>=20
> What is it you object to about this requirement?
>=20
> -Ekr
>=20


--Apple-Mail=_30640413-C1C1-485A-B183-8FF5D88551C9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJRD5LvAAoJEDY/T2tCIPW3WFIP/3clST0xVqIqqZE151wUp4jB
bedSAivoVxXqx/kExs1vqqWupm7n/P+nICX/RL+veKIzT7iqnHEv3YsJOoMDArSu
BNuEfbm30mZrppBYpKWPCA9dtD0H9njJ8duHqZlCM2mbzPoxJoThX+FLv1Sq9fT8
Nk72k5q/P5iK6oXONDSx6CMLxXxhuvLfL6vioJvVVQaJYfUAb9Dm89MlEPzwwAE4
OVRbEBa9ia/GVQCgo1WiwNxzkenTPovYaXDpBuc6RA5LB4JxWPZ95jOCoCbNULDi
BlhPlGpAK8Bcl0iQCSYFKqBl5bSnTukZi9ykaQYggV8wajactYKYF8LL2av0+v6i
e0s+X2yrt2EXrN7qsTdx+G2xuHkcW9vzHEGnuuqcfCNEGBS8irUGewuvZGxXj+DC
afLVaXVhhrPJBt316I5G5K8hD4WG6ruNZstUrK5Ow2HJRcAoHSfqTHl22irdCRIg
zNdP5GgcDYId6co+UkcY8TpWkRf0pvSvZMe/ua/E8FiqN0HdmVjavq2AUeUajf4o
Ka/OJcRQlmYTm+s7HS22l2Nb/MCJycO9WdWo05frY/5YrHEb3tyxkZxSyiTF3RbL
8rYPExlPFBbgZEspG0vV48+6DrdZ2qmLlZdhL8j4HfS18PDo1Bo+Ay5LT90laGkI
xPKEC+7iVrbzTpAlzQt1
=rQ9K
-----END PGP SIGNATURE-----

--Apple-Mail=_30640413-C1C1-485A-B183-8FF5D88551C9--

From john@jlc.net  Mon Feb  4 04:19:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D8821F8688 for ; Mon,  4 Feb 2013 04:19:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.498
X-Spam-Level: 
X-Spam-Status: No, score=-105.498 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, J_CHICKENPOX_17=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 QpHbO8fdA9Ho for ; Mon,  4 Feb 2013 04:19:53 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6B93721F861F for ; Mon,  4 Feb 2013 04:19:53 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id F017233C95; Mon,  4 Feb 2013 07:19:52 -0500 (EST)
Date: Mon, 4 Feb 2013 07:19:52 -0500
From: John Leslie 
To: Harald Alvestrand 
Message-ID: <20130204121952.GB71970@verdi>
References: <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <510B9FD8.6000008@alvestrand.no>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 12:19:54 -0000

Harald Alvestrand  wrote:
> On 02/01/2013 11:34 AM, Stefan H?kansson LK wrote:
>>>
>>>    A25             It must be possible for the application to
>>>                    refrain from exposing the IP address

   This definitely needs work: "the application", "refrain", "exposing",
and "the IP address" are all a bit ambiguous. :^(

   I have been having trouble following this discussion: let me try
to summarize my understanding.

> Should we instead say
> 
> "It MUST be possible to set up a call between two parties A and B 
> without one party learning the other party's IP address"

   This is a far clearer statement, leaving only "other party's IP
address" ambiguous.

   What I haven't been able to follow is whether we all believe the
problem we're trying to solve is "one party" learning the "other
party's" whatever.

   In any case, A25 is supposed to be a requirement of the API --
thus it need to be stated in terms of what the API does.

   In a later message, Harald explained:
] 
] the A browser has to be able to send media to B without sending IP
] packets to B, which means that it has to use an intermediary, and
] force B to use an intermediary too.

   Later still, Harald says:
] 
] The security property that has most often been expressed is that
] the correspondent should not be able to use the IP address to
] geolocate the user; this means that the most important value of
] "xxxx" is the globally routable IP address that is closest to the
] user's location.

   AFAICT, we're now talking about:
] 
] A25    It MUST be possible to set up a call between two parties
]        A and B without one party learning the other party's
]        globally-routable IP address

and the discusion is about whether such an API requirement belongs
here at all.

   FWIW, my opinion is that it arguably belongs as a requirement
that the API have a way to request this; otherwise not. IMHO it is
not appropriate that RTCWEB require such a request to succeed.

   Furthermore, I remain very unsure whether we're talking about
hiding your globally-routable IP address only from another endpoint
(as opposed to hiding it from a middlebox near that endpoint.

   I can be happy with any requirement which is simple enough to
achieve, or no requirement in this direction at all -- a person
intent on hiding his globally-routable IP address needs to take
responsibility for hiding it -- not trust some widely-distributed
application which needs to seek distribution in countries where
such hiding is forbidden by the government.

   (YMMV, obviously...)

--
John Leslie 

From mubmar@gmail.com  Mon Feb  4 07:14:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5C221F8800 for ; Mon,  4 Feb 2013 07:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpDvoVcK-zv5 for ; Mon,  4 Feb 2013 07:14:13 -0800 (PST)
Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2121F8818 for ; Mon,  4 Feb 2013 07:14:13 -0800 (PST)
Received: by mail-da0-f54.google.com with SMTP id n2so2689065dad.13 for ; Mon, 04 Feb 2013 07:14:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version; bh=P7HeY9V8slKcECvPgqo4jrYXFTwgbNLteT9CJ+1hLTM=; b=XJXEfBIjNihJ5kXF7HrjCbxtyuFoAiGNNENzVTQDAUUWRwB3MB+WwJUFCwyv0P6gcF /ZgjvvnslZDb78inEmGuqwrZ3Vjm8RGUjrRAvAu92IxcOGuAX9JebEP6f6Voc8owxtTv VFxwv4Hyv41RAtUdlS5IoNPg0svK9rs3PPHdO4JHy6MsRarekrRjTCRcuk5R9HCFFJ4e Z5q59+3sTJdA6RFFz/cIr29AMYpvB4XgyMDUh7BZIo2SCbQddi0czDOQ6HWoF07mfw59 aKHz2GK98+h11nK/GB4tzufOGGl7a/13hRH84so+nON2nDB1K217eBWo1e4tLg9KePt+ ZG4w==
X-Received: by 10.66.86.101 with SMTP id o5mr54067840paz.15.1359990850670; Mon, 04 Feb 2013 07:14:10 -0800 (PST)
Received: from [10.214.199.165] (mobile-166-147-083-230.mycingular.net. [166.147.83.230]) by mx.google.com with ESMTPS id o5sm22083735pay.5.2013.02.04.07.14.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 07:14:09 -0800 (PST)
References: 
From: Mubmar 
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPhone Mail (10A523)
In-Reply-To: 
Message-Id: 
Date: Mon, 4 Feb 2013 07:14:04 -0800
To: "rtcweb@ietf.org" 
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: [rtcweb] rtcweb Digest, Vol 24, Issue 7
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:14:13 -0000

Sent from my iPhone

On Feb 3, 2013, at 12:00 PM, rtcweb-request@ietf.org wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
> 
> 
> 
> Send rtcweb mailing list submissions to
>    rtcweb@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://www.ietf.org/mailman/listinfo/rtcweb
> or, via email, send a message with subject or body 'help' to
>    rtcweb-request@ietf.org
> 
> You can reach the person managing the list at
>    rtcweb-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of rtcweb digest..."
> Today's Topics:
> 
>   1. Re: Revealing IP addresses (Re: Review of
>      draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
>      (Eric Rescorla)
>   2. Re: Revealing IP addresses (Re: Review of
>      draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
>      (Eric Burger)
>   3. Re: WG Last Call:
>      draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text
>      (Martin Thomson)
>   4. Re: WG Last Call:
>      draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text
>      (Bernard Aboba)
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From pkyzivat@alum.mit.edu  Mon Feb  4 07:18:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0C721F88B1 for ; Mon,  4 Feb 2013 07:18:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE4ipUcXIWtS for ; Mon,  4 Feb 2013 07:18:21 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 6945721F8818 for ; Mon,  4 Feb 2013 07:18:21 -0800 (PST)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id wDSq1k0011GhbT854FJL3t; Mon, 04 Feb 2013 15:18:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:c889:2409:dacd:ae16]) by omta07.westchester.pa.mail.comcast.net with comcast id wFJJ1k00E0tAQKE3TFJJ3f; Mon, 04 Feb 2013 15:18:20 +0000
Message-ID: <510FD138.7050005@alum.mit.edu>
Date: Mon, 04 Feb 2013 10:18:16 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hadriel Kaplan 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359991100; bh=2+R7aUqI4i0lQt1izhyx9S8cRg0W25tQgJhsPJJ6P7U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WmspQnXQwzek8XgAL4RCG2tKyu0jbL73W8UL0jfmAHVY7JgLkVAakxM/6HLGW2ey0 T6FOoH9K7r40uVcD1wl2RHikUS/xPLUcQQMx/AEacNcsDArU12GGY22o68tO4sMj/O k/x1TqXsi6VEiDw1Uz/xvND8/Jo+a9yObEEekI3haxHvugfMPlO6saZqctbA9X8Zul AlGklnmdy70hFgs/zQELF4ybhB5cCcL9TGgTFsJ1qpco3iKTli7lXWBq/7+MdtLtwb Vt7x0YQ1hClONshFZYge51V2hxKQmEp8ykCqdekFHnsghsQtE72AB+H7k+Mtn8YTcy 1/EV095ppidnA==
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [rtcweb] February Interim registration and logistics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:18:22 -0000

Is there a detailed agenda, with actual start times?
I've looked but can't find one.

	Thanks,
	Paul

On 1/18/13 2:33 PM, Hadriel Kaplan wrote:
> Howdy,
> We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at our Corporate Galactic Headquarters in Bedford, Massachusetts.
>
> Please register at the following page if you plan to attend:
> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c
>
> The logistics/venue info page is here:
> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics
>
> You should NOT register if you're only going to attend remotely.  Details for remote participation will be sent out later on the relevant mailing lists.
>
> We hope to see you here!
> And bring warm clothing - it's slightly chilly. ;)
>
> -hadriel
>
> p.s. We've tested the registration page on several browsers and it works generally, except for on Lynx, Links, or Elinks. (Lynx and Links because they don't support Javascript, but why it doesn't work on Elinks w/SpiderMonkey I haven't looked into)  The logistics page seems to work on all browsers.
> :)
>
>
>


From vvucetic@cisco.com  Mon Feb  4 07:34:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7521F8694; Mon,  4 Feb 2013 07:34:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 VkmV0PDlxaLD; Mon,  4 Feb 2013 07:34:13 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCD821F86D3; Mon,  4 Feb 2013 07:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1731; q=dns/txt; s=iport; t=1359992050; x=1361201650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iLXdfWR6UHnBUePl/y6MFDWTM44pAe4MaseVrW4hL68=; b=AGzvUBNDvRIrQym7VR0GRkiJeyVKJgUlWDgYfbKE/ZbToC314oUroYVd TQ5i0/azYEATP4Hb5FKY+PcLSdGMR6IyMZNd+6w01QdKXHvAgodc+Ax8N i4MkrSujH0B/jvVkDem5lqicFizbdFvfkBLpytOn3a90itsMLz0MumsOH U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFACnUD1GtJV2a/2dsb2JhbABFDr8sFnOCHwEBAQQBAQE3NAsMBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCIgJDLtZjSqDR2EDlzyPNII+PoFvNQ
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; d="scan'208";a="172764601"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 04 Feb 2013 15:34:10 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r14FY9si018980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Feb 2013 15:34:09 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.138]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 09:34:09 -0600
From: "Vojislav Vucetic (vvucetic)" 
To: Paul Kyzivat , Hadriel Kaplan 
Thread-Topic: [rtcweb] February Interim registration and logistics
Thread-Index: AQHOAurjXno7/EtQakuKaNa0T35yUphp1CDQ
Date: Mon, 4 Feb 2013 15:34:09 +0000
Message-ID: <23E4AF2696DFB44BBAE64F13EF9B3779153400E3@xmb-aln-x11.cisco.com>
References:  <510FD138.7050005@alum.mit.edu>
In-Reply-To: <510FD138.7050005@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.98.76.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [rtcweb] February Interim registration and logistics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:34:13 -0000

What about the remote access to the sessions?

Thank you,

vvv

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Paul Kyzivat
Sent: Monday, February 04, 2013 10:18 AM
To: Hadriel Kaplan
Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)
Subject: Re: [rtcweb] February Interim registration and logistics

Is there a detailed agenda, with actual start times?
I've looked but can't find one.

	Thanks,
	Paul

On 1/18/13 2:33 PM, Hadriel Kaplan wrote:
> Howdy,
> We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF =
MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at =
our Corporate Galactic Headquarters in Bedford, Massachusetts.
>
> Please register at the following page if you plan to attend:
> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c
>
> The logistics/venue info page is here:
> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics
>
> You should NOT register if you're only going to attend remotely.  Details=
 for remote participation will be sent out later on the relevant mailing li=
sts.
>
> We hope to see you here!
> And bring warm clothing - it's slightly chilly. ;)
>
> -hadriel
>
> p.s. We've tested the registration page on several browsers and it works =
generally, except for on Lynx, Links, or Elinks. (Lynx and Links because th=
ey don't support Javascript, but why it doesn't work on Elinks w/SpiderMonk=
ey I haven't looked into)  The logistics page seems to work on all browsers=
.
> :)
>
>
>

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

From ron.even.tlv@gmail.com  Mon Feb  4 08:56:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11FC21F88A6; Mon,  4 Feb 2013 08:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.513
X-Spam-Level: 
X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.886,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=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 tvX4CSAfI6EN; Mon,  4 Feb 2013 08:56:32 -0800 (PST)
Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1A221F8648; Mon,  4 Feb 2013 08:56:31 -0800 (PST)
Received: by mail-ea0-f173.google.com with SMTP id i1so3041034eaa.32 for ; Mon, 04 Feb 2013 08:56:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=hKkfxuYKcIOM9LH5T9rZ6R9IelUd1J9CRrFd1aBUsHY=; b=uFeza5dmSNYuT2kHGr0PvcypBjPgoQ8QOGgIBbwlkBUJyFYxZ53jZWg87Fathr+2jj hYVqFZdU0J/qGdFj7IAIVptvNVeZzM1/o+P+ULvF6xMdTUsd/FJgbcYuPHDU7m7Bqn2J 58n7nbSSSDPoMFlOUYvNUMO9Q71ixw+NZ44fz6O7/i9Rrf3ibivcrzvJGVK0GmTOA+cd +qrAFNAsJY5A1PaI45XVvB+W15pLNjijyCh5fOhEp88wR87r0E2M8a/dFuN8NmTTJ3fr 2RiweE4Q0rjdstdcVoX8ayFjLfkQyvsY/0DcTThCGGHzD1lQrzxMKP5ilro7b8qYUrTc JITQ==
X-Received: by 10.14.215.131 with SMTP id e3mr9666855eep.32.1359996991002; Mon, 04 Feb 2013 08:56:31 -0800 (PST)
Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id t4sm28167973eel.0.2013.02.04.08.56.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 08:56:29 -0800 (PST)
From: "Roni Even" 
To: , 
References: <5108ED00.9090605@ericsson.com>
In-Reply-To: <5108ED00.9090605@ericsson.com>
Date: Mon, 4 Feb 2013 18:53:36 +0200
Message-ID: <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQKyoQBbe7ZUzYPbSQyQEvL2IxXs9pagrVNw
Content-Language: en-us
Cc: rtcweb@ietf.org, mmusic@ietf.org
Subject: Re: [rtcweb] Boston meeting agenda
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 16:56:33 -0000

Hi,
Is there a final agenda with time schedule. There is no relation between the
agenda here and i=the one for mmusic and rtcweb in the reference.
I would like to attend from remote and since there is time difference it
will be helpful to plan ahead.
Thanks
Roni Even who will try to attend from remote being 7 hours ahead of Boston

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Stefan H?kansson LK
Sent: 30 January, 2013 11:51 AM
To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org;
public-media-capture@w3.org
Subject: [rtcweb] Boston meeting agenda

All,

below is a merged agenda covering both W3C and IETF parts of the meeting.
Details are likely to change - the main message is that W3C meetings will be
before lunch, and IETF after. Before lunch could mean
8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A hard
stop is planned for 17:00 on Feb 7th as many have planes to catch.

(The sources used to assemble the agenda below are the W3C meeting wiki's,
[1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]).

--Stefan (for all involved chairs)

Feb 5th
=======
Morning session: W3C Media Capture TF
-------------------------------------
* device enumeration
* error handling
* "immediate stream" gUM
* Resource reservation

Afternoon session: IETF mmusic and rtcweb WGs
---------------------------------------------
* Multiple Flow SDP representation
* SDP for Data channels

Feb 6th
=======
Morning session: W3C Media Capture TF + WebRTC WG
-------------------------------------------------
* Identity aspects of MediaStreams (MediaCap)
* Settings/constraints (MediaCap)
* Recording (MediaCap)
* Call flow (WebRTC)

Afternoon session: IETF mmusic and rtcweb WGs
---------------------------------------------
* SDP Grouping (Bundle/MMT/one-rtp)
* Mapping stream/track label concepts to SDP identifiers

Feb 7th
=======
Morning session: W3C WebRTC WG
------------------------------
* MediaStream and MediaStreamTrack - SDP interface
* Error handling
* Data channel
* Stats

Afternoon session: IETF mmusic and rtcweb WGs
---------------------------------------------
* Trickle ICE
* JSEP

[1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013
[2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013
[3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html




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


From matthew.kaufman@skype.net  Mon Feb  4 09:56:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B4021F8AB0 for ; Mon,  4 Feb 2013 09:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 f0BMwr-Eypmn for ; Mon,  4 Feb 2013 09:56:52 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 22CC721F8AA3 for ; Mon,  4 Feb 2013 09:56:51 -0800 (PST)
Received: from BY2FFO11FD010.protection.gbl (10.1.15.200) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.609.9; Mon, 4 Feb 2013 17:56:48 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Mon, 4 Feb 2013 17:56:48 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.197]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 4 Feb 2013 17:56:27 +0000
From: "Matthew Kaufman (SKYPE)" 
To: Eric Burger , Eric Rescorla 
Thread-Topic: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
Thread-Index: AQHOAsW/xiVFfEc0KEqEsvGiX+ANRphp+lzQ
Date: Mon, 4 Feb 2013 17:56:26 +0000
Message-ID: 
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>  <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52314002)(51704002)(13464002)(199002)(189002)(24454001)(377454001)(47736001)(49866001)(4396001)(74502001)(50986001)(50466001)(31966008)(77982001)(44976002)(47446002)(47976001)(55846006)(79102001)(23726001)(5343635001)(56816002)(47776003)(53806001)(33656001)(76482001)(46406002)(59766001)(5343655001)(63696002)(20776003)(56776001)(51856001)(46102001)(74662001)(54316002)(54356001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:3; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07473990A5
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of	draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 17:56:53 -0000

I see two possible readings (either or both of them might be useful):

1. The browser must have a way for its user to force the use of TURN server=
s (and this is only useful if the user also provides the address and creden=
tials for the TURN servers) for transmission of media.

2. The browser must have an API that keeps some kinds of candidates from be=
ing included in the SDP the API generates.

#1 seems like a very useful thing to require for users who might actually c=
are about their privacy, but I don't think that requirement belongs in an I=
ETF document but rather the W3C requirements TR for WEBRTC, that appears to=
 have not even been started.

#2 seems highly questionable to me, due to the large number of failure mode=
s in both the interpretation of the spec and the ability to circumvent the =
intent...

For #2 do you mean "API flag to prevent local candidates from being include=
d" or "API flag to prevent server-reflexive STUN-learned candidates from be=
ing included" or both?

For #2 how do you propose a malicious application or page injection not sim=
ply change the flag?

For #2 why can't the same behavior be accomplished by including all the can=
didates in the SDP and then letting the JavaScript remove the "dangerous" c=
andidates before sending the SDP to the server?

For #2 why can't the same behavior be accomplished by including all the can=
didates in the SDP, sending it to the server (which you must trust anyway, =
as it also can change the flag itself *or* derive your IP address by lookin=
g at where you load pages from), and having the server remove the "dangerou=
s" candidates before sending them on to the far client?

Matthew Kaufman
=20

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Eric Burger
Sent: Monday, February 4, 2013 2:53 AM
To: Eric Rescorla
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcw=
eb-use-cases-and-requirements-10 (Part II))

Under what circumstances would it be up to the Web server to decide to make=
 the client interaction quasi-anonymous? Would that not be a entirely up to=
 and the responsibility of the client? By definition, the Web server is not=
 anonymous -- the user had to reach it somehow to get the page in the first=
 place. Likewise, it is well within the power of the server to obfuscate it=
s media address. It is quite likely media is NOT coming from the same IP ad=
dress as the Web page under normal circumstances, so the server has built-i=
n opportunities to obfuscate its address. Conversely, it is well within the=
 capabilities of the browser to figure out how to obfuscate its media addre=
ss. More importantly, I have yet to hear a cogent use case for the server s=
aying, "I want this interaction to not have IP addresses *TO PROTECT YOU*."=
 If you are in a scenario where you need protection, you cannot depend on t=
he server. You must depend on yourself, which means you will have a browser=
 that will protect you. Moreover, will not a bad server simply always tell =
all browsers it connects with to open lots of anonymity relays to DDoS the =
relays? Saying we want to build something that is only sometimes useful and=
 can only be useful if we trust all sides to do the right thing does not so=
und very useful.

Am I missing something here?

On Feb 3, 2013, at 6:48 PM, Eric Rescorla  wrote:

>=20
>=20
> On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger =
 wrote:
> To be clear, I think ekr's formulation is the best:
> > 1. If you don't want the server learning your global IP, you need to us=
e Tor or the like.
>=20
> To me, this means it is totally orthogonal to RTCweb. If you want to use =
Tor, a TURN server, an ALG, or foo, that is up to you. That does not impact=
 the protocol.
>=20
> That's certainly what I meant to be saying, with the small caveat that=20
> if you are using media relays (e.g., TURN) they are supposed to be=20
> reflected in ICE candidate lines.
>=20
>=20
> > 2. I would suggest that it is simplest to divide the world into host=20
> > addresses, server/peer reflexive, and relayed and say that the=20
> > requirement is that the browser must be able to send packets without=20
> > revealing either of the former two, but that it is not a requirement th=
at it be able to do so in the face of an adversarial server.
> And this is the most reasonable. I guess the concern is we will forget al=
l of this list discussion, and someone will require hard-coded endpoint IP =
addresses in the protocol, which is what sunk SIP in the early days.
>=20
> Inline...
>=20
> On Feb 3, 2013, at 1:32 PM, Eric Rescorla  wrote:
>=20
> > On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric =
 wrote:
> > Is what we are really asking for is the ability of the protocol to be T=
OR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one pa=
rticular anonymity network or another into the RTCweb protocol suite.
> >
> > I'm certainly not suggesting that.
> >
> >
> > On the one hand, with my purist hat on, saying it is a requirement to m=
ake sure we do not need to have end-to-end connectivity smells a bit weird.
> >
> >> I don't understand this... I don't think anyone is suggesting that.
>=20
> Saying we will bake into the protocol the REQUIREMENT that it support goo=
d or bad boxes in the middle of the network does not sound like the end-to-=
end Internet. It sounds more like IMS.
>=20
> Which requirement do you think suggests that? I certainly favor=20
> requirements that we be able to work in the face of as many known=20
> classes of intermediaries (NATs, firewalls, etc. as possible.) I mean,=20
> isn't that the point of ICE supporting TURN and other types of relays?
>=20
> Is there something wrong with this? Do you think people are suggesting=20
> some other requirement?
>=20
>=20
> > On the other hand, with my practical hat on, saying it is a requirement=
 to make sure the protocol works in situations that are NOT the Internet (N=
ATs, a need for an overlay privacy network, etc.) seems like a good thing t=
o do.
> >
> >> As far as I know, the only novel requirement here is that there be=20
> >> a way for Web application to tell the browser to solely use relayed=20
> >> addresses/candidates (and hopefully thus not reveal the user's=20
> >> actual location) when communicating with the peer. There is of=20
> >> course a requirement to be able to work when behind NATs but that is a=
 functional requirement, not an anonymity one.
>=20
> That is asking an awful lot of an application. Moreover, as the cat-and-m=
ouse game of anonymous application communication is ever evolving, I would =
challenge how meaningful it is to specify a Hidden Bit or Anonymous Bit in =
the protocol. I would offer that will work as well as the Evil Bit.
>=20
> I really am not following what you are saying here about a "hidden bit"?
>=20
> There is a very specific requirement being suggested here, namely that=20
> applications should be able to instruct browsers not to use host or=20
> srvflx candidates. This is neither a hidden bit, nor an anonymous bit.=20
> Rather, it is a mechanism designed to allow the site, *if it wishes*=20
> to offer a calling service that doesn't immediately reveal the=20
> caller's location. This isn't a complete anonymity service against=20
> sophisticated attackers. For that you need something like Tor. Rather,=20
> it's an easy-to-implement measure that offers location protection against=
 a (relatively common) class of limited attackers.
>=20
> What is it you object to about this requirement?
>=20
> -Ekr
>=20


From btv1==7476154b17d==HKaplan@acmepacket.com  Mon Feb  4 10:25:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE0F21F8A64 for ; Mon,  4 Feb 2013 10:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level: 
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550,  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 b8ZjXCE9fsU6 for ; Mon,  4 Feb 2013 10:25:33 -0800 (PST)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 65DED21F8A52 for ; Mon,  4 Feb 2013 10:25:33 -0800 (PST)
X-ASG-Debug-ID: 1360002326-03fc207afd19e290001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id 4ekYM4DyNmVRHO9F (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Mon, 04 Feb 2013 13:25:26 -0500 (EST)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Mon, 4 Feb 2013 13:25:26 -0500
From: Hadriel Kaplan 
To: Paul Kyzivat 
Thread-Topic: February Interim registration and logistics
X-ASG-Orig-Subj: Re: February Interim registration and logistics
Thread-Index: AQHOAwUAJlsqwRqOpESjXFiKxPyc6Q==
Date: Mon, 4 Feb 2013 18:25:26 +0000
Message-ID: <5FC802B8-DE25-4B3C-87D7-3382B1FCD1D6@acmepacket.com>
References:  <510FD138.7050005@alum.mit.edu>
In-Reply-To: <510FD138.7050005@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1E4E760217CE284C998EB10E063089A0@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1360002326
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.121804 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [rtcweb] February Interim registration and logistics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 18:26:51 -0000

Hi Paul,
An email confirmation and with some logistics info was just sent out.
The breakfast starts at 8am each day, with the meeting starting at 8:30-ish=
.
But I'm not the one handling detailed meeting agenda with presentations and=
 stuff - I assumed that was up to the Chairs.
The last one I saw was this one:
http://www.ietf.org/mail-archive/web/mmusic/current/msg10168.html

-hadriel


On Feb 4, 2013, at 10:18 AM, Paul Kyzivat  wrote:

> Is there a detailed agenda, with actual start times?
> I've looked but can't find one.
>=20
> 	Thanks,
> 	Paul
>=20
> On 1/18/13 2:33 PM, Hadriel Kaplan wrote:
>> Howdy,
>> We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF=
 MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at=
 our Corporate Galactic Headquarters in Bedford, Massachusetts.
>>=20
>> Please register at the following page if you plan to attend:
>> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c
>>=20
>> The logistics/venue info page is here:
>> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics
>>=20
>> You should NOT register if you're only going to attend remotely.  Detail=
s for remote participation will be sent out later on the relevant mailing l=
ists.
>>=20
>> We hope to see you here!
>> And bring warm clothing - it's slightly chilly. ;)
>>=20
>> -hadriel
>>=20
>> p.s. We've tested the registration page on several browsers and it works=
 generally, except for on Lynx, Links, or Elinks. (Lynx and Links because t=
hey don't support Javascript, but why it doesn't work on Elinks w/SpiderMon=
key I haven't looked into)  The logistics page seems to work on all browser=
s.
>> :)
>>=20
>>=20
>>=20
>=20


From spromano@unina.it  Mon Feb  4 10:40:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34621F8A8E; Mon,  4 Feb 2013 10:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.718
X-Spam-Level: 
X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 uHb4P+sb63Mq; Mon,  4 Feb 2013 10:40:12 -0800 (PST)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53021F8A66; Mon,  4 Feb 2013 10:40:12 -0800 (PST)
Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r14IduXM012752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Feb 2013 19:39:56 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33"
From: Simon Pietro Romano 
In-Reply-To: <23E4AF2696DFB44BBAE64F13EF9B3779153400E3@xmb-aln-x11.cisco.com>
Date: Mon, 4 Feb 2013 19:39:56 +0100
Message-Id: <767E45D1-8A23-4236-AD56-D907187F4F6F@unina.it>
References:  <510FD138.7050005@alum.mit.edu> <23E4AF2696DFB44BBAE64F13EF9B3779153400E3@xmb-aln-x11.cisco.com>
To: Vojislav Vucetic (vvucetic) 
X-Mailer: Apple Mail (2.1283)
Cc: rtcweb@ietf.org, "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [rtcweb] February Interim registration and logistics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 18:40:13 -0000

--Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

+1 for info about remote participation.

Thanks,

Simon

Il giorno 04/feb/2013, alle ore 16:34, Vojislav Vucetic (vvucetic) ha =
scritto:

> What about the remote access to the sessions?
>=20
> Thank you,
>=20
> vvv
>=20
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On =
Behalf Of Paul Kyzivat
> Sent: Monday, February 04, 2013 10:18 AM
> To: Hadriel Kaplan
> Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)
> Subject: Re: [rtcweb] February Interim registration and logistics
>=20
> Is there a detailed agenda, with actual start times?
> I've looked but can't find one.
>=20
> 	Thanks,
> 	Paul
>=20
> On 1/18/13 2:33 PM, Hadriel Kaplan wrote:
>> Howdy,
>> We're pleased to host the upcoming interim meetings of IETF RTCWeb, =
IETF MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, =
2013, at our Corporate Galactic Headquarters in Bedford, Massachusetts.
>>=20
>> Please register at the following page if you plan to attend:
>> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c
>>=20
>> The logistics/venue info page is here:
>> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics
>>=20
>> You should NOT register if you're only going to attend remotely.  =
Details for remote participation will be sent out later on the relevant =
mailing lists.
>>=20
>> We hope to see you here!
>> And bring warm clothing - it's slightly chilly. ;)
>>=20
>> -hadriel
>>=20
>> p.s. We've tested the registration page on several browsers and it =
works generally, except for on Lynx, Links, or Elinks. (Lynx and Links =
because they don't support Javascript, but why it doesn't work on Elinks =
w/SpiderMonkey I haven't looked into)  The logistics page seems to work =
on all browsers.
>> :)
>>=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

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico =
II
                		     Computer Engineering Department=20
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

		    <>. =
Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            =
(   )
			                                  \_)          ) =
/
                                                                       =
(_/






--Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

+1 =
for info about remote =
participation.

Thanks,

Simon

Il giorno 04/feb/2013, alle ore 16:34, Vojislav =
Vucetic (vvucetic) ha scritto:

What =
about the remote access to the sessions?

Thank =
you,

vvv

-----Original Message-----
From: rtcweb-bounces@ietf.org =
[mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: =
Monday, February 04, 2013 10:18 AM
To: Hadriel Kaplan
Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)
Subject: =
Re: [rtcweb] February Interim registration and logistics

Is there =
a detailed agenda, with actual start times?
I've looked but can't =
find one.

=
	Thanks,
	Paul

On 1/18/13 2:33 PM, =
Hadriel Kaplan wrote:
Howdy,
We're =
pleased to host the upcoming interim meetings of IETF RTCWeb, IETF =
MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, =
at our Corporate Galactic Headquarters in Bedford, =
Massachusetts.

Please register =
at the following page if you plan to attend:
http:=
//info.acmepacket.com/acme-packet-hosting-ietf-and-w3c

The =
logistics/venue info page is here:
http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics=


You should NOT =
register if you're only going to attend remotely.  Details for =
remote participation will be sent out later on the relevant mailing =
lists.

We hope to see =
you here!
And bring warm =
clothing - it's slightly chilly. ;)

-hadriel

p.s. We've =
tested the registration page on several browsers and it works generally, =
except for on Lynx, Links, or Elinks. (Lynx and Links because they don't =
support Javascript, but why it doesn't work on Elinks w/SpiderMonkey I =
haven't looked into)  The logistics page seems to work on all =
browsers.
:)




_______________________________________=
________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or=
g/mailman/listinfo/rtcweb
_____________________________________________=
__
rtcweb mailing =
list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



      =
               				=
	   =
    _\\|//_
          =
                 				=
      ( O-O )
  =
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =
  				=
Simon Pietro Romano
          =
    Universita' di Napoli =
Federico II
              =
  	=
	     Computer Engineering =
Department 
	         =
    Phone: +39 081 7683823 -- Fax: +39 081 =
7683816
              =
                    =
         e-mail: spromano@unina.it

		=
    <<Molti mi dicono che lo scoraggiamento =CB =
l'alibi degli 
		   =
 idioti. Ci rifletto un istante; e mi scoraggio>>. =
Magritte.
             =
  			=
                  =
   oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   =
)~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
				=
	                =
 \ (            (   =
)
	=
		              =
                    =
\_)          ) /
      =
                    =
                    =
                    =
     (_/








=

--Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33--

From dwing@cisco.com  Mon Feb  4 12:27:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18E821F84B9 for ; Mon,  4 Feb 2013 12:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.98
X-Spam-Level: 
X-Spam-Status: No, score=-109.98 tagged_above=-999 required=5 tests=[AWL=0.619, 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 ikM9ZXRDcS92 for ; Mon,  4 Feb 2013 12:27:27 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BD52421F8499 for ; Mon,  4 Feb 2013 12:27:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8711; q=dns/txt; s=iport; t=1360009647; x=1361219247; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=p/zehNqrIe+968cXYcf1J7+lCMNgsuPcjCaCP+mRkjI=; b=lY/4Jw4sGmEH+RGcepVNPNC5ntV3lhDlUims8u3PNlz8/z+t1QcoUvQd CbFe0cZ15SgqbqeEaekNbX/BpT6lbUeVOFhl0/jOUGTwr6X4acafWRqDD kXJ7Q09epzIvFQeDTcGtwdYggdPRoTeentIDMTaFlH9XftuBeSo/AmYqy A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAMkYEFGrRDoJ/2dsb2JhbABEAb9AFnOCHwEBAQQBAQEFAjAzAQsMAQMCCREEAQEBGQIIBAcZDh8JCAIEARILBYgADbtEBI0kB4EPAYMXA4hmhSGIGJBRgx2BRQ
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="68128478"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 04 Feb 2013 20:27:27 +0000
Received: from DWINGWS01 ([10.156.17.137]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r14KRRcu020032; Mon, 4 Feb 2013 20:27:27 GMT
From: "Dan Wing" 
To: "'Matthew Kaufman \(SKYPE\)'" , "'Eric Burger'" , "'Eric Rescorla'" 
References: <50F97303.4070906@ericsson.com>				<5109265F.6040106@ericsson.com>		<510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no>	<510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no>	<510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>		<479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>		<984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>		 
In-Reply-To: 
Date: Mon, 4 Feb 2013 12:27:27 -0800
Message-ID: <048e01ce0316$0c4c8bb0$24e5a310$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJQIOHSeuqgYht2zObTrgilJ3dHYwNtiWVQAjnqTgwCqIqjJQGepyyzAhNOBNcBqObJUAKBeO/CApnbdfQB9xlSOQIbzvF8AY4rltEBtZ4aPAM37MtxAtlx4rMCejsExAIay3gKA1/R1CEB6D9/W5YVjl/w
Content-Language: en-us
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review	of	draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:27:29 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Matthew Kaufman (SKYPE)
> Sent: Monday, February 04, 2013 9:56 AM
> To: Eric Burger; Eric Rescorla
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-
> rtcweb-use-cases-and-requirements-10 (Part II))
> 
> I see two possible readings (either or both of them might be useful):
> 
> 1. The browser must have a way for its user to force the use of TURN
> servers (and this is only useful if the user also provides the address
> and credentials for the TURN servers) for transmission of media.
> 
> 2. The browser must have an API that keeps some kinds of candidates from
> being included in the SDP the API generates.

That is one way to implement it.  Another way to is an additional 
checkbox "Always use TURN servers (for privacy)" in the same place
the TURN servers are configured, *roughly* similar to how 
FTP/HTTP proxies are configured today.

-d


> #1 seems like a very useful thing to require for users who might
> actually care about their privacy, but I don't think that requirement
> belongs in an IETF document but rather the W3C requirements TR for
> WEBRTC, that appears to have not even been started.
> 
> #2 seems highly questionable to me, due to the large number of failure
> modes in both the interpretation of the spec and the ability to
> circumvent the intent...
> 
> For #2 do you mean "API flag to prevent local candidates from being
> included" or "API flag to prevent server-reflexive STUN-learned
> candidates from being included" or both?
> 
> For #2 how do you propose a malicious application or page injection not
> simply change the flag?
> 
> For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP and then letting the JavaScript remove the
> "dangerous" candidates before sending the SDP to the server?
> 
> For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP, sending it to the server (which you must trust
> anyway, as it also can change the flag itself *or* derive your IP
> address by looking at where you load pages from), and having the server
> remove the "dangerous" candidates before sending them on to the far
> client?
> 
> Matthew Kaufman
> 
> 
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Eric Burger
> Sent: Monday, February 4, 2013 2:53 AM
> To: Eric Rescorla
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-
> rtcweb-use-cases-and-requirements-10 (Part II))
> 
> Under what circumstances would it be up to the Web server to decide to
> make the client interaction quasi-anonymous? Would that not be a
> entirely up to and the responsibility of the client? By definition, the
> Web server is not anonymous -- the user had to reach it somehow to get
> the page in the first place. Likewise, it is well within the power of
> the server to obfuscate its media address. It is quite likely media is
> NOT coming from the same IP address as the Web page under normal
> circumstances, so the server has built-in opportunities to obfuscate its
> address. Conversely, it is well within the capabilities of the browser
> to figure out how to obfuscate its media address. More importantly, I
> have yet to hear a cogent use case for the server saying, "I want this
> interaction to not have IP addresses *TO PROTECT YOU*." If you are in a
> scenario where you need protection, you cannot depend on the server. You
> must depend on yourself, which means you will have a browser that will
> prot  ect you. Moreover, will not a bad server simply always tell all
> browsers it connects with to open lots of anonymity relays to DDoS the
> relays? Saying we want to build something that is only sometimes useful
> and can only be useful if we trust all sides to do the right thing does
> not sound very useful.
> 
> Am I missing something here?
> 
> On Feb 3, 2013, at 6:48 PM, Eric Rescorla  wrote:
> 
> >
> >
> > On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger
>  wrote:
> > To be clear, I think ekr's formulation is the best:
> > > 1. If you don't want the server learning your global IP, you need to
> use Tor or the like.
> >
> > To me, this means it is totally orthogonal to RTCweb. If you want to
> use Tor, a TURN server, an ALG, or foo, that is up to you. That does not
> impact the protocol.
> >
> > That's certainly what I meant to be saying, with the small caveat that
> > if you are using media relays (e.g., TURN) they are supposed to be
> > reflected in ICE candidate lines.
> >
> >
> > > 2. I would suggest that it is simplest to divide the world into host
> > > addresses, server/peer reflexive, and relayed and say that the
> > > requirement is that the browser must be able to send packets without
> > > revealing either of the former two, but that it is not a requirement
> that it be able to do so in the face of an adversarial server.
> > And this is the most reasonable. I guess the concern is we will forget
> all of this list discussion, and someone will require hard-coded
> endpoint IP addresses in the protocol, which is what sunk SIP in the
> early days.
> >
> > Inline...
> >
> > On Feb 3, 2013, at 1:32 PM, Eric Rescorla  wrote:
> >
> > > On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric
>  wrote:
> > > Is what we are really asking for is the ability of the protocol to
> be TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in
> one particular anonymity network or another into the RTCweb protocol
> suite.
> > >
> > > I'm certainly not suggesting that.
> > >
> > >
> > > On the one hand, with my purist hat on, saying it is a requirement
> to make sure we do not need to have end-to-end connectivity smells a bit
> weird.
> > >
> > >> I don't understand this... I don't think anyone is suggesting that.
> >
> > Saying we will bake into the protocol the REQUIREMENT that it support
> good or bad boxes in the middle of the network does not sound like the
> end-to-end Internet. It sounds more like IMS.
> >
> > Which requirement do you think suggests that? I certainly favor
> > requirements that we be able to work in the face of as many known
> > classes of intermediaries (NATs, firewalls, etc. as possible.) I mean,
> > isn't that the point of ICE supporting TURN and other types of relays?
> >
> > Is there something wrong with this? Do you think people are suggesting
> > some other requirement?
> >
> >
> > > On the other hand, with my practical hat on, saying it is a
> requirement to make sure the protocol works in situations that are NOT
> the Internet (NATs, a need for an overlay privacy network, etc.) seems
> like a good thing to do.
> > >
> > >> As far as I know, the only novel requirement here is that there be
> > >> a way for Web application to tell the browser to solely use relayed
> > >> addresses/candidates (and hopefully thus not reveal the user's
> > >> actual location) when communicating with the peer. There is of
> > >> course a requirement to be able to work when behind NATs but that
> is a functional requirement, not an anonymity one.
> >
> > That is asking an awful lot of an application. Moreover, as the cat-
> and-mouse game of anonymous application communication is ever evolving,
> I would challenge how meaningful it is to specify a Hidden Bit or
> Anonymous Bit in the protocol. I would offer that will work as well as
> the Evil Bit.
> >
> > I really am not following what you are saying here about a "hidden
> bit"?
> >
> > There is a very specific requirement being suggested here, namely that
> > applications should be able to instruct browsers not to use host or
> > srvflx candidates. This is neither a hidden bit, nor an anonymous bit.
> > Rather, it is a mechanism designed to allow the site, *if it wishes*
> > to offer a calling service that doesn't immediately reveal the
> > caller's location. This isn't a complete anonymity service against
> > sophisticated attackers. For that you need something like Tor. Rather,
> > it's an easy-to-implement measure that offers location protection
> against a (relatively common) class of limited attackers.
> >
> > What is it you object to about this requirement?
> >
> > -Ekr
> >
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From vvucetic@cisco.com  Mon Feb  4 12:53:09 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67421F8B48; Mon,  4 Feb 2013 12:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.18
X-Spam-Level: 
X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[AWL=-5.420,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837, UNPARSEABLE_RELAY=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 44qS+EZmUO5p; Mon,  4 Feb 2013 12:53:07 -0800 (PST)
Received: from WIN-CDPOO5N337C (gw.ntelia.co.kr [175.196.232.146]) by ietfa.amsl.com (Postfix) with ESMTP id E30D821F8B3A; Mon,  4 Feb 2013 12:53:06 -0800 (PST)
Received: from mail pickup service by WIN-CDPOO5N337C with Microsoft SMTPSVC;  Tue, 5 Feb 2013 05:52:56 +0900
Content-Transfer-Encoding: 7bit
Content-Language: en-US
x-sender: vvucetic@cisco.com
x-receiver: hongkee67@gmail.com
Received: from mail.ietf.org ([64.170.98.30]) by WIN-CDPOO5N337C with Microsoft SMTPSVC(7.5.7601.17514); Tue, 5 Feb 2013 05:52:50 +0900
Received: from ietfa.amsl.com (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id E97E121F85DC;Mon,  4 Feb 2013 12:52:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360011165; bh=h0X6woMvxmj+w4BWyoU2kJfffIdccImEKBWHilIYdaM=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=IDmZlfywabETr1b5NKZ8inzYB/VfPGqgPCwGgzVuRTcdBoX/yJttRNHGtTWG9/a75 G53BbKxZvzZPOJacAPVtzMR7sTVv7sBsauWP6wq0z4j7x7GLl1ETWxkTcHyAdQrrBa fKGtGE/CRecMkxz+YW3uizhXlEMkFwGmYjeWc0cg=
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id 95E7521F8694;Mon,  4 Feb 2013 07:34:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.30])by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id VkmV0PDlxaLD; Mon,  4 Feb 2013 07:34:13 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72])by ietfa.amsl.com (Postfix) with ESMTP id 7FCD821F86D3; Mon,  4 Feb 2013 07:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1731; q=dns/txt; s=iport;t=1359992050; x=1361201650; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-transfer-encoding:mime-version; bh=iLXdfWR6UHnBUePl/y6MFDWTM44pAe4MaseVrW4hL68=; b=AGzvUBNDvRIrQym7VR0GRkiJeyVKJgUlWDgYfbKE/ZbToC314oUroYVdTQ5i0/azYEATP4Hb5FKY+PcLSdGMR6IyMZNd+6w01QdKXHvAgodc+Ax8Ni4MkrSujH0B/jvVkDem5lqicFizbdFvfkBLpytOn3a90itsMLz0MumsOH U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFACnUD1GtJV2a/2dsb2JhbABFDr8sFnOCHwEBAQQBAQE3NAsMBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCIgJDLtZjSqDR2EDlzyPNII+PoFvNQ
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; d="scan'208";a="172764601"
Received: from rcdn-core-3.cisco.com ([173.37.93.154])by rcdn-iport-1.cisco.com with ESMTP; 04 Feb 2013 15:34:10 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78])by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r14FY9si018980(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Feb 2013 15:34:09 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.138]) byxhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 09:34:09 -0600
From: "Vojislav Vucetic (vvucetic)" 
To: "Paul Kyzivat" , "Hadriel Kaplan" 
Thread-Topic: [rtcweb] February Interim registration and logistics
Thread-Index: AQHOAurjXno7/EtQakuKaNa0T35yUphp1CDQ
Date: Mon, 4 Feb 2013 15:34:09 +0000
Message-ID: <1.657355dcbec592b63032@cisco.com>
References: <510FD138.7050005@alum.mit.edu>
In-Reply-To: <510FD138.7050005@alum.mit.edu>
Accept-Language: en-US
x-originating-ip: [10.98.76.137]
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 04 Feb 2013 12:52:30 -0800
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
X-OriginalArrivalTime: 04 Feb 2013 20:52:50.0657 (UTC) FILETIME=[986B7D10:01CE0319]
Content-Type: multipart/alternative; boundary="----=_NextPart_000_668A_1FDD79FA.445619C9"
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [rtcweb] [MMUSIC]  February Interim registration and logistics
X-BeenThere: rtcweb@ietf.org
List-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 Feb 2013 20:53:09 -0000

------=_NextPart_000_668A_1FDD79FA.445619C9
Content-Language: en-US
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

What about the remote access to the sessions?

Thank you,

vvv

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
 Paul Kyzivat
Sent: Monday, February 04, 2013 10:18 AM
To: Hadriel Kaplan
Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)
Subject: Re: [rtcweb] February Interim registration and logistics

Is there a detailed agenda, with actual start times?
I've looked but can't find one.

	Thanks,
	Paul

On 1/18/13 2:33 PM, Hadriel Kaplan wrote:
> Howdy,
> We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF
 MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at
 our Corporate Galactic Headquarters in Bedford, Massachusetts.
>
> Please register at the following page if you plan to attend:
> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c
>
> The logistics/venue info page is here:
> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics
>
> You should NOT register if you're only going to attend remotely.  Details
 for remote participation will be sent out later on the relevant mailing
 lists.
>
> We hope to see you here!
> And bring warm clothing - it's slightly chilly. ;)
>
> -hadriel
>
> p.s. We've tested the registration page on several browsers and it works
 generally, except for on Lynx, Links, or Elinks. (Lynx and Links because they
 don't support Javascript, but why it doesn't work on Elinks w/SpiderMonkey
 I haven't looked into)  The logistics page seems to work on all browsers.
> :)
>
>
>

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

------=_NextPart_000_668A_1FDD79FA.445619C9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What about the remote access to the sessions?





Thank you,





vvv





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


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Paul Kyzivat


Sent: Monday, February 04, 2013 10:18 AM


To: Hadriel Kaplan


Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)


Subject: Re: [rtcweb] February Interim registration and logistics





Is there a detailed agenda, with actual start times?


I've looked but can't find one.





	Thanks,


	Paul





On 1/18/13 2:33 PM, Hadriel Kaplan wrote:


> Howdy,


> We're pleased to host the upcoming interim meetings of IETF RTCWeb, IE=
TF MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, =
at our Corporate Galactic Headquarters in Bedford, Massachusetts.


>


> Please register at the following page if you plan to attend:


> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c


>


> The logistics/venue info page is here:


> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics


>


> You should NOT register if you're only going to attend remotely.  Deta=
ils for remote participation will be sent out later on the relevant mailing=
 lists.


>


> We hope to see you here!


> And bring warm clothing - it's slightly chilly. ;)


>


> -hadriel


>


> p.s. We've tested the registration page on several browsers and it wor=
ks generally, except for on Lynx, Links, or Elinks. (Lynx and Links because=
 they don't support Javascript, but why it doesn't work on Elinks w/SpiderM=
onkey I haven't looked into)  The logistics page seems to work on all brows=
ers.


> :)


>


>


>





_______________________________________________


rtcweb mailing list


rtcweb@ietf.org


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


_______________________________________________


mmusic mailing list


mmusic@ietf.org


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



------=_NextPart_000_668A_1FDD79FA.445619C9--

From btv1==7476154b17d==HKaplan@acmepacket.com  Mon Feb  4 13:11:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0FD21F8AB7 for ; Mon,  4 Feb 2013 13:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level: 
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302,  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 aMKM+w74hjN3 for ; Mon,  4 Feb 2013 13:11:28 -0800 (PST)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08B21F8949 for ; Mon,  4 Feb 2013 13:11:28 -0800 (PST)
X-ASG-Debug-ID: 1360012285-03fc207afd1ae330001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id q78lgcKI0DDrxMRP (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Mon, 04 Feb 2013 16:11:25 -0500 (EST)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Mon, 4 Feb 2013 16:11:25 -0500
From: Hadriel Kaplan 
To: "Vojislav Vucetic (vvucetic)" 
Thread-Topic: [MMUSIC] [rtcweb] February Interim registration and logistics
X-ASG-Orig-Subj: Re: [MMUSIC] [rtcweb] February Interim registration and logistics
Thread-Index: AQHOAxwwYQi1WyU/Z0me6zlI3nt9Sw==
Date: Mon, 4 Feb 2013 21:11:24 +0000
Message-ID: <7EDA53E2-625C-47E3-BFFE-77A450939B1C@acmepacket.com>
References: <510FD138.7050005@alum.mit.edu> <1.657355dcbec592b63032@cisco.com>
In-Reply-To: <1.657355dcbec592b63032@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <561FE227C9612D4F8E0A58ACA6CE1C7F@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1360012285
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.121816 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header
Cc: "fluffy@cisco.com \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [rtcweb] [MMUSIC]  February Interim registration and logistics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 21:11:29 -0000

It's a WebEx session, graciously offered/hosted by Cisco.  I haven't seen w=
hat the URL/dial-in info is for it yet.

-hadriel


On Feb 4, 2013, at 10:34 AM, Vojislav Vucetic (vvucetic)  wrote:

> What about the remote access to the sessions?=20
>=20
> Thank you,=20
>=20
> vvv=20
>=20
> -----Original Message-----=20
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of Paul Kyzivat=20
> Sent: Monday, February 04, 2013 10:18 AM=20
> To: Hadriel Kaplan=20
> Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)=20
> Subject: Re: [rtcweb] February Interim registration and logistics=20
>=20
> Is there a detailed agenda, with actual start times?=20
> I've looked but can't find one.=20
>=20
> Thanks,=20
> Paul=20
>=20
> On 1/18/13 2:33 PM, Hadriel Kaplan wrote:=20
> > Howdy,=20
> > We're pleased to host the upcoming interim meetings of IETF RTCWeb, IET=
F MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, a=
t our Corporate Galactic Headquarters in Bedford, Massachusetts.=20
> >=20
> > Please register at the following page if you plan to attend:=20
> > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c=20
> >=20
> > The logistics/venue info page is here:=20
> > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics=20
> >=20
> > You should NOT register if you're only going to attend remotely. Detail=
s for remote participation will be sent out later on the relevant mailing l=
ists.=20
> >=20
> > We hope to see you here!=20
> > And bring warm clothing - it's slightly chilly. ;)=20
> >=20
> > -hadriel=20
> >=20
> > p.s. We've tested the registration page on several browsers and it work=
s generally, except for on Lynx, Links, or Elinks. (Lynx and Links because =
they don't support Javascript, but why it doesn't work on Elinks w/SpiderMo=
nkey I haven't looked into) The logistics page seems to work on all browser=
s.=20
> > :)=20
> >=20
> >=20
> >=20
>=20
> _______________________________________________=20
> rtcweb mailing list=20
> rtcweb@ietf.org=20
> https://www.ietf.org/mailman/listinfo/rtcweb=20
> _______________________________________________=20
> mmusic mailing list=20
> mmusic@ietf.org=20
> https://www.ietf.org/mailman/listinfo/mmusic=20


From ekr@rtfm.com  Mon Feb  4 14:05:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3312121F8AF2 for ; Mon,  4 Feb 2013 14:05:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.203
X-Spam-Level: 
X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 KUAA+0t4B9ak for ; Mon,  4 Feb 2013 14:05:02 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0588921F8AD8 for ; Mon,  4 Feb 2013 14:05:01 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fr13so855104vbb.31 for ; Mon, 04 Feb 2013 14:05:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=VvfFBhzWfSBQeRwCL+X3KL7yALIEpYrDli9fZ/URbSk=; b=eR/xTg+3soHNH/My9p6muSm7N+5pLbwshGgGGSdtDijt+ZOqXh+TE3xhLUfKpGcRhW 2o4G3MkzzILXT23mp04SlDt77Zi6P8MQwCcyfuRiQ2VvHYpRWYM9DUzHxdre23WOyB/4 v6W0vqBtBiIZmfmFEOPPN76fJx41fkf3UL5R1PshH2bJgNK2sQ0blDj/P4g1zW+J/TNu 2vLRGuGO5CTLffVThQ+kJtvW6ITLu4UxcRRvN3kLt0jV1SiSsPPHt4JDkpY1DwX2aAM3 oQSRuX0VvsdjFus1loo35isMSf7dDL1G4sIAjQE1AKpoH1hW43RNrFQ1qqs3+xp1wLNf DqtA==
X-Received: by 10.52.27.138 with SMTP id t10mr21539149vdg.59.1360015501147; Mon, 04 Feb 2013 14:05:01 -0800 (PST)
Received: from [10.66.118.111] (mobile-198-228-207-184.mycingular.net. [198.228.207.184]) by mx.google.com with ESMTPS id l18sm23925779vdh.10.2013.02.04.14.04.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 14:05:00 -0800 (PST)
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>  <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>   
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (10B142)
From: Eric Rescorla 
Date: Mon, 4 Feb 2013 17:04:54 -0500
To: "Matthew Kaufman (SKYPE)" 
X-Gm-Message-State: ALoCoQno82cyzx2jLHaTOEDEBbeBLzJzMlctEIAMbAM38/Wbe4VNKyw1ukXPHrRyFX91aopGPXHv
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 22:05:03 -0000

On Feb 4, 2013, at 12:56, "Matthew Kaufman (SKYPE)"  wrote:

> I see two possible readings (either or both of them might be useful):
>=20
> 1. The browser must have a way for its user to force the use of TURN serve=
rs (and this is only useful if the user also provides the address and creden=
tials for the TURN servers) for transmission of media.
>=20
> 2. The browser must have an API that keeps some kinds of candidates from b=
eing included in the SDP the API generates.
>=20
> #1 seems like a very useful thing to require for users who might actually c=
are about their privacy, but I don't think that requirement belongs in an IE=
TF document but rather the W3C requirements TR for WEBRTC, that appears to h=
ave not even been started.
>=20

I had 2 in mind. I don't think #1 needs standardization


> #2 seems highly questionable to me, due to the large number of failure mod=
es in both the interpretation of the spec and the ability to circumvent the i=
ntent...
>=20
> For #2 do you mean "API flag to prevent local candidates from being includ=
ed" or "API flag to prevent server-reflexive STUN-learned candidates from be=
ing included" or both?
>=20
> For #2 how do you propose a malicious application or page injection not si=
mply change the flag?
>=20

The intent here is to allow the server to offer an anonymous calling service=
 so this threat isn't relevant


> For #2 why can't the same behavior be accomplished by including all the ca=
ndidates in the SDP and then letting the JavaScript remove the "dangerous" c=
andidates before sending the SDP to the server?
>=20

This I have a good answer to. You need to suppress checks on this candidates=
 because those reveal your address. And even if you think stripping in sdp b=
efore set local accomplishes this how do you do it for trickle ice?


> For #2 why can't the same behavior be accomplished by including all the ca=
ndidates in the SDP, sending it to the server (which you must trust anyway, a=
s it also can change the flag itself *or* derive your IP address by looking a=
t where you load pages from), and having the server remove the "dangerous" c=
andidates before sending them on to the far client?
>=20

Same reason
> Matthew Kaufman
>=20
>=20
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O=
f Eric Burger
> Sent: Monday, February 4, 2013 2:53 AM
> To: Eric Rescorla
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtc=
web-use-cases-and-requirements-10 (Part II))
>=20
> Under what circumstances would it be up to the Web server to decide to mak=
e the client interaction quasi-anonymous? Would that not be a entirely up to=
 and the responsibility of the client? By definition, the Web server is not a=
nonymous -- the user had to reach it somehow to get the page in the first pl=
ace. Likewise, it is well within the power of the server to obfuscate its me=
dia address. It is quite likely media is NOT coming from the same IP address=
 as the Web page under normal circumstances, so the server has built-in oppo=
rtunities to obfuscate its address. Conversely, it is well within the capabi=
lities of the browser to figure out how to obfuscate its media address. More=
 importantly, I have yet to hear a cogent use case for the server saying, "I=
 want this interaction to not have IP addresses *TO PROTECT YOU*." If you ar=
e in a scenario where you need protection, you cannot depend on the server. Y=
ou must depend on yourself, which means you will have a browser that will pr=
otect you. Moreover, will not a bad server simply always tell all browsers i=
t connects with to open lots of anonymity relays to DDoS the relays? Saying w=
e want to build something that is only sometimes useful and can only be usef=
ul if we trust all sides to do the right thing does not sound very useful.
>=20
> Am I missing something here?
>=20
> On Feb 3, 2013, at 6:48 PM, Eric Rescorla  wrote:
>=20
>>=20
>>=20
>> On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger =
 wrote:
>> To be clear, I think ekr's formulation is the best:
>>> 1. If you don't want the server learning your global IP, you need to use=
 Tor or the like.
>>=20
>> To me, this means it is totally orthogonal to RTCweb. If you want to use T=
or, a TURN server, an ALG, or foo, that is up to you. That does not impact t=
he protocol.
>>=20
>> That's certainly what I meant to be saying, with the small caveat that=20=

>> if you are using media relays (e.g., TURN) they are supposed to be=20
>> reflected in ICE candidate lines.
>>=20
>>=20
>>> 2. I would suggest that it is simplest to divide the world into host=20
>>> addresses, server/peer reflexive, and relayed and say that the=20
>>> requirement is that the browser must be able to send packets without=20
>>> revealing either of the former two, but that it is not a requirement tha=
t it be able to do so in the face of an adversarial server.
>> And this is the most reasonable. I guess the concern is we will forget al=
l of this list discussion, and someone will require hard-coded endpoint IP a=
ddresses in the protocol, which is what sunk SIP in the early days.
>>=20
>> Inline...
>>=20
>> On Feb 3, 2013, at 1:32 PM, Eric Rescorla  wrote:
>>=20
>>> On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric  w=
rote:
>>> Is what we are really asking for is the ability of the protocol to be TO=
R-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one part=
icular anonymity network or another into the RTCweb protocol suite.
>>>=20
>>> I'm certainly not suggesting that.
>>>=20
>>>=20
>>> On the one hand, with my purist hat on, saying it is a requirement to ma=
ke sure we do not need to have end-to-end connectivity smells a bit weird.
>>>=20
>>>> I don't understand this... I don't think anyone is suggesting that.
>>=20
>> Saying we will bake into the protocol the REQUIREMENT that it support goo=
d or bad boxes in the middle of the network does not sound like the end-to-e=
nd Internet. It sounds more like IMS.
>>=20
>> Which requirement do you think suggests that? I certainly favor=20
>> requirements that we be able to work in the face of as many known=20
>> classes of intermediaries (NATs, firewalls, etc. as possible.) I mean,=20=

>> isn't that the point of ICE supporting TURN and other types of relays?
>>=20
>> Is there something wrong with this? Do you think people are suggesting=20=

>> some other requirement?
>>=20
>>=20
>>> On the other hand, with my practical hat on, saying it is a requirement t=
o make sure the protocol works in situations that are NOT the Internet (NATs=
, a need for an overlay privacy network, etc.) seems like a good thing to do=
.
>>>=20
>>>> As far as I know, the only novel requirement here is that there be=20
>>>> a way for Web application to tell the browser to solely use relayed=20
>>>> addresses/candidates (and hopefully thus not reveal the user's=20
>>>> actual location) when communicating with the peer. There is of=20
>>>> course a requirement to be able to work when behind NATs but that is a f=
unctional requirement, not an anonymity one.
>>=20
>> That is asking an awful lot of an application. Moreover, as the cat-and-m=
ouse game of anonymous application communication is ever evolving, I would c=
hallenge how meaningful it is to specify a Hidden Bit or Anonymous Bit in th=
e protocol. I would offer that will work as well as the Evil Bit.
>>=20
>> I really am not following what you are saying here about a "hidden bit"?
>>=20
>> There is a very specific requirement being suggested here, namely that=20=

>> applications should be able to instruct browsers not to use host or=20
>> srvflx candidates. This is neither a hidden bit, nor an anonymous bit.=20=

>> Rather, it is a mechanism designed to allow the site, *if it wishes*=20
>> to offer a calling service that doesn't immediately reveal the=20
>> caller's location. This isn't a complete anonymity service against=20
>> sophisticated attackers. For that you need something like Tor. Rather,=20=

>> it's an easy-to-implement measure that offers location protection against=
 a (relatively common) class of limited attackers.
>>=20
>> What is it you object to about this requirement?
>>=20
>> -Ekr
>=20

From matthew.kaufman@skype.net  Mon Feb  4 14:30:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4425121F8AB7 for ; Mon,  4 Feb 2013 14:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM5gtreISL+L for ; Mon,  4 Feb 2013 14:30:53 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id D004921F8AA3 for ; Mon,  4 Feb 2013 14:30:48 -0800 (PST)
Received: from BL2FFO11FD013.protection.gbl (10.173.161.202) by BL2FFO11HUB018.protection.gbl (10.173.160.110) with Microsoft SMTP Server (TLS) id 15.0.609.9; Mon, 4 Feb 2013 22:30:44 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Mon, 4 Feb 2013 22:30:44 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.197]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Mon, 4 Feb 2013 22:30:10 +0000
From: "Matthew Kaufman (SKYPE)" 
To: Eric Rescorla 
Thread-Topic: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
Thread-Index: AQHOAyOzvMjV16PQAUKbnzLpy7eiuJhqRnYg
Date: Mon, 4 Feb 2013 22:30:09 +0000
Message-ID: 
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>  <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.73]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(52314002)(13464002)(377454001)(199002)(50084002)(189002)(51704002)(16406001)(51856001)(79102001)(50466001)(46406002)(47976001)(47736001)(56816002)(50986001)(49866001)(46102001)(20776003)(33656001)(56776001)(54316002)(74662001)(23726001)(31966008)(5343635001)(77982001)(5343655001)(55846006)(4396001)(53806001)(54356001)(5343645001)(47776003)(63696002)(59766001)(47446002)(76482001)(44976002)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB018; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:3; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07473990A5
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 22:30:54 -0000

I still don't understand how I, as a user, can possibly trust your web site=
 to set the flags appropriately so that my browser doesn't execute connecti=
vity checks to someone I'm worried might learn my IP address.

I get it in option #1. I set my browser that way, I trust my browser vendor=
, end of story.

In case #2, I go to your site, I don't trust your site, but I decide to use=
 it anyway. It gives my addresses away when I do my HTTP GET from it. Then =
I make a call, and it sets the flags however it wants. Or it sets the flags=
 to "don't do checks except over TURN" and then it sets up a TURN server, b=
ut points the TURN server to be the address of the bad guy I didn't want my=
 addresses disclosed to and so my connection attempt to that TURN server re=
veals my addresses, etc. How does any of this actually help me?

If I really trust the site to protect me, the site runs a media proxy and o=
nly has me run ICE checks against that (because those are the only far cand=
idates in the SDP). It relays the traffic. Done.

Matthew Kaufman

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com]=20
Sent: Monday, February 4, 2013 2:05 PM
To: Matthew Kaufman (SKYPE)
Cc: Eric Burger; rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcw=
eb-use-cases-and-requirements-10 (Part II))



On Feb 4, 2013, at 12:56, "Matthew Kaufman (SKYPE)"  wrote:

> I see two possible readings (either or both of them might be useful):
>=20
> 1. The browser must have a way for its user to force the use of TURN serv=
ers (and this is only useful if the user also provides the address and cred=
entials for the TURN servers) for transmission of media.
>=20
> 2. The browser must have an API that keeps some kinds of candidates from =
being included in the SDP the API generates.
>=20
> #1 seems like a very useful thing to require for users who might actually=
 care about their privacy, but I don't think that requirement belongs in an=
 IETF document but rather the W3C requirements TR for WEBRTC, that appears =
to have not even been started.

>=20

I had 2 in mind. I don't think #1 needs standardization


> #2 seems highly questionable to me, due to the large number of failure mo=
des in both the interpretation of the spec and the ability to circumvent th=
e intent...
>=20
> For #2 do you mean "API flag to prevent local candidates from being inclu=
ded" or "API flag to prevent server-reflexive STUN-learned candidates from =
being included" or both?
>=20
> For #2 how do you propose a malicious application or page injection not s=
imply change the flag?
>=20

The intent here is to allow the server to offer an anonymous calling servic=
e so this threat isn't relevant


> For #2 why can't the same behavior be accomplished by including all the c=
andidates in the SDP and then letting the JavaScript remove the "dangerous"=
 candidates before sending the SDP to the server?
>=20

This I have a good answer to. You need to suppress checks on this candidate=
s because those reveal your address. And even if you think stripping in sdp=
 before set local accomplishes this how do you do it for trickle ice?


> For #2 why can't the same behavior be accomplished by including all the c=
andidates in the SDP, sending it to the server (which you must trust anyway=
, as it also can change the flag itself *or* derive your IP address by look=
ing at where you load pages from), and having the server remove the "danger=
ous" candidates before sending them on to the far client?
>=20

Same reason
> Matthew Kaufman
>=20
>=20
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20
> Behalf Of Eric Burger
> Sent: Monday, February 4, 2013 2:53 AM
> To: Eric Rescorla
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of=20
> draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
>=20
> Under what circumstances would it be up to the Web server to decide to ma=
ke the client interaction quasi-anonymous? Would that not be a entirely up =
to and the responsibility of the client? By definition, the Web server is n=
ot anonymous -- the user had to reach it somehow to get the page in the fir=
st place. Likewise, it is well within the power of the server to obfuscate =
its media address. It is quite likely media is NOT coming from the same IP =
address as the Web page under normal circumstances, so the server has built=
-in opportunities to obfuscate its address. Conversely, it is well within t=
he capabilities of the browser to figure out how to obfuscate its media add=
ress. More importantly, I have yet to hear a cogent use case for the server=
 saying, "I want this interaction to not have IP addresses *TO PROTECT YOU*=
." If you are in a scenario where you need protection, you cannot depend on=
 the server. You must depend on yourself, which means you will have a brows=
er that will protect you. Moreover, will not a bad server simply always tel=
l all browsers it connects with to open lots of anonymity relays to DDoS th=
e relays? Saying we want to build something that is only sometimes useful a=
nd can only be useful if we trust all sides to do the right thing does not =
sound very useful.
>=20
> Am I missing something here?
>=20
> On Feb 3, 2013, at 6:48 PM, Eric Rescorla  wrote:
>=20
>>=20
>>=20
>> On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger  wrote:
>> To be clear, I think ekr's formulation is the best:
>>> 1. If you don't want the server learning your global IP, you need to us=
e Tor or the like.
>>=20
>> To me, this means it is totally orthogonal to RTCweb. If you want to use=
 Tor, a TURN server, an ALG, or foo, that is up to you. That does not impac=
t the protocol.
>>=20
>> That's certainly what I meant to be saying, with the small caveat=20
>> that if you are using media relays (e.g., TURN) they are supposed to=20
>> be reflected in ICE candidate lines.
>>=20
>>=20
>>> 2. I would suggest that it is simplest to divide the world into host=20
>>> addresses, server/peer reflexive, and relayed and say that the=20
>>> requirement is that the browser must be able to send packets without=20
>>> revealing either of the former two, but that it is not a requirement th=
at it be able to do so in the face of an adversarial server.
>> And this is the most reasonable. I guess the concern is we will forget a=
ll of this list discussion, and someone will require hard-coded endpoint IP=
 addresses in the protocol, which is what sunk SIP in the early days.
>>=20
>> Inline...
>>=20
>> On Feb 3, 2013, at 1:32 PM, Eric Rescorla  wrote:
>>=20
>>> On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric =
 wrote:
>>> Is what we are really asking for is the ability of the protocol to be T=
OR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one pa=
rticular anonymity network or another into the RTCweb protocol suite.
>>>=20
>>> I'm certainly not suggesting that.
>>>=20
>>>=20
>>> On the one hand, with my purist hat on, saying it is a requirement to m=
ake sure we do not need to have end-to-end connectivity smells a bit weird.
>>>=20
>>>> I don't understand this... I don't think anyone is suggesting that.
>>=20
>> Saying we will bake into the protocol the REQUIREMENT that it support go=
od or bad boxes in the middle of the network does not sound like the end-to=
-end Internet. It sounds more like IMS.
>>=20
>> Which requirement do you think suggests that? I certainly favor=20
>> requirements that we be able to work in the face of as many known=20
>> classes of intermediaries (NATs, firewalls, etc. as possible.) I=20
>> mean, isn't that the point of ICE supporting TURN and other types of rel=
ays?
>>=20
>> Is there something wrong with this? Do you think people are=20
>> suggesting some other requirement?
>>=20
>>=20
>>> On the other hand, with my practical hat on, saying it is a requirement=
 to make sure the protocol works in situations that are NOT the Internet (N=
ATs, a need for an overlay privacy network, etc.) seems like a good thing t=
o do.
>>>=20
>>>> As far as I know, the only novel requirement here is that there be=20
>>>> a way for Web application to tell the browser to solely use relayed=20
>>>> addresses/candidates (and hopefully thus not reveal the user's=20
>>>> actual location) when communicating with the peer. There is of=20
>>>> course a requirement to be able to work when behind NATs but that is a=
 functional requirement, not an anonymity one.
>>=20
>> That is asking an awful lot of an application. Moreover, as the cat-and-=
mouse game of anonymous application communication is ever evolving, I would=
 challenge how meaningful it is to specify a Hidden Bit or Anonymous Bit in=
 the protocol. I would offer that will work as well as the Evil Bit.
>>=20
>> I really am not following what you are saying here about a "hidden bit"?
>>=20
>> There is a very specific requirement being suggested here, namely=20
>> that applications should be able to instruct browsers not to use host=20
>> or srvflx candidates. This is neither a hidden bit, nor an anonymous bit=
.
>> Rather, it is a mechanism designed to allow the site, *if it wishes*=20
>> to offer a calling service that doesn't immediately reveal the=20
>> caller's location. This isn't a complete anonymity service against=20
>> sophisticated attackers. For that you need something like Tor.=20
>> Rather, it's an easy-to-implement measure that offers location protectio=
n against a (relatively common) class of limited attackers.
>>=20
>> What is it you object to about this requirement?
>>=20
>> -Ekr
>=20


From rlb@ipv.sx  Mon Feb  4 14:36:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FF421F8B69 for ; Mon,  4 Feb 2013 14:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.48
X-Spam-Level: 
X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FqGWGTIOjYB for ; Mon,  4 Feb 2013 14:36:06 -0800 (PST)
Received: from mail-la0-x22f.google.com (la-in-x022f.1e100.net [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0417321F8B61 for ; Mon,  4 Feb 2013 14:36:05 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id fj20so5156884lab.34 for ; Mon, 04 Feb 2013 14:36:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vNSUoEnDaOtnNK8bau+5tW7WjW8FnlcBJ4Tu2wJXgxU=; b=GtM56MpcPALsvfsoQEfsJ1Dg9yYus5k8lM2wi6hem2HGU7kZKRYvI3XxgSi+r988IT /xLRFPd6faY6iOw8rAWvTbGVJsdSZFkC9ck96nVFChRWy1Y7NJgr1E97O6iQ5AoasB84 xrSIZGINwtT34h+gYNU0oCbDNxtrEsU8u7RxBi6dbOPBmQiTXHsNfmnG52D9CYHaWoCQ v+/sGwDd4Vm+WrGabojlSLgTuTzTPv3MOMLU3+QFqIIWjCKkpgIIwKElW/vrJdAF+P+2 6X3Y9sDdV81T0DfENtulbktyFPTvGMUxam3NSY4vEDmj59n4OO0astrTiFxFDL9LXaCr OaGQ==
MIME-Version: 1.0
X-Received: by 10.112.27.34 with SMTP id q2mr8961598lbg.56.1360017364720; Mon, 04 Feb 2013 14:36:04 -0800 (PST)
Received: by 10.112.142.170 with HTTP; Mon, 4 Feb 2013 14:36:04 -0800 (PST)
X-Originating-IP: [174.254.182.97]
In-Reply-To: 
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>  <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>     
Date: Mon, 4 Feb 2013 17:36:04 -0500
Message-ID: 
From: Richard Barnes 
To: "Matthew Kaufman (SKYPE)" 
Content-Type: multipart/alternative; boundary=bcaec554d9f0e99bb804d4edb7b9
X-Gm-Message-State: ALoCoQlr/qTIWR/TdmtvedpmgQEcqb/EScz9q8QTXABywr/B5MAkV3uJPG7RRfXwhtEGOSa8eblx
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 22:36:07 -0000

--bcaec554d9f0e99bb804d4edb7b9
Content-Type: text/plain; charset=ISO-8859-1

It seems like #1 is a special case of #2, in which the browser overrides
whatever flag is set.  It seems like even in #2, there could be chrome to
mitigate the risk of pages lying.

I agree that #1 would not require standardization.

--Richard

On Monday, February 4, 2013, Matthew Kaufman (SKYPE) wrote:

> I still don't understand how I, as a user, can possibly trust your web
> site to set the flags appropriately so that my browser doesn't execute
> connectivity checks to someone I'm worried might learn my IP address.
>
> I get it in option #1. I set my browser that way, I trust my browser
> vendor, end of story.
>
> In case #2, I go to your site, I don't trust your site, but I decide to
> use it anyway. It gives my addresses away when I do my HTTP GET from it.
> Then I make a call, and it sets the flags however it wants. Or it sets the
> flags to "don't do checks except over TURN" and then it sets up a TURN
> server, but points the TURN server to be the address of the bad guy I
> didn't want my addresses disclosed to and so my connection attempt to that
> TURN server reveals my addresses, etc. How does any of this actually help
> me?
>
> If I really trust the site to protect me, the site runs a media proxy and
> only has me run ICE checks against that (because those are the only far
> candidates in the SDP). It relays the traffic. Done.
>
> Matthew Kaufman
>
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Monday, February 4, 2013 2:05 PM
> To: Matthew Kaufman (SKYPE)
> Cc: Eric Burger; rtcweb@ietf.org
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of
> draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
>
>
>
> On Feb 4, 2013, at 12:56, "Matthew Kaufman (SKYPE)" <
> matthew.kaufman@skype.net> wrote:
>
> > I see two possible readings (either or both of them might be useful):
> >
> > 1. The browser must have a way for its user to force the use of TURN
> servers (and this is only useful if the user also provides the address and
> credentials for the TURN servers) for transmission of media.
> >
> > 2. The browser must have an API that keeps some kinds of candidates from
> being included in the SDP the API generates.
> >
> > #1 seems like a very useful thing to require for users who might
> actually care about their privacy, but I don't think that requirement
> belongs in an IETF document but rather the W3C requirements TR for WEBRTC,
> that appears to have not even been started.
>
> >
>
> I had 2 in mind. I don't think #1 needs standardization
>
>
> > #2 seems highly questionable to me, due to the large number of failure
> modes in both the interpretation of the spec and the ability to circumvent
> the intent...
> >
> > For #2 do you mean "API flag to prevent local candidates from being
> included" or "API flag to prevent server-reflexive STUN-learned candidates
> from being included" or both?
> >
> > For #2 how do you propose a malicious application or page injection not
> simply change the flag?
> >
>
> The intent here is to allow the server to offer an anonymous calling
> service so this threat isn't relevant
>
>
> > For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP and then letting the JavaScript remove the
> "dangerous" candidates before sending the SDP to the server?
> >
>
> This I have a good answer to. You need to suppress checks on this
> candidates because those reveal your address. And even if you think
> stripping in sdp before set local accomplishes this how do you do it for
> trickle ice?
>
>
> > For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP, sending it to the server (which you must trust
> anyway, as it also can change the flag itself *or* derive your IP address
> by looking at where you load pages from), and having the server remove the
> "dangerous" candidates before sending them on to the far client?
> >
>
> Same reason
> > Matthew Kaufman
> >
> >
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Eric Burger
> > Sent: Monday, February 4, 2013 2:53 AM
> > To: Eric Rescorla
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of
> > draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
> >
> > Under what circumstances would it be up to the Web server to decide to
> make the client interaction quasi-anonymous? Would that not be a entirely
> up to and the responsibility of the client? By definition, the Web server
> is not anonymous -- the user had to reach it somehow to get the page in the
> first place. Likewise, it is well within the power of the server to
> obfuscate its media address. It is quite likely media is NOT coming from
> the same IP address as the Web page under normal circumstances, so the
> server has built-in opportunities to obfuscate its address. Conversely, it
> is well within the capabilities of the browser to figure out how to
> obfuscate its media address. More importantly, I have yet to hear a cogent
> use case for the server saying, "I want this interaction to not have IP
> addresses *TO PROTECT YOU*." If you are in a scenario where you need
> protection, you cannot depend on the server. You must depend on yourself,
> which means you will have a browser that will pr
>  otect you. Moreover, will not a bad server simply always tell all
> browsers it connects with to open lots of anonymity relays to DDoS the
> relays? Saying we want to build something that is only sometimes useful and
> can only be useful if we trust all sides to do the right thing does not
> sound very useful.
> >
> > Am I m

--bcaec554d9f0e99bb804d4edb7b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It seems like #1 is a special case of #2, in which the browser overrides wh=
atever flag is set. =A0It seems like even in #2, there could be chrome to m=
itigate the risk of pages lying.=A0

I agree=
=A0that #1 would not require standardization.=A0



--Richard

On Monday, February 4, 2013, Matthew K=
aufman (SKYPE)  wrote:
I still don't =
understand how I, as a user, can possibly trust your web site to set the fl=
ags appropriately so that my browser doesn't execute connectivity check=
s to someone I'm worried might learn my IP address.




I get it in option #1. I set my browser that way, I trust my browser vendor=
, end of story.



In case #2, I go to your site, I don't trust your site, but I decide to=
 use it anyway. It gives my addresses away when I do my HTTP GET from it. T=
hen I make a call, and it sets the flags however it wants. Or it sets the f=
lags to "don't do checks except over TURN" and then it sets u=
p a TURN server, but points the TURN server to be the address of the bad gu=
y I didn't want my addresses disclosed to and so my connection attempt =
to that TURN server reveals my addresses, etc. How does any of this actuall=
y help me?




If I really trust the site to protect me, the site runs a media proxy and o=
nly has me run ICE checks against that (because those are the only far cand=
idates in the SDP). It relays the traffic. Done.



Matthew Kaufman



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

From: Eric Rescorla [mailto:ekr@rtfm.com]

Sent: Monday, February 4, 2013 2:05 PM

To: Matthew Kaufman (SKYPE)

Cc: Eric Burger; rtcweb@ietf.org

Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcw=
eb-use-cases-and-requirements-10 (Part II))







On Feb 4, 2013, at 12:56, "Matthew Kaufman (SKYPE)" <matthe=
w.kaufman@skype.net> wrote:



> I see two possible readings (either or both of them might be useful):<=
br>
>

> 1. The browser must have a way for its user to force the use of TURN s=
ervers (and this is only useful if the user also provides the address and c=
redentials for the TURN servers) for transmission of media.

>

> 2. The browser must have an API that keeps some kinds of candidates fr=
om being included in the SDP the API generates.

>

> #1 seems like a very useful thing to require for users who might actua=
lly care about their privacy, but I don't think that requirement belong=
s in an IETF document but rather the W3C requirements TR for WEBRTC, that a=
ppears to have not even been started.




>



I had 2 in mind. I don't think #1 needs standardization





> #2 seems highly questionable to me, due to the large number of failure=
 modes in both the interpretation of the spec and the ability to circumvent=
 the intent...

>

> For #2 do you mean "API flag to prevent local candidates from bei=
ng included" or "API flag to prevent server-reflexive STUN-learne=
d candidates from being included" or both?

>

> For #2 how do you propose a malicious application or page injection no=
t simply change the flag?

>



The intent here is to allow the server to offer an anonymous calling servic=
e so this threat isn't relevant





> For #2 why can't the same behavior be accomplished by including al=
l the candidates in the SDP and then letting the JavaScript remove the &quo=
t;dangerous" candidates before sending the SDP to the server?


>



This I have a good answer to. You need to suppress checks on this candidate=
s because those reveal your address. And even if you think stripping in sdp=
 before set local accomplishes this how do you do it for trickle ice?






> For #2 why can't the same behavior be accomplished by including al=
l the candidates in the SDP, sending it to the server (which you must trust=
 anyway, as it also can change the flag itself *or* derive your IP address =
by looking at where you load pages from), and having the server remove the =
"dangerous" candidates before sending them on to the far client?<=
br>

>



Same reason

> Matthew Kaufman

>

>

> -----Original Message-----

> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or=
g] On

> Behalf Of Eric Burger

> Sent: Monday, February 4, 2013 2:53 AM

> To: Eric Rescorla

> Cc: rtcweb@ietf.org

> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of

> draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

>

> Under what circumstances would it be up to the Web server to decide to=
 make the client interaction quasi-anonymous? Would that not be a entirely =
up to and the responsibility of the client? By definition, the Web server i=
s not anonymous -- the user had to reach it somehow to get the page in the =
first place. Likewise, it is well within the power of the server to obfusca=
te its media address. It is quite likely media is NOT coming from the same =
IP address as the Web page under normal circumstances, so the server has bu=
ilt-in opportunities to obfuscate its address. Conversely, it is well withi=
n the capabilities of the browser to figure out how to obfuscate its media =
address. More importantly, I have yet to hear a cogent use case for the ser=
ver saying, "I want this interaction to not have IP addresses *TO PROT=
ECT YOU*." If you are in a scenario where you need protection, you can=
not depend on the server. You must depend on yourself, which means you will=
 have a browser that will pr


=A0otect you. Moreover, will not a bad server simply always tell all browse=
rs it connects with to open lots of anonymity relays to DDoS the relays? Sa=
ying we want to build something that is only sometimes useful and can only =
be useful if we trust all sides to do the right thing does not sound very u=
seful.


>

> Am I m


--bcaec554d9f0e99bb804d4edb7b9--

From matthew.kaufman@skype.net  Mon Feb  4 15:08:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B495921F8B2E for ; Mon,  4 Feb 2013 15:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWDJzX+LH7Bb for ; Mon,  4 Feb 2013 15:08:13 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id EABE421F8B26 for ; Mon,  4 Feb 2013 15:08:12 -0800 (PST)
Received: from BY2FFO11FD006.protection.gbl (10.1.15.203) by BY2FFO11HUB013.protection.gbl (10.1.14.85) with Microsoft SMTP Server (TLS) id 15.0.609.9; Mon, 4 Feb 2013 23:08:09 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Mon, 4 Feb 2013 23:08:09 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.197]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Mon, 4 Feb 2013 23:07:48 +0000
From: "Matthew Kaufman (SKYPE)" 
To: Richard Barnes 
Thread-Topic: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
Thread-Index: AQHOAyOzvMjV16PQAUKbnzLpy7eiuJhqRnYggAADSgCAAAiysA==
Date: Mon, 4 Feb 2013 23:07:48 +0000
Message-ID: 
References: <50F97303.4070906@ericsson.com>    <5109265F.6040106@ericsson.com>  <510B9A41.8000804@ericsson.com>	<510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com>	<510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com>	<510D6039.3060501@alvestrand.no>  <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu>  <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.73]
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A484161C5DEEtk5ex14mbxc272r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(50084002)(199002)(189002)(13464002)(24454001)(52314002)(51704002)(50986001)(47976001)(33656001)(51856001)(47736001)(5343655001)(5343635001)(512954001)(20776003)(79102001)(56816002)(4396001)(63696002)(49866001)(46102001)(74502001)(31966008)(16236675001)(15202345001)(77982001)(59766001)(47446002)(74662001)(44976002)(55846006)(54356001)(53806001)(76482001)(16406001)(56776001)(54316002)(5343645001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB013; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:3; MX:3; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07473990A5
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 23:08:16 -0000

--_000_AE1A6B5FD507DC4FB3C5166F3A05A484161C5DEEtk5ex14mbxc272r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We're talking about the use cases and requirements document. I believe that=
 the W3C requirements doc for the browser should include #1. That's differe=
nt than "standardization", and isn't an IETF issue either.

Matthew Kaufman

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Monday, February 4, 2013 2:36 PM
To: Matthew Kaufman (SKYPE)
Cc: Eric Rescorla; rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcw=
eb-use-cases-and-requirements-10 (Part II))

It seems like #1 is a special case of #2, in which the browser overrides wh=
atever flag is set.  It seems like even in #2, there could be chrome to mit=
igate the risk of pages lying.

I agree that #1 would not require standardization.

--Richard

On Monday, February 4, 2013, Matthew Kaufman (SKYPE) wrote:
I still don't understand how I, as a user, can possibly trust your web site=
 to set the flags appropriately so that my browser doesn't execute connecti=
vity checks to someone I'm worried might learn my IP address.

I get it in option #1. I set my browser that way, I trust my browser vendor=
, end of story.

In case #2, I go to your site, I don't trust your site, but I decide to use=
 it anyway. It gives my addresses away when I do my HTTP GET from it. Then =
I make a call, and it sets the flags however it wants. Or it sets the flags=
 to "don't do checks except over TURN" and then it sets up a TURN server, b=
ut points the TURN server to be the address of the bad guy I didn't want my=
 addresses disclosed to and so my connection attempt to that TURN server re=
veals my addresses, etc. How does any of this actually help me?

If I really trust the site to protect me, the site runs a media proxy and o=
nly has me run ICE checks against that (because those are the only far cand=
idates in the SDP). It relays the traffic. Done.

Matthew Kaufman

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Monday, February 4, 2013 2:05 PM
To: Matthew Kaufman (SKYPE)
Cc: Eric Burger; rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcw=
eb-use-cases-and-requirements-10 (Part II))



On Feb 4, 2013, at 12:56, "Matthew Kaufman (SKYPE)"  wrote:

> I see two possible readings (either or both of them might be useful):
>
> 1. The browser must have a way for its user to force the use of TURN serv=
ers (and this is only useful if the user also provides the address and cred=
entials for the TURN servers) for transmission of media.
>
> 2. The browser must have an API that keeps some kinds of candidates from =
being included in the SDP the API generates.
>
> #1 seems like a very useful thing to require for users who might actually=
 care about their privacy, but I don't think that requirement belongs in an=
 IETF document but rather the W3C requirements TR for WEBRTC, that appears =
to have not even been started.

>

I had 2 in mind. I don't think #1 needs standardization


> #2 seems highly questionable to me, due to the large number of failure mo=
des in both the interpretation of the spec and the ability to circumvent th=
e intent...
>
> For #2 do you mean "API flag to prevent local candidates from being inclu=
ded" or "API flag to prevent server-reflexive STUN-learned candidates from =
being included" or both?
>
> For #2 how do you propose a malicious application or page injection not s=
imply change the flag?
>

The intent here is to allow the server to offer an anonymous calling servic=
e so this threat isn't relevant


> For #2 why can't the same behavior be accomplished by including all the c=
andidates in the SDP and then letting the JavaScript remove the "dangerous"=
 candidates before sending the SDP to the server?
>

This I have a good answer to. You need to suppress checks on this candidate=
s because those reveal your address. And even if you think stripping in sdp=
 before set local accomplishes this how do you do it for trickle ice?


> For #2 why can't the same behavior be accomplished by including all the c=
andidates in the SDP, sending it to the server (which you must trust anyway=
, as it also can change the flag itself *or* derive your IP address by look=
ing at where you load pages from), and having the server remove the "danger=
ous" candidates before sending them on to the far client?
>

Same reason
> Matthew Kaufman
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Eric Burger
> Sent: Monday, February 4, 2013 2:53 AM
> To: Eric Rescorla
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of
> draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
>
> Under what circumstances would it be up to the Web server to decide to ma=
ke the client interaction quasi-anonymous? Would that not be a entirely up =
to and the responsibility of the client? By definition, the Web server is n=
ot anonymous -- the user had to reach it somehow to get the page in the fir=
st place. Likewise, it is well within the power of the server to obfuscate =
its media address. It is quite likely media is NOT coming from the same IP =
address as the Web page under normal circumstances, so the server has built=
-in opportunities to obfuscate its address. Conversely, it is well within t=
he capabilities of the browser to figure out how to obfuscate its media add=
ress. More importantly, I have yet to hear a cogent use case for the server=
 saying, "I want this interaction to not have IP addresses *TO PROTECT YOU*=
." If you are in a scenario where you need protection, you cannot depend on=
 the server. You must depend on yourself, which means you will have a brows=
er that will pr
 otect you. Moreover, will not a bad server simply always tell all browsers=
 it connects with to open lots of anonymity relays to DDoS the relays? Sayi=
ng we want to build something that is only sometimes useful and can only be=
 useful if we trust all sides to do the right thing does not sound very use=
ful.
>
> Am I m

--_000_AE1A6B5FD507DC4FB3C5166F3A05A484161C5DEEtk5ex14mbxc272r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











We’re talking about=
 the use cases and requirements document. I believe that the W3C requiremen=
ts doc for the browser should include #1. That’s different than
 “standardization”, and isn’t an IETF issue either.<=
/o:p>


 <=
/p>

Matthew Kaufman


 <=
/p>

From: Richard Barnes [mailto:rlb@ipv.sx]


Sent: Monday, February 4, 2013 2:36 PM

To: Matthew Kaufman (SKYPE)

Cc: Eric Rescorla; rtcweb@ietf.org

Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ie=
tf-rtcweb-use-cases-and-requirements-10 (Part II))


 


It seems like #1 is a spe=
cial case of #2, in which the browser overrides whatever flag is set.  =
;It seems like even in #2, there could be chrome to mitigate the risk of pa=
ges lying. 




 






I agree that #1 woul=
d not require standardization. 






 






--Richard



On Monday, February 4, 2013, Matthew Kaufman (SKYPE) wrote:


I still don't understand =
how I, as a user, can possibly trust your web site to set the flags appropr=
iately so that my browser doesn't execute connectivity checks to someone I'=
m worried might learn my IP address.



I get it in option #1. I set my browser that way, I trust my browser vendor=
, end of story.



In case #2, I go to your site, I don't trust your site, but I decide to use=
 it anyway. It gives my addresses away when I do my HTTP GET from it. Then =
I make a call, and it sets the flags however it wants. Or it sets the flags=
 to "don't do checks except over
 TURN" and then it sets up a TURN server, but points the TURN server t=
o be the address of the bad guy I didn't want my addresses disclosed to and=
 so my connection attempt to that TURN server reveals my addresses, etc. Ho=
w does any of this actually help me?



If I really trust the site to protect me, the site runs a media proxy and o=
nly has me run ICE checks against that (because those are the only far cand=
idates in the SDP). It relays the traffic. Done.



Matthew Kaufman



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

From: Eric Rescorla [mailto:ekr@rtfm.com]

Sent: Monday, February 4, 2013 2:05 PM

To: Matthew Kaufman (SKYPE)

Cc: Eric Burger; rtcweb@ietf.org

Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcw=
eb-use-cases-and-requirements-10 (Part II))







On Feb 4, 2013, at 12:56, "Matthew Kaufman (SKYPE)" <matthew.k=
aufman@skype.net> wrote:



> I see two possible readings (either or both of them might be useful):<=
br>
>

> 1. The browser must have a way for its user to force the use of TURN s=
ervers (and this is only useful if the user also provides the address and c=
redentials for the TURN servers) for transmission of media.

>

> 2. The browser must have an API that keeps some kinds of candidates fr=
om being included in the SDP the API generates.

>

> #1 seems like a very useful thing to require for users who might actua=
lly care about their privacy, but I don't think that requirement belongs in=
 an IETF document but rather the W3C requirements TR for WEBRTC, that appea=
rs to have not even been started.



>



I had 2 in mind. I don't think #1 needs standardization





> #2 seems highly questionable to me, due to the large number of failure=
 modes in both the interpretation of the spec and the ability to circumvent=
 the intent...

>

> For #2 do you mean "API flag to prevent local candidates from bei=
ng included" or "API flag to prevent server-reflexive STUN-learne=
d candidates from being included" or both?

>

> For #2 how do you propose a malicious application or page injection no=
t simply change the flag?

>



The intent here is to allow the server to offer an anonymous calling servic=
e so this threat isn't relevant





> For #2 why can't the same behavior be accomplished by including all th=
e candidates in the SDP and then letting the JavaScript remove the "da=
ngerous" candidates before sending the SDP to the server?

>



This I have a good answer to. You need to suppress checks on this candidate=
s because those reveal your address. And even if you think stripping in sdp=
 before set local accomplishes this how do you do it for trickle ice?





> For #2 why can't the same behavior be accomplished by including all th=
e candidates in the SDP, sending it to the server (which you must trust any=
way, as it also can change the flag itself *or* derive your IP address by l=
ooking at where you load pages from),
 and having the server remove the "dangerous" candidates before s=
ending them on to the far client?

>



Same reason

> Matthew Kaufman

>

>

> -----Original Message-----

> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On

> Behalf Of Eric Burger

> Sent: Monday, February 4, 2013 2:53 AM

> To: Eric Rescorla

> Cc: rtcweb@ietf.org

> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of

> draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

>

> Under what circumstances would it be up to the Web server to decide to=
 make the client interaction quasi-anonymous? Would that not be a entirely =
up to and the responsibility of the client? By definition, the Web server i=
s not anonymous -- the user had to
 reach it somehow to get the page in the first place. Likewise, it is well =
within the power of the server to obfuscate its media address. It is quite =
likely media is NOT coming from the same IP address as the Web page under n=
ormal circumstances, so the server
 has built-in opportunities to obfuscate its address. Conversely, it is wel=
l within the capabilities of the browser to figure out how to obfuscate its=
 media address. More importantly, I have yet to hear a cogent use case for =
the server saying, "I want this
 interaction to not have IP addresses *TO PROTECT YOU*." If you are in=
 a scenario where you need protection, you cannot depend on the server. You=
 must depend on yourself, which means you will have a browser that will pr<=
br>
 otect you. Moreover, will not a bad server simply always tell all bro=
wsers it connects with to open lots of anonymity relays to DDoS the relays?=
 Saying we want to build something that is only sometimes useful and can on=
ly be useful if we trust all sides to
 do the right thing does not sound very useful.

>

> Am I m








--_000_AE1A6B5FD507DC4FB3C5166F3A05A484161C5DEEtk5ex14mbxc272r_--

From eckelcu@cisco.com  Mon Feb  4 18:28:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065D21F8727; Mon,  4 Feb 2013 18:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 o+YMgPGomnb4; Mon,  4 Feb 2013 18:28:09 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B721F890D; Mon,  4 Feb 2013 18:28:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2275; q=dns/txt; s=iport; t=1360031289; x=1361240889; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iWpRYVqGPk+ouYle0tdGJo3gMkNVesZznllK1Od3tyg=; b=IWH0oXuzwZ2CxpDAyb55HucQ71KEQS3evQr+Zkk5TYj4usqTOxGcdrhO J3EEg/kxkBJORGYEXRrxrjMVvXAuMe+FV8Ots0gRgT+wYky6T1Nm47Mve aKGq54Wdf+8PlkPH71DVxbmLMBpApZWT271hZQ0Cp3UVzVHZ8aiiZUbnI 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAD5sEFGtJXG//2dsb2JhbABFv0QWc4IfAQEBBAxmEwICAgEIEQQBAQsdBxsXFAkIAgQBEgiICatvkA0EjSaDR2EDiDCeQIJvDYFvNQ
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="173276458"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 05 Feb 2013 02:28:09 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r152S9Rn021311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 02:28:09 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.207]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 20:28:08 -0600
From: "Charles Eckel (eckelcu)" 
To: Magnus Westerlund , "mmusic (E-mail)" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Draft on Multimedia concepts and relations for Intermim
Thread-Index: AQHN/6A+vrlehv19GUGvsxwr0HOEbJhqHUDA
Date: Tue, 5 Feb 2013 02:28:08 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C088280477C368@xmb-aln-x08.cisco.com>
References: <510A4B7C.3000009@ericsson.com>
In-Reply-To: <510A4B7C.3000009@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.117.254]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Draft on Multimedia concepts and relations for Intermim
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 02:28:10 -0000

Hi Magnus and Bo,

Thanks for putting this together, and more importantly, for attaching a cop=
y in the e-mail so I was able to access it on the plane without internet.
I agree with most of the reasoning in the various sections; however, there =
are a couple related concepts for which I'd like more clarification.

1) MediaStream
Is a MediaStream restricted to a single source? I did not think it was, but=
 the description on page 8 seems to imply this restriction. For example, co=
uld I have a single MediaStream with the following 4 MediaStreamTracks, whe=
re source 1 and source 2 are two video cameras from the same endpoint, or a=
 mic and an camera from the same endpoint:

Source 1 - encoding 1
Source 1 - encoding 2
Source 2 - encoding 1
Source 2 - encoding 2

2) PeerConnection
Later, on page 18, a related restriction of a single encoding per PC is sug=
gested. In the case of a layered encoding, this seems to imply each layer b=
eing in its own PC. Is that the recommendation being suggested?

Thanks,
Charles=20



> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Magnus Westerlund
> Sent: Thursday, January 31, 2013 2:46 AM
> To: mmusic (E-mail); rtcweb@ietf.org
> Subject: [rtcweb] Draft on Multimedia concepts and relations for Intermim
>=20
> Hi,
>=20
> Attached is a draft on multimedia concepts and relations that we believe
> relevant for the upcoming interim. This includes commonalties between
> WebRTC and CLUE and other RTP usages.
>=20
> Sorry for the late submission, i do hope you have time to review it. At
> will also be properly submitted to IETF as soon as we figure out why the
> submission tools refuses to process it.
>=20
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------

From eckelcu@cisco.com  Mon Feb  4 18:29:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3D21F8995; Mon,  4 Feb 2013 18:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.18
X-Spam-Level: 
X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[AWL=-5.420,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837, UNPARSEABLE_RELAY=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 qwlviGAY1rf3; Mon,  4 Feb 2013 18:29:40 -0800 (PST)
Received: from WIN-CDPOO5N337C (gw.ntelia.co.kr [175.196.232.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0521F8862; Mon,  4 Feb 2013 18:29:39 -0800 (PST)
Received: from mail pickup service by WIN-CDPOO5N337C with Microsoft SMTPSVC;  Tue, 5 Feb 2013 11:28:20 +0900
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
x-sender: eckelcu@cisco.com
x-receiver: hongkee67@gmail.com
Received: from mail.ietf.org ([64.170.98.30]) by WIN-CDPOO5N337C with Microsoft SMTPSVC(7.5.7601.17514); Tue, 5 Feb 2013 11:28:13 +0900
Received: from ietfa.amsl.com (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id EDDB021F8995;Mon,  4 Feb 2013 18:28:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360031292; bh=N4R+qrC9cRmOCQ15tac+TO2JpDPp3I9cgRoGwXXAw1g=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=n+1iG+8AfJvNkBEUA6ZW+LsFWnekSYlnCzgRDT1ALaBXNW9Tb2VW9w5H7BkYDXICs ng/ITRJ/0KWtjjxBpQNTW97+iwpiVFxLkIUyHMek3zVR8yXb/ktgAHQCDYl0lNnd66 cSVB9Xgv7WKCbC7/qru/J3c2LI0Qfu6OYgzA0XqY=
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id 7065D21F8727;Mon,  4 Feb 2013 18:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: 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+YMgPGomnb4; Mon,  4 Feb 2013 18:28:09 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76])by ietfa.amsl.com (Postfix) with ESMTP id AC7B721F890D; Mon,  4 Feb 2013 18:28:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2275; q=dns/txt; s=iport;t=1360031289; x=1361240889; h=from:to:subject:date:message-id:references:in-reply-to:content-transfer-encoding:mime-version; bh=iWpRYVqGPk+ouYle0tdGJo3gMkNVesZznllK1Od3tyg=; b=IWH0oXuzwZ2CxpDAyb55HucQ71KEQS3evQr+Zkk5TYj4usqTOxGcdrhOJ3EEg/kxkBJORGYEXRrxrjMVvXAuMe+FV8Ots0gRgT+wYky6T1Nm47MveaKGq54Wdf+8PlkPH71DVxbmLMBpApZWT271hZQ0Cp3UVzVHZ8aiiZUbnI 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAD5sEFGtJXG//2dsb2JhbABFv0QWc4IfAQEBBAxmEwICAgEIEQQBAQsdBxsXFAkIAgQBEgiICatvkA0EjSaDR2EDiDCeQIJvDYFvNQ
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="173276458"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191])by rcdn-iport-5.cisco.com with ESMTP; 05 Feb 2013 02:28:09 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85])by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r152S9Rn021311(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 02:28:09 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.207]) byxhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 20:28:08 -0600
From: "Charles Eckel (eckelcu)" 
To: "Magnus Westerlund" , "mmusic (E-mail)" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Draft on Multimedia concepts and relations for Intermim
Thread-Index: AQHN/6A+vrlehv19GUGvsxwr0HOEbJhqHUDA
Date: Tue, 5 Feb 2013 02:28:08 +0000
Message-ID: <1.199d195427787e1fdefa@cisco.com>
References: <510A4B7C.3000009@ericsson.com>
In-Reply-To: <510A4B7C.3000009@ericsson.com>
Accept-Language: en-US
x-originating-ip: [10.21.117.254]
MIME-Version: 1.0
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
X-OriginalArrivalTime: 05 Feb 2013 02:28:13.0928 (UTC) FILETIME=[72D2F680:01CE0348]
Content-Type: multipart/alternative; boundary="----=_NextPart_000_2590_4B93DC7D.74A586E7"
Subject: Re: [rtcweb] [MMUSIC] Draft on Multimedia concepts and relationsfor Intermim
X-BeenThere: rtcweb@ietf.org
List-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 Feb 2013 02:29:41 -0000

------=_NextPart_000_2590_4B93DC7D.74A586E7
Content-Language: en-US
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Magnus and Bo,

Thanks for putting this together, and more importantly, for attaching a cop=
y in the e-mail so I was able to access it on the plane without internet.
I agree with most of the reasoning in the various sections; however, there =
are a couple related concepts for which I'd like more clarification.

1) MediaStream
Is a MediaStream restricted to a single source? I did not think it was, but=
 the description on page 8 seems to imply this restriction. For example, co=
uld I have a single MediaStream with the following 4 MediaStreamTracks, whe=
re source 1 and source 2 are two video cameras from the same endpoint, or a=
 mic and an camera from the same endpoint:

Source 1 - encoding 1
Source 1 - encoding 2
Source 2 - encoding 1
Source 2 - encoding 2

2) PeerConnection
Later, on page 18, a related restriction of a single encoding per PC is sug=
gested. In the case of a layered encoding, this seems to imply each layer b=
eing in its own PC. Is that the recommendation being suggested?

Thanks,
Charles 



> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Magnus Westerlund
> Sent: Thursday, January 31, 2013 2:46 AM
> To: mmusic (E-mail); rtcweb@ietf.org
> Subject: [rtcweb] Draft on Multimedia concepts and relations for Intermim=

> 
> Hi,
> 
> Attached is a draft on multimedia concepts and relations that we believe
> relevant for the upcoming interim. This includes commonalties between
> WebRTC and CLUE and other RTP usages.
> 
> Sorry for the late submission, i do hope you have time to review it. At
> will also be properly submitted to IETF as soon as we figure out why the
> submission tools refuses to process it.
> 
> 
> 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
> ----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

------=_NextPart_000_2590_4B93DC7D.74A586E7
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Magnus and Bo,





Thanks for putting this together, and more importantly, for attaching a cop=
y in the e-mail so I was able to access it on the plane without internet.


I agree with most of the reasoning in the various sections; however, there =
are a couple related concepts for which I'd like more clarification.





1) MediaStream


Is a MediaStream restricted to a single source? I did not think it was, but=
 the description on page 8 seems to imply this restriction. For example, co=
uld I have a single MediaStream with the following 4 MediaStreamTracks, whe=
re source 1 and source 2 are two video cameras from the same endpoint, or a=
 mic and an camera from the same endpoint:





Source 1 - encoding 1


Source 1 - encoding 2


Source 2 - encoding 1


Source 2 - encoding 2





2) PeerConnection


Later, on page 18, a related restriction of a single encoding per PC is sug=
gested. In the case of a layered encoding, this seems to imply each layer b=
eing in its own PC. Is that the recommendation being suggested?





Thanks,


Charles 











> -----Original Message-----


> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On


> Behalf Of Magnus Westerlund


> Sent: Thursday, January 31, 2013 2:46 AM


> To: mmusic (E-mail); rtcweb@ietf.org


> Subject: [rtcweb] Draft on Multimedia concepts and relations for Inter=
mim


> 


> Hi,


> 


> Attached is a draft on multimedia concepts and relations that we belie=
ve


> relevant for the upcoming interim. This includes commonalties between


> WebRTC and CLUE and other RTP usages.


> 


> Sorry for the late submission, i do hope you have time to review it. At


> will also be properly submitted to IETF as soon as we figure out why t=
he


> submission tools refuses to process it.


> 


> 


> 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


> ----------------------------------------------------------------------=



_______________________________________________


mmusic mailing list


mmusic@ietf.org


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



------=_NextPart_000_2590_4B93DC7D.74A586E7--

From fluffy@cisco.com  Mon Feb  4 19:35:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FA021F8A47; Mon,  4 Feb 2013 19:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.182
X-Spam-Level: 
X-Spam-Status: No, score=-110.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM8p0S7px4P4; Mon,  4 Feb 2013 19:35:55 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0621F852B; Mon,  4 Feb 2013 19:35:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8134; q=dns/txt; s=iport; t=1360035355; x=1361244955; h=from:to:subject:date:message-id:references:mime-version; bh=xUXU2EkJ+L6aE+lXsscvaeeZ16Zs8Uzwhh5Tym+IZRs=; b=L8r1HFsQiTDdaoPSqfy6gzBc6FcTJR5IBWSAY0eJJcPF1n8LiOgG6wjN IPy+miZV/UzkIH1OMityR4hMBtTMIs64EeyppP+KIvbLUHMrIEiuuNtfS m5/hn31yI5xYQapnM8IOJxwFCQBGEholohHdhW+KVlKPAbiASH6q5zBqa Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAId8EFGtJV2c/2dsb2JhbAArFwO/UBZzgiABAQRmAiECARwOCgQMAwcyFBABAgEDARIIiAkMLKtGgU+OP40aG28HgkZhA5c8jzSCLEMNgW81
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600";  d="scan'208,217";a="173275162"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 05 Feb 2013 03:35:54 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r153ZsZU030549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 03:35:54 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 21:35:54 -0600
From: "Cullen Jennings (fluffy)" 
To: "" , "public-webrtc@w3.org" , mmusic WG 
Thread-Topic: Webex for  WebRTC / RTCWeb / MMusic interim meeting
Thread-Index: AQHOA1Hnb0mXRjeshEmbqUcNz+ZEDw==
Date: Tue, 5 Feb 2013 03:35:05 +0000
Message-ID: 
References: <287030554.79219.1360034826664.JavaMail.nobody@jsj6tc002.webex.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.89.1.35]
Content-Type: multipart/alternative; boundary="_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_"
MIME-Version: 1.0
Subject: [rtcweb] Webex for  WebRTC / RTCWeb / MMusic 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, 05 Feb 2013 03:35:56 -0000

--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Here is the dial in information for the interim meeting for WebRTC, RTCWeb,=
 and MMUSIC over the next few day. It is the same conference for all the me=
etings on all days to avoid the need to switch back and forth.

I find the easiest way to use this is join the web page, but then have it d=
ial you back to phone a PSTN phone line.

Please mute yourself when not speaking.

(Note the bridge is starting up at 8:00 but the meeting does not start unti=
l 8:30 )




Hello ,

Cullen Jennings invites you to attend this online meeting.

Topic: WebRTC / RTCWeb / MMusic
Date: Every 1 day, from Tuesday, February 5, 2013 to Thursday, February 7, =
2013
Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)
Meeting Number: 200 160 998
Meeting Password: acme


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW=
=3DNN2I3YzUxYjJk&RT=3DMiMxMQ%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: acme
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW=3DNN2I3Y=
zUxYjJk&ORT=3DMiMxMQ%3D%3D

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
fluffy@cisco.com


To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&ICS=3DMI&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkgeSvE1NzcP1FAQFi0Kzp6vvYe1NCey7X109lhs/gVs&=
RT=3DMiMxMQ%3D%3D


--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <2B4D0BA1CF5D5C4D8114892C36FE77EA@cisco.com>
Content-Transfer-Encoding: quoted-printable












Here is the dial in information for the interim meeting for WebRTC, RT=
CWeb, and MMUSIC over the next few day. It is the same conference for all t=
he meetings on all days to avoid the need to switch back and forth. 






I find the easiest way to use this is join the web page, but then have=
 it dial you back to phone a PSTN phone line. 







Please mute yourself when not speaking. 







(Note the bridge is starting up at 8:00 but the meeting does not start=
 until 8:30 )
















Hello , 



Cullen Jennings invites you to attend this online meeting. 



Topic: WebRTC / RTCWeb / MMusic 

Date: Every 1 day, from Tuesday, February 5, 2013 to Thursday, February 7, =
2013 

Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00) 

Meeting Number: 200 160 998 

Meeting Password: acme 





------------------------------------------------------- 

To join the online meeting (Now from mobile devices!) 

------------------------------------------------------- 

1. Go to 
https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW=
=3DNN2I3YzUxYjJk&RT=3DMiMxMQ%3D%3D


2. Enter your name and email address. 

3. Enter the meeting password: acme 

4. Click "Join Now". 



To view in other time zones or languages, please click the link: 

https=
://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW=3DNN2=
I3YzUxYjJk&ORT=3DMiMxMQ%3D%3D




---------------------------------------------------------------- 

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 

---------------------------------------------------------------- 



The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.




Please dial the local access number for your area from the list below: 

- San Jose/Milpitas (408) area: 525-6800 

- RTP (919) area: 392-3330 



------------------------------------------------------- 

To join the teleconference only 

------------------------------------------------------- 

1. Dial into Cisco WebEx (view all Global Access Numbers at 

http://cisco.com/en/US/about/doing_business/conferen=
cing/index.html


2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.




San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 



US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 



India: +91.80.4350.1111 Germany: +49.619.6773.9002 



Japan: +81.3.5763.9394 China: +86.10.8515.5666 



------------------------------------------------------- 

For assistance 

------------------------------------------------------- 

1. Go to https://cisco.webex.com/ciscosales/mc


2. On the left navigation bar, click "Support". 



You can contact me at: 

fluffy@cisco.com 





To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:


https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&I=
CS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkgeSvE1NzcP1FAQFi0=
Kzp6vvYe1NCey7X109lhs/gVs&RT=3DMiMxMQ%3D%3D













--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_--

From ron.even.tlv@gmail.com  Mon Feb  4 23:25:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D454621F8A47; Mon,  4 Feb 2013 23:25:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level: 
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=1.388,  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 PV2+IxIFuNKK; Mon,  4 Feb 2013 23:25:49 -0800 (PST)
Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B921F8A2F; Mon,  4 Feb 2013 23:25:42 -0800 (PST)
Received: by mail-ea0-f173.google.com with SMTP id i1so3149350eaa.4 for ; Mon, 04 Feb 2013 23:25:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=PJyHoTPt9Qnd/rlPNikQJ9QDLnuYAn4Ze9QzTkHrHsM=; b=iqcvIiiaNgeRqYD0KkTMQ1TXd0+n9/m4lD47c0PkakbGueYOk9P49Xas0f0RLA2rWZ sC9q+qft6MnzXVOA3QqXdppYcfMwm/bYbUX6rGN3OeJg6gbdCdNyzFScOTUTV1c8MT2Y NXvRW3/TkTxWUd4CUMEH7CQb2NSucMo2aJcV00nx5cpkFJanfFGcV+9KiY889982LvSL Gx26/5YKTbPTbAzrTETLCypOgn9g+uuyaRxqeYXGWF+up4zUggSzlwQnu8bqLTzkvxzw xGnB8+NxWxWtxBQsbhYpsnkvUNFFjQLiMXR+LbIagbD+zpOmbtX0HuDYQ8yrWn/0Qlal I8KA==
X-Received: by 10.14.201.69 with SMTP id a45mr81012990eeo.43.1360049141987; Mon, 04 Feb 2013 23:25:41 -0800 (PST)
Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id o3sm30872559eem.15.2013.02.04.23.25.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 23:25:41 -0800 (PST)
From: "Roni Even" 
To: 
Date: Tue, 5 Feb 2013 09:22:49 +0200
Message-ID: <03e701ce0371$9c8913a0$d59b3ae0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: Ac4DcYPYcPBQbgqnQMeh68L0xqSLFA==
Content-Language: en-us
Cc: rtcweb@ietf.org
Subject: [rtcweb] New Version Notification for draft-even-mmusic-multiple-streams-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: Tue, 05 Feb 2013 07:25:50 -0000

Hi,
Resubmitted with small editorial changes and some clarifying text
Roni


________________________________________
From: internet-drafts@ietf.org [internet-drafts@ietf.org]
Sent: Tuesday, February 05, 2013 9:22 AM
To: Roni Even
Cc: jonathan@vidyo.com; bill.wu@huawei.com
Subject: New Version Notification for
draft-even-mmusic-multiple-streams-01.txt

A new version of I-D, draft-even-mmusic-multiple-streams-01.txt
has been successfully submitted by Roni Even and posted to the IETF
repository.

Filename:        draft-even-mmusic-multiple-streams
Revision:        01
Title:           Describing multiple RTP media streams in SDP
Creation date:   2013-02-05
WG ID:           Individual Submission
Number of pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-even-mmusic-multiple-streams-01.tx
t
Status:
http://datatracker.ietf.org/doc/draft-even-mmusic-multiple-streams
Htmlized:
http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-even-mmusic-multiple-streams-01

Abstract:
   This document describes issues when describing multiple RTP streams
   in a single RTP session using SDP.  The document looks at current
   solutions and provides paths toward addressing the issues.




The IETF Secretariat=


From ted.ietf@gmail.com  Tue Feb  5 06:03:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C9921F889C for ; Tue,  5 Feb 2013 06:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnfHbgYypzed for ; Tue,  5 Feb 2013 06:03:35 -0800 (PST)
Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1BF21F87BB for ; Tue,  5 Feb 2013 06:03:35 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id u8so182254iag.3 for ; Tue, 05 Feb 2013 06:03:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yF08wVsVSqs+ULGu8aWjzq+9c5tXW///r7Rw6bo60lY=; b=JNjLE8ksKe9QnOTIajsw+rvpaMmsRA/7c7QKZ6AKS5jMgNRRFJDhXugaZWMTdrwe53 g9Ui0KLhH8TBXBcUkeQmEEGYLB6FJIPZspDIVnU3bKVgNb3boc5xTfdFJhO3VyI9p9WG fGfD5VfkWcuszIGWmgCe8tii3kGgzPJnA0elUaU4xvkEmLxou+Al0oXDmvDBRx0AKTaY NckIdS9ZpCtcBCsjkCEtptf4iszlPg6zjpDn+phc4l1Qey6HE23DD12nO/Do/LAkk5XA JK/YvenbFZpzyvQh5RKYuhHUbtxBVE5JJplT1OH7JJSRJFADnqbxeEBFdXxGwMYSuL1O rWUg==
MIME-Version: 1.0
X-Received: by 10.50.171.36 with SMTP id ar4mr13345991igc.70.1360073014958; Tue, 05 Feb 2013 06:03:34 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Tue, 5 Feb 2013 06:03:34 -0800 (PST)
In-Reply-To: 
References:   
Date: Tue, 5 Feb 2013 09:03:34 -0500
Message-ID: 
From: Ted Hardie 
To: Martin Thomson 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time 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: Tue, 05 Feb 2013 14:03:36 -0000

On Sun, Feb 3, 2013 at 2:05 PM, Martin Thomson  wrote:
> On 2 February 2013 18:55, Ted Hardie  wrote:
>> No, the concrete question is whether the requirement to interwork with
>> emergency services will constrain the design.
>
> I think that Bernard was addressing that question directly.  Namely:
> we do not need to constrain the design for it to be possible to
> provide emergency services.
>
"the design" is not clear here.  If you mean:  it must be possible for
a WebRTC system to be built that connects with emergency services,
then we already agree.  If you mean *all WebRTC applications* must be
buit to interwork with emergency services then we disagree.  There are
clear use cases for games, chat roulette-style casual encounter
systems, and similar that do not have any need for PSTN gateways and
for which emergency services should not be expected.  We can discuss
it more in person at the meeting, but I don't see any reason to
revisit this decision.

Again, my personal view.

Ted

From ted.ietf@gmail.com  Tue Feb  5 06:41:18 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CE621F8962 for ; Tue,  5 Feb 2013 06:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnJ+l9AVb3lG for ; Tue,  5 Feb 2013 06:41:18 -0800 (PST)
Received: from mail-ie0-x234.google.com (ie-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D7C6721F894E for ; Tue,  5 Feb 2013 06:41:17 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id bn7so253335ieb.39 for ; Tue, 05 Feb 2013 06:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NatpJHHN8dLKk3cJwF58dZQGZw58xMdFG/d0aQ3vhDQ=; b=dTKIJnl9fLf9Cf25CUOB9JO5UOaUXJ7htRYrcthzWycWIOtKS2qvtvvnBugJwPkGVZ gqU1o3OnzhGTtPLJjyq9cQVzsg5zxccNlYUBTs7q9G7BtdLjygmQoEXBDEFeolh562yI gBWzHiFBfV5+MveI5ZCZNAA5O5du+reZkLifSzj3q4Rusy4sC4jkgvPIwL888Ecbl1vA nK+iC4x12dD3s/ddzdJBWavLvxjLKekD2UpYFRfj9SL9gQNCIyMsImNofhaemDYdc6l5 3lyUYWWcW8ucSOmEemTVevkzD5+DjdNhUCQOmGdymB17hFNX0SCnkly+V2AGscAMAo2v wj6w==
MIME-Version: 1.0
X-Received: by 10.50.88.136 with SMTP id bg8mr13654292igb.96.1360075277324; Tue, 05 Feb 2013 06:41:17 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Tue, 5 Feb 2013 06:41:17 -0800 (PST)
In-Reply-To: <510EEF55.7000902@omnitor.se>
References:     <510EEF55.7000902@omnitor.se>
Date: Tue, 5 Feb 2013 09:41:17 -0500
Message-ID: 
From: Ted Hardie 
To: Gunnar Hellstrom 
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - emergency service access
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 14:41:18 -0000

On Sun, Feb 3, 2013 at 6:14 PM, Gunnar Hellstrom
 wrote:
> Right, the emergency calls need to be as mainstream as possible.

For devices that make phone calls, this is a sensible statement.  But
we're not building phone-in-a-browser.  It's entirely possible to use
RTCWEB to set up a data channel between two consenting peers where
there is no audio, no video, and no real time text but, say, games
play exchanges.  And in cases where there are audio and video streams,
there is no requirement that this be a general facility.  Look, for
example, at the puzzlible application here:
http://cargocollective.com/mimmijostell/PROTOTHON-PROJECTS.  Expecting
that this is useful to contact emergency services doesn't make sense
to me personally.

> But there are RFCs about how emergency calls are expected to appear, and
> they require a couple of "special" actions from the client and service
> provider.
> Since next generation emergency services are now planned based on these RFCs
> it is best to make sure rtcweb based systems can comply.
>
> It is mainly:
> -provide location

If you would like several months entertainment, please go back to the
ECRIT and GEOPRIV mailing lists and read up on how little emergency
services like trusting user generated location.  Then you might
consider working through how exactly we're going to get what they
would consider trustable location through browser chrome and into
javascript *that we know many come from an untrustable server* in a
way that doesn't provide a very nice attack surface indeed.

> -use SIP

In this case, that would have to be "know where there is a trustable
SIP gateway", right, since there is no requirement to use SIP in
WebRTC?

> -use supported codecs for audio, video and real-time text
> -either client or server use urn:service:sos.... addressing
>
> In order to test if it really works, a method for testing is specified in
> RFC 6443, requesting automatic loopback of a couple of RTP packets, and an
> opportunity to verify that the right emergency service was reached.
> (I am a bit afraid that the load of these test calls will be overwhelming
> for the network resources compared to real calls, and might need a
> rethinking, but they at least do not load any operational human call taker.
> So, the mechanisms you ask for are there.)
>
> It is true with all features in rtcweb that they are not required to be used
> in all application implementations. But they need to be described and
> included in the support from the browsers and APIs.
>

If you would like to describe how to build an emergency service WebRTC
app, I see know problem in your doing so.  But requiring all
applications have this facility simply misses the point of the
technology.  To repeat myself, we are not building a technology for
creating phones in browsers.

Still speaking personally,

regards,

Ted Hardie

From spencer@wonderhamster.org  Tue Feb  5 15:11:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D621F8648 for ; Tue,  5 Feb 2013 15:11:44 -0800 (PST)
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 0g9FkIO8+dQC for ; Tue,  5 Feb 2013 15:11:44 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1385C21F8630 for ; Tue,  5 Feb 2013 15:10:49 -0800 (PST)
Received: from [192.168.2.75] (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M8lzI-1UF0ji1dyG-00CMD5; Tue, 05 Feb 2013 18:10:48 -0500
Message-ID: <5111916F.2030509@wonderhamster.org>
Date: Tue, 05 Feb 2013 17:10:39 -0600
From: Spencer Dawkins 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:woXpf9P/VS4W1irS7WNy5R8RWYFuANBjIHuIKU3otwj AhJZ/nlMcR5lHFRnuX8aHCGmekO8X2QuHd3Mq0wptNiqmrkSXL H3i5n1OvJAsKLESMu7n77RkmcAc5Uv6o8uxBl4+1wI8dYNe5vz G4R5F9FzjSTwXSqLCt1uhuZQ17BEJXLbVQ1fNYIouVrg4MYIIn OAHLTWjK4CI9YTOFLPuR0yVxEgFamEfNR6+XZUWHsLor1kszfa oTKSdLHxjSyAehV5aKKU3/O5TDCDEH18DRposs2WsO99wsoui+ RF50rVoXUGzn1DBoJsRVQu0nSAXrAq+iwzo4ZQYBhkAMbLsJyr halMjiv40Ipf8B+r72KjKzo04UMX71tyRNrVhmUzO
Subject: [rtcweb] My notes (decisions and action items only)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 23:11:44 -0000

* Decision - we won't use the words "media stream" without an identifier 
for context, and we'll consider changing terms to "avocado, chicken and 
fleen"

* Action item to develop new terms? Jonathan will provide the list of 
laggards who volunteered to help him do that, and the chairs will nag them

* decision - ask w3c to change terms to "track sets, etc.? Hands in the 
room were not conclusive

* action - Ted will capture Jonathan's comments at the mike for 
inclusion in RTCWeb documents. Dale Worley asked that "RTP session" be 
included in the rune reading

* Action - for Richard Ejzak to think about doing a use case-by-use case 
analysis of the various approaches

Option 1 - driven by broader RTCWeb use cases

14 hands

Option 2 - add CLUE use cases

9 hands

Option 3 - add any offer/answer use cases

4 hands


From harald@alvestrand.no  Tue Feb  5 20:28:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEA021F8996; Tue,  5 Feb 2013 20:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4rhROcnBylN; Tue,  5 Feb 2013 20:28:35 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0A221F8988; Tue,  5 Feb 2013 20:28:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDF4539E130; Wed,  6 Feb 2013 05:28:32 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw+-W7JA5fiO; Wed,  6 Feb 2013 05:28:32 +0100 (CET)
Received: from [192.168.5.247] (216-206-165-162.dia.static.qwest.net [216.206.165.162]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A6EDF39E0C8; Wed,  6 Feb 2013 05:28:31 +0100 (CET)
Message-ID: <5111DBEE.20501@alvestrand.no>
Date: Wed, 06 Feb 2013 05:28:30 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: mmusic , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="------------030404010108030502030206"
Subject: [rtcweb] The 171-attribute spreadsheet
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 04:28:36 -0000

This is a multi-part message in MIME format.
--------------030404010108030502030206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Just in case anyone else lost the link, the spreadsheet with all defined 
SDP attributes that an m-line can have is here:

https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0

Everyone with the link should be able to edit.

             Harald


--------------030404010108030502030206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Just in case anyone else lost the link, the spreadsheet with all
    defined SDP attributes that an m-line can have is here:

    

    
    https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0

    

    Everyone with the link should be able to edit.

    

                Harald

    

  


--------------030404010108030502030206--

From ari.keranen@ericsson.com  Wed Feb  6 08:58:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECDB21F855D; Wed,  6 Feb 2013 08:58:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.349
X-Spam-Level: 
X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=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 KyUQF91MIY+p; Wed,  6 Feb 2013 08:58:36 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 367F321F8569; Wed,  6 Feb 2013 08:58:36 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-93-51128bbaf91c
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.BB.19728.ABB82115; Wed,  6 Feb 2013 17:58:35 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 6 Feb 2013 17:58:34 +0100
Received: from As-MacBook-Air.local (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 450B5233F; Wed,  6 Feb 2013 18:58:33 +0200 (EET)
Message-ID: <51128BB8.3080808@ericsson.com>
Date: Wed, 6 Feb 2013 11:58:32 -0500
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Roni Even 
References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com>
In-Reply-To: <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvre7ubqFAgwXvOCz+7U2ymLr8MYvF 33Zmizm7HjBZrP3Xzu7A6rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoErY+KcLtaC mRIVzc2z2RoY3wl3MXJySAiYSEyZ+p8RwhaTuHBvPVsXIxeHkMBJRokHuycxQTjrGSWar1xi hHC2MEp0dE9l72Lk4OAV0Ja4NNcJpJtFQEXiRsMlJhCbTcBe4uaE6+wgtqhAskTbrYMsIDav gKDEyZlPwGwRATWJ12s/s4HYzEA1D7d+BOsVBhq5eF4T2EVCAuESe7r7wGo4BSwk1s6bwAJR bytxYc51KFteYvvbOcwQ9aoSV/+9YpzAKDQLybpZSFpmIWlZwMi8ipE9NzEzJ73caBMjMKAP bvmtuoPxzjmRQ4zSHCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDOL5qZ/O5z ytS3Xrf/h58IDSn6/TfzQouhiOmUBytrbPur7+kY70lvvNrAkmXw1HHqp0nW5QvmPV9W/sDO PlT+dd5bnbv/bN523EnKXvtr8QqW9sk1ar/PmhY37ml3mPuluMh04ROde82qgg9sJv0zXPqG pWLJguM7Tb6s3f73nLh3k+062SJXJZbijERDLeai4kQAPiX2ITYCAAA=
X-Mailman-Approved-At: Wed, 06 Feb 2013 13:31:19 -0800
Cc: mmusic-chairs@tools.ietf.org, rtcweb@ietf.org, rtcweb-chairs@tools.ietf.org, mmusic@ietf.org
Subject: Re: [rtcweb] Boston meeting agenda
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 16:58:37 -0000

Hi,

The agenda is (roughly) still as shown below. The afternoon sessions 
(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material 
(including chair slides with updated agenda) is available here:
http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.html


Cheers,
Ari

On 2/4/13 11:53 AM, Roni Even wrote:
> Hi,
> Is there a final agenda with time schedule. There is no relation between the
> agenda here and i=the one for mmusic and rtcweb in the reference.
> I would like to attend from remote and since there is time difference it
> will be helpful to plan ahead.
> Thanks
> Roni Even who will try to attend from remote being 7 hours ahead of Boston
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Stefan H?kansson LK
> Sent: 30 January, 2013 11:51 AM
> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org;
> public-media-capture@w3.org
> Subject: [rtcweb] Boston meeting agenda
>
> All,
>
> below is a merged agenda covering both W3C and IETF parts of the meeting.
> Details are likely to change - the main message is that W3C meetings will be
> before lunch, and IETF after. Before lunch could mean
> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A hard
> stop is planned for 17:00 on Feb 7th as many have planes to catch.
>
> (The sources used to assemble the agenda below are the W3C meeting wiki's,
> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]).
>
> --Stefan (for all involved chairs)
>
> Feb 5th
> =======
> Morning session: W3C Media Capture TF
> -------------------------------------
> * device enumeration
> * error handling
> * "immediate stream" gUM
> * Resource reservation
>
> Afternoon session: IETF mmusic and rtcweb WGs
> ---------------------------------------------
> * Multiple Flow SDP representation
> * SDP for Data channels
>
> Feb 6th
> =======
> Morning session: W3C Media Capture TF + WebRTC WG
> -------------------------------------------------
> * Identity aspects of MediaStreams (MediaCap)
> * Settings/constraints (MediaCap)
> * Recording (MediaCap)
> * Call flow (WebRTC)
>
> Afternoon session: IETF mmusic and rtcweb WGs
> ---------------------------------------------
> * SDP Grouping (Bundle/MMT/one-rtp)
> * Mapping stream/track label concepts to SDP identifiers
>
> Feb 7th
> =======
> Morning session: W3C WebRTC WG
> ------------------------------
> * MediaStream and MediaStreamTrack - SDP interface
> * Error handling
> * Data channel
> * Stats
>
> Afternoon session: IETF mmusic and rtcweb WGs
> ---------------------------------------------
> * Trickle ICE
> * JSEP
>
> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013
> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013
> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From keith.drage@alcatel-lucent.com  Wed Feb  6 13:52:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AD321F856E; Wed,  6 Feb 2013 13:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.989
X-Spam-Level: 
X-Spam-Status: No, score=-106.989 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 LkH9wk-xKYtK; Wed,  6 Feb 2013 13:52:23 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id D44B521F855F; Wed,  6 Feb 2013 13:52:22 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r16Lq8Kn006161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Feb 2013 22:52:16 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 6 Feb 2013 22:52:06 +0100
From: "DRAGE, Keith (Keith)" 
To: Harald Alvestrand , mmusic , "rtcweb@ietf.org" 
Date: Wed, 6 Feb 2013 22:51:57 +0100
Thread-Topic: [rtcweb] The 171-attribute spreadsheet
Thread-Index: Ac4EInPfiio0UcNGTq+Gcc59EyknewAkIWzw
Message-ID: 
References: <5111DBEE.20501@alvestrand.no>
In-Reply-To: <5111DBEE.20501@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [rtcweb] The 171-attribute spreadsheet
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 21:52:24 -0000

--_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is still missing any criteria for deciding whether something is in or =
out. I assume importance to RTCWEB has only two values from what I can see =
(1 =3D important, 0 =3D not important). I believe I could make a use case f=
or all of these being supported, I'm sure all of them can be found in SDP w=
hen interworking - the question is whether any of these cases are useful to=
 applications or not, and whether an otherwise successful communication wou=
ld fail if an attribute was not understood, and therefore dropped.

I can solve the problem of g.3gpp.cat and g.3gpp.crs for you. These are mis=
registrations and are in fact values of the content attribute (which is mis=
sing from your list because it has only just been inserted as a correction,=
 and probably is important to RTCWEB). It is in the process of being sorted=
 but requires some changes to the registration data in the references speci=
fication to make things clear.

Keith



________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Harald Alvestrand
Sent: 06 February 2013 04:29
To: mmusic; rtcweb@ietf.org
Subject: [rtcweb] The 171-attribute spreadsheet

Just in case anyone else lost the link, the spreadsheet with all defined SD=
P attributes that an m-line can have is here:

https://docs.google.com/spreadsheet/ccc?key=3D0Av-aF69sk5C6dDhPblpRV2pkbXVG=
NV9lUFI3cHlIRFE#gid=3D0

Everyone with the link should be able to edit.

            Harald

--_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















This is still missing any criteria for
deciding whether something is in or out. I assume importance to RTCWEB has =
only
two values from what I can see (1 =3D important, 0 =3D not important). I be=
lieve I
could make a use case for all of these being supported, I’m sure all =
of
them can be found in SDP when interworking – the question is whether =
any
of these cases are useful to applications or not, and whether an otherwise
successful communication would fail if an attribute was not understood, and
therefore dropped.



 



I can solve the problem of g.3gpp.cat =
and
g.3gpp.crs for you. These are misregistrations and are in fact values of th=
e
content attribute (which is missing from your list because it has only just
been inserted as a correction, and probably is important to RTCWEB). It is =
in
the process of being sorted but requires some changes to the registration d=
ata
in the references specification to make things clear.



 



Keith



 



 



 


















From: rtcweb-bounces@ietf.org
[mailto:rtcweb-bounces@ietf.org] On Beh=
alf Of
Harald Alvestrand

Sent: 06 February 2013 04:29=


To: mmusic; rtcweb@ietf.org<=
br>
Subject: [rtcweb] The
171-attribute spreadsheet






=
 



Just in case anyo=
ne else
lost the link, the spreadsheet with all defined SDP attributes that an m-li=
ne
can have is here:



https://docs.google.com/spreadsheet/ccc?ke=
y=3D0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=3D0



Everyone with the link should be able to edit.



            Harald












--_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_--

From tterriberry@mozilla.com  Wed Feb  6 14:42:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6919221E8041; Wed,  6 Feb 2013 14:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.477
X-Spam-Level: 
X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=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 ryq-PtAvTkP8; Wed,  6 Feb 2013 14:42:36 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 95B0821F8526; Wed,  6 Feb 2013 14:42:36 -0800 (PST)
Received: from [192.168.2.33] (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 22F20F218D;  Wed,  6 Feb 2013 14:42:38 -0800 (PST)
Message-ID: <5112DC51.30604@mozilla.com>
Date: Wed, 06 Feb 2013 14:42:25 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: rtcweb@ietf.org, mmusic@ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Minutes from 6 Feb joint interim 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: Wed, 06 Feb 2013 22:42:37 -0000

BUNDLE, ONE-RTP, MMT:

* Note - If we proceed with MMT, we should use m=application instead of 
m=anymedia

* Decision - Are you generally okay with any of the approaches that 
reduce the number of long-lived flows to this level OR is there some 
other feature in one of the proposals you must have before this meets 
your needs?

6 for the former, 17 for the latter


Cullen's plan to dig us out of this hole:

* Proposed Superset of Requirement 2 - Should be able to interop with 
legacy without the JS doing anything special.

* Proposed Relaxation of Requirement 2 - Should be able to interop with 
legacy, but not necessarily in one O/A exchange within a single dialog 
(without relying on failure cases).

* Requirement 3 - Change video flows to media flows

* Proposed Requirement - When we have a large conference with 1000's of 
people, we don't have to send new signaling to every participant of the 
conference.

* Proposed Requirement - Must be able to configure a set of similar 
flows such that once established, the endpoints can add or remove flows 
without having to do an O/A cycle (i.e., without having to exchange SDP).

* Proposed Requirement - Have this process terminate in some finite 
period of time.

* Point of Discussion - Plan A: same port on each m-line or different 
candidate sets?

* Action - Plan B: Write the drafts to extend SDP to explicitly describe 
multiple cameras with multiple streams from each camera under a single 
m-line.

* Decision - Should we come up with a set of requirements and proceed 
with Plan A and Plan B with the timelines outlined here?

24 for, 5 against

* Note - Mary Barnes refuses to go back to work until she gets her mini 
candy bars.

DataChannel SDP

* Action - Justin to draft API for SDP-only channel open

* Decision (rtcweb hats) -
   2a) In-band only - 6
   2b) SDP & in-band - 10
   2c) SDP-only - 15
   Work on both will continue until a decision is reached.

* Action - Martin believes he can send a proposal to the list which will 
change some minds.

From harald@alvestrand.no  Wed Feb  6 19:16:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2021F84E9; Wed,  6 Feb 2013 19:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.856
X-Spam-Level: 
X-Spam-Status: No, score=-109.856 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SEca8ixin4U; Wed,  6 Feb 2013 19:16:25 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF3921E8034; Wed,  6 Feb 2013 19:16:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2973A39E0CE; Thu,  7 Feb 2013 04:16:23 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u1A1ENzTJEO; Thu,  7 Feb 2013 04:16:20 +0100 (CET)
Received: from [192.168.5.247] (216-206-165-162.dia.static.qwest.net [216.206.165.162]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 093E639E03A; Thu,  7 Feb 2013 04:16:19 +0100 (CET)
Message-ID: <51131C81.9080303@alvestrand.no>
Date: Thu, 07 Feb 2013 04:16:17 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" 
References: <5111DBEE.20501@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050505070305080005020008"
Cc: "rtcweb@ietf.org" , mmusic 
Subject: Re: [rtcweb] The 171-attribute spreadsheet
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 03:16:27 -0000

This is a multi-part message in MIME format.
--------------050505070305080005020008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 02/06/2013 10:51 PM, DRAGE, Keith (Keith) wrote:
>
> This is still missing any criteria for deciding whether something is 
> in or out. I assume importance to RTCWEB has only two values from what 
> I can see (1 = important, 0 = not important). I believe I could make a 
> use case for all of these being supported, I'm sure all of them can be 
> found in SDP when interworking -- the question is whether any of these 
> cases are useful to applications or not, and whether an otherwise 
> successful communication would fail if an attribute was not 
> understood, and therefore dropped.
>
I don't think "in" or "out" is what we're looking for.
It's either Transport, Flow or Media - which gives us a basis for seeing 
how bigthe problem is:

- under BUNDLE, there must be new rules for Transport ("pick first", 
"sum values", or "other processing")
- under "two M-lines" and MMT, theFlow attributes need to be redefined 
to be per-SSRC, or we have to decide to ignore them
- I think the Media ones are OK with either proposal, unless some usage 
of them depends on there being only one flow in an M-line, in which case 
they're really Flow, even though they're marking Media

I put in only 1 and 0 for RTCWEB because I started in on the easy cases- 
if you feel a more graded scale is useful, please suggest values!

> I can solve the problem of g.3gpp.cat and g.3gpp.crs for you. These 
> are misregistrations and are in fact values of the content attribute 
> (which is missing from your list because it has only just been 
> inserted as a correction, and probably is important to RTCWEB). It is 
> in the process of being sorted but requires some changes to the 
> registration data in the references specification to make things clear.
>
values of a=content? That's good to know about. Hope you can put notes 
on those in the "notes" columns!

> Keith
>
> ------------------------------------------------------------------------
>
> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *Harald Alvestrand
> *Sent:* 06 February 2013 04:29
> *To:* mmusic; rtcweb@ietf.org
> *Subject:* [rtcweb] The 171-attribute spreadsheet
>
> Just in case anyone else lost the link, the spreadsheet with all 
> defined SDP attributes that an m-line can have is here:
>
> https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0
>
> Everyone with the link should be able to edit.
>
>             Harald
>


--------------050505070305080005020008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 02/06/2013 10:51 PM, DRAGE, Keith
      (Keith) wrote:

    

    

      
      
      
      
      

        
This is still missing
              any criteria for
              deciding whether something is in or out. I assume
              importance to RTCWEB has only
              two values from what I can see (1 = important, 0 = not
              important). I believe I
              could make a use case for all of these being supported,
              I’m sure all of
              them can be found in SDP when interworking – the question
              is whether any
              of these cases are useful to applications or not, and
              whether an otherwise
              successful communication would fail if an attribute was
              not understood, and
              therefore dropped.

      

    

    I don't think "in" or "out" is what we're looking
              for.

              It's either Transport, Flow or Media -
                which gives us a basis for seeing how big
                  the problem is:

                    

                    - under BUNDLE, there must be new rules for
                                    Transport ("pick first", "sum
                                    values", or "other processing")

                                      - under "two M-lines" and MMT,
                                          the Flow attributes
                                              need to be redefined to be
                                              per-SSRC, or we have to decide to ignore them

                                                  - I
                                                    think the Media
                                                      ones are OK with
                                                      either proposal,
                                                        unless some
                                                        usage of them
                                                        depends on there
                                                        being only one flow
                                                          in an M-line, in
                                                          which case
                                                          they're really
                                                          Flow, even
                                                          though they're
                                                          marking
                                                          Media

                                                          

                                                          I
                                                          put in only 1
                                                          and 0 for RTCWEB
                                                          because I
                                                          started in on
                                                          the easy cases - if
                                                          you feel a
                                                          more graded
                                                          scale is
                                                          useful, please
                                                          suggest
                                                          values!

                                                          

                                                          
    

      

        

        
 

        
I can solve the
              problem of g.3gpp.cat and
              g.3gpp.crs for you. These are misregistrations and are in
              fact values of the
              content attribute (which is missing from your list because
              it has only just
              been inserted as a correction, and probably is important
              to RTCWEB). It is in
              the process of being sorted but requires some changes to
              the registration data
              in the references specification to make things clear.

      

    

    values
            of a=content? That's good to know about. Hope
              you can put notes on those in the "notes"
                columns!

                

              
    

      

        

        
 

        
Keith

        
 

        
 

        
 

        

          

            

                  

                

            
From:
                  rtcweb-bounces@ietf.org
                  [mailto:rtcweb-bounces@ietf.org] On Behalf Of
                    Harald Alvestrand

                  Sent: 06
                  February 2013 04:29

                  To:
                  mmusic; rtcweb@ietf.org

                  Subject:
                  [rtcweb] The
                  171-attribute spreadsheet

          

          
 

          
Just in case anyone else
                lost the link, the spreadsheet with all defined SDP
                attributes that an m-line
                can have is here:

                

                https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0

                

                Everyone with the link should be able to edit.

                

                            Harald

        

      

    

    

  


--------------050505070305080005020008--

From mperumal@cisco.com  Wed Feb  6 22:22:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE721F841D; Wed,  6 Feb 2013 22:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.849
X-Spam-Level: 
X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, 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 6Y1cOvEa54Ih; Wed,  6 Feb 2013 22:22:28 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 034A121F841E; Wed,  6 Feb 2013 22:22:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3839; q=dns/txt; s=iport; t=1360218148; x=1361427748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gLx8ix6/2pPQE8eSrFfbvnRPgzheiF6Ym0zE9WeFTI0=; b=ITq9fLxJRUshlA72spbBKEdoJonwqKMLZIyz7bvhqU+U6BFdQccxwiM5 v4p4x1CxSCzlrv+W7/QRCoxPas3oM8ak9LEcfcyYY4SqMZPVqXc9X8Dvj RIjiEe23xh4WqrIX/Xu8Ll6S34RqXtNGuRkEV83Al/tsK4n3FyqJ4B2hQ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAKxHE1GtJXHA/2dsb2JhbAA8CcBQFnOCHwEBAQQBAQFrBAcMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCAGICAy8c40YCYNXYQOIMJ5Dgn6BbzU
X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; d="scan'208";a="174333883"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2013 06:22:26 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r176MQ6o021814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 06:22:26 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.64]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 00:22:26 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" 
To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , Roni Even 
Thread-Topic: [MMUSIC] [rtcweb] Boston meeting agenda
Thread-Index: AQHOBIs4IjrUXcS7SkKVAgPQPh30C5ht7QJw
Date: Thu, 7 Feb 2013 06:22:26 +0000
Message-ID: 
References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> <51128BB8.3080808@ericsson.com>
In-Reply-To: <51128BB8.3080808@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.39.64.152]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic-chairs@tools.ietf.org" , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" , "mmusic@ietf.org" 
Subject: Re: [rtcweb] [MMUSIC]  Boston meeting agenda
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 06:22:29 -0000

Are we recording these sessions? Will someone be sharing the URLs for the r=
ecording?

Muthu

|-----Original Message-----
|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O=
f Ari Ker=E4nen
|Sent: Wednesday, February 06, 2013 10:29 PM
|To: Roni Even
|Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.iet=
f.org; mmusic@ietf.org
|Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda
|
|Hi,
|
|The agenda is (roughly) still as shown below. The afternoon sessions
|(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material
|(including chair slides with updated agenda) is available here:
|http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.html
|
|
|Cheers,
|Ari
|
|On 2/4/13 11:53 AM, Roni Even wrote:
|> Hi,
|> Is there a final agenda with time schedule. There is no relation between=
 the
|> agenda here and i=3Dthe one for mmusic and rtcweb in the reference.
|> I would like to attend from remote and since there is time difference it
|> will be helpful to plan ahead.
|> Thanks
|> Roni Even who will try to attend from remote being 7 hours ahead of Bost=
on
|>
|> -----Original Message-----
|> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf=
 Of
|> Stefan H?kansson LK
|> Sent: 30 January, 2013 11:51 AM
|> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org;
|> public-media-capture@w3.org
|> Subject: [rtcweb] Boston meeting agenda
|>
|> All,
|>
|> below is a merged agenda covering both W3C and IETF parts of the meeting=
.
|> Details are likely to change - the main message is that W3C meetings wil=
l be
|> before lunch, and IETF after. Before lunch could mean
|> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A =
hard
|> stop is planned for 17:00 on Feb 7th as many have planes to catch.
|>
|> (The sources used to assemble the agenda below are the W3C meeting wiki'=
s,
|> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]).
|>
|> --Stefan (for all involved chairs)
|>
|> Feb 5th
|> =3D=3D=3D=3D=3D=3D=3D
|> Morning session: W3C Media Capture TF
|> -------------------------------------
|> * device enumeration
|> * error handling
|> * "immediate stream" gUM
|> * Resource reservation
|>
|> Afternoon session: IETF mmusic and rtcweb WGs
|> ---------------------------------------------
|> * Multiple Flow SDP representation
|> * SDP for Data channels
|>
|> Feb 6th
|> =3D=3D=3D=3D=3D=3D=3D
|> Morning session: W3C Media Capture TF + WebRTC WG
|> -------------------------------------------------
|> * Identity aspects of MediaStreams (MediaCap)
|> * Settings/constraints (MediaCap)
|> * Recording (MediaCap)
|> * Call flow (WebRTC)
|>
|> Afternoon session: IETF mmusic and rtcweb WGs
|> ---------------------------------------------
|> * SDP Grouping (Bundle/MMT/one-rtp)
|> * Mapping stream/track label concepts to SDP identifiers
|>
|> Feb 7th
|> =3D=3D=3D=3D=3D=3D=3D
|> Morning session: W3C WebRTC WG
|> ------------------------------
|> * MediaStream and MediaStreamTrack - SDP interface
|> * Error handling
|> * Data channel
|> * Stats
|>
|> Afternoon session: IETF mmusic and rtcweb WGs
|> ---------------------------------------------
|> * Trickle ICE
|> * JSEP
|>
|> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013
|> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013
|> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html
|>
|>
|>
|>
|> _______________________________________________
|> rtcweb mailing list
|> rtcweb@ietf.org
|> https://www.ietf.org/mailman/listinfo/rtcweb
|>
|
|_______________________________________________
|mmusic mailing list
|mmusic@ietf.org
|https://www.ietf.org/mailman/listinfo/mmusic

From mperumal@cisco.com  Wed Feb  6 22:23:40 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81A21F8691; Wed,  6 Feb 2013 22:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.055
X-Spam-Level: 
X-Spam-Status: No, score=-4.055 tagged_above=-999 required=5 tests=[AWL=-5.794, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re6JPtMLFSEa; Wed,  6 Feb 2013 22:23:39 -0800 (PST)
Received: from WIN-CDPOO5N337C (gw.ntelia.co.kr [175.196.232.146]) by ietfa.amsl.com (Postfix) with ESMTP id D8CA121F8423; Wed,  6 Feb 2013 22:23:38 -0800 (PST)
Received: from mail pickup service by WIN-CDPOO5N337C with Microsoft SMTPSVC;  Thu, 7 Feb 2013 15:22:42 +0900
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
x-sender: mperumal@cisco.com
x-receiver: hongkee67@gmail.com
Received: from mail.ietf.org ([64.170.98.30]) by WIN-CDPOO5N337C with Microsoft SMTPSVC(7.5.7601.17514); Thu, 7 Feb 2013 15:22:34 +0900
Received: from ietfa.amsl.com (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id C559421F841F;Wed,  6 Feb 2013 22:22:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360218150; bh=76umuRuCTbee03gLqL8hCywmwEOzy4uTS4Q1LbTrur8=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QpL1Heo64rDLrXJH9NKMd0WUGKXWzNizTn7lciU916DoHdAd7g2UfN++9m1mhKrKl f6GoAhG6lnP281vCMnLJOvStRPD/0U+YjePkOAxSB+sgGFO2nO/Kydd+yNRruD1tYi 2lHhj/y1d1rJVw/7q1PFGBQ7qMnAWIzefiG+08IA=
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id 33DE721F841D;Wed,  6 Feb 2013 22:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.30])by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 6Y1cOvEa54Ih; Wed,  6 Feb 2013 22:22:28 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78])by ietfa.amsl.com (Postfix) with ESMTP id 034A121F841E; Wed,  6 Feb 2013 22:22:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3839; q=dns/txt; s=iport;t=1360218148; x=1361427748; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-transfer-encoding:mime-version; bh=gLx8ix6/2pPQE8eSrFfbvnRPgzheiF6Ym0zE9WeFTI0=; b=ITq9fLxJRUshlA72spbBKEdoJonwqKMLZIyz7bvhqU+U6BFdQccxwiM5v4p4x1CxSCzlrv+W7/QRCoxPas3oM8ak9LEcfcyYY4SqMZPVqXc9X8DvjRIjiEe23xh4WqrIX/Xu8Ll6S34RqXtNGuRkEV83Al/tsK4n3FyqJ4B2hQ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAKxHE1GtJXHA/2dsb2JhbAA8CcBQFnOCHwEBAQQBAQFrBAcMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCAGICAy8c40YCYNXYQOIMJ5Dgn6BbzU
X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; d="scan'208";a="174333883"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192])by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2013 06:22:26 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79])by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r176MQ6o021814(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 06:22:26 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.64]) by xhc-aln-x05.cisco.com([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 00:22:26 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" 
To: "=?iso-8859-1?Q?Ari_Ker=E4nen?=" , "Roni Even" 
Thread-Topic: [MMUSIC] [rtcweb] Boston meeting agenda
Thread-Index: AQHOBIs4IjrUXcS7SkKVAgPQPh30C5ht7QJw
Date: Thu, 7 Feb 2013 06:22:26 +0000
Message-ID: <1.94dc0188bed96e22f168@cisco.com>
References: <5108ED00.9090605@ericsson.com><03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com><51128BB8.3080808@ericsson.com>
In-Reply-To: <51128BB8.3080808@ericsson.com>
Accept-Language: en-US
x-originating-ip: [173.39.64.152]
MIME-Version: 1.0
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
X-OriginalArrivalTime: 07 Feb 2013 06:22:35.0159 (UTC) FILETIME=[84CC0A70:01CE04FB]
Content-Type: multipart/alternative; boundary="----=_NextPart_000_F084_A1C25FF7.C7E57345"
Cc: "mmusic-chairs@tools.ietf.org" , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" , "mmusic@ietf.org" 
Subject: Re: [rtcweb] [MMUSIC]  Boston meeting agenda
X-BeenThere: rtcweb@ietf.org
List-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 Feb 2013 06:23:40 -0000

------=_NextPart_000_F084_A1C25FF7.C7E57345
Content-Language: en-US
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Are we recording these sessions? Will someone be sharing the URLs for the r=
ecording?

Muthu

|-----Original Message-----
|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O=
f Ari Ker=E4nen
|Sent: Wednesday, February 06, 2013 10:29 PM
|To: Roni Even
|Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.iet=
f.org; mmusic@ietf.org
|Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda
|
|Hi,
|
|The agenda is (roughly) still as shown below. The afternoon sessions
|(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material
|(including chair slides with updated agenda) is available here:
|http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.html=

|
|
|Cheers,
|Ari
|
|On 2/4/13 11:53 AM, Roni Even wrote:
|> Hi,
|> Is there a final agenda with time schedule. There is no relation between=
 the
|> agenda here and i=3Dthe one for mmusic and rtcweb in the reference.
|> I would like to attend from remote and since there is time difference it=

|> will be helpful to plan ahead.
|> Thanks
|> Roni Even who will try to attend from remote being 7 hours ahead of Bost=
on
|>
|> -----Original Message-----
|> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf=
 Of
|> Stefan H?kansson LK
|> Sent: 30 January, 2013 11:51 AM
|> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org;
|> public-media-capture@w3.org
|> Subject: [rtcweb] Boston meeting agenda
|>
|> All,
|>
|> below is a merged agenda covering both W3C and IETF parts of the meeting.
|> Details are likely to change - the main message is that W3C meetings wil=
l be
|> before lunch, and IETF after. Before lunch could mean
|> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A =
hard
|> stop is planned for 17:00 on Feb 7th as many have planes to catch.
|>
|> (The sources used to assemble the agenda below are the W3C meeting wiki'=
s,
|> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]).
|>
|> --Stefan (for all involved chairs)
|>
|> Feb 5th
|> =3D=3D=3D=3D=3D=3D=3D
|> Morning session: W3C Media Capture TF
|> -------------------------------------
|> * device enumeration
|> * error handling
|> * "immediate stream" gUM
|> * Resource reservation
|>
|> Afternoon session: IETF mmusic and rtcweb WGs
|> ---------------------------------------------
|> * Multiple Flow SDP representation
|> * SDP for Data channels
|>
|> Feb 6th
|> =3D=3D=3D=3D=3D=3D=3D
|> Morning session: W3C Media Capture TF + WebRTC WG
|> -------------------------------------------------
|> * Identity aspects of MediaStreams (MediaCap)
|> * Settings/constraints (MediaCap)
|> * Recording (MediaCap)
|> * Call flow (WebRTC)
|>
|> Afternoon session: IETF mmusic and rtcweb WGs
|> ---------------------------------------------
|> * SDP Grouping (Bundle/MMT/one-rtp)
|> * Mapping stream/track label concepts to SDP identifiers
|>
|> Feb 7th
|> =3D=3D=3D=3D=3D=3D=3D
|> Morning session: W3C WebRTC WG
|> ------------------------------
|> * MediaStream and MediaStreamTrack - SDP interface
|> * Error handling
|> * Data channel
|> * Stats
|>
|> Afternoon session: IETF mmusic and rtcweb WGs
|> ---------------------------------------------
|> * Trickle ICE
|> * JSEP
|>
|> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013
|> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013
|> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html
|>
|>
|>
|>
|> _______________________________________________
|> rtcweb mailing list
|> rtcweb@ietf.org
|> https://www.ietf.org/mailman/listinfo/rtcweb
|>
|
|_______________________________________________
|mmusic mailing list
|mmusic@ietf.org
|https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

------=_NextPart_000_F084_A1C25FF7.C7E57345
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Are we recording these sessions? Will someone be sharing the URLs for the r=
ecording?





Muthu





|-----Original Message-----


|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O=
f Ari Ker=E4nen


|Sent: Wednesday, February 06, 2013 10:29 PM


|To: Roni Even


|Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.iet=
f.org; mmusic@ietf.org


|Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda


|


|Hi,


|


|The agenda is (roughly) still as shown below. The afternoon sessions


|(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material


|(including chair slides with updated agenda) is available here:


|http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.html=



|


|


|Cheers,


|Ari


|


|On 2/4/13 11:53 AM, Roni Even wrote:


|> Hi,


|> Is there a final agenda with time schedule. There is no relation betw=
een the


|> agenda here and i=3Dthe one for mmusic and rtcweb in the reference.


|> I would like to attend from remote and since there is time difference=
 it


|> will be helpful to plan ahead.


|> Thanks


|> Roni Even who will try to attend from remote being 7 hours ahead of B=
oston


|>


|> -----Original Message-----


|> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beh=
alf Of


|> Stefan H?kansson LK


|> Sent: 30 January, 2013 11:51 AM


|> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org;


|> public-media-capture@w3.org


|> Subject: [rtcweb] Boston meeting agenda


|>


|> All,


|>


|> below is a merged agenda covering both W3C and IETF parts of the meet=
ing.


|> Details are likely to change - the main message is that W3C meetings =
will be


|> before lunch, and IETF after. Before lunch could mean


|> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC.=
 A hard


|> stop is planned for 17:00 on Feb 7th as many have planes to catch.


|>


|> (The sources used to assemble the agenda below are the W3C meeting wi=
ki's,


|> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]).


|>


|> --Stefan (for all involved chairs)


|>


|> Feb 5th


|> =3D=3D=3D=3D=3D=3D=3D


|> Morning session: W3C Media Capture TF


|> -------------------------------------


|> * device enumeration


|> * error handling


|> * "immediate stream" gUM


|> * Resource reservation


|>


|> Afternoon session: IETF mmusic and rtcweb WGs


|> ---------------------------------------------


|> * Multiple Flow SDP representation


|> * SDP for Data channels


|>


|> Feb 6th


|> =3D=3D=3D=3D=3D=3D=3D


|> Morning session: W3C Media Capture TF + WebRTC WG


|> -------------------------------------------------


|> * Identity aspects of MediaStreams (MediaCap)


|> * Settings/constraints (MediaCap)


|> * Recording (MediaCap)


|> * Call flow (WebRTC)


|>


|> Afternoon session: IETF mmusic and rtcweb WGs


|> ---------------------------------------------


|> * SDP Grouping (Bundle/MMT/one-rtp)


|> * Mapping stream/track label concepts to SDP identifiers


|>


|> Feb 7th


|> =3D=3D=3D=3D=3D=3D=3D


|> Morning session: W3C WebRTC WG


|> ------------------------------


|> * MediaStream and MediaStreamTrack - SDP interface


|> * Error handling


|> * Data channel


|> * Stats


|>


|> Afternoon session: IETF mmusic and rtcweb WGs


|> ---------------------------------------------


|> * Trickle ICE


|> * JSEP


|>


|> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013


|> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013


|> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html=



|>


|>


|>


|>


|> _______________________________________________


|> rtcweb mailing list


|> rtcweb@ietf.org


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


|>


|


|_______________________________________________


|mmusic mailing list


|mmusic@ietf.org


|https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________


mmusic mailing list


mmusic@ietf.org


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



------=_NextPart_000_F084_A1C25FF7.C7E57345--

From martin.thomson@gmail.com  Thu Feb  7 03:22:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B488121F85E8 for ; Thu,  7 Feb 2013 03:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.500,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUc5BwTiTBkq for ; Thu,  7 Feb 2013 03:22:32 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4821E21F85CB for ; Thu,  7 Feb 2013 03:22:31 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id r6so1966893wey.33 for ; Thu, 07 Feb 2013 03:22:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=MZSrzZHUg151/Xd07il8lWNfvzWfeJ3IM+5tyuGY8fI=; b=LSN/h3ACOZbfzw2VJqQulWzogZFxkPUIE4hXDOOViAOfJTVH2S+KyzZKN651vdWD9q s9T2DiRrKc8T4vLXV0xmKGXVwbCN0vpPn19RIWvvbhD9l90lqWmvqD0+8CHbE1CYnHnw tA2WuixRijA9l/dAmFUtHXYdW9y2SGzaYWGuL32BZJZEAPtClP2lHpqpw4B5SEuryUAv ght82xkP1bnrzlCt5/ZiC69gOItHWWnAMXBhisdMRfaqksm2+qY45kdxOx7VHtFzMu5o iRg06tdx1LuT3QJ9sOPAWnnZGU4DEYWjtBjNJykQRkreqESM0coyvlWFj6Vsq3ynDwaJ ezug==
MIME-Version: 1.0
X-Received: by 10.180.90.147 with SMTP id bw19mr10977688wib.28.1360236135701;  Thu, 07 Feb 2013 03:22:15 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Thu, 7 Feb 2013 03:22:15 -0800 (PST)
Date: Thu, 7 Feb 2013 06:22:15 -0500
Message-ID: 
From: Martin Thomson 
To: "rtcweb@ietf.org" , Randell Jesup 
Content-Type: text/plain; charset=UTF-8
Subject: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 11:22:35 -0000

We're a fickle lot.  It seems that decisions can be unmade very easily.

In any case, I promised a concrete proposal.  Here it is.  Beware:
long post ahead.

This proposal is progressive, I think that the best option would be to
take all of it, but we could choose to not adopt the later parts.
I'll start with the basics.

==Layer 1

Negotiate all new data channels with SDP offer/answer.

As I understand it, the 1.5 round trip cost for in-band channel
creation was to prevent glare.  (Randell hinted that there might have
been something else that was SCTP-specific, but this appears to reduce
to a straightforward glare situation.)  Doing the negotiation in SDP
lets us use the glare mitigation mechanisms we have built into SDP, so
we save 0.5 round trips for every new channel.

This allows us to ditch the in-band signaling protocol almost entirely
(see Option B below).

Creating a new data channel triggers the onnegotiationneeded event.

==Layer 2

Zero round trip channel establishment

The only reason that we have for negotiation of each channel is to
provide a consistent set of characteristics for each channel.  The
peer that creates a channel decides the values for label,
retransmission count (0, n, infinite), and subprotocol.  If you don't
care about these values being consistent between peers, or you have
another means of ensuring consistency, you don't need to negotiate new
channels at all.

Here, we permit the use of additional channels immediately after
creation, without negotiation.  This has several advantages...and
ramifications.  And no real drawbacks.

Firstly, the arrival of a packet on a stream that is not negotiated
will require the creation of a data channel.  The properties of this
data channel will be largely unknown. The browser can possibly detect
that the channel is unreliable if the packet doesn't request
acknowledgement, but that's something I'm not 100% clear on for
partially reliable messages.  As a result, the browser will be
required to leave these properties undefined or generate default
values for them.

It's perfectly OK to have default or undefined values for label,
reliability and subprotocol as long as you let the application set new
values.  This allows for another advantage: applications can, if they
choose, set the reliability on a per-packet basis, consistent with all
other SCTP APIs, but setting the property before sending each packet.
This keeps the simplicity of the API design, ensures websocket
compatibility for those that need it, but it exposes more SCTP
capabilities to those that desire those features.

This does have consequences for negotiation: Values for label,
reliability and subprotocol need to be declarative in SDP, not
negotiated.  Both peers would be required to signal the values that
they are using for each stream.  This would allow for the fact that
peers could set different values for the same stream number, based on
whatever values are set on their data channel object.  In the general
case, it allows one peer to declare the use of a particular stream and
the other peer to not advertise anything on the matching stream.

This also makes the 'onopen' event useless for all but the first
channel.  It should fire immediately for any channel that is created
when the association is already active.

Receipt of a message on a channel that has not already been created
locally causes the following events, one after the other:
ondatachannel, onopen, onmessage.

In order to maintain the symmetrical usage pattern, and the
websockets-compatible usage pattern, we would then require several
things:
1. The browser MUST, by default, negotiate streams with values that
match any in an offer if it does not already have a data channel for
that stream number.  The browser MUST also create the corresponding
data channels.
2. Applications that require perfect channel symmetry need to
negotiate before using streams.
3. Applications that care about having their use of the API be
interchangeable with websockets need to wait for the 'onopen' event
before sending anything, lest they get errors when switching to
websockets.

On that last point: We could require that channels reject attempts to
send() prior to the onopen event being processed, but that is
unnecessarily mean.  Calling createDataChannel() followed immediately
by send() should be OK as long as the association is active.  Just
because you haven't processed the 'onopen', doesn't mean that you
should be prevented from using a perfectly usable channel.  Of course,
waiting for onopen would be safest in the general case, and many
applications would naturally do this, but I see no reason to constrain
usage patterns unnecessarily.

===Option A

Removing the in-band protocol makes the negotiation of the protocol
that layers on top of SCTP less crucial ... it makes negotiation of
the upper-layer protocol less crucial.  In the WebRTC case, we
probably don't need to negotiate 'webrtc-datachannel', we could even
let the application decide the value for that label.

Personally, I don't think that we need to surface API to enable
changing protocols.  However, it would be completely harmless in this
configuration for an application to change the protocol label to
something else by editing SDP, so that they could interoperate with a
peer that expected another protocol.  That would enable CLUE usage, or
BFCP, or whatever, as long as you can find someone who talks SCTP over
DTLS over UDP.

===Option B

The one remnant of the in-band protocol that remains is the parts that
apply to the data payloads.  The in-band protocol is required to
provide two features:
1. the ability to distinguish between textual data and binary data
2. the ability to send messages of arbitrary length

I am sorely tempted to suggest that the first feature can instead be
part of channel configuration, such that it is negotiated (with a
default of binary).  This would mean that negotiation is needed if you
want to use text and you can't handle the conversion of binary to
text.  (Sadly, this isn't made easy and the top answer at
stackoverflow doesn't work for UTF-8:
http://stackoverflow.com/questions/6965107/converting-between-strings-and-arraybuffers)

For the second, draft-jesup-rtcweb-data-protocol indicates that 2Gb is
the limit, but my reading of RFC 4920 indicates that there is no limit
to message size.  I'm far from expert in this area, but is it possible
that this is an implementation limitation rather than a protocol one?
Either way, I'm tempted to suggest that fragmentation can be pushed to
the application.

This would allow for direct access to SCTP, rather than an
encapsulated layer.  This is good for several reasons.  Firstly, we
don't need to specify a protocol at all.  We avoid all the arguments
about what byte goes where.  More importantly, it leaves the SCTP
clean, allowing WebRTC applications to use SCTP without ornamentation.

===Option C

If you care about reconciling the values for label, reliability, and
subprotocol, it might be necessary to surface the values declared by
your peer in the API.  You can get this information from the SDP, but
if you don't like the idea of SDP spelunking you have two choices:
provide an 'on(re)negotiated' event that carries the values declared
by the remote peer; or, provide read-only accessors for these.

I'm not certain that reconciliation of these values is important.
Applications can even build their own mechanisms if it is.  If we must
build more mechanisms, then I tend to favor the 'on(re)negotiated'
event.

From ron.even.tlv@gmail.com  Thu Feb  7 04:44:52 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279B721F854C; Thu,  7 Feb 2013 04:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Level: 
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.356,  BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=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 hNHe9ehrul2t; Thu,  7 Feb 2013 04:44:51 -0800 (PST)
Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3114621F853E; Thu,  7 Feb 2013 04:44:51 -0800 (PST)
Received: by mail-ee0-f54.google.com with SMTP id c41so1364178eek.27 for ; Thu, 07 Feb 2013 04:44:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Tb0Lx49RK8Wx6RF6KTBTSGm1+MNYJkuRpzrTGkwqDV8=; b=cMfmPnf35tM5qrgHhjRHNzMyj9JVF2Swf4Npd7mb1cxJfLD2UYM0a4C7VnSJsSbnKx IxTWllOZztDhVi6ESwGKQ1xVaMlTcfnrGlLHzmgd/FixUQ3O6TwF23sMhxGxSotyGq+w 5RBE2jbn2s6eZFWeO9XJ6pGTTLEHfZ9wzeUEXPp/HjxDKgDQopqNX/5Zu6bU1dPFKvrC 3AE55VoEg4CZO57bL6C6ZnkWk1MhZAdJIH26FySzEmFr4c6uDJwz5JyvO5txeFLKsf4g IQpKfm5LgPfh3RhD4VifG1JUO6AC0wEbZDJK0Esx02pqRudQP5+st+dsHUT0ycYchHD1 BUKQ==
X-Received: by 10.14.174.197 with SMTP id x45mr3946686eel.5.1360241090041; Thu, 07 Feb 2013 04:44:50 -0800 (PST)
Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id t4sm41902252eel.0.2013.02.07.04.44.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Feb 2013 04:44:48 -0800 (PST)
From: "Roni Even" 
To: "'Timothy B. Terriberry'" , , 
References: <5112DC51.30604@mozilla.com>
In-Reply-To: <5112DC51.30604@mozilla.com>
Date: Thu, 7 Feb 2013 14:41:43 +0200
Message-ID: <056601ce0530$84f99000$8eecb000$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQGNAesojb2nU8D/T/W2cOyhIBJiDZjwXAgg
Content-Language: en-us
Subject: Re: [rtcweb] [MMUSIC] Minutes from 6 Feb joint interim 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: Thu, 07 Feb 2013 12:44:52 -0000

Hi,
On Action - Plan B: Write the drafts to extend SDP to explicitly describe
multiple cameras with multiple streams from each camera under a single
m-line.

We did it in CLUE look at
http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04  examples is
section 6.1 and 6.2. (6.2 was taken out in the 05 version since we agreed in
CLUE that simulcast is out of scope for CLUE)

Roni Even


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
Timothy B. Terriberry
Sent: 07 February, 2013 12:42 AM
To: rtcweb@ietf.org; mmusic@ietf.org
Subject: [MMUSIC] Minutes from 6 Feb joint interim session

BUNDLE, ONE-RTP, MMT:

* Note - If we proceed with MMT, we should use m=application instead of
m=anymedia

* Decision - Are you generally okay with any of the approaches that reduce
the number of long-lived flows to this level OR is there some other feature
in one of the proposals you must have before this meets your needs?

6 for the former, 17 for the latter


Cullen's plan to dig us out of this hole:

* Proposed Superset of Requirement 2 - Should be able to interop with legacy
without the JS doing anything special.

* Proposed Relaxation of Requirement 2 - Should be able to interop with
legacy, but not necessarily in one O/A exchange within a single dialog
(without relying on failure cases).

* Requirement 3 - Change video flows to media flows

* Proposed Requirement - When we have a large conference with 1000's of
people, we don't have to send new signaling to every participant of the
conference.

* Proposed Requirement - Must be able to configure a set of similar flows
such that once established, the endpoints can add or remove flows without
having to do an O/A cycle (i.e., without having to exchange SDP).

* Proposed Requirement - Have this process terminate in some finite period
of time.

* Point of Discussion - Plan A: same port on each m-line or different
candidate sets?

* Action - Plan B: Write the drafts to extend SDP to explicitly describe
multiple cameras with multiple streams from each camera under a single
m-line.

* Decision - Should we come up with a set of requirements and proceed with
Plan A and Plan B with the timelines outlined here?

24 for, 5 against

* Note - Mary Barnes refuses to go back to work until she gets her mini
candy bars.

DataChannel SDP

* Action - Justin to draft API for SDP-only channel open

* Decision (rtcweb hats) -
   2a) In-band only - 6
   2b) SDP & in-band - 10
   2c) SDP-only - 15
   Work on both will continue until a decision is reached.

* Action - Martin believes he can send a proposal to the list which will
change some minds.
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


From mary.ietf.barnes@gmail.com  Thu Feb  7 06:01:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7340B21F86AF; Thu,  7 Feb 2013 06:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103
X-Spam-Level: 
X-Spam-Status: No, score=-103 tagged_above=-999 required=5 tests=[AWL=-0.601,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNvNZc10qLvX; Thu,  7 Feb 2013 06:01:50 -0800 (PST)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7E521F866D; Thu,  7 Feb 2013 06:01:50 -0800 (PST)
Received: by mail-qe0-f54.google.com with SMTP id 1so1195459qeb.13 for ; Thu, 07 Feb 2013 06:01:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=jluss0Hq53aD8TzghcCwvlYqxWMrGoCUdHmkGFPliLo=; b=RMEZvx4Ay7desktp17uY1axmiI2qLhK2vhPCdpX4nzwDyrxKbRnxE3pOp44sNnJW7q 7aJ2vh1SeECFK1M10fsSfdNz4hRmkZGb6p6ZDZ2vY55Dv+wQ6XKeyn9ZA0O4ipcYR6pn ZkT3ITlBXcq9aSJfXWR1aEphwaYoyVWYVonWqr6tf5FZUMcmTnwYwYUuHOHUFIbY/cT/ XdY0W6/BEZv4RpdHflXICkBa09+Ida33JHUZf/LAJk9u6fdwlojzk2jYMtiWwHHIbY7I t4k/UyqEDdXqzyUB+gprS5ntd9q8NrJer4gH0j9VbgaLhrNl35FttvP40mmPfv/5RFJ1 V4ww==
MIME-Version: 1.0
X-Received: by 10.49.72.136 with SMTP id d8mr588017qev.62.1360245709612; Thu, 07 Feb 2013 06:01:49 -0800 (PST)
Received: by 10.49.131.199 with HTTP; Thu, 7 Feb 2013 06:01:49 -0800 (PST)
In-Reply-To: <1.94dc0188bed96e22f168@cisco.com>
References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> <51128BB8.3080808@ericsson.com> <1.94dc0188bed96e22f168@cisco.com>
Date: Thu, 7 Feb 2013 08:01:49 -0600
Message-ID: 
From: Mary Barnes 
To: "Muthu Arul Mozhi Perumal (mperumal)" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , "rtcweb-chairs@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [rtcweb] [MMUSIC] Boston meeting agenda
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 14:01:51 -0000

The intent was to record the Webex sessions, thus a link to the
recordings should be posted in the meeting minutes.  However, the
recording for the Feb. 6th session yesterday wasn't started until
partway into the session so there will be a gap.  Hopefully, someone
will remember to start the recording at the beginning of the session
tomorrow.

Mary.

On Thu, Feb 7, 2013 at 12:22 AM, Muthu Arul Mozhi Perumal (mperumal)
 wrote:
> Are we recording these sessions? Will someone be sharing the URLs for the
> recording?
>
> Muthu
>
> |-----Original Message-----
> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf=
 Of
> Ari Ker=E4nen
> |Sent: Wednesday, February 06, 2013 10:29 PM
> |To: Roni Even
> |Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org;
> rtcweb-chairs@tools.ietf.org; mmusic@ietf.org
> |Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda
> |
> |Hi,
> |
> |The agenda is (roughly) still as shown below. The afternoon sessions
> |(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material
> |(including chair slides with updated agenda) is available here:
> |http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.ht=
ml
> |
> |
> |Cheers,
> |Ari
> |
> |On 2/4/13 11:53 AM, Roni Even wrote:
> |> Hi,
> |> Is there a final agenda with time schedule. There is no relation betwe=
en
> the
> |> agenda here and i=3Dthe one for mmusic and rtcweb in the reference.
> |> I would like to attend from remote and since there is time difference =
it
> |> will be helpful to plan ahead.
> |> Thanks
> |> Roni Even who will try to attend from remote being 7 hours ahead of
> Boston
> |>
> |> -----Original Message-----
> |> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beha=
lf
> Of
> |> Stefan H?kansson LK
> |> Sent: 30 January, 2013 11:51 AM
> |> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org;
> |> public-media-capture@w3.org
> |> Subject: [rtcweb] Boston meeting agenda
> |>
> |> All,
> |>
> |> below is a merged agenda covering both W3C and IETF parts of the meeti=
ng.
> |> Details are likely to change - the main message is that W3C meetings w=
ill
> be
> |> before lunch, and IETF after. Before lunch could mean
> |> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. =
A
> hard
> |> stop is planned for 17:00 on Feb 7th as many have planes to catch.
> |>
> |> (The sources used to assemble the agenda below are the W3C meeting
> wiki's,
> |> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]).
> |>
> |> --Stefan (for all involved chairs)
> |>
> |> Feb 5th
> |> =3D=3D=3D=3D=3D=3D=3D
> |> Morning session: W3C Media Capture TF
> |> -------------------------------------
> |> * device enumeration
> |> * error handling
> |> * "immediate stream" gUM
> |> * Resource reservation
> |>
> |> Afternoon session: IETF mmusic and rtcweb WGs
> |> ---------------------------------------------
> |> * Multiple Flow SDP representation
> |> * SDP for Data channels
> |>
> |> Feb 6th
> |> =3D=3D=3D=3D=3D=3D=3D
> |> Morning session: W3C Media Capture TF + WebRTC WG
> |> -------------------------------------------------
> |> * Identity aspects of MediaStreams (MediaCap)
> |> * Settings/constraints (MediaCap)
> |> * Recording (MediaCap)
> |> * Call flow (WebRTC)
> |>
> |> Afternoon session: IETF mmusic and rtcweb WGs
> |> ---------------------------------------------
> |> * SDP Grouping (Bundle/MMT/one-rtp)
> |> * Mapping stream/track label concepts to SDP identifiers
> |>
> |> Feb 7th
> |> =3D=3D=3D=3D=3D=3D=3D
> |> Morning session: W3C WebRTC WG
> |> ------------------------------
> |> * MediaStream and MediaStreamTrack - SDP interface
> |> * Error handling
> |> * Data channel
> |> * Stats
> |>
> |> Afternoon session: IETF mmusic and rtcweb WGs
> |> ---------------------------------------------
> |> * Trickle ICE
> |> * JSEP
> |>
> |> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013
> |> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013
> |> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html
> |>
> |>
> |>
> |>
> |> _______________________________________________
> |> rtcweb mailing list
> |> rtcweb@ietf.org
> |> https://www.ietf.org/mailman/listinfo/rtcweb
> |>
> |
> |_______________________________________________
> |mmusic mailing list
> |mmusic@ietf.org
> |https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From ted.ietf@gmail.com  Thu Feb  7 06:06:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FCF21F8645; Thu,  7 Feb 2013 06:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnhaOw0I1vSh; Thu,  7 Feb 2013 06:06:03 -0800 (PST)
Received: from mail-ie0-x22d.google.com (ie-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0130A21F85F0; Thu,  7 Feb 2013 06:06:02 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id 9so3499489iec.32 for ; Thu, 07 Feb 2013 06:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=opjvC8wEZFadF52yVzIvlET48bmJH12o84TK7He6V04=; b=o9DDDaWVipTBvk7sx8s8tlgIT0pUPMfEDL992J38tJ6gvky6rvqLKMbIb/QxGFLNRj QjDqNwq2KfqLmzASAYHAqZH5WIBYmk7gjEDgOq0JaLPkIOosD1PkeFS7BYTcL41217MQ Hkusq2HuXJk5eDeSw5UG2BQ+AenI5lEPmAkYga7a9l0b7VOnBhT4vEapUDl8cb7KVuNW WJyA5cONS/ChRbPmbDXewVfdngjCqSDawKwm0W8dpjtMa0KOb5shn/4b2kZoHUcj3vI+ F2jDv6ZxdHMyq4CZoVlqK9At+wD9e2MA+cRDtplTsvGy7voXU/49Cqp05oH3cVelg5K5 uZMQ==
MIME-Version: 1.0
X-Received: by 10.50.194.134 with SMTP id hw6mr3128073igc.20.1360245962420; Thu, 07 Feb 2013 06:06:02 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 06:06:02 -0800 (PST)
In-Reply-To: 
References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> <51128BB8.3080808@ericsson.com> <1.94dc0188bed96e22f168@cisco.com> 
Date: Thu, 7 Feb 2013 09:06:02 -0500
Message-ID: 
From: Ted Hardie 
To: Mary Barnes 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , "rtcweb-chairs@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [rtcweb] [MMUSIC] Boston meeting agenda
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 14:06:03 -0000

On Thu, Feb 7, 2013 at 9:01 AM, Mary Barnes  wr=
ote:
> The intent was to record the Webex sessions, thus a link to the
> recordings should be posted in the meeting minutes.  However, the
> recording for the Feb. 6th session yesterday wasn't started until
> partway into the session so there will be a gap.  Hopefully, someone
> will remember to start the recording at the beginning of the session
> tomorrow.

Apologies for missing the recording yesterday; we will try to do
better today.  Nagging from those in the room would be welcome.


Ted

>
> Mary.
>
> On Thu, Feb 7, 2013 at 12:22 AM, Muthu Arul Mozhi Perumal (mperumal)
>  wrote:
>> Are we recording these sessions? Will someone be sharing the URLs for th=
e
>> recording?
>>
>> Muthu
>>
>> |-----Original Message-----
>> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal=
f Of
>> Ari Ker=E4nen
>> |Sent: Wednesday, February 06, 2013 10:29 PM
>> |To: Roni Even
>> |Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org;
>> rtcweb-chairs@tools.ietf.org; mmusic@ietf.org
>> |Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda
>> |
>> |Hi,
>> |
>> |The agenda is (roughly) still as shown below. The afternoon sessions
>> |(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material
>> |(including chair slides with updated agenda) is available here:
>> |http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.h=
tml
>> |
>> |
>> |Cheers,
>> |Ari
>> |
>> |On 2/4/13 11:53 AM, Roni Even wrote:
>> |> Hi,
>> |> Is there a final agenda with time schedule. There is no relation betw=
een
>> the
>> |> agenda here and i=3Dthe one for mmusic and rtcweb in the reference.
>> |> I would like to attend from remote and since there is time difference=
 it
>> |> will be helpful to plan ahead.
>> |> Thanks
>> |> Roni Even who will try to attend from remote being 7 hours ahead of
>> Boston
>> |>
>> |> -----Original Message-----
>> |> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beh=
alf
>> Of
>> |> Stefan H?kansson LK
>> |> Sent: 30 January, 2013 11:51 AM
>> |> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org;
>> |> public-media-capture@w3.org
>> |> Subject: [rtcweb] Boston meeting agenda
>> |>
>> |> All,
>> |>
>> |> below is a merged agenda covering both W3C and IETF parts of the meet=
ing.
>> |> Details are likely to change - the main message is that W3C meetings =
will
>> be
>> |> before lunch, and IETF after. Before lunch could mean
>> |> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC.=
 A
>> hard
>> |> stop is planned for 17:00 on Feb 7th as many have planes to catch.
>> |>
>> |> (The sources used to assemble the agenda below are the W3C meeting
>> wiki's,
>> |> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]).
>> |>
>> |> --Stefan (for all involved chairs)
>> |>
>> |> Feb 5th
>> |> =3D=3D=3D=3D=3D=3D=3D
>> |> Morning session: W3C Media Capture TF
>> |> -------------------------------------
>> |> * device enumeration
>> |> * error handling
>> |> * "immediate stream" gUM
>> |> * Resource reservation
>> |>
>> |> Afternoon session: IETF mmusic and rtcweb WGs
>> |> ---------------------------------------------
>> |> * Multiple Flow SDP representation
>> |> * SDP for Data channels
>> |>
>> |> Feb 6th
>> |> =3D=3D=3D=3D=3D=3D=3D
>> |> Morning session: W3C Media Capture TF + WebRTC WG
>> |> -------------------------------------------------
>> |> * Identity aspects of MediaStreams (MediaCap)
>> |> * Settings/constraints (MediaCap)
>> |> * Recording (MediaCap)
>> |> * Call flow (WebRTC)
>> |>
>> |> Afternoon session: IETF mmusic and rtcweb WGs
>> |> ---------------------------------------------
>> |> * SDP Grouping (Bundle/MMT/one-rtp)
>> |> * Mapping stream/track label concepts to SDP identifiers
>> |>
>> |> Feb 7th
>> |> =3D=3D=3D=3D=3D=3D=3D
>> |> Morning session: W3C WebRTC WG
>> |> ------------------------------
>> |> * MediaStream and MediaStreamTrack - SDP interface
>> |> * Error handling
>> |> * Data channel
>> |> * Stats
>> |>
>> |> Afternoon session: IETF mmusic and rtcweb WGs
>> |> ---------------------------------------------
>> |> * Trickle ICE
>> |> * JSEP
>> |>
>> |> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013
>> |> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_201=
3
>> |> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html
>> |>
>> |>
>> |>
>> |>
>> |> _______________________________________________
>> |> rtcweb mailing list
>> |> rtcweb@ietf.org
>> |> https://www.ietf.org/mailman/listinfo/rtcweb
>> |>
>> |
>> |_______________________________________________
>> |mmusic mailing list
>> |mmusic@ietf.org
>> |https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>

From randell-ietf@jesup.org  Thu Feb  7 07:49:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A45221F84D1 for ; Thu,  7 Feb 2013 07:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 dRTlVE+D6oSM for ; Thu,  7 Feb 2013 07:49:48 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCD621F84CA for ; Thu,  7 Feb 2013 07:49:48 -0800 (PST)
Received: from static-155-212-214-60.mas.onecommunications.net ([155.212.214.60]:64969 helo=[192.168.2.58]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U3TjP-000BCV-IS for rtcweb@ietf.org; Thu, 07 Feb 2013 09:49:47 -0600
Message-ID: <5113CD16.6090806@jesup.org>
Date: Thu, 07 Feb 2013 10:49:42 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:49:50 -0000

On 2/7/2013 6:22 AM, Martin Thomson wrote:
> We're a fickle lot.  It seems that decisions can be unmade very easily.
>
> In any case, I promised a concrete proposal.  Here it is.  Beware:
> long post ahead.
>
> This proposal is progressive, I think that the best option would be to
> take all of it, but we could choose to not adopt the later parts.
> I'll start with the basics.
>
> ==Layer 1
>
> Negotiate all new data channels with SDP offer/answer.
>
> As I understand it, the 1.5 round trip cost for in-band channel
> creation was to prevent glare.  (Randell hinted that there might have
> been something else that was SCTP-specific, but this appears to reduce
> to a straightforward glare situation.)  Doing the negotiation in SDP
> lets us use the glare mitigation mechanisms we have built into SDP, so
> we save 0.5 round trips for every new channel.

The SCTP-specific thing requiring the ACK was to avoid an in-band issue 
(need to review mail archives with the SCTP authors to find it), so it 
wouldn't apply here.  I think it was only need to be able to tell the 
app for *sure* that the other side had processed the openresponse, but 
I'm not certain.

> This allows us to ditch the in-band signaling protocol almost entirely
> (see Option B below).
>
> Creating a new data channel triggers the onnegotiationneeded event.

This solution will work.  It means you're beholden to SDP and 
negotiation with the app involved.  I've always tried to avoid 
re-negotiation wherever possible; renegotiation is rife with 
hard-to-track-down timing and other issues.

>
> ==Layer 2
>
> Zero round trip channel establishment
>
> The only reason that we have for negotiation of each channel is to
> provide a consistent set of characteristics for each channel.  The
> peer that creates a channel decides the values for label,
> retransmission count (0, n, infinite), and subprotocol.  If you don't
> care about these values being consistent between peers, or you have
> another means of ensuring consistency, you don't need to negotiate new
> channels at all.

In fact, the current design (in-band protocol or the 'mixed' (2b) 
proposal) doesn't actually negotiate them - they're declarative. The 
response merely tells the creator what the opposite-direction stream 
number is (or if there was some failure).

>
> Here, we permit the use of additional channels immediately after
> creation, without negotiation.  This has several advantages...and
> ramifications.  And no real drawbacks.
>
> Firstly, the arrival of a packet on a stream that is not negotiated
> will require the creation of a data channel.  The properties of this
> data channel will be largely unknown. The browser can possibly detect
> that the channel is unreliable if the packet doesn't request
> acknowledgement, but that's something I'm not 100% clear on for
> partially reliable messages.  As a result, the browser will be
> required to leave these properties undefined or generate default
> values for them.
>
> It's perfectly OK to have default or undefined values for label,
> reliability and subprotocol as long as you let the application set new
> values.  This allows for another advantage: applications can, if they
> choose, set the reliability on a per-packet basis, consistent with all
> other SCTP APIs, but setting the property before sending each packet.
> This keeps the simplicity of the API design, ensures websocket
> compatibility for those that need it, but it exposes more SCTP
> capabilities to those that desire those features.
>
> This does have consequences for negotiation: Values for label,
> reliability and subprotocol need to be declarative in SDP, not
> negotiated.

The proposal I made yesterday (though I really didn't get a chance to 
present it) was purely declarative in the SDP (the mixed case I 
proposed).  They were stand-ins for the Open in-band messages and 
carried the same declarative info.

>   Both peers would be required to signal the values that
> they are using for each stream.  This would allow for the fact that
> peers could set different values for the same stream number, based on
> whatever values are set on their data channel object.  In the general
> case, it allows one peer to declare the use of a particular stream and
> the other peer to not advertise anything on the matching stream.
>
> This also makes the 'onopen' event useless for all but the first
> channel.  It should fire immediately for any channel that is created
> when the association is already active.
>
> Receipt of a message on a channel that has not already been created
> locally causes the following events, one after the other:
> ondatachannel, onopen, onmessage.

I'll note this is virtually the same as the original in-band protocol 
suggestion from Stockholm, with the loss of symmetry and labels.  The 
original proposal has the first message on a  stream be an Open message, 
but you can call Send() immediately.  We could fire onOpen immediately 
for WebSockets compatibility (without waiting for an OpenResponse); 
since we're declarative, this isn't unreasonable even semantically 
different than what causes onOpen in Websockets.

The downside(?) would be you have actual Open/OpenResponse/ACK(maybe).  
This also means there's no need to ever specify the channels in the SDP 
or renegotiate; all channel opens are 0 RTT effectively.

We previously had discussed exposing the full SCTP per-packet options, 
and generally people saw this as minimally useful and adding 
considerable confusion/complexity to web app authors.  Given you can 
open any number of channels with different characteristics the user 
isn't that constrained by this.

>
> In order to maintain the symmetrical usage pattern, and the
> websockets-compatible usage pattern, we would then require several
> things:
> 1. The browser MUST, by default, negotiate streams with values that
> match any in an offer if it does not already have a data channel for
> that stream number.  The browser MUST also create the corresponding
> data channels.
> 2. Applications that require perfect channel symmetry need to
> negotiate before using streams.
> 3. Applications that care about having their use of the API be
> interchangeable with websockets need to wait for the 'onopen' event
> before sending anything, lest they get errors when switching to
> websockets.
>
> On that last point: We could require that channels reject attempts to
> send() prior to the onopen event being processed, but that is
> unnecessarily mean.  Calling createDataChannel() followed immediately
> by send() should be OK as long as the association is active.

The wire protocol I've speced in draft-jesup-datachannel-protocol (sp) 
allows for send immediately after createDataChannel.  I agree and see no 
reason not to allow the JS to do this, though I think there was some 
disagreement last time from the W3 side.  However, this is not a real 
issue if you're going to fire onopen immediately on both sides.

>    Just
> because you haven't processed the 'onopen', doesn't mean that you
> should be prevented from using a perfectly usable channel.  Of course,
> waiting for onopen would be safest in the general case, and many
> applications would naturally do this, but I see no reason to constrain
> usage patterns unnecessarily.
>
> ===Option A
>
> Removing the in-band protocol makes the negotiation of the protocol
> that layers on top of SCTP less crucial ... it makes negotiation of
> the upper-layer protocol less crucial.  In the WebRTC case, we
> probably don't need to negotiate 'webrtc-datachannel', we could even
> let the application decide the value for that label.
>
> Personally, I don't think that we need to surface API to enable
> changing protocols.  However, it would be completely harmless in this
> configuration for an application to change the protocol label to
> something else by editing SDP, so that they could interoperate with a
> peer that expected another protocol.  That would enable CLUE usage, or
> BFCP, or whatever, as long as you can find someone who talks SCTP over
> DTLS over UDP.

They'd need to support SCTP over DTLS over ICE, and they'd need to 
support JSEP (or you'd need to somehow fake a response)
Is this an actual usecase?  If so, it hasn't been really surfaced 
before; could you expand on what this really means and how it would work?

If this is an important usecase (examples!), then we can move Open 
notifications over to a control channel.  This could be a wireline 
protocol in the browser (basically the same as the current wireline 
protocol with a field or two added).  Or as you say you push it all off 
into the application - but that means simple uses need a lot more 
boilerplate or JS-implement network protocol that many of these authors 
aren't familiar with.

>
> ===Option B
>
> The one remnant of the in-band protocol that remains is the parts that
> apply to the data payloads.  The in-band protocol is required to
> provide two features:
> 1. the ability to distinguish between textual data and binary data
> 2. the ability to send messages of arbitrary length
>
> I am sorely tempted to suggest that the first feature can instead be
> part of channel configuration, such that it is negotiated (with a
> default of binary).  This would mean that negotiation is needed if you
> want to use text and you can't handle the conversion of binary to
> text.  (Sadly, this isn't made easy and the top answer at
> stackoverflow doesn't work for UTF-8:
> http://stackoverflow.com/questions/6965107/converting-between-strings-and-arraybuffers)

this would introduce a significant incompatibility with Websockets I 
believe.

>
> For the second, draft-jesup-rtcweb-data-protocol indicates that 2Gb is
> the limit, but my reading of RFC 4920 indicates that there is no limit
> to message size.  I'm far from expert in this area, but is it possible
> that this is an implementation limitation rather than a protocol one?
> Either way, I'm tempted to suggest that fragmentation can be pushed to
> the application.

This limit probably can be relaxed; Websockets allows IIRC 71-bit 
lengths ...  just in case you need them.

The practical limit is likely lower in that it returns a single 
arraybuffer/blob.  Right now Firefox limits Websockets to 2Gb.

>
> This would allow for direct access to SCTP, rather than an
> encapsulated layer.  This is good for several reasons.  Firstly, we
> don't need to specify a protocol at all.  We avoid all the arguments
> about what byte goes where.  More importantly, it leaves the SCTP
> clean, allowing WebRTC applications to use SCTP without ornamentation.

Sure, we can expose raw (or virtually raw) SCTP.  This was my original 
proposal over a year ago.  For what I think are good reasons, we pretty 
definitively decided on a simpler API for the JS programming API and in 
the wireline, and had left that decision lie since then.

>
> ===Option C
>
> If you care about reconciling the values for label, reliability, and
> subprotocol, it might be necessary to surface the values declared by
> your peer in the API.  You can get this information from the SDP, but
> if you don't like the idea of SDP spelunking you have two choices:
> provide an 'on(re)negotiated' event that carries the values declared
> by the remote peer; or, provide read-only accessors for these.
>
> I'm not certain that reconciliation of these values is important.
> Applications can even build their own mechanisms if it is.  If we must
> build more mechanisms, then I tend to favor the 'on(re)negotiated'
> event.
> _____________________________________________

I like (a lot) the declarative approach, and all the complications were 
due to needing to fulfill glare considerations (now resolved by not 
requiring resolving of label glare and not requiring bidirectional 
stream pairs have the same number), and due to the requirement for 
websockets compatibility with onOpen (and to not fire it until you have 
positive notification from the other side). If you drop that last part, 
you have immediate declarative 0-RTT opening time DataChannels.  I would 
propose keeping things simpler for users and to use the wireline 
protocol for the declaration/response, and avoid all the weirdnesses 
around labels, protocols and modes caused by dropping it.

I like your Layer 2, but with the wireline protocol previously speced.  
It gets you all the label/mode/etc sync stuff, and merely rules out 
option A (or requires you to dedicate a control stream).

-- 
Randell Jesup
randell-ietf@jesup.org


From ted.ietf@gmail.com  Thu Feb  7 09:09:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC67921F8561; Thu,  7 Feb 2013 09:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCLMXtYgcYFt; Thu,  7 Feb 2013 09:09:29 -0800 (PST)
Received: from mail-ie0-x233.google.com (ie-in-x0233.1e100.net [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3378F21F841F; Thu,  7 Feb 2013 09:09:28 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id k11so3781973iea.24 for ; Thu, 07 Feb 2013 09:09:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=tC8+2jo/S2AzpUlYdb5F7P43PDxO6SlTrugcPvdex4U=; b=kB8HeEqvJdwRtojDnu9ysodrRJoS5/QrlCCCk5DHdWO6Xlemt2Snj+rEK4zI331JmO Vm9CLw0cP6V3xYQTVhPCTUr/+HSWXQtZELRrqYfyK/ADpEzDmbjmt4F7uDPUAXAk2AA9 c/UYZx+k+QIwUzdR/SOBpLVKJDvWGd2eFVQD+SKXKz4smyhb1gIspm3UJmcXHv6MglfW 9elA4ESy6OWCKYY7tzSnSc06P3P3cRu0iR+DqnmuCZu8TPr9T4HfUi77Sp9sQCzYy95i Im9GnJQTf8ti9iYGhMp0zx5rH5Gj4NVzulfK+WFuyc8TsPmtujiciT096Kpo1rywojrD YHeg==
MIME-Version: 1.0
X-Received: by 10.42.48.147 with SMTP id s19mr3722504icf.18.1360256967963; Thu, 07 Feb 2013 09:09:27 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 09:09:27 -0800 (PST)
Date: Thu, 7 Feb 2013 12:09:27 -0500
Message-ID: 
From: Ted Hardie 
To: rtcweb@ietf.org, mmusic@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [rtcweb] IETF Interim starting fifteen minutes early at 1:15 p.m. Boston time
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 17:09:29 -0000

In order to give folks a little extra time to get to the airport,
we're going to start at 1:15 and aim to finish on time at 5:00.


Ted

From ibc@aliax.net  Thu Feb  7 10:06:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028F421F8856 for ; Thu,  7 Feb 2013 10:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.677
X-Spam-Level: 
X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, 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 G7Q8wYV-d3zP for ; Thu,  7 Feb 2013 10:06:03 -0800 (PST)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 219C321F8845 for ; Thu,  7 Feb 2013 10:06:03 -0800 (PST)
Received: by mail-qe0-f50.google.com with SMTP id 7so1308845qea.37 for ; Thu, 07 Feb 2013 10:05:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=ktaQbn1qKLzp/0uoLPeUOCxehxatTNXP9nUiLEsMo6E=; b=EC7sOWWBzolmXh8KJxGCPHizlSHAgpr7qpWkrZQsuOw1GkJZJShFOId+cgnpORNgEc G1WSdlN/PUDxziCVzLv0bdBMtZAu2EDno8i0AJ85KGXduIeCVRyTgx2aqBpSVX3iZRbf 8/i132aWWpztOYns8nFodYnkt1ytmVjX+n4OzaloXuMPckMg3lOXkezSCApGhVmTSa6J p7R2iqCEp//wrKGf22c/9bQFvOArAAq2hy7j2zvwFvfMqOZZjPjaieYsRVGpsDU4BZ1I OpViNzaOWdYEotF5+aatjXFt0n7dEmhiMy9gfVwavEYixFx7spJ5G9Epi1bttUpu1ZmY Yz7Q==
X-Received: by 10.229.176.144 with SMTP id be16mr200434qcb.130.1360260357968;  Thu, 07 Feb 2013 10:05:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.94.193 with HTTP; Thu, 7 Feb 2013 10:05:37 -0800 (PST)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 7 Feb 2013 19:05:37 +0100
Message-ID: 
To: rtcweb@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnWFGBhrLwArNC3OaK+oVG2lvFw6sPUbXxVz72yWtORqfxmd3CWJUC0JaTEXOeQY01RHk3v
Subject: [rtcweb] [Tryit JsSIP] online demo SIP+WebSocket+WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 18:06:04 -0000

Hi all,


We have made public our "Tryit JsSIP" online application which uses
JsSIP JavaScript SIP stack.

  http://tryit.jssip.net/



Tryit JsSIP features:

- Use our SIP WebSocket server (OverSIP) with dynamically generated
accounts in our SIP domain.

- Use our SIP WebSocket server (OverSIP) to reach your SIP domain
(your own SIP accounts and server).

- Use your own SIP WebSocket server and your SIP domain.

It also allows sending easy invitations to make a call by clicking
into a link received via email/chat. And mainly, it uses WebRTC ;)



Best regards.


--=20
I=C3=B1aki Baz Castillo


From ekr@rtfm.com  Thu Feb  7 11:23:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA5621F8856 for ; Thu,  7 Feb 2013 11:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.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_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 DRvporI438Vq for ; Thu,  7 Feb 2013 11:23:01 -0800 (PST)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4676E21F8809 for ; Thu,  7 Feb 2013 11:22:59 -0800 (PST)
Received: by mail-qa0-f53.google.com with SMTP id z4so1337665qan.5 for ; Thu, 07 Feb 2013 11:22:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=B3+50ZgYT3tjsJLXz7VViOLSyvLE9eOupvRf4+IRYpE=; b=T/7kpczvwPGywfl4ev26KkdiHyQBdkKWTE0fCWYddiz/oZaaLcg7C1FdOM4ea5S0yq PpnYq+g+mrsMzWH9IocIWl1feC5A7DIVRhJ//8Q47BWVMk7w31Z1/sShaXukbojKwGqq sQKXelpk/eOCZMnZHB+kKM5eYxixfRIRXfzcNoo7SDJ0pDR5R2UuyInDTXs2bQis8xXv GKEBViRcwyhpf9Hvk+6l5j4yDVBDkjrbbAtXdaPY4NeRnex/RQeyoXJGh3DPLb61ZFMv 2fQtgJ1Av8XwcGwvOn91Ud6Tkp/rJ6Xu/SMGRhHOTIB39lC1QPCleJom3ceznTrcHZYL Qq0Q==
X-Received: by 10.224.53.7 with SMTP id k7mr1111243qag.96.1360264978731; Thu, 07 Feb 2013 11:22:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.82.130 with HTTP; Thu, 7 Feb 2013 11:22:18 -0800 (PST)
X-Originating-IP: [155.212.214.60]
From: Eric Rescorla 
Date: Thu, 7 Feb 2013 11:22:18 -0800
Message-ID: 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=20cf3074d9d8db918004d5275e0c
X-Gm-Message-State: ALoCoQkRhObB1g4sBlQwOvBjIFCuuusEONihYRfw+bexpZIc8CXPfkF6rvkMIIcfMZFxWp2k1kFC
Subject: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:23:10 -0000

--20cf3074d9d8db918004d5275e0c
Content-Type: text/plain; charset=ISO-8859-1

Here's what I was trying to say at the microphone.

1. When two MSTracks are in the same MediaStream on the sending side:
 They must generate the same MSID in SDP and the same CNAME in RTP.

2. One the receiving side, any two tracks with the same MSID will appear in
the same MediaStreamTrack.

3. On the receiving side, any two RTP streams with the same CNAME will
be synchronized.

4. There are two ways for MSID and CNAME to be inconsistent.
- If MSID indicates synchronization but different CNAMEs are provided,
  synchronization is not attempted.
- If MSID indicates no synchronization but the same CNAME is used,
  then the tracks shall be synchronized, even though they appear in
  different MediaStreams.

-Ekr

--20cf3074d9d8db918004d5275e0c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Here's what I was trying to say at the microphone.

1=
. When two MSTracks are in the same MediaStream on the sending side:
=
=A0They must generate the same MSID in SDP and the same CNAME in RTP.
=





2. One the receiving side, any two tracks with the same=
 MSID will appear in
the same MediaStreamTrack.

3. On the receiving side, any two RTP streams with the same CNAME w=
ill



be synchronized.

4. There are two ways for MS=
ID and CNAME to be inconsistent.
- If MSID indicates synchronizat=
ion but different CNAMEs are provided,
=A0 synchronization is not=
 attempted.



- If MSID indicates no synchronization but the same CNAME is used,
=A0 then the tracks shall be synchronized, even though they appear i=
n
=A0 different MediaStreams.

-Ekr






--20cf3074d9d8db918004d5275e0c--

From jim.barnett@genesyslab.com  Thu Feb  7 11:27:08 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE04E21F8904 for ; Thu,  7 Feb 2013 11:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHm1K3xDIqEd for ; Thu,  7 Feb 2013 11:27:07 -0800 (PST)
Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8F121F88F7 for ; Thu,  7 Feb 2013 11:27:07 -0800 (PST)
Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Thu, 07 Feb 2013 14:27:06 -0500
Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 11:27:03 -0800
From: Jim Barnett 
To: Eric Rescorla , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
Thread-Index: AQHOBWiaQZ9LPtsGMkigYi8uDi1lLphuxzhw
Date: Thu, 7 Feb 2013 19:27:03 +0000
Message-ID: <57A15FAF9E58F841B2B1651FFE16D28101F23D@GENSJZMBX03.msg.int.genesyslab.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [155.212.214.60]
MIME-Version: 1.0
X-MC-Unique: 113020714270611102
Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D28101F23DGENSJZMBX03msgint_"
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:27:08 -0000

--_000_57A15FAF9E58F841B2B1651FFE16D28101F23DGENSJZMBX03msgint_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

On point 2,  do you mean "same MediaStream"?


-          Jim

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Eric Rescorla
Sent: Thursday, February 07, 2013 2:22 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchroniz=
ation

Here's what I was trying to say at the microphone.

1. When two MSTracks are in the same MediaStream on the sending side:
 They must generate the same MSID in SDP and the same CNAME in RTP.

2. One the receiving side, any two tracks with the same MSID will appear in
the same MediaStreamTrack.

3. On the receiving side, any two RTP streams with the same CNAME will
be synchronized.

4. There are two ways for MSID and CNAME to be inconsistent.
- If MSID indicates synchronization but different CNAMEs are provided,
  synchronization is not attempted.
- If MSID indicates no synchronization but the same CNAME is used,
  then the tracks shall be synchronized, even though they appear in
  different MediaStreams.

-Ekr

--_000_57A15FAF9E58F841B2B1651FFE16D28101F23DGENSJZMBX03msgint_
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable











On point 2,  do you =
mean “same MediaStream”? 



 <=
/p>

- =
        
Jim


 <=
/p>



From: rtcweb-b=
ounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Eric Rescorla

Sent: Thursday, February 07, 2013 2:22 PM

To: rtcweb@ietf.org

Subject: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for syn=
chronization




 


Here's what I was trying to say at the microphone.




 






1. When two MSTracks are in the same MediaStream on =
the sending side:




 They must generate the same MSID in SDP and th=
e same CNAME in RTP.








 






2. One the receiving side, any two tracks with the s=
ame MSID will appear in






the same MediaStreamTrack.






 






3. On the receiving side, any two RTP streams with t=
he same CNAME will






be synchronized.






 






4. There are two ways for MSID and CNAME to be incon=
sistent.






- If MSID indicates synchronization but different CN=
AMEs are provided,






  synchronization is not attempted.<=
/p>





- If MSID indicates no synchronization but the same =
CNAME is used,






  then the tracks shall be synchronized, even t=
hough they appear in






  different MediaStreams.






 






-Ekr






 







--_000_57A15FAF9E58F841B2B1651FFE16D28101F23DGENSJZMBX03msgint_--


From stefan.lk.hakansson@ericsson.com  Thu Feb  7 11:27:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27F321F88DD for ; Thu,  7 Feb 2013 11:27:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.069
X-Spam-Level: 
X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.180,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIqJNfmhHb9s for ; Thu,  7 Feb 2013 11:27:56 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F221021F8206 for ; Thu,  7 Feb 2013 11:27:55 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-52-5114003a5cf1
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7C.E5.10459.A3004115; Thu,  7 Feb 2013 20:27:55 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 7 Feb 2013 20:27:54 +0100
Message-ID: <51140038.3040001@ericsson.com>
Date: Thu, 7 Feb 2013 20:27:52 +0100
From: Stefan Hakansson LK 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
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: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvja41g0igwbETjBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/GMeSwFfVwV8zousjQw/mLvYuTkkBAwkfj+5gUzhC0mceHe ejYQW0jgJKPEjTs8XYxcQPYyRokVZ+aCJXgFtCVeX5jHCGKzCKhI3G3YDTaITcBGYm33FCYQ W1QgTKL39TlGiHpBiZMzn7CA2CICwhJbX/WC1QgLhEhM633GDLEsQGL9Qog5nAKBEh86l4HZ zAK2EhfmXGeBsOUltr+dA1WvK/Hu9T3WCYwCs5CsmIWkZRaSlgWMzKsY2XMTM3PSyw03MQLD 7OCW37o7GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY9uiqs4G Qy1RiylH/rb35p05fLlagUtfVGxPi+DieXkn29s5Z7hZMKevVsnel/rj3MN9b91nfp4mz+yq 9ZM9/PjarXvYpu7+UP/Qt9xe+V640Jm/N67W3C0OM1zH4n7nmZ2/jMME2/jlyytK0y/t9Ugu DN+pMWlDpu3Zvypr7yk81W32ONoyTYmlOCPRUIu5qDgRACpMQxIBAgAA
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:27:57 -0000

On 02/07/2013 08:22 PM, Eric Rescorla wrote:
> Here's what I was trying to say at the microphone.
>
> 1. When two MSTracks are in the same MediaStream on the sending side:
>   They must generate the same MSID in SDP and the same CNAME in RTP.
>
> 2. One the receiving side, any two tracks with the same MSID will appear in
> the same MediaStreamTrack.

Same _MediaStream_?

>
> 3. On the receiving side, any two RTP streams with the same CNAME will
> be synchronized.

Yes.

My question is basically: what if the sender creates two MediaStreams 
for which all tracks have local sources (cam's, mike's), sends them to a 
peer, will the RTP streams for both MediaStreams have the same or 
different CNAME?

I argued for that they should have the same.

>
> 4. There are two ways for MSID and CNAME to be inconsistent.
> - If MSID indicates synchronization but different CNAMEs are provided,
>    synchronization is not attempted.
> - If MSID indicates no synchronization but the same CNAME is used,
>    then the tracks shall be synchronized, even though they appear in
>    different MediaStreams.
>
> -Ekr
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From ekr@rtfm.com  Thu Feb  7 11:43:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0120F21F8870 for ; Thu,  7 Feb 2013 11:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.865
X-Spam-Level: 
X-Spam-Status: No, score=-101.865 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 X3CRjizegnyr for ; Thu,  7 Feb 2013 11:43:50 -0800 (PST)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4559E21F875F for ; Thu,  7 Feb 2013 11:43:50 -0800 (PST)
Received: by mail-qe0-f50.google.com with SMTP id 7so1350858qea.23 for ; Thu, 07 Feb 2013 11:43:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=15Wtn0Ga86daUuXckUaIFp2/jBJHx3QHyv4j0Am72ck=; b=oeolYyEljywBcAdHInyjdsjIq0hMsA3YcS4qk8Ok3DEUH2x1MmIc7EM+M4lLviWydC WX6udVnOz4wxmZweVqJeybkM+d6fyGSLojmlHtFwKZWMEeY5sPInZunjr7b6KwPn+4GF gUIKa07azDXnrdzqNr6PMLzQ2R3znDqd+bFw0aKzamd4+N+UFwqpjbuD0nhekFc+VI9O /5tbaXhKdHi5FSWG+d0jxeO1Jtl5B5iGMURbKxGjxqFDhBahW4CWpSGmJJ4gqagkjJ/S qCUoOwfgNZgTOnyEAvdFthtMMKTrpiPZZTGC2JIzwrrJsQyAq8KKTDRCNw7gne/ALJVf 3t5A==
X-Received: by 10.224.222.15 with SMTP id ie15mr1182432qab.75.1360266229818; Thu, 07 Feb 2013 11:43:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.82.130 with HTTP; Thu, 7 Feb 2013 11:43:09 -0800 (PST)
X-Originating-IP: [155.212.214.60]
In-Reply-To: <51140038.3040001@ericsson.com>
References:  <51140038.3040001@ericsson.com>
From: Eric Rescorla 
Date: Thu, 7 Feb 2013 11:43:09 -0800
Message-ID: 
To: Stefan Hakansson LK 
Content-Type: multipart/alternative; boundary=20cf3074b51a6da6b604d527a978
X-Gm-Message-State: ALoCoQkUjCmKjiNBnY9m/zeKeeIMb36DbtjUwI9ciYlKsBEILzlnDZxHm+37wK9jyYitta3hiJ02
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:43:51 -0000

--20cf3074b51a6da6b604d527a978
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 7, 2013 at 11:27 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 02/07/2013 08:22 PM, Eric Rescorla wrote:
>
>> Here's what I was trying to say at the microphone.
>>
>> 1. When two MSTracks are in the same MediaStream on the sending side:
>>   They must generate the same MSID in SDP and the same CNAME in RTP.
>>
>> 2. One the receiving side, any two tracks with the same MSID will appear
>> in
>> the same MediaStreamTrack.
>>
>
> Same _MediaStream_?


Yes. Doh.


>
>
>> 3. On the receiving side, any two RTP streams with the same CNAME will
>> be synchronized.
>>
>
> Yes.
>
> My question is basically: what if the sender creates two MediaStreams for
> which all tracks have local sources (cam's, mike's), sends them to a peer,
> will the RTP streams for both MediaStreams have the same or different CNAME?
>
> I argued for that they should have the same.
>

Yes, I think this is a separate (and fraught) question. :)

-Ekr


>
>> 4. There are two ways for MSID and CNAME to be inconsistent.
>> - If MSID indicates synchronization but different CNAMEs are provided,
>>    synchronization is not attempted.
>> - If MSID indicates no synchronization but the same CNAME is used,
>>    then the tracks shall be synchronized, even though they appear in
>>    different MediaStreams.
>>
>> -Ekr
>>
>>
>>
>> ______________________________**_________________
>> 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
>

--20cf3074b51a6da6b604d527a978
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Feb 7, 2013 at 11:27 AM, Stefan =
Hakansson LK <stefan.lk.hakansson@ericsson.com> wrote:



On 02/07/2013 08:22 PM, Er=
ic Rescorla wrote:



Here's what I was trying to say at the microphone.



1. When two MSTracks are in the same MediaStream on the sending side:

=A0 They must generate the same MSID in SDP and the same CNAME in RTP.



2. One the receiving side, any two tracks with the same MSID will appear in=


the same MediaStreamTrack.





Same _MediaStream_?

Yes. Doh.
=A0=








3. On the receiving side, any two RTP streams with the same CNAME will

be synchronized.





Yes.



My question is basically: what if the sender creates two MediaStreams for w=
hich all tracks have local sources (cam's, mike's), sends them to a=
 peer, will the RTP streams for both MediaStreams have the same or differen=
t CNAME?





I argued for that they should have the same.

Yes, I think this is a separate (and fraught) question. :)
=

-Ekr
=A0







4. There are two ways for MSID and CNAME to be inconsistent.

- If MSID indicates synchronization but different CNAMEs are provided,

=A0 =A0synchronization is not attempted.

- If MSID indicates no synchronization but the same CNAME is used,

=A0 =A0then the tracks shall be synchronized, even though they appear in
=A0 =A0different MediaStreams.



-Ekr







_______________________________________________

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





--20cf3074b51a6da6b604d527a978--

From stefan.lk.hakansson@ericsson.com  Thu Feb  7 11:59:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664CA21F88EA for ; Thu,  7 Feb 2013 11:59:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.085
X-Spam-Level: 
X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.164,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYmdz12Q2HvY for ; Thu,  7 Feb 2013 11:59:41 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55521F87EE for ; Thu,  7 Feb 2013 11:59:41 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-6d-511407ac0e19
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1B.AB.32353.CA704115; Thu,  7 Feb 2013 20:59:40 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 7 Feb 2013 20:59:40 +0100
Message-ID: <511407AA.1040501@ericsson.com>
Date: Thu, 7 Feb 2013 20:59:38 +0100
From: Stefan Hakansson LK 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Eric Rescorla 
References:  <51140038.3040001@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3RncNu0igwc/JMhYrXp9jt1j7r53d gcljyZKfTB6TH7cxBzBFcdmkpOZklqUW6dslcGW03r7DVDCVp+LM0rXsDYxfOboYOTkkBEwk Lr3rZoawxSQu3FvP1sXIxSEkcJJR4sDSY8wQzjJGiStHfrGCVPEKaEt8OTWdHcRmEVCR+PT7 MBOIzSZgI7G2ewqYLSoQJtH7+hwjRL2gxMmZT1hAbBEBBYlff06A2cwCwhIbLraB2cICIRLT ep9BLdvKKNG54BnYIE6BQIlHc88yQzTYSlyYcx2qWV5i+9s5YHEhAV2Jd6/vsU5gFJyFZN8s JC2zkLQsYGRexciem5iZk15uvokRGJYHt/w22MG46b7YIUZpDhYlcd5w1wsBQgLpiSWp2amp BalF8UWlOanFhxiZODilGhjlZ72tNXQwt5/G9sRQxfTAl1ophyMe+eVzdDef6Aq8NHcqs1MK x8s96xSSRZ22nvTlEnAyLxE2qdsn+sRa4dcUnfZr/ll3z0WGGXltWnrkcO6vyjW/VwbW+9d/ NP4vNWM2K9O+cJbvP3e8tbV4O7HLY9XbVUKMqnPU7FVudTwIqXt1X3P/ZCklluKMREMt5qLi RABUKHOrGQIAAA==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:59:42 -0000

On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>
>

>
>     My question is basically: what if the sender creates two
>     MediaStreams for which all tracks have local sources (cam's,
>     mike's), sends them to a peer, will the RTP streams for both
>     MediaStreams have the same or different CNAME?
>
>     I argued for that they should have the same.
>
>
> Yes, I think this is a separate (and fraught) question. :)

Separate question, but I think the answer should be documented 
(regardless on if it is "same", "different" or "implementers choice").

>
> -Ekr
>
>
>         4. There are two ways for MSID and CNAME to be inconsistent.
>         - If MSID indicates synchronization but different CNAMEs are
>         provided,
>             synchronization is not attempted.
>         - If MSID indicates no synchronization but the same CNAME is used,
>             then the tracks shall be synchronized, even though they
>         appear in
>             different MediaStreams.
>
>         -Ekr
>
>
>
>         _________________________________________________
>         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 ekr@rtfm.com  Thu Feb  7 12:04:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6221F8936 for ; Thu,  7 Feb 2013 12:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.727
X-Spam-Level: 
X-Spam-Status: No, score=-101.727 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 X86cMu2RrK6P for ; Thu,  7 Feb 2013 12:04:03 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2160D21F8918 for ; Thu,  7 Feb 2013 12:04:03 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id b25so1156269qca.3 for ; Thu, 07 Feb 2013 12:04:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=8M1vzSVzwjrUecZ9FCijKag+247TQD76khcTncAvshg=; b=YiSD3+lY9HCmvE6qXBXG4O0KJjya1T0q7zVR9+avfxDgemtTjxgiNJrxXp3+gQZiY4 Em+Icgyc2CyA0F8oRpb8zMul5C5JU8Vk5ghrbhD1NwInTqudMhgSFGp6ClklWtLUu8x3 xLzkUgL9wOyzhk0aDjJOHd7JfEsoBmfBAVL4ThgJlvpv4U5qfZJGQrOdTMMXeyFasgui B0N8/pyjnRq//U3AIhsrZG/QmvIBlN2PUSPRzy4r0NXiNLtRpofCKBbiIKQfxDLIAXG4 G2e70gzupILp0fNGRn4bBanNNRHtl7ME1YTzSEYQjtVuHaOhUtu6iy7ubC7dgvCwe8Ej hsOA==
X-Received: by 10.49.127.145 with SMTP id ng17mr1134494qeb.25.1360267442462; Thu, 07 Feb 2013 12:04:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.82.130 with HTTP; Thu, 7 Feb 2013 12:03:22 -0800 (PST)
X-Originating-IP: [155.212.214.60]
In-Reply-To: <511407AA.1040501@ericsson.com>
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>
From: Eric Rescorla 
Date: Thu, 7 Feb 2013 12:03:22 -0800
Message-ID: 
To: Stefan Hakansson LK 
Content-Type: multipart/alternative; boundary=047d7b6dcee0b5200c04d527f1f1
X-Gm-Message-State: ALoCoQnfhto2zylhfPLNJoAtX2jgoy3tRKZd3khXWK/xiZr8pg0BmEnkppMWfxiQ9IYUD2Onccrf
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:04:04 -0000

--047d7b6dcee0b5200c04d527f1f1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 7, 2013 at 11:59 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>
>>
>>
>>
>
>>     My question is basically: what if the sender creates two
>>     MediaStreams for which all tracks have local sources (cam's,
>>     mike's), sends them to a peer, will the RTP streams for both
>>     MediaStreams have the same or different CNAME?
>>
>>     I argued for that they should have the same.
>>
>>
>> Yes, I think this is a separate (and fraught) question. :)
>>
>
> Separate question, but I think the answer should be documented (regardless
> on if it is "same", "different" or "implementers choice").
>

Agreed.

-Ekr


>
>> -Ekr
>>
>>
>>         4. There are two ways for MSID and CNAME to be inconsistent.
>>         - If MSID indicates synchronization but different CNAMEs are
>>         provided,
>>             synchronization is not attempted.
>>         - If MSID indicates no synchronization but the same CNAME is used,
>>             then the tracks shall be synchronized, even though they
>>         appear in
>>             different MediaStreams.
>>
>>         -Ekr
>>
>>
>>
>>         ______________________________**___________________
>>         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
>>     
>> >
>>
>>
>>
>

--047d7b6dcee0b5200c04d527f1f1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Feb 7, 2013 at 11:59 AM, Stefan =
Hakansson LK <stefan.lk.hakansson@ericsson.com> wrote:



On 02/07/2013 08:43 PM, Er=
ic Rescorla wrote:















=A0 =A0 My question is basically: what if the sender creates two

=A0 =A0 MediaStreams for which all tracks have local sources (cam's,
=A0 =A0 mike's), sends them to a peer, will the RTP streams for both
=A0 =A0 MediaStreams have the same or different CNAME?



=A0 =A0 I argued for that they should have the same.





Yes, I think this is a separate (and fraught) question. :)





Separate question, but I think the answer should be documented (regardless =
on if it is "same", "different" or "implementers c=
hoice").

Agreed.




-Ekr
=A0





-Ekr





=A0 =A0 =A0 =A0 4. There are two ways for MSID and CNAME to be inconsistent=
.

=A0 =A0 =A0 =A0 - If MSID indicates synchronization but different CNAMEs ar=
e

=A0 =A0 =A0 =A0 provided,

=A0 =A0 =A0 =A0 =A0 =A0 synchronization is not attempted.

=A0 =A0 =A0 =A0 - If MSID indicates no synchronization but the same CNAME i=
s used,

=A0 =A0 =A0 =A0 =A0 =A0 then the tracks shall be synchronized, even though =
they

=A0 =A0 =A0 =A0 appear in

=A0 =A0 =A0 =A0 =A0 =A0 different MediaStreams.



=A0 =A0 =A0 =A0 -Ekr







=A0 =A0 =A0 =A0 _________________________________________________
=A0 =A0 =A0 =A0 rtcweb mailing list

=A0 =A0 =A0 =A0 rtcweb=
@ietf.org <mailto:rtcweb@ietf.org>

=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/rtcweb=


=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/rtcweb=
>





=A0 =A0 _________________________________________________

=A0 =A0 rtcweb mailing list

=A0 =A0 rtcweb@ietf.or=
g <mailto:rtcwe=
b@ietf.org>

=A0 =A0 https://www.ietf.org/mailman/__listinfo/rtcweb

=A0 =A0 <https://www.ietf.org/mailman/listinfo/rtcweb>













--047d7b6dcee0b5200c04d527f1f1--

From eckelcu@cisco.com  Thu Feb  7 12:08:52 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB16921F842E for ; Thu,  7 Feb 2013 12:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[AWL=3.160,  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 9xAeJRGQd3rD for ; Thu,  7 Feb 2013 12:08:51 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA4DC21F843D for ; Thu,  7 Feb 2013 12:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2767; q=dns/txt; s=iport; t=1360267731; x=1361477331; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gimFm9FoMsH3f9LicgQFOLH7IsPpklvw7gn4MRJ+/Vw=; b=hJlOUj9TQdcInoU+Id62lZTvxw/XV+am4gounHpleG3RdpgA53BiOrHr XJT/s0GGJ1r+RxPnouz0nBmZHhGhBOuk3no+LlwB9ktJTEoIIdUT4z7Y3 KpSfLF0xGCpD+VunnpAN5AVF+6qhx53QHUnUOxQzyhBMtzLRFUJQkVYkJ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAOgIFFGtJXG//2dsb2JhbABFwGoWc4IfAQEBBAEBATc0CwwEAgEIDgMEAQEBChQJBycLFAkIAgQBDQUIiAkMv3YEkHthA6ZzgwCCJA
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208";a="171620432"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 07 Feb 2013 20:08:50 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r17K8oon013577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 20:08:50 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.180]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 14:08:50 -0600
From: "Charles Eckel (eckelcu)" 
To: Eric Rescorla , Stefan Hakansson LK 
Thread-Topic: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
Thread-Index: AQHOBWibViPecFs2mkCye+0PXdv32phvLDUAgAAERYCAAASbAIAAAQsA//+byrA=
Date: Thu, 7 Feb 2013 20:08:49 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com>
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.125.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:08:52 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Eric Rescorla
> Sent: Thursday, February 07, 2013 3:03 PM
> To: Stefan Hakansson LK
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for
> synchronization
>=20
>=20
>=20
> On Thu, Feb 7, 2013 at 11:59 AM, Stefan Hakansson LK
>  wrote:
>=20
>=20
> 	On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>=20
>=20
>=20
>=20
>=20
>=20
> 		    My question is basically: what if the sender creates two
> 		    MediaStreams for which all tracks have local sources
> (cam's,
> 		    mike's), sends them to a peer, will the RTP streams for
> both
> 		    MediaStreams have the same or different CNAME?
>=20
> 		    I argued for that they should have the same.
>=20
>=20
> 		Yes, I think this is a separate (and fraught) question. :)
>=20
>=20
>=20
> 	Separate question, but I think the answer should be documented
> (regardless on if it is "same", "different" or "implementers choice").
>=20
>=20
>=20
> Agreed.

I think SHOULD is the correct thing to document. I can imagine there will b=
e cases in which the sender will be a somewhat distributed app that does no=
t really know that the media source should be synchronized, so it will assi=
gn a different CNAME.
The rest of the proposal sounded good as well.

Cheers,
Charles
=20
> -Ekr
>=20
>=20
>=20
> 		-Ekr
>=20
>=20
> 		        4. There are two ways for MSID and CNAME to be
> inconsistent.
> 		        - If MSID indicates synchronization but different CNAMEs
> are
> 		        provided,
> 		            synchronization is not attempted.
> 		        - If MSID indicates no synchronization but the same
> CNAME is used,
> 		            then the tracks shall be synchronized, even though
> they
> 		        appear in
> 		            different MediaStreams.
>=20
> 		        -Ekr
>=20
>=20
>=20
>=20
> 		        _________________________________________________
> 		        rtcweb mailing list
> 		        rtcweb@ietf.org 
> 		        https://www.ietf.org/mailman/__listinfo/rtcweb
> 
> 		          >
>=20
>=20
> 		    _________________________________________________
> 		    rtcweb mailing list
> 		    rtcweb@ietf.org 
> 		    https://www.ietf.org/mailman/__listinfo/rtcweb
> 
> 		      >
>=20
>=20
>=20
>=20
>=20


From stefan.lk.hakansson@ericsson.com  Thu Feb  7 12:19:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4B721F8807 for ; Thu,  7 Feb 2013 12:19:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level: 
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCDnhaRNmtGz for ; Thu,  7 Feb 2013 12:19:53 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5716321F87DC for ; Thu,  7 Feb 2013 12:19:53 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-3d-51140c689a6a
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A9.3D.32353.86C04115; Thu,  7 Feb 2013 21:19:52 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 7 Feb 2013 21:19:51 +0100
Message-ID: <51140C65.80006@ericsson.com>
Date: Thu, 7 Feb 2013 21:19:49 +0100
From: Stefan Hakansson LK 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Charles Eckel (eckelcu)" 
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com>
In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RjeDRyTQ4Ok3JYtNs76wWax4fY7d Yu2/dnYHZo8pvzeyeixZ8pPJY/LjNuYA5igum5TUnMyy1CJ9uwSujBfTTzIVzBepWNxS08B4 TqCLkZNDQsBEYvm3T2wQtpjEhXvrgWwuDiGBk4wSh79/g3KWMUq875nAClLFK6ApsbOjgxHE ZhFQkfj0qoEJxGYTsJFY2z0FzBYVCJPofX2OEaJeUOLkzCcsILaIgKHEoknrwGxmAVeJczMh 6oUFQiSm9T5jhlh2m0ni2bt7YMs4BXwl7tz+xwTRYCtxYc51qGZ5ie1v5zCD2EICuhLvXt9j ncAoOAvJvllIWmYhaVnAyLyKkT03MTMnvdx8EyMwUA9u+W2wg3HTfbFDjNIcLErivOGuFwKE BNITS1KzU1MLUovii0pzUosPMTJxcEo1MHokpfLYpHZsvHNNZrrHdOcXhUbb0hRvha3ax2Rt eXKDWut7ztrvU8t0rUVPfl7keOjs4xUnEp9zfJGd3czVvSrwm4yIlVnikZBSVTPF457q6xcm GKYk6h51ZhfU0dxXJcN7b91Nprlrn+/Is/U85vR+T3CRu2rOxcX2cr+yH2yNY1rKIaR3VYml OCPRUIu5qDgRAC/7taQiAgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:19:54 -0000

On 02/07/2013 09:08 PM, Charles Eckel (eckelcu) wrote:
>> -----Original Message----- From: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla Sent:
>> Thursday, February 07, 2013 3:03 PM To: Stefan Hakansson LK Cc:
>> rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for dealing with
>> CNAMEs and MSIDs for synchronization
>>
>>
>>
>> On Thu, Feb 7, 2013 at 11:59 AM, Stefan Hakansson LK
>>  wrote:
>>
>>
>> On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>>
>>
>>
>>
>>
>>
>> My question is basically: what if the sender creates two
>> MediaStreams for which all tracks have local sources (cam's,
>> mike's), sends them to a peer, will the RTP streams for both
>> MediaStreams have the same or different CNAME?
>>
>> I argued for that they should have the same.
>>
>>
>> Yes, I think this is a separate (and fraught) question. :)
>>
>>
>>
>> Separate question, but I think the answer should be documented
>> (regardless on if it is "same", "different" or "implementers
>> choice").
>>
>>
>>
>> Agreed.
>
> I think SHOULD is the correct thing to document.
"SHOULD use _same_"?

> I can imagine there
> will be cases in which the sender will be a somewhat distributed app
> that does not really know that the media source should be
> synchronized, so it will assign a different CNAME.

Definitely.

> The rest of the
> proposal sounded good as well.
>
> Cheers, Charles
>
>> -Ekr
>>
>>
>>
>> -Ekr
>>
>>
>> 4. There are two ways for MSID and CNAME to be inconsistent. - If
>> MSID indicates synchronization but different CNAMEs are provided,
>> synchronization is not attempted. - If MSID indicates no
>> synchronization but the same CNAME is used, then the tracks shall
>> be synchronized, even though they appear in different
>> MediaStreams.
>>
>> -Ekr
>>
>>
>>
>>
>> _________________________________________________ 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 spencer@wonderhamster.org  Thu Feb  7 12:29:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBE021F88A0 for ; Thu,  7 Feb 2013 12:29:32 -0800 (PST)
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 E8ErwBLQ5h1a for ; Thu,  7 Feb 2013 12:29:31 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 689C921F8895 for ; Thu,  7 Feb 2013 12:29:31 -0800 (PST)
Received: from [192.168.2.75] (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MaaKf-1UNgTh2Gs5-00Ksyd; Thu, 07 Feb 2013 15:29:30 -0500
Message-ID: <51140EA7.1030509@wonderhamster.org>
Date: Thu, 07 Feb 2013 14:29:27 -0600
From: Spencer Dawkins 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V02:K0:eV9wSOV7bAKZLix6yswVbDKwvt2KSkemVfvjZr2iY6b V+tPnZROxjIJYFnSDvrhmCz/ynWYaoA/QvTbhxuetIK8f7vAqv W+EU8fB7bC5SUJ/dUzhCBprXZbwx8n2T+pE0ZuQkO6AQjS+dDT bMqZ56WZdaayNa+ucbfBarsNpRv8up5mL1pcu7VjYlxsZCaJ0f SIb2IMq86upTbggaCyqN/Aa1TcQ1GQORwNHj4xJBndPZ2ogu/Q wDGSRKpzWRNinkpGzuTIPgopk3ZkaJTYQOihsAmF1hzFLTS0E2 Q133U8Zho4ycW5viNZQ29G0WeNtXM/XelOVUjULW/hfrmZg8Dt glqcrVqQl5CnBnS+FxBjlU8DnSVDr+aFqFvRf6xNq
Subject: Re: [rtcweb] 2119 language in requirements (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part I))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:29:32 -0000

On 2/1/2013 3:15 PM, Bernard Aboba wrote:
> I cannot find an RFC that deals with normative language in requirements documents specifically. Part of the reason for that may be that requirements documents are by no means uniform.  Some are created to assist in making a selection between competing protocols.  Some are just created to inform subsequent WG protocol design efforts.  Sometimes the eventual output is evaluated against the requirements, sometimes not.  With such a level of variation, it is not clear me that “one size fits all”.

I thought the IESG had done an IESG Statement on the use of normative 
language in Informational documents in general, but I'm not seeing that, 
either. I know it was discussed, but I'm not seeing that it was produced.

I also checked at the RFC Editor site, but what I found (example: 
http://www.rfc-editor.org/rfc-editor/instructions2authors.txt) doesn't 
provide guidance about 2119 for documents that aren't standards-track.

> Overall, I’d say it is up to IETF RTCWEB (and W3C WEBRTC) to decide how it wants the requirements document to be used, and this in turn will influence what the normative language will mean.  Judging by the number of issues we have had with requirements documents in the past (e.g. typically the understanding of the problem evolves considerably over time and often initially specified requirements are “overtaken by events”), we should be careful about setting expectations too high.

I agree with Bernard here.

Spencer



From martin.thomson@gmail.com  Fri Feb  8 01:21:55 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE1521F8795 for ; Fri,  8 Feb 2013 01:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Level: 
X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 yZTar5f5U7pg for ; Fri,  8 Feb 2013 01:21:52 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 36D7121F874F for ; Fri,  8 Feb 2013 01:21:49 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ez12so558958wid.6 for ; Fri, 08 Feb 2013 01:21:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l9eBGxxzwFxml/IDOCsuQuZ/U0HLkoXMmw1BYc2fN/c=; b=VtZFf6t7kv6gH+9exXfklGbtPYLNm6AimzIW9+5QyYTg3Jg/d2IoYPSCflc9XUghOL LudBXMBcwHEFp2cMGUbeEOLGZP2hrgrRaiMuCy52d3Wcv5mE0iIXIJvoxPZrDvzcmzB+ V6jAmxfvoI6ozi9PzTciHgGfC7pYOXGGQs3n6bQLb49lAQUJJ3VyZQALLKa8WrUuXc5j iu2LOLQRxqcR8Ch1IEMH9UoFn5j0vAW756K8I3dhEKUSfdKJ2Gf/EYtp7Lx66XFZHzSS p/dFnzzgWPG3VjF3ijPICOfAlXrx3YKscuCg/bAWgOrSU1NLtKSgHYjx7wB6YDPTs+ii GVRg==
MIME-Version: 1.0
X-Received: by 10.180.95.166 with SMTP id dl6mr1073789wib.9.1360315308180; Fri, 08 Feb 2013 01:21:48 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Fri, 8 Feb 2013 01:21:48 -0800 (PST)
In-Reply-To: <5113CD16.6090806@jesup.org>
References:  <5113CD16.6090806@jesup.org>
Date: Fri, 8 Feb 2013 04:21:48 -0500
Message-ID: 
From: Martin Thomson 
To: Randell Jesup 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 09:21:55 -0000

On 7 February 2013 10:49, Randell Jesup  wrote:
> The proposal I made yesterday (though I really didn't get a chance to
> present it) was purely declarative in the SDP (the mixed case I proposed).
> They were stand-ins for the Open in-band messages and carried the same
> declarative info.

The difference, from what I saw, was that the declarations in your
examples showed stream 1 in the offer and no stream 1 in the answer.
This would require that stream 1 appear in the answer with the
attributes that the answerer had assigned (which we would require to
be the same as the offerer, unless the answerer side had already had
created a DataChannel).

> This limit probably can be relaxed; Websockets allows IIRC 71-bit lengths
> ...  just in case you need them.

63 bit.  A poor decision in my opinion, but we need to respect working
group consensus.

> The practical limit is likely lower in that it returns a single
> arraybuffer/blob.  Right now Firefox limits Websockets to 2Gb.

This is definitely an implementation choice.  I expect lower limits in
many implementations.  Desktop browsers probably need to be a little
more flexible than most.

> I like (a lot) the declarative approach, and all the complications were due
> to needing to fulfill glare considerations (now resolved by not requiring
> resolving of label glare and not requiring bidirectional stream pairs have
> the same number), and due to the requirement for websockets compatibility
> with onOpen (and to not fire it until you have positive notification from
> the other side). If you drop that last part, you have immediate declarative
> 0-RTT opening time DataChannels.  I would propose keeping things simpler for
> users and to use the wireline protocol for the declaration/response, and
> avoid all the weirdnesses around labels, protocols and modes caused by
> dropping it.
>
> I like your Layer 2, but with the wireline protocol previously speced.  It
> gets you all the label/mode/etc sync stuff, and merely rules out option A
> (or requires you to dedicate a control stream).

If we have out-of-band negotiation, the only thing that the protocol
needs is a type indicator (one bit).  Reserve the other 7 bits (or 254
values) and we're done.  There is no benefit to the control messages.

From jonathan@vidyo.com  Fri Feb  8 07:59:59 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9311221F8AB7 for ; Fri,  8 Feb 2013 07:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.316
X-Spam-Level: 
X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.284,  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 U57OC-rCjQMS for ; Fri,  8 Feb 2013 07:59:59 -0800 (PST)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id EC46321F8A6E for ; Fri,  8 Feb 2013 07:59:58 -0800 (PST)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 00A9C416A2E; Fri,  8 Feb 2013 05:03:02 -0500 (EST)
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 A8C974169B0; Fri,  8 Feb 2013 05:02:36 -0500 (EST)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Fri, 8 Feb 2013 10:59:31 -0500
From: Jonathan Lennox 
To: Eric Rescorla 
Date: Fri, 8 Feb 2013 10:59:30 -0500
Thread-Topic: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
Thread-Index: Ac4GFUcjPcSygTsHS/CAvR70U4OLjA==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:59:59 -0000

On Feb 7, 2013, at 2:22 PM, Eric Rescorla wrote:

> Here's what I was trying to say at the microphone.
>=20
> 1. When two MSTracks are in the same MediaStream on the sending side:
>  They must generate the same MSID in SDP and the same CNAME in RTP.

Note that, as a consequence of this -- if the same MediaStreamTrack is put =
into two different MediaStreams of the same PeerConnection, the sending sid=
e will need to synchronize all the tracks of those two MediaStreams togethe=
r, and give them all the same CNAME.  (Because synchronization is transitiv=
e.)

If Stefan's proposal is accepted (i.e., all the tracks from a single endpoi=
nt are synchronized, period), this may come for free, at least for locally-=
generated tracks.  But if it isn't, this is a subtlety that may not be full=
y appreciated.

--
Jonathan Lennox
jonathan@vidyo.com



From Michael.Tuexen@lurchi.franken.de  Fri Feb  8 09:43:59 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC321F8B18 for ; Fri,  8 Feb 2013 09:43:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 pVREVJkJbgnu for ; Fri,  8 Feb 2013 09:43:58 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B5D7621F8B16 for ; Fri,  8 Feb 2013 09:43:57 -0800 (PST)
Received: from [192.168.1.101] (p508FB4BF.dip.t-dialin.net [80.143.180.191]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 794D21C0C069B; Fri,  8 Feb 2013 18:43:54 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Michael Tuexen 
In-Reply-To: 
Date: Fri, 8 Feb 2013 18:43:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Martin Thomson 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 17:43:59 -0000

Hi Martin,

just a few comments/questions in-line.

Best regards
Michael

On Feb 7, 2013, at 12:22 PM, Martin Thomson wrote:

> We're a fickle lot.  It seems that decisions can be unmade very =
easily.
>=20
> In any case, I promised a concrete proposal.  Here it is.  Beware:
> long post ahead.
>=20
> This proposal is progressive, I think that the best option would be to
> take all of it, but we could choose to not adopt the later parts.
> I'll start with the basics.
>=20
> =3D=3DLayer 1
>=20
> Negotiate all new data channels with SDP offer/answer.
>=20
> As I understand it, the 1.5 round trip cost for in-band channel
> creation was to prevent glare.  (Randell hinted that there might have
> been something else that was SCTP-specific, but this appears to reduce
> to a straightforward glare situation.)  Doing the negotiation in SDP
> lets us use the glare mitigation mechanisms we have built into SDP, so
> we save 0.5 round trips for every new channel.
>=20
> This allows us to ditch the in-band signaling protocol almost entirely
> (see Option B below).
>=20
> Creating a new data channel triggers the onnegotiationneeded event.
The signaling channel might have a different RTT than the peer to peer
connections. So you prefer to do take always the signaling channel.
Taking down a data channel is not signaled via SDP, right?

How do you handle a shortage in the number of streams? How do you
handle collisions if both sides want to open a data channel and
chose the same streams?
>=20
> =3D=3DLayer 2
>=20
> Zero round trip channel establishment
>=20
> The only reason that we have for negotiation of each channel is to
> provide a consistent set of characteristics for each channel.  The
> peer that creates a channel decides the values for label,
> retransmission count (0, n, infinite), and subprotocol.  If you don't
There is also a limitation of lifetime in milli seconds.
> care about these values being consistent between peers, or you have
> another means of ensuring consistency, you don't need to negotiate new
> channels at all.
So basically a data channel is not symmetric anymore. Do you consider
it bidirectional or unidirectional?
>=20
> Here, we permit the use of additional channels immediately after
> creation, without negotiation.  This has several advantages...and
> ramifications.  And no real drawbacks.
>=20
> Firstly, the arrival of a packet on a stream that is not negotiated
> will require the creation of a data channel.  The properties of this
If you consider a data channel to be bidirectional, what makes sure
that a stream for the backwards direction is available? How do you
now the pairing?
> data channel will be largely unknown. The browser can possibly detect
> that the channel is unreliable if the packet doesn't request
> acknowledgement, but that's something I'm not 100% clear on for
> partially reliable messages.  As a result, the browser will be
=46rom an SCTP point of view: A receiver doesn't know that a particular
user message was sent reliable or not until it gets a FORWARD-TSN
chunk...
> required to leave these properties undefined or generate default
> values for them.
>=20
> It's perfectly OK to have default or undefined values for label,
> reliability and subprotocol as long as you let the application set new
> values.  This allows for another advantage: applications can, if they
> choose, set the reliability on a per-packet basis, consistent with all
> other SCTP APIs, but setting the property before sending each packet.
> This keeps the simplicity of the API design, ensures websocket
> compatibility for those that need it, but it exposes more SCTP
> capabilities to those that desire those features.
I guess most of this comes down to the question of =
uni-/bi-directional...
>=20
> This does have consequences for negotiation: Values for label,
> reliability and subprotocol need to be declarative in SDP, not
> negotiated.  Both peers would be required to signal the values that
> they are using for each stream.  This would allow for the fact that
> peers could set different values for the same stream number, based on
> whatever values are set on their data channel object.  In the general
> case, it allows one peer to declare the use of a particular stream and
> the other peer to not advertise anything on the matching stream.
>=20
> This also makes the 'onopen' event useless for all but the first
> channel.  It should fire immediately for any channel that is created
> when the association is already active.
>=20
> Receipt of a message on a channel that has not already been created
> locally causes the following events, one after the other:
> ondatachannel, onopen, onmessage.
>=20
> In order to maintain the symmetrical usage pattern, and the
> websockets-compatible usage pattern, we would then require several
> things:
> 1. The browser MUST, by default, negotiate streams with values that
> match any in an offer if it does not already have a data channel for
> that stream number.  The browser MUST also create the corresponding
> data channels.
> 2. Applications that require perfect channel symmetry need to
> negotiate before using streams.
> 3. Applications that care about having their use of the API be
> interchangeable with websockets need to wait for the 'onopen' event
> before sending anything, lest they get errors when switching to
> websockets.
>=20
> On that last point: We could require that channels reject attempts to
> send() prior to the onopen event being processed, but that is
> unnecessarily mean.  Calling createDataChannel() followed immediately
> by send() should be OK as long as the association is active.  Just
> because you haven't processed the 'onopen', doesn't mean that you
> should be prevented from using a perfectly usable channel.  Of course,
> waiting for onopen would be safest in the general case, and many
> applications would naturally do this, but I see no reason to constrain
> usage patterns unnecessarily.
>=20
> =3D=3D=3DOption A
>=20
> Removing the in-band protocol makes the negotiation of the protocol
> that layers on top of SCTP less crucial ... it makes negotiation of
> the upper-layer protocol less crucial.  In the WebRTC case, we
> probably don't need to negotiate 'webrtc-datachannel', we could even
> let the application decide the value for that label.
>=20
> Personally, I don't think that we need to surface API to enable
> changing protocols.  However, it would be completely harmless in this
> configuration for an application to change the protocol label to
> something else by editing SDP, so that they could interoperate with a
> peer that expected another protocol.  That would enable CLUE usage, or
> BFCP, or whatever, as long as you can find someone who talks SCTP over
> DTLS over UDP.
>=20
> =3D=3D=3DOption B
>=20
> The one remnant of the in-band protocol that remains is the parts that
> apply to the data payloads.  The in-band protocol is required to
> provide two features:
> 1. the ability to distinguish between textual data and binary data
> 2. the ability to send messages of arbitrary length
>=20
> I am sorely tempted to suggest that the first feature can instead be
> part of channel configuration, such that it is negotiated (with a
> default of binary).  This would mean that negotiation is needed if you
> want to use text and you can't handle the conversion of binary to
> text.  (Sadly, this isn't made easy and the top answer at
> stackoverflow doesn't work for UTF-8:
> =
http://stackoverflow.com/questions/6965107/converting-between-strings-and-=
arraybuffers)
>=20
> For the second, draft-jesup-rtcweb-data-protocol indicates that 2Gb is
> the limit, but my reading of RFC 4920 indicates that there is no limit
> to message size.  I'm far from expert in this area, but is it possible
Not sure why you refer to RFC 4920... RFC 4960 (SCTP) doesn't have such
a limit.
> that this is an implementation limitation rather than a protocol one?
> Either way, I'm tempted to suggest that fragmentation can be pushed to
> the application.
>=20
> This would allow for direct access to SCTP, rather than an
> encapsulated layer.  This is good for several reasons.  Firstly, we
> don't need to specify a protocol at all.  We avoid all the arguments
> about what byte goes where.  More importantly, it leaves the SCTP
> clean, allowing WebRTC applications to use SCTP without ornamentation.
Going down this road: Do you consider data channels as abstractions
of SCTP streams? So uni-directional?
>=20
> =3D=3D=3DOption C
>=20
> If you care about reconciling the values for label, reliability, and
> subprotocol, it might be necessary to surface the values declared by
> your peer in the API.  You can get this information from the SDP, but
> if you don't like the idea of SDP spelunking you have two choices:
> provide an 'on(re)negotiated' event that carries the values declared
> by the remote peer; or, provide read-only accessors for these.
>=20
> I'm not certain that reconciliation of these values is important.
> Applications can even build their own mechanisms if it is.  If we must
> build more mechanisms, then I tend to favor the 'on(re)negotiated'
> event.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20


From harald@alvestrand.no  Fri Feb  8 13:38:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABAC21F8782 for ; Fri,  8 Feb 2013 13:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.339
X-Spam-Level: 
X-Spam-Status: No, score=-110.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 JjfB9hhq+4sj for ; Fri,  8 Feb 2013 13:38:13 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35D21F87B6 for ; Fri,  8 Feb 2013 13:38:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0B5039E197 for ; Fri,  8 Feb 2013 22:37:59 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXveap712N2x for ; Fri,  8 Feb 2013 22:37:58 +0100 (CET)
Received: from [IPv6:2620:0:1004:b:f175:1fb4:5361:b9a8] (unknown [IPv6:2620:0:1004:b:f175:1fb4:5361:b9a8]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C476739E125 for ; Fri,  8 Feb 2013 22:37:57 +0100 (CET)
Message-ID: <51157034.3020800@alvestrand.no>
Date: Fri, 08 Feb 2013 22:37:56 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com>
In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 21:38:14 -0000

On 02/07/2013 09:08 PM, Charles Eckel (eckelcu) wrote:
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Eric Rescorla
>> Sent: Thursday, February 07, 2013 3:03 PM
>> To: Stefan Hakansson LK
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for
>> synchronization
>>
>>
>>
>> On Thu, Feb 7, 2013 at 11:59 AM, Stefan Hakansson LK
>>  wrote:
>>
>>
>> 	On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>>
>>
>>
>>
>>
>>
>> 		    My question is basically: what if the sender creates two
>> 		    MediaStreams for which all tracks have local sources
>> (cam's,
>> 		    mike's), sends them to a peer, will the RTP streams for
>> both
>> 		    MediaStreams have the same or different CNAME?
>>
>> 		    I argued for that they should have the same.
>>
>>
>> 		Yes, I think this is a separate (and fraught) question. :)
>>
>>
>>
>> 	Separate question, but I think the answer should be documented
>> (regardless on if it is "same", "different" or "implementers choice").
>>
>>
>>
>> Agreed.
> I think SHOULD is the correct thing to document. I can imagine there will be cases in which the sender will be a somewhat distributed app that does not really know that the media source should be synchronized, so it will assign a different CNAME.
> The rest of the proposal sounded good as well.
>
>
SHOULD often makes me unhappy, because it can lead easily to something 
being true so much of the time, people forget to check for whether it is 
true or not.

I think "all the streams have local sources" is a property that we 
shouldn't require that one end of a PeerConnection reveals to the other end.

(Parenthesis: In the discussion, the question was raised of what it 
meant to send out two tracks in one MediaStream that were not 
originallly synchronized - one local and one remote, for instance. The 
best answer I heard was that they would have to be synchronized 
(re-clocked if necessary) in such a way that when played out at the 
recipient, they would give the same experience as when played out 
locally at the sender - same relative timing for the playout.)


From stefan.lk.hakansson@ericsson.com  Sat Feb  9 05:11:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FD721F8839 for ; Sat,  9 Feb 2013 05:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.961
X-Spam-Level: 
X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgPSjixJgWBx for ; Sat,  9 Feb 2013 05:11:27 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2730C21F8815 for ; Sat,  9 Feb 2013 05:11:26 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-55-51164afe73e8
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 29.C5.19728.EFA46115; Sat,  9 Feb 2013 14:11:26 +0100 (CET)
Received: from [153.88.44.235] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Sat, 9 Feb 2013 14:11:25 +0100
Message-ID: <51164AFC.80700@ericsson.com>
Date: Sat, 9 Feb 2013 14:11:24 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no>
In-Reply-To: <51157034.3020800@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvje4/L7FAgxX9QhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+WatYwFp8QqZm6awNjAeF6wi5GTQ0LARGLi3dXMELaYxIV7 69m6GLk4hAROMkrsmbWOCcJZxSgx+eMvRpAqXgFNibWH24ESHBwsAioSPzeADWITCJS4/v8X E4gtKhAl8f5qEzNEuaDEyZlPWEBsEQFhia2vesFahQVCJFYeZAUJCwn8YZJYtSUbxOYU0JX4 u3s9WDmzgK3EhTnXoWx5ie1v5zBD1OtKvHt9j3UCo8AsJBtmIWmZhaRlASPzKkb23MTMnPRy o02MwCA7uOW36g7GO+dEDjFKc7AoifOGu14IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCo 4CZ9Md32ltKeOOnN4kbFsd+Xlruc32iz4eA+wfRvL1hFPHqe7tjEdTnwpL1ZoJVGQIz6kpVq bYJSM19sdzzSc/FgjPG0WSINC6yfdv9sk18xi3eBsbLx98KLIWz3JifN3pThfvrdRK9PaxbJ RPncvfb/ePm7nF+pS6w2pRkWTonZbvj9u9M+JZbijERDLeai4kQA0Bpp7AACAAA=
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Feb 2013 13:11:29 -0000

On 2013-02-08 22:37, Harald Alvestrand wrote:
> On 02/07/2013 09:08 PM, Charles Eckel (eckelcu) wrote:
>>> -----Original Message-----
>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>> Behalf Of Eric Rescorla
>>> Sent: Thursday, February 07, 2013 3:03 PM
>>> To: Stefan Hakansson LK
>>> Cc: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for
>>> synchronization
>>>
>>>
>>>
>>> On Thu, Feb 7, 2013 at 11:59 AM, Stefan Hakansson LK
>>>  wrote:
>>>
>>>
>>>     On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>             My question is basically: what if the sender creates two
>>>             MediaStreams for which all tracks have local sources
>>> (cam's,
>>>             mike's), sends them to a peer, will the RTP streams for
>>> both
>>>             MediaStreams have the same or different CNAME?
>>>
>>>             I argued for that they should have the same.
>>>
>>>
>>>         Yes, I think this is a separate (and fraught) question. :)
>>>
>>>
>>>
>>>     Separate question, but I think the answer should be documented
>>> (regardless on if it is "same", "different" or "implementers choice").
>>>
>>>
>>>
>>> Agreed.
>> I think SHOULD is the correct thing to document. I can imagine there
>> will be cases in which the sender will be a somewhat distributed app
>> that does not really know that the media source should be
>> synchronized, so it will assign a different CNAME.
>> The rest of the proposal sounded good as well.
>>
>>
> SHOULD often makes me unhappy, because it can lead easily to something
> being true so much of the time, people forget to check for whether it is
> true or not.
>
> I think "all the streams have local sources" is a property that we
> shouldn't require that one end of a PeerConnection reveals to the other
> end.

When you say "streams" above I guess you mean RTP streams (or 
MediaStreamTracks) as it would not make sense to make this a secret when 
they are transported in different MediaStreams but expose it if they are 
in the same.

What info would reveal this ("have local sources")? Is it them having 
the same CNAME?

>
> (Parenthesis: In the discussion, the question was raised of what it
> meant to send out two tracks in one MediaStream that were not
> originallly synchronized - one local and one remote, for instance. The
> best answer I heard was that they would have to be synchronized
> (re-clocked if necessary) in such a way that when played out at the
> recipient, they would give the same experience as when played out
> locally at the sender - same relative timing for the playout.)
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From harald@alvestrand.no  Sat Feb  9 06:40:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0BB21F882A for ; Sat,  9 Feb 2013 06:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQr35AMAcTni for ; Sat,  9 Feb 2013 06:40:37 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 64AA921F87FA for ; Sat,  9 Feb 2013 06:40:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 525A639E194 for ; Sat,  9 Feb 2013 15:40:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCw5l-2AwWbx for ; Sat,  9 Feb 2013 15:40:33 +0100 (CET)
Received: from [192.168.1.84] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E292139E151 for ; Sat,  9 Feb 2013 15:40:30 +0100 (CET)
Message-ID: <51165FCA.2040707@alvestrand.no>
Date: Sat, 09 Feb 2013 15:40:10 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com>
In-Reply-To: <51164AFC.80700@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Feb 2013 14:40:38 -0000

On 02/09/2013 02:11 PM, Stefan Håkansson LK wrote:
> On 2013-02-08 22:37, Harald Alvestrand wrote:
>> On 02/07/2013 09:08 PM, Charles Eckel (eckelcu) wrote:
>>>> -----Original Message-----
>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>>> Behalf Of Eric Rescorla
>>>> Sent: Thursday, February 07, 2013 3:03 PM
>>>> To: Stefan Hakansson LK
>>>> Cc: rtcweb@ietf.org
>>>> Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for
>>>> synchronization
>>>>
>>>>
>>>>
>>>> On Thu, Feb 7, 2013 at 11:59 AM, Stefan Hakansson LK
>>>>  wrote:
>>>>
>>>>
>>>>     On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             My question is basically: what if the sender creates two
>>>>             MediaStreams for which all tracks have local sources
>>>> (cam's,
>>>>             mike's), sends them to a peer, will the RTP streams for
>>>> both
>>>>             MediaStreams have the same or different CNAME?
>>>>
>>>>             I argued for that they should have the same.
>>>>
>>>>
>>>>         Yes, I think this is a separate (and fraught) question. :)
>>>>
>>>>
>>>>
>>>>     Separate question, but I think the answer should be documented
>>>> (regardless on if it is "same", "different" or "implementers choice").
>>>>
>>>>
>>>>
>>>> Agreed.
>>> I think SHOULD is the correct thing to document. I can imagine there
>>> will be cases in which the sender will be a somewhat distributed app
>>> that does not really know that the media source should be
>>> synchronized, so it will assign a different CNAME.
>>> The rest of the proposal sounded good as well.
>>>
>>>
>> SHOULD often makes me unhappy, because it can lead easily to something
>> being true so much of the time, people forget to check for whether it is
>> true or not.
>>
>> I think "all the streams have local sources" is a property that we
>> shouldn't require that one end of a PeerConnection reveals to the other
>> end.
>
> When you say "streams" above I guess you mean RTP streams (or 
> MediaStreamTracks) as it would not make sense to make this a secret 
> when they are transported in different MediaStreams but expose it if 
> they are in the same.
When they are in the same MediaStream, they are required to have the 
same CNAME (unless I lost track of the conversation), so it's only when 
they're in different MediaStreams that it matters whether the CNAME is 
the same or not.

>
> What info would reveal this ("have local sources")? Is it them having 
> the same CNAME?

Yes.


From randell-ietf@jesup.org  Sat Feb  9 07:24:43 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4721F88E4 for ; Sat,  9 Feb 2013 07:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 p3lgLtO1BVz3 for ; Sat,  9 Feb 2013 07:24:42 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C860921F85DA for ; Sat,  9 Feb 2013 07:24:42 -0800 (PST)
Received: from 216-206-165-162.dia.static.qwest.net ([216.206.165.162]:58107 helo=[192.168.5.197]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U4CIE-000Bgh-27 for rtcweb@ietf.org; Sat, 09 Feb 2013 09:24:42 -0600
Message-ID: <51166A3C.4000604@jesup.org>
Date: Sat, 09 Feb 2013 10:24:44 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5113CD16.6090806@jesup.org> 
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Feb 2013 15:24:43 -0000

On 2/8/2013 4:21 AM, Martin Thomson wrote:
> On 7 February 2013 10:49, Randell Jesup  wrote:
>> The proposal I made yesterday (though I really didn't get a chance to
>> present it) was purely declarative in the SDP (the mixed case I proposed).
>> They were stand-ins for the Open in-band messages and carried the same
>> declarative info.
> The difference, from what I saw, was that the declarations in your
> examples showed stream 1 in the offer and no stream 1 in the answer.
> This would require that stream 1 appear in the answer with the
> attributes that the answerer had assigned (which we would require to
> be the same as the offerer, unless the answerer side had already had
> created a DataChannel).

As I mentioned, it was purely declarative (no response/negotiation), 
which is why the return SDP doesn't have them.

If you were to extend this to work for renegotiations where glare is 
possible, you'd have to either wait for the renegotiation to finish, or 
use some even/odd sort of trick which was proposed way back when on the 
list.

>> This limit probably can be relaxed; Websockets allows IIRC 71-bit lengths
>> ...  just in case you need them.
> 63 bit.  A poor decision in my opinion, but we need to respect working
> group consensus.

Ah yes, you're correct, 63 bits (encoded in 71 bits).  So small!


My proposal:
>> I like (a lot) the declarative approach, and all the complications were due
>> to needing to fulfill glare considerations (now resolved by not requiring
>> resolving of label glare and not requiring bidirectional stream pairs have
>> the same number), and due to the requirement for websockets compatibility
>> with onOpen (and to not fire it until you have positive notification from
>> the other side). If you drop that last part, you have immediate declarative
>> 0-RTT opening time DataChannels.  I would propose keeping things simpler for
>> users and to use the wireline protocol for the declaration/response, and
>> avoid all the weirdnesses around labels, protocols and modes caused by
>> dropping it.
>>
>> I like your Layer 2, but with the wireline protocol previously speced.  It
>> gets you all the label/mode/etc sync stuff, and merely rules out option A
>> (or requires you to dedicate a control stream).
> If we have out-of-band negotiation, the only thing that the protocol
> needs is a type indicator (one bit).  Reserve the other 7 bits (or 254
> values) and we're done.  There is no benefit to the control messages.

Out-of-band negotiation means either:

a) SDP offer/answer (which in many cases will go via a central server, 
though it can go over an existing datachannel), min 1 RTT (perhaps 
1-RTT-through-server) plus SDP processing delay, and requires 
implementing error handling for cases where the answers and offers don't 
properly match up,

b) a single control stream, which works, but it adds complexity since 
SCTP doesn't make between-stream guarantees about delivery, so you have 
to either have a handshake on the control stream before sending data (1 
RTT at least), or you need to have methods in place to handle 
out-of-order control versus data delivery, or

c) application-implemented out-of-band negotiation, which just (IMHO) 
pushes the problem off onto the application without solving any problems 
for the general case.  In the (fairly common) app talking to another 
instance of itself or a "known" peer, the application could pre-define 
what streams/channels mean, if we surface the stream numbers to the API 
(this would be far closer to the old 'raw SCTP' proposals, which push a 
lot over onto the app). This would also make interoperating in 
federation cases considerably more complex.

The reason the current in-band protocol uses in-stream open messages is 
that this avoids any out-of-order delivery issues (they're marked as 
reliable-in-order).  If you relax the don't-send-until-onopen JS 
requirement (which is no work for the wireline protocol; it's already 
supported) and fire onopen immediately on createDataChannel or when a 
channel open comes in, you have 0-RTT startup, and you retain all the 
symmetry, label, protocol, etc that had been previously agreed to.  See 
my quoted proposal above.

Are there real usecases where the in-band Open and OpenResponse messages 
actually cause a usecase not to work?

-- 
Randell Jesup
randell-ietf@jesup.org


From stefan.lk.hakansson@ericsson.com  Sun Feb 10 04:47:12 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD61521F845F for ; Sun, 10 Feb 2013 04:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.66
X-Spam-Level: 
X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=-0.311,  BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=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 QUU1KnTY+Frt for ; Sun, 10 Feb 2013 04:47:11 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6251421F8459 for ; Sun, 10 Feb 2013 04:47:03 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-32-511796c630e6
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 36.E7.32353.6C697115; Sun, 10 Feb 2013 13:47:02 +0100 (CET)
Received: from [153.88.62.210] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Sun, 10 Feb 2013 13:47:02 +0100
Message-ID: <511796C6.3050601@ericsson.com>
Date: Sun, 10 Feb 2013 13:47:02 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com> <51165FCA.2040707@alvestrand.no>
In-Reply-To: <51165FCA.2040707@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvje6xaeKBBq+7lCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpFLt9kL9olWHGzcwt7AOFuwi5GTQ0LAROLW4lOMELaYxIV7 69m6GLk4hAROMkocvf0PylnNKNHW/4MFpIpXQFuia/VjVhCbRUBV4ui+vewgNptAoMT1/7+Y QGxRgSiJ91ebmCHqBSVOznwC1isiICyx9VUvUA0Hh7BAiMTKg6wQ83czS5zq2g/WyymgKzFj 5Sqwi5gFbCUuzLnOAmHLSzRvnQ02Uwio5t3re6wTGAVmIVkxC0nLLCQtCxiZVzGy5yZm5qSX m29iBAbawS2/DXYwbrovdohRmoNFSZw33PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG zojmb/4aRULpK86lJ6474MAkr/U+5ZN8xPZF8d3pL5671s9gbcqO3NJnkl8tbJqd99Pq7MVH TyQCuqX/7VX6oR9ULPFW52K7vaFOPf/Nok2PWvtWZmru9jDa0vN8+gxRN6/3s+5JCZ/Iyrhe qb7sIM/vNw/YDm7493eRzJLTmpd/dCYsmGinxFKckWioxVxUnAgAyUuRswICAAA=
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 12:47:13 -0000

On 2013-02-09 15:40, Harald Alvestrand wrote:
> On 02/09/2013 02:11 PM, Stefan Håkansson LK wrote:
>> On 2013-02-08 22:37, Harald Alvestrand wrote:
>>> On 02/07/2013 09:08 PM, Charles Eckel (eckelcu) wrote:
>>>> I think SHOULD is the correct thing to document. I can imagine there
>>>> will be cases in which the sender will be a somewhat distributed app
>>>> that does not really know that the media source should be
>>>> synchronized, so it will assign a different CNAME.
>>>> The rest of the proposal sounded good as well.
>>>>
>>>>
>>> SHOULD often makes me unhappy, because it can lead easily to something
>>> being true so much of the time, people forget to check for whether it is
>>> true or not.
>>>
>>> I think "all the streams have local sources" is a property that we
>>> shouldn't require that one end of a PeerConnection reveals to the other
>>> end.
>>
>> When you say "streams" above I guess you mean RTP streams (or
>> MediaStreamTracks) as it would not make sense to make this a secret
>> when they are transported in different MediaStreams but expose it if
>> they are in the same.
> When they are in the same MediaStream, they are required to have the
> same CNAME (unless I lost track of the conversation), so it's only when
> they're in different MediaStreams that it matters whether the CNAME is
> the same or not.
>
>>
>> What info would reveal this ("have local sources")? Is it them having
>> the same CNAME?
>
> Yes.

Just to verify that I get all of this correctly:
* There is a privacy issue if the app at the peer can find out if the 
tracks for _different_ MediaStream's have local sources
* This could be found out if the CNAME's are the same and if CNAME's are 
made available to the application
* Therefore we should have a design where tracks belonging to different 
MediaStream's use different CNAME's even if they originate from local 
sources at the same end-point

Did I get that right?

To me this seems far fetched. With this design you would have to select 
between synchronization and privacy, if you care about privacy each 
track would go to a different MediaStream (audio to one MS, video to 
another in the simple "one audio+one video" case) and there would be no 
sync.

If this is indeed a problem, then there must be other ways. A setting 
"privacy=on" on PeerConnection, or do not expose CNAME to the app (do we 
really need to signal it?; and [1] indicates you can use other CNAME's 
than those signaled).

Stefan

[1] http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-attributes-01

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


From harald@alvestrand.no  Sun Feb 10 14:36:55 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C1821F8860 for ; Sun, 10 Feb 2013 14:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.38
X-Spam-Level: 
X-Spam-Status: No, score=-109.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+cygLsGngxo for ; Sun, 10 Feb 2013 14:36:55 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B83C221F86C5 for ; Sun, 10 Feb 2013 14:36:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E536F39E0F3 for ; Sun, 10 Feb 2013 23:36:51 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+mbgiXKl4ta for ; Sun, 10 Feb 2013 23:36:50 +0100 (CET)
Received: from [192.168.240.52] (unknown [209.117.47.251]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 97F5C39E058 for ; Sun, 10 Feb 2013 23:36:50 +0100 (CET)
Message-ID: <511820F9.5080806@alvestrand.no>
Date: Sun, 10 Feb 2013 23:36:41 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com> <51165FCA.2040707@alvestrand.no> <511796C6.3050601@ericsson.com>
In-Reply-To: <511796C6.3050601@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 22:36:56 -0000

On 02/10/2013 01:47 PM, Stefan Håkansson LK wrote:
> On 2013-02-09 15:40, Harald Alvestrand wrote:
>> On 02/09/2013 02:11 PM, Stefan Håkansson LK wrote:
>>> On 2013-02-08 22:37, Harald Alvestrand wrote:
>>>> On 02/07/2013 09:08 PM, Charles Eckel (eckelcu) wrote:
>>>>> I think SHOULD is the correct thing to document. I can imagine there
>>>>> will be cases in which the sender will be a somewhat distributed app
>>>>> that does not really know that the media source should be
>>>>> synchronized, so it will assign a different CNAME.
>>>>> The rest of the proposal sounded good as well.
>>>>>
>>>>>
>>>> SHOULD often makes me unhappy, because it can lead easily to something
>>>> being true so much of the time, people forget to check for whether 
>>>> it is
>>>> true or not.
>>>>
>>>> I think "all the streams have local sources" is a property that we
>>>> shouldn't require that one end of a PeerConnection reveals to the 
>>>> other
>>>> end.
>>>
>>> When you say "streams" above I guess you mean RTP streams (or
>>> MediaStreamTracks) as it would not make sense to make this a secret
>>> when they are transported in different MediaStreams but expose it if
>>> they are in the same.
>> When they are in the same MediaStream, they are required to have the
>> same CNAME (unless I lost track of the conversation), so it's only when
>> they're in different MediaStreams that it matters whether the CNAME is
>> the same or not.
>>
>>>
>>> What info would reveal this ("have local sources")? Is it them having
>>> the same CNAME?
>>
>> Yes.
>
> Just to verify that I get all of this correctly:
> * There is a privacy issue if the app at the peer can find out if the 
> tracks for _different_ MediaStream's have local sources
> * This could be found out if the CNAME's are the same and if CNAME's 
> are made available to the application
> * Therefore we should have a design where tracks belonging to 
> different MediaStream's use different CNAME's even if they originate 
> from local sources at the same end-point
>
> Did I get that right?
Points one and two, yes. Point three, no, that's not my thinking.
I see no reason to force different CNAMEs, I just want to permit it.
>
> To me this seems far fetched. With this design you would have to 
> select between synchronization and privacy, if you care about privacy 
> each track would go to a different MediaStream (audio to one MS, video 
> to another in the simple "one audio+one video" case) and there would 
> be no sync.
>
> If this is indeed a problem, then there must be other ways. A setting 
> "privacy=on" on PeerConnection, or do not expose CNAME to the app (do 
> we really need to signal it?; and [1] indicates you can use other 
> CNAME's than those signaled).
What I'd like to have is to have no statement that forces (even at 
SHOULD level) all local sources to have the same CNAME, and perhaps even 
an explicit statement that the sender can use different CNAMEs for local 
sources if it wants to (for whatever reason it wants to do so), as long 
as they are in different tracks.




From stefan.lk.hakansson@ericsson.com  Mon Feb 11 05:10:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37C521F8578 for ; Mon, 11 Feb 2013 05:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.639
X-Spam-Level: 
X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=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 qiwP1IoScLSM for ; Mon, 11 Feb 2013 05:10:29 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2457F21F8B3A for ; Mon, 11 Feb 2013 05:10:28 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-1a-5118edc45444
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CA.A3.10459.4CDE8115; Mon, 11 Feb 2013 14:10:28 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 11 Feb 2013 14:10:25 +0100
Message-ID: <5118EDC1.2000809@ericsson.com>
Date: Mon, 11 Feb 2013 14:10:25 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com> <51165FCA.2040707@alvestrand.no> <511796C6.3050601@ericsson.com> <511820F9.5080806@alvestrand.no>
In-Reply-To: <511820F9.5080806@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje6RtxKBBh/eClms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJmdz1gLvghXLP26m62B8TV/FyMnh4SAicTdK/vYIWwxiQv3 1rN1MXJxCAmcZJS4e2s5I4SzllHi/pPLrCBVvALaErdebmMEsVkEVCU2H57LAmKzCQRKXP// iwnEFhWIknh/tYkZol5Q4uTMJ2A1IgLCEltf9QLVcHAIC4RIrDzICjH/D7PEyYt/GEHinAK6 EtN3WIKUMwvYSlyYc50FwpaXaN46G2ykEFDJu9f3WCcwCsxCsmEWkpZZSFoWMDKvYmTPTczM SS833MQIDLODW37r7mA8dU7kEKM0B4uSOG+Y64UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYz90pZH07JlzXgrKrwWLGCPz67s2ZkUvWHrywNigSfNXT8tqhH9pN54Mod/6VlO38+6nIG5 880eHVX75CnU/8XWI4rR+Sn3Ka35jbX7YwyXVyk/ef1KuJCvbbcXk8bleeez3XK2fNq+hufF ee3ZHif4+Sx3OSoL26l8fXoo+uolnbSs1kqT70osxRmJhlrMRcWJAH4vfwABAgAA
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 13:10:31 -0000

On 2013-02-10 23:36, Harald Alvestrand wrote:
> On 02/10/2013 01:47 PM, Stefan Håkansson LK wrote:
>> On 2013-02-09 15:40, Harald Alvestrand wrote:
>>> On 02/09/2013 02:11 PM, Stefan Håkansson LK wrote:
>>>> On 2013-02-08 22:37, Harald Alvestrand wrote:
>>
>> Just to verify that I get all of this correctly:
>> * There is a privacy issue if the app at the peer can find out if the
>> tracks for _different_ MediaStream's have local sources
>> * This could be found out if the CNAME's are the same and if CNAME's
>> are made available to the application
>> * Therefore we should have a design where tracks belonging to
>> different MediaStream's use different CNAME's even if they originate
>> from local sources at the same end-point
>>
>> Did I get that right?
> Points one and two, yes. Point three, no, that's not my thinking.
> I see no reason to force different CNAMEs, I just want to permit it.
>>
>> To me this seems far fetched. With this design you would have to
>> select between synchronization and privacy, if you care about privacy
>> each track would go to a different MediaStream (audio to one MS, video
>> to another in the simple "one audio+one video" case) and there would
>> be no sync.
>>
>> If this is indeed a problem, then there must be other ways. A setting
>> "privacy=on" on PeerConnection, or do not expose CNAME to the app (do
>> we really need to signal it?; and [1] indicates you can use other
>> CNAME's than those signaled).
> What I'd like to have is to have no statement that forces (even at
> SHOULD level) all local sources to have the same CNAME, and perhaps even
> an explicit statement that the sender can use different CNAMEs for local
> sources if it wants to (for whatever reason it wants to do so), as long
> as they are in different tracks.

The problem I have with this is that it makes it impossible for someone 
building a service to know whether streams will be synced (and I mean in 
situations when syncing makes sense - not when the video is delayed by 
500ms) or not. This is fully up to the browser - it may be that 
sometimes they are and sometimes not.

I would prefer that all streams used the same CNAME (if it is signaled 
or not is another question). If this is a privacy issue I think we 
should solve that instead of having the browser use, or not use, the 
same CNAMEs at its own will.

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


From martin.thomson@gmail.com  Mon Feb 11 11:40:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348F721F8845 for ; Mon, 11 Feb 2013 11:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.839
X-Spam-Level: 
X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=-1.240, 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 OJDhbNRzMZSE for ; Mon, 11 Feb 2013 11:40:12 -0800 (PST)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCEC21F87C3 for ; Mon, 11 Feb 2013 11:40:12 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id e12so4920714wge.34 for ; Mon, 11 Feb 2013 11:40:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zah9+3FssmdJx49N4H6IVp6lcfh8+hI3dVMXL0TzajE=; b=mMkBONjxtIFV2GKbUNsB9ZOBkVWlEmQl8E3XGxYlpdJ1kR9Gokwlp86RXqDrpsER4X rqxYX8ei7hIr36jGPDlciqr4d4WEh8iHABCzMzIh4pqOCTiwNzXtL9axN5QFjXo3AODv qSHU++GQv/X6w1bo0YxZ+7J+or5E54pYOITPaOuYVejXp0Z0OvUep9w/KPqxANSjzqF9 7b2M9WqupZiZcChuV8wuNTuuu0tX8irP99T2elJoMUpHrC7BYpRADOxc9BRGlwWyLQoO IdmK1bjHz6u0qLUsMB0rzbqJ7sYJ7W50jOJQWB0ir3UfngsMUH15mCQZsfBnP0LEbSAK xsag==
MIME-Version: 1.0
X-Received: by 10.180.90.147 with SMTP id bw19mr18306260wib.28.1360611611456;  Mon, 11 Feb 2013 11:40:11 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Mon, 11 Feb 2013 11:40:11 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 11 Feb 2013 11:40:11 -0800
Message-ID: 
From: Martin Thomson 
To: Michael Tuexen 
Content-Type: text/plain; charset=UTF-8
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:40:13 -0000

On 8 February 2013 09:43, Michael Tuexen
 wrote:
>> Creating a new data channel triggers the onnegotiationneeded event.
> The signaling channel might have a different RTT than the peer to peer
> connections. So you prefer to do take always the signaling channel.

But since you have a short path for this, you can take that path.
Some people may prefer to take the slower signaling path for this, but
those that care about speed will use the data channel to do channel
establishment (and they will probably do what I suggest below).

> Taking down a data channel is not signaled via SDP, right?

I believe that you are able to use in-band mechanisms (6525) for take-down.

> How do you handle a shortage in the number of streams? How do you
> handle collisions if both sides want to open a data channel and
> chose the same streams?

A shortage is easy, createDataChannel can throw an exception.

Collisions are also easy - if you care about consistency, then do an
offer/answer, which has inbuilt glare resolution.  If you don't care
about consistency, both sides can create and use channels without
having to agree on the details.  (That's mostly based on the stuff
below.

> There is also a limitation of lifetime in milli seconds.

Sure, let's have that too.  All this is per-message, so consistency
isn't really a required property.

> So basically a data channel is not symmetric anymore. Do you consider
> it bidirectional or unidirectional?

Yes.  Depending on the needs of your application.  Inherently, they
are unidirectional.  But if you care about the bidirectional property,
then you are free to perform a signaling negotiation to ensure
consistency (which is the only property that was provided by the
negotiation as designed previously).

>> Firstly, the arrival of a packet on a stream that is not negotiated
>> will require the creation of a data channel.  The properties of this
> If you consider a data channel to be bidirectional, what makes sure
> that a stream for the backwards direction is available? How do you
> now the pairing?

There is no guarantee.  Two reasons for this, neither of which I find
particularly dire:

a. I don't recall there being any signalling of the stream limit, so
there is a possibility that the stream limit in one direction will
exceed the limit in the other.  Streams with numbers that exceed the
lower limit will of course be unable to be reciprocal.  Two solutions
occur to me: 1. prevent the sending of return messages, or 2. cap the
number of channels to the lower of the two stream limits.  I prefer
the latter.

b. There is no guarantee that the other side hasn't already created a
data channel on the same number.  That's not a problem - you just end
up with asymmetry.

Note: deferring the allocation of a stream number until messages are
sent on streams does allow the browser implementation some flexibility
in how it manages assignment of streams.

> Not sure why you refer to RFC 4920... RFC 4960 (SCTP) doesn't have such
> a limit.
Crossed wires :)

From martin.thomson@gmail.com  Mon Feb 11 11:54:02 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255AF21F8799 for ; Mon, 11 Feb 2013 11:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.97
X-Spam-Level: 
X-Spam-Status: No, score=-4.97 tagged_above=-999 required=5 tests=[AWL=-1.371,  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 eTgKNSNRT6ab for ; Mon, 11 Feb 2013 11:54:01 -0800 (PST)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8D321F85E0 for ; Mon, 11 Feb 2013 11:54:01 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id hn17so3588616wib.16 for ; Mon, 11 Feb 2013 11:54:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9MeTzL8+voaR0pz/cur4DzLUyZw3gxkETcSZ9bExw0o=; b=oViz9iFgelZ07pJiDdRfObyF9VM+AhvtBAsdog63j04g8/x1AFakSvcCit5vPBXKdm uxC0kN8arsRpx1PlkDcQaLOj9NhzZInziuIx2GZscX4arayPzmCL9TNQnSCaWayBi01Q TKVwokSFfCsiQh1oVwccO2jRMzvPGTHLke+4Rn8M4yUA2rrxPAeXKCSrZdLXvbCPRT6L 6xpt7zO4B10NQI8+E0jq2McbJ40Jy2RRYGS4YyawiXsrLRCk611Jra7QkQeDJk7YxCDO V3dcavjhDZ4DBQfa2m22+nvQhRFSos1pClP4DxaD/jq58b899eemlJy0CU41PtfK68sV cM3A==
MIME-Version: 1.0
X-Received: by 10.194.88.202 with SMTP id bi10mr26402843wjb.5.1360612440484; Mon, 11 Feb 2013 11:54:00 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Mon, 11 Feb 2013 11:54:00 -0800 (PST)
In-Reply-To: <51166A3C.4000604@jesup.org>
References:  <5113CD16.6090806@jesup.org>  <51166A3C.4000604@jesup.org>
Date: Mon, 11 Feb 2013 11:54:00 -0800
Message-ID: 
From: Martin Thomson 
To: Randell Jesup 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:54:02 -0000

On 9 February 2013 07:24, Randell Jesup  wrote:
> As I mentioned, it was purely declarative (no response/negotiation), which
> is why the return SDP doesn't have them.

Your examples didn't have the values for stream 1 echoed in the
answer, so I assumed that it was "semi-declarative" or something like
that: where the values for stream 1 were inferred.

> If you were to extend this to work for renegotiations where glare is
> possible, you'd have to either wait for the renegotiation to finish, or use
> some even/odd sort of trick which was proposed way back when on the list.

If you want to resolve glare, then you use the mechanisms you already
have for glare resolution.  Which, RFC 3264 defers to RFC 3261, which
uses a fairly heavy-weight mechanism.  Keep in mind that you already
need this if you are using offer-answer.  Use whatever mechanism you
already have in place (I like the tie-breaker random number method
myself).

Or, you could stop worrying about glare and in those cases where glare
is possible, allow the collision to proceed.

This is an application choice.
> Out-of-band negotiation means either:
>
> a) SDP offer/answer (which in many cases will go via a central server,
> though it can go over an existing datachannel), min 1 RTT (perhaps
> 1-RTT-through-server) plus SDP processing delay, and requires implementing
> error handling for cases where the answers and offers don't properly match
> up,

This was my thought.  There is no need to reserve a channel for this
purpose, that's just extra machinery.  Any app that wants the fast
path for this will make their own.  And, the nice thing about that is
that they can do this before setting up the session.

> Are there real usecases where the in-band Open and OpenResponse messages
> actually cause a usecase not to work?

Well, given that we need message type stuff, we already have to suffer
some extra muck on top of the SCTP association.  Not many applications
will survive that.

No, the real question is: what value do these messages actually add?
What information do they convey that isn't already negotiated through
other channels?

Starting a stream with a header that declares attributes for a stream
sounds nice, but it's completely unnecessary in a vast number of
cases.  For many cases, this is a case of the same piece of software
talking to itself - it hardly cares.  In many other cases, negotiation
of properties through SDP is perfectly sufficient.

The only case I see for an in-band protocol is where you wish to
invent some new protocol on this platform, and I can't really muster
up that much enthusiasm for that.  It's far too heavily reliant on my
imagination.  Even in those cases, my knowledge of existing SCTP usage
patterns suggest that the properties that are sent in
Open/OpenResponse messages are not that useful to have.  Many
applications will use the same values for all new streams.

From Michael.Tuexen@lurchi.franken.de  Mon Feb 11 12:04:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9166D21F86C4 for ; Mon, 11 Feb 2013 12:04:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 jD75OzTA0iTm for ; Mon, 11 Feb 2013 12:04:49 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAC621F86CD for ; Mon, 11 Feb 2013 12:04:48 -0800 (PST)
Received: from [192.168.1.101] (p508FA903.dip.t-dialin.net [80.143.169.3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B15331C0C0695; Mon, 11 Feb 2013 21:04:28 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Michael Tuexen 
In-Reply-To: 
Date: Mon, 11 Feb 2013 21:04:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5113CD16.6090806@jesup.org>  <51166A3C.4000604@jesup.org> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:04:49 -0000

On Feb 11, 2013, at 8:54 PM, Martin Thomson wrote:

> On 9 February 2013 07:24, Randell Jesup  =
wrote:
>> As I mentioned, it was purely declarative (no response/negotiation), =
which
>> is why the return SDP doesn't have them.
>=20
> Your examples didn't have the values for stream 1 echoed in the
> answer, so I assumed that it was "semi-declarative" or something like
> that: where the values for stream 1 were inferred.
>=20
>> If you were to extend this to work for renegotiations where glare is
>> possible, you'd have to either wait for the renegotiation to finish, =
or use
>> some even/odd sort of trick which was proposed way back when on the =
list.
>=20
> If you want to resolve glare, then you use the mechanisms you already
> have for glare resolution.  Which, RFC 3264 defers to RFC 3261, which
> uses a fairly heavy-weight mechanism.  Keep in mind that you already
> need this if you are using offer-answer.  Use whatever mechanism you
> already have in place (I like the tie-breaker random number method
> myself).
>=20
> Or, you could stop worrying about glare and in those cases where glare
> is possible, allow the collision to proceed.
>=20
> This is an application choice.
>> Out-of-band negotiation means either:
>>=20
>> a) SDP offer/answer (which in many cases will go via a central =
server,
>> though it can go over an existing datachannel), min 1 RTT (perhaps
>> 1-RTT-through-server) plus SDP processing delay, and requires =
implementing
>> error handling for cases where the answers and offers don't properly =
match
>> up,
>=20
> This was my thought.  There is no need to reserve a channel for this
> purpose, that's just extra machinery.  Any app that wants the fast
> path for this will make their own.  And, the nice thing about that is
> that they can do this before setting up the session.
>=20
>> Are there real usecases where the in-band Open and OpenResponse =
messages
>> actually cause a usecase not to work?
>=20
> Well, given that we need message type stuff, we already have to suffer
> some extra muck on top of the SCTP association.  Not many applications
> will survive that.
>=20
> No, the real question is: what value do these messages actually add?
One important thing is that they tie the two outgoing streams together.
Each side controls its outgoing streams.
The other things are just declaring channel properties...

Best regards
Michael
> What information do they convey that isn't already negotiated through
> other channels?
>=20
> Starting a stream with a header that declares attributes for a stream
> sounds nice, but it's completely unnecessary in a vast number of
> cases.  For many cases, this is a case of the same piece of software
> talking to itself - it hardly cares.  In many other cases, negotiation
> of properties through SDP is perfectly sufficient.
>=20
> The only case I see for an in-band protocol is where you wish to
> invent some new protocol on this platform, and I can't really muster
> up that much enthusiasm for that.  It's far too heavily reliant on my
> imagination.  Even in those cases, my knowledge of existing SCTP usage
> patterns suggest that the properties that are sent in
> Open/OpenResponse messages are not that useful to have.  Many
> applications will use the same values for all new streams.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20


From Michael.Tuexen@lurchi.franken.de  Mon Feb 11 12:14:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4A21F8837 for ; Mon, 11 Feb 2013 12:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 U75DhB31iGgm for ; Mon, 11 Feb 2013 12:14:56 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9040921F879B for ; Mon, 11 Feb 2013 12:14:55 -0800 (PST)
Received: from [192.168.1.101] (p508FA903.dip.t-dialin.net [80.143.169.3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7A4BC1C0C069D; Mon, 11 Feb 2013 21:14:54 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Michael Tuexen 
In-Reply-To: 
Date: Mon, 11 Feb 2013 21:14:53 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   
To: Martin Thomson 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:14:57 -0000

On Feb 11, 2013, at 8:40 PM, Martin Thomson wrote:

> On 8 February 2013 09:43, Michael Tuexen
>  wrote:
>>> Creating a new data channel triggers the onnegotiationneeded event.
>> The signaling channel might have a different RTT than the peer to peer
>> connections. So you prefer to do take always the signaling channel.
> 
> But since you have a short path for this, you can take that path.
> Some people may prefer to take the slower signaling path for this, but
> those that care about speed will use the data channel to do channel
> establishment (and they will probably do what I suggest below).
> 
>> Taking down a data channel is not signaled via SDP, right?
> 
> I believe that you are able to use in-band mechanisms (6525) for take-down.
Sure. The goal of my questions is to understand your proposal better...
> 
>> How do you handle a shortage in the number of streams? How do you
>> handle collisions if both sides want to open a data channel and
>> chose the same streams?
> 
> A shortage is easy, createDataChannel can throw an exception.
> 
> Collisions are also easy - if you care about consistency, then do an
> offer/answer, which has inbuilt glare resolution.  If you don't care
> about consistency, both sides can create and use channels without
> having to agree on the details.  (That's mostly based on the stuff
> below.
However, *if* data channels are bidirectional (which they currently are),
then you need to tie two streams together. This has to be done somehow.
I'm wondering how you envision this without using SDP and without the
data channel protocol...
> 
>> There is also a limitation of lifetime in milli seconds.
> 
> Sure, let's have that too.  All this is per-message, so consistency
> isn't really a required property.
OK.
> 
>> So basically a data channel is not symmetric anymore. Do you consider
>> it bidirectional or unidirectional?
> 
> Yes.  Depending on the needs of your application.  Inherently, they
> are unidirectional.  But if you care about the bidirectional property,
> then you are free to perform a signaling negotiation to ensure
> consistency (which is the only property that was provided by the
> negotiation as designed previously).
If we change to data channels being uni-directional, then most of
the stuff done by the data channel protocol is not required... I agree
with that conclusion.
However, currently that the bi-directional.
> 
>>> Firstly, the arrival of a packet on a stream that is not negotiated
>>> will require the creation of a data channel.  The properties of this
>> If you consider a data channel to be bidirectional, what makes sure
>> that a stream for the backwards direction is available? How do you
>> now the pairing?
> 
> There is no guarantee.  Two reasons for this, neither of which I find
> particularly dire:
> 
> a. I don't recall there being any signalling of the stream limit, so
> there is a possibility that the stream limit in one direction will
> exceed the limit in the other.  Streams with numbers that exceed the
> lower limit will of course be unable to be reciprocal.  Two solutions
> occur to me: 1. prevent the sending of return messages, or 2. cap the
Instead of "prevent sending the return message" which would one side
waiting forever, I would prefer sending some sort of error message
(which is currently not specified enough in the data channel protocol).
> number of channels to the lower of the two stream limits.  I prefer
> the latter.
As long as you know this limit... But RFC 6525 allows you to increase the
number of streams (unless the peer agrees to do so). 
> 
> b. There is no guarantee that the other side hasn't already created a
> data channel on the same number.  That's not a problem - you just end
> up with asymmetry.
This is a normal case with the current data channel protocol. The
stream identifiers might not be the same in both directions.
When testing with the current implementation in Firefox, this actually
happens a lot.
> 
> Note: deferring the allocation of a stream number until messages are
> sent on streams does allow the browser implementation some flexibility
> in how it manages assignment of streams.
> 
>> Not sure why you refer to RFC 4920... RFC 4960 (SCTP) doesn't have such
>> a limit.
> Crossed wires :)
... that was my guess.
> 


From martin.thomson@gmail.com  Mon Feb 11 13:44:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9F21F8682 for ; Mon, 11 Feb 2013 13:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level: 
X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 Ze5N9oMCkxxb for ; Mon, 11 Feb 2013 13:43:59 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 35AEC21F8893 for ; Mon, 11 Feb 2013 13:43:59 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hq4so3698969wib.12 for ; Mon, 11 Feb 2013 13:43:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=c3Ei2DILfB+QwTDL+vItArHelZwf5tOp4FboLdL6Ls4=; b=ohPoMQXYueP6sbvwayB0Hy/19uKSgaq5Qt7SO+MjyjOCXJKTuBdiaIYfVgmrCkRQFw x4dWsiRHaBlrPDvS3QvOuIrlsjUilVLFKhQWzkTBN619nVuYFPdnioVLKHT08LfyzvHa bVMNR3kI8wRiHdCTKtZQJWP5WlQJ8Dk8W5fqK8gJPV1Vs0ZHvE/yqbtcCeo1pb+c6pSy AtctSxNCi+8uNqdNwUgOVHJBS741g0GJnZzoIiiceVmx1zPW0BGcYTd4EAM4sqNkFbfG DPiXROtLTOs6s6zoe4oap2aEu6e5TB61vNfPUxrxyqDi+B27W7AIYp3wP2MvmkkLq5LY 3vBQ==
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr19699050wjw.21.1360619038398; Mon, 11 Feb 2013 13:43:58 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Mon, 11 Feb 2013 13:43:58 -0800 (PST)
In-Reply-To: 
References:    
Date: Mon, 11 Feb 2013 13:43:58 -0800
Message-ID: 
From: Martin Thomson 
To: Michael Tuexen 
Content-Type: text/plain; charset=UTF-8
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 21:44:00 -0000

On 11 February 2013, Michael Tuexen  wrote:
> One important thing is that they tie the two outgoing streams together.
> Each side controls its outgoing streams.
> The other things are just declaring channel properties...

The binding between stream X in one direction and stream X in the
other is as strong - or as loose - as the application needs.  This is
a departure from what was previously specified, but I think that the
advantages (0 RTT establishment) outweigh the disadvantages.


>>> How do you handle a shortage in the number of streams? How do you
>>> handle collisions if both sides want to open a data channel and
>>> chose the same streams?
>>
>> A shortage is easy, createDataChannel can throw an exception.
>>
>> Collisions are also easy - if you care about consistency, then do an
>> offer/answer, which has inbuilt glare resolution.  If you don't care
>> about consistency, both sides can create and use channels without
>> having to agree on the details.  (That's mostly based on the stuff
>> below.
> However, *if* data channels are bidirectional (which they currently are),
> then you need to tie two streams together. This has to be done somehow.
> I'm wondering how you envision this without using SDP and without the
> data channel protocol...

The easiest way to tie two channels together is to use the stream
number.  That is what I was proposing.

(If stream numbers are used, then you don't even need to have a strong
uniqueness guarantee on the label.)

In the case that this is negotiated, then the guarantee is exactly the
same as the one provided previously.  Otherwise, it's a little less
strong.  If both sides create a channel at the same time, then they
could be bound together without any strong assurances about the exact
nature of the bidirectionality guarantee.  Now, I'm OK with that.  You
may not be.

> If we change to data channels being uni-directional, then most of
> the stuff done by the data channel protocol is not required... I agree
> with that conclusion.
> However, currently that the bi-directional.

The API would remain bi-directional.  In fact, the API would be
unchanged, except as it pertains to timing of channel use.  The
guarantees with respect to consistency would be weaker than what is
provided, depending (again) on that timing.

> Instead of "prevent sending the return message" which would one side
> waiting forever,

That presumes a lot.  Many protocols have one-way messages.

> I would prefer sending some sort of error message
> (which is currently not specified enough in the data channel protocol).

This also assumes that you have some channel upon which to end this
error message, plus a definition for the error message.  I'm looking
to have less protocol machinery, not more.

>> number of channels to the lower of the two stream limits.  I prefer
>> the latter.
> As long as you know this limit... But RFC 6525 allows you to increase the
> number of streams (unless the peer agrees to do so).

Negotiating stream limits up doesn't seem like a particularly likely
thing in this sort of environment.  That said, we probably need to
decide if this is a feature that we want to have available.  If it is
available, then this could be used in the case that the limits are
reached.

>> b. There is no guarantee that the other side hasn't already created a
>> data channel on the same number.  That's not a problem - you just end
>> up with asymmetry.
> This is a normal case with the current data channel protocol. The
> stream identifiers might not be the same in both directions.
> When testing with the current implementation in Firefox, this actually
> happens a lot.

Interesting.  I'd be interested in learning how this would be signaled
and what the advantages of this arrangement are.

From harald@alvestrand.no  Mon Feb 11 23:38:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA6321F8BE8 for ; Mon, 11 Feb 2013 23:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.351
X-Spam-Level: 
X-Spam-Status: No, score=-110.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 FwcjZ5AOV2Ii for ; Mon, 11 Feb 2013 23:38:01 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4521F8BDB for ; Mon, 11 Feb 2013 23:38:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A188839E1BB for ; Tue, 12 Feb 2013 08:37:58 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Q6QKsMkjZ5 for ; Tue, 12 Feb 2013 08:37:57 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:906d:d465:2b80:5d1d] (unknown [IPv6:2001:470:de0a:27:906d:d465:2b80:5d1d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B198939E0A7 for ; Tue, 12 Feb 2013 08:37:57 +0100 (CET)
Message-ID: <5119F155.8090303@alvestrand.no>
Date: Tue, 12 Feb 2013 08:37:57 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com> <51165FCA.2040707@alvestrand.no> <511796C6.3050601@ericsson.com> <511820F9.5080806@alvestrand.no> <5118EDC1.2000809@ericsson.com>
In-Reply-To: <5118EDC1.2000809@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 07:38:04 -0000

On 02/11/2013 02:10 PM, Stefan Håkansson LK wrote:
>>> If this is indeed a problem, then there must be other ways. A setting
>>> "privacy=on" on PeerConnection, or do not expose CNAME to the app (do
>>> we really need to signal it?; and [1] indicates you can use other
>>> CNAME's than those signaled).
>> What I'd like to have is to have no statement that forces (even at
>> SHOULD level) all local sources to have the same CNAME, and perhaps even
>> an explicit statement that the sender can use different CNAMEs for local
>> sources if it wants to (for whatever reason it wants to do so), as long
>> as they are in different tracks.
>
> The problem I have with this is that it makes it impossible for 
> someone building a service to know whether streams will be synced (and 
> I mean in situations when syncing makes sense - not when the video is 
> delayed by 500ms) or not. This is fully up to the browser - it may be 
> that sometimes they are and sometimes not.

I don't understand what the problem is here. I may be dumb.
If syncing is important to the guy writing the service, (he can't live 
with them being unsynchronized), he should put them in the same stream.

Under your suggestion, it would be impossible to generate two 
MediaStreams that have local content and are *not* synced - I don't see 
a reason to outlaw that.

The practical issue I can think of would be a source that had its own 
clock, not the system clock, but is otherwise a local source. Having the 
same CNAME would require resynchronizing that source. I don't know if 
any such sources exist in practice, but again, I don't want to outlaw them.


>
> I would prefer that all streams used the same CNAME (if it is signaled 
> or not is another question). If this is a privacy issue I think we 
> should solve that instead of having the browser use, or not use, the 
> same CNAMEs at its own will. 

CNAMEs are signaled in RTCP SRs. We don't have the option of leaving 
them out.



From stefan.lk.hakansson@ericsson.com  Tue Feb 12 00:04:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18F621F8CA7 for ; Tue, 12 Feb 2013 00:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.921
X-Spam-Level: 
X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTCq+guNm-Lo for ; Tue, 12 Feb 2013 00:04:13 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 94DBD21F8C9E for ; Tue, 12 Feb 2013 00:04:11 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-25-5119f77a4eea
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 58.63.19728.977F9115; Tue, 12 Feb 2013 09:04:10 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Feb 2013 09:04:09 +0100
Message-ID: <5119F779.8080305@ericsson.com>
Date: Tue, 12 Feb 2013 09:04:09 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com> <51165FCA.2040707@alvestrand.no> <511796C6.3050601@ericsson.com> <511820F9.5080806@alvestrand.no> <5118EDC1.2000809@ericsson.com> <5119F155.8090303@alvestrand.no>
In-Reply-To: <5119F155.8090303@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvjW7Vd8lAg/MLeCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtW3d9kLnotU3DnbwtLAuE2gi5GDQ0LARKLzSnEXIyeQKSZx 4d56ti5GLg4hgZOMEof+zWWHcNYyShxefpoFpIpXQFti6+eDzCA2i4CqxI4nu1lBbDaBQInr /38xgdiiAlES7682MUPUC0qcnPkErFdEQFhi66teJpDFwgIhEisPskLM38si8eDPe7B6TgFd icYdF9lBbGYBW4kLc66zQNjyEs1bZ4PVCAHVvHt9j3UCo8AsJCtmIWmZhaRlASPzKkb23MTM nPRyo02MwDA7uOW36g7GO+dEDjFKc7AoifOGu14IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cDorqfXclPjE2Pc8eP1bRzJFu6tZSa6X2/8fjYj9+YPnb0LAnUZnsy3/NAskjPzzX61hkLG 2TlRhznDXzYqB8l3f6p8ttz75OF3u1YtOXzwFd+TM78ZF7tv/VKkI3W6ijdss4F6z+uvWzM+ +v9i+ZDFu2leYtbSNWsWmly/GdmZp/nn6YS+hGJnJZbijERDLeai4kQAnHhV+gECAAA=
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 08:04:14 -0000

On 2013-02-12 08:37, Harald Alvestrand wrote:
> On 02/11/2013 02:10 PM, Stefan Håkansson LK wrote:
>>>> If this is indeed a problem, then there must be other ways. A setting
>>>> "privacy=on" on PeerConnection, or do not expose CNAME to the app (do
>>>> we really need to signal it?; and [1] indicates you can use other
>>>> CNAME's than those signaled).
>>> What I'd like to have is to have no statement that forces (even at
>>> SHOULD level) all local sources to have the same CNAME, and perhaps even
>>> an explicit statement that the sender can use different CNAMEs for local
>>> sources if it wants to (for whatever reason it wants to do so), as long
>>> as they are in different tracks.
>>
>> The problem I have with this is that it makes it impossible for
>> someone building a service to know whether streams will be synced (and
>> I mean in situations when syncing makes sense - not when the video is
>> delayed by 500ms) or not. This is fully up to the browser - it may be
>> that sometimes they are and sometimes not.
>
> I don't understand what the problem is here. I may be dumb.

Or I am :)

> If syncing is important to the guy writing the service, (he can't live
> with them being unsynchronized), he should put them in the same stream.
>
> Under your suggestion, it would be impossible to generate two
> MediaStreams that have local content and are *not* synced - I don't see
> a reason to outlaw that.

But under your suggestion, it could be synced or not, the app would have 
no way to control or know. It is basically random (and implementation 
dependent). This is my main problem, I would like a consistent behavior 
(secondary is that I would like it to be the same CNAME).

>
> The practical issue I can think of would be a source that had its own
> clock, not the system clock, but is otherwise a local source. Having the
> same CNAME would require resynchronizing that source. I don't know if
> any such sources exist in practice, but again, I don't want to outlaw them.
>
>
>>
>> I would prefer that all streams used the same CNAME (if it is signaled
>> or not is another question). If this is a privacy issue I think we
>> should solve that instead of having the browser use, or not use, the
>> same CNAMEs at its own will.
>
> CNAMEs are signaled in RTCP SRs. We don't have the option of leaving
> them out.

Exactly, but what goes in the RTCP need not to be made available to the 
application in all cases - why not hide CNAME?


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


From gonzalo.camarillo@ericsson.com  Tue Feb 12 03:45:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC0821F8D12; Tue, 12 Feb 2013 03:45:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.186
X-Spam-Level: 
X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g22iBF8FRQmC; Tue, 12 Feb 2013 03:45:06 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD821F8D0B; Tue, 12 Feb 2013 03:45:05 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-09-511a2b40cc22
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 68.5A.19728.04B2A115; Tue, 12 Feb 2013 12:45:04 +0100 (CET)
Received: from [131.160.36.86] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Feb 2013 12:45:04 +0100
Message-ID: <511A2B40.2030408@ericsson.com>
Date: Tue, 12 Feb 2013 13:45:04 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org, mmusic 
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBJMWRmVeSWpSXmKPExsUyM+Jvja6DtlSgwfX1lhZTlz9msVj7r53d gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZh69uZy2Ywlcx695z5gbGzdxdjJwcEgImEvPnLGKC sMUkLtxbz9bFyMUhJHCSUeJ6QyeUs5pRYsKRN6wgVbwC2hK3Lp1mA7FZBFQltj6fwg5iswlY SGy5dZ8FxBYViJJ4f7WJGaJeUOLkzCdgcREBXYkDmx6D2cICGhIvvk9ig9gsKbFoWidYnFlA T2LK1RZGCFteYvvbOWBzhID2Ln/WwjKBkX8WkrGzkLTMQtKygJF5FSN7bmJmTnq50SZGYGgd 3PJbdQfjnXMihxilOViUxHnDXS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcVbDFk2vR /mV+aUs2XkubZRj5i8l77+GjJ2/rTzN+LXzPetGcXxFGZyN6Tj37t3GaoM3fZPUt377I7boc IJG+N9Pq+Ioy94T+lRbdbK17HkhL8qeff3bONpPdg3OT/ZPFLXGbVjdHsYmm93Ff/ybmO+/X au9s7h9sAYFNn+7JRv33k/nAdDxJiaU4I9FQi7moOBEAG85bB/sBAAA=
Subject: [rtcweb] Interim meeting and way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 11:45:07 -0000

Folks,

first of all, I hope everybody has already managed to get back home
after the storm. Also, I want to thank Hadriel and Acme for being great
hosts. The information flow, the meeting facilities, the catering, the
pullovers, and everything else was just perfect.

With respect to the technical work that got done in Boston and, more
importantly, that remains to be done, I want to share a few thoughts
with the group.

A fact that is obvious but some of us sometimes forget about is that
RTCWeb, as any other technology, has a window of opportunity. The
usefulness and relevance of any standards we develop in this area will
be extremely high within that window, but will decrease dramatically if
the window closes (e.g., if too many new applications out there are
based on non-standard mechanisms).

While we have everything in the group to meet the relevant market's
deadlines, we should keep them in mind nevertheless. In particular, we
are going to be facing cases where *any* decision is better than *no*
decision, or where the *perfect* will be the enemy of the *good*.

In practical terms, the group should think twice before opening
already-made decisions and open them only for very good reasons. Also,
the group is going to have to make decisions based on *rough* consensus,
as opposed to *wide* consensus or unanimity. This may sound like
motherhood and apple pie but I want to stress these points anyway since
they are important and need to be kept in mind.

For Orlando, I have allocated a *significant* amount of time to RTCWeb
and MMUSIC. Those sessions will allow us to take advantage of the
momentum we currently have after the interim and to make more progress
in all the relevant specifications.

Cheers,

Gonzalo
AD for the RTCWeb and MMUSIC WGs


From randell-ietf@jesup.org  Wed Feb 13 02:38:18 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38921F88A8 for ; Wed, 13 Feb 2013 02:38:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_17=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO8C91DNWGRk for ; Wed, 13 Feb 2013 02:38:17 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 430C821F8869 for ; Wed, 13 Feb 2013 02:38:17 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3681 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U5ZjD-0004cR-PI; Wed, 13 Feb 2013 04:38:16 -0600
Message-ID: <511B6C9A.4090904@jesup.org>
Date: Wed, 13 Feb 2013 05:36:10 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5113CD16.6090806@jesup.org>  <51166A3C.4000604@jesup.org> 
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: [rtcweb] Data Channel Negotiation and reopening of decisions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 10:38:18 -0000

A general note to start this:

We've been here before.  ALL of this has been argued over in great 
detail A YEAR AGO.  I'm sorry if some people were not involved at the 
time, and I'm fine with technical criticism of details of the solutions 
chosen.  However, while we did not have formal consensus calls (I 
think), there certainly was list (and in many cases room) consensus on 
these details, such as bidirectional channels and adding the WebSockets 
'protocol' ID at Atlanta in order to ease heterogeneous application 
interop for things like chat.

Sure, there were many options available to us.  We discussed them in 
great detail and chose a solution that was strongly patterned on 
WebSockets (and to good effect, from what I've seen in practice).  
Options like my original proposals for effectively "raw" unidirectional 
SCTP with SDP negotiation were firmly rejected in favor of bidirectional 
channels with low-overhead creation - and I agreed with the consensus on 
the list.

*Can* we reopen all of this?  Sure!  We *can* reopen ANYTHING (including 
consensus calls).  *Should* we?  No, if we ever want to make progress, 
unless there is some technical problem with the solution.  The details I 
was trying to resolve here and finalize were the outcome of conflicting 
requests to make small changes to channel creation from the Interim 
*last June*.  If people had issues with the general approach, they 
should have been presented then (or earlier on the list).

"Rough consensus and running code"?  We certainly had rough consensus a 
long time ago on most of this (and more IMO).  Running code?  We have a 
largely debugged implementation today in Firefox that's in-use in our 
Social API stuff, in 3D games, and other prototype applications.  We 
worked closely with Michael Tuexen, Randall Stewart and others to polish 
the open user-space SCTP library.

To be clear:  My revised proposal after the discussion in the room and 
on the list is to resolve the startup issues by firing onopen 
immediately and thus allowing 0-RTT opens, removing the need for special 
SDP parameters other than the m=application line and a=sctpmap line 
(which are needed to specify an SCTP/DTLS association, and are part of 
the existing MMUSIC draft).

I think we have a *workable* solution that addresses the end-user 
requirements and expectations, and is flexible enough to support complex 
future uses, and will allow for straightforward heterogeneous 
application interop.  Let's move on and make progress where we *haven't* 
been able to eliminate alternatives yet (or where they keep expanding 
instead of being pruned away).


On to the detailed response:

On 2/11/2013 2:54 PM, Martin Thomson wrote:
> On 9 February 2013 07:24, Randell Jesup  wrote:
>
>> If you were to extend this to work for renegotiations where glare is
>> possible, you'd have to either wait for the renegotiation to finish, or use
>> some even/odd sort of trick which was proposed way back when on the list.
> If you want to resolve glare, then you use the mechanisms you already
> have for glare resolution.  Which, RFC 3264 defers to RFC 3261, which
> uses a fairly heavy-weight mechanism.  Keep in mind that you already
> need this if you are using offer-answer.  Use whatever mechanism you
> already have in place (I like the tie-breaker random number method
> myself).
>
> Or, you could stop worrying about glare and in those cases where glare
> is possible, allow the collision to proceed.
>
> This is an application choice.

Not unless you change the semantics of the JS API I believe.  If you're 
exposing glare to the application in some manner that's complexity for 
them to manage (and in a case that's hard for them to test).  It's easy 
to imagine applications making mistakes or ignoring the possibility here 
if it's exposed.

>> Out-of-band negotiation means either:
>>
>> a) SDP offer/answer (which in many cases will go via a central server,
>> though it can go over an existing datachannel), min 1 RTT (perhaps
>> 1-RTT-through-server) plus SDP processing delay, and requires implementing
>> error handling for cases where the answers and offers don't properly match
>> up,
> This was my thought.  There is no need to reserve a channel for this
> purpose, that's just extra machinery.  Any app that wants the fast
> path for this will make their own.  And, the nice thing about that is
> that they can do this before setting up the session.

Sure, that's the standard "fast-path" solution.  It's still 1 RTT and a 
lot of processing, and blocks other renegotiations while it's in-flight 
(that's fairly minor, but it would block adding more channels during 
that RTT).  Remember RTT isn't always tens of milliseconds.  Sometimes 
you're on a satellite link with 500+ms of RTT, sometimes you're on the 
other side of the globe with 200+ms RTT, sometimes you're fighting 
congestion or bufferbloat (it happens, and some apps like this may be 
pure-data apps) and you have crazy RTT's like 1 second+.  And if you 
have a non-colocated TURN server (say AUS->AUS via TURN in the US) you 
can have a lot of RTT.  TURN will be expensive; do not expect every app 
to have fully geo-dispersed TURN networks!  However, these are largely 
nits - it's still min 1 RTT an heavy string processing.

>> Are there real usecases where the in-band Open and OpenResponse messages
>> actually cause a usecase not to work?
> Well, given that we need message type stuff, we already have to suffer
> some extra muck on top of the SCTP association.  Not many applications
> will survive that.

Ok, good - I couldn't see how that argument made sense.

> No, the real question is: what value do these messages actually add?
> What information do they convey that isn't already negotiated through
> other channels?

It's an alternative to negotiating it through other channels.  In the 
proposal I just made here on the list, it gets you consistency with 
WebSockets and bidirectional symmetric channels (both also doable by 
other methods like pure-SDP), and 0-RTT opens (not possible in SDP while 
retaining the first set of JS-API-level features).

> Starting a stream with a header that declares attributes for a stream
> sounds nice, but it's completely unnecessary in a vast number of
> cases.  For many cases, this is a case of the same piece of software
> talking to itself - it hardly cares.  In many other cases, negotiation
> of properties through SDP is perfectly sufficient.

Sure, many apps will have (when talking to themselves) a fixed set of 
channels set up at the start, which was what I was attempting to 
optimize given the W3 constraint to wait for a truly-acknowledged 
'onopen' ala WebSockets.  My alternative proposed here is to fire onopen 
immediately (since DataChannels are declarative) and allow 0-RTT opens, 
obviating the need the SDP enhancements presented at the meeting.

We already do have people querying if DataChannels could be used for 
things like GFC avoidance for things like proxied browsing, which (if 
it's doable, which I haven't verified but seems plausible if the user 
grants the app special permissions), which would imply a need for 
low-overhead channel creation.

> The only case I see for an in-band protocol is where you wish to
> invent some new protocol on this platform, and I can't really muster
> up that much enthusiasm for that.  It's far too heavily reliant on my
> imagination.  Even in those cases, my knowledge of existing SCTP usage
> patterns suggest that the properties that are sent in
> Open/OpenResponse messages are not that useful to have.  Many
> applications will use the same values for all new streams.

There are lots of applications I envision (such as games) that will want 
a small mix of reliable and unreliable (or partially-reliable) channels, 
and others that want a mix of priorities (which we haven't talked about 
much, but would allow specifying if a data channel should be higher or 
lower priority than media streams, and perhaps more granularity.  
Control information (low BW) may be higher, file transfer may be lower, 
for example.

-- 
Randell Jesup
randell-ietf@jesup.org


From fluffy@cisco.com  Wed Feb 13 06:06:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C9D21F86C4; Wed, 13 Feb 2013 06:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.26
X-Spam-Level: 
X-Spam-Status: No, score=-110.26 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q8iJsBqn8Si; Wed, 13 Feb 2013 06:06:49 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8FADA21F86BC; Wed, 13 Feb 2013 06:06:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7445; q=dns/txt; s=iport; t=1360764407; x=1361974007; h=from:to:subject:date:message-id:references:mime-version; bh=ocjybb0QY4slDZog5GG5rsd897aQHSiXGVVIiJ5Oehs=; b=G/Xcbujz/68XwpMn0afDhwruZmd7NwL2XjaiSbVmy4FgADVaoMd/Xj8o jwwRWLSJPKL1cPTQkI04c5QmgkweIzCMfPecIFTgbb+V2fx9M0fQpPjiY W4aKnyeaUaORnqV4eyctkJamlIcmTwiQ9All+RodXXFJ+cpuxfF/NSdSX U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al8FAAudG1GtJV2c/2dsb2JhbAAqGoYHumAWc4IgAQEEgQkCASokMiUCBAEaiAoMLb4xBJEiYQOmd4MGgic
X-IronPort-AV: E=Sophos;i="4.84,657,1355097600";  d="scan'208,217";a="176412547"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 13 Feb 2013 14:06:47 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1DE6lwo008123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 14:06:47 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 08:06:46 -0600
From: "Cullen Jennings (fluffy)" 
To: "mmusic@ietf.org WG" , "rtcweb@ietf.org" 
Thread-Topic: Recording of Feb 6 interim meeting
Thread-Index: AQHOCfNb73WQHE8ZbUuj1M8OtF7bDg==
Date: Wed, 13 Feb 2013 14:06:46 +0000
Message-ID: 
References: <249625838.2178581360190911147.JavaMail.nobody@rsj6rmd001.webex.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: multipart/alternative; boundary="_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_"
MIME-Version: 1.0
Subject: [rtcweb] Recording of Feb 6 interim meeting
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 14:06:50 -0000

--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Begin forwarded message:

Your recording is now available on the WebEx service site. Click the link b=
elow to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D65855352&r=
Key=3D10997854d4b84af5

WebRTC / RTCWeb / MMusic-20130206 1953-1
Wednesday, February 6, 2013 11:53 am San Francisco Time
2 Hours 52 Minutes


--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <59D8E63AF0978B458DE1C1C1EAA63A36@cisco.com>
Content-Transfer-Encoding: quoted-printable










Begin forwarded message:




Your
 recording is now available on the WebEx service site. Click the link below=
 to play it: 



https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=
=3D65855352&rKey=3D10997854d4b84af5 



WebRTC
 / RTCWeb / MMusic-20130206 1953-1&nb=
sp;

Wednesday,
 February 6, 2013 11:53 am San Francisco Time 

2
 Hours 52 Minutes =











--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_--

From fluffy@cisco.com  Wed Feb 13 06:11:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AF321F8605; Wed, 13 Feb 2013 06:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.28
X-Spam-Level: 
X-Spam-Status: No, score=-110.28 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbcJU3oR658O; Wed, 13 Feb 2013 06:11:13 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 516F621F866D; Wed, 13 Feb 2013 06:11:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7723; q=dns/txt; s=iport; t=1360764670; x=1361974270; h=from:to:subject:date:message-id:references:mime-version; bh=vjHb6dLxNb3hWJ24JAm+CBBS7rDl47wjb1EBeaOmEa8=; b=KCH8aTBC/ayfPcbAL0g0syQZSlPkEENEnEhqKZxbkGxXgNbQl3uoHfJM nfSpBr0D0eRyC4kXNlitprBCv6ejsx5hdv211tvL1+S7Fu5vv4Xxxx52/ JqexSQzyZ9cS3YX+QjBv4zsgGQLtgp1I6HrvNGHZjezRbDHlRBykDuara w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al8FAB2eG1GtJV2c/2dsb2JhbAAqGoYHumAWc4IgAQEEgQkCASokMiUCBAEaiAoMLb4zBJEiYQOmd4MGgic
X-IronPort-AV: E=Sophos;i="4.84,657,1355097600";  d="scan'208,217";a="176605594"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2013 14:11:09 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1DEB9pb013096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 14:11:09 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 08:11:09 -0600
From: "Cullen Jennings (fluffy)" 
To: "mmusic@ietf.org WG" , "rtcweb@ietf.org" 
Thread-Topic: Recording of Feb 7 interim meeting 
Thread-Index: AQHOCfP42GBEEiij4kmMU7C+TANYJQ==
Date: Wed, 13 Feb 2013 14:11:09 +0000
Message-ID: 
References: <854910216.2305321360270351399.JavaMail.nobody@rsj6rmd001.webex.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: multipart/alternative; boundary="_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_"
MIME-Version: 1.0
Subject: [rtcweb] Recording of Feb 7 interim meeting
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 14:11:14 -0000

--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



Your recording is now available on the WebEx service site. Click the link b=
elow to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D65887687&r=
Key=3D8c217cc13c9e0ea7

WebRTC / RTCWeb / MMusic-20130207 1348-1
Thursday, February 7, 2013 5:48 am San Francisco Time
7 Hours


--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <6AD1EC2A7AD84E46A45318AD5F9548D0@cisco.com>
Content-Transfer-Encoding: quoted-printable













Your
 recording is now available on the WebEx service site. Click the link below=
 to play it: 



https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=
=3D65887687&rKey=3D8c217cc13c9e0ea7 



WebRTC
 / RTCWeb / MMusic-20130207 1348-1&nb=
sp;

Thursday,
 February 7, 2013 5:48 am San Francisco Time 

7
 Hours 










--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_--

From ron.even.tlv@gmail.com  Wed Feb 13 06:25:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8047F21F8712; Wed, 13 Feb 2013 06:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.700,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNsBtbClImsO; Wed, 13 Feb 2013 06:25:28 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 878CE21F86FC; Wed, 13 Feb 2013 06:25:27 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id b57so613865eek.4 for ; Wed, 13 Feb 2013 06:25:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=lHTdHM8ZRkYYDXENA/gLhhiAFFqJUkH0zV3iiYLguQY=; b=0S0OVRMPxcMqodquuoRC7HvdhsCsaEQTmpK2Jaa2tMDOcmohMfnauU7mlKchbalpaE +g+uuNvZlhVkuD27ufjCINWxlfS2MawMbU1xx8R4WDnAIMT1E9ZOytgIC7TXDfUVmHdM OWScNlzgsjHVGFEAw/BvrWEvxG2MLpz4miXGpfFejR2Nk8L1B/FwsD1JefyM7AFAd/xo 3VnPB35RR6usqL3LiFFkDhRerhx5VcaSPFtJyTT5p9QQCzdgh3c64Bck4B4uyAYR3Q01 YBbwDzhmyGL45IgGNsh4JTmdQwoVjafm4fOWo0GABlwNigP+mI2g1WlW+ftTTkQCLhkn LSHg==
X-Received: by 10.14.183.67 with SMTP id p43mr75202632eem.10.1360765519485; Wed, 13 Feb 2013 06:25:19 -0800 (PST)
Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id u44sm13525229eel.7.2013.02.13.06.25.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 06:25:18 -0800 (PST)
From: "Roni Even" 
To: "'Gonzalo Camarillo'" , , "'mmusic'" 
References: <511A2B40.2030408@ericsson.com>
In-Reply-To: <511A2B40.2030408@ericsson.com>
Date: Wed, 13 Feb 2013 16:22:09 +0200
Message-ID: <003801ce09f5$84478440$8cd68cc0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDGMsj9CFovUr+bUSEmt3Vs6iJBAJqHhNpQ
Content-Language: en-us
Subject: Re: [rtcweb] Interim meeting and way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 14:25:28 -0000

Hi Gonzalo,
Is there a meeting summary from the interim meeting that list the
already-made decisions from the interim or are you talking about ones from
IETF85?
Thanks
Roni Even

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Gonzalo Camarillo
Sent: 12 February, 2013 1:45 PM
To: rtcweb@ietf.org; mmusic
Subject: [rtcweb] Interim meeting and way forward

Folks,

first of all, I hope everybody has already managed to get back home after
the storm. Also, I want to thank Hadriel and Acme for being great hosts. The
information flow, the meeting facilities, the catering, the pullovers, and
everything else was just perfect.

With respect to the technical work that got done in Boston and, more
importantly, that remains to be done, I want to share a few thoughts with
the group.

A fact that is obvious but some of us sometimes forget about is that RTCWeb,
as any other technology, has a window of opportunity. The usefulness and
relevance of any standards we develop in this area will be extremely high
within that window, but will decrease dramatically if the window closes
(e.g., if too many new applications out there are based on non-standard
mechanisms).

While we have everything in the group to meet the relevant market's
deadlines, we should keep them in mind nevertheless. In particular, we are
going to be facing cases where *any* decision is better than *no* decision,
or where the *perfect* will be the enemy of the *good*.

In practical terms, the group should think twice before opening already-made
decisions and open them only for very good reasons. Also, the group is going
to have to make decisions based on *rough* consensus, as opposed to *wide*
consensus or unanimity. This may sound like motherhood and apple pie but I
want to stress these points anyway since they are important and need to be
kept in mind.

For Orlando, I have allocated a *significant* amount of time to RTCWeb and
MMUSIC. Those sessions will allow us to take advantage of the momentum we
currently have after the interim and to make more progress in all the
relevant specifications.

Cheers,

Gonzalo
AD for the RTCWeb and MMUSIC WGs

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


From gonzalo.camarillo@ericsson.com  Wed Feb 13 07:00:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE121F878F; Wed, 13 Feb 2013 07:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.189
X-Spam-Level: 
X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBAf1cLBntIx; Wed, 13 Feb 2013 07:00:19 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7811A21F874C; Wed, 13 Feb 2013 07:00:18 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-ac-511baa814733
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.43.19728.18AAB115; Wed, 13 Feb 2013 16:00:17 +0100 (CET)
Received: from [131.160.126.60] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Feb 2013 16:00:17 +0100
Message-ID: <511BAA80.6090604@ericsson.com>
Date: Wed, 13 Feb 2013 17:00:16 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Roni Even 
References: <511A2B40.2030408@ericsson.com> <003801ce09f5$84478440$8cd68cc0$@gmail.com>
In-Reply-To: <003801ce09f5$84478440$8cd68cc0$@gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+JvjW7jKulAg56vahZTlz9msfjbzmyx 9l87uwOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CVsenTcqaCdvGK1xcmMDcw7hXqYuTk kBAwkXi8qY8FwhaTuHBvPVsXIxeHkMBJRon9b95BOWsYJU4dOg/kcHDwCmhLXPnkCdLAIqAq cWvOQlYQm03AQmLLrftgg0QFoiTeX21iBrF5BQQlTs58AhYXEVCTeL32MxuIzSygL3Ht6F92 EFtYwFTi88KnTCC2kEC4xKMth8FsTqCZ3/b1M0McJymxaFonC0SvnsSUqy2MELa8xPa3c5gh erUllj9rYZnAKDQLyepZSFpmIWlZwMi8ipE9NzEzJ73caBMjMGQPbvmtuoPxzjmRQ4zSHCxK 4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBy8BgnGwUwTr37IC4ubPWu8Nnbu39K SPPw856+KJukkbi+3CPls13ByhgP/2+/vZrc+pkDDIRCkqpWTFFlOyuZe2fmM9cNc2Ufz3xr Mv2EXuLNhHiPCr4ZG9UtG3x8LkU2+V5R/x5TO3md2rQnjmKqy8KMlqnH8U+W/W/aNmd/fu7G TRb72ZVYijMSDbWYi4oTAa8/sBcnAgAA
Cc: rtcweb@ietf.org, 'mmusic' 
Subject: Re: [rtcweb] Interim meeting and way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:00:24 -0000

Hi Roni,

at this point, I am talking in general and strategically, not about any
decision in particular. Which particular topics would benefit from the
suggestions below and which wouldn't should be kind-of obvious to anyone
who is somewhat involved in the technical work. Also, as usual, the
technical discussions on individual topics will be moderated and
facilitated by the chairs.

Thanks,

Gonzalo

On 13/02/2013 4:22 PM, Roni Even wrote:
> Hi Gonzalo,
> Is there a meeting summary from the interim meeting that list the
> already-made decisions from the interim or are you talking about ones from
> IETF85?
> Thanks
> Roni Even
> 
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Gonzalo Camarillo
> Sent: 12 February, 2013 1:45 PM
> To: rtcweb@ietf.org; mmusic
> Subject: [rtcweb] Interim meeting and way forward
> 
> Folks,
> 
> first of all, I hope everybody has already managed to get back home after
> the storm. Also, I want to thank Hadriel and Acme for being great hosts. The
> information flow, the meeting facilities, the catering, the pullovers, and
> everything else was just perfect.
> 
> With respect to the technical work that got done in Boston and, more
> importantly, that remains to be done, I want to share a few thoughts with
> the group.
> 
> A fact that is obvious but some of us sometimes forget about is that RTCWeb,
> as any other technology, has a window of opportunity. The usefulness and
> relevance of any standards we develop in this area will be extremely high
> within that window, but will decrease dramatically if the window closes
> (e.g., if too many new applications out there are based on non-standard
> mechanisms).
> 
> While we have everything in the group to meet the relevant market's
> deadlines, we should keep them in mind nevertheless. In particular, we are
> going to be facing cases where *any* decision is better than *no* decision,
> or where the *perfect* will be the enemy of the *good*.
> 
> In practical terms, the group should think twice before opening already-made
> decisions and open them only for very good reasons. Also, the group is going
> to have to make decisions based on *rough* consensus, as opposed to *wide*
> consensus or unanimity. This may sound like motherhood and apple pie but I
> want to stress these points anyway since they are important and need to be
> kept in mind.
> 
> For Orlando, I have allocated a *significant* amount of time to RTCWeb and
> MMUSIC. Those sessions will allow us to take advantage of the momentum we
> currently have after the interim and to make more progress in all the
> relevant specifications.
> 
> Cheers,
> 
> Gonzalo
> AD for the RTCWeb and MMUSIC WGs
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


From magnus.westerlund@ericsson.com  Wed Feb 13 07:07:25 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DA921F8717; Wed, 13 Feb 2013 07:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.681
X-Spam-Level: 
X-Spam-Status: No, score=-105.681 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcbLbi-+xuKM; Wed, 13 Feb 2013 07:07:22 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7A21F870E; Wed, 13 Feb 2013 07:07:20 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-7d-511bac27e27c
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 38.12.32353.72CAB115; Wed, 13 Feb 2013 16:07:19 +0100 (CET)
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.279.1; Wed, 13 Feb 2013 16:07:19 +0100
Message-ID: <511BAC25.8020501@ericsson.com>
Date: Wed, 13 Feb 2013 16:07:17 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Charles Eckel (eckelcu)" 
References: <510A4B7C.3000009@ericsson.com> <92B7E61ADAC1BB4F941F943788C088280477C368@xmb-aln-x08.cisco.com>
In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280477C368@xmb-aln-x08.cisco.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvja76GulAg/f3JSw2zfrCZjF1+WMW i7X/2tkdmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsErozDz7+xFhySrvjQO5m5gXGyWBcj J4eEgInEnceLWSFsMYkL99azdTFycQgJnGSUuHCuD8pZziix9MNBRpAqXgFtiZdz25lBbBYB VYlXyzaCxdkELCRu/mhkA7FFBYIlNhxcxQRRLyhxcuYTFhBbRMBQYtGkdWA2s4C/RNe1qWC2 sICvxJUpG8HqhQRyJK5+2wk2kxMo/m/3P6CZHEDXiUusecMB0aonMeVqCyOELS/RvHU2M0Sr tkRDUwfrBEahWUg2z0LSMgtJywJG5lWM7LmJmTnp5eabGIFBe3DLb4MdjJvuix1ilOZgURLn DXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMbJDskWDbb6T+szbVeIhM1cs1qs4eMJy 24NlVfyyzA6FE6dedP4WFSnmu+xV2c3DeyyELVKY9+qasU1IbA2YMtlySobk00maK8+FnI52 PJzspq79dM8ZQXbuBJXX3IK6b1bI7ImfWT6T+8WZiA2/jJ5fvjxnSdI/z53HzDdM/fj00jdl Dekdz5RYijMSDbWYi4oTAT6j33MoAgAA
Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" 
Subject: Re: [rtcweb] Draft on Multimedia concepts and relations for Intermim
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:07:25 -0000

Hi Charles,

Lets respond to your questions.

On 2013-02-05 03:28, Charles Eckel (eckelcu) wrote:
> Hi Magnus and Bo,
> 
> Thanks for putting this together, and more importantly, for attaching
> a copy in the e-mail so I was able to access it on the plane without
> internet. I agree with most of the reasoning in the various sections;
> however, there are a couple related concepts for which I'd like more
> clarification.
> 
> 1) MediaStream Is a MediaStream restricted to a single source? I did
> not think it was, but the description on page 8 seems to imply this
> restriction. For example, could I have a single MediaStream with the
> following 4 MediaStreamTracks, where source 1 and source 2 are two
> video cameras from the same endpoint, or a mic and an camera from the
> same endpoint:
> 
> 
> Source 1 - encoding 1 
> Source 1 - encoding 2 
> Source 2 - encoding 1 
> Source 2 - encoding 2

No, MediaStream is definitely not restricted to a single Media source.
In fact a common MediaStream will contain one MediaStreamTrack with an
audio source, and another MediaStreamTrack with Video. Thus two
different media sources.

Your example above gets us into I think land where discussion is ongoing
and agreement needs to be established. From my perspective there need to
be a way of dealing with control of encoding and and a plan for
different encodings of the same media source. If that is achieved by
having multiple MediaStreamTracks of the same media source, having
multiple MediaStreams with the same set of MediaStreamTracks but
different encoding settings, or explicit encoding settings within a
MediaStram and MediaStreamTrack or having them tied to the
PeerConnection is a choice that needs to happen. They have different
impact on differnt parts, but we really need to make a choice here.

> 
> 2) PeerConnection Later, on page 18, a related restriction of a
> single encoding per PC is suggested. In the case of a layered
> encoding, this seems to imply each layer being in its own PC. Is that
> the recommendation being suggested?

For layered encoding this proposal is far from optimal. It works for
simulcast where having different RTP streams each carrying a different
encoding is fine. Thus we proposed it as a solution which appeared to
require minimal impact with some simple restrictions regarding usage of
CNAME, i.e. same CNAME for both SSRC, even if they are in different RTP
sessions due to the different PeerConnections. I assume for layering
that one like to be able to send the layers in a single RTP stream.

When it comes to layering and simulcast I think the first step is
actually to agree on requirements level. Are we supporting it from
start, are we at least having it on the future road-map to avoid
solutions which makes it difficult to add in the future?

I have gotten the impression that a number of different people have
interest in it. Maybe not to implement it immediately, but at least have
a plan for how it should be included.

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 stefan.lk.hakansson@ericsson.com  Wed Feb 13 07:13:08 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E147521F86C5 for ; Wed, 13 Feb 2013 07:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.323
X-Spam-Level: 
X-Spam-Status: No, score=-5.323 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeTkwZvK2aVQ for ; Wed, 13 Feb 2013 07:13:05 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55E21F86C2 for ; Wed, 13 Feb 2013 07:13:04 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-65-511bad7f3065
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B3.15.19728.F7DAB115; Wed, 13 Feb 2013 16:13:04 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Feb 2013 16:13:03 +0100
Message-ID: <511BAD7F.1000709@ericsson.com>
Date: Wed, 13 Feb 2013 16:13:03 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5113CD16.6090806@jesup.org>  <51166A3C.4000604@jesup.org>  <511B6C9A.4090904@jesup.org>
In-Reply-To: <511B6C9A.4090904@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+JvjW7DWulAg+ab3BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY1Hff6aCey4VF681MjcwzjTvYuTkkBAwkVjR/44JwhaTuHBv PVsXIxeHkMBJRomNix6wQjhrGSUWTLvLClLFK6AtcfLuMiCbg4NFQFVi665YkDCbQKDE9f+/ wAaJCkRJvL/axAxRLihxcuYTFhBbREBYYuurXrAaYQFPiTk3j0It28gk8W3lD3aQBKeApsT5 n2cZQWxmAVuJC3Ous0DY8hLb384BGyokoCvx7vU91gmMArOQ7JiFpGUWkpYFjMyrGNlzEzNz 0suNNjECA+3glt+qOxjvnBM5xCjNwaIkzhvueiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6PJSYZ18k8cxG9k7i3fku2Wos/16bGT0H7fDUsLOlTEXz4+/XFlzI/oLzs1sp/4RVb0hH87 onT/z4knQQdvNbTw8HLul5po0bvggfOippk8Ova+3zjUmkWZN6/rtOPeX3BP1mX7VLvqOdbF OxRnt0/iu735ts9zLq+geYYPm5daWpo+uWWSvV2JpTgj0VCLuag4EQBKzQEZAgIAAA==
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 15:13:08 -0000

Without going into details, I'd like to support Randell's main message: 
we discussed this at length a long time ago, arrived at a solution that 
seem to support the use-cases, and even have implementations.

I haven't been convinced we should reopen all this again.

Stefan

On 2013-02-13 11:36, Randell Jesup wrote:
> A general note to start this:
>
> We've been here before.  ALL of this has been argued over in great
> detail A YEAR AGO.  I'm sorry if some people were not involved at the
> time, and I'm fine with technical criticism of details of the solutions
> chosen.  However, while we did not have formal consensus calls (I
> think), there certainly was list (and in many cases room) consensus on
> these details, such as bidirectional channels and adding the WebSockets
> 'protocol' ID at Atlanta in order to ease heterogeneous application
> interop for things like chat.
>
> Sure, there were many options available to us.  We discussed them in
> great detail and chose a solution that was strongly patterned on
> WebSockets (and to good effect, from what I've seen in practice).
> Options like my original proposals for effectively "raw" unidirectional
> SCTP with SDP negotiation were firmly rejected in favor of bidirectional
> channels with low-overhead creation - and I agreed with the consensus on
> the list.
>
> *Can* we reopen all of this?  Sure!  We *can* reopen ANYTHING (including
> consensus calls).  *Should* we?  No, if we ever want to make progress,
> unless there is some technical problem with the solution.  The details I
> was trying to resolve here and finalize were the outcome of conflicting
> requests to make small changes to channel creation from the Interim
> *last June*.  If people had issues with the general approach, they
> should have been presented then (or earlier on the list).
>
> "Rough consensus and running code"?  We certainly had rough consensus a
> long time ago on most of this (and more IMO).  Running code?  We have a
> largely debugged implementation today in Firefox that's in-use in our
> Social API stuff, in 3D games, and other prototype applications.  We
> worked closely with Michael Tuexen, Randall Stewart and others to polish
> the open user-space SCTP library.
>
> To be clear:  My revised proposal after the discussion in the room and
> on the list is to resolve the startup issues by firing onopen
> immediately and thus allowing 0-RTT opens, removing the need for special
> SDP parameters other than the m=application line and a=sctpmap line
> (which are needed to specify an SCTP/DTLS association, and are part of
> the existing MMUSIC draft).
>
> I think we have a *workable* solution that addresses the end-user
> requirements and expectations, and is flexible enough to support complex
> future uses, and will allow for straightforward heterogeneous
> application interop.  Let's move on and make progress where we *haven't*
> been able to eliminate alternatives yet (or where they keep expanding
> instead of being pruned away).
>
>
> On to the detailed response:
>
> On 2/11/2013 2:54 PM, Martin Thomson wrote:
>> On 9 February 2013 07:24, Randell Jesup  wrote:
>>
>>> If you were to extend this to work for renegotiations where glare is
>>> possible, you'd have to either wait for the renegotiation to finish,
>>> or use
>>> some even/odd sort of trick which was proposed way back when on the
>>> list.
>> If you want to resolve glare, then you use the mechanisms you already
>> have for glare resolution.  Which, RFC 3264 defers to RFC 3261, which
>> uses a fairly heavy-weight mechanism.  Keep in mind that you already
>> need this if you are using offer-answer.  Use whatever mechanism you
>> already have in place (I like the tie-breaker random number method
>> myself).
>>
>> Or, you could stop worrying about glare and in those cases where glare
>> is possible, allow the collision to proceed.
>>
>> This is an application choice.
>
> Not unless you change the semantics of the JS API I believe.  If you're
> exposing glare to the application in some manner that's complexity for
> them to manage (and in a case that's hard for them to test).  It's easy
> to imagine applications making mistakes or ignoring the possibility here
> if it's exposed.
>
>>> Out-of-band negotiation means either:
>>>
>>> a) SDP offer/answer (which in many cases will go via a central server,
>>> though it can go over an existing datachannel), min 1 RTT (perhaps
>>> 1-RTT-through-server) plus SDP processing delay, and requires
>>> implementing
>>> error handling for cases where the answers and offers don't properly
>>> match
>>> up,
>> This was my thought.  There is no need to reserve a channel for this
>> purpose, that's just extra machinery.  Any app that wants the fast
>> path for this will make their own.  And, the nice thing about that is
>> that they can do this before setting up the session.
>
> Sure, that's the standard "fast-path" solution.  It's still 1 RTT and a
> lot of processing, and blocks other renegotiations while it's in-flight
> (that's fairly minor, but it would block adding more channels during
> that RTT).  Remember RTT isn't always tens of milliseconds.  Sometimes
> you're on a satellite link with 500+ms of RTT, sometimes you're on the
> other side of the globe with 200+ms RTT, sometimes you're fighting
> congestion or bufferbloat (it happens, and some apps like this may be
> pure-data apps) and you have crazy RTT's like 1 second+.  And if you
> have a non-colocated TURN server (say AUS->AUS via TURN in the US) you
> can have a lot of RTT.  TURN will be expensive; do not expect every app
> to have fully geo-dispersed TURN networks!  However, these are largely
> nits - it's still min 1 RTT an heavy string processing.
>
>>> Are there real usecases where the in-band Open and OpenResponse messages
>>> actually cause a usecase not to work?
>> Well, given that we need message type stuff, we already have to suffer
>> some extra muck on top of the SCTP association.  Not many applications
>> will survive that.
>
> Ok, good - I couldn't see how that argument made sense.
>
>> No, the real question is: what value do these messages actually add?
>> What information do they convey that isn't already negotiated through
>> other channels?
>
> It's an alternative to negotiating it through other channels.  In the
> proposal I just made here on the list, it gets you consistency with
> WebSockets and bidirectional symmetric channels (both also doable by
> other methods like pure-SDP), and 0-RTT opens (not possible in SDP while
> retaining the first set of JS-API-level features).
>
>> Starting a stream with a header that declares attributes for a stream
>> sounds nice, but it's completely unnecessary in a vast number of
>> cases.  For many cases, this is a case of the same piece of software
>> talking to itself - it hardly cares.  In many other cases, negotiation
>> of properties through SDP is perfectly sufficient.
>
> Sure, many apps will have (when talking to themselves) a fixed set of
> channels set up at the start, which was what I was attempting to
> optimize given the W3 constraint to wait for a truly-acknowledged
> 'onopen' ala WebSockets.  My alternative proposed here is to fire onopen
> immediately (since DataChannels are declarative) and allow 0-RTT opens,
> obviating the need the SDP enhancements presented at the meeting.
>
> We already do have people querying if DataChannels could be used for
> things like GFC avoidance for things like proxied browsing, which (if
> it's doable, which I haven't verified but seems plausible if the user
> grants the app special permissions), which would imply a need for
> low-overhead channel creation.
>
>> The only case I see for an in-band protocol is where you wish to
>> invent some new protocol on this platform, and I can't really muster
>> up that much enthusiasm for that.  It's far too heavily reliant on my
>> imagination.  Even in those cases, my knowledge of existing SCTP usage
>> patterns suggest that the properties that are sent in
>> Open/OpenResponse messages are not that useful to have.  Many
>> applications will use the same values for all new streams.
>
> There are lots of applications I envision (such as games) that will want
> a small mix of reliable and unreliable (or partially-reliable) channels,
> and others that want a mix of priorities (which we haven't talked about
> much, but would allow specifying if a data channel should be higher or
> lower priority than media streams, and perhaps more granularity. Control
> information (low BW) may be higher, file transfer may be lower, for
> example.
>


From christer.holmberg@ericsson.com  Wed Feb 13 11:48:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2566A21F852C; Wed, 13 Feb 2013 11:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.144
X-Spam-Level: 
X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.105,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5xTray9j16D; Wed, 13 Feb 2013 11:48:27 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8621F8530; Wed, 13 Feb 2013 11:48:25 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-81-511bee0810c6
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A2.FA.32353.80EEB115; Wed, 13 Feb 2013 20:48:25 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 20:48:24 +0100
From: Christer Holmberg 
To: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: BUNDLE: RTP only?
Thread-Index: Ac4KIxU5eB8ChmgfTeKF683MxdSffg==
Date: Wed, 13 Feb 2013 19:48:23 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvjS7nO+lAg63nGC2mLn/MYrH2Xzu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyTt9/xlgwl7WiuX0OSwNjH0sXIyeHhICJxMJrF5kh bDGJC/fWs3UxcnEICRxilGjddoUVJCEksIRR4vOz9C5GDg42AQuJ7n/aIGERAR+Jr1OWgfUK C0hJbLo+jxEiLi9xfd18JghbT2L14+9gNouAqkTLjIlsIDavgLfE0V8HwHoZgfZ+P7UGrIZZ QFzi1hOIXgkBAYkle85D3SYq8fLxP1aQEyQEFCWW98tBlOtILNj9iQ3C1pZYtvA1M8R4QYmT M5+wTGAUnoVk6iwkLbOQtMxC0rKAkWUVI3tuYmZOern5JkZgMB/c8ttgB+Om+2KHGKU5WJTE ecNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNxY/jL3ziQDxbo3f2pM9/Nuqk1U9DSs XMR8ff2sL7olmkqpCbLbNGdaHs7ccCkrUDPZ/rXR/XSpHbwb0vMesL8oEuAr6eKR6mTr3lJg kW3zKS7s2jbvT88U/Z8t/P2vwPWAXlTSSulLGw0PPv7kvGNnub6GD3P3/kXx1x//tpeQl/e0 KtYIVWIpzkg01GIuKk4EANavOhQ0AgAA
Subject: [rtcweb] BUNDLE: RTP only?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 19:48:28 -0000

(Sorry for sending this to both RTCWEB and MMUSIC, but it is related to bot=
h the need of RTCWEB, and the solution produced by MMUSIC)

Hi,

At the interim, during my BUNDLE presentation, I indicated that we need to =
make a decision whether the solution (whatever it will be...) shall support=
 bundling of non-RTP media. Not saying it can't be changed, but as currentl=
y documented all alternatives only support bundling of RTP media.

There might have been some comments from the mic, but as far as I know ther=
e was no decision (if there was, please point me to it).

So, my question is: do we keep the scope to RTP media?

Regards,

Christer=

From fluffy@cisco.com  Wed Feb 13 12:37:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3910921E8064; Wed, 13 Feb 2013 12:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.298
X-Spam-Level: 
X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 weXfTUFS6MpA; Wed, 13 Feb 2013 12:37:43 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4DC21E8055; Wed, 13 Feb 2013 12:37:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1065; q=dns/txt; s=iport; t=1360787863; x=1361997463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yDQyfEh9wl2MUgutnT7/ceetg9OC+8Mku4WZez/JGd0=; b=MNsEIJTavk1FfbIR7STJ3uaDerRaEyq0cGjE5mwAK6FeLwy3UVshwpwU ypCXbiUEpFgSZDLQQ0T/4BkoDbcvzBW2xfCFkVWP3wyLhbL6ScVg8I2CL 6S3mxn9NgiDgp1YrSngi7Ygdbh+Myb/Dw629SVhCxlURW+a4r/qjr/WX8 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAG/4G1GtJXG8/2dsb2JhbABFwG4Wc4IgAQEEAQEBNzQLEAIBCCIUECcLJQIEDgUIE4d3DL9EBJEjYQOmd4MGgic
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176830057"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 13 Feb 2013 20:37:42 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1DKbg6V010889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 20:37:42 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 14:37:42 -0600
From: "Cullen Jennings (fluffy)" 
To: Christer Holmberg 
Thread-Topic: [MMUSIC] BUNDLE: RTP only?
Thread-Index: AQHOCin4yriVbi3BTkiuqlV2yqiiBw==
Date: Wed, 13 Feb 2013 20:37:42 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [rtcweb] [MMUSIC] BUNDLE: RTP only?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:37:44 -0000

I think EKR expressed that he felt it was important for data channel to be =
included in the multiplexing.=20


On Feb 13, 2013, at 12:48 PM, Christer Holmberg  wrote:

>=20
> (Sorry for sending this to both RTCWEB and MMUSIC, but it is related to b=
oth the need of RTCWEB, and the solution produced by MMUSIC)
>=20
> Hi,
>=20
> At the interim, during my BUNDLE presentation, I indicated that we need t=
o make a decision whether the solution (whatever it will be...) shall suppo=
rt bundling of non-RTP media. Not saying it can't be changed, but as curren=
tly documented all alternatives only support bundling of RTP media.
>=20
> There might have been some comments from the mic, but as far as I know th=
ere was no decision (if there was, please point me to it).
>=20
> So, my question is: do we keep the scope to RTP media?
>=20
> Regards,
>=20
> Christer
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From randell-ietf@jesup.org  Wed Feb 13 12:44:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A1621F85F0; Wed, 13 Feb 2013 12:44:39 -0800 (PST)
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]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEgGniJjaNYK; Wed, 13 Feb 2013 12:44:38 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9E30521F85C0; Wed, 13 Feb 2013 12:44:38 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:4463 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U5jC2-0000XQ-0u; Wed, 13 Feb 2013 14:44:38 -0600
Message-ID: <511BFAB7.4060303@jesup.org>
Date: Wed, 13 Feb 2013 15:42:31 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org, mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> 
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [rtcweb] [MMUSIC] BUNDLE: RTP only?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 20:44:39 -0000

On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote:
> I think EKR expressed that he felt it was important for data channel to be included in the multiplexing.

And I agree(d), strongly.  We want 1 port to minimize NAT issues and 
startup times.

>
> At the interim, during my BUNDLE presentation, I indicated that we need to make a decision whether the solution (whatever it will be...) shall support bundling of non-RTP media. Not saying it can't be changed, but as currently documented all alternatives only support bundling of RTP media.
>
> There might have been some comments from the mic, but as far as I know there was no decision (if there was, please point me to it).
>
> So, my question is: do we keep the scope to RTP media?
>

-- 
Randell Jesup
randell-ietf@jesup.org


From ekr@rtfm.com  Wed Feb 13 13:49:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ED421E808F for ; Wed, 13 Feb 2013 13:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.143
X-Spam-Level: 
X-Spam-Status: No, score=-102.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_LOW=-1, 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 OJfbwM6JYaMD for ; Wed, 13 Feb 2013 13:49:11 -0800 (PST)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id C883921E803D for ; Wed, 13 Feb 2013 13:49:10 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id cr7so2372036qab.1 for ; Wed, 13 Feb 2013 13:49:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=bZNR1yLLbNONO+3G9vNQGv8qHfCRt/OsmO+SO/F+ti4=; b=EAPS7yoUACgoMeWY8HWMf0bfLgBRLVUVdZNrVU8mab45W9DqGZU2h0QTSo1YOpRoEJ OyjZ+Zvvd8xlG8cmWws/qTU5jQ14A5uyZGj4YUXHu4Re8+fVuZRK3wnrxiSwokyFZwjM oqfwfmnLitu7nKumV9wBHekMUjxMtGxZpDPGRA4ck61OFBvNmuyHv5UdKaPHeYCMRFYu Hr51bc07Pfrv8K/VnjWQ8Y1/GxgWTblyw/6hQg2T8Kmy5/nHpDn1IwztAvxT5oKfsbkG QSOPDNYSi/IpBgxmHR7FAZuOHBVVOgRgHQx4mN3x0xEO6Egt+3XQlgV03TZaEMLuE6NZ rFkg==
X-Received: by 10.224.59.134 with SMTP id l6mr9084630qah.93.1360792150314; Wed, 13 Feb 2013 13:49:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.130.198 with HTTP; Wed, 13 Feb 2013 13:48:30 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <511BFAB7.4060303@jesup.org>
References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>  <511BFAB7.4060303@jesup.org>
From: Eric Rescorla 
Date: Wed, 13 Feb 2013 13:48:30 -0800
Message-ID: 
To: Randell Jesup 
Content-Type: multipart/alternative; boundary=20cf3068447dbb90b404d5a21c41
X-Gm-Message-State: ALoCoQkGgWVVF2/POXWoGhV+oczhJUWrfP4sk7JIc06dOfWBtpQAwBrqfZFYaaeK2YpSbkqLMsad
Cc: rtcweb@ietf.org, mmusic@ietf.org
Subject: Re: [rtcweb] [MMUSIC] BUNDLE: RTP only?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 21:49:11 -0000

--20cf3068447dbb90b404d5a21c41
Content-Type: text/plain; charset=ISO-8859-1

I would phrase this somewhat less strongly: less ports is better than more
ports,
so all things being equal, a multiplexing mechanism that keeps you down to
one port is better than not. That said, if we decide that plan A is dead and
we are going to plan B, I can live with having data on a separate port.

-Ekr

On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup wrote:

> On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote:
>
>> I think EKR expressed that he felt it was important for data channel to
>> be included in the multiplexing.
>>
>
> And I agree(d), strongly.  We want 1 port to minimize NAT issues and
> startup times.
>
>
>
>> At the interim, during my BUNDLE presentation, I indicated that we need
>> to make a decision whether the solution (whatever it will be...) shall
>> support bundling of non-RTP media. Not saying it can't be changed, but as
>> currently documented all alternatives only support bundling of RTP media.
>>
>> There might have been some comments from the mic, but as far as I know
>> there was no decision (if there was, please point me to it).
>>
>> So, my question is: do we keep the scope to RTP media?
>>
>>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb
>

--20cf3068447dbb90b404d5a21c41
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would phrase this somewhat less strongly: less ports is better than more =
ports,
so all things being equal, a multiplexing mechanism that keeps y=
ou down to
one port is better than not. That said, if we decide t=
hat plan A is dead and




we are going to plan B, I can live with having data on a separate port=
.

-Ekr

On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup &=
lt;randell-ietf=
@jesup.org> wrote:




On 2/13/2013 3:37 PM, Cullen Jennings (=
fluffy) wrote:



I think EKR expressed that he felt it was important for data channel to be =
included in the multiplexing.





And I agree(d), strongly. =A0We want 1 port to minimize NAT issues and star=
tup times.








At the interim, during my BUNDLE presentation, I indicated that we need to =
make a decision whether the solution (whatever it will be...) shall support=
 bundling of non-RTP media. Not saying it can't be changed, but as curr=
ently documented all alternatives only support bundling of RTP media.






There might have been some comments from the mic, but as far as I know ther=
e was no decision (if there was, please point me to it).



So, my question is: do we keep the scope to RTP media?







-- 

Randell Jesup

randell-ietf@je=
sup.org



_______________________________________________

rtcweb mailing list

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





--20cf3068447dbb90b404d5a21c41--

From martin.thomson@gmail.com  Wed Feb 13 14:03:52 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D205421F87A6 for ; Wed, 13 Feb 2013 14:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Level: 
X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0AlAJBZY32k for ; Wed, 13 Feb 2013 14:03:52 -0800 (PST)
Received: from mail-we0-x235.google.com (we-in-x0235.1e100.net [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9240121F8790 for ; Wed, 13 Feb 2013 14:03:51 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id t44so1430322wey.40 for ; Wed, 13 Feb 2013 14:03:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pGaqVwF+Dh4Hkw9/epCikIhTFiW5uFdNE9ugPjM39RA=; b=tnykIaDzkUKk5pvC51BVRqtXl/EHawXgTPXGEB9zcowR0Oftwpl519GiQQlnYAkW4c UnWerUymk5qsEQAQrw8t7+RtdmRGpymdLPYGlzirpeO+SxjRcHDs+FhD/zbTiJmgvVPn k5BgL0i52BUJFFWXPBzx7L1jOJO0Y0Ujh+YcvzWYVXJS1X1LlzKsNN6I6HpkLhf7LHJc hrCS15OFS4drPpvbBxoEc/nFy5Ts0uRygxzpyRa7BQdEH//dlDyI07L2ewWSk/njGw+B bCUqkHuKkbHiOksXnCNA8Rm/7lCT0u+grezU6ryQmDPUeYAcBpIHuKtkYuI6/4ooNZQZ dOCQ==
MIME-Version: 1.0
X-Received: by 10.194.91.211 with SMTP id cg19mr2100966wjb.43.1360793030532; Wed, 13 Feb 2013 14:03:50 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Wed, 13 Feb 2013 14:03:50 -0800 (PST)
In-Reply-To: <511B6C9A.4090904@jesup.org>
References:  <5113CD16.6090806@jesup.org>  <51166A3C.4000604@jesup.org>  <511B6C9A.4090904@jesup.org>
Date: Wed, 13 Feb 2013 14:03:50 -0800
Message-ID: 
From: Martin Thomson 
To: Randell Jesup 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 22:03:52 -0000

None of what I suggest would change the API.  At most, it would have
removed the in-band handshake messages in exchange for loosening some
of the guarantees.  And I've been trained to value the deletion of
code highly.  That seemed like a good trade.

And timing?  It wasn't until you presented at the interim that I
realized just how little value the in-band handshake was adding.

In terms of the specifics of your fast open proposal, what do you do
with the message(s) that arrive on channels that you reject?  How does
this surface in the API?

I'll do a blow-by-blow on your points below, if you want to continue
the conversation.  If we're exchanging rhetoric bombs, I see little
point.

On 13 February 2013 02:36, Randell Jesup  wrote:
> A general note to start this:
>
> We've been here before.  ALL of this has been argued over in great detail A
> YEAR AGO.  I'm sorry if some people were not involved at the time, and I'm
> fine with technical criticism of details of the solutions chosen.  However,
> while we did not have formal consensus calls (I think), there certainly was
> list (and in many cases room) consensus on these details, such as
> bidirectional channels and adding the WebSockets 'protocol' ID at Atlanta in
> order to ease heterogeneous application interop for things like chat.
>
> Sure, there were many options available to us.  We discussed them in great
> detail and chose a solution that was strongly patterned on WebSockets (and
> to good effect, from what I've seen in practice).  Options like my original
> proposals for effectively "raw" unidirectional SCTP with SDP negotiation
> were firmly rejected in favor of bidirectional channels with low-overhead
> creation - and I agreed with the consensus on the list.
>
> *Can* we reopen all of this?  Sure!  We *can* reopen ANYTHING (including
> consensus calls).  *Should* we?  No, if we ever want to make progress,
> unless there is some technical problem with the solution.  The details I was
> trying to resolve here and finalize were the outcome of conflicting requests
> to make small changes to channel creation from the Interim *last June*.  If
> people had issues with the general approach, they should have been presented
> then (or earlier on the list).
>
> "Rough consensus and running code"?  We certainly had rough consensus a long
> time ago on most of this (and more IMO).  Running code?  We have a largely
> debugged implementation today in Firefox that's in-use in our Social API
> stuff, in 3D games, and other prototype applications.  We worked closely
> with Michael Tuexen, Randall Stewart and others to polish the open
> user-space SCTP library.
>
> To be clear:  My revised proposal after the discussion in the room and on
> the list is to resolve the startup issues by firing onopen immediately and
> thus allowing 0-RTT opens, removing the need for special SDP parameters
> other than the m=application line and a=sctpmap line (which are needed to
> specify an SCTP/DTLS association, and are part of the existing MMUSIC
> draft).
>
> I think we have a *workable* solution that addresses the end-user
> requirements and expectations, and is flexible enough to support complex
> future uses, and will allow for straightforward heterogeneous application
> interop.  Let's move on and make progress where we *haven't* been able to
> eliminate alternatives yet (or where they keep expanding instead of being
> pruned away).
>
>
> On to the detailed response:
>
> On 2/11/2013 2:54 PM, Martin Thomson wrote:
>>
>> On 9 February 2013 07:24, Randell Jesup  wrote:
>>
>>> If you were to extend this to work for renegotiations where glare is
>>> possible, you'd have to either wait for the renegotiation to finish, or
>>> use
>>> some even/odd sort of trick which was proposed way back when on the list.
>>
>> If you want to resolve glare, then you use the mechanisms you already
>> have for glare resolution.  Which, RFC 3264 defers to RFC 3261, which
>> uses a fairly heavy-weight mechanism.  Keep in mind that you already
>> need this if you are using offer-answer.  Use whatever mechanism you
>> already have in place (I like the tie-breaker random number method
>> myself).
>>
>> Or, you could stop worrying about glare and in those cases where glare
>> is possible, allow the collision to proceed.
>>
>> This is an application choice.
>
>
> Not unless you change the semantics of the JS API I believe.  If you're
> exposing glare to the application in some manner that's complexity for them
> to manage (and in a case that's hard for them to test).  It's easy to
> imagine applications making mistakes or ignoring the possibility here if
> it's exposed.
>
>>> Out-of-band negotiation means either:
>>>
>>> a) SDP offer/answer (which in many cases will go via a central server,
>>> though it can go over an existing datachannel), min 1 RTT (perhaps
>>> 1-RTT-through-server) plus SDP processing delay, and requires
>>> implementing
>>> error handling for cases where the answers and offers don't properly
>>> match
>>> up,
>>
>> This was my thought.  There is no need to reserve a channel for this
>> purpose, that's just extra machinery.  Any app that wants the fast
>> path for this will make their own.  And, the nice thing about that is
>> that they can do this before setting up the session.
>
>
> Sure, that's the standard "fast-path" solution.  It's still 1 RTT and a lot
> of processing, and blocks other renegotiations while it's in-flight (that's
> fairly minor, but it would block adding more channels during that RTT).
> Remember RTT isn't always tens of milliseconds.  Sometimes you're on a
> satellite link with 500+ms of RTT, sometimes you're on the other side of the
> globe with 200+ms RTT, sometimes you're fighting congestion or bufferbloat
> (it happens, and some apps like this may be pure-data apps) and you have
> crazy RTT's like 1 second+.  And if you have a non-colocated TURN server
> (say AUS->AUS via TURN in the US) you can have a lot of RTT.  TURN will be
> expensive; do not expect every app to have fully geo-dispersed TURN
> networks!  However, these are largely nits - it's still min 1 RTT an heavy
> string processing.
>
>>> Are there real usecases where the in-band Open and OpenResponse messages
>>> actually cause a usecase not to work?
>>
>> Well, given that we need message type stuff, we already have to suffer
>> some extra muck on top of the SCTP association.  Not many applications
>> will survive that.
>
>
> Ok, good - I couldn't see how that argument made sense.
>
>> No, the real question is: what value do these messages actually add?
>> What information do they convey that isn't already negotiated through
>> other channels?
>
>
> It's an alternative to negotiating it through other channels.  In the
> proposal I just made here on the list, it gets you consistency with
> WebSockets and bidirectional symmetric channels (both also doable by other
> methods like pure-SDP), and 0-RTT opens (not possible in SDP while retaining
> the first set of JS-API-level features).
>
>> Starting a stream with a header that declares attributes for a stream
>> sounds nice, but it's completely unnecessary in a vast number of
>> cases.  For many cases, this is a case of the same piece of software
>> talking to itself - it hardly cares.  In many other cases, negotiation
>> of properties through SDP is perfectly sufficient.
>
>
> Sure, many apps will have (when talking to themselves) a fixed set of
> channels set up at the start, which was what I was attempting to optimize
> given the W3 constraint to wait for a truly-acknowledged 'onopen' ala
> WebSockets.  My alternative proposed here is to fire onopen immediately
> (since DataChannels are declarative) and allow 0-RTT opens, obviating the
> need the SDP enhancements presented at the meeting.
>
> We already do have people querying if DataChannels could be used for things
> like GFC avoidance for things like proxied browsing, which (if it's doable,
> which I haven't verified but seems plausible if the user grants the app
> special permissions), which would imply a need for low-overhead channel
> creation.
>
>> The only case I see for an in-band protocol is where you wish to
>> invent some new protocol on this platform, and I can't really muster
>> up that much enthusiasm for that.  It's far too heavily reliant on my
>> imagination.  Even in those cases, my knowledge of existing SCTP usage
>> patterns suggest that the properties that are sent in
>> Open/OpenResponse messages are not that useful to have.  Many
>> applications will use the same values for all new streams.
>
>
> There are lots of applications I envision (such as games) that will want a
> small mix of reliable and unreliable (or partially-reliable) channels, and
> others that want a mix of priorities (which we haven't talked about much,
> but would allow specifying if a data channel should be higher or lower
> priority than media streams, and perhaps more granularity.  Control
> information (low BW) may be higher, file transfer may be lower, for example.
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From bernard_aboba@hotmail.com  Wed Feb 13 14:24:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5958711E80A3; Wed, 13 Feb 2013 14:24:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.921
X-Spam-Level: 
X-Spam-Status: No, score=-100.921 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 MLEjcGxFGWIU; Wed, 13 Feb 2013 14:24:02 -0800 (PST)
Received: from blu0-omc4-s20.blu0.hotmail.com (blu0-omc4-s20.blu0.hotmail.com [65.55.111.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9A46311E809C; Wed, 13 Feb 2013 14:24:02 -0800 (PST)
Received: from BLU402-EAS53 ([65.55.111.137]) by blu0-omc4-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Feb 2013 14:24:02 -0800
X-EIP: [i2ME+56uDtkFcVuSHdrAPNS+6fBXn6qm]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/related; boundary="_d31fe700-cd39-4a01-bdb8-08db532a2a1c_"
References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>  <511BFAB7.4060303@jesup.org> 
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: 
Date: Wed, 13 Feb 2013 14:24:00 -0800
To: Eric Rescorla 
X-OriginalArrivalTime: 13 Feb 2013 22:24:02.0139 (UTC) FILETIME=[D36522B0:01CE0A38]
Cc: Randell Jesup , "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [rtcweb] [MMUSIC] BUNDLE: RTP only?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 22:24:03 -0000

--_d31fe700-cd39-4a01-bdb8-08db532a2a1c_
Content-Type: multipart/alternative;
	boundary="Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8"
Content-Transfer-Encoding: 7bit

--Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

A question:=20

Since we have a clear way of de-multiplexing RTP and DTLS, is it necessary t=
o entangle that (solved) problem with the A/V mux issue? I realize that SDP h=
as the tendency to "deeply intermingle" just about everything, but at the RT=
P/DTLS level, we're in much better shape.

Bernard "Do we need to boil the entire ocean, or just a lake or two?" Aboba

On Feb 13, 2013, at 13:49, "Eric Rescorla"  wrote:

> I would phrase this somewhat less strongly: less ports is better than more=
 ports,
> so all things being equal, a multiplexing mechanism that keeps you down to=

> one port is better than not. That said, if we decide that plan A is dead a=
nd
> we are going to plan B, I can live with having data on a separate port.
>=20
> -Ekr
>=20
> On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup  w=
rote:
>> On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote:
>>> I think EKR expressed that he felt it was important for data channel to b=
e included in the multiplexing.
>>=20
>> And I agree(d), strongly.  We want 1 port to minimize NAT issues and star=
tup times.
>>=20
>>=20
>>>=20
>>> At the interim, during my BUNDLE presentation, I indicated that we need t=
o make a decision whether the solution (whatever it will be...) shall suppor=
t bundling of non-RTP media. Not saying it can't be changed, but as currentl=
y documented all alternatives only support bundling of RTP media.
>>>=20
>>> There might have been some comments from the mic, but as far as I know t=
here was no decision (if there was, please point me to it).
>>>=20
>>> So, my question is: do we keep the scope to RTP media?
>>=20
>> --=20
>> Randell Jesup
>> randell-ietf@jesup.org
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit


A question: 

Since we have a clear way of de-multiplexing RTP and DTLS, is it necessary to entangle that (solved) problem with the A/V mux issue? I realize that SDP has the tendency to "deeply intermingle" just about everything, but at the RTP/DTLS level, we're in much better shape.

Bernard "Do we need to boil the entire ocean, or just a lake or two?" Aboba

On Feb 13, 2013, at 13:49, "Eric Rescorla" <ekr@rtfm.com> wrote:

I would phrase this somewhat less strongly: less ports is better than more ports,
so all things being equal, a multiplexing mechanism that keeps you down to
one port is better than not. That said, if we decide that plan A is dead and




we are going to plan B, I can live with having data on a separate port.

-Ekr

On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup <randell-ietf@jesup.org> wrote:




On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote:



I think EKR expressed that he felt it was important for data channel to be included in the multiplexing.





And I agree(d), strongly.  We want 1 port to minimize NAT issues and startup times.








At the interim, during my BUNDLE presentation, I indicated that we need to make a decision whether the solution (whatever it will be...) shall support bundling of non-RTP media. Not saying it can't be changed, but as currently documented all alternatives only support bundling of RTP media.






There might have been some comments from the mic, but as far as I know there was no decision (if there was, please point me to it).



So, my question is: do we keep the scope to RTP media?







-- 

Randell Jesup

randell-ietf@jesup.org



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





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

--Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8--

--_d31fe700-cd39-4a01-bdb8-08db532a2a1c_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--_d31fe700-cd39-4a01-bdb8-08db532a2a1c_--

From fluffy@iii.ca  Wed Feb 13 14:24:19 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07C21E8096 for ; Wed, 13 Feb 2013 14:24:19 -0800 (PST)
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_111=0.6, J_CHICKENPOX_17=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 0GEYU0uB2CzY for ; Wed, 13 Feb 2013 14:24:18 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id EA03C11E809C for ; Wed, 13 Feb 2013 14:24:17 -0800 (PST)
Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5C650509B6; Wed, 13 Feb 2013 17:24:16 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Cullen Jennings 
In-Reply-To: 
Date: Wed, 13 Feb 2013 15:24:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5113CD16.6090806@jesup.org>  <51166A3C.4000604@jesup.org>  <511B6C9A.4090904@jesup.org> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.1499)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 22:24:19 -0000

To help this move quickly, could someone just draw out the various call =
flows and shows the pro's con's of them so that everyone is on the same =
page?


On Feb 13, 2013, at 3:03 PM, Martin Thomson  =
wrote:

> None of what I suggest would change the API.  At most, it would have
> removed the in-band handshake messages in exchange for loosening some
> of the guarantees.  And I've been trained to value the deletion of
> code highly.  That seemed like a good trade.
>=20
> And timing?  It wasn't until you presented at the interim that I
> realized just how little value the in-band handshake was adding.
>=20
> In terms of the specifics of your fast open proposal, what do you do
> with the message(s) that arrive on channels that you reject?  How does
> this surface in the API?
>=20
> I'll do a blow-by-blow on your points below, if you want to continue
> the conversation.  If we're exchanging rhetoric bombs, I see little
> point.
>=20
> On 13 February 2013 02:36, Randell Jesup  =
wrote:
>> A general note to start this:
>>=20
>> We've been here before.  ALL of this has been argued over in great =
detail A
>> YEAR AGO.  I'm sorry if some people were not involved at the time, =
and I'm
>> fine with technical criticism of details of the solutions chosen.  =
However,
>> while we did not have formal consensus calls (I think), there =
certainly was
>> list (and in many cases room) consensus on these details, such as
>> bidirectional channels and adding the WebSockets 'protocol' ID at =
Atlanta in
>> order to ease heterogeneous application interop for things like chat.
>>=20
>> Sure, there were many options available to us.  We discussed them in =
great
>> detail and chose a solution that was strongly patterned on WebSockets =
(and
>> to good effect, from what I've seen in practice).  Options like my =
original
>> proposals for effectively "raw" unidirectional SCTP with SDP =
negotiation
>> were firmly rejected in favor of bidirectional channels with =
low-overhead
>> creation - and I agreed with the consensus on the list.
>>=20
>> *Can* we reopen all of this?  Sure!  We *can* reopen ANYTHING =
(including
>> consensus calls).  *Should* we?  No, if we ever want to make =
progress,
>> unless there is some technical problem with the solution.  The =
details I was
>> trying to resolve here and finalize were the outcome of conflicting =
requests
>> to make small changes to channel creation from the Interim *last =
June*.  If
>> people had issues with the general approach, they should have been =
presented
>> then (or earlier on the list).
>>=20
>> "Rough consensus and running code"?  We certainly had rough consensus =
a long
>> time ago on most of this (and more IMO).  Running code?  We have a =
largely
>> debugged implementation today in Firefox that's in-use in our Social =
API
>> stuff, in 3D games, and other prototype applications.  We worked =
closely
>> with Michael Tuexen, Randall Stewart and others to polish the open
>> user-space SCTP library.
>>=20
>> To be clear:  My revised proposal after the discussion in the room =
and on
>> the list is to resolve the startup issues by firing onopen =
immediately and
>> thus allowing 0-RTT opens, removing the need for special SDP =
parameters
>> other than the m=3Dapplication line and a=3Dsctpmap line (which are =
needed to
>> specify an SCTP/DTLS association, and are part of the existing MMUSIC
>> draft).
>>=20
>> I think we have a *workable* solution that addresses the end-user
>> requirements and expectations, and is flexible enough to support =
complex
>> future uses, and will allow for straightforward heterogeneous =
application
>> interop.  Let's move on and make progress where we *haven't* been =
able to
>> eliminate alternatives yet (or where they keep expanding instead of =
being
>> pruned away).
>>=20
>>=20
>> On to the detailed response:
>>=20
>> On 2/11/2013 2:54 PM, Martin Thomson wrote:
>>>=20
>>> On 9 February 2013 07:24, Randell Jesup  =
wrote:
>>>=20
>>>> If you were to extend this to work for renegotiations where glare =
is
>>>> possible, you'd have to either wait for the renegotiation to =
finish, or
>>>> use
>>>> some even/odd sort of trick which was proposed way back when on the =
list.
>>>=20
>>> If you want to resolve glare, then you use the mechanisms you =
already
>>> have for glare resolution.  Which, RFC 3264 defers to RFC 3261, =
which
>>> uses a fairly heavy-weight mechanism.  Keep in mind that you already
>>> need this if you are using offer-answer.  Use whatever mechanism you
>>> already have in place (I like the tie-breaker random number method
>>> myself).
>>>=20
>>> Or, you could stop worrying about glare and in those cases where =
glare
>>> is possible, allow the collision to proceed.
>>>=20
>>> This is an application choice.
>>=20
>>=20
>> Not unless you change the semantics of the JS API I believe.  If =
you're
>> exposing glare to the application in some manner that's complexity =
for them
>> to manage (and in a case that's hard for them to test).  It's easy to
>> imagine applications making mistakes or ignoring the possibility here =
if
>> it's exposed.
>>=20
>>>> Out-of-band negotiation means either:
>>>>=20
>>>> a) SDP offer/answer (which in many cases will go via a central =
server,
>>>> though it can go over an existing datachannel), min 1 RTT (perhaps
>>>> 1-RTT-through-server) plus SDP processing delay, and requires
>>>> implementing
>>>> error handling for cases where the answers and offers don't =
properly
>>>> match
>>>> up,
>>>=20
>>> This was my thought.  There is no need to reserve a channel for this
>>> purpose, that's just extra machinery.  Any app that wants the fast
>>> path for this will make their own.  And, the nice thing about that =
is
>>> that they can do this before setting up the session.
>>=20
>>=20
>> Sure, that's the standard "fast-path" solution.  It's still 1 RTT and =
a lot
>> of processing, and blocks other renegotiations while it's in-flight =
(that's
>> fairly minor, but it would block adding more channels during that =
RTT).
>> Remember RTT isn't always tens of milliseconds.  Sometimes you're on =
a
>> satellite link with 500+ms of RTT, sometimes you're on the other side =
of the
>> globe with 200+ms RTT, sometimes you're fighting congestion or =
bufferbloat
>> (it happens, and some apps like this may be pure-data apps) and you =
have
>> crazy RTT's like 1 second+.  And if you have a non-colocated TURN =
server
>> (say AUS->AUS via TURN in the US) you can have a lot of RTT.  TURN =
will be
>> expensive; do not expect every app to have fully geo-dispersed TURN
>> networks!  However, these are largely nits - it's still min 1 RTT an =
heavy
>> string processing.
>>=20
>>>> Are there real usecases where the in-band Open and OpenResponse =
messages
>>>> actually cause a usecase not to work?
>>>=20
>>> Well, given that we need message type stuff, we already have to =
suffer
>>> some extra muck on top of the SCTP association.  Not many =
applications
>>> will survive that.
>>=20
>>=20
>> Ok, good - I couldn't see how that argument made sense.
>>=20
>>> No, the real question is: what value do these messages actually add?
>>> What information do they convey that isn't already negotiated =
through
>>> other channels?
>>=20
>>=20
>> It's an alternative to negotiating it through other channels.  In the
>> proposal I just made here on the list, it gets you consistency with
>> WebSockets and bidirectional symmetric channels (both also doable by =
other
>> methods like pure-SDP), and 0-RTT opens (not possible in SDP while =
retaining
>> the first set of JS-API-level features).
>>=20
>>> Starting a stream with a header that declares attributes for a =
stream
>>> sounds nice, but it's completely unnecessary in a vast number of
>>> cases.  For many cases, this is a case of the same piece of software
>>> talking to itself - it hardly cares.  In many other cases, =
negotiation
>>> of properties through SDP is perfectly sufficient.
>>=20
>>=20
>> Sure, many apps will have (when talking to themselves) a fixed set of
>> channels set up at the start, which was what I was attempting to =
optimize
>> given the W3 constraint to wait for a truly-acknowledged 'onopen' ala
>> WebSockets.  My alternative proposed here is to fire onopen =
immediately
>> (since DataChannels are declarative) and allow 0-RTT opens, obviating =
the
>> need the SDP enhancements presented at the meeting.
>>=20
>> We already do have people querying if DataChannels could be used for =
things
>> like GFC avoidance for things like proxied browsing, which (if it's =
doable,
>> which I haven't verified but seems plausible if the user grants the =
app
>> special permissions), which would imply a need for low-overhead =
channel
>> creation.
>>=20
>>> The only case I see for an in-band protocol is where you wish to
>>> invent some new protocol on this platform, and I can't really muster
>>> up that much enthusiasm for that.  It's far too heavily reliant on =
my
>>> imagination.  Even in those cases, my knowledge of existing SCTP =
usage
>>> patterns suggest that the properties that are sent in
>>> Open/OpenResponse messages are not that useful to have.  Many
>>> applications will use the same values for all new streams.
>>=20
>>=20
>> There are lots of applications I envision (such as games) that will =
want a
>> small mix of reliable and unreliable (or partially-reliable) =
channels, and
>> others that want a mix of priorities (which we haven't talked about =
much,
>> but would allow specifying if a data channel should be higher or =
lower
>> priority than media streams, and perhaps more granularity.  Control
>> information (low BW) may be higher, file transfer may be lower, for =
example.
>>=20
>> --
>> Randell Jesup
>> randell-ietf@jesup.org
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From martin.thomson@gmail.com  Wed Feb 13 15:14:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DC721F8644 for ; Wed, 13 Feb 2013 15:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.100,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WivUdppz1HU for ; Wed, 13 Feb 2013 15:14:24 -0800 (PST)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8899821E8098 for ; Wed, 13 Feb 2013 15:14:20 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id x43so1471250wey.24 for ; Wed, 13 Feb 2013 15:14:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=tIq6EWH9p0rcjIMmMlUzM1O5DNW1B/T2tGptBBwRezk=; b=drYJqws+u0xL5bCiel1BWWAunitvLnuObk6FWeu3+H91B4TneNHdt/OcaC9GPVX1ka SzuTLNNA9evjjdpPvnX912PLnW9aXCXApZ2zbHnRLuJ6dk/oWfvZDlZW7d+/5upCqEge wwapIcO/nJKj2gRIGHkNUtaduOuJ9lhy67U7qS0t7Zu2+DVsnVE3ryrJFaqD3sL2HNmZ hJVko3zdYFlGmoGPgh+s2wQ21u52u3AKnSPYi7fOfiX/rpkkTXxuw6oXJlD0t8ZTEMUw LaVDBfVEqoDseGycZZKjjuMczqRBkRqqwJEiWPY1EY5M5zTX9bY9IBE7luMdgdsXiCJh isDQ==
MIME-Version: 1.0
X-Received: by 10.180.76.84 with SMTP id i20mr13266452wiw.9.1360796287327; Wed, 13 Feb 2013 14:58:07 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Wed, 13 Feb 2013 14:58:07 -0800 (PST)
In-Reply-To: 
References:  <5113CD16.6090806@jesup.org>  <51166A3C.4000604@jesup.org>  <511B6C9A.4090904@jesup.org>  
Date: Wed, 13 Feb 2013 14:58:07 -0800
Message-ID: 
From: Martin Thomson 
To: Cullen Jennings 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 23:14:24 -0000

On 13 February 2013 14:24, Cullen Jennings  wrote:
>
> To help this move quickly, could someone just draw out the various call f=
lows and shows the pro's con's of them so that everyone is on the same page=
?

I'm not sure that this will help, or even cover all the nuances effectively=
...

in-band negotiation only:
http://www.websequencediagrams.com/?lz=3DdGl0bGUgZGF0YSBjaGFubmVsIHN0YXR1cy=
BxdW8KCkFsaWNlLT5Cb2I6IE9mZmVyCm5vdGUgcmlnaHQgb2YgABQFQm9iIHRoaW5rcyBhYm91d=
CBpdApCb2ItPgA5BTogQW5zdwAyCG92ZXIgAFEFADYGSUNFLCBEVExTLCBTQ1RQLCBldGMuLi4A=
aw5wZW4gKCJsYWJlbCIsIHN0cmVhbSBYLACBKApldHRpbmdzKQCBBhhjYW4gcmVzcG9uZCBvbiB=
hbnkgYXZhaWxhYmxlAEkHAIElDU9wZW5SACsFc2UAaBJZKQCCCw1Mb2NrSXRJAIEZCgCBAAcAgV=
sQAIJYCGlzIHJlYWR5AIJQDWRhdGE&s=3Dnapkin

SDP negotiation only:
http://www.websequencediagrams.com/?lz=3DdGl0bGUgZGF0YSBjaGFubmVsIFNEUCBvbm=
x5Cgpub3RlIGxlZnQgb2YgQWxpY2U6AAEGIGNyZWF0ZXMALAgKABgFLT5Cb2I6IE9mZmVyADYGc=
mlnaAA4BQAUBUJvYiBnZXRzICdkYXRhAGgHJyBldmVudApCb2ItPgBcCG5zdwA7CG92ZXIAbgcA=
WQVJQ0UsIERUTFMsIFNDVFAsIGV0Yy4uLgB1DQCBSgUoc3RyZWFtIFgpAHgUABcGcyBhcmUgbGl=
ua2VkIGJhc2VkIG9uIG5lZ290aWF0ZWQgbGFiZWwgaW4gc3RhdHVzIHF1bwCBHQ1tb3IAgjcHAG=
cIWSkAgXUYAII6D1RoaXMgbQCCHAV1c2UgdGhlIGV4aXN0aW5nAIMDDQCCBhQAgVQZUSk&s=3Dn=
apkin

Randell's 0RTT in-band option:
http://www.websequencediagrams.com/?lz=3DdGl0bGUgZGF0YSBjaGFubmVsIGZhc3QgaW=
4tYmFuZAoKQWxpY2UtPkJvYjogT2ZmZXIKQm9iLT4AEgU6IEFuc3dlcgpub3RlIG92ZXIgACoFI=
AApBUlDRSwgRFRMUywgU0NUUCwgZXRjLi4uAEQOcGVuICgibGFiZWwiLCBzdHJlYW0gWCwAgQQJ=
c2V0dGluZ3MpAHwNZGF0YQBvBnJpZ2h0IG9mAG0Gb25kYXRhAIFBCCsgb25vcGVuAAQFbWVzc2F=
nZSBldmVudHMAgTgNT3BlblJlc3BvbnNlAHsSWQBtDkxvY2tJdEkAgSwKKQo&s=3Dnapkin

No negotiation option:
http://www.websequencediagrams.com/?lz=3DdGl0bGUgZGF0YSBjaGFubmVsIG5vIG5lZ2=
90aWF0aW9uIG9wdGlvbgoKCkFsaWNlLT5Cb2I6IE9mZmVyCkJvYi0-ABIFOiBBbnN3ZXIKbm90Z=
SBvdmVyIAAqBSAAKQVJQ0UsIERUTFMsIFNDVFAsIGV0Yy4uLgBFDgCAfwUoc3RyZWFtIFgpAFAN=
cmVwbHkAEQwAYgZsZWZ0IG9mAGUGOiBjcmVhdGVEYXRhQwCBRAcoWSkAShpZKQCBKAZyaWdoAEI=
FAIFVBTMgZXZlbnRzIG9uZGF0YQCCDQgrIG9ub3BlbgAEBW1lc3NhZ2UAgQgbAFQIAIF6EERyYX=
diYWNrOiBCb2IgYW5kAIIgB20AgH8FaGF2ZSBkaWZmZXJlbnQgbGFiZWxzL3Byb3BlcnRpZXMAg=
kgWU29sdXRpb246AIMuCWUAg0QIcyBpZiB5b3UgY2FyZQCDBhZDb25zdHJhaW50OiAAgjAHcyB1=
c2UgdGhlIHNhbWUgAIMMB251bWJlciBvbiBib3RoIGVuZHMsIG5vAIEfCA&s=3Dnapkin

What we really have at the moment is both in-band + SDP.  I was
proposing that we go to SDP only, and maybe also allow the zero
negotiation option at the expense of consistency.  (Not just because
eventual consistency is web-scale.)

From tterriberry@mozilla.com  Wed Feb 13 20:23:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E959021E80D5 for ; Wed, 13 Feb 2013 20:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 cbJGWM59LKmu for ; Wed, 13 Feb 2013 20:23:28 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 794B621E80D2 for ; Wed, 13 Feb 2013 20:23:28 -0800 (PST)
Received: from [172.17.167.47] (h-64-105-111-74.cmbrmaor.static.covad.net [64.105.111.74]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BDDB3F226B for ; Wed, 13 Feb 2013 20:23:27 -0800 (PST)
Message-ID: <511C66BE.7090105@mozilla.com>
Date: Wed, 13 Feb 2013 20:23:26 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <51140038.3040001@ericsson.com>  <511407AA.1040501@ericsson.com>  <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com> <51165FCA.2040707@alvestrand.no> <511796C6.3050601@ericsson.com> <511820F9.5080806@alvestrand.no> <5118EDC1.2000809@ericsson.com> <5119F155.8090303@alvestrand.no>
In-Reply-To: <5119F155.8090303@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for	synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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 Feb 2013 04:23:29 -0000

Harald Alvestrand wrote:
> I don't understand what the problem is here. I may be dumb.
> If syncing is important to the guy writing the service, (he can't live
> with them being unsynchronized), he should put them in the same stream.

The argument goes that if we leave this unspecified, web authors will 
test against browser A which does X, and not against browser B which 
does Y, and users of browser B will suffer when things don't work like 
they did in browser A.

Personally I'm not convinced this argument applies here. For cases like 
"Do the contents of this table element show up at all when I fail to 
close my ?" it's pretty important, but in reality resynchronization 
is only going to affect things so much... if things get more than a few 
100 ms out of sync on the wire, the experience is going to be terrible 
no matter what you do (and I'd call them "bad" long before that point).

The goal of pixel-perfect rendering for webpages might be reasonable, 
but sample-accurate rendering of real-time media will never be possible 
given the limitations of real-world networks, and whether you're forcing 
synchronization or not, the media will still play.

> The practical issue I can think of would be a source that had its own
> clock, not the system clock, but is otherwise a local source. Having the
> same CNAME would require resynchronizing that source. I don't know if
> any such sources exist in practice, but again, I don't want to outlaw them.

I can certainly think of cases where two local streams with, e.g., the 
same sampling rate would advance at different rates measured against a 
global wallclock. For example, a gUM stream running against the 
microphone's clock vs. a