From magnus.westerlund@ericsson.com Thu Nov 1 01:39:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC58821F84BE for ; Thu, 1 Nov 2012 01:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 oqd9aJGo30KV for ; Thu, 1 Nov 2012 01:39:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0621F8498 for ; Thu, 1 Nov 2012 01:39:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-36-50923526fc92 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 77.24.11564.62532905; Thu, 1 Nov 2012 09:39:02 +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; Thu, 1 Nov 2012 09:39:02 +0100 Message-ID: <50923524.70109@ericsson.com> Date: Thu, 1 Nov 2012 09:39:00 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Matthew Kaufman References: <5091415E.4030902@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvra6a6aQAgy0fZCxm3DrLYrH2Xzu7 A5PHkiU/mTxuPZjEFsAUxWWTkpqTWZZapG+XwJWx8mILe8Fjvorb/5YwNjC+5e5i5OSQEDCR uLdkFiOELSZx4d56ti5GLg4hgZOMEqenXGKFcJYxSnSdPsEMUsUroCnRsv4oC4jNIqAi8XFW J5jNJmAhcfNHI1A3B4eoQLDE845iiHJBiZMzn4CViAjoS/Rsvs4KYjMLqEvcWXyOHcQWFjCT 2NU+BSwuJHCNUWLN+0AQm1MgUWJCwxtmiOMkJd6+f8UM0asnMeVqCyOELS/RvHU2M0SvtkRD UwfrBEahWUhWz0LSMgtJywJG5lWM7LmJmTnp5YabGIGhenDLb90djKfOiRxilOZgURLn5Ura 7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcdZd2cONW5gqn7NxJDQzPpj09FfKHOsFvhIq zIE9RgWHxG8cb2ovrqyRDDmVoC6rqv0oxOyny1SGMkZxpukz1QrnqifnSXxv8p26V7KbeVLl FIG6n6yPjj1oPrD6cIjkxfK1exnvWJp/v+678tV0p6AfZRstt73bcC9hsvvzQAsbnxOxvLbX lViKMxINtZiLihMBeouq6SMCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Nov 2012 08:39:04 -0000 On 2012-10-31 17:25, Matthew Kaufman wrote: > Harald Alvestrand: >> >> However, I believe that my opinion is based enough in facts that >> it's unlikely that I'll be swayed by a presentation given at the >> IETF; reading the drafts of the H.264 proponents certainly did not >> change it. >> > > Perfect. If everyone can read the drafts ahead of time and make up > their mind then we can spend valuable face-to-face time on the > existing issues plus the three (or more) new items that are coming > out of W3C this week instead of on the predetermined codec > discussion. Matthew, Your standpoint that any time spent on codec selection is meaningless has been made clear. I as chair however strongly believe that it is important that we run through the process we have outlined and announced. It is possible that the result in Atlanta will be the same as the one in Paris, but it might also be different. If I was certain about the outcome we would not spend time on this topic. But there is a number of people in this WG for which this topic is an important one. Regarding new issues coming out of the W3C it would be good if someone could fill in the rest of the WG what has occurred. Trying to have this WG respond to such raised issues without giving people time to think over the issues and any proposals would be problematic. So what are the issue that you like to discuss. 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 paalh@ifi.uio.no Thu Nov 1 06:49:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A896E21F8BF7; Thu, 1 Nov 2012 06:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGvQQOn3VK2Z; Thu, 1 Nov 2012 06:49:59 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 2033E21F8BD5; Thu, 1 Nov 2012 06:49:59 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TTv9d-0001zH-P6; Thu, 01 Nov 2012 14:49:53 +0100 Received: from ipbfp010-040.kcn.ne.jp ([61.89.102.40] helo=[192.168.24.90]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user paalh (Exim 4.80) (envelope-from ) id 1TTv9c-0006Bt-PF; Thu, 01 Nov 2012 14:49:53 +0100 From: =?iso-8859-1?Q?P=E5l_Halvorsen?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2012 14:49:50 +0100 Message-Id: <637F13A6-45A6-4800-B14E-ACA0CFEF1E06@ifi.uio.no> To: bloat@lists.bufferbloat.net, iccrg@cs.ucl.ac.uk, rmcat@ietf.org, rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 47 msgs/h 17 sum rcpts/h 49 sum msgs/h 19 total rcpts 25327 max rcpts/h 4849 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1B84527D3E17BAEDEA4B8B22C45270BB4F77D141 X-UiO-SPAM-Test: remote_host: 61.89.102.40 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 22 total 101 max/h 22 blacklist 0 greylist 0 ratelimit 0 Subject: [rtcweb] NOSSDAV 2013: less than a month until paper deadline (26. November) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Nov 2012 13:49:59 -0000 NOSSDAV 2013 - Call for Papers: less than a month until paper deadline = (26. November) NOSSDAV 2013: ACM Workshop on Network and Operating Systems Support=20 for Digital Audio and Video Oslo, Norway, February 26 =97 27, 2013 http://nossdav2013.ndlab.net NEW: Authors of selected good papers will be invited to submit an extended = version of=20 their work and submit it to the ACM Transactions on Multimedia = Computing,=20 Communications and Applications (ACM TOMCCAP) journal. NEW:=20 Dr. Aljosa Smolic (Disney Research Zurich, Switzerland) will give a = keynote=20 entiteled "Advanced 3D Video Processing and Coding" at NOSSDAV 2013.=20 http://nossdav2013.ndlab.net/program.html = --------------------------------------------------------------------------= -------------- As in previous years, NOSSDAV will continue to focus on both established=20= and emerging research topics, high-risk high-return ideas and proposals, = and=20 future research directions in multimedia networking and systems, in a=20 single-track format that encourages active participation and discussions = among academic and industry researchers and practitioners. The workshop seeks papers in all areas of multimedia networking and systems. Authors are especially encouraged to submit papers with real-world experimental results and real data sets. Topics of interest include (but are not restricted to): - Cloud and peer-to-peer system architectures - Media streaming, distribution and storage support - Multimedia communications and system security - Multi-core and many-core architecture support - Networked GPUs, graphics and virtual environments - Networked games / Real-time immersive systems - Operating system, middleware and network support - Web 2.0 systems and social networks - Wireless networks and embedded systems for multimedia applications =20 In particular, we are interested in soliciting papers that discuss system-level support for social media and social networking, papers that focus on improving performance with multi-core and many-core processors, as well as papers that focus on multimedia applications on mobile devices and/or in a cloud computing environment. Submitted papers must be original and should not be currently under review for any other publication. Authors of accepted papers will need to sign an ACM copyright release form and present their paper at NOSSDAV 2013 in person. The Proceedings of NOSSDAV 2013 will be published by ACM and distributed at the workshop electronically, and will also be included in the ACM Digital Library. * Paper Deadline: 26. November 2012 All paper submissions will be handled electronically in the NOSSDAV 2013 submission web site: http://submission.ndlab.net/nossdav13/ (also available from http://nossdav2013.ndlab.net) Best regards, Program Co-Chairs P=E5l Halvorsen, University of Oslo/Simula, Norway Laszlo B=F6sz=F6rmenyi, Klagenfurt University, Austria From ted.ietf@gmail.com Thu Nov 1 07:49:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F29121F8D39 for ; Thu, 1 Nov 2012 07:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 DeVXCQ9yOCPO for ; Thu, 1 Nov 2012 07:49:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 168E621F8D2E for ; Thu, 1 Nov 2012 07:49:37 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3066207vcb.31 for ; Thu, 01 Nov 2012 07:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i1JT5nMREh+Qvz0oHZeuiR6rVHmInDPaw1zeXg48wsY=; b=p58nNhvNujjChDWwW9jwdsGVMTUfnKgb9vstJSNYbDeBCxz0JVzWCUKTpg/030+kky JyIZ2X9fAilvBOnvc+B/+KAJyGNP2vH/+l7jSGs7VUTgmcK7diGkl8xfmXxT8gr3k3VG 1ZbVJdUwZvY1kg2rNeFH+r9TJp7Odccp6nd7c578RDjsI8YdGfqMhna4WXoEOpdC3hOb KC51jn2wFScwcTo7gmYXh64sPt4t+MclubtY3UB71NFTR/kZr18Vzq3TmzuIvW16UgvW BXtb9kCM0XJLxjfLGVYtaCJUbKbE+eHS1cSyHvBYp5nYTqmZDherEZd2SfITCIfK7iUc HhJg== MIME-Version: 1.0 Received: by 10.220.39.206 with SMTP id h14mr23206578vce.41.1351781376591; Thu, 01 Nov 2012 07:49:36 -0700 (PDT) Received: by 10.58.164.35 with HTTP; Thu, 1 Nov 2012 07:49:36 -0700 (PDT) In-Reply-To: <20121101122853.4065.5996.idtracker@ietfa.amsl.com> References: <20121101122853.4065.5996.idtracker@ietfa.amsl.com> Date: Thu, 1 Nov 2012 07:49:36 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Fwd: NomCom 2012: Feedback and Office Hours X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Nov 2012 14:49:44 -0000 A reminder to the working group that the NomCom is seeking feedback. regards, Ted Hardie ---------- Forwarded message ---------- From: NomCom Chair Date: Thu, Nov 1, 2012 at 5:28 AM Subject: NomCom 2012: Feedback and Office Hours To: IETF Announcement List The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ In order to ensure that your input is received in time to be useful, please provide your input on or before Sunday, November 11. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org From worley@shell01.TheWorld.com Fri Nov 2 08:54:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09A721F89DA for ; Fri, 2 Nov 2012 08:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkX+i3DdBncC for ; Fri, 2 Nov 2012 08:54:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id BD43D21F89DF for ; Fri, 2 Nov 2012 08:54:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qA2Fq9qA020272 for ; Fri, 2 Nov 2012 11:52:11 -0400 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 qA2Fq8wi206973 for ; Fri, 2 Nov 2012 10:52:08 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qA2Fq8l1207997; Fri, 2 Nov 2012 11:52:08 -0400 (EDT) Date: Fri, 2 Nov 2012 11:52:08 -0400 (EDT) Message-Id: <201211021552.qA2Fq8l1207997@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <066.b5060d6f1c778a37ddaaeadfa120da84@trac.tools.ietf.org> (trac+rtcweb@grenache.tools.ietf.org) Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2012 15:54:04 -0000 > #3: JSEP-02 Review (from Andy Hutton) > > 6. Section 4.2. Session Descriptions and State Machine states: > > "Lastly, while the exact media parameters are only known only after a > offer and an answer have been exchanged, it is possible for the offerer to > receive media after they have sent an offer and before they have received > an answer. To properly process incoming media in this case, the offerer's > media handler must be aware of the details of the offerer before the > answer arrives." > > I don't see the relevance of the statement "it is possible for the offerer > to receive media after they have sent an offer and before they have > received an answer". Why is the purpose of this statement? Unless one is familiar with how offer/answer works in SIP, one might easily assume that media can only be sent after the offer/answer cycle is complete. > 7. Section 4.2. Session Descriptions and State Machine states: > > "In [RFC3264], the constraints at the signaling level is that only one > offer can be outstanding for a given session but from the media stack > level, a new offer can be generated at any point. For example, when using > SIP for signaling, if one offer is sent, then cancelled using a SIP > CANCEL, another offer can be generated even though no answer was received > for the first offer. To support this, the JSEP media layer can provide an > offer whenever the Javascript application needs one for the signaling." > > Regarding the example SIP sequence in this scenario if the CANCEL is used > to terminate a SIP dialog initiating INVITE I would assume that normally > the peer connection would be terminated and a new peer connection used for > any subsequent call so it does not seem to be a good example. If the > example is meant to indicate that such a sequence could be used whilst > establishing a SIP dialog it is a really horrible example. If it is > intended to be an example mid dialog then the offer needs to be cancelled > and the media state reverted to what it was previously. In the language of the quoted passage, in SIP, once a CANCEL has been sent, the session is ended (at least from this end's point of view). This end may send another offer, but it will describe a different session. If there is some difficulty in the API about this, it is probably because the API doesn't explicitly allow manipulation of multiple sessions at once, and leaves the identify of the session that is being controlled implicit. > 14. Section 5.2.3 SessionDescriptionType > > ""pranswer" indicates that a description should be parsed as an answer, > but not a final answer, and so should not result in the freeing of > allocated resources. It may result in the start of media transmission, > if the answer does not specify an inactive media direction". Do we have any need for "pranswer"? Dale From csp@csperkins.org Fri Nov 2 08:55:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B002121F8C17 for ; Fri, 2 Nov 2012 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrh0bckNWXIt for ; Fri, 2 Nov 2012 08:55:44 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 04AF521F8C12 for ; Fri, 2 Nov 2012 08:55:44 -0700 (PDT) Received: from [130.209.247.112] (helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TUJat-0004dn-PT; Fri, 02 Nov 2012 15:55:40 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB441223-1A44-4905-B894-978DCB9F5590" From: Colin Perkins In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC96218B57F57E@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Date: Fri, 2 Nov 2012 15:55:38 +0000 Message-Id: <806B50B4-503D-4FA0-B706-0123E3C28007@csperkins.org> References: <5F7BCCF5541B7444830A2288ABBEBC96218B57F57E@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> To: "Schwarz, Albrecht (Albrecht)" X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -13 X-Mythic-Debug: Threshold = On = Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] editorial nits: draft-ietf-rtcweb-rtp-usage-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:55:45 -0000 --Apple-Mail=_DB441223-1A44-4905-B894-978DCB9F5590 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Albrecht, Thanks for the detailed feedback. The -05 version of the draft should = fix most of these, although some are differences between English and = American that I have no intention of fixing ;-) Cheers, Colin On 13 Aug 2012, at 15:33, Schwarz, Albrecht (Albrecht) wrote: > Colin, Magnus, > fyi, some editorial nits, > regards, > Albrecht > =20 > Line numbers according > = http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-rtc= web-rtp-usage-04.txt > =20 > Editorial change proposals: > =20 > 232 RTP Media Stream: A sequence of RTP packets, and = associated RTCP > packets, using a single synchronisation source (SSRC) that > =20 > synchronization (according RFC 3550) > =85 multiple times in doc > =20 > 295 participants in the session; support for randomised RTCP > =3D> randomized > =20 > 407 session also effects the possibility for differentiated = treatment of > =3D> affects > =20 > 528 implemented using a centralised server, multi-unicast, or = using IP > =3D> centralized > =85 multiple times > =20 > 588 Request above as there there may be multiple methods to = fulfill the > =3D> delete =91there=92 > =20 > 694 optimisations of non critical functions, and is hence = OPTIONAL to > =3D> optimizations > =20 > 715 will support negative acknowlegdements (NACKs) for RTP data = packets > =3D> acknowledgements > =20 > 1247 own traffic. While is is clearly considered a bug, it is = important > =3D> is is > 1248 that the end-point is able to recognise and handle the case = when it > =3D> recognize > =20 > =20 > 1670 This in an attempt to highlight the differencies and the in = many case > =3D> differences > =20 > 1718 An RTP session have good support for simultanously = transport multiple > =3D> simultaneously > =20 > 1723 video cameras can potentially transmitt video from both to = its > =3D> transmit > =20 > 1730 Thus we can introduce a couple of different notiations in = the below > =3D> notations > =20 > 1731 two alternate figures of a single peer connection in a a = point to > =3D> a a > =20 > 1838 different media bit-rates to the differnt peers, thus not = forcing B > =3D> different > =20 > 1839 to endure the same quality reductions if there are = limiations in the > =3D> limitations > 1874 encoder instances each beeing associated with two different > =3D> being > =20 > 1883 resource costrained will use a different implementation = strategy > =3D> constrained > =20 > 1918 limited to congestion control, also prefered resolution to = receive > =3D> preferred > =20 > 1919 based on dispaly area available is another aspect requiring > =3D> display > =20 > 1920 consideration. The need for this type of descion logic = does arise in > =3D> decision > =20 > 1949 its operation and form new RTP packets, encrypts and = integegrity > =3D> integrity > =20 > 1970 in a media domain mix of the incomming RTP media streams. = Then > =3D> incoming > =20 > 1980 produce a Mix of all N streams for the group that are = curently not > =3D> currently > =20 > 2046 particpants. As each peer receives a different version = produced by > =3D> participants > =20 > 2070 There exist an possible implementation choice to have the = RTP > =3D> =93a possible=94 ? > =20 > 2074 about the contributing sources. This removes both the = functionality > =3D> functionality > =20 > 2078 they can be avoide to be resolved and instead remapped = between the > =3D> avoided > =20 > 2080 requiresthat SSRC/CSRC are never exposed to the WebRTC = javascript > =3D> space > =20 > 2185 arguments and conisderations as discussed in Appendix = A.3.1.1 applies > =3D> considerations > =20 > 2194 mixer in another RTP session recieves media from that = end-point. > =3D> receives > =20 > 2257 sequence number will need to be consequitvely incremented = based on > =3D> consequ=85 ? > =20 > 2263 handled indepdentently also thus working around any SSRC = collisions > =3D> independently > =20 > 2265 related WebRTC MediaStream signalling must be = correspondlingly > =3D> correspondingly > =20 > 2272 requests comming from an end-point and decide if it can act = on it > =3D> coming > =20 > 2327 end-point. For example receving a 2.5 mbps video stream = and then > =3D> receiving > =20 > 2328 send out a 250 kbps video stream after transcoding is a = vaste of > =3D> waste > =20 > 2332 increasing media bit-rate futher than what is needed to = represent the > =3D> further > =20 > 2368 in the two different PeerConnections that are represtented = by having > =3D> represented > =20 > 2372 likely needed to be soruced by the translator in response = to actions > =3D> sourced > =20 > 2397 keymanagement. On RTP level the main functions that may be = missing > =3D> key management > =20 > 2398 in a legacy implementation that otherswise support RTP are = RTCP in > =3D> otherwise > =20 > 2433 need to change is higly dependent on what functions it need = to proxy > =3D> highly=20 > 2451 packet content or media. In fact one of the more likley = scenario is > =3D> likely > =20 > 2455 encryption and integirty protection operation to resolve = missmatch in > =3D> integrity > =3D> mismatch > =20 > 2464 and the second one which is to to provide a group = communication > =3D> to to > 2480 forwards all the RTP/RTCP traffic and keymanagment to the = end-point > =3D> key management > =20 > 2551 the client A must be capable of handlilng that when = determining > =3D> handling > =20 > 2560 reporting in that case becomes incosistent and without = explicit > =3D> inconsistent > =20 > 2634 A relay approache will result in that the WebRTC end-points = will have > =3D> approach > =20 > =20 > 2671 to be most easily accomplished by establishing mutliple > =3D> multiple > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_DB441223-1A44-4905-B894-978DCB9F5590 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Colin, = Magnus,
fyi, some editorial = nits,
regards,
Albrecht
 
Line = numbers according
 
Editorial = change proposals:
 
232      =   RTP Media Stream:  A sequence of RTP packets, and associated = RTCP
  1.       packets, = using a single synchronisation source (SSRC) that
 
     
295      =      participants in the session; support for = randomised RTCP
=3D> randomized
 
407      =   session also effects the possibility for differentiated treatment = of
=3D> affects
 
528      =   implemented using a centralised server, multi-unicast, or using = IP
=3D> centralized
=85 multiple = times
 
588      =   Request above as there there may be multiple methods to fulfill = the
=3D> delete =91there=92
 
694      =   optimisations of non critical functions, and is hence OPTIONAL = to
=3D> = optimizations
 
715     =    will support negative acknowlegdements (NACKs) for RTP data = packets
=3D> = acknowledgements
 
1247    &n= bsp;  own traffic.  While is is clearly considered a bug, it = is important
=3D> is = is
1248       that the end-point = is able to recognise and handle the case when it
=3D> = recognize
 
 
1670      = ; This in an attempt to highlight the differencies and the in many = case
=3D> differences
 
1718      = ; An RTP session have good support for simultanously transport = multiple
=3D> simultaneously
 
1723      = ; video cameras can potentially transmitt video from both to = its
=3D> transmit
 
1730      = ; Thus we can introduce a couple of different notiations in the = below
=3D> notations
 
1731      = ; two alternate figures of a single peer connection in a a point = to
=3D> a = a
 
1838       = different media bit-rates to the differnt peers, thus not forcing = B
=3D> = different
 
1839     &nb= sp; to endure the same quality reductions if there are limiations in = the
=3D> = limitations
1874       = encoder instances each beeing associated with two = different
=3D> being
 
1883      = ; resource costrained will use a different implementation = strategy
=3D> constrained
 
1918      = ; limited to congestion control, also prefered resolution to = receive
=3D> preferred
 
1919      = ; based on dispaly area available is another aspect = requiring
=3D> = display
 
1920      = ; consideration.  The need for this type of descion logic does = arise in
=3D> decision
 
1949      = ; its operation and form new RTP packets, encrypts and = integegrity
=3D> integrity
 
1970      = ; in a media domain mix of the incomming RTP media streams.  = Then
=3D> incoming
 
1980      = ; produce a Mix of all N streams for the group that are curently = not
=3D> currently
 
2046      = ; particpants.  As each peer receives a different version produced = by
=3D> participants
 
2070      = ; There exist an possible implementation choice to have the = RTP
=3D> =93a possible=94 ?
 
2074      = ; about the contributing sources.  This removes both the = functionality
=3D> functionality
 
2078      = ; they can be avoide to be resolved and instead remapped between = the
=3D> avoided
 
2080      = ; requiresthat SSRC/CSRC are never exposed to the WebRTC = javascript
=3D> space
 
2185      = ; arguments and conisderations as discussed in Appendix A.3.1.1 = applies
=3D> = considerations
 
2194    &nbs= p;  mixer in another RTP session recieves media from that = end-point.
=3D> receives
 
2257      = ; sequence number will need to be consequitvely incremented based = on
=3D> consequ=85 ?
 
2263      = ; handled indepdentently also thus working around any SSRC = collisions
=3D> independently
 
2265      = ; related WebRTC MediaStream signalling must be = correspondlingly
=3D> correspondingly
 
2272      = ; requests comming from an end-point and decide if it can act on = it
=3D> = coming
 
2327      = end-point.  For example receving a 2.5 mbps video stream and = then
=3D> = receiving
 
2328     &nb= sp; send out a 250 kbps video stream after transcoding is a vaste = of
=3D> = waste
 
2332       = increasing media bit-rate futher than what is needed to represent = the
=3D> = further
 
2368      = ; in the two different PeerConnections that are represtented by = having
=3D> = represented
 
2372     &= nbsp; likely needed to be soruced by the translator in response to = actions
=3D> = sourced
 
2397      = ; keymanagement.  On RTP level the main functions that may be = missing
=3D> key = management
 
2398     &n= bsp; in a legacy implementation that otherswise support RTP are RTCP = in
=3D> = otherwise
 
2433     &nb= sp; need to change is higly dependent on what functions it need to = proxy
=3D> highly 
2451 &nbs= p;     packet content or media.  In fact one of = the more likley scenario is
=3D> = likely
 
2455      = encryption and integirty protection operation to resolve missmatch = in
=3D> integrity
=3D> = mismatch
 
2464     &nbs= p; and the second one which is to to provide a group = communication
=3D> to = to
2480       forwards all = the RTP/RTCP traffic and keymanagment to the end-point
=3D> = key management
 
2551      = ; the client A must be capable of handlilng that when = determining
=3D> handling
 
2560      = ; reporting in that case becomes incosistent and without = explicit
=3D> = inconsistent
 
2634     =   A relay approache will result in that the WebRTC end-points will = have
=3D> = approach
 
 
2671   = ;    to be most easily accomplished by establishing = mutliple
=3D> multiple
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
_____________________________________= __________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org= /mailman/listinfo/rtcweb



-- 
Colin Perkins



= --Apple-Mail=_DB441223-1A44-4905-B894-978DCB9F5590-- From csp@csperkins.org Fri Nov 2 08:57:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51EC21F8C17 for ; Fri, 2 Nov 2012 08:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV5MhnoY0Pe3 for ; Fri, 2 Nov 2012 08:57:58 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id DAAFC21F8BCB for ; Fri, 2 Nov 2012 08:57:57 -0700 (PDT) Received: from [130.209.247.112] (helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TUJd6-00054r-OX for rtcweb@ietf.org; Fri, 02 Nov 2012 15:57:57 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Colin Perkins In-Reply-To: <20121022213241.15898.74886.idtracker@ietfa.amsl.com> Date: Fri, 2 Nov 2012 15:57:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5AC7F1B7-E44F-454C-B2AA-8ACBF6C87EAD@csperkins.org> References: <20121022213241.15898.74886.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -13 X-Mythic-Debug: Threshold = On = Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:57:58 -0000 On 22 Oct 2012, at 22:32, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-05.txt > Pages : 61 > Date : 2012-10-22 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-05 The diff from the previous version of this draft is messy because of a = spell-check and lots of editorial fixes. The main changes are: - Use RFC 2119 terminology by reference, rather than by copying the = definitions. - In Section 4.2 on the Choice of RTP Profile, note that the RTP/SAVPF = profile with the updated list of recommended codecs is mandated, not the = standard RTP/SAVPF profile. Update Section 4.3 on the Choice of RTP = Payload Formats to match. - In Section 4.6, clarify that the use of non-compound RTCP packets MUST = be negotiated on the signalling channel before use, and that = implementations are REQUIRED to support compound RTCP feedback packets = if the remote endpoint does not agree to use non-compound RTCP packets. - In Section 4.9, remove the reference to RFC 6222 and instead reference = the RFC 622bis draft. - Update references to RFC 5117 to joint to the RTP Topologies update = draft. - In Section 5.1.1, clarify that a WebRTC sender is REQUIRED to = understand and react to FIR messages it receives, but that sending FIR = messages is OPTIONAL. - Rewrite Section 7 on rate control and media adaptation for clarity. = Merge the previous Sections 7.1 and 7.2 into a single new section, and = try to better explain the relationship between the RTP circuit breakers, = the signalled SDP bandwidth limitations, and any RTP/AVPF TMMBR = messages. - Add Section 13 on Open Issues. - Revise and expand Section 15 on Security Considerations. It doesn't look like this draft is on the agenda for RTCWeb in Atlanta, = but we're happy to receive feedback on the list. --=20 Colin Perkins http://csperkins.org/ From ted.ietf@gmail.com Fri Nov 2 09:23:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D3321F8B38 for ; Fri, 2 Nov 2012 09:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 Gtaqs81wBQSO for ; Fri, 2 Nov 2012 09:23:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C79321F8CDD for ; Fri, 2 Nov 2012 09:23:58 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4432360vbb.31 for ; Fri, 02 Nov 2012 09:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dimCfmnD5Wrehy5dEfGK/gZ00bF+zPzKOt+9yXqqlXQ=; b=hCkx+Gy3Oeou+nqX/DD7vcWxkXzSavfr3EeJL5LLgt6kuRpS2gcb/XYjKjeoiUZ36Q HtnoilTcfmxrp4nVwYgudGPLBdoPKq022SwSR11+Gr/j6Txb0ofS3BMKPdjsGiU0qTPh dcEqtF+XbwOaDMh9ZJN2CyiResyyOuK5sa0Ge/APcnW4U84oO1xoU1sLvAER6pcZ2tkk BXaC/UG3h3s24NmNOzSOZcM0RPC6fCClw/FEj4P9H7F4ozSwrb7CEDjve9EJIKoBksoV 6mLyI+rABCPx23s82zPptZG+rmDegGl3eBfz3y1GJ0ZZDbwwtRAWdy2VC1t86YSQ9vgR FD9g== MIME-Version: 1.0 Received: by 10.58.64.196 with SMTP id q4mr2450605ves.3.1351873434766; Fri, 02 Nov 2012 09:23:54 -0700 (PDT) Received: by 10.58.164.35 with HTTP; Fri, 2 Nov 2012 09:23:54 -0700 (PDT) Date: Fri, 2 Nov 2012 09:23:54 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Slides, please X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2012 16:23:59 -0000 If you are presenting at the upcoming meeting, please send your slides no later than Monday evening. We're once again being supported by the Meetecho team (thanks!), and they need to be able to load our slides into their system. thanks, Ted Hardie From matthew.kaufman@skype.net Fri Nov 2 11:21:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891331F0C69 for ; Fri, 2 Nov 2012 11:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Vh-A345spOlj for ; Fri, 2 Nov 2012 11:21:46 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id A50561F0C59 for ; Fri, 2 Nov 2012 11:21:46 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.200) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.545.8; Fri, 2 Nov 2012 18:21:43 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Fri, 2 Nov 2012 18:21:43 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 2 Nov 2012 18:21:13 +0000 From: Matthew Kaufman To: "public-webrtc@w3.org" , "rtcweb@ietf.org" Thread-Topic: summary of issues raised at W3C meeting Thread-Index: Ac25Jht82bllP8XRTkCijqp9bu7o/g== Date: Fri, 2 Nov 2012 18:21:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: 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:(53806001)(54316001)(46102001)(47736001)(4396001)(47446002)(47776002)(54356001)(33656001)(50986001)(50466001)(51856001)(49866001)(47976001)(31966008)(44976002)(76482001)(74662001)(48376001)(16406001)(74502001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06530126A4 Cc: Martin Thomson Subject: [rtcweb] summary of issues raised at W3C 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: Fri, 02 Nov 2012 18:21:47 -0000 During the one and a half days of WEBRTC meeting and half day of Media Capt= ure Task Force meeting at this week's W3C TPAC, a large number of issues ca= me up, some of which were resolved. These fall into several categories, suc= h as issues for the W3C WG, for other W3C WGs, for the IETF RTCWEB WG, othe= r IETF WGs, and in some cases span more than one. Rather than attempt to ca= tegorize each of these items, I will simply list them below for 1) others p= resent to expand upon where I missed or mis-stated something and 2) others = to categorize appropriate and/or turn into action items (drafts, etc.) -- begin list -- Collections of streams within an RTCPeerConnection are currently an array. = This leads to the risk that someone will remember the array index, which wo= uld prevent removing streams. Solution is to replace this with a different = type of collection and accessor. (Likewise, outside of WEBRTC, there needs = to be a corresponding change for arrays of tracks within streams) Both streams and tracks need both "id" and "label" fields. "id" is guarant= eed to be unique and will be used as the "msid" in the SDP. "label" is huma= n-readable. AGC and AEC settings will have local effect only, set using constraints. There is no API to reject an incoming track (and thus reject from the offe= r/answer exchange without modifying SDP directly)... even if there were at = the track level, this wouldn't map directly to the m=3D sections of the SDP= . It was suggested that content labels to be added a parameter on a track. De= fault of none. If specific content type is set then label is set in a new m= =3D section with a=3Dcontent: set to match the label. SDES or not still needs to be decided at IETF. Also things like MTI cipher= suites for both SDES and DTLS-SRTP. There is apparently a desire to get certain kinds of constraints to the fa= r end of an RTCPeerConnection... treating it as a pipe. So that if a constr= aint of (say) resolution is placed on a video track that is playing out tha= t constraint would be sent somehow (SDP? RTCP? Application?) to the other e= nd and affect the sending track and ultimately the source device. There is a desire to do trickle ICE. This requires a way to signal the des= ire to do trickle ICE in the SDP in a way that is backwards-compatible with= existing RFC3264 O/A and existing non-trickle ICE implementations, while s= till generating fully 3264-compatible SDP for the trickle case (or updating= 3264 and pointing JSEP at the update). There is a need to write down what MUST NOT be changed in the SDP that com= es out of createOffer (and createAnswer?) before it is put in to setLocalDe= scription, and what MUST BE ACCEPTED IF CHANGED. This includes complexities= such as reassignment of ports in m=3D line. The rest is permissive to chan= ge (see below). SDP changes that aren't compatible either because they are in the "what MUS= T NOT be changed" list or in the (default) permissive list but not supporte= d by this browser must be reported as an error. That error must include an = error object that has an sdpLineNumber field. The ICE state machine in the draft is poorly labeled... need a better drawi= ng. There is a desire to merge the icegatheringchange event into the onicecandi= date event. Rename iceconnect state to iceconnected. Still open the be decided in media capture task force is what device enumer= ation we are allowed to do before and after user consent is received. Stats - Several alternatives were proposed, general consensus to use a java= script structure with some limited hierarchy vs. flat dictionary w/ string = keys encoding structure into the strings. Document the ICE stats as an exam= ple to test this. DTMF - Decided to wrap mediastream in a decorator using peerconnection to d= o the creation/wrapping (so it learns about the peerconnection), NOT add a = dtmf api on the peerconnection. Open issue - at receiver, do all audio streams that have DTMF in the SDP co= me out decorated as above or undecorated? Identity proposal was discussed - General opinion was that a hybrid approac= h ("# 4 =3D (1+3)") with peeridentity attribute is appropriate. Open issue = is how to distinguish between have and don't have identity cases. There was a desire to propose new names for onaddstream events and maybe ot= hers. Open issue: how does createOffer decide to offer a data channel - not resol= ved Still need to resolve bundle at the IETF. Still need to resolve media stream ID at the IETF. Need to specify what happens if ssrc is not provided or media stream ID is = not provided in received SDP. Is this an error? We need a way to set priority for each track/data channel (3 or 4 levels) *= and* have that enforced in the network subsystem of UA *and* optionally dif= fserv mark *and* get the diffserv markings back via an API (and include in = SDP?) createOffer, createAnswer, setLocalDescription, setRemoteDescription all ca= use callbacks. There is ambiguity created in the state machine if any of th= ese can be called while any other is in the process of acting. Queuing must= be implemented to ensure that execution of any of these is prevented until= the callback is delivered from the previous call to any of these. Rollback APIs must be added for both setLocalDescription(offer) and setRemo= teDescription(offer) in order to get back to the stable state from which th= e same or opposite might be called. Need to strengthen language to show that createOffer() is mandatory to call= because without createOffer() you cannot have some of the SDP that MUST be= provided to setLocalDescription() Desire to change the guarantee of how long createOffer() is guaranteed to h= ave its output accepted by setLocalDescription() from "in callback" to "15 = seconds" (or something similar to that) Discussion of changing the defaults for starting ICE from "all" to "none", = resolved to staying with "all" and adding contraints (see below). Decision to add a new constraint on RTCPeerConnection() to ask it to "prehe= at" a specified number of ICE candidate... the default constraint is 0. The= refore, this also clarifies than candidate gathering will not start at "new= RTCPeerConnection" and instead waits until the constraint is set OR some u= ndefined point in the future which still needs clarification (at createOffe= r or setLocalDescription, but neither is currently a good answer). Decision to merge the concept of constraints and settings to only have cons= traints. Constraints always replace previous constraints. (Some interpretat= ions were to set them to the intersection of request and previous.) getUserMedia() currently returns nothing, and has async callbacks on succe= ss or failure. This is a problem because the callee side of an RTCPeerConne= ction must either 1) not connect the camera immediately when a call is sign= aled, and thus respond with recvonly (and send the information to the calle= r necessary to have it pre-attached to the correct audio and video tags (be= cause the information required to populate the ssrc and msid and send a pro= vision answer doesn't exist), thus preventing playout at the caller even if= RTP packets were to be sent to it), or 2) pre-allocate the camera and/or m= icrophone while waiting for a call and tie up the resource. Proposed soluti= on is to change getUserMedia() to return a MediaStream immediately which is= a source of no sound and no video... if/when user consent is received this= is delivered as an event on that stream, likewise failure to gain consent = is an event on that stream. There was some discussion against the idea of r= eturning the MediaStream synchronously in favor of a callback delivering th= e "empty" MediaStream which was not resolved. -- end list -- Matthew Kaufman (and compiled with the assistance of Dan Burnett and Martin= Thomson) From matthew.kaufman@skype.net Fri Nov 2 11:31:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97341F0C6E for ; Fri, 2 Nov 2012 11:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgAvtrqsKDub for ; Fri, 2 Nov 2012 11:31:41 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6F01F0C6A for ; Fri, 2 Nov 2012 11:31:40 -0700 (PDT) Received: from BY2FFO11FD012.protection.gbl (10.1.15.200) by BY2FFO11HUB039.protection.gbl (10.1.14.122) with Microsoft SMTP Server (TLS) id 15.0.545.8; Fri, 2 Nov 2012 18:31:37 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Fri, 2 Nov 2012 18:31:37 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Fri, 2 Nov 2012 18:30:53 +0000 From: Matthew Kaufman To: "Dale R. Worley" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) Thread-Index: AQHNuRJLzVnrRqz+kEerz/qLVogJ7pfW3JiQ Date: Fri, 2 Nov 2012 18:30:52 +0000 Message-ID: References: <066.b5060d6f1c778a37ddaaeadfa120da84@trac.tools.ietf.org> (trac+rtcweb@grenache.tools.ietf.org) <201211021552.qA2Fq8l1207997@shell01.TheWorld.com> In-Reply-To: <201211021552.qA2Fq8l1207997@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: 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:(51704002)(377454001)(13464001)(54356001)(74662001)(44976002)(76482001)(47446002)(50466001)(53806001)(54316001)(46102001)(5343655001)(31966008)(16406001)(47776002)(47736001)(50986001)(48376001)(51856001)(74502001)(33656001)(49866001)(47976001)(4396001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06530126A4 Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2012 18:31:42 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Dale R. Worley > Sent: Friday, November 2, 2012 3:52 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) >=20 > > #3: JSEP-02 Review (from Andy Hutton) > > > > 6. Section 4.2. Session Descriptions and State Machine states: > > > > "Lastly, while the exact media parameters are only known only after a > > offer and an answer have been exchanged, it is possible for the > > offerer to receive media after they have sent an offer and before > > they have received an answer. To properly process incoming media in > > this case, the offerer's media handler must be aware of the details > > of the offerer before the answer arrives." > > > > I don't see the relevance of the statement "it is possible for the > > offerer to receive media after they have sent an offer and before > > they have received an answer". Why is the purpose of this statement? >=20 > Unless one is familiar with how offer/answer works in SIP, one might easi= ly > assume that media can only be sent after the offer/answer cycle is comple= te. And if one *is* familiar with how offer/answer works in SIP, one might easi= ly assume that media can be successfully received and played out by the off= ering side if the answering side were to send some before sending an answer= . An assumption which often holds in SIP but which I believe cannot hold in= RTCWEB. While you can create the unidirectional *sending* MediaStreams and= hook them up, there is no way for the receive MediaStreams to "pop out" of= the RTCPeerConnection prior to an answer (provisional or final) being rece= ived, and thus no way to "hook up" the video and audio tags in advance of t= hose RTP packets potentially arriving from the answering side. > > 14. Section 5.2.3 SessionDescriptionType > > > > ""pranswer" indicates that a description should be parsed as an > > answer, but not a final answer, and so should not result in the freein= g of > > allocated resources. It may result in the start of media transmissi= on, > > if the answer does not specify an inactive media direction". >=20 > Do we have any need for "pranswer"? Standard Answer #22 applies. Matthew Kaufman From tterriberry@mozilla.com Fri Nov 2 13:32:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C254521F9A30 for ; Fri, 2 Nov 2012 13:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 qYuHlnNejpnA for ; Fri, 2 Nov 2012 13:32:17 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 646B621F9A1E for ; Fri, 2 Nov 2012 13:32:17 -0700 (PDT) Received: from kizuka.merseine.nu (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 28D7EF20BA; Fri, 2 Nov 2012 13:32:16 -0700 (PDT) Received: by kizuka.merseine.nu (Postfix, from userid 81) id 8ACA975C02F; Fri, 2 Nov 2012 16:32:15 -0400 (EDT) Message-ID: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> Date: Fri, 02 Nov 2012 16:32:15 -0400 From: "Timothy B. Terriberry" To: "public-webrtc@w3.org" , "rtcweb@ietf.org" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) Subject: Re: [rtcweb] summary of issues raised at W3C 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: Fri, 02 Nov 2012 20:32:17 -0000 Matthew Kaufman wrote: > Open issue - at receiver, do all audio streams that have DTMF in the > SDP come out decorated as above or undecorated? I don't remember all the details of this discussion, but I'm not sure I understand this one. There is currently no W3C API for _receiving_ DTMF, and no use case driving one, so I don't know what you would decorate a remote stream you are receiving with. > We need a way to set priority for each track/data channel (3 or 4 > levels) *and* have that enforced in the network subsystem of UA > *and* optionally diffserv mark *and* get the diffserv markings back > via an API (and include in SDP?) To be clear, the DSCP is probably an IETF matter (and certainly including it in the SDP is). Enforcement in the UA's network subsystem might be, depending on how much of that rmcat needs to standardize. From pkyzivat@alum.mit.edu Fri Nov 2 13:37:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9321F9A58 for ; Fri, 2 Nov 2012 13:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.066, 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 II5O5o54-yx7 for ; Fri, 2 Nov 2012 13:37:27 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 6458221F9A37 for ; Fri, 2 Nov 2012 13:37:27 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id JgKm1k00J1ap0As59kdXuX; Fri, 02 Nov 2012 20:37:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id Jke21k00Z3ZTu2S3ike2zR; Fri, 02 Nov 2012 20:38:02 +0000 Message-ID: <50942F05.7050305@alum.mit.edu> Date: Fri, 02 Nov 2012 16:37:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 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] summary of issues raised at W3C meeting - Rollback X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2012 20:37:28 -0000 On 11/2/12 2:21 PM, Matthew Kaufman wrote: > Rollback APIs must be added for both setLocalDescription(offer) and setRemoteDescription(offer) in order to get back to the stable state from which the same or opposite might be called. Certainly there is a need to rollback. Conversely there should also be a need to commit. Assume a prior O/A was successful and corresponding media streams are in operation. Then an offer is generated with the intent to change this state. For example, assume the new offer adds one new media stream and drops one that is currently in use. From the time of the offer until it's known that the answer has been accepted, resources need to be assigned to both the old media stream and the new one. If the answer is successfully received, then the changes can be committed - which means that the resources associated with the dropped stream can be reclaimed. If there is an error, then there is need to do a rollback - which means that the resources associated with the stream that was being added can be reclaimed. What doesn't work (at least not well) is to assume at the time of the new offer that it will succeed, reclaiming resources from the stream being dropped. If that is done and then a rollback is needed, the resources would need to be reclaimed and reinitialized. There is no guarantee that they will be available, and even if they were this would cause all sorts of glitches. It might then also require ICE again, making more of a mess. Thanks, Paul From fluffy@cisco.com Fri Nov 2 13:43:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6B11E80D9 for ; Fri, 2 Nov 2012 13:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 GlG+3Y-JS6Op for ; Fri, 2 Nov 2012 13:43:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8B03321F8E56 for ; Fri, 2 Nov 2012 13:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=849; q=dns/txt; s=iport; t=1351889003; x=1353098603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FojSs2rt6LbETTAkbgFpVoSAIqrHZTz3/gu53maYM9A=; b=U/OHVWeoRK0cVKYfnymUbZkSAZve4B0fspt1+RrjU52nQQhfdaR1sKuU C+ALHlJxKK4BcF9NvbE2Ma5uu32PVA4/u8qr+wPklBwlNPqyKDqr3ygBv qhIc5OfsJO800bUhQ38uLVUUYl/AtYmyvB66+W2Mc+CBGq3AOhzUxWKvL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAMQvlFCtJV2c/2dsb2JhbABEhVC9c4EIgh4BAQEDARIBJz8FCwIBCBgKFBAyJQEBBA4FCBqHYgacA6AQjACFWmEDpFKBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138341801" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2012 20:43:23 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA2KhMnK010351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 20:43:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 15:43:22 -0500 From: "Cullen Jennings (fluffy)" To: "Timothy B. Terriberry" Thread-Topic: [rtcweb] summary of issues raised at W3C meeting Thread-Index: Ac25Jht82bllP8XRTkCijqp9bu7o/gAPPJuAAABjPoA= Date: Fri, 2 Nov 2012 20:43:21 +0000 Message-ID: References: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> In-Reply-To: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--32.816500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] summary of issues raised at W3C 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: Fri, 02 Nov 2012 20:43:24 -0000 On Nov 2, 2012, at 2:32 PM, "Timothy B. Terriberry" wrote: > Matthew Kaufman wrote: >> Open issue - at receiver, do all audio streams that have DTMF in the SD= P come out decorated as above or undecorated? >=20 > I don't remember all the details of this discussion, but I'm not sure I u= nderstand this one. There is currently no W3C API for _receiving_ DTMF, and= no use case driving one, so I don't know what you would decorate a remote = stream you are receiving with. Consider the case where a PSTN gateway calls a browser - or at least the br= owser gets an offer with the media stream that will later be used for DTMF.= The browser still wants to be able to send DTMF to the PSTN on that audio = track so seems you might need something to be able to do that.=20 From matthew.kaufman@skype.net Fri Nov 2 14:12:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714CA1F0C92 for ; Fri, 2 Nov 2012 14:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 pmROa4PH9uZQ for ; Fri, 2 Nov 2012 14:11:54 -0700 (PDT) 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 E97391F0C80 for ; Fri, 2 Nov 2012 14:11:53 -0700 (PDT) Received: from BY2FFO11FD007.protection.gbl (10.1.15.201) by BY2FFO11HUB006.protection.gbl (10.1.14.164) with Microsoft SMTP Server (TLS) id 15.0.545.8; Fri, 2 Nov 2012 21:11:50 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Fri, 2 Nov 2012 21:11:50 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 2 Nov 2012 21:11:21 +0000 From: Matthew Kaufman To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] summary of issues raised at W3C meeting - Rollback Thread-Index: AQHNuTnjhyGWEiVc/0qt4dyX4pRDc5fXCnRw Date: Fri, 2 Nov 2012 21:11:20 +0000 Message-ID: References: <50942F05.7050305@alum.mit.edu> In-Reply-To: <50942F05.7050305@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] 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:(377454001)(51704002)(24454001)(13464001)(479174001)(50986001)(47776002)(47446002)(46102001)(44976002)(48376001)(31966008)(53806001)(33656001)(16406001)(49866001)(76482001)(74502001)(50466001)(51856001)(54316001)(47976001)(4396001)(54356001)(47736001)(74662001)(5343655001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06530126A4 Subject: Re: [rtcweb] summary of issues raised at W3C meeting - Rollback X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2012 21:12:00 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, November 2, 2012 8:37 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] summary of issues raised at W3C meeting - Rollback >=20 > On 11/2/12 2:21 PM, Matthew Kaufman wrote: >=20 > > Rollback APIs must be added for both setLocalDescription(offer) and > setRemoteDescription(offer) in order to get back to the stable state from > which the same or opposite might be called. >=20 > Certainly there is a need to rollback. > Conversely there should also be a need to commit. Yes. >=20 > Assume a prior O/A was successful and corresponding media streams are in > operation. Then an offer is generated with the intent to change this stat= e. > For example, assume the new offer adds one new media stream and drops > one that is currently in use. >=20 > From the time of the offer until it's known that the answer has been > accepted, resources need to be assigned to both the old media stream and > the new one. If the answer is successfully received, then the changes can= be > committed - which means that the resources associated with the dropped > stream can be reclaimed. That's the difference between PRANSWER and ANSWER, I'm afraid. Standard comment #22 applies here as well. Matthew Kaufman From matthew.kaufman@skype.net Fri Nov 2 14:13:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE45E1F0C8C for ; Fri, 2 Nov 2012 14:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 is+s1ONJMlf9 for ; Fri, 2 Nov 2012 14:13:56 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id 169A11F0C80 for ; Fri, 2 Nov 2012 14:13:55 -0700 (PDT) Received: from BL2FFO11FD015.protection.gbl (10.173.161.201) by BL2FFO11HUB011.protection.gbl (10.173.161.117) with Microsoft SMTP Server (TLS) id 15.0.545.8; Fri, 2 Nov 2012 21:13:47 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Fri, 2 Nov 2012 21:13:47 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Fri, 2 Nov 2012 21:13:16 +0000 From: Matthew Kaufman To: "Timothy B. Terriberry" , "public-webrtc@w3.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] summary of issues raised at W3C meeting Thread-Index: Ac25Jht82bllP8XRTkCijqp9bu7o/gAEwmaAAAFf03A= Date: Fri, 2 Nov 2012 21:13:15 +0000 Message-ID: References: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> In-Reply-To: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] 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)(377454001)(13464001)(51704002)(31966008)(47976001)(33656001)(5343655001)(53806001)(74502001)(54316001)(16406001)(44976002)(47776002)(54356001)(47446002)(76482001)(74662001)(50466001)(4396001)(49866001)(46102001)(50986001)(5343645001)(47736001)(51856001)(48376001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06530126A4 Subject: Re: [rtcweb] summary of issues raised at W3C 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: Fri, 02 Nov 2012 21:13:56 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Timothy B. Terriberry > Sent: Friday, November 2, 2012 8:32 PM > To: public-webrtc@w3.org; rtcweb@ietf.org > Subject: Re: [rtcweb] summary of issues raised at W3C meeting >=20 > Matthew Kaufman wrote: > > Open issue - at receiver, do all audio streams that have DTMF in the > > SDP come out decorated as above or undecorated? >=20 > I don't remember all the details of this discussion, but I'm not sure I > understand this one. There is currently no W3C API for _receiving_ DTMF, > and no use case driving one, so I don't know what you would decorate a > remote stream you are receiving with. I think I was confusing MediaStream (unidirectional) with the RTP media str= eams (bidirectional). Of course in the future we might add receipt-of-DTMF too... I can think of = JavaScript apps I might want to do that in, using RTCWEB, outside of browse= rs. >=20 > > We need a way to set priority for each track/data channel (3 or 4 > > levels) *and* have that enforced in the network subsystem of UA > > *and* optionally diffserv mark *and* get the diffserv markings back > > via an API (and include in SDP?) >=20 > To be clear, the DSCP is probably an IETF matter (and certainly including= it in > the SDP is). Enforcement in the UA's network subsystem might be, > depending on how much of that rmcat needs to standardize. Exactly. Matthew Kaufman From matthew.kaufman@skype.net Fri Nov 2 14:17:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCB811E80D3 for ; Fri, 2 Nov 2012 14:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 HtGasqaULKjf for ; Fri, 2 Nov 2012 14:17:04 -0700 (PDT) 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 0F4F611E80D2 for ; Fri, 2 Nov 2012 14:17:03 -0700 (PDT) Received: from BL2FFO11FD016.protection.gbl (10.173.161.200) by BL2FFO11HUB013.protection.gbl (10.173.160.105) with Microsoft SMTP Server (TLS) id 15.0.545.8; Fri, 2 Nov 2012 21:17:00 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Fri, 2 Nov 2012 21:17:00 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 2 Nov 2012 21:16:35 +0000 From: Matthew Kaufman To: "Cullen Jennings (fluffy)" , "Timothy B. Terriberry" Thread-Topic: [rtcweb] summary of issues raised at W3C meeting Thread-Index: Ac25Jht82bllP8XRTkCijqp9bu7o/gAEwmaAAABjPoAAAQ3lMA== Date: Fri, 2 Nov 2012 21:16:34 +0000 Message-ID: References: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> 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.74] 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:(51704002)(74662001)(31966008)(74502001)(50466001)(54356001)(44976002)(4396001)(49866001)(76482001)(47446002)(33656001)(47736001)(50986001)(16406001)(47976001)(51856001)(48376001)(47776002)(54316001)(53806001)(46102001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06530126A4 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] summary of issues raised at W3C 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: Fri, 02 Nov 2012 21:17:04 -0000 Cullen Jennings (fluffy): >=20 > Consider the case where a PSTN gateway calls a browser - or at least the > browser gets an offer with the media stream that will later be used for > DTMF. The browser still wants to be able to send DTMF to the PSTN on that > audio track so seems you might need something to be able to do that. No, I think Tim's right... there's two audio tracks, and only the "outgoing= " one needs DTMF and that's not the one on the stream that "pops out" of th= e RTCPeerConnection. Of course this is also the other driver for getUserMedia allowing you to ge= t a null media stream... you might want to get a call from a device that ex= pects you to enter some DTMF but you don't have -- or want to provide conse= nt to -- a microphone. Matthew Kaufman From martin.thomson@gmail.com Fri Nov 2 14:50:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C581F0C7E for ; Fri, 2 Nov 2012 14:50:09 -0700 (PDT) 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=-1.750, 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 0ddeWiOs29PZ for ; Fri, 2 Nov 2012 14:50:08 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4054421F9ADF for ; Fri, 2 Nov 2012 14:50:08 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3165342lbo.31 for ; Fri, 02 Nov 2012 14:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vX9CzgERN+NBnqkjSuUv1qrJMNjczUANjA3NvO3Pn30=; b=mfEC8o36/WffvmnOuyLXMnp9gBgkdJ56MEeqNiWxJJd7/GUrFPZtlq+nMGSxhP+/Iv Nx15AJJ7iil0jFkDewvnr5ln4sjrK+nkyQpTlWI8+eBXKYGJonwgi4fNywixp03gMQk3 ceuHD2RQrUk8odvuf9JX7p/RypwGxtLYN3TjvjpANg3HXuA2i+tQRQPGaCob/Kqmuvta tosdvIRleXP08uHadvh81ADaVWNf3PX2vWQLNBS9Gg156dbKoSZDNgsNl+RO9A3PHj54 CmKad4DZr8O5t6CsmNZ8/9M8q/kZ315KOqbzMmXwVNd1+yzhVr6PrXuUsv57upbnzhyi fSBw== MIME-Version: 1.0 Received: by 10.152.108.66 with SMTP id hi2mr2843485lab.11.1351893007187; Fri, 02 Nov 2012 14:50:07 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Fri, 2 Nov 2012 14:50:07 -0700 (PDT) In-Reply-To: References: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> Date: Fri, 2 Nov 2012 21:50:07 +0000 Message-ID: From: Martin Thomson To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] summary of issues raised at W3C 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: Fri, 02 Nov 2012 21:50:09 -0000 On 2 November 2012 21:16, Matthew Kaufman wrote: > Of course this is also the other driver for getUserMedia allowing you to get a null media stream... you might want to get a call from a device that expects you to enter some DTMF but you don't have -- or want to provide consent to -- a microphone. We didn't work out how we would make a truly fake stream. In the synchronous proposal, any fakeness in the stream ends when the user permits or denies access to the input device. We should probably fix that. From martin.thomson@gmail.com Sat Nov 3 01:11:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16421F9C88 for ; Sat, 3 Nov 2012 01:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.766 X-Spam-Level: X-Spam-Status: No, score=-4.766 tagged_above=-999 required=5 tests=[AWL=-1.167, 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 xHe8AVEMRJNe for ; Sat, 3 Nov 2012 01:11:03 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7627121F9CB3 for ; Sat, 3 Nov 2012 01:11:02 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3316106lam.31 for ; Sat, 03 Nov 2012 01:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TXG3yUtSt2dk5b9qBh7gacWdAbGp8dKViDdiVGexH1Y=; b=Aobi7V1G3+Xb+kDuFQ+5hCwu7lokdvVKiJAQZu47FbyoxbPfXew5Yu4V/az0LwnTaY 0/NizJlyinO6DG71oPH4rYkYhN3lRt9XNciQGjwrkWx3Mxgo9pYaLAUES2czqixSnPVC ewN4nljPmuG08AEwaOUN3Qv6qvTRgFTFAAQ2+m+wiAgH/Z+Uy8O5Bes9SlOHHJMOZJ3v /mDtF56dsKNJP3Eq8pVWuXOAYY+2E4fz0nHmKwZWL9IXnDuZfiTupETrE0DkHnKp4s/1 /7QERvgQwOz6MWZAQW8OSgfiZg04cN83/wsdiI76gcs4z0SUbXE5nv6DKvUTsVM3PWcK ySAA== MIME-Version: 1.0 Received: by 10.112.102.132 with SMTP id fo4mr1615983lbb.111.1351930261274; Sat, 03 Nov 2012 01:11:01 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Sat, 3 Nov 2012 01:11:01 -0700 (PDT) Date: Sat, 3 Nov 2012 08:11:01 +0000 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] 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, 03 Nov 2012 08:11:05 -0000 The discussion in the Web RTC (or was it media capture?) meeting this week reached the following conclusion: For a given MediaStream instance, the MediaStreamTracks that are part of that MediaStream are synchronized for playback. This is the only synchronization guarantee. Inter-MediaStream synchronization is entirely at browser discretion. No guarantees are required between MediaStream instances, even for MediaStreams that are composed of exactly the same set of tracks. >From this, I also note that the "playback" guarantees necessarily apply to the application of RTP timestamps, such that it would be possible to ensure that the tracks could be successfully synchronized on a remote peer when they are extended over the network. However, this does not imply that the browser place the packets on the network at the same time. Though synchronizing packet construction would be a desirable property, this neither required nor sensible. Nor does it especially help given that different tracks might traverse the network in dramatically different ways (due to different network paths, different QoS treatment or other factors). A receiver is therefore required to pay attention to the timestamps and account for any skew that might have occurred. In practice, delaying any synchronization adjustment (i.e., buffering) until playback allows for less effort in the case where the MediaStream is immediately disassembled. A possible recommendation would be to have packets sent as soon as is practical with no particular regard to synchronization of transmission. Let the playback device provide any buffering necessary for synchronized playback. We can construct an example with tracks t1, t2 and media streams m1 (comprised of t1 and t2, denoted m1[t1] and m2[t2]) and m2 (comprised of m2[t1] and m2[t2]). In this example, playback of m1 causes m1[t1] and m1[t2] to be synchronized. It may naturally occur that when playing both m1 and m2, the tracks m1[t1] and m2[t1] also playback synchronized, but the browser is not required to ensure that this happens. This is made clearer when a third track is added to m2. Replacing m2[t1] with m2[t3] requires that the playback of m2 causes m2[t2] and m2[t3] to be synchronized. t3 could vastly different timing characteristics to t1 and t2, maybe it is a copy of t1 that has been sent through the network and has been returned with a significant delay. This results in a need for playback of m2 to be delayed until t2 and t3 are synchronized. The browser is required to buffer m2[t2] until its timing corresponds with m2[t3]; it is not required to synchronize m1[t2] and m2[t2]. Though t2 is part of the same MediaStream as t1 and t3, there is no transitive synchronization such that t1 and t3 become synchronized. It is the browsers choice entirely. Because the browser is not obliged to adhere to any particular latency constraints, it could choose to delay playback of m1 to align with m2 as a matter of optimization. This causes t1 and t3 to become synchronized if that suits the implementation constraints of the browser. It is conceivable that synchronizing playback of the two MediaStreams could - for example - allow the browser to share decoder resources for t2. This would result in t1 and t3 being synchronized, but that remains entirely an implementation choice. This would, on face value, seem to be fairly dire consequences for interoperability. Consider CNAME. A WebRTC-aware implementation is able to follow these rules and produce behavior consistent with the WebRTC source. The actual CNAMEs assigned to tracks as they traverse the network are not important as it pertains to WebRTC-aware receivers. An RTP implementation that follows specification will use CNAME to determine which RTP streams (aka WebRTC tracks, aka MediaStreamTrack instances) require synchronization. But even in the simple example given above, it is not clear how each RTP stream is assigned CNAME. The only two choices that seem viable are to have either just one CNAME for all RTP streams or one CNAME for each RTP stream. Had there been no "sharing" of tracks, each MediaStream could be given a different CNAME and everything would work out. As soon as sharing occurs, there is a choice: a) replicate the RTP stream so that the one CNAME per MediaStream guarantee is met b) consider breaking synchronization for peers that are not aware of WebRTC synchronization contexts (aka MediaStream) The former is safe, but wasteful, the latter has potential interoperability and user experience ramifications. Who makes this choice is another choice we need to make: a) we could decide and require browsers to implement one or other choice b) we could allow browsers to decide, with or without a recommendation c) we could require browser to allow applications to decide, with or without a default, where the default may be required, recommended or up to browsers to choose Furthermore, it is unclear how this synchronization extends to multiple inbound RTP streams on the same session. The implied design is one where MediaStreams are created as a result of receiving offers or answers. Offers and answers that contain the necessary msid markings can be used to pre-allocate MediaStreams and MediaStreamTrack instances based on the provided description. There are several potential failure modes in this design: the signaling may not provide the necessary markings (for instance, it might not be possible to know what SSRC will be chosen for a given track at the time that signaling is created), additional streams may arrive, streams could arrive prior to the necessary signaling, or streams could undergo an SSRC reassignment. In all these cases, streams are arriving that do not have known synchronization characteristics. In RTP, the expectation is that a sender report will arrive with CNAME information that enables the receiver to learn the synchronization properties of streams. Prior to this happening (which could be a very long time), the receiver is forced to play streams in a synchronized fashion. There are clearly several designs currently in mind for how this synchronization operates. It would seem that none of these are perfectly adequate. On the other hand, at the point where unsynchronized tracks are noticeable, it is also likely that the delay imposed by synchronization would be noticeable to the point of being worse. In the end, it may be that all this complexity doesn't turn out to be useful... --Martin From stefan.lk.hakansson@ericsson.com Sat Nov 3 06:54:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB921F982D for ; Sat, 3 Nov 2012 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bA6E95Xvxzy for ; Sat, 3 Nov 2012 06:54:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4577821F981A for ; Sat, 3 Nov 2012 06:54:31 -0700 (PDT) X-AuditID: c1b4fb30-b7f936d0000018b3-03-509522154f93 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9A.E9.06323.51225905; Sat, 3 Nov 2012 14:54:29 +0100 (CET) Received: from [153.88.5.10] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Sat, 3 Nov 2012 14:54:28 +0100 Message-ID: <50952214.4030409@ericsson.com> Date: Sat, 3 Nov 2012 14:54:28 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <066.b5060d6f1c778a37ddaaeadfa120da84@trac.tools.ietf.org> (trac+rtcweb@grenache.tools.ietf.org) <201211021552.qA2Fq8l1207997@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvja6Y0tQAg+1zuSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq4ljgXrBCsW7alpYGzg62Lk5JAQMJF4/vQkO4QtJnHh3nq2 LkYuDiGBk4wSD//MhXJWMEr82r+cDaSKV0Bb4tSDP6xdjBwcLAIqEh97WEHCbAKBEtf//2IC sUUFoiR+bD3LDlEuKHFy5hMWEFtEQFhi66tesBphAWuJJ7M7mCDmf2GU+NIzhxFkJqdAosSF UzkgNcwCthIX5lxngbDlJba/ncMMYgsJ6Eq8e32PdQKjwCwkK2YhaZmFpGUBI/MqRvbcxMyc 9HLzTYzAEDu45bfBDsZN98UOMUpzsCiJ8+qp7vcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wBhf3nKjbeHtSonAHaflPMRsjxduebXS8L3b87PL4rtdLaxKkxvm1u1jTWXhDpl6wKVY4PkJ 945JjX9XLmwv2nbmhnzw9D0lCpemrPzA5va77s8po23zLRZOK3xc9/POqXUV4pot/E1nXU4p 2L+bo6zGsVTOujsl4cjU5cubxEoaFmm6ij79kaLEUpyRaKjFXFScCABAsur2/wEAAA== Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2012 13:54:32 -0000 On 2012-11-02 19:30, Matthew Kaufman wrote: >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: >> Friday, November 2, 2012 3:52 PM To: rtcweb@ietf.org Subject: Re: >> [rtcweb] #3: JSEP-02 Review (from Andy Hutton) >> >>> #3: JSEP-02 Review (from Andy Hutton) >>> >>> 6. Section 4.2. Session Descriptions and State Machine states: >>> >>> "Lastly, while the exact media parameters are only known only >>> after a offer and an answer have been exchanged, it is possible >>> for the offerer to receive media after they have sent an offer >>> and before they have received an answer. To properly process >>> incoming media in this case, the offerer's media handler must be >>> aware of the details of the offerer before the answer arrives." >>> >>> I don't see the relevance of the statement "it is possible for >>> the offerer to receive media after they have sent an offer and >>> before they have received an answer". Why is the purpose of this >>> statement? >> >> Unless one is familiar with how offer/answer works in SIP, one >> might easily assume that media can only be sent after the >> offer/answer cycle is complete. > > And if one *is* familiar with how offer/answer works in SIP, one > might easily assume that media can be successfully received and > played out by the offering side if the answering side were to send > some before sending an answer. An assumption which often holds in SIP > but which I believe cannot hold in RTCWEB. While you can create the > unidirectional *sending* MediaStreams and hook them up, there is no > way for the receive MediaStreams to "pop out" of the > RTCPeerConnection prior to an answer (provisional or final) being > received, and thus no way to "hook up" the video and audio tags in > advance of those RTP packets potentially arriving from the answering > side. I have the same understanding. But I have also been told that the DTLS handshake cannot complete until the answer is provided to the offering side RTCPeerConnection, so the media could anyway not be decoded before the answer is available. I might have gotten this wrong though. From plh@w3.org Fri Nov 2 09:05:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1189221F8B2E for ; Fri, 2 Nov 2012 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxH8mqntTayq for ; Fri, 2 Nov 2012 09:05:17 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8F62221F878B for ; Fri, 2 Nov 2012 09:05:16 -0700 (PDT) Received: from [91.217.168.220] (helo=[172.19.31.3]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TUJkB-0002z1-IK; Fri, 02 Nov 2012 12:05:15 -0400 From: Philippe Le Hegaret To: rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Organization: World Wide Web Consortium Date: Fri, 02 Nov 2012 17:05:08 +0100 Message-ID: <1351872308.2346.635.camel@chacal> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 03 Nov 2012 08:23:32 -0700 Cc: Thomas Roessler , public-ietf-w3c@ietf.org, public-webrtc@w3.org Subject: [rtcweb] W3C's position on RTCWEB mandatory to implement video codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2012 16:05:18 -0000 We understand that the IETF rtcweb Working Group is expecting to select a mandatory-to-implement video codec. W3C believes that there should be a royalty-free standard web infrastructure which should include Real Time Communications on the Web. W3C is not expressing any preference among the codecs based on the technical merits of the proposals before the working group. We wish to bring a few background facts to participants' attention. In 2011 W3C approached MPEG-LA, the licensing authority for the generally-known patent pool for H.264, with a proposal for royalty-free licensing of the H.264 baseline codec, to be referenced for use by the HTML5 video tag. MPEG-LA was receptive to this proposal; however, the proposal was turned down by a narrow margin within the MPEG-LA membership. Whatever codec the rtcweb Working Group might choose, we encourage the Working Group to work toward technologies that implementers can be confident are available on a royalty-free basis and W3C is willing to work with the IETF in achieving this. Regards, For Tim Berners-Lee, Director, and Jeff Jaffe, CEO, Philippe Le Hégaret and Thomas Roessler, IETF Contacts for W3C From tlr@w3.org Fri Nov 2 09:59:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A342E21F8E08 for ; Fri, 2 Nov 2012 09:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msNuwyF7MFic for ; Fri, 2 Nov 2012 09:59:53 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id ACAAF21F8CF3 for ; Fri, 2 Nov 2012 09:59:47 -0700 (PDT) Received: from [91.217.168.220] (helo=[172.19.1.105]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1TUKax-0008VU-3u; Fri, 02 Nov 2012 12:59:47 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Roessler In-Reply-To: <1351872308.2346.635.camel@chacal> Date: Fri, 2 Nov 2012 17:59:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75485203-4F91-4C70-AD26-F6A8AFDD9AA1@w3.org> References: <1351872308.2346.635.camel@chacal> To: Philippe Le Hegaret X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sat, 03 Nov 2012 08:23:32 -0700 Cc: "public-ietf-w3c@w3.org" , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] W3C's position on RTCWEB mandatory to implement video codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2012 16:59:53 -0000 Redirecting to the correct address of the W3C/IETF coordination list. On 2012-11-02, at 17:05 +0100, Philippe Le Hegaret wrote: > We understand that the IETF rtcweb Working Group is expecting to = select > a mandatory-to-implement video codec. >=20 > W3C believes that there should be a royalty-free standard web > infrastructure which should include Real Time Communications on the = Web. >=20 > W3C is not expressing any preference among the codecs based on the > technical merits of the proposals before the working group. We wish to > bring a few background facts to participants' attention. >=20 > In 2011 W3C approached MPEG-LA, the licensing authority for the > generally-known patent pool for H.264, with a proposal for = royalty-free > licensing of the H.264 baseline codec, to be referenced for use by the > HTML5 video tag. MPEG-LA was receptive to this proposal; however, the > proposal was turned down by a narrow margin within the MPEG-LA > membership. >=20 > Whatever codec the rtcweb Working Group might choose, we encourage the > Working Group to work toward technologies that implementers can be > confident are available on a royalty-free basis and W3C is willing to > work with the IETF in achieving this. >=20 > Regards, >=20 > For Tim Berners-Lee, Director, and > Jeff Jaffe, CEO, > Philippe Le H=E9garet and Thomas Roessler, IETF Contacts for W3C >=20 >=20 >=20 From fluffy@cisco.com Sat Nov 3 08:55:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303D121F9C92 for ; Sat, 3 Nov 2012 08:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69+6nhJezimh for ; Sat, 3 Nov 2012 08:55:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B955521F9C91 for ; Sat, 3 Nov 2012 08:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=621; q=dns/txt; s=iport; t=1351958154; x=1353167754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tG2BbQ2EomoEpuuicSDaX1t9uMO87w2OIkt1/dKpnKA=; b=XUypA+oSBOt0MvdN+oJ1QyXp8e63i0A9hmT0qElPT7W4IBDUSUPpVI+Y vNS8A2un4TLWgZSS+upH8ZxV5KQD4BOlai5fHOtGSX8o7AxpGwU+DyjIW nRDPJ50+Me6joh8cnRCuzU+NAqYsYd9tUtbhHvEJnq+cqOL+0CxLUw8e5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAEk+lVCtJV2c/2dsb2JhbABEhVC9ZYEIgh4BAQEDAQEBAQ8BJzQLBQsCAQgiFBAhBgslAgQOBQgah1YDCQYLmWOVcQ2JUASLGWiFW2EDlCaNCIMmgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208";a="138441342" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 03 Nov 2012 15:55:46 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA3FtkBq020577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 15:55:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 10:55:46 -0500 From: "Cullen Jennings (fluffy)" To: Ted Hardie Thread-Topic: [rtcweb] Slides, please Thread-Index: AQHNuduvFAjlbatEfEig3CbQNSkrEg== Date: Sat, 3 Nov 2012 15:55:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--35.116100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Slides, please X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2012 15:55:55 -0000 mine will probably not be finished by monday night - sorry but back to back= W3C / IETF meetings does have some downside On Nov 2, 2012, at 10:23 AM, Ted Hardie wrote: > If you are presenting at the upcoming meeting, please send your slides > no later than Monday evening. We're once again being supported by the > Meetecho team (thanks!), and they need to be able to load our slides > into their system. >=20 > thanks, >=20 > Ted Hardie > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Sat Nov 3 15:08:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654E421F97C5 for ; Sat, 3 Nov 2012 15:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDLo-Nf5NJwQ for ; Sat, 3 Nov 2012 15:08:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C5B2621F976D for ; Sat, 3 Nov 2012 15:08:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73EBB39E13F for ; Sat, 3 Nov 2012 23:08:52 +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 mYKFgZmEGPpI for ; Sat, 3 Nov 2012 23:08:51 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:91e3:51d:16dc:b462] (unknown [IPv6:2001:470:de0a:27:91e3:51d:16dc:b462]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 81B8D39E0FA for ; Sat, 3 Nov 2012 23:08:51 +0100 (CET) Message-ID: <50959617.2000705@alvestrand.no> Date: Sat, 03 Nov 2012 23:09:27 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20121102163215.uipapngdw8000swc@kizuka.merseine.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] summary of issues raised at W3C 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: Sat, 03 Nov 2012 22:08:55 -0000 On 11/02/2012 10:50 PM, Martin Thomson wrote: > On 2 November 2012 21:16, Matthew Kaufman wrote: >> Of course this is also the other driver for getUserMedia allowing you to get a null media stream... you might want to get a call from a device that expects you to enter some DTMF but you don't have -- or want to provide consent to -- a microphone. > We didn't work out how we would make a truly fake stream. In the > synchronous proposal, any fakeness in the stream ends when the user > permits or denies access to the input device. We should probably fix > that. There's another proposal (not on the list so far) that proposes adding a constraint "source-type" and a constraint "source-id" for doing things like selecting a screengrab, a browser tab or other synthetic objects. Should we have a "source-type: synthetic" and a "source-id: silence"? The user shouldn't need to be prompted for that. Or is that too much magic? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Sat Nov 3 16:33:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45B121F9C7D for ; Sat, 3 Nov 2012 16:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.246 X-Spam-Level: X-Spam-Status: No, score=-4.246 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar2qbGkNcjZ9 for ; Sat, 3 Nov 2012 16:33:07 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20421F9B59 for ; Sat, 3 Nov 2012 16:32:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3625314lbo.31 for ; Sat, 03 Nov 2012 16:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=glllSgyMWu/M6MmO7gBBf2+/WBHpri91TsBNwRnSDZc=; b=A027JpMP5G9dr1Wc0V5m2+EJ5LiVd3x6gOXgHapJpR6gSc5w5gkz5N5qc/2I+Nwg8o 4vkQ2qRzHDNolKLMFszUSKTh75oC/PIKo1yFQbZK+WHGL0Et/89dRA9viXLHEK8pp3y9 hz95m2TsOwoHnkgdDenP6WiqbcTFCdkpY7UUiteH/Hfk4RgDrqgyYJQxIQkpw492vjVh xsw7CSyKR4R6r2TJtIsz+nSsFxCQPbuXLTx0C3/i6MzrPtQOXgRFOMqqPS2yRQgqti55 kqsch5h5pKNlmmOL1QweZjvqU5rRcwkMxmUEnNoucx3n32ck2Bl2cTdSH7KWxQMu8RQ7 6abw== MIME-Version: 1.0 Received: by 10.152.106.212 with SMTP id gw20mr5368719lab.8.1351985577976; Sat, 03 Nov 2012 16:32:57 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Sat, 3 Nov 2012 16:32:57 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Sat, 3 Nov 2012 16:32:57 -0700 (PDT) In-Reply-To: <50952214.4030409@ericsson.com> References: <066.b5060d6f1c778a37ddaaeadfa120da84@trac.tools.ietf.org> <201211021552.qA2Fq8l1207997@shell01.TheWorld.com> <50952214.4030409@ericsson.com> Date: Sat, 3 Nov 2012 23:32:57 +0000 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=f46d0420a6951de45f04cd9facf1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2012 23:33:07 -0000 --f46d0420a6951de45f04cd9facf1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Nov 3, 2012 9:54 AM, "Stefan H=C3=A5kansson LK" < stefan.lk.hakansson@ericsson.com> wrote: > > I have the same understanding. But I have also been told that the DTLS handshake cannot complete until the answer is provided to the offering side RTCPeerConnection, so the media could anyway not be decoded before the answer is available. I might have gotten this wrong though. That is correct. It is also true that candidate pair nomination cannot complete until the answer arrives too. The answer includes the ICE password. But that is just because ICE is back to front. Not a problem with security descriptions, though. Not does it require extra round trips. Pity that is can't do peer authentication. --f46d0420a6951de45f04cd9facf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 3, 2012 9:54 AM, "Stefan H=C3=A5kansson LK" <stefan.lk.hakansson@ericsson.com<= /a>> wrote:
>
> I have the same understanding. But I have also been told that the DTLS= handshake cannot complete until the answer is provided to the offering sid= e RTCPeerConnection, so the media could anyway not be decoded before the an= swer is available. I might have gotten this wrong though.

That is correct. It is also true that candidate pair nomination cannot c= omplete until the answer arrives too.=C2=A0 The answer includes the ICE pas= sword. But that is just because ICE is back to front.

Not a problem with security descriptions, though. Not does it require ex= tra round trips. Pity that is can't do peer authentication.

--f46d0420a6951de45f04cd9facf1-- From partha@parthasarathi.co.in Sun Nov 4 02:37:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120C921F86CB for ; Sun, 4 Nov 2012 02:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrigxKYbmjfL for ; Sun, 4 Nov 2012 02:37:29 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id 873EC21F86C0 for ; Sun, 4 Nov 2012 02:37:29 -0800 (PST) Received: from userPC (unknown [122.179.39.251]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 733331908123; Sun, 4 Nov 2012 10:37:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1352025449; bh=ddKCp4bH09HWpuoLfrjKID6UA+AUl7fT1GRHjdH4KrQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Wu+TvEDQ/KYYUC9ifN/WezoENQRYzOnthuQkyFHIwmZQO7SACNxUyvdK/050r8Rr0 kNBwNGKqT7pDku653LdNwCs3sl/HOWcM9crjL0fqLOanMaH/tASkKuUJfPYlKD2WnH F+rKbenajxC/wCIK4ZyVEhw97xA27gmFGMAIMmKc= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Bernard Aboba'" References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> <006401cdb6ca$e6102840$b23078c0$@co.in> <7594FB04B1934943A5C02806D1A2204B021AA4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B021AA4@ESESSMB209.ericsson.se> Date: Sun, 4 Nov 2012 16:07:21 +0530 Message-ID: <002901cdba78$634f0fa0$29ed2ee0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2yt7t/ZNifzsQLTfGdplUZjCzVaAAZJ5CAAK2UXaAAPZPxAP//+zoA///n8+D/+IgUoA== Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0203.50964569.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2012 10:37:30 -0000 Christer, I agree with you that cloning for serial SIP forking has to be discussed. Bernard, I'm talking about consensus of not to support SIP parallel forking in 13-Jun-2012 RTCweb interim meeting. Cloning was the proposed mechanism for SIP parallel forking. I try to find Jun-13 RTCWeb interim meeting minutes in RTCWeb archives but I have trouble in finding it. One of the relevant mail thread about SIP parallel forking consensus is discussed at http://www.ietf.org/mail-archive/web/rtcweb/current/msg04603.html. Thanks Partha -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, October 31, 2012 12:44 AM To: 'Bernard Aboba'; 'Parthasarathi R' Cc: rtcweb@ietf.org Subject: RE: [rtcweb] JSEP-02 Comments Hi, There has been discussions about using cloning for SERIAL forking, because it would solve some issues. Regards, Christer -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 30. lokakuuta 2012 20:47 To: 'Parthasarathi R'; Christer Holmberg Cc: rtcweb@ietf.org Subject: RE: [rtcweb] JSEP-02 Comments Partha said: "Christer, IIRC, cloning is removed as there is a consensus not to have parallel forking in one of the earlier interim meeting. Thanks Partha" [BA] Can you send a pointer to the consensus determination you are referring to? Also, I cannot find a consensus call on this subject sent to the RTCWEB mailing list. If in fact a consensus determination has been made (either in IETF or W3C), can someone send a pointer to it? From harald@alvestrand.no Sun Nov 4 11:48:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF26721F8783 for ; Sun, 4 Nov 2012 11:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.064 X-Spam-Level: X-Spam-Status: No, score=-110.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4c6Q1TNrLgF for ; Sun, 4 Nov 2012 11:48:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 361A021F84BA for ; Sun, 4 Nov 2012 11:48:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF88439E16F for ; Sun, 4 Nov 2012 20:48:41 +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 dqcClJy7scBw for ; Sun, 4 Nov 2012 20:48:40 +0100 (CET) Received: from [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1F49839E151 for ; Sun, 4 Nov 2012 20:48:38 +0100 (CET) Message-ID: <50966531.7010801@alvestrand.no> Date: Sun, 04 Nov 2012 13:53:05 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 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] 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, 04 Nov 2012 19:48:44 -0000 Thanks for the thorough analysis! I have been thinking about synchronization in a reasonably ad-hoc fashion; I want to ensure that we can support the following scenarios: - Audio and video for one source arrives in one MediaStream, over one PeerConnection. They are played out synchronized. - Multiple MediaStreams arrive, with very varying jitters, over the same PeerConnection. It should be possible to play out those streams that do not have much jitter without having their timebase disrupted by streams that need heavy dynamic adaptation because of jitter (varying-speed playback can sound quite odd at times). If there is no stream duplication, a sender can choose to do this in a backwards-compatible fashion by assigning one CNAME for each MediaStream. It will also achieve backwards compatibility by using one CNAME across all MediaStreams; this will not permit old gateways to break synchronization in the way that an RTCWEB browser is permitted to do (if we decide that such breaking is permissible). If we only want to send each MediaStreamTrack once, RTP doesn't allow more than one CNAME, so the sender that wants to be backwards compatible is faced with the choice of either sending it more than once (achieving compatibility by paying a bandwidth tax) or using the same CNAME for multiple MediaStreamTracks (achieving compatibility by imposing a synchronization requirement on the traditional RTP recipient). This is made somewhat more complex by the fact that making this decision when tracks get added to MediaStreams might be less than trivial; changing the CNAME of an RTP stream seems to be something that isn't exactly obvious how to do in RTP and SDP; it's obvious how to send the new name, but it's not obvious what the behaviour is intended to be when a name changes, or whether this imposes timing constraints between signalling and SR sending. Are there cases in current SDP/RTP usage when one changes a CNAME? On 11/03/2012 09:11 AM, Martin Thomson wrote: > The discussion in the Web RTC (or was it media capture?) meeting this > week reached the following conclusion: > > For a given MediaStream instance, the MediaStreamTracks that are part > of that MediaStream are synchronized for playback. This is the only > synchronization guarantee. Inter-MediaStream synchronization is > entirely at browser discretion. No guarantees are required between > MediaStream instances, even for MediaStreams that are composed of > exactly the same set of tracks. > > From this, I also note that the "playback" guarantees necessarily > apply to the application of RTP timestamps, such that it would be > possible to ensure that the tracks could be successfully synchronized > on a remote peer when they are extended over the network. However, > this does not imply that the browser place the packets on the network > at the same time. > > Though synchronizing packet construction would be a desirable > property, this neither required nor sensible. Nor does it especially > help given that different tracks might traverse the network in > dramatically different ways (due to different network paths, different > QoS treatment or other factors). A receiver is therefore required to > pay attention to the timestamps and account for any skew that might > have occurred. In practice, delaying any synchronization adjustment > (i.e., buffering) until playback allows for less effort in the case > where the MediaStream is immediately disassembled. > > A possible recommendation would be to have packets sent as soon as is > practical with no particular regard to synchronization of > transmission. Let the playback device provide any buffering necessary > for synchronized playback. > > We can construct an example with tracks t1, t2 and media streams m1 > (comprised of t1 and t2, denoted m1[t1] and m2[t2]) and m2 (comprised > of m2[t1] and m2[t2]). In this example, playback of m1 causes m1[t1] > and m1[t2] to be synchronized. It may naturally occur that when > playing both m1 and m2, the tracks m1[t1] and m2[t1] also playback > synchronized, but the browser is not required to ensure that this > happens. > > This is made clearer when a third track is added to m2. Replacing > m2[t1] with m2[t3] requires that the playback of m2 causes m2[t2] and > m2[t3] to be synchronized. t3 could vastly different timing > characteristics to t1 and t2, maybe it is a copy of t1 that has been > sent through the network and has been returned with a significant > delay. This results in a need for playback of m2 to be delayed until > t2 and t3 are synchronized. The browser is required to buffer m2[t2] > until its timing corresponds with m2[t3]; it is not required to > synchronize m1[t2] and m2[t2]. > > Though t2 is part of the same MediaStream as t1 and t3, there is no > transitive synchronization such that t1 and t3 become synchronized. > It is the browsers choice entirely. Because the browser is not > obliged to adhere to any particular latency constraints, it could > choose to delay playback of m1 to align with m2 as a matter of > optimization. This causes t1 and t3 to become synchronized if that > suits the implementation constraints of the browser. It is > conceivable that synchronizing playback of the two MediaStreams could > - for example - allow the browser to share decoder resources for t2. > This would result in t1 and t3 being synchronized, but that remains > entirely an implementation choice. > > This would, on face value, seem to be fairly dire consequences for > interoperability. Consider CNAME. A WebRTC-aware implementation is > able to follow these rules and produce behavior consistent with the > WebRTC source. The actual CNAMEs assigned to tracks as they traverse > the network are not important as it pertains to WebRTC-aware > receivers. > > An RTP implementation that follows specification will use CNAME to > determine which RTP streams (aka WebRTC tracks, aka MediaStreamTrack > instances) require synchronization. But even in the simple example > given above, it is not clear how each RTP stream is assigned CNAME. > The only two choices that seem viable are to have either just one > CNAME for all RTP streams or one CNAME for each RTP stream. Had there > been no "sharing" of tracks, each MediaStream could be given a > different CNAME and everything would work out. As soon as sharing > occurs, there is a choice: > a) replicate the RTP stream so that the one CNAME per MediaStream > guarantee is met > b) consider breaking synchronization for peers that are not aware > of WebRTC synchronization contexts (aka MediaStream) > The former is safe, but wasteful, the latter has potential > interoperability and user experience ramifications. > > Who makes this choice is another choice we need to make: > a) we could decide and require browsers to implement one or other choice > b) we could allow browsers to decide, with or without a recommendation > c) we could require browser to allow applications to decide, with > or without a default, where the default may be required, recommended > or up to browsers to choose > > Furthermore, it is unclear how this synchronization extends to > multiple inbound RTP streams on the same session. The implied design > is one where MediaStreams are created as a result of receiving offers > or answers. Offers and answers that contain the necessary msid > markings can be used to pre-allocate MediaStreams and MediaStreamTrack > instances based on the provided description. > > There are several potential failure modes in this design: the > signaling may not provide the necessary markings (for instance, it > might not be possible to know what SSRC will be chosen for a given > track at the time that signaling is created), additional streams may > arrive, streams could arrive prior to the necessary signaling, or > streams could undergo an SSRC reassignment. In all these cases, > streams are arriving that do not have known synchronization > characteristics. > > In RTP, the expectation is that a sender report will arrive with CNAME > information that enables the receiver to learn the synchronization > properties of streams. Prior to this happening (which could be a very > long time), the receiver is forced to play streams in a synchronized > fashion. > > There are clearly several designs currently in mind for how this > synchronization operates. It would seem that none of these are > perfectly adequate. > > On the other hand, at the point where unsynchronized tracks are > noticeable, it is also likely that the delay imposed by > synchronization would be noticeable to the point of being worse. In > the end, it may be that all this complexity doesn't turn out to be > useful... > > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Sun Nov 4 16:26:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0608E21F87F7 for ; Sun, 4 Nov 2012 16:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcLX3aZy8iBj for ; Sun, 4 Nov 2012 16:26:19 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CE51D21F87EC for ; Sun, 4 Nov 2012 16:26:18 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-5a-509707a7b8ca Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 12.0D.06323.7A707905; Mon, 5 Nov 2012 01:26:15 +0100 (CET) Received: from ESESSHC001.ericsson.se (153.88.183.21) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 5 Nov 2012 01:26:15 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 01:26:14 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP-02 and draft-nandakumar-rtcweb-sdp Thread-Index: Ac267Co4pGPlkQBISuWswTkOy+kFjA== Date: Mon, 5 Nov 2012 00:26:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B024D26@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B024D26ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje5y9ukBBpMPilms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD3LTzEXtIhVTJu2i72B8YBwFyMnh4SAicSW/0dYIGwxiQv3 1rN1MXJxCAmcZJSY2t7GCuHsYJR4/WYFM4SzmFFi5783TF2MHBxsAhYS3f+0QbpFBNQlLj+8 wA5iCwsYSGy+dZsdIm4q8fjrHVYIW0+ic9EMNhCbRUBFYmH/MjaQMbwC3hJtZ2tAwoxAR3w/ tYYJxGYWEJe49WQ+E8RxAhJL9pxnhrBFJV4+/scKYStKfHy1jxFkDLNAvsT5OU4gYV4BQYmT M5+A/SUkoC3RsngC+wRGkVlIps5C6JiFpAOiREdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRf xciem5iZk15uvokRGCMHt/w22MG46b7YIUZpDhYlcV491f3+QgLpiSWp2ampBalF8UWlOanF hxiZODilGhjVWhMZU5pavL4ft5SN9cj78i3yjXTb2gi1uob6PxwrdXqvHY65Xx0zr3BajGaJ 8qM5dpPnvkj88SiTXWudoqfB+/cizTaVex5smPan4fevnzrbmc9yJyfO/rRnjmiRIGNd5FeO OZ7XbJ+u3ikc2xyw1i34x/eglvb54Yc/v9Q/x275rE5h8VwlluKMREMt5qLiRABenKlVXwIA AA== Subject: [rtcweb] JSEP-02 and draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 00:26:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B024D26ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.1 of JESP-02 contains the following text: "Example SDP for RTCWeb call flows can be found in [I-D.nandakumar-rtcweb-s= dp]." AFAIK, this is another draft that has not been discussed it all. It also co= ntains Cullen's BUNDLE proposal, for which there is no agreement. I don't think the authors, in a WG document, should add new references with= out any prior WG discussions. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B024D26ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 <= /div>
Section 5.1 of JESP-0= 2 contains the following text:
 <= /div>
"Example SDP for= RTCWeb call flows can be found in [I-D.nandakumar-rtcweb-sdp]."
 <= /div>
AFAIK, this is anothe= r draft that has not been discussed it all. It also contains Cullen's BUNDL= E proposal, for which there is no agreement.
 <= /div>
I don't think the aut= hors, in a WG document, should add new references without any prior WG disc= ussions.
 <= /div>
Regards,
 <= /div>
Christer
 <= /div> --_000_7594FB04B1934943A5C02806D1A2204B024D26ESESSMB209ericsso_-- From nataraju.sip@gmail.com Sun Nov 4 20:19:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB7421F89CB for ; Sun, 4 Nov 2012 20:19:07 -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 26fStqT29nEJ for ; Sun, 4 Nov 2012 20:19:06 -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 AB4A221F89E6 for ; Sun, 4 Nov 2012 20:19:06 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6119347vbb.31 for ; Sun, 04 Nov 2012 20:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Hbjbsya5qNciev3jEw1QGQbrcqGeHs6Wcb1bVHmDcP0=; b=nL2hlvU/XRrzWPVBtFuTCIqv1exNfj80T+EDfZxzbEtVTPUFSnfnFwg9jf2iFcRYWP KF5YY62tbF3L4alAFm3HIjqve6VVwxyvUqPVPGmtjS67zon0ZPJgFrIKfj0Rjo6vdPrV dl9wF92AMJcCPelVdiOOfQ0YOUTVu10KWKO1EdUN8ySPMDmYRHoQ4iqlb3A2Jy993c/p 3yP+gSrYdpCs2Y0DUl4l6VIowRwxsZ8rmiq2P/Hr/pWFwb1eZ+K9OOrZXiHmRIekvpSF ZDPoZg3XhjSDnwprvhGNy8s1SRB8wCO8tXKZFxspeDDz4/6XcR4KMduevOm+sgBZBZlK HtfQ== MIME-Version: 1.0 Received: by 10.52.177.130 with SMTP id cq2mr7340071vdc.102.1352089146191; Sun, 04 Nov 2012 20:19:06 -0800 (PST) Received: by 10.58.151.136 with HTTP; Sun, 4 Nov 2012 20:19:06 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B024D26@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B024D26@ESESSMB209.ericsson.se> Date: Mon, 5 Nov 2012 09:49:06 +0530 Message-ID: From: "Nataraju A.B" To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=20cf3071cc5643712a04cdb7c90e Subject: [rtcweb] JSEP-02 and draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 04:19:07 -0000 --20cf3071cc5643712a04cdb7c90e Content-Type: text/plain; charset=ISO-8859-1 All, A minor editorial comment on the draft draft-nandakumar-rtcweb-sdp Table 1: 4.1 SDP Offer Table 2: 4.1 SDP Answer Table 3: 4.2 SDP Updated Offer w/DataChannel Drop Table 4: 4.2 SDP Updated Answer Table 5: 4.3 SDP Offer w/Bundle Table 6: 4.3 SDP Answer w/Bundle Table 7: 4.4 SDP Offer ...... In all these cases 4.x seems to be redundant / misleading. Please remove the same. A suggestion would be Table 4: SDP Updated Answer Table 5: SDP Offer w/Bundle Table 6: SDP Answer w/Bundle Table 7: SDP Offer ....... the same comment applicable for tables 1-14 Thanks, Nataraju A.B. --20cf3071cc5643712a04cdb7c90e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

A minor editorial comment on the draft=A0draft-nandakumar-rtcweb-sdp= 

Table 1: 4.1 SDP Offer
Table 2: 4.1 SDP Answer
Table 3: 4.2 SDP Updated Offer w/DataChannel Drop

=
Table 4: 4.2 SDP Updated Answer
=

Table 5: 4.3 SDP Offer w/Bundle


Table 6: 4.3 SDP Answer w/Bundle
Tabl=
e 7: 4.4 SDP Offer


......



In all these cases 4.x seems to be redundan=
t / misleading. Please remove the same.
A suggestion would be 
Table 4: SDP U=
pdated Answer


Table 5: SDP Offer w/Bundle
Table 6: =
SDP Answer w/Bundle


Table 7: SDP Offer .......



the same comment applicable for tables =
1-14

Thanks,
Nataraju A.B.
=
--20cf3071cc5643712a04cdb7c90e-- From stefan.lk.hakansson@ericsson.com Mon Nov 5 00:26:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DE321F8421 for ; Mon, 5 Nov 2012 00:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.228, 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 d+lEr9IXFpsJ for ; Mon, 5 Nov 2012 00:26:05 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 64CE021F841C for ; Mon, 5 Nov 2012 00:26:04 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-c2-5097781a47cd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F1.AF.06323.A1877905; Mon, 5 Nov 2012 09:26:02 +0100 (CET) Received: from [150.132.142.225] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 5 Nov 2012 09:26:02 +0100 Message-ID: <5097781A.8020504@ericsson.com> Date: Mon, 5 Nov 2012 09:26:02 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.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+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvja5UxfQAg+0bLSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtLHD1kKpjhXHL9xmqWBcZJZFyMnh4SAicSE+R9ZIWwxiQv3 1rN1MXJxCAmcZJR4uXcxWEJIYA2jxJwFhiA2r4C2xIdFzSwgNouAisSlf41MIDabgI3E2u4p YLaoQJjEmj2HmCDqBSVOznwCVi8iICyx9VUvWFxYQFVi/7SLLBDzAyQ+ftgOtJiDg1MgUGLv 8QKQMLOArcSFOddZIGx5ie1v5zBDlOtKvHt9j3UCo8AsJBtmIWmZhaRlASPzKkb23MTMnPRy 802MwCA7uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCo ePWYmcjf/4LLHmhd/LxoT1Wv0DxLWd4px36/+/3OlF152bV7mXMOR7zg8pmU+uPxz2mNphKa JmsTPGedf7y7soVTcuY1ueZdX6tbH71/5pZyf4frYcn7n2duzDjv8cx8ukZbX9kmD6/+mEDZ ebIh3Q/zvI+HVumf9dpuY9K3YuWttjb+0jlTlFiKMxINtZiLihMB0vLKbgACAAA= Subject: Re: [rtcweb] 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, 05 Nov 2012 08:26:06 -0000 Martin, thanks for this write up. I totally agree to that it makes most sense to send packets as soon as possible, and let the playback device handle synchronization. And perhaps we should change the notion of a MediaStream from being "play back synchronized" to something like "these tracks belong together", but leave it to the playback device (browser) to decide if it gives better user experience to play them synchronized, or (which is likely if one or more of the tracks have much larger latency than other track(s)) unsynchronized. Regarding CNAMEs, to me it seems natural that all MediaStreamTracks (RTP streams) originating from the same browser should have the same CNAME. The audio and video is presumable captured in the same location at the same time. This would enable, if the network latency is short, the playback device to synch them even for situations when not all tracks go in the same MediaStream (but capture the same scene). But MediaStreamTracks from other sources should have another CNAME. So, as example: assume you (for some reason) create a MediaStream containing MediaStreamTracks locally generated (by camera and mike) as well as MediaStreamTracks received from a PeerConnection. If this MediaStream is in turn sent over a PeerConnection, it seems most natural to me if the locally generated tracks have the same CNAME, and the forwared tracks have another (presumably the one given by the browser they origin from). Stefan On 11/03/2012 09:11 AM, Martin Thomson wrote: > The discussion in the Web RTC (or was it media capture?) meeting this > week reached the following conclusion: > > For a given MediaStream instance, the MediaStreamTracks that are part > of that MediaStream are synchronized for playback. This is the only > synchronization guarantee. Inter-MediaStream synchronization is > entirely at browser discretion. No guarantees are required between > MediaStream instances, even for MediaStreams that are composed of > exactly the same set of tracks. > > From this, I also note that the "playback" guarantees necessarily > apply to the application of RTP timestamps, such that it would be > possible to ensure that the tracks could be successfully synchronized > on a remote peer when they are extended over the network. However, > this does not imply that the browser place the packets on the network > at the same time. > > Though synchronizing packet construction would be a desirable > property, this neither required nor sensible. Nor does it especially > help given that different tracks might traverse the network in > dramatically different ways (due to different network paths, different > QoS treatment or other factors). A receiver is therefore required to > pay attention to the timestamps and account for any skew that might > have occurred. In practice, delaying any synchronization adjustment > (i.e., buffering) until playback allows for less effort in the case > where the MediaStream is immediately disassembled. > > A possible recommendation would be to have packets sent as soon as is > practical with no particular regard to synchronization of > transmission. Let the playback device provide any buffering necessary > for synchronized playback. > > We can construct an example with tracks t1, t2 and media streams m1 > (comprised of t1 and t2, denoted m1[t1] and m2[t2]) and m2 (comprised > of m2[t1] and m2[t2]). In this example, playback of m1 causes m1[t1] > and m1[t2] to be synchronized. It may naturally occur that when > playing both m1 and m2, the tracks m1[t1] and m2[t1] also playback > synchronized, but the browser is not required to ensure that this > happens. > > This is made clearer when a third track is added to m2. Replacing > m2[t1] with m2[t3] requires that the playback of m2 causes m2[t2] and > m2[t3] to be synchronized. t3 could vastly different timing > characteristics to t1 and t2, maybe it is a copy of t1 that has been > sent through the network and has been returned with a significant > delay. This results in a need for playback of m2 to be delayed until > t2 and t3 are synchronized. The browser is required to buffer m2[t2] > until its timing corresponds with m2[t3]; it is not required to > synchronize m1[t2] and m2[t2]. > > Though t2 is part of the same MediaStream as t1 and t3, there is no > transitive synchronization such that t1 and t3 become synchronized. > It is the browsers choice entirely. Because the browser is not > obliged to adhere to any particular latency constraints, it could > choose to delay playback of m1 to align with m2 as a matter of > optimization. This causes t1 and t3 to become synchronized if that > suits the implementation constraints of the browser. It is > conceivable that synchronizing playback of the two MediaStreams could > - for example - allow the browser to share decoder resources for t2. > This would result in t1 and t3 being synchronized, but that remains > entirely an implementation choice. > > This would, on face value, seem to be fairly dire consequences for > interoperability. Consider CNAME. A WebRTC-aware implementation is > able to follow these rules and produce behavior consistent with the > WebRTC source. The actual CNAMEs assigned to tracks as they traverse > the network are not important as it pertains to WebRTC-aware > receivers. > > An RTP implementation that follows specification will use CNAME to > determine which RTP streams (aka WebRTC tracks, aka MediaStreamTrack > instances) require synchronization. But even in the simple example > given above, it is not clear how each RTP stream is assigned CNAME. > The only two choices that seem viable are to have either just one > CNAME for all RTP streams or one CNAME for each RTP stream. Had there > been no "sharing" of tracks, each MediaStream could be given a > different CNAME and everything would work out. As soon as sharing > occurs, there is a choice: > a) replicate the RTP stream so that the one CNAME per MediaStream > guarantee is met > b) consider breaking synchronization for peers that are not aware > of WebRTC synchronization contexts (aka MediaStream) > The former is safe, but wasteful, the latter has potential > interoperability and user experience ramifications. > > Who makes this choice is another choice we need to make: > a) we could decide and require browsers to implement one or other choice > b) we could allow browsers to decide, with or without a recommendation > c) we could require browser to allow applications to decide, with > or without a default, where the default may be required, recommended > or up to browsers to choose > > Furthermore, it is unclear how this synchronization extends to > multiple inbound RTP streams on the same session. The implied design > is one where MediaStreams are created as a result of receiving offers > or answers. Offers and answers that contain the necessary msid > markings can be used to pre-allocate MediaStreams and MediaStreamTrack > instances based on the provided description. > > There are several potential failure modes in this design: the > signaling may not provide the necessary markings (for instance, it > might not be possible to know what SSRC will be chosen for a given > track at the time that signaling is created), additional streams may > arrive, streams could arrive prior to the necessary signaling, or > streams could undergo an SSRC reassignment. In all these cases, > streams are arriving that do not have known synchronization > characteristics. > > In RTP, the expectation is that a sender report will arrive with CNAME > information that enables the receiver to learn the synchronization > properties of streams. Prior to this happening (which could be a very > long time), the receiver is forced to play streams in a synchronized > fashion. > > There are clearly several designs currently in mind for how this > synchronization operates. It would seem that none of these are > perfectly adequate. > > On the other hand, at the point where unsynchronized tracks are > noticeable, it is also likely that the delay imposed by > synchronization would be noticeable to the point of being worse. In > the end, it may be that all this complexity doesn't turn out to be > useful... > > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Mon Nov 5 03:12:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEB921F855C for ; Mon, 5 Nov 2012 03:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.332 X-Spam-Level: X-Spam-Status: No, score=-110.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 2eo6-z19x7zX for ; Mon, 5 Nov 2012 03:12:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F360421F859B for ; Mon, 5 Nov 2012 03:12:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ABCE039E197 for ; Mon, 5 Nov 2012 12:12: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 yB9JouW2SUeo for ; Mon, 5 Nov 2012 12:12:38 +0100 (CET) Received: from [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 81D5E39E04C for ; Mon, 5 Nov 2012 12:12:38 +0100 (CET) Message-ID: <50979F24.70002@alvestrand.no> Date: Mon, 05 Nov 2012 12:12:36 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5097781A.8020504@ericsson.com> In-Reply-To: <5097781A.8020504@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] 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, 05 Nov 2012 11:12:41 -0000 On 11/05/2012 09:26 AM, Stefan Hakansson LK wrote: > Martin, > > thanks for this write up. > > I totally agree to that it makes most sense to send packets as soon as > possible, and let the playback device handle synchronization. > > And perhaps we should change the notion of a MediaStream from being > "play back synchronized" to something like "these tracks belong > together", but leave it to the playback device (browser) to decide if > it gives better user experience to play them synchronized, or (which > is likely if one or more of the tracks have much larger latency than > other track(s)) unsynchronized. If I were a stickler for precision, I think I'd claim that "synchronized" only means that "these streams come in with consistent timestamps", there's nobody going to whap you over the head with a wet noodle if you play them out unsynchronized. > > Regarding CNAMEs, to me it seems natural that all MediaStreamTracks > (RTP streams) originating from the same browser should have the same > CNAME. The audio and video is presumable captured in the same location > at the same time. This would enable, if the network latency is short, > the playback device to synch them even for situations when not all > tracks go in the same MediaStream (but capture the same scene). > > But MediaStreamTracks from other sources should have another CNAME. > > So, as example: assume you (for some reason) create a MediaStream > containing MediaStreamTracks locally generated (by camera and mike) as > well as MediaStreamTracks received from a PeerConnection. If this > MediaStream is in turn sent over a PeerConnection, it seems most > natural to me if the locally generated tracks have the same CNAME, and > the forwared tracks have another (presumably the one given by the > browser they origin from). An example of a real use case where this track arrangement might be natural is one where the remotely generated streams are of a politician giving a speech, and a locally added video channel gives interpretation in sign language.... those streams should not be allowed to drift in relation to each other, so it makes sense to claim that they're synchronized (and for the relaying node to make sure clock drift doesn't happen, by whatever means he can). But they don't have the same origin. From harald@alvestrand.no Mon Nov 5 03:17:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241C221F8592 for ; Mon, 5 Nov 2012 03:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.42 X-Spam-Level: X-Spam-Status: No, score=-110.42 tagged_above=-999 required=5 tests=[AWL=0.178, 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 G3PZZ7Yv9v57 for ; Mon, 5 Nov 2012 03:17:12 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4387D21F856E for ; Mon, 5 Nov 2012 03:17:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB71C39E197 for ; Mon, 5 Nov 2012 12:17:08 +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 EfA08gXuvmSS for ; Mon, 5 Nov 2012 12:17:07 +0100 (CET) Received: from [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8C6C539E04C for ; Mon, 5 Nov 2012 12:17:07 +0100 (CET) Message-ID: <5097A031.8060306@alvestrand.no> Date: Mon, 05 Nov 2012 12:17:05 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B024D26@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B024D26@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------050400060808000307020904" Subject: Re: [rtcweb] JSEP-02 and draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:17:13 -0000 This is a multi-part message in MIME format. --------------050400060808000307020904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/05/2012 01:26 AM, Christer Holmberg wrote: > Hi, > Section 5.1 of JESP-02 contains the following text: > "Example SDP for RTCWeb call flows can be found in > [I-D.nandakumar-rtcweb-sdp]." > AFAIK, this is another draft that has not been discussed it all. It > also contains Cullen's BUNDLE proposal, for which there is no agreement. There's actually no reference to any version of bundle, which is a pity, since it leaves it undefined. The example would have been more consistent if it had used TOGETHER, since it's using that mechanism. I hope this is clearer after today's MMUSIC meeting. > I don't think the authors, in a WG document, should add new references > without any prior WG discussions. Informative reference; I think this is a reasonable thing to do. It's faster to get them in and then to discuss. > Regards, > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050400060808000307020904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/05/2012 01:26 AM, Christer Holmberg wrote:
 
Hi,
 
Section 5.1 of JESP-02 contains the following text:
 
"Example SDP for RTCWeb call flows can be found in [I-D.nandakumar-rtcweb-sdp]."
 
AFAIK, this is another draft that has not been discussed it all. It also contains Cullen's BUNDLE proposal, for which there is no agreement.
There's actually no reference to any version of bundle, which is a pity, since it leaves it undefined.
The example would have been more consistent if it had used TOGETHER, since it's using that mechanism.
I hope this is clearer after today's MMUSIC meeting.
 
I don't think the authors, in a WG document, should add new references without any prior WG discussions.
Informative reference; I think this is a reasonable thing to do. It's faster to get them in and then to discuss.
--------------050400060808000307020904-- From martin.thomson@gmail.com Mon Nov 5 04:26:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FA421F85B3 for ; Mon, 5 Nov 2012 04:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[AWL=-0.654, 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 tTzJV+AfOHV8 for ; Mon, 5 Nov 2012 04:26:23 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B490921F85A3 for ; Mon, 5 Nov 2012 04:26:22 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so4353929lam.31 for ; Mon, 05 Nov 2012 04:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ywe+XiUA2/DDZdhY+tqgIIMimn4FKz6moleM630xK5E=; b=hb7WGpQzm5Nkq1ZoRpwn9VfaVyj43YTnWMWv3ZvlxnGvZSKcnar5SSiQVowYbUZIYI /oVZfYMvQAdjAi/+uQx9ZKLdhNP5EMx43eRmX5XGo2zeKkN0bcnVj8dKyHE6LXmBf6MS DgQax56cq42G07c/KUqragMSDLi1WFkwwqawntYxNavN27o85XNrXSNtVId2CyGNRN2r g5KYEL/eCbVmAN6FO4y1cdNVz8Xkjf1GabbHTTfm9ka5LTyzBhmJpDzigIcitFg26wsB AGpPff8t6lyUiZ7e5it4g3U44KmsMaJYVj7/vRFqDmPoCfpbbSrAHhEoaDMk63Ni/AW9 rpbQ== MIME-Version: 1.0 Received: by 10.112.28.169 with SMTP id c9mr3864954lbh.59.1352118381603; Mon, 05 Nov 2012 04:26:21 -0800 (PST) Received: by 10.112.83.2 with HTTP; Mon, 5 Nov 2012 04:26:21 -0800 (PST) In-Reply-To: <50979F24.70002@alvestrand.no> References: <5097781A.8020504@ericsson.com> <50979F24.70002@alvestrand.no> Date: Mon, 5 Nov 2012 12:26:21 +0000 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] 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, 05 Nov 2012 12:26:23 -0000 On 5 November 2012 11:12, Harald Alvestrand wrote: >> And perhaps we should change the notion of a MediaStream from being "play >> back synchronized" to something like "these tracks belong together", but >> leave it to the playback device (browser) to decide if it gives better user >> experience to play them synchronized, or (which is likely if one or more of >> the tracks have much larger latency than other track(s)) unsynchronized. > > If I were a stickler for precision, I think I'd claim that "synchronized" > only means that "these streams come in with consistent timestamps", there's > nobody going to whap you over the head with a wet noodle if you play them > out unsynchronized. Yes, user experience will be the most important consideration. Whatever that means for synchronization. Obviously, synchronization is desirable, but it needs to be balanced against a lot of other concerns. Bernard and I discussed this, as well as other scenarios where you have synthetic, blob-sourced and remote streams. In those cases, it might make sense to progress the clock consistently, but it is possible that true synchronization is nonsensical. > But they don't have the same origin. I'm not sure how that would be relevant. If you are talking about marking tracks for their source, that is true. Streams consisting of tracks from mixed sources would not come directly from RTCPeerConnection, they would be assembled locally. An authenticated RTCPeerConnection would not be able to provide a mix of authenticated an unauthenticated streams. That is, unless we add considerably more detail to identity assertions. From adam.bergkvist@ericsson.com Mon Nov 5 04:29:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839421F8711 for ; Mon, 5 Nov 2012 04:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 E4TWC3xYp6Ee for ; Mon, 5 Nov 2012 04:29:55 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BE9FC21F85CE for ; Mon, 5 Nov 2012 04:29:54 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-ac-5097b1418a12 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.F0.26143.141B7905; Mon, 5 Nov 2012 13:29:53 +0100 (CET) Received: from [150.132.141.93] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 5 Nov 2012 13:29:53 +0100 Message-ID: <5097B140.4050700@ericsson.com> Date: Mon, 5 Nov 2012 13:29:52 +0100 From: Adam Bergkvist User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Matthew Kaufman References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvja7jxukBBj8uWFpMmPuU1WLGrbMs Fr0flzBarP3Xzu7A4rFkyU8mj1sPJrF5HJ23nzWAOYrLJiU1J7MstUjfLoErY+rsH8wF69kr HrduZGxgfMnaxcjJISFgIvHx2jtGCFtM4sK99WwgtpDASUaJX9sUuhi5gOzVjBJnVj9kB0nw CmhLXPneCGazCKhI/PjxjAXEZhMwkpi05DrYIFGBKIlDGw9C1QtKnJz5BKxGREBfomfzdbDF zAJtjBJP5+WC2MICthKLfk9hhlicILHs9jywXk6BRIk5Ow6yQdTbSlyYc50FwpaX2P52DlS9 hsSu2X+ZJzAKzkKybhaSlllIWhYwMq9iZM9NzMxJLzfaxAgM2INbfqvuYLxzTuQQozQHi5I4 r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGDVXax7kTdiksFrl59Z0dp6eL5MkpWWZ bcxKOZR1nBRtCs5tOMWkFXRpE+MN9X+XbfeVt5z83OfHuShZwTOkyVvoSGOD94uFD/ecvXZY w7/xmHpJ+mztj0lmvKcyo2w9fjlVLX++USlp5tpetWMP91kZdLit4lxVEDY/ylLIJqnLNHab r7qUEktxRqKhFnNRcSIAvHEhuyYCAAA= Cc: Martin Thomson , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] summary of issues raised at W3C meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:29:56 -0000 On 2012-11-02 19:21, Matthew Kaufman wrote: > During the one and a half days of WEBRTC meeting and half day of > Media Capture Task Force meeting at this week's W3C TPAC, a large > number of issues came up, some of which were resolved. These fall > into several categories, such as issues for the W3C WG, for other W3C > WGs, for the IETF RTCWEB WG, other IETF WGs, and in some cases span > more than one. Rather than attempt to categorize each of these items, > I will simply list them below for 1) others present to expand upon > where I missed or mis-stated something and 2) others to categorize > appropriate and/or turn into action items (drafts, etc.) > > -- begin list -- [...] > Both streams and tracks need both "id" and "label" fields. "id" is > guaranteed to be unique and will be used as the "msid" in the SDP. > "label" is human-readable. If no-one objects, I'll go ahead and edit this into the specs. /Adam From stefan.lk.hakansson@ericsson.com Mon Nov 5 05:16:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8E21F86AE for ; Mon, 5 Nov 2012 05:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 kw4wimaFkgea for ; Mon, 5 Nov 2012 05:16:58 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DBB8521F86B3 for ; Mon, 5 Nov 2012 05:16:53 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-fb-5097bc44ec27 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FE.37.06323.44CB7905; Mon, 5 Nov 2012 14:16:53 +0100 (CET) Received: from [150.132.142.225] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 5 Nov 2012 14:16:52 +0100 Message-ID: <5097BC43.8000000@ericsson.com> Date: Mon, 5 Nov 2012 14:16:51 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5097781A.8020504@ericsson.com> <50979F24.70002@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvja7rnukBBucvM1us/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA+XVzIW/GCpOLaml6WB8T9zFyMnh4SAicTX06tZIWwxiQv3 1rN1MXJxCAmcZJR4vqmZEcJZwyjx5chPoCoODl4BbYlH89hBGlgEVCTmtH4Ca2YTsJFY2z2F CcQWFQiTWLPnEJjNKyAocXLmExYQW0RAWGLrq16wuLCAqsT+aRdZIOZfYZT4+OUZO8h8ToFA iR9dDiA1zAK2EhfmXGeBsOUltr+dA3a0kICuxLvX91gnMArMQrJiFpKWWUhaFjAyr2Jkz03M zEkvN9/ECAyzg1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MU45E1b2ef6nqnOqBHye/q1nt0NMzO+9qsZLFbOncFbZVPybwrv+8Pz3j/nzW7Wa7Tvf+ +83cYZNVFZQbe2WG0K6WhINvyncGs3ceMdp/KWrJYg/e9FXsD0r+fmuJFhN9IzvDyPXd+Q2P 2xM/7TE4bcpVp/H6E4fc1vDJmxK6+jhWndp5/kWThBJLcUaioRZzUXEiAKcVFqsBAgAA Subject: Re: [rtcweb] 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, 05 Nov 2012 13:16:58 -0000 On 11/05/2012 01:26 PM, Martin Thomson wrote: >> But they don't have the same origin. > > I'm not sure how that would be relevant. If you are talking about > marking tracks for their source, that is true. Streams consisting of > tracks from mixed sources would not come directly from > RTCPeerConnection, they would be assembled locally. At least if used without identity assertion, you can very well forward the locally assembled MediaStream over a RTCPeerConnection. Then I think that the tracks in that assembler MediaStream can have different origin, and they should use different CNAME in the transmission. From stefan.lk.hakansson@ericsson.com Mon Nov 5 05:46:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8221F8606 for ; Mon, 5 Nov 2012 05:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 zW4Z+euE7B4h for ; Mon, 5 Nov 2012 05:46:53 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 43C1D21F85F5 for ; Mon, 5 Nov 2012 05:46:53 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-28-5097c34ca05f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EF.CD.26143.C43C7905; Mon, 5 Nov 2012 14:46:52 +0100 (CET) Received: from [150.132.142.225] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Mon, 5 Nov 2012 14:46:52 +0100 Message-ID: <5097C34B.3010300@ericsson.com> Date: Mon, 5 Nov 2012 14:46:51 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5097B140.4050700@ericsson.com> In-Reply-To: <5097B140.4050700@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvja7P4ekBBqubxS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs65R5kK9nNWbP3fz9LAeIa9i5GDQ0LAROLlFK0uRk4gU0zi wr31bCC2kMBJRokdT3W7GLmA7DWMEm/3P2MFSfAKaEu07PrJDGKzCKhIXN15iQXEZhOwkVjb PYUJxBYVCJNYs+cQE0S9oMTJmU/AakQEhCW2vuoFiwsL2Eos+j2FGWJBA6NE14+VYEM5BXQk pm+cyA5iMwMVXZhznQXClpfY/nYOM8R1uhLvXt9jncAoMAvJjllIWmYhaVnAyLyKkT03MTMn vdxoEyMwzA5u+a26g/HOOZFDjNIcLErivNZb9/gLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YHRzXn9P02RyZDZ3yyk29RMaLOtuPGdRDTBStc7eaKGR2zXJny/e7KgvV5N4TkvUtZLoc74s f7IddnEyb8sSPs3o/yDr8EMb3RWvGNbrT+vxLlittPnJmkM1kwsUXTWsDrO6f33XEHBLM8+l wPmf99tQft9bdenGyzWmKJx7+nvB6sVSxgsKlViKMxINtZiLihMB7NbLxgECAAA= Subject: Re: [rtcweb] summary of issues raised at W3C meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:46:54 -0000 On 11/05/2012 01:29 PM, Adam Bergkvist wrote: > On 2012-11-02 19:21, Matthew Kaufman wrote: >> During the one and a half days of WEBRTC meeting and half day of >> Media Capture Task Force meeting at this week's W3C TPAC, a large >> number of issues came up, some of which were resolved. These fall >> into several categories, such as issues for the W3C WG, for other W3C >> WGs, for the IETF RTCWEB WG, other IETF WGs, and in some cases span >> more than one. Rather than attempt to categorize each of these items, >> I will simply list them below for 1) others present to expand upon >> where I missed or mis-stated something and 2) others to categorize >> appropriate and/or turn into action items (drafts, etc.) >> >> -- begin list -- > [...] >> Both streams and tracks need both "id" and "label" fields. "id" is >> guaranteed to be unique and will be used as the "msid" in the SDP. >> "label" is human-readable. > > If no-one objects, I'll go ahead and edit this into the specs. (Personal view): I think you can go ahead. Stefan > > /Adam > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Nov 5 06:03:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E086A21F8496 for ; Mon, 5 Nov 2012 06:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 ITuZ1FD9nfdR for ; Mon, 5 Nov 2012 06:03:03 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CC3B721F8714 for ; Mon, 5 Nov 2012 06:03:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DA4139E1AC; Mon, 5 Nov 2012 15:02:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in3DWmDyOXBP; Mon, 5 Nov 2012 15:02:55 +0100 (CET) Received: from [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2655E39E197; Mon, 5 Nov 2012 15:02:54 +0100 (CET) Message-ID: <5097C70D.9080208@alvestrand.no> Date: Mon, 05 Nov 2012 15:02:53 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Martin Thomson References: <5097781A.8020504@ericsson.com> <50979F24.70002@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] 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, 05 Nov 2012 14:03:04 -0000 On 11/05/2012 01:26 PM, Martin Thomson wrote: > On 5 November 2012 11:12, Harald Alvestrand wrote: >>> And perhaps we should change the notion of a MediaStream from being "play >>> back synchronized" to something like "these tracks belong together", but >>> leave it to the playback device (browser) to decide if it gives better user >>> experience to play them synchronized, or (which is likely if one or more of >>> the tracks have much larger latency than other track(s)) unsynchronized. >> If I were a stickler for precision, I think I'd claim that "synchronized" >> only means that "these streams come in with consistent timestamps", there's >> nobody going to whap you over the head with a wet noodle if you play them >> out unsynchronized. > Yes, user experience will be the most important consideration. > Whatever that means for synchronization. Obviously, synchronization > is desirable, but it needs to be balanced against a lot of other > concerns. > > Bernard and I discussed this, as well as other scenarios where you > have synthetic, blob-sourced and remote streams. In those cases, it > might make sense to progress the clock consistently, but it is > possible that true synchronization is nonsensical. > >> But they don't have the same origin. > I'm not sure how that would be relevant. If you are talking about > marking tracks for their source, that is true. Streams consisting of > tracks from mixed sources would not come directly from > RTCPeerConnection, they would be assembled locally. An authenticated > RTCPeerConnection would not be able to provide a mix of authenticated > an unauthenticated streams. That is, unless we add considerably more > detail to identity assertions. Or if the other end of the RTCPeerConnection is a mixer - it would then vouch for the identity of the streams it's providing as saying "these were definitely provided by me", but that wouldn't be proof of their original source. Whether anyone wants to do some action based on what the origin for the stream is a different question. From ted.ietf@gmail.com Mon Nov 5 06:12:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF37021F8715 for ; Mon, 5 Nov 2012 06:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 s1Ru0x7Sty7u for ; Mon, 5 Nov 2012 06:12:43 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7942021F87BC for ; Mon, 5 Nov 2012 06:12:43 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so6565917vcb.31 for ; Mon, 05 Nov 2012 06:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=L4ioZGG9em8oLsqJgALlOfwUNq7g9cjDFvjzCdnxeWI=; b=K+Ey6eFodzW9WjeHp+AMXIiD5a85he3Tzry6zjUr0NSZX3keyZdwV/QzctMVjJVKRf WL0oXRfL5F9ZIFSPXbGy/7cy97JJMtrJIQqNW6YSo2NeJn6o6CVGA5GZREOjVOmyGEIa jPbrbEjEspmcF4uaV1zgEghrgdJ1EE1DcRAmxn0pFcnRdzOTxWyL2fWq9CgabFA/NCeT 8OCWHSH9TUAmTo4b5CyKxhJg+lwRHrKA4WNytGFUFjEMpgW7RM0Zc6D0anRUyR3kjkdI DOqPhCnpYUFFOFXjXNjqqmbc/3BhqB7setSPyaPKMih7HQxQTOzSZO96FvUSsi7r8ZOn lCGw== MIME-Version: 1.0 Received: by 10.58.221.130 with SMTP id qe2mr9876109vec.14.1352124754839; Mon, 05 Nov 2012 06:12:34 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 5 Nov 2012 06:12:34 -0800 (PST) Date: Mon, 5 Nov 2012 06:12:34 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "Scott O. Bradner" Subject: [rtcweb] Agenda Change X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 14:12:48 -0000 In the draft agenda currently posted, there is a 10 minute slot on Thursday: IPR at the IETF ( 10 min ) - this is a reminder of IETF rules and guidelines around IPR Scott Bradner, who will be presenting this, is not able to attend Thursday, so it will shift to Wednesday. As a little bit more context, our charter currently has this language: The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Scott will describe what the "Note Well" and 2026 rules for disclosure mean in the context of this charter language. We are still hoping for some compaction of the Video Codec discussion on Thursday, so expect further agenda basing as the week goes on. regards, Ted Hardie From dbenham@cisco.com Mon Nov 5 08:38:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAE321F8846 for ; Mon, 5 Nov 2012 08:38:05 -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 iLIJrknmH-Sr for ; Mon, 5 Nov 2012 08:38:04 -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 68C8321F883E for ; Mon, 5 Nov 2012 08:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3518; q=dns/txt; s=iport; t=1352133484; x=1353343084; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Un7dD/Wcw+zwTR3MRIGO3vCepdua3jnxhCShY6xcJQk=; b=A5O8U0Yo2gtuXm+HseZ4bkJrSeqPGXAjqOqh3eRP0oG2HPdGuCu6N/5K hH68RUmJNs+aO1rGsqNpbL6D+ifC2bdsNct0Vxn8kKo4Hc2tsje6j3xu8 ojsX996xW4D0HwTu+XDGs3kBij9JVEkCABdIQybHu0xD2UIBuwPjRPfUh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFjql1CtJXG9/2dsb2JhbABEwzCBCIIeAQEBAwEBAQEPAQpREAsCAQgRBAEBCx0HJwsUCQgCBAESCAESB4diBgubCZ92jAGFW2EDiCWENYVvhE6NPYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="138988830" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 05 Nov 2012 16:38:04 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA5Gc3aR023325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 16:38:03 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 10:38:03 -0600 From: "David Benham (dbenham)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Incoming liaison statement from MPEG Thread-Index: AQHNsuNQzjknwsADnEqWTGe8sEFUv5fbf84Q Date: Mon, 5 Nov 2012 16:38:03 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC5150ACC9B@xmb-aln-x10.cisco.com> References: <0683D6CB32AC424D8AF52C0F660E5DC51509CFE0@xmb-aln-x10.cisco.com> <5088DB26.5020701@alvestrand.no> In-Reply-To: <5088DB26.5020701@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.14] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--32.285800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 16:38:05 -0000 > Apple deserves to be commended for making a royalty-free commitment, but = it's a lonely position. They do deserve such, however not that lonely. Cisco's declaration was s= ubmitted previously, but against the wrong numbers (admin error). Re-subm= ission is underway and will have the same, royalty-free commitment. =20 The more pronounced observation is that most declarations have not been not= submitted yet in this still relatively young effort. From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, October 24, 2012 11:25 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Incoming liaison statement from MPEG On 10/24/2012 10:58 PM, David Benham (dbenham) wrote: To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a non-= royalty bearing solution was mentioned in our draft below as a potential up= side to selecting H264/AVC constrained baseline profile today. Unfortunate= ly, the outcome will not be known soon enough, but to the extent future sur= prises weigh on our decision ... this one is positive! FWIW, there have been 11 IPR submissions into the ISO registry on MPEG-4 pa= rt 29 to date; 1 of them specifies that the IPR is available on a royalty f= ree basis, 10 do not. Unless I miscounted. Apple deserves to be commended for making a royalty-free commitment, but it= 's a lonely position. The registry of IPR submissions is available at http://www.iso.org/iso/stan= dards_development/patents http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00 6.4. Future IPR Status Consideration For additional informative purposes, the MPEG/IEC/ISO made a call for a royalty-free video coding solution for the Internet. As of its 98th meeting, two tracks forward are being pursued; one of which is based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is presently collecting patent licensing declarations that would include patent holder's royalty expectations unbundled from other higher profile mechanisms. Should this effort result in a royalty-free constrained baseline profile, this would benefit RTCweb in the future if H.264/AVC is selected as mandatory today. From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Wednesday, October 24, 2012 2:40 AM To: video-codec@ietf.org; rtcweb@ietf.org Subject: [rtcweb] Incoming liaison statement from MPEG Hi all, Please find attached an incoming liaison statement from MPEG. =A0It's short= , and therefore attached. =A0For those not familiar with MPEG's terminology= : "AVC" stands for "Advanced Video Codec" and is used in certain circles fo= r what other people know as H.264, and sometimes, depending on context, onl= y for the non-scalable and non-multiview profiles of H.264. =A0(H.264 is th= e ITU designation for the joint standard). =A0MPEG-4 part 29, or WebVC is, = as described in the statement, what most people know as "constrained baseli= ne H.264", i.e. H.264 baseline without the rarely used tools known as Arbit= rary Slice Order, Flexible Macroblock Order, and Redundant Slices. Also, in order to avoid possible confusion, let me emphasize that this liai= son statement comes from the standardization body known as MPEG (ISO/IEC JT= C1/SC29/WG11 ) and not from the licensing administrator known as MPEG-LA. Regards, Stephan _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From singer@apple.com Mon Nov 5 08:45:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7242821F8A09 for ; Mon, 5 Nov 2012 08:45:30 -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 0t-wUDtf24to for ; Mon, 5 Nov 2012 08:45:28 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id CC15B21F8A08 for ; Mon, 5 Nov 2012 08:45:28 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MD0009VNX7SV9B1@mail-out.apple.com> for rtcweb@ietf.org; Mon, 05 Nov 2012 08:45:28 -0800 (PST) X-AuditID: 11807112-b7f296d000001183-13-5097ed271165 Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 21.2A.04483.82DE7905; Mon, 05 Nov 2012 08:45:28 -0800 (PST) Received: from [17.78.213.99] by orrisroot.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MD000AK0X7MAY80@orrisroot.apple.com> for rtcweb@ietf.org; Mon, 05 Nov 2012 08:45:27 -0800 (PST) From: David Singer In-reply-to: <0683D6CB32AC424D8AF52C0F660E5DC5150ACC9B@xmb-aln-x10.cisco.com> Date: Mon, 05 Nov 2012 17:45:22 +0100 Message-id: <74322281-995C-491C-9A6C-6F46601D45BC@apple.com> References: <0683D6CB32AC424D8AF52C0F660E5DC51509CFE0@xmb-aln-x10.cisco.com> <5088DB26.5020701@alvestrand.no> <0683D6CB32AC424D8AF52C0F660E5DC5150ACC9B@xmb-aln-x10.cisco.com> To: Harald Alvestrand , "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1499) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FCcpavxdnqAwfWFLBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9rzBpaCXoWK78cWMjUw9kp1MXJySAiYSOyb1s8IYYtJXLi3 nq2LkYtDSGAmk8SiK2tZIJxWJomnm5vZQKqYBXQker9/Y+5i5ODgFdCTmLQ/CCQsLGAlcXn6 Z7ASNgFViQdzjoEN5RTwlVh15zgziM0CFP91+xgTxBhtiSfvLrCC2LwCNhKbX7UyQezqZpLo 29IKViQiECyx6vQfFojrZCVWTO1lmsDIPwvJGbMQzpiFZOwCRuZVjIJFqTmJlYbmeokFBTmp esn5uZsYwSFWKLSD8f4uvUOMAhyMSjy8M8SmBwixJpYVV+YeYpTgYFYS4eW4AxTiTUmsrEot yo8vKs1JLT7EKM3BoiTOe7EfKCWQnliSmp2aWpBaBJNl4uCUamA0cOrvm6Y/4WfbJG+9d13b FR02hd+LqDacYSeS5cXW1nHDz03/+CGpLzsm7pXeMrt0hn9K2YuUl3p/L0e1uRSvWh/Oxc1l 2MHboPTgYOeZ21m5qdX/DeKFVhxLslU9+rN/1ew05ml7ZJduiWFo/2LwpjGGZ69wj6vNBk7f 1RZWKltEzs3TFFNiKc5INNRiLipOBAC6j+yeLQIAAA== Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 16:45:30 -0000 On Nov 5, 2012, at 17:38 , "David Benham (dbenham)" wrote: >> Apple deserves to be commended for making a royalty-free commitment, but it's a lonely position. > > They do deserve such, however not that lonely. Cisco's declaration was submitted previously, but against the wrong numbers (admin error). Re-submission is underway and will have the same, royalty-free commitment. > > The more pronounced observation is that most declarations have not been not submitted yet in this still relatively young effort. Thanks Also, we are aware that some of the submissions were more nuanced, and the nuance is lost. For example, at least one was 'RAND, but will be RF if compatibility with AVC/H.264 is preserved'. Yes, MPEG is trying to get more details from the secretariat. > > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Wednesday, October 24, 2012 11:25 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Incoming liaison statement from MPEG > > On 10/24/2012 10:58 PM, David Benham (dbenham) wrote: > To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a non-royalty bearing solution was mentioned in our draft below as a potential upside to selecting H264/AVC constrained baseline profile today. Unfortunately, the outcome will not be known soon enough, but to the extent future surprises weigh on our decision ... this one is positive! > FWIW, there have been 11 IPR submissions into the ISO registry on MPEG-4 part 29 to date; 1 of them specifies that the IPR is available on a royalty free basis, 10 do not. Unless I miscounted. > > Apple deserves to be commended for making a royalty-free commitment, but it's a lonely position. > > The registry of IPR submissions is available at http://www.iso.org/iso/standards_development/patents > > > > > > > http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00 > 6.4. Future IPR Status Consideration > For additional informative purposes, the MPEG/IEC/ISO made a call for > a royalty-free video coding solution for the Internet. As of its > 98th meeting, two tracks forward are being pursued; one of which is > based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is > presently collecting patent licensing declarations that would include > patent holder's royalty expectations unbundled from other higher > profile mechanisms. Should this effort result in a royalty-free > constrained baseline profile, this would benefit RTCweb in the future > if H.264/AVC is selected as mandatory today. > > > > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Wednesday, October 24, 2012 2:40 AM > To: video-codec@ietf.org; rtcweb@ietf.org > Subject: [rtcweb] Incoming liaison statement from MPEG > > Hi all, > Please find attached an incoming liaison statement from MPEG. It's short, and therefore attached. For those not familiar with MPEG's terminology: "AVC" stands for "Advanced Video Codec" and is used in certain circles for what other people know as H.264, and sometimes, depending on context, only for the non-scalable and non-multiview profiles of H.264. (H.264 is the ITU designation for the joint standard). MPEG-4 part 29, or WebVC is, as described in the statement, what most people know as "constrained baseline H.264", i.e. H.264 baseline without the rarely used tools known as Arbitrary Slice Order, Flexible Macroblock Order, and Redundant Slices. > Also, in order to avoid possible confusion, let me emphasize that this liaison statement comes from the standardization body known as MPEG (ISO/IEC JTC1/SC29/WG11 ) and not from the licensing administrator known as MPEG-LA. > Regards, > Stephan > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > David Singer Multimedia and Software Standards, Apple Inc. From harald@alvestrand.no Mon Nov 5 12:48:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EEC21F84BA for ; Mon, 5 Nov 2012 12:48:27 -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 jT4FV9mGv418 for ; Mon, 5 Nov 2012 12:48:26 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EB06221F8496 for ; Mon, 5 Nov 2012 12:48:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90F8939E1AC for ; Mon, 5 Nov 2012 21:48:16 +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 XzmKcLS4axW9 for ; Mon, 5 Nov 2012 21:48:14 +0100 (CET) Received: from [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D70DA39E091 for ; Mon, 5 Nov 2012 21:48:13 +0100 (CET) Message-ID: <5098260C.8060606@alvestrand.no> Date: Mon, 05 Nov 2012 21:48:12 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------020704030708060502020407" Subject: [rtcweb] Measurement techniques, VP8 vs H.264 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 20:48:27 -0000 This is a multi-part message in MIME format. --------------020704030708060502020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adrian Grange, who's done the H.264 vs VP8 tests we've presented in our draft, asked me to forward this message so as to get it into your hands ASAP. His copy will follow as soon as the approvers approve. -- Begin Adrian's message -- I have made available the source clips, script files, compressed files and associated materials that were used to generate the VP8 vs H.264 comparison results included in our submission: draft-alvestrand-rtcweb-vp8-00 "VP8 as RTCWEB Mandatory to Implement" The notes below provide notes on how to access the materials and provide a first pointer on where to look for instructions on how to build the clips. In addition there are instructions on how to download the resulting compressed video files for both VP8 & H.264. ------------------------------------------------------------------------------ VP8 versus H264 Tests Produced for IETF85. The script files for the tests can be downloaded from: http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz It may be reflated using the command: tar -x --xz vp8_vs_h264.tar.xz Once deflated you will find a README.txt file explaining how to proceed. NOTE: The raw test video clips must also be downloaded before the tests are run and placed in a sub-directory named "video". These clips are a little over 2GB in total and may be individually downloaded using the following links: http://downloads.webmproject.org/ietf_tests/desktop_640_360_30.yuv.xz http://downloads.webmproject.org/ietf_tests/gipsrecmotion_1280_720_50.yuv.xz http://downloads.webmproject.org/ietf_tests/gipsrecstat_1280_720_50.yuv.xz http://downloads.webmproject.org/ietf_tests/kirland_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/macmarcomoving_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/macmarcostationary_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/niklas_1280_720_30.yuv.xz http://downloads.webmproject.org/ietf_tests/niklas_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/tacomanarrows_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/tacomasmallcameramovement_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/thaloundeskmtg_640_480_30.yuv.xz They must each be reflated using the command: xz -d .xz (The original .xz file is automatically deleted). Alternatively, the resulting compressed clips may be downloaded directly using the following link format: VP8: http://downloads.webmproject.org/ietf_tests/vp8_videos/ .webm H.264: http://downloads.webmproject.org/ietf_tests/vp8_videos/ .mkv where corresposnds to one of the file names in the links above, e.g. "desktop_640_360_30". If there are any problems please contact agrange@google.com --------------020704030708060502020407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adrian Grange, who's done the H.264 vs VP8 tests we've presented in our draft, asked me to forward this message so as to get it into your hands ASAP.
His copy will follow as soon as the approvers approve.

-- Begin Adrian's message --

I have made available the source clips, script files, compressed files and associated
materials that were used to generate the VP8 vs H.264 comparison results included
in our submission:
draft-alvestrand-rtcweb-vp8-00 "VP8 as RTCWEB Mandatory to Implement"

The notes below provide notes on how to access the materials and provide a first
pointer on where to look for instructions on how to build the clips.

In addition there are instructions on how to download the resulting compressed
video files for both VP8 & H.264.

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

VP8 versus H264 Tests

Produced for IETF85.

The script files for the tests can be downloaded from:

It may be reflated using the command:
tar -x --xz vp8_vs_h264.tar.xz

Once deflated you will find a README.txt file explaining how to proceed.

NOTE: The raw test video clips must also be downloaded before the tests
are run and placed in a sub-directory named "video". These clips are a little
over 2GB in total and  may be individually downloaded using the following links:


They must each be reflated using the command:
xz -d <filename>.xz
(The original .xz file is automatically deleted).

Alternatively, the resulting compressed clips may be downloaded directly using the
following link format:

VP8:

H.264:

where <video_name> corresposnds to one of the file names in the links above,
e.g. "desktop_640_360_30".

If there are any problems please contact agrange@google.com


--------------020704030708060502020407-- From agrange@google.com Mon Nov 5 11:08:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599D821F8488 for ; Mon, 5 Nov 2012 11:08:25 -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 nVlOwpmNI5UJ for ; Mon, 5 Nov 2012 11:08:24 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B886A21F8A78 for ; Mon, 5 Nov 2012 11:08:23 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so495766qaa.10 for ; Mon, 05 Nov 2012 11:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=yZffuxv2LCQqhAehL3H3oVh8eS81DhoryHMLqaS2WYc=; b=ogyj2UYEUHJ6ouXDN29ANc5yTr3h4y+Zw4m27uqNVZYcO5l+HzT0MMZp8S97m402yi 2BmX7CeYp1QVT7LKUQ1LRFEoVrUFEK/oEf6rbp2Z2x8DETooskjIkpSGUa7IYqO//nCQ mk6oPGLts2PnKLu0UACsx5NH/RNKMXh1GrzAN8rlrN/g0QKqEpir5FXEUAjXRPBYCy5i X57l9JiVgzx2J+zW6G9g2JNgCUOkhJk+QKoImHpfNodkDQliY48gmpH2ceqwXRV3vSbB BQAgjGWueutjzMvCWspCSuVEQkDorTpD9l068RGYTZ3kfc1auyRB5Pjs2YhFFPzY/x/Y 1gLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=yZffuxv2LCQqhAehL3H3oVh8eS81DhoryHMLqaS2WYc=; b=BNsS/WDgMkwjbBEZqCoOHNpQTrjheAr/KXx/UHZdToLJPZVms87u5p1Afv3hCv+Rz1 9MD9dxDvUuO3JXpInmTmTFf4A6Y5suU9xHpbrVZ5NEjxLZdKgBteEEVAs774VqwgrDES 3pY43uDFL97MU2LOjtKrStOdbVyq4DKAS9NBkqh5iRwe0PDmLopXq70QqU40C3jv9ofx +JIWMsjlMxkNvRwomtYkcwfuULfsfVB7nmBk7njwIfl7yl2tWJiQmPO+kH7ZvPr2EJsp 1eXMzkLGu+xiRczxA7iJgY7bBifTBZdczWRjJppYBjypxyXZ38K+4xCbPM1UsdXAUXfm Zkrg== MIME-Version: 1.0 Received: by 10.229.115.38 with SMTP id g38mr3910014qcq.142.1352142502823; Mon, 05 Nov 2012 11:08:22 -0800 (PST) Received: by 10.229.186.19 with HTTP; Mon, 5 Nov 2012 11:08:22 -0800 (PST) Date: Mon, 5 Nov 2012 14:08:22 -0500 Message-ID: From: Adrian Grange To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=00235447026891090604cdc43510 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnddL6LUEVyJffCM9NPzHaM8xGhwTFXKG2hSXX7r8E7XS0VWoA7GcOvf7+OitUpx41xI0PipNmugJ7MnMRLCv26NphVLodFfFGyQdGpfjfV120FfIfmBiRKHfVsHimdHWKx8UayvwLPabPY5GV6GZGVzN+L/C72U0ohA7S/67dZDAvC9u9AclflojRipAabAE989oEe X-Mailman-Approved-At: Mon, 05 Nov 2012 13:50:34 -0800 Subject: [rtcweb] VP8 vs H.264 Comparison data sources X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 19:08:25 -0000 --00235447026891090604cdc43510 Content-Type: text/plain; charset=ISO-8859-1 I have made available the source clips, script files, compressed files and associated materials that were used to generate the VP8 vs H.264 comparison results included in our submission: draft-alvestrand-rtcweb-vp8-00 "VP8 as RTCWEB Mandatory to Implement" The notes below provide notes on how to access the materials and provide a first pointer on where to look for instructions on how to build the clips. In addition there are instructions on how to download the resulting compressed video files for both VP8 & H.264. ------------------------------------------------------------------------------ VP8 versus H264 Tests Produced for IETF85. The script files for the tests can be downloaded from: http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz It may be reflated using the command: tar -x --xz vp8_vs_h264.tar.xz Once deflated you will find a README.txt file explaining how to proceed. NOTE: The raw test video clips must also be downloaded before the tests are run and placed in a sub-directory named "video". These clips are a little over 2GB in total and may be individually downloaded using the following links: http://downloads.webmproject.org/ietf_tests/desktop_640_360_30.yuv.xz http://downloads.webmproject.org/ietf_tests/gipsrecmotion_1280_720_50.yuv.xz http://downloads.webmproject.org/ietf_tests/gipsrecstat_1280_720_50.yuv.xz http://downloads.webmproject.org/ietf_tests/kirland_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/macmarcomoving_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/macmarcostationary_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/niklas_1280_720_30.yuv.xz http://downloads.webmproject.org/ietf_tests/niklas_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/tacomanarrows_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/tacomasmallcameramovement_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/thaloundeskmtg_640_480_30.yuv.xz They must each be reflated using the command: xz -d .xz (The original .xz file is automatically deleted). Alternatively, the resulting compressed clips may be downloaded directly using the following link format: VP8: http://downloads.webmproject.org/ietf_tests/vp8_videos/.webm H.264: http://downloads.webmproject.org/ietf_tests/vp8_videos/.mkv where corresposnds to one of the file names in the links above, e.g. "desktop_640_360_30". If there are any problems please contact agrange@google.com Adrian Grange Chrome Media Group, Google. --00235447026891090604cdc43510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div>I have made available the source clips, script files, compressed files = and associated
materials that were used to generate the VP8 vs H.= 264 comparison results included
in our submission:
draft-alvestrand-rtcweb-vp8-00=A0&qu= ot;VP8 as RTCWEB Mandatory to Implement"

The notes below provide notes on how to access the materials and provide = a first
 
Regards,
 
Christer
 
 

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
pointer on=A0where to look for instructions on how to build the clips.=

In addition there are instructions on how to down= load the resulting compressed
video files for both VP8 & H.26= 4.

-------------------------------------------------------= -----------------------

VP8 versus H264 Tests

Produced for IETF85.

The scri= pt files for the tests can be downloaded from:
http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz

It may be reflated using the command:
tar -= x --xz vp8_vs_h264.tar.xz

Once deflated you will find a README.txt file explainin= g how to proceed.

NOTE: The raw test video clips m= ust also be downloaded before the tests
are run and placed in a s= ub-directory named "video". These clips are a little
over 2GB in total and =A0may be individually downloaded using the foll= owing links:

http://downloads.= webmproject.org/ietf_tests/tacomasmallcameramovement_640_480_30.yuv.xz<= /div>

They must each be reflate= d using the command:
xz -d <filename>.xz
(The original .xz file is automati= cally deleted).

Alternatively, the resulting compr= essed clips may be downloaded directly using the
following link f= ormat:

VP8:

H.264:

where <video_name> corresposnds to one = of the file names in the links above,
e.g. "desktop_640_360_30".

If there= are any problems please contact agra= nge@google.com

Adrian Grange
Chrome = Media Group, Google.

--00235447026891090604cdc43510-- From stewe@stewe.org Mon Nov 5 13:51:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07A711E8099 for ; Mon, 5 Nov 2012 13:51:38 -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 k8UGS3FSZvSW for ; Mon, 5 Nov 2012 13:51:37 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4579321F881E for ; Mon, 5 Nov 2012 13:51:37 -0800 (PST) Received: from mail4-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 21:51:36 +0000 Received: from mail4-db3 (localhost [127.0.0.1]) by mail4-db3-R.bigfish.com (Postfix) with ESMTP id EFF67C00E6; Mon, 5 Nov 2012 21:51:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I1432I14ffIb7mzz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail4-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail4-db3 (localhost.localdomain [127.0.0.1]) by mail4-db3 (MessageSwitch) id 1352152293828073_10578; Mon, 5 Nov 2012 21:51:33 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.254]) by mail4-db3.bigfish.com (Postfix) with ESMTP id C3C75A0061; Mon, 5 Nov 2012 21:51:33 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 21:51:33 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.122]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0233.002; Mon, 5 Nov 2012 21:51:28 +0000 From: Stephan Wenger To: David Singer , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Incoming liaison statement from MPEG Thread-Index: AQHNscuQrKWwUbiVwUGukf/J2FnY8pfI8Q6AgACeLACAEfUIgIAAAgsAgAABsAA= Date: Mon, 5 Nov 2012 21:51:27 +0000 Message-ID: In-Reply-To: <74322281-995C-491C-9A6C-6F46601D45BC@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DEC446EC03D804D9E5CF58CD88A926B@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 21:51:38 -0000 On 11.5.2012 11:45 , "David Singer" wrote: > >On Nov 5, 2012, at 17:38 , "David Benham (dbenham)" >wrote: > >>> Apple deserves to be commended for making a royalty-free commitment, >>>but it's a lonely position. >>=20 >> They do deserve such, however not that lonely. Cisco's declaration >>was submitted previously, but against the wrong numbers (admin error). >>Re-submission is underway and will have the same, royalty-free >>commitment. =20 >>=20 >> The more pronounced observation is that most declarations have not been >>not submitted yet in this still relatively young effort. > >Thanks > >Also, we are aware that some of the submissions were more nuanced, and >the nuance is lost. For example, at least one was 'RAND, but will be RF >if compatibility with AVC/H.264 is preserved'. To put this in context, ISO's patent policy (which is the same as the ITU's) does not allow free-format declarations (like the IETF) where one could express such nuances. Instead, it has a fixed format for patent right declarations. A declarer can either check RAND, or RAND-Z (both with an additional checkbox requiring reciprocity). No deviations are allowed. =20 > >Yes, MPEG is trying to get more details from the secretariat. There are many ways to communicate support for a business model, and I'm sure that MPEG will find one. The official ISO declaration process is not one of them. According to that process, at this point, it's still 11:1 (or 11:2, given David Benham's comment) for RAND. Stephan > >>=20 >>=20 >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Wednesday, October 24, 2012 11:25 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Incoming liaison statement from MPEG >>=20 >> On 10/24/2012 10:58 PM, David Benham (dbenham) wrote: >> To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a >>non-royalty bearing solution was mentioned in our draft below as a >>potential upside to selecting H264/AVC constrained baseline profile >>today. Unfortunately, the outcome will not be known soon enough, but to >>the extent future surprises weigh on our decision ... this one is >>positive! >> FWIW, there have been 11 IPR submissions into the ISO registry on >>MPEG-4 part 29 to date; 1 of them specifies that the IPR is available on >>a royalty free basis, 10 do not. Unless I miscounted. >>=20 >> Apple deserves to be commended for making a royalty-free commitment, >>but it's a lonely position. >>=20 >> The registry of IPR submissions is available at >>http://www.iso.org/iso/standards_development/patents >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00 >> 6.4. Future IPR Status Consideration >> For additional informative purposes, the MPEG/IEC/ISO made a call for >> a royalty-free video coding solution for the Internet. As of its >> 98th meeting, two tracks forward are being pursued; one of which is >> based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is >> presently collecting patent licensing declarations that would include >> patent holder's royalty expectations unbundled from other higher >> profile mechanisms. Should this effort result in a royalty-free >> constrained baseline profile, this would benefit RTCweb in the future >> if H.264/AVC is selected as mandatory today. >>=20 >>=20 >>=20 >> From: Stephan Wenger [mailto:stewe@stewe.org] >> Sent: Wednesday, October 24, 2012 2:40 AM >> To: video-codec@ietf.org; rtcweb@ietf.org >> Subject: [rtcweb] Incoming liaison statement from MPEG >>=20 >> Hi all, >> Please find attached an incoming liaison statement from MPEG. It's >>short, and therefore attached. For those not familiar with MPEG's >>terminology: "AVC" stands for "Advanced Video Codec" and is used in >>certain circles for what other people know as H.264, and sometimes, >>depending on context, only for the non-scalable and non-multiview >>profiles of H.264. (H.264 is the ITU designation for the joint >>standard). MPEG-4 part 29, or WebVC is, as described in the statement, >>what most people know as "constrained baseline H.264", i.e. H.264 >>baseline without the rarely used tools known as Arbitrary Slice Order, >>Flexible Macroblock Order, and Redundant Slices. >> Also, in order to avoid possible confusion, let me emphasize that this >>liaison statement comes from the standardization body known as MPEG >>(ISO/IEC JTC1/SC29/WG11 ) and not from the licensing administrator known >>as MPEG-LA. >> Regards, >> Stephan >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 > >David Singer >Multimedia and Software Standards, Apple Inc. > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From stewe@stewe.org Mon Nov 5 14:18:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5C21F8558 for ; Mon, 5 Nov 2012 14:18:16 -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 0d8QoSAhZBsu for ; Mon, 5 Nov 2012 14:18:15 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDD321F854F for ; Mon, 5 Nov 2012 14:18:14 -0800 (PST) Received: from mail108-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 22:18:13 +0000 Received: from mail108-db3 (localhost [127.0.0.1]) by mail108-db3-R.bigfish.com (Postfix) with ESMTP id 428B12C025E; Mon, 5 Nov 2012 22:18:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I1432I14ffIb7mzz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail108-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail108-db3 (localhost.localdomain [127.0.0.1]) by mail108-db3 (MessageSwitch) id 1352153891734347_28717; Mon, 5 Nov 2012 22:18:11 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.250]) by mail108-db3.bigfish.com (Postfix) with ESMTP id AF4074E00B6; Mon, 5 Nov 2012 22:18:11 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 22:18:11 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.122]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0233.002; Mon, 5 Nov 2012 22:18:09 +0000 From: Stephan Wenger To: "David Benham (dbenham)" , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Incoming liaison statement from MPEG Thread-Index: AQHNscuQrKWwUbiVwUGukf/J2FnY8pfI8Q6AgACeLACAEfUIgIAACzAA Date: Mon, 5 Nov 2012 22:18:09 +0000 Message-ID: In-Reply-To: <0683D6CB32AC424D8AF52C0F660E5DC5150ACC9B@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <580D3B9063C1824F93C8967606F0B76E@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 22:18:16 -0000 On 11.5.2012 11:38 , "David Benham (dbenham)" wrote: >> Apple deserves to be commended for making a royalty-free commitment, >>but it's a lonely position. > >They do deserve such, however not that lonely. Cisco's declaration was >submitted previously, but against the wrong numbers (admin error). >Re-submission is underway and will have the same, royalty-free >commitment. =20 > >The more pronounced observation is that most declarations have not been >not submitted yet in this still relatively young effort. Yes, it's a young effort. But: First, declarations against 14496-29 have been received over the course of half year now, by at least one third of the suspected (by me) baseline rightholders. Second, this is not a majority vote game, nor consensus driven. One solid patent of a determined rightholder is all that is needed to kill a royalty free effort (which obviously goes for all standards, including RF H.264 and VP8 and whatnot). Third, a number of the RAND declarations came from companies with very large known H.264 related portfolios, some of which are known to monetarize their portfolio through licensing, through MPEG-LA or otherwise. Fourth, and that's to me the scariest, some of the RAND declarations come from companies which have (to the best of my knowledge) not contributed to the -29 effort and, therefore and arguably, are not even under an obligation to declare. They declared voluntarily, and that is really bad new for the -29 effort, IMO. It's possible that the -29 process is being resurrected, and I know that a number of people are working very hard on that. Only time will tell. However, for now, I believe the characterization of H.264 constrained baseline being a royalty bearing standard is the only correct and supported one. Stephan > > >From: Harald Alvestrand [mailto:harald@alvestrand.no] >Sent: Wednesday, October 24, 2012 11:25 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Incoming liaison statement from MPEG > >On 10/24/2012 10:58 PM, David Benham (dbenham) wrote: >To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a >non-royalty bearing solution was mentioned in our draft below as a >potential upside to selecting H264/AVC constrained baseline profile >today. Unfortunately, the outcome will not be known soon enough, but to >the extent future surprises weigh on our decision ... this one is >positive! >FWIW, there have been 11 IPR submissions into the ISO registry on MPEG-4 >part 29 to date; 1 of them specifies that the IPR is available on a >royalty free basis, 10 do not. Unless I miscounted. > >Apple deserves to be commended for making a royalty-free commitment, but >it's a lonely position. > >The registry of IPR submissions is available at >http://www.iso.org/iso/standards_development/patents > > > > > > >http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00 >6.4. Future IPR Status Consideration > For additional informative purposes, the MPEG/IEC/ISO made a call for > a royalty-free video coding solution for the Internet. As of its > 98th meeting, two tracks forward are being pursued; one of which is > based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is > presently collecting patent licensing declarations that would include > patent holder's royalty expectations unbundled from other higher > profile mechanisms. Should this effort result in a royalty-free > constrained baseline profile, this would benefit RTCweb in the future > if H.264/AVC is selected as mandatory today. > > > >From: Stephan Wenger [mailto:stewe@stewe.org] >Sent: Wednesday, October 24, 2012 2:40 AM >To: video-codec@ietf.org; rtcweb@ietf.org >Subject: [rtcweb] Incoming liaison statement from MPEG > >Hi all, >Please find attached an incoming liaison statement from MPEG. It's >short, and therefore attached. For those not familiar with MPEG's >terminology: "AVC" stands for "Advanced Video Codec" and is used in >certain circles for what other people know as H.264, and sometimes, >depending on context, only for the non-scalable and non-multiview >profiles of H.264. (H.264 is the ITU designation for the joint >standard). MPEG-4 part 29, or WebVC is, as described in the statement, >what most people know as "constrained baseline H.264", i.e. H.264 >baseline without the rarely used tools known as Arbitrary Slice Order, >Flexible Macroblock Order, and Redundant Slices. >Also, in order to avoid possible confusion, let me emphasize that this >liaison statement comes from the standardization body known as MPEG >(ISO/IEC JTC1/SC29/WG11 ) and not from the licensing administrator known >as MPEG-LA. >Regards, >Stephan > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From dbenham@cisco.com Mon Nov 5 15:20:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E22921F84D5 for ; Mon, 5 Nov 2012 15:20:34 -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 dLnqweKORs0x for ; Mon, 5 Nov 2012 15:20:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E721F84BF for ; Mon, 5 Nov 2012 15:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6647; q=dns/txt; s=iport; t=1352157633; x=1353367233; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=D+qqPQ4HqLUITKgEAuzodNPxEtIDasmNTCEGMsoPcso=; b=FM+Fyt/50BrFQGYB+UTwKH5TC/9Xu+XndYNXLQMVI3lkAt0pPJQ2vVqk wedwc2IibX8Sez+UO2DfZUUFXvjOhBO4pXuVbOW+76kTJmuYIz98L+JmA 6pthuCEIFMZVGF9UsGDgSRbEIZFnXMTWfTcfZp5ovWY8IoR0BcuuD/rTN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA1JmFCtJV2d/2dsb2JhbABEwzOBCIIeAQEBBAEBAQ8BCh00FwQCAQgOAwQBAQEKFAkHJwsUCQgCBAESCAESB4doC5sCoBaMAYNigXlhA4xahW+ETo09gWuCYg2BZBce X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139079976" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 05 Nov 2012 23:20:32 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA5NKW7f012726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 23:20:32 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:20:32 -0600 From: "David Benham (dbenham)" To: Stephan Wenger , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Incoming liaison statement from MPEG Thread-Index: AQHNsuNQzjknwsADnEqWTGe8sEFUv5fbf84QgADF34D//6O6AA== Date: Mon, 5 Nov 2012 23:20:31 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC5150AD75A@xmb-aln-x10.cisco.com> References: <0683D6CB32AC424D8AF52C0F660E5DC5150ACC9B@xmb-aln-x10.cisco.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.124.93] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--55.814000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2012 23:20:34 -0000 >characterization of H.264 constrained baseline being a royalty bearing sta= ndard is the only correct and supported one. Yes, and it was stated in our draft that this MPEG/ITU effort is a potentia= l "future" upside. The reality is we are going to have make estimates ab= out the future of the alternative's royalty/IPR status, so this in-progress= effort is worth noting too. Also, your reply sounds like you're assumin= g that a RAND declaration means said patent holder will be asking for money= and will not offer royalty free if they like the result -- that assumption= doesn't necessarily hold, which I think is the main point of Singer's pos= t. Considering how well known the patent situation is for H264/AVC, it is easi= er to be pessimistic and when less well known as with the alternative propo= sed, it is easier to be optimistic. Although, it was interesting to read = 'narrow margin' in W3C/Philippe's email to us, "(RF for HTML5) proposal was= turned down by a narrow margin within the MPEG-LA membership"? =20 > -----Original Message----- > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Monday, November 05, 2012 2:18 PM > To: David Benham (dbenham); Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Incoming liaison statement from MPEG >=20 > On 11.5.2012 11:38 , "David Benham (dbenham)" > wrote: >=20 > >> Apple deserves to be commended for making a royalty-free commitment, > >>but it's a lonely position. > > > >They do deserve such, however not that lonely. Cisco's declaration wa= s > >submitted previously, but against the wrong numbers (admin error). > >Re-submission is underway and will have the same, royalty-free > >commitment. > > > >The more pronounced observation is that most declarations have not been > >not submitted yet in this still relatively young effort. >=20 > Yes, it's a young effort. But: > First, declarations against 14496-29 have been received over the course o= f > half year now, by at least one third of the suspected (by me) baseline > rightholders. Second, this is not a majority vote game, nor consensus > driven. One solid patent of a determined rightholder is all that is > needed to kill a royalty free effort (which obviously goes for all > standards, including RF H.264 and VP8 and whatnot). Third, a number of > the RAND declarations came from companies with very large known H.264 > related portfolios, some of which are known to monetarize their portfolio > through licensing, through MPEG-LA or otherwise. Fourth, and that's to m= e > the scariest, some of the RAND declarations come from companies which > have (to the best of my knowledge) not contributed to the -29 effort and, > therefore and arguably, are not even under an obligation to declare. The= y > declared voluntarily, and that is really bad new for the -29 effort, IMO. >=20 > It's possible that the -29 process is being resurrected, and I know that = a > number of people are working very hard on that. Only time will tell. > However, for now, I believe the characterization of H.264 constrained > baseline being a royalty bearing standard is the only correct and > supported one. >=20 > Stephan >=20 > > > > > >From: Harald Alvestrand [mailto:harald@alvestrand.no] > >Sent: Wednesday, October 24, 2012 11:25 PM > >To: rtcweb@ietf.org > >Subject: Re: [rtcweb] Incoming liaison statement from MPEG > > > >On 10/24/2012 10:58 PM, David Benham (dbenham) wrote: > >To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a > >non-royalty bearing solution was mentioned in our draft below as a > >potential upside to selecting H264/AVC constrained baseline profile > >today. Unfortunately, the outcome will not be known soon enough, but to > >the extent future surprises weigh on our decision ... this one is > >positive! > >FWIW, there have been 11 IPR submissions into the ISO registry on MPEG-4 > >part 29 to date; 1 of them specifies that the IPR is available on a > >royalty free basis, 10 do not. Unless I miscounted. > > > >Apple deserves to be commended for making a royalty-free commitment, > but > >it's a lonely position. > > > >The registry of IPR submissions is available at > >http://www.iso.org/iso/standards_development/patents > > > > > > > > > > > > > >http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00 > >6.4. Future IPR Status Consideration > > For additional informative purposes, the MPEG/IEC/ISO made a call for > > a royalty-free video coding solution for the Internet. As of its > > 98th meeting, two tracks forward are being pursued; one of which is > > based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is > > presently collecting patent licensing declarations that would include > > patent holder's royalty expectations unbundled from other higher > > profile mechanisms. Should this effort result in a royalty-free > > constrained baseline profile, this would benefit RTCweb in the future > > if H.264/AVC is selected as mandatory today. > > > > > > > >From: Stephan Wenger [mailto:stewe@stewe.org] > >Sent: Wednesday, October 24, 2012 2:40 AM > >To: video-codec@ietf.org; rtcweb@ietf.org > >Subject: [rtcweb] Incoming liaison statement from MPEG > > > >Hi all, > >Please find attached an incoming liaison statement from MPEG. It's > >short, and therefore attached. For those not familiar with MPEG's > >terminology: "AVC" stands for "Advanced Video Codec" and is used in > >certain circles for what other people know as H.264, and sometimes, > >depending on context, only for the non-scalable and non-multiview > >profiles of H.264. (H.264 is the ITU designation for the joint > >standard). MPEG-4 part 29, or WebVC is, as described in the statement, > >what most people know as "constrained baseline H.264", i.e. H.264 > >baseline without the rarely used tools known as Arbitrary Slice Order, > >Flexible Macroblock Order, and Redundant Slices. > >Also, in order to avoid possible confusion, let me emphasize that this > >liaison statement comes from the standardization body known as MPEG > >(ISO/IEC JTC1/SC29/WG11 ) and not from the licensing administrator known > >as MPEG-LA. > >Regards, > >Stephan > > > > > > > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb > > > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 From singer@apple.com Tue Nov 6 00:29:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A3621F8837 for ; Tue, 6 Nov 2012 00:29:34 -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 JH4I4ztDoIiG for ; Tue, 6 Nov 2012 00:29:34 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63C21F8825 for ; Tue, 6 Nov 2012 00:29:34 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MD2002L84WSV360@mail-out.apple.com> for rtcweb@ietf.org; Tue, 06 Nov 2012 00:29:18 -0800 (PST) X-AuditID: 1180711d-b7fe16d00000096a-82-5098ca5e7a50 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id D6.39.02410.E5AC8905; Tue, 06 Nov 2012 00:29:18 -0800 (PST) Received: from [17.78.213.175] by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MD2009NN4WQO960@fenugreek.apple.com> for rtcweb@ietf.org; Tue, 06 Nov 2012 00:29:18 -0800 (PST) From: David Singer In-reply-to: Date: Tue, 06 Nov 2012 09:29:13 +0100 Message-id: <3501F1E2-D75F-4A92-A7C6-392BC37AA36A@apple.com> References: To: Harald Alvestrand , "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1499) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FCcqBt3akaAwfMWAYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eC0S8Evvoodq2axNjDO5Oli5OSQEDCR6O7eygphi0lcuLee rYuRi0NIYAaTxIXV91kgnDYmiSctWxlBqpgFtCTW7zzO1MXIwcEroCcxaX8QSFhYwEri8vTP bCA2m4CqxIM5x8DKOQWSJWa8h1jAAhRvn/kZaoy2xJN3F8DivAI2Eq9mvWcHsYUEkiSWbHkA FhcRCJZYdfoPC8RxshIrpvYyTWDkn4XkilkIV8xCMnUBI/MqRsGi1JzESkNjvcSCgpxUveT8 3E2M4PAqlN3BuP8n/yFGAQ5GJR7eXcIzAoRYE8uKK3MPMUpwMCuJ8O7YBhTiTUmsrEotyo8v Ks1JLT7EKM3BoiTOm8cLlBJITyxJzU5NLUgtgskycXBKNTAueKK9Im3nLbczgtfSIyK+fy6Q 0NkSvlrdrGX716YE+e0+kiFxDQ8efXWISfzRZFLqum/3i+Wp3GcDL0Rv2XJqZoZQ7/2SIunj X04uWmE2U1yO78TUD+UVczQfHJJfxnFv7fr8TQXyS29FdH37KuYtw7/AUXxKW53AtDQHqS1p F2vVmyd9qD+vxFKckWioxVxUnAgAgpgdkSsCAAA= Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2012 08:29:34 -0000 As an example of the patent statements received, I am pleased to be able to forward the following from Fraunhofer HHI (forwarded with permission): Begin forwarded message: > Subject: Re: [rtcweb] Incoming liaison statement from MPEG > Date: November 5, 2012 23:37:57 GMT+01:00 > > Dear all, > > we, Fraunhofer HHI, have submitted a statement for IVCT that declares our IPR under condition 2 (RAND) of the ISO patent policy. However, we have also submitted an additional statement to ISO with the following contents (and I believe others did as well): > > "In the event that the Patent Holder holds granted and/or pending applications for patents, the use of which would be required to implement the Constrained Baseline Profile proposed in N 12733 and the Constrained Baseline Profile is approved as the new proposed IVCT royalty-free Standard, Patent Holder is prepared to grant a Type 1 license comparable to option 1, including reciprocity and reservation of rights suboptions therein, of the Patent Statement and Licensing Declaration for ITU-T /ITU-R Recommendation and ISO/IEC Deliverable (FORM: 1 March 2007) for use in an internet video codec that implements solely the Constrained Baseline Profile, provided that all other patent holders do the same. The license would not extend to other Profiles or other implementations." > > Hence, we support the process of creating a royalty-free Baseline Profile of H.264/MPEG4-AVC and we are optimistic that further progress will be achieved as the process continues. > > Best regards, > Thomas Wiegand > --- > Prof. Dr.-Ing. Thomas Wiegand > Chair, Image Communication, TU Berlin, Sekr. EN-16, Einsteinufer 17 > Head, Image Processing Department, Fraunhofer HHI, Einsteinufer 37 > D-10587 Berlin, Germany David Singer Multimedia and Software Standards, Apple Inc. From agrange@google.com Tue Nov 6 13:18:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630A721F8ABE for ; Tue, 6 Nov 2012 13:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_14=1, 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 FbR1y7l4EBh5 for ; Tue, 6 Nov 2012 13:18:00 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D39821F899B for ; Tue, 6 Nov 2012 13:17:58 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id c4so617467qae.10 for ; Tue, 06 Nov 2012 13:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+GT54+lvzzEd8xoY+ex6II50biwa0y+klJufldYpj6s=; b=lE5qTYzCRTv99kBk2GQPpamMHneFLOPyRMu/3caFd3hdkZN34QH+w1dRzO2KNh7u+g 7TV5p6T5KNuunS10bkdgApsEGEXwg7wlzryBwpTyksjOY9Z/DtvXRymhmdflOMiDtEhu IM9caWD62pzxDPldYEwr3PkSCSfeATnevN/EyXxGZsN9AGYncQRjh+qmHRcr9dQSNFns jet6PIeWxHQo+dKQNxVIon/InNHy7+0BtGy/IYYfkOcXhX9oRieXPrmGZOQBcq99ZrJo SPtH/rC6gVTu03ZoEqELsMlO7LRKPt5NKhFyxEC49tW+ql80H/Pbe2VI63rutKWmQQdN waYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=+GT54+lvzzEd8xoY+ex6II50biwa0y+klJufldYpj6s=; b=eg8pTicTMGQ4f78flyq009SBkQl9opyXJhMb+c63oLbmr2dg9nDTFCTctLARsDC4xC 0AU18lczddvV6BoDp2+Y/bGPsT4YQNqEOcrWf0IN5YlDZlgVgwrF/dfpfIY15Bta4avE z7irC590UwWDF8Ij9pJctxluDKn1Cch/ZlRK9gkTTaH/0Fg/ebAkoxtaG8QpRGOk4mHu EYVLPRgpDdgrwQPiuOGAWZlgaRfrhUKzrNl8d2QbJf/DQT9sXwrEYYzJcm1B6KlJTlGH nv3NdEGOX8W/FMDb/n0bcxvlf+ewQNatLvkRY8e80Uos/y5TyUUE8ORwOfCaO4iQH576 4fJQ== MIME-Version: 1.0 Received: by 10.49.5.9 with SMTP id o9mr4080003qeo.55.1352236678412; Tue, 06 Nov 2012 13:17:58 -0800 (PST) Received: by 10.229.186.19 with HTTP; Tue, 6 Nov 2012 13:17:58 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 16:17:58 -0500 Message-ID: From: Adrian Grange To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7bea32dade793704cdda2279 X-Gm-Message-State: ALoCoQm0ORZXi0YXa+U9aDkUjxCTD4jmzjLUL+iIgkco3MPCGQcmPmGLe40WB2hipISQOPclg7I5NvfOeTT1TrY0aKDl7c7r/SgnbIKNGshw4SBNrJ1SGJa4nwa/ih5rKHaHJzEb6azoF0r3nCr4XVnRaGnu/zXrQBLje8wUJ6oBbPDTHgTFGJHh3UNUnfjRpJq9CqwDrzKA Subject: Re: [rtcweb] VP8 vs H.264 Comparison data sources X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2012 21:18:01 -0000 --047d7bea32dade793704cdda2279 Content-Type: text/plain; charset=ISO-8859-1 The links to download the encoded clips for the tests were incorrect in the previous email. The corrected version appears below. Apologies for the confusion. Adrian ------------------------------------------------------------------------------ VP8 versus H264 Tests Produced for IETF85. The script files for the tests can be downloaded from: http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz It may be reflated using the command: tar -x --xz vp8_vs_h264.tar.xz Once deflated you will find a README.txt file explaining how to proceed. NOTE: The raw test video clips must also be downloaded before the tests are run and placed in a sub-directory named "video". These clips are a little over 2GB in total and may be individually downloaded using the following links: http://downloads.webmproject.org/ietf_tests/desktop_640_360_30.yuv.xz http://downloads.webmproject.org/ietf_tests/gipsrecmotion_1280_720_50.yuv.xz http://downloads.webmproject.org/ietf_tests/gipsrecstat_1280_720_50.yuv.xz http://downloads.webmproject.org/ietf_tests/kirland_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/macmarcomoving_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/macmarcostationary_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/niklas_1280_720_30.yuv.xz http://downloads.webmproject.org/ietf_tests/niklas_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/tacomanarrows_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/tacomasmallcameramovement_640_480_30.yuv.xz http://downloads.webmproject.org/ietf_tests/thaloundeskmtg_640_480_30.yuv.xz They must each be reflated using the command: xz -d .xz (The original .xz file is automatically deleted). Alternatively, the resulting compressed clips may be downloaded directly using the following link format: VP8: http://downloads.webmproject.org/ietf_tests/vp8_videos/ _kbps.webm H.264: http://downloads.webmproject.org/ietf_tests/vp8_videos/ _kbps.mkv where corresponds to one of the file names in the links above, e.g. "desktop_640_360_30", and is the encoded data-rate of the clip, in the range: 800 to 1500 in steps of 100 for the 1280x720 clips, 100 to 800 in steps of 100 for the remaining clips. On Mon, Nov 5, 2012 at 2:08 PM, Adrian Grange wrote: > I have made available the source clips, script files, compressed files and > associated > materials that were used to generate the VP8 vs H.264 comparison results > included > in our submission: > draft-alvestrand-rtcweb-vp8-00 "VP8 as RTCWEB Mandatory to Implement" > > The notes below provide notes on how to access the materials and provide a > first > pointer on where to look for instructions on how to build the clips. > > In addition there are instructions on how to download the resulting > compressed > video files for both VP8 & H.264. > > > ------------------------------------------------------------------------------ > > VP8 versus H264 Tests > > Produced for IETF85. > > The script files for the tests can be downloaded from: > http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz > > It may be reflated using the command: > tar -x --xz vp8_vs_h264.tar.xz > > Once deflated you will find a README.txt file explaining how to proceed. > > NOTE: The raw test video clips must also be downloaded before the tests > are run and placed in a sub-directory named "video". These clips are a > little > over 2GB in total and may be individually downloaded using the following > links: > > http://downloads.webmproject.org/ietf_tests/desktop_640_360_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/gipsrecmotion_1280_720_50.yuv.xz > http://downloads.webmproject.org/ietf_tests/gipsrecstat_1280_720_50.yuv.xz > http://downloads.webmproject.org/ietf_tests/kirland_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/macmarcomoving_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/macmarcostationary_640_480_30.yuv.xz > http://downloads.webmproject.org/ietf_tests/niklas_1280_720_30.yuv.xz > http://downloads.webmproject.org/ietf_tests/niklas_640_480_30.yuv.xz > http://downloads.webmproject.org/ietf_tests/tacomanarrows_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/tacomasmallcameramovement_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/thaloundeskmtg_640_480_30.yuv.xz > > They must each be reflated using the command: > xz -d .xz > (The original .xz file is automatically deleted). > > Alternatively, the resulting compressed clips may be downloaded directly > using the > following link format: > > VP8: > http://downloads.webmproject.org/ietf_tests/vp8_videos/.webm > > H.264: > http://downloads.webmproject.org/ietf_tests/vp8_videos/.mkv > > where corresposnds to one of the file names in the links > above, > e.g. "desktop_640_360_30". > > If there are any problems please contact agrange@google.com > > Adrian Grange > Chrome Media Group, Google. > > --047d7bea32dade793704cdda2279 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:13px">
Th= e links to download the encoded clips for the tests were incorrect in the
previous email. The corrected version appears below.

Apologies for the confusion.

Adrian

-----------------------------------------------------= -------------------------

VP8 versus H264 Tests

Produced for IETF85.

The scrip= t files for the tests can be downloaded from:

It may be reflated using the command:
tar -x = --xz vp8_vs_h264.tar.xz

Once deflated you will fin= d a README.txt file explaining how to proceed.

NOTE: The raw test video clips must also be downloaded before the tests
are run and placed in a sub-directory named "video". These= clips are a little
over 2GB in total and =A0may be individually = downloaded using the following links:


They mu= st each be reflated using the command:
xz -d <filename>.xz
(The original .xz file is automati= cally deleted).

Alternatively, the resulting compressed= clips may be downloaded directly using the
follow= ing link format:

VP8:

H.= 264:

where <video_name> corresponds to one of the file names in the li= nks above,
e.g. "desktop_640_360_30", and <rate> is the encoded data-r= ate of the clip, in the range:
800 to 1500 in steps of 100 for the 1280x720 = clips,
100 to= 800 in steps of 100 for the remaining clips.




On Mon, Nov 5= , 2012 at 2:08 PM, Adrian Grange <agrange@google.com> wrote= :
I have made available the source clips, scrip= t files, compressed files and associated
materials that were used to generate the VP8 vs H.264 comparison resul= ts included
in our submission:
draft-alvestrand-rtcweb-vp8-00=A0&qu= ot;VP8 as RTCWEB Mandatory to Implement"

The notes below provide notes on how to access the materials and provide = a first
pointer on=A0where to look for instructions on how to build the clips.=

In addition there are instructions on how to down= load the resulting compressed
video files for both VP8 & H.26= 4.

-------------------------------------------------------= -----------------------

VP8 versus H264 Tests

Produced for IETF85.

The scri= pt files for the tests can be downloaded from:

It may be reflated using the comman= d:
tar -x --xz vp8_vs_h264.tar.xz

Once deflated you will find a README.txt file explainin= g how to proceed.

NOTE: The raw test video clips m= ust also be downloaded before the tests
are run and placed in a s= ub-directory named "video". These clips are a little
over 2GB in total and =A0may be individually downloaded using the foll= owing links:


They mu= st each be reflated using the command:
xz -d <filename>.xz
(The original .xz file is automati= cally deleted).

Alternatively, the resulting compr= essed clips may be downloaded directly using the
following link f= ormat:

VP8:

H.264:

where <video_name> co= rresposnds to one of the file names in the links above,
e.g. "desktop_640_360_30".

If there= are any problems please contact agrange@google.com

Adrian Grange
Chrome Media Group, Google.


--047d7bea32dade793704cdda2279-- From agrange@google.com Tue Nov 6 15:24:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EBF21F8BB2 for ; Tue, 6 Nov 2012 15:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_14=1, 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 HTbMQJxQEfEF for ; Tue, 6 Nov 2012 15:24:53 -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 EA5A121F8582 for ; Tue, 6 Nov 2012 15:24:52 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so734208qca.31 for ; Tue, 06 Nov 2012 15:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=o2Q2vq7hqID6CuQedt0oEK0/9RMPSTkaDKhX9hwEwpM=; b=f2O/lMaMvfwcuEkb6mH9uw8XMbx7KPB6wAq++dGLjfuv36kCApyUcfyt0Sx2w0Xet8 1HH3XcH8mVyCxvxyvYd14+dRCyAc/dgbURK/R1kjbmaRLvc29U4B4s0LfUTk87XDqPWY CsS5RLJirvzppVALd1D5QyNn6SzuTW031zNsITLsrId0rqBrsnqerZBWMtnXxch+atqG Rj6Jw6T6/qfvcka90bvehOCd7cgcl1yPxkPz4UUZNBBOa/qd1hiPqIFVgqwyHEUzxpqj fHpvXS+nYRXVpzKhCHzch+dxtfuw3ZxMx3cjh7PR0LTPJSyYuu0rWFRdspEkh6K8I8Q/ Vs8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=o2Q2vq7hqID6CuQedt0oEK0/9RMPSTkaDKhX9hwEwpM=; b=hwt+jHbKxsHaa+OSqFrQt9LN+ZuHpnU+dxVGFO3XSm6UV/MuK919USCSzlddfygvBB XkmWM6XCksC7FfUglTUgc8ZhIhrZUZZBh7DgXBe0CAcWNZNc89UgaELoKS0lAKJ2oum/ vBuOJlZshD0yHER3e8xguHH8y7iFdq3wd+db7NLPN6km0da92vjeN9Sjr9biLQnvzovP IuomDrkkkj1/QVxyXPzVQlMwJlshr3jJNOh9P1wzlnV6HLkoK/khV3NRXzlolOty6Qh5 KH/+eNev0L78sK3qIwJB2xEyFEOSwKxyiYkgMogePX0vV3VlD4V7RmVr6AKsULNEp//5 ocZw== MIME-Version: 1.0 Received: by 10.224.33.135 with SMTP id h7mr4201580qad.26.1352244292301; Tue, 06 Nov 2012 15:24:52 -0800 (PST) Received: by 10.229.186.19 with HTTP; Tue, 6 Nov 2012 15:24:52 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 18:24:52 -0500 Message-ID: From: Adrian Grange To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf306f7704b133bd04cddbe895 X-Gm-Message-State: ALoCoQkGRSBtIp0qxIwc1imh0BZ42Lh2rqszOywCnXEjwRhg0LOayLUv9e0qgknAO3yr/l9tSRmMoOl11LpTYsoo0wDkUOvds0+ogqVdxMxFb0u2QbezHJXyAzRehn+m7h7Y7dMVt8wgT5ZtPHvYYncdoTPGaxQTzqn6byxDq8lBd0npgHe7GToH9bWQn9+nzCJM7y2C7EWO Subject: Re: [rtcweb] VP8 vs H.264 Comparison data sources X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2012 23:24:54 -0000 --20cf306f7704b133bd04cddbe895 Content-Type: text/plain; charset=ISO-8859-1 We added an index file to the clip download page (thanks for the suggestion TIm), and corrected the path for the H.264 clips. Updated instructions below: ---------------------------- Alternatively, the resulting compressed clips may be downloaded directly using the following link format: VP8: http://downloads.webmproject.org/ietf_tests/vp8_videos/ _kbps.webm H.264: http://downloads.webmproject.org/ietf_tests/h264_videos/ _kbps.mkv where corresponds to one of the file names in the links above, e.g. "desktop_640_360_30", and is the encoded data-rate of the clip, in the range: 800 to 1500 in steps of 100 for the 1280x720 clips, 100 to 800 in steps of 100 for the remaining clips. On Tue, Nov 6, 2012 at 4:17 PM, Adrian Grange wrote: > The links to download the encoded clips for the tests were incorrect in the > previous email. The corrected version appears below. > > Apologies for the confusion. > > Adrian > > > ------------------------------------------------------------------------------ > > VP8 versus H264 Tests > > Produced for IETF85. > > The script files for the tests can be downloaded from: > http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz > > It may be reflated using the command: > tar -x --xz vp8_vs_h264.tar.xz > > Once deflated you will find a README.txt file explaining how to proceed. > > NOTE: The raw test video clips must also be downloaded before the tests > are run and placed in a sub-directory named "video". These clips are a > little > over 2GB in total and may be individually downloaded using the following > links: > > http://downloads.webmproject.org/ietf_tests/desktop_640_360_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/gipsrecmotion_1280_720_50.yuv.xz > > http://downloads.webmproject.org/ietf_tests/gipsrecstat_1280_720_50.yuv.xz > http://downloads.webmproject.org/ietf_tests/kirland_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/macmarcomoving_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/macmarcostationary_640_480_30.yuv.xz > http://downloads.webmproject.org/ietf_tests/niklas_1280_720_30.yuv.xz > http://downloads.webmproject.org/ietf_tests/niklas_640_480_30.yuv.xz > http://downloads.webmproject.org/ietf_tests/tacomanarrows_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/tacomasmallcameramovement_640_480_30.yuv.xz > > http://downloads.webmproject.org/ietf_tests/thaloundeskmtg_640_480_30.yuv.xz > > They must each be reflated using the command: > xz -d .xz > (The original .xz file is automatically deleted). > > Alternatively, the resulting compressed clips may be downloaded directly > using the > following link format: > > VP8: > http://downloads.webmproject.org/ietf_tests/vp8_videos/ > _kbps.webm > > H.264: > http://downloads.webmproject.org/ietf_tests/vp8_videos/ > _kbps.mkv > > where corresponds to one of the file names in the links above, > e.g. "desktop_640_360_30", and is the encoded data-rate of the > clip, in the range: > 800 to 1500 in steps of 100 for the 1280x720 clips, > 100 to 800 in steps of 100 for the remaining clips. > > > > > On Mon, Nov 5, 2012 at 2:08 PM, Adrian Grange wrote: > >> I have made available the source clips, script files, compressed files >> and associated >> materials that were used to generate the VP8 vs H.264 comparison results >> included >> in our submission: >> draft-alvestrand-rtcweb-vp8-00 "VP8 as RTCWEB Mandatory to Implement" >> >> The notes below provide notes on how to access the materials and provide >> a first >> pointer on where to look for instructions on how to build the clips. >> >> In addition there are instructions on how to download the resulting >> compressed >> video files for both VP8 & H.264. >> >> >> ------------------------------------------------------------------------------ >> >> VP8 versus H264 Tests >> >> Produced for IETF85. >> >> The script files for the tests can be downloaded from: >> http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz >> >> It may be reflated using the command: >> tar -x --xz vp8_vs_h264.tar.xz >> >> Once deflated you will find a README.txt file explaining how to proceed. >> >> NOTE: The raw test video clips must also be downloaded before the tests >> are run and placed in a sub-directory named "video". These clips are a >> little >> over 2GB in total and may be individually downloaded using the following >> links: >> >> http://downloads.webmproject.org/ietf_tests/desktop_640_360_30.yuv.xz >> >> http://downloads.webmproject.org/ietf_tests/gipsrecmotion_1280_720_50.yuv.xz >> http://downloads.webmproject.org/ietf_tests/gipsrecstat_1280_720_50.yuv.xz >> http://downloads.webmproject.org/ietf_tests/kirland_640_480_30.yuv.xz >> >> http://downloads.webmproject.org/ietf_tests/macmarcomoving_640_480_30.yuv.xz >> >> http://downloads.webmproject.org/ietf_tests/macmarcostationary_640_480_30.yuv.xz >> http://downloads.webmproject.org/ietf_tests/niklas_1280_720_30.yuv.xz >> http://downloads.webmproject.org/ietf_tests/niklas_640_480_30.yuv.xz >> >> http://downloads.webmproject.org/ietf_tests/tacomanarrows_640_480_30.yuv.xz >> >> http://downloads.webmproject.org/ietf_tests/tacomasmallcameramovement_640_480_30.yuv.xz >> >> http://downloads.webmproject.org/ietf_tests/thaloundeskmtg_640_480_30.yuv.xz >> >> They must each be reflated using the command: >> xz -d .xz >> (The original .xz file is automatically deleted). >> >> Alternatively, the resulting compressed clips may be downloaded directly >> using the >> following link format: >> >> VP8: >> http://downloads.webmproject.org/ietf_tests/vp8_videos/.webm >> >> H.264: >> http://downloads.webmproject.org/ietf_tests/vp8_videos/.mkv >> >> where corresposnds to one of the file names in the links >> above, >> e.g. "desktop_640_360_30". >> >> If there are any problems please contact agrange@google.com >> >> Adrian Grange >> Chrome Media Group, Google. >> >> > --20cf306f7704b133bd04cddbe895 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:13px">
We= added an index file to the clip download page (thanks for the suggestion T= Im), and corrected the path for the H.264 clips. Updated instructions below= :

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

A= lternatively, the resulting compressed clips may be downloaded directly usi= ng the
following link format:

VP8:

H.= 264:

where <video_name> corresponds to one of the file names in the li= nks above,
e.g. "desktop_640_360_30", and <rate> is the encoded data-r= ate of the clip, in the range:
800 to 1500 in steps of 100 for the 1280x720 = clips,
100 to= 800 in steps of 100 for the remaining clips.


On Tue, Nov 6= , 2012 at 4:17 PM, Adrian Grange <agrange@google.com> wrote= :
The links to download the encoded clips for the tests were incorrect i= n the
previous email. The corrected version appears below.

Apologies for the confusion.

Adrian

------------------------------= ------------------------------------------------

VP8 versus H264 Tests

Produced for IETF85.

The scrip= t files for the tests can be downloaded from:

It may be reflated using the command:
tar -x = --xz vp8_vs_h264.tar.xz

Once deflated you will fin= d a README.txt file explaining how to proceed.

NOTE: The raw test video clips must also be downloaded before the tests
are run and placed in a sub-directory named "video". These= clips are a little
over 2GB in total and =A0may be individually = downloaded using the following links:


They mu= st each be reflated using the command:
xz -d <filename>.xz
(The original .xz file is automati= cally deleted).

Alte= rnatively, the resulting compressed clips may be downloaded directly using = the
follow= ing link format:

VP8:

H.= 264:

where <video_name> corresponds to one of the file names in the li= nks above,
e.g. "desktop_640_360_30", and <rate> is the encoded data-r= ate of the clip, in the range:
800 to 1500 in steps of 100 for the 1280x720 = clips,
100 to= 800 in steps of 100 for the remaining clips.
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:13px">



On Mon, Nov 5= , 2012 at 2:08 PM, Adrian Grange <agrange@google.com> wrote= :
I have made available the source clips, scrip= t files, compressed files and associated
materials that were used to generate the VP8 vs H.264 comparison resul= ts included
in our submission:
draft-alvestrand-rtcweb-vp8-00=A0&qu= ot;VP8 as RTCWEB Mandatory to Implement"

The notes below provide notes on how to access the materials and provide = a first
pointer on=A0where to look for instructions on how to build the clips.=

In addition there are instructions on how to down= load the resulting compressed
video files for both VP8 & H.26= 4.

-------------------------------------------------------= -----------------------

VP8 versus H264 Tests

Produced for IETF85.

The scri= pt files for the tests can be downloaded from:

It may be reflated using the comman= d:
tar -x --xz vp8_vs_h264.tar.xz

Once deflated you will find a README.txt file explainin= g how to proceed.

NOTE: The raw test video clips m= ust also be downloaded before the tests
are run and placed in a s= ub-directory named "video". These clips are a little
over 2GB in total and =A0may be individually downloaded using the foll= owing links:


They mu= st each be reflated using the command:
xz -d <filename>.xz
(The original .xz file is automati= cally deleted).

Alternatively, the resulting compr= essed clips may be downloaded directly using the
following link f= ormat:

VP8:

H.264:

where <video_name> co= rresposnds to one of the file names in the links above,
e.g. "desktop_640_360_30".

If there= are any problems please contact agrange@google.com

Adrian Grange
Chrome Media Group, Google.



--20cf306f7704b133bd04cddbe895-- From giles@thaumas.net Tue Nov 6 15:41:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD00F21F8BB9 for ; Tue, 6 Nov 2012 15:41:09 -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 p5YvNVktLBoj for ; Tue, 6 Nov 2012 15:41:09 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6438321F8BB4 for ; Tue, 6 Nov 2012 15:41:09 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so777499pbb.31 for ; Tue, 06 Nov 2012 15:41:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ejvUgLyB2MtG4YuLxho0SS2KxEyq07NKzukLJVvoBHo=; b=JXf4NawfDkJhTHwrN6ycKb5APJHD8rxGrOEP7WAYQy9dunSumSXy39Dqt5tgb61um+ pJgCmp0gd7nqkMyg4nqyaENw3bv1vGYkx7V8S537NqIBgBaXEQ6OBpMfSWpCAhP/IBqU CiLzZ3Culy+6UOjAYR3Sn81FwOHF3T46UBangponKHCgE9XH//RmboT0bt52F2Y2CCMJ TevVCGaQR8JZGPJUmKVVfSb7SKum5PvhpLnXJ2KG4ll8Ys6PLRgrlfA83Qz1Z2EV82kb k6HXlDY+dVn9O42dXfxra4lc8TpJ2iackOlCZ6CBAjS4YU9cEHhuluXGrydZOCpZVXTF Kl8w== Received: by 10.68.248.33 with SMTP id yj1mr8087308pbc.141.1352245269211; Tue, 06 Nov 2012 15:41:09 -0800 (PST) Received: from Glaucomys.local ([64.213.70.194]) by mx.google.com with ESMTPS id v9sm13183481paz.6.2012.11.06.15.41.07 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 15:41:08 -0800 (PST) Message-ID: <5099A013.1060908@thaumas.net> Date: Tue, 06 Nov 2012 15:41:07 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: agrange@google.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlUpsOd5oJaO9L9Mk2t++TyyzpVzEgPw/Dsddb5c4YNLNZ9ttdh5llhFbtVP3vEGc4RTCkH Cc: rtcweb@ietf.org Subject: Re: [rtcweb] VP8 vs H.264 Comparison data sources X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2012 23:41:09 -0000 On 12-11-05 11:08 AM, Adrian Grange wrote: > NOTE: The raw test video clips must also be downloaded before the tests > are run and placed in a sub-directory named "video". These clips are a > little > over 2GB in total and may be individually downloaded using the > following links: Thanks for posting your data. Are this clips redistributable? I'd like to add them to our public collection at media.xiph.org. -r From agrange@google.com Tue Nov 6 19:43:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3921F8B54 for ; Tue, 6 Nov 2012 19:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=0.333, 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 c0Et6aGgw8hW for ; Tue, 6 Nov 2012 19:43:06 -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 0EA7C21F8609 for ; Tue, 6 Nov 2012 19:43:05 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so853097qca.31 for ; Tue, 06 Nov 2012 19:43:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ozs933jTFRd4uhiS14qW7U4ux2BZdNQBA86QhndFVOs=; b=ZtLUdGuVrH7uNKLvzwD6Z8v6omlSO5S2Xoc2RJED7b+oD1QL97/sYc5ldmAm7LbcmB afysZWQjbvGpU8LjXoKrmtR7FiPmOhPXE2QxNGqSxPPdbL5sCZMPk03bPKyrRE1v+xkm m0puJPEJn538u82CfSDugFZWbsy+18xKX2sE5ZhwJcYYCRbkntnFZ6xu/TchEWCt31VZ av29EBXeo4Nba1WGiu12+T+NY9f6ZWG1Y7Q3XUmfsnnkFINOBL4GB/BZwenSwe8wpNOE cf6maJWCabmoqqzte4omxuzShfvPHtqUdKyDFOGucBia1+aSpvpYl9zhSWbJ6ZuewDU2 zyTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Ozs933jTFRd4uhiS14qW7U4ux2BZdNQBA86QhndFVOs=; b=ZAbFMqJUTjXYvjuk5uXcT9iq52sbk2Tjzk+yref1b5fRMrsk4JhaP0SNDC3LreTcC3 SU+HgQD6A/ZOoxhgKZ32foQLuHoLqqqSxDy7qN8gUsrY1ltJ2uYIziqxZBFKPI7VGi/r DnIlg581lRSlv8x2JFPGWIEYa8Gowxkb3tztfG2hShSL9Z3AUkm7Ry79JbRZP/LTJsO4 FElpqGGWI9RgxD4qy8fIesi7akzWUFq+5aeGFhE5ZdprnLNB2Nt87wc3shHuhSfAEcBO Zm8bC9eDzFXBGoDGxP3lJJzdmBK2BsFHhRHkTgkqPhR1vlq39fbCJsCxXy9rOOZpTvue Ct8Q== MIME-Version: 1.0 Received: by 10.49.59.115 with SMTP id y19mr3691299qeq.59.1352259784213; Tue, 06 Nov 2012 19:43:04 -0800 (PST) Received: by 10.229.186.19 with HTTP; Tue, 6 Nov 2012 19:43:04 -0800 (PST) In-Reply-To: <5099A013.1060908@thaumas.net> References: <5099A013.1060908@thaumas.net> Date: Tue, 6 Nov 2012 22:43:04 -0500 Message-ID: From: Adrian Grange To: Ralph Giles Content-Type: multipart/alternative; boundary=047d7b6221ea1502f404cddf8416 X-Gm-Message-State: ALoCoQlnfBnMCKM9nqaJNqwGIIae3F9NTVFKzpvs1ZGfGt5XXUtbqXPOxbRMZoMM42y9/E23ew20rkPnIY5R9Z9pDTjCAPjijF7iya5NE7TKaP4T2L8+z9Djq4I6vibZKdl/Dmfivsf+HVcekUzBW21YRdG5FHeDTGnGsFMkELzyV5gXGNNQkbV6fYLxsbsvigNtNj0iI4AK Cc: rtcweb@ietf.org Subject: Re: [rtcweb] VP8 vs H.264 Comparison data sources X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Nov 2012 03:43:10 -0000 --047d7b6221ea1502f404cddf8416 Content-Type: text/plain; charset=ISO-8859-1 I'll check to see if that's possible... I would hope that it would be. On Tue, Nov 6, 2012 at 6:41 PM, Ralph Giles wrote: > On 12-11-05 11:08 AM, Adrian Grange wrote: > > > NOTE: The raw test video clips must also be downloaded before the tests > > are run and placed in a sub-directory named "video". These clips are a > > little > > over 2GB in total and may be individually downloaded using the > > following links: > > Thanks for posting your data. Are this clips redistributable? I'd like > to add them to our public collection at media.xiph.org. > > -r > --047d7b6221ea1502f404cddf8416 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I= 'll check to see if that's possible... I would hope that it would b= e.


On Tue, Nov= 6, 2012 at 6:41 PM, Ralph Giles <giles@thaumas.net> wrote:<= br>
On 12-11-05 11:08 AM, Adri= an Grange wrote:

> NOTE: The raw test video clips must also be downloaded before the test= s
> are run and placed in a sub-directory named "video". These c= lips are a
> little
> over 2GB in total and =A0may be individually downloaded using the
> following links:

Thanks for posting your data. Are this clips redistributable? I'd= like
to add them to our public collection at media.xiph.org.

=A0-r

--047d7b6221ea1502f404cddf8416-- From randell-ietf@jesup.org Tue Nov 6 23:04:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF22021F8AD7 for ; Tue, 6 Nov 2012 23:04:46 -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 2j6agUydMlpP for ; Tue, 6 Nov 2012 23:04:46 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 304B021F8ACD for ; Tue, 6 Nov 2012 23:04:46 -0800 (PST) Received: from [65.50.0.4] (port=16723 helo=[10.16.90.229]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TVzgr-000BRj-8w for rtcweb@ietf.org; Wed, 07 Nov 2012 01:04:45 -0600 Message-ID: <509A0813.8060700@jesup.org> Date: Wed, 07 Nov 2012 02:04:51 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5097781A.8020504@ericsson.com> <50979F24.70002@alvestrand.no> 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] 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: Wed, 07 Nov 2012 07:04:47 -0000 On 11/5/2012 7:26 AM, Martin Thomson wrote: > On 5 November 2012 11:12, Harald Alvestrand wrote: >> >> If I were a stickler for precision, I think I'd claim that "synchronized" >> only means that "these streams come in with consistent timestamps", there's >> nobody going to whap you over the head with a wet noodle if you play them >> out unsynchronized. > > Yes, user experience will be the most important consideration. > Whatever that means for synchronization. Obviously, synchronization > is desirable, but it needs to be balanced against a lot of other > concerns. Agreed. > Bernard and I discussed this, as well as other scenarios where you > have synthetic, blob-sourced and remote streams. In those cases, it > might make sense to progress the clock consistently, but it is > possible that true synchronization is nonsensical. Yes, those are some of the obvious cases of synchronization between different MediaStreams is nonsensical - if a stream sourced from a
--14dae9340f536222e204cdfc3104-- From dromasca@avaya.com Thu Nov 8 06:46:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BF321F8B2F for ; Thu, 8 Nov 2012 06:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6131ahehg2m for ; Thu, 8 Nov 2012 06:46:22 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 913A221F8536 for ; Thu, 8 Nov 2012 06:46:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANzEm1CHCzI1/2dsb2JhbABEw2qBCIIgAQEDEh4KUQEVFQYMDAdXAQQbDAUJh2iaX4QrnTePNIJEYQOcCIo2gnA X-IronPort-AV: E=Sophos;i="4.80,738,1344225600"; d="scan'208";a="375246112" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Nov 2012 09:38:35 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Nov 2012 09:23:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 15:46:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the problem with (no) remote stats Thread-Index: Ac29v88QTdh4J/UkT2K0OhB0DbHnDg== From: "Romascanu, Dan (Dan)" To: Subject: [rtcweb] the problem with (no) remote stats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2012 14:46:23 -0000 Concerning the remote stats aspect - While the discussion may indeed belong to the w3c webrtc wg where the APIs are discussed, the argument I believe should concern the rtcweb community as well. Statistics on a two-ends (or multiple ends) session do not have too much use without getting information from all hosts, and synchronizing it. These stats will no longer serve the monitoring of one host but of two or more browsers participating in the session. Thus the timestamp is critical. Taking out the remote component of the object while simplifies the API on the hosts makes the life of operators more complicated, as now operators need to access remotely two (or more) hosts instead the one and perform the time synchronization in their applications.=20 Regards, Dan From martin.thomson@gmail.com Thu Nov 8 06:48:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A403621F8596 for ; Thu, 8 Nov 2012 06:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.926 X-Spam-Level: X-Spam-Status: No, score=-3.926 tagged_above=-999 required=5 tests=[AWL=-0.327, 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 GHUxiLO3u0Zm for ; Thu, 8 Nov 2012 06:48:24 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E28A221F8590 for ; Thu, 8 Nov 2012 06:48:23 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so2435994lbo.31 for ; Thu, 08 Nov 2012 06:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t2gP7UJxEze6dNT55S+NyDwqKmM+Jo9WVgUhWFoCXqY=; b=i17QcHX4vzQtgw5E4/R6zyMT+WwX/wEvlAYrzEb8Z4uKsKzOeZ3Aui1SmknPBPAo3g tOUZBrex6sNIQwbgWSgpj7xjZx8SQExylckqLkovBum06fmSH81ZmQMCwuZMTPX0xqEq 2QSNn46lYvQm6EC1CqCv1ukxia4uzdmaALsCxasNrcfWri3vpQg/mnZnRpLdUQDLG2gE OBXqxjpOsZVzjQ4BH5tM9yy7sgEvyoWsqzPP3efrR97XkrgUs6Zfd/I+JyniWodTY5On c/XGwtKBPqoAqHt7QTiX6hULmrI05V4cYdXBSgLlekVm4e6+vyQDcDb+oFOEXVwqBx44 52FA== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr7759600lab.30.1352386102892; Thu, 08 Nov 2012 06:48:22 -0800 (PST) Received: by 10.112.83.2 with HTTP; Thu, 8 Nov 2012 06:48:22 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Nov 2012 09:48:22 -0500 Message-ID: From: Martin Thomson To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] the problem with (no) remote stats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2012 14:48:24 -0000 I believe that the decision was to structure the stats, not to remove remote stats entirely. Harald and I may have grossly different remembrances. On 8 November 2012 09:46, Romascanu, Dan (Dan) wrote: > Concerning the remote stats aspect - While the discussion may indeed > belong to the w3c webrtc wg where the APIs are discussed, the argument I > believe should concern the rtcweb community as well. Statistics on a > two-ends (or multiple ends) session do not have too much use without > getting information from all hosts, and synchronizing it. These stats > will no longer serve the monitoring of one host but of two or more > browsers participating in the session. Thus the timestamp is critical. > Taking out the remote component of the object while simplifies the API > on the hosts makes the life of operators more complicated, as now > operators need to access remotely two (or more) hosts instead the one > and perform the time synchronization in their applications. > > Regards, > > Dan > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Thu Nov 8 06:54:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAACF21F8B3B for ; Thu, 8 Nov 2012 06:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsOBI237G39Z for ; Thu, 8 Nov 2012 06:54:34 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id EA63121F8596 for ; Thu, 8 Nov 2012 06:54:33 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA8EsSKd028932; Thu, 8 Nov 2012 16:54:29 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Nov 2012 16:54:27 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.221]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0318.003; Thu, 8 Nov 2012 14:54:25 +0000 From: To: , Thread-Topic: [rtcweb] MTI codec discussion, request to postpone Thread-Index: AQHNvbjIIEr7te/WmEOQkJBRvaiUp5fgBBGw Date: Thu, 8 Nov 2012 14:54:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.49.60] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7622FACA7008AM1MPN1041mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Nov 2012 14:54:27.0770 (UTC) FILETIME=[F35951A0:01CDBDC0] X-Nokia-AV: Clean Subject: Re: [rtcweb] MTI codec discussion, request to postpone X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2012 14:54:34 -0000 --_000_E44893DD4E290745BB608EB23FDDB7622FACA7008AM1MPN1041mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Serge, I agreed to the proposal to drop the discussions since I was pretty sure we= would not learn much new or reach any concensus over this. However, could = you elaborate a bit what lead to your request just 5 minutes before the sta= rt of the session? I mean, concerns about VP IPR status have been raised al= l along the way and probably will continue to be. Is there something new, o= r something that could be resolved by IETF86? Markus From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= ext Serge Lachapelle Sent: 08 November, 2012 15:55 To: rtcweb@ietf.org Subject: [rtcweb] MTI codec discussion, request to postpone All, Google understands that concerns have been raised within the IETF RTCWEB WG= in regards to VP8 IPR. We endeavored to properly address these concerns in= time for this IETF meeting but did not meet the deadline. We hereby commit to addressing this by the next IETF meeting in Orlando. Ou= r proposal will address prevalent IPR issues. Google believes strongly that the VP8 codec is the best technical option fo= r a mandatory to implement codec. We therefore kindly ask to postpone this decision and hope the workgoup wil= l take this opportunity to make progress on other vital topics. /Serge --_000_E44893DD4E290745BB608EB23FDDB7622FACA7008AM1MPN1041mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Serge,

 <= /p>

I agreed to the proposal = to drop the discussions since I was pretty sure we would not learn much new= or reach any concensus over this. However, could you elaborate a bit what lead to your request just 5 minutes before the start of the ses= sion? I mean, concerns about VP IPR status have been raised all along the w= ay and probably will continue to be. Is there something new, or something t= hat could be resolved by IETF86?

 <= /p>

Markus<= /p>

 <= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Serge Lachapelle
Sent: 08 November, 2012 15:55
To: rtcweb@ietf.org
Subject: [rtcweb] MTI codec discussion, request to postpone

 

All,

 

Google understands that concerns have bee= n raised within the IETF RTCWEB WG in regards to VP8 IPR. We endeavored to = properly address these concerns in time for this IETF meeting but did not meet the deadline.

 

We hereby commit to addressing this by th= e next IETF meeting in Orlando. Our  proposal will address prevalent I= PR issues.

 

Google believes strongly that the VP8 cod= ec is the best technical option for a mandatory to implement codec. 

 

We therefore kindly ask to postpone this = decision and hope the workgoup will take this opportunity to make progress = on other vital topics.

 

/Serge

--_000_E44893DD4E290745BB608EB23FDDB7622FACA7008AM1MPN1041mgdn_-- From singer@apple.com Thu Nov 8 08:14:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F3621F88EF for ; Thu, 8 Nov 2012 08:14:47 -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 lVYwEaNOFz-Q for ; Thu, 8 Nov 2012 08:14:46 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id CEBF121F87E5 for ; Thu, 8 Nov 2012 08:14:46 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_EMTP4CvcGDAPO4fcN8AObw)" Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MD600KXYFNPDF81@mail-out.apple.com> for rtcweb@ietf.org; Thu, 08 Nov 2012 08:14:27 -0800 (PST) X-AuditID: 11807112-b7f296d000001183-41-509bda62b63f Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 67.98.04483.26ADB905; Thu, 08 Nov 2012 08:14:27 -0800 (PST) Received: from [17.78.213.51] by chicory.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MD6009DFFRYWU10@chicory.apple.com> for rtcweb@ietf.org; Thu, 08 Nov 2012 08:14:26 -0800 (PST) From: David Singer In-reply-to: Date: Thu, 08 Nov 2012 17:14:24 +0100 Message-id: References: To: Serge Lachapelle X-Mailer: Apple Mail (2.1499) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FCcrJt8a3aAwcx/jBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/PqZfaC/foVna8eMTYw/tHoYuTgkBAwkdhxSLqLkRPIFJO4 cG89WxcjF4eQwBQmie/tK5ggnEYmiYPPXrCDVDELJEl87DnFCtLMK6AnMWl/EEhYWMBe4tr8 o2wgNpuAqsSDOccYQWxOgWCJlq+XmEBsFqB4/7zfzBBjhCW+P77HAmLzCthIXN3fAhYXEgiQ mPtwK1hcREBD4vZtiHoJAVmJFVN7mSYw8s9CcsUshCsgwtoSyxa+Zoaw9SReNr1jxxTXlbi4 bhLjAka2VYyCRak5iZWG5nqJBQU5qXrJ+bmbGMFhWii0g/H+Lr1DjAIcjEo8vEIsswOEWBPL iitzDzFKcDArifAGHQUK8aYkVlalFuXHF5XmpBYfYpTmYFES532wZWaAkEB6YklqdmpqQWoR TJaJg1OqgbGvo+6at00T37GyDtH9R7zF573SEjC/9MeS3eVXkAPX38XHTPzZ7x3cVmX7bcr0 M1dVmN/O2FhSdet2aejdK1r/VrZtUGxfHnplb5988b4dkVWbQjY02h2LcXy7ZbH9hJv2u7sd lN+GMFWfXPbt7aXgCzcn3l3/SqGqcdbqzduCs8S89lRd/LZbiaU4I9FQi7moOBEAypmrQ08C AAA= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MTI codec discussion, request to postpone X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2012 16:14:47 -0000 --Boundary_(ID_EMTP4CvcGDAPO4fcN8AObw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Nov 8, 2012, at 14:55 , Serge Lachapelle wrote: > All, > > Google understands that concerns have been raised within the IETF RTCWEB WG in regards to VP8 IPR. We endeavored to properly address these concerns in time for this IETF meeting but did not meet the deadline. whoa, whoa. this has been on the agenda for quite a long time, and other people have gone to quite some trouble to prepare for and attend the meeting. > We hereby commit to addressing this by the next IETF meeting in Orlando. Our proposal will address prevalent IPR issues. > > Google believes strongly that the VP8 codec is the best technical option for a mandatory to implement codec. The best *technical* option is almost certainly something widely deployed, implemented, and understood. :-) > We therefore kindly ask to postpone this decision and hope the workgoup will take this opportunity to make progress on other vital topics. Perhaps a courtesy delay is appropriate, perhaps not, but asking so late is not good. Even 24 hours notice would have been courteous. This not a 'VP8 project', VP8 stands as a possible candidate, one of a set. It seems you are having trouble putting it formally on the table. Are you sure that those troubles can be resolved in a defined interval? David Singer Multimedia and Software Standards, Apple Inc. --Boundary_(ID_EMTP4CvcGDAPO4fcN8AObw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable sergel@webrtc.org> = wrote:

All,<= /div>

Google understands that concerns have been = raised within the IETF RTCWEB WG in regards to VP8 IPR. We endeavored to = properly address these concerns in time for this IETF meeting but did = not meet the deadline.

whoa, = whoa.  this has been on the agenda for quite a long time, and other = people have gone to quite some trouble to prepare for and attend the = meeting.

We hereby commit to addressing this by the next IETF meeting in = Orlando. Our  proposal will address prevalent IPR = issues.

Google believes strongly that the VP8 = codec is the best technical option for a mandatory to implement = codec. 

The best *technical* = option is almost certainly something widely deployed, implemented, and = understood. :-)

We therefore kindly ask to postpone this decision and hope the = workgoup will take this opportunity to make progress on other vital = topics.

Perhaps a courtesy delay = is appropriate, perhaps not, but asking so late is not good.  Even = 24 hours notice would have been courteous.

This = not a 'VP8 project', VP8 stands as a possible candidate, one of a set. = It seems you are having trouble putting it formally on the table. Are = you sure that those troubles can be resolved in a defined = interval?

David Singer
Multimedia and Software = Standards, Apple Inc.

= --Boundary_(ID_EMTP4CvcGDAPO4fcN8AObw)-- From harald@alvestrand.no Thu Nov 8 08:26:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7654D21F85F4 for ; Thu, 8 Nov 2012 08:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.913 X-Spam-Level: X-Spam-Status: No, score=-109.913 tagged_above=-999 required=5 tests=[AWL=0.686, 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 Iy3Pva6GTjs8 for ; Thu, 8 Nov 2012 08:26:30 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 37FEF21F8B7E for ; Thu, 8 Nov 2012 08:24:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BDBE39E029 for ; Thu, 8 Nov 2012 17:24:13 +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 ghVKf6AzJm1a for ; Thu, 8 Nov 2012 17:24:12 +0100 (CET) Received: from [IPv6:2001:df8:0:16:64b4:1954:eff9:cc33] (unknown [IPv6:2001:df8:0:16:64b4:1954:eff9:cc33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4626F39E01E for ; Thu, 8 Nov 2012 17:24:12 +0100 (CET) Message-ID: <509BDCAA.60601@alvestrand.no> Date: Thu, 08 Nov 2012 17:24:10 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.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] the problem with (no) remote stats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2012 16:26:31 -0000 On 11/08/2012 03:48 PM, Martin Thomson wrote: > I believe that the decision was to structure the stats, not to remove > remote stats entirely. Harald and I may have grossly different > remembrances. As I said in the room, my interpretation of what we agreed on was that we'd have one stats object for each side of the connection, with appropriate identifiers/pointers/references so that we can find both ends. We don't have synchronized stats from the 2 ends (given that we have no global clock, and given the somewhat-randomized sending times for RTCP stats), so the synchronization problem is hard anyway. > > On 8 November 2012 09:46, Romascanu, Dan (Dan) wrote: >> Concerning the remote stats aspect - While the discussion may indeed >> belong to the w3c webrtc wg where the APIs are discussed, the argument I >> believe should concern the rtcweb community as well. Statistics on a >> two-ends (or multiple ends) session do not have too much use without >> getting information from all hosts, and synchronizing it. These stats >> will no longer serve the monitoring of one host but of two or more >> browsers participating in the session. Thus the timestamp is critical. >> Taking out the remote component of the object while simplifies the API >> on the hosts makes the life of operators more complicated, as now >> operators need to access remotely two (or more) hosts instead the one >> and perform the time synchronization in their applications. >> >> Regards, >> >> Dan >> >> >> >> _______________________________________________ >> 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 Thu Nov 8 08:30:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9E221F8467 for ; Thu, 8 Nov 2012 08:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.872 X-Spam-Level: X-Spam-Status: No, score=-3.872 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 F3D2tENY9Fvn for ; Thu, 8 Nov 2012 08:30:57 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02921F8450 for ; Thu, 8 Nov 2012 08:30:56 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so2527567lbo.31 for ; Thu, 08 Nov 2012 08:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XIP/eqzkQ5zfx109LrUMowZAFilj2+V71KcjPVqVZdk=; b=dpQXa6TBlT1uVNCvG2lSDgNCFJOha98eFCtrSKkUAWFlYmCu0QRqKz0EuuLTtzlJgr 9GDVKa5SHB0rPhV/wQWx7dxdllhMjn/L/yTeetOYYRIrP55ZF3CChFVneck0AZ9eBKnE XNHe4ppc6Ds3gwAdGVQMuJRvoyHZcyELmKhbw2Mdi5t7/kZbf3HdQSTwhv2gwibdK5zA x95YH6wJ81Lt8YhLhifH+emUcF7fXTJYBPHZSuwNZX8tXNMAiIsBbOwVT+hsiD0iovTq 0LupOveyHpnGYSZyJMqHZgeyj2uf2shoqqqIeGQ+MwDGSyEXaOHBVVhC04j3L7hRe9wm i6rg== MIME-Version: 1.0 Received: by 10.152.148.8 with SMTP id to8mr8206064lab.2.1352392255934; Thu, 08 Nov 2012 08:30:55 -0800 (PST) Received: by 10.112.83.2 with HTTP; Thu, 8 Nov 2012 08:30:55 -0800 (PST) In-Reply-To: <509BDCAA.60601@alvestrand.no> References: <509BDCAA.60601@alvestrand.no> Date: Thu, 8 Nov 2012 11:30:55 -0500 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] the problem with (no) remote stats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2012 16:30:58 -0000 We haven't seen a concrete proposal, so until we do, this is hard to resolve. On 8 November 2012 11:24, Harald Alvestrand wrote: > On 11/08/2012 03:48 PM, Martin Thomson wrote: >> >> I believe that the decision was to structure the stats, not to remove >> remote stats entirely. Harald and I may have grossly different >> remembrances. > > As I said in the room, my interpretation of what we agreed on was that we'd > have one stats object for each side of the connection, with appropriate > identifiers/pointers/references so that we can find both ends. > > We don't have synchronized stats from the 2 ends (given that we have no > global clock, and given the somewhat-randomized sending times for RTCP > stats), so the synchronization problem is hard anyway. > > >> >> On 8 November 2012 09:46, Romascanu, Dan (Dan) wrote: >>> >>> Concerning the remote stats aspect - While the discussion may indeed >>> belong to the w3c webrtc wg where the APIs are discussed, the argument I >>> believe should concern the rtcweb community as well. Statistics on a >>> two-ends (or multiple ends) session do not have too much use without >>> getting information from all hosts, and synchronizing it. These stats >>> will no longer serve the monitoring of one host but of two or more >>> browsers participating in the session. Thus the timestamp is critical. >>> Taking out the remote component of the object while simplifies the API >>> on the hosts makes the life of operators more complicated, as now >>> operators need to access remotely two (or more) hosts instead the one >>> and perform the time synchronization in their applications. >>> >>> Regards, >>> >>> Dan >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ietf@meetecho.com Fri Nov 9 09:07:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AC321F8775 for ; Fri, 9 Nov 2012 09:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9bg+7mID5Wl for ; Fri, 9 Nov 2012 09:07:40 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id E453E21F876C for ; Fri, 9 Nov 2012 09:07:37 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV7b1k00x0ELJoa01V7ca2; Fri, 09 Nov 2012 18:07:36 +0100 Message-ID: <509D3855.60707@meetecho.com> Date: Fri, 09 Nov 2012 18:07:33 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Meetecho session recording X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2012 17:07:41 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From lazarmb@yahoo.com Fri Nov 9 21:55:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A4B21F84D5 for ; Fri, 9 Nov 2012 21:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jusSMSXcdU7O for ; Fri, 9 Nov 2012 21:55:19 -0800 (PST) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7721F8604 for ; Fri, 9 Nov 2012 21:55:18 -0800 (PST) Received: from [98.139.214.32] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 05:55:14 -0000 Received: from [98.139.212.248] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 05:55:14 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 05:55:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 394135.33383.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 91254 invoked by uid 60001); 10 Nov 2012 05:55:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352526914; bh=7JyNoK/JFS+tl0++lXib4iMvo9ebYovoRkaHbKyNdDA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=UWtHoy4iGEYqi9KIhfULL+z9od4dcdY11pElhHYJ8f/VbvPIFl0pqIAdUpBCnHcSUf/6dMohF6nSFVQLvta72g0RGHs8lzpQXqqwk1K4+GOe3cF6tijkOEKyeJ2u80TTzW6evt3ygEkd63gVJZf3+czf0+H5rn9yXLKXJ4rnO8k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=oZhVyLT7WxFkrCGHMyrQK+gOS/58DHMB5P4wDVIlCHJLspJWU6RTtmylaWigeRb+PPAdaqRH+GosDlp/1PzUYgAnOG0/v5cl4SuZm/pzuNEvGfdFupzd3tHJ1z6NvCO3swoQyUmnHpZOBoALrdCQossbZHn/eqcEmXCtV7lGx6M=; X-YMail-OSG: umCPVNwVM1lYtZRCJm98Na3YeBc7tNZ82wKk7QzkgNXW8gY RKy8x7L7ooN_W9mozlKyer42qx44oPksDuQM..y4CWCHvbwkzgsqxZHRMz8W 3EkYOX.O1psPLgEna8hhc4JzH_C3UG0vnv9VFcvDzTPQ9SazoFAiQKJyZkgD 1WNvRgCdFq9hoLhGCPlgoT7rIga6ZFdpfRATNLREZUkJVvi9w7wYBCrvbli1 PV6M7i.wkhz73rm_RbpK8zfH6LWxgQ65QeKnK3jAfTZnJbXXDQNfkXKXRCFA NHlgYB6pxpLSZuzrAmh2Bl4HLXUx_EAssbCeiGtUN6Xtbasq6FvBwCqUvEOI 3whtXdekEIkSmQkR_8047alWdZCPwfgVAUrl4FFKuYAzg0db_KyCig5NiMiE 442sPYusgO.KQFoHGsqZGGVTpBDpxZSb.BsijoG_l9YlKzykt141mZxS7U8V BCrHEwcs7rUTUJ2uiM4BNUVlTHIbY3KnfWT1GyWl3_2l1G2Old84yeXK9x.4 aito- Received: from [69.181.125.120] by web140803.mail.bf1.yahoo.com via HTTP; Fri, 09 Nov 2012 21:55:14 PST X-Rocket-MIMEInfo: 001.001, SGkgUm9uLAoKVGhlIGJlc3QgaW50ZXJwcmV0YXRpb24gd291bGQgaGF2ZSB0byBiZSBmcm9tIEZyYXVuaG9mZXIgSEhJLgoKTXkgdW5kZXJzdGFuZGluZyBvZiB0aGlzIHN0YXRlbWVudCwgYXMgYSBwYXJ0aWNpcGFudCBpbiB0aGUgSVNPIApJbnRlcm5ldCBWaWRlbyBDb2RpbmcgcHJvamVjdCwgaXMgdGhhdCB0aGUgbGljZW5zZSBpcyBnaXZlbiB0byB0aGUKTVBFRy00IFBhcnQgMjkgKFdlYlZDKSBzdGFuZGFyZCBvbmx5LCB3aGljaCBpcyBhIHJveWFsdHktZnJlZQpzdGFuZGFyZCBhbmQgaXMgZXF1aXZhbGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <3501F1E2-D75F-4A92-A7C6-392BC37AA36A@apple.com> <20121107084831.GB6812@audi.shelbyville.oz> Message-ID: <1352526914.90661.YahooMailNeo@web140803.mail.bf1.yahoo.com> Date: Fri, 9 Nov 2012 21:55:14 -0800 (PST) From: Lazar Bivolarski To: Ron , "rtcweb@ietf.org" In-Reply-To: <20121107084831.GB6812@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1957186862-1684146584-1352526914=:90661" Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Lazar Bivolarski List-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, 10 Nov 2012 05:55:20 -0000 ---1957186862-1684146584-1352526914=:90661 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ron,=0A=0AThe best interpretation would have to be from Fraunhofer HHI.= =0A=0AMy understanding of this statement, as a participant in the ISO =0AIn= ternet Video Coding project, is that the license is given to the=0AMPEG-4 P= art 29 (WebVC) standard only, which is a royalty-free=0Astandard and is equ= ivalent to MPEG-4 AVC / H.264 Constrained=0ABaseline Profile.=A0 =0A=0AThe = language used in the Fraunhofer HHI's statement specifically=0Aexcludes the= possibility of licensing their IP in other standards.=0A=0ARegards,=0A=0AL= azar. =A0 =0A=0A=0A=0A=0A=0A________________________________=0A From: Ron <= ron@debian.org>=0ATo: rtcweb@ietf.org =0ASent: Wednesday, November 7, 2012 = 12:48 AM=0ASubject: Re: [rtcweb] Incoming liaison statement from MPEG=0A = =0AOn Tue, Nov 06, 2012 at 09:29:13AM +0100, David Singer wrote:=0A> As an = example of the patent statements received, I am pleased to be able to=0A> f= orward the following from Fraunhofer HHI (forwarded with permission):=0A> = =0A> Begin forwarded message:=0A> =0A> > Subject: Re: [rtcweb] Incoming lia= ison statement from MPEG=0A> > Date: November 5, 2012 23:37:57 GMT+01:00=0A= > > =0A> > Dear all,=0A> > =0A> > we, Fraunhofer HHI, have submitted a stat= ement for IVCT that declares our=0A> > IPR under condition 2 (RAND) of the = ISO patent policy. However, we have=0A> > also submitted an additional stat= ement to ISO with the following contents=0A> > (and I believe others did as= well):=0A> > =0A> > "In the event that the Patent Holder holds granted and= /or pending=0A> > applications for patents, the use of which would be requi= red to implement=0A> > the Constrained Baseline Profile proposed in N 12733= and the Constrained=0A> > Baseline Profile is approved as the new proposed= IVCT royalty-free=0A> > Standard, Patent Holder is prepared to grant a Typ= e 1 license comparable to=0A> > option 1, including reciprocity and reserva= tion of rights suboptions=0A> > therein, of the Patent Statement and Licens= ing Declaration for ITU-T /ITU-R=0A> > Recommendation and ISO/IEC Deliverab= le (FORM: 1 March 2007) for use in an=0A> > internet video codec that imple= ments solely the Constrained Baseline=0A> > Profile, provided that all othe= r patent holders do the same. The license=0A> > would not extend to other P= rofiles or other implementations."=0A=0ADoes "The license would not extend = to ... other implementations" really mean=0Athat they would licence *just* = the reference implementation produced by that=0Agroup, and that any other i= mplementation would still need a separate licence?=0A=0ANot extending to ot= her Profiles seems obvious enough - but not permitting=0Aother implementati= ons seems ...=A0 limiting.=0A=0AI know legalese likes to be ambiguous where= that is in its favour, so it's=0Anot clear if that is really the intent --= but it's not clear from this that=0Ait is not either.=0A=0ACan anyone clar= ify the actual intent of that language one way or the other?=0A=0A=A0 Cheer= s,=0A=A0 Ron=0A=0A=0A_______________________________________________=0Artcw= eb mailing list=0Artcweb@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/r= tcweb ---1957186862-1684146584-1352526914=:90661 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ron,

The be= st interpretation would have to be from Fraunhofer HHI.

My understan= ding of this statement, as a participant in the ISO
Internet Video Codi= ng project, is that the license is given to the
MPEG-4 Part 29 (WebVC) s= tandard only, which is a royalty-free
standard and is equivalent to MPEG= -4 AVC / H.264 Constrained
Baseline Profile. 

The language = used in the Fraunhofer HHI's statement specifically
excludes the possibi= lity of licensing their IP in other standards.

Regards,

Lazar= .  


<= /div>
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Incoming liaison s= tatement from MPEG

On Tue, Nov 06, 2012 at 09:29:13A= M +0100, David Singer wrote:
> As an example of the patent statements= received, I am pleased to be able to
> forward the following from Fr= aunhofer HHI (forwarded with permission):
>
> Begin forwarded = message:
>
> > Subject: Re: [rtcweb] Incoming liaison state= ment from MPEG
> > Date: November 5, 2012 23:37:57 GMT+01:00
&g= t; >
> > Dear all,
> >
> > we, Fraunhofer H= HI, have submitted a statement for IVCT that declares our
> > IPR = under condition 2 (RAND) of the ISO patent policy. However, we have
> >= also submitted an additional statement to ISO with the following contents<= br>> > (and I believe others did as well):
> >
> >= "In the event that the Patent Holder holds granted and/or pending
> = > applications for patents, the use of which would be required to implem= ent
> > the Constrained Baseline Profile proposed in N 12733 and t= he Constrained
> > Baseline Profile is approved as the new propose= d IVCT royalty-free
> > Standard, Patent Holder is prepared to gra= nt a Type 1 license comparable to
> > option 1, including reciproc= ity and reservation of rights suboptions
> > therein, of the Paten= t Statement and Licensing Declaration for ITU-T /ITU-R
> > Recomme= ndation and ISO/IEC Deliverable (FORM: 1 March 2007) for use in an
> = > internet video codec that implements solely the Constrained Baseline
> > Profile, provided that all other patent holders do t= he same. The license
> > would not extend to other Profiles or oth= er implementations."

Does "The license would not extend to ... other= implementations" really mean
that they would licence *just* the referen= ce implementation produced by that
group, and that any other implementat= ion would still need a separate licence?

Not extending to other Prof= iles seems obvious enough - but not permitting
other implementations see= ms ...  limiting.

I know legalese likes to be ambiguous where t= hat is in its favour, so it's
not clear if that is really the intent -- = but it's not clear from this that
it is not either.

Can anyone cl= arify the actual intent of that language one way or the other?

 = ; Cheers,
  Ron


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

---1957186862-1684146584-1352526914=:90661-- From ron@debian.org Sat Nov 10 03:15:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F5E21F853A for ; Sat, 10 Nov 2012 03:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=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 dBhRoDTBPi75 for ; Sat, 10 Nov 2012 03:15:23 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 5E42E21F84BD for ; Sat, 10 Nov 2012 03:15:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD42nlB20lPf/2dsb2JhbABDw1SBCYIeAQEBAwEBAQEvASMYCwULCxEBAgEBAQEuFBMFDRAGDhOIBAUMvRQEjBWFaWEDjg6HbAGQQ4MC Received: from ppp118-210-83-223.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.83.223]) by ipmail05.adl6.internode.on.net with ESMTP; 10 Nov 2012 21:45:20 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id C7FE04F8F3; Sat, 10 Nov 2012 21:45:18 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8oZDXdBk9yXf; Sat, 10 Nov 2012 21:45:17 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 281FD4F902; Sat, 10 Nov 2012 21:45:17 +1030 (CST) Date: Sat, 10 Nov 2012 21:45:17 +1030 From: Ron To: Lazar Bivolarski Message-ID: <20121110111517.GC3822@audi.shelbyville.oz> References: <3501F1E2-D75F-4A92-A7C6-392BC37AA36A@apple.com> <20121107084831.GB6812@audi.shelbyville.oz> <1352526914.90661.YahooMailNeo@web140803.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1352526914.90661.YahooMailNeo@web140803.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Nov 2012 11:15:23 -0000 Hi Lazar, On Fri, Nov 09, 2012 at 09:55:14PM -0800, Lazar Bivolarski wrote: > Hi Ron, > > The best interpretation would have to be from Fraunhofer HHI. Yeah, I wasn't expecting that David could elaborate on that himself, he was clear about just being the messenger, but I figure if people here are in contact with them, we might be able to get a more direct clarification about that - for both their benefit and ours. > My understanding of this statement, as a participant in the ISO > Internet Video Coding project, is that the license is given to the > MPEG-4 Part 29 (WebVC) standard only, which is a royalty-free > standard and is equivalent to MPEG-4 AVC / H.264 Constrained > Baseline Profile.  > > The language used in the Fraunhofer HHI's statement specifically > excludes the possibility of licensing their IP in other standards. Right, that's what I understood the "other Profiles" exclusion to mean. It was the "other implementations" addition to that which isn't quite so clear to me. By listing it separately I assume they mean something different to "other Profiles" -- and the only 'obvious' interpretation I see at present is that they would only be licencing the specific reference implementation that the IVC group produced and not any other. I'm hoping to be wrong about that though, since that would seem to preclude being able to port it to other architectures if needed, fix bugs if found, or to further optimise the code for specific architectures to achieve acceptable performance on them. The latter seems kind of important since it was stressed by some folk in the Video Codec group discussion that a reference codec is often a "toy" implementation, that is easy to read and perform conformance tests with, but not really suitable for real world real-time deployment. Even a reasonably optimised one couldn't really hope to be optimal for every architecture present and future - so the ability to make "other implementations" of the licenced Profile does seem fairly essential to it being usefully RF rather than just ostensibly, but not very practically so. Unless of course they mean something entirely different by the word "implementation", which is the bit I was hoping somebody might be able to shed some more light on for us -- since I do accept that's also quite possible, it's just not something that we can guess for ourselves in any meaningful way without Fraunhofer HHI telling us what _they_ intended it to mean. Thanks, Ron > ________________________________ > From: Ron > To: rtcweb@ietf.org > Sent: Wednesday, November 7, 2012 12:48 AM > Subject: Re: [rtcweb] Incoming liaison statement from MPEG > > On Tue, Nov 06, 2012 at 09:29:13AM +0100, David Singer wrote: > > As an example of the patent statements received, I am pleased to be able to > > forward the following from Fraunhofer HHI (forwarded with permission): > > > > Begin forwarded message: > > > > > Subject: Re: [rtcweb] Incoming liaison statement from MPEG > > > Date: November 5, 2012 23:37:57 GMT+01:00 > > > > > > Dear all, > > > > > > we, Fraunhofer HHI, have submitted a statement for IVCT that declares our > > > IPR under condition 2 (RAND) of the ISO patent policy. However, we have > > > also submitted an additional statement to ISO with the following contents > > > (and I believe others did as well): > > > > > > "In the event that the Patent Holder holds granted and/or pending > > > applications for patents, the use of which would be required to implement > > > the Constrained Baseline Profile proposed in N 12733 and the Constrained > > > Baseline Profile is approved as the new proposed IVCT royalty-free > > > Standard, Patent Holder is prepared to grant a Type 1 license comparable to > > > option 1, including reciprocity and reservation of rights suboptions > > > therein, of the Patent Statement and Licensing Declaration for ITU-T /ITU-R > > > Recommendation and ISO/IEC Deliverable (FORM: 1 March 2007) for use in an > > > internet video codec that implements solely the Constrained Baseline > > > Profile, provided that all other patent holders do the same. The license > > > would not extend to other Profiles or other implementations." > > Does "The license would not extend to ... other implementations" really mean > that they would licence *just* the reference implementation produced by that > group, and that any other implementation would still need a separate licence? > > Not extending to other Profiles seems obvious enough - but not permitting > other implementations seems ...  limiting. > > I know legalese likes to be ambiguous where that is in its favour, so it's > not clear if that is really the intent -- but it's not clear from this that > it is not either. > > Can anyone clarify the actual intent of that language one way or the other? > >   Cheers, >   Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Sat Nov 10 13:17:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506BF21F8745 for ; Sat, 10 Nov 2012 13:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.011 X-Spam-Level: X-Spam-Status: No, score=-110.011 tagged_above=-999 required=5 tests=[AWL=0.588, 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 9rsCT+t-pD7F for ; Sat, 10 Nov 2012 13:17:13 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 396C321F8738 for ; Sat, 10 Nov 2012 13:17:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5B5439E11A for ; Sat, 10 Nov 2012 22:17:08 +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 0Z+ue+xyzGEr for ; Sat, 10 Nov 2012 22:17:07 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:492a:da8a:584b:d487] (unknown [IPv6:2001:470:de0a:27:492a:da8a:584b:d487]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1C06939E04C for ; Sat, 10 Nov 2012 22:17:07 +0100 (CET) Message-ID: <509EC452.9060600@alvestrand.no> Date: Sat, 10 Nov 2012 22:17:06 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3501F1E2-D75F-4A92-A7C6-392BC37AA36A@apple.com> <20121107084831.GB6812@audi.shelbyville.oz> <1352526914.90661.YahooMailNeo@web140803.mail.bf1.yahoo.com> <20121110111517.GC3822@audi.shelbyville.oz> In-Reply-To: <20121110111517.GC3822@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Nov 2012 21:17:14 -0000 On 11/10/2012 12:15 PM, Ron wrote: > Hi Lazar, > > On Fri, Nov 09, 2012 at 09:55:14PM -0800, Lazar Bivolarski wrote: >> Hi Ron, >> >> The best interpretation would have to be from Fraunhofer HHI. > Yeah, I wasn't expecting that David could elaborate on that himself, > he was clear about just being the messenger, but I figure if people > here are in contact with them, we might be able to get a more direct > clarification about that - for both their benefit and ours. > >> My understanding of this statement, as a participant in the ISO >> Internet Video Coding project, is that the license is given to the >> MPEG-4 Part 29 (WebVC) standard only, which is a royalty-free >> standard and is equivalent to MPEG-4 AVC / H.264 Constrained >> Baseline Profile. >> >> The language used in the Fraunhofer HHI's statement specifically >> excludes the possibility of licensing their IP in other standards. > Right, that's what I understood the "other Profiles" exclusion to mean. > It was the "other implementations" addition to that which isn't quite > so clear to me. > > By listing it separately I assume they mean something different to > "other Profiles" -- and the only 'obvious' interpretation I see at > present is that they would only be licencing the specific reference > implementation that the IVC group produced and not any other. > > I'm hoping to be wrong about that though, since that would seem to > preclude being able to port it to other architectures if needed, > fix bugs if found, or to further optimise the code for specific > architectures to achieve acceptable performance on them. > > The latter seems kind of important since it was stressed by some > folk in the Video Codec group discussion that a reference codec is > often a "toy" implementation, that is easy to read and perform > conformance tests with, but not really suitable for real world > real-time deployment. Even a reasonably optimised one couldn't > really hope to be optimal for every architecture present and > future - so the ability to make "other implementations" of the > licenced Profile does seem fairly essential to it being usefully > RF rather than just ostensibly, but not very practically so. > > Unless of course they mean something entirely different by the > word "implementation", which is the bit I was hoping somebody > might be able to shed some more light on for us -- since I do > accept that's also quite possible, it's just not something > that we can guess for ourselves in any meaningful way without > Fraunhofer HHI telling us what _they_ intended it to mean. It wouldn't be totally unreasonable to assume that "implementation" refers to the phrase a little earlier: "for use in an internet video codec that implements solely the Constrained Baseline Profile" - that is, if the codec implements (for instance) full Baseline, you need a license from Fraunhofer, even if the difference between constrained Baseline and full Baseline is not covered by Fraunhofer's patents. Of course, this is uninformed speculation. I have no idea what Fraunhofer's patents are; if they want to tell us more about what the license means, they'll tell us. > > Thanks, > Ron > > > >> ________________________________ >> From: Ron >> To: rtcweb@ietf.org >> Sent: Wednesday, November 7, 2012 12:48 AM >> Subject: Re: [rtcweb] Incoming liaison statement from MPEG >> >> On Tue, Nov 06, 2012 at 09:29:13AM +0100, David Singer wrote: >>> As an example of the patent statements received, I am pleased to be able to >>> forward the following from Fraunhofer HHI (forwarded with permission): >>> >>> Begin forwarded message: >>> >>>> Subject: Re: [rtcweb] Incoming liaison statement from MPEG >>>> Date: November 5, 2012 23:37:57 GMT+01:00 >>>> >>>> Dear all, >>>> >>>> we, Fraunhofer HHI, have submitted a statement for IVCT that declares our >>>> IPR under condition 2 (RAND) of the ISO patent policy. However, we have >>>> also submitted an additional statement to ISO with the following contents >>>> (and I believe others did as well): >>>> >>>> "In the event that the Patent Holder holds granted and/or pending >>>> applications for patents, the use of which would be required to implement >>>> the Constrained Baseline Profile proposed in N 12733 and the Constrained >>>> Baseline Profile is approved as the new proposed IVCT royalty-free >>>> Standard, Patent Holder is prepared to grant a Type 1 license comparable to >>>> option 1, including reciprocity and reservation of rights suboptions >>>> therein, of the Patent Statement and Licensing Declaration for ITU-T /ITU-R >>>> Recommendation and ISO/IEC Deliverable (FORM: 1 March 2007) for use in an >>>> internet video codec that implements solely the Constrained Baseline >>>> Profile, provided that all other patent holders do the same. The license >>>> would not extend to other Profiles or other implementations." >> Does "The license would not extend to ... other implementations" really mean >> that they would licence *just* the reference implementation produced by that >> group, and that any other implementation would still need a separate licence? >> >> Not extending to other Profiles seems obvious enough - but not permitting >> other implementations seems ... limiting. >> >> I know legalese likes to be ambiguous where that is in its favour, so it's >> not clear if that is really the intent -- but it's not clear from this that >> it is not either. >> >> Can anyone clarify the actual intent of that language one way or the other? >> >> Cheers, >> Ron >> >> >> _______________________________________________ >> 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 lazarmb@yahoo.com Sat Nov 10 15:52:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F6021F87B9 for ; Sat, 10 Nov 2012 15:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 i9lA1kE7nSNH for ; Sat, 10 Nov 2012 15:52:08 -0800 (PST) Received: from nm17-vm0.bullet.mail.bf1.yahoo.com (nm17-vm0.bullet.mail.bf1.yahoo.com [98.139.213.157]) by ietfa.amsl.com (Postfix) with ESMTP id 3817E21F87B5 for ; Sat, 10 Nov 2012 15:52:08 -0800 (PST) Received: from [98.139.212.146] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 23:52:07 -0000 Received: from [98.139.215.251] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 23:52:07 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 23:52:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 638634.21402.bm@omp1064.mail.bf1.yahoo.com Received: (qmail 94844 invoked by uid 60001); 10 Nov 2012 23:52:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352591527; bh=UO6dTiZuV3cUTDltzjP4ZDI+Wohr1DxQXrlznOBlRPY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2XA60eaDGh2TIOf2vXbwojc99uLVJ6ISM6pP5rZPFFMfoO95yOtzIYOgty2EpvTVtHlQIibLWJt1mvOGFUi96EVO/QJ1rcl+O5AV/NSDupaNXJqu4Lw+mmRql6/YrE/nMHqIO4gkhxjcR5MawdBblq+50AA/ISgxBqdTyyFgMME= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g+cY/zSM2loAkaW9nmbWtmDwrf8ARtcM2Xsv4h+Ezv4XmTigkaR7hC3/6XVGDs/Nri+NwH1zastjzqUBWHV5RWLXpLJHOleMNWJKXgWKmFoEvK0QfAAm30F4my5pHqayg0QEQXZgbF6QCDNK5CuhxEj5eHQ1UA0Fs/ih1A05Pjk=; X-YMail-OSG: 2OxCtVoVM1n3ubNA3N0rVKL_Gx9Z1V__hUWXOsxU_2fEXXC EKLoe2PI0eno9qDj_U2lzM4olqk9ASCEHYx7WRkENUqDB1Ix2uO2sMTTWZa1 96znrLrntIr3rw29cVN6wPqVPUIrXyjJNouEBE8C6FF1Gy2XpjSslBD2Eejh dyYIUMH8SkF9K4H1loMrjQOrJGTFb.bb6OAhs2lfMicQn8FEHV18XNJI54LY kl2f1R80wngc4hgTW8Zc7ewdO081vprdypLeIiIQKVlNp9U72sxfWmLKZ91Q U.E3WqxBCXqb7O83CIes0JRUz4rkOhHUgui2ca4gf1Y7E_c9KeHSPFBbYjRv pNstbyVaSuhR_zuy3haMokc4q1Hmz9BL4AznphBle1Rc7OWViAC9ZP24pdvJ 666.sDN7q.R5TE9QF6X1eduxB2sZzWcAwIm7vBBN7SLm_GIAGtqL3EU1d8bc 7tYGbv1uYpyDCk.zBFutBWcJBqy0pIdf2alvAJVXM7U54e1aWLnWXmLx8_k9 Suds- Received: from [69.181.125.120] by web140805.mail.bf1.yahoo.com via HTTP; Sat, 10 Nov 2012 15:52:07 PST X-Rocket-MIMEInfo: 001.001, SGkgSGFyYWxkLAoKWW91ciBpbnRlcnByZXRhdGlvbiBpcyBjb3JyZWN0LiBUaGUgbGljZW5zZSBpcyBnaXZlbiB0byBhbiAiaW1wbGVtZW50YXRpb24iIHdpdGjCoCBpbiB0aGlzIAoKY2FzZSBtZWFucyB0aGUgbmV3IEludGVybmV0IFZpZGVvIENvZGluZyBzdGFuZGFyZCBvciBNUEVHLTQ6UGFydCAyOSAoV2ViVkMpLgoKSnVzdCB0byBjbGFyaWZ5IHRoZSBsaWNlbnNlIGluIElFQy9JU08gcG9saWNpZXMgaXMgbm90IGdpdmVuIHRvIGEgcmVmZXJlbmNlIHNvZnR3YXJlIHRoYXQKaW1wbGVtZW50cyBhIHBhcnQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <3501F1E2-D75F-4A92-A7C6-392BC37AA36A@apple.com> <20121107084831.GB6812@audi.shelbyville.oz> <1352526914.90661.YahooMailNeo@web140803.mail.bf1.yahoo.com> <20121110111517.GC3822@audi.shelbyville.oz> <509EC452.9060600@alvestrand.no> Message-ID: <1352591527.92315.YahooMailNeo@web140805.mail.bf1.yahoo.com> Date: Sat, 10 Nov 2012 15:52:07 -0800 (PST) From: Lazar Bivolarski To: Harald Alvestrand , "rtcweb@ietf.org" In-Reply-To: <509EC452.9060600@alvestrand.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1230856681-480068995-1352591527=:92315" Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Lazar Bivolarski List-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, 10 Nov 2012 23:52:10 -0000 --1230856681-480068995-1352591527=:92315 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Harald,=0A=0AYour interpretation is correct. The license is given to an = "implementation" with=A0 in this =0A=0Acase means the new Internet Video Co= ding standard or MPEG-4:Part 29 (WebVC).=0A=0AJust to clarify the license i= n IEC/ISO policies is not given to a reference software that=0Aimplements a= particular standard's specification, but to the technology that is part of= the =0A=0Atext of the standard. Software implementing the standard should = be developed and =0A=0Aoptimized from manufacturers implementing the standa= rd. Reference code is provided=0Afor a reference only. Common practice at I= EC/ISO is bugs found in the reference code =0A=0Atobe fixed and accepted in= the reference code by the participants.=0A=0ARegards,=0A=0ALazar.=A0 =A0 = =0A=0A=0A=0A________________________________=0A From: Harald Alvestrand =0ATo: rtcweb@ietf.org =0ASent: Saturday, November 10, 2= 012 1:17 PM=0ASubject: Re: [rtcweb] Incoming liaison statement from MPEG=0A= =0AOn 11/10/2012 12:15 PM, Ron wrote:=0A> Hi Lazar,=0A>=0A> On Fri, Nov 09= , 2012 at 09:55:14PM -0800, Lazar Bivolarski wrote:=0A>> Hi Ron,=0A>>=0A>> = The best interpretation would have to be from Fraunhofer HHI.=0A> Yeah, I w= asn't expecting that David could elaborate on that himself,=0A> he was clea= r about just being the messenger, but I figure if people=0A> here are in co= ntact with them, we might be able to get a more direct=0A> clarification ab= out that - for both their benefit and ours.=0A>=0A>> My understanding of th= is statement, as a participant in the ISO=0A>> Internet Video Coding projec= t, is that the license is given to the=0A>> MPEG-4 Part 29 (WebVC) standard= only, which is a royalty-free=0A>> standard and is equivalent to MPEG-4 AV= C / H.264 Constrained=0A>> Baseline Profile.=0A>>=0A>> The language used in= the Fraunhofer HHI's statement specifically=0A>> excludes the possibility = of licensing their IP in other standards.=0A> Right, that's what I understo= od the "other Profiles" exclusion to mean.=0A> It was the "other implementa= tions" addition to that which isn't quite=0A> so clear to me.=0A>=0A> By li= sting it separately I assume they mean something different to=0A> "other Pr= ofiles" -- and the only 'obvious' interpretation I see at=0A> present is th= at they would only be licencing the specific reference=0A> implementation t= hat the IVC group produced and not any other.=0A>=0A> I'm hoping to be wron= g about that though, since that would seem to=0A> preclude being able to po= rt it to other architectures if needed,=0A> fix bugs if found, or to furthe= r optimise the code for specific=0A> architectures to achieve acceptable pe= rformance on them.=0A>=0A> The latter seems kind of important since it was = stressed by some=0A> folk in the Video Codec group discussion that a refere= nce codec is=0A> often a "toy" implementation, that is easy to read and per= form=0A> conformance tests with, but not really suitable for real world=0A>= real-time deployment.=A0 Even a reasonably optimised one couldn't=0A> real= ly hope to be optimal for every architecture present and=0A> future - so th= e ability to make "other implementations" of the=0A> licenced Profile does = seem fairly essential to it being usefully=0A> RF rather than just ostensib= ly, but not very practically so.=0A>=0A> Unless of course they mean somethi= ng entirely different by the=0A> word "implementation", which is the bit I = was hoping somebody=0A> might be able to shed some more light on for us -- = since I do=0A> accept that's also quite possible, it's just not something= =0A> that we can guess for ourselves in any meaningful way without=0A> Frau= nhofer HHI telling us what _they_ intended it to mean.=0A=0AIt wouldn't be = totally unreasonable to assume that "implementation" =0Arefers to the phras= e a little earlier: "for use in an internet video =0Acodec that implements = solely the Constrained Baseline Profile" - that =0Ais, if the codec impleme= nts (for instance) full Baseline, you need a =0Alicense from Fraunhofer, ev= en if the difference between constrained =0ABaseline and full Baseline is n= ot covered by Fraunhofer's patents.=0A=0AOf course, this is uninformed spec= ulation. I have no idea what =0AFraunhofer's patents are; if they want to t= ell us more about what the =0Alicense means, they'll tell us.=0A=0A>=0A>=A0= =A0 Thanks,=0A>=A0 =A0 Ron=0A>=0A>=0A>=0A>> ______________________________= __=0A>>=A0 From: Ron =0A>> To: rtcweb@ietf.org=0A>> Sent: = Wednesday, November 7, 2012 12:48 AM=0A>> Subject: Re: [rtcweb] Incoming li= aison statement from MPEG=0A>>=A0 =0A>> On Tue, Nov 06, 2012 at 09:29:13AM = +0100, David Singer wrote:=0A>>> As an example of the patent statements rec= eived, I am pleased to be able to=0A>>> forward the following from Fraunhof= er HHI (forwarded with permission):=0A>>>=0A>>> Begin forwarded message:=0A= >>>=0A>>>> Subject: Re: [rtcweb] Incoming liaison statement from MPEG=0A>>>= > Date: November 5, 2012 23:37:57 GMT+01:00=0A>>>>=0A>>>> Dear all,=0A>>>>= =0A>>>> we, Fraunhofer HHI, have submitted a statement for IVCT that declar= es our=0A>>>> IPR under condition 2 (RAND) of the ISO patent policy. Howeve= r, we have=0A>>>> also submitted an additional statement to ISO with the fo= llowing contents=0A>>>> (and I believe others did as well):=0A>>>>=0A>>>> "= In the event that the Patent Holder holds granted and/or pending=0A>>>> app= lications for patents, the use of which would be required to implement=0A>>= >> the Constrained Baseline Profile proposed in N 12733 and the Constrained= =0A>>>> Baseline Profile is approved as the new proposed IVCT royalty-free= =0A>>>> Standard, Patent Holder is prepared to grant a Type 1 license compa= rable to=0A>>>> option 1, including reciprocity and reservation of rights s= uboptions=0A>>>> therein, of the Patent Statement and Licensing Declaration= for ITU-T /ITU-R=0A>>>> Recommendation and ISO/IEC Deliverable (FORM: 1 Ma= rch 2007) for use in an=0A>>>> internet video codec that implements solely = the Constrained Baseline=0A>>>> Profile, provided that all other patent hol= ders do the same. The license=0A>>>> would not extend to other Profiles or = other implementations."=0A>> Does "The license would not extend to ... othe= r implementations" really mean=0A>> that they would licence *just* the refe= rence implementation produced by that=0A>> group, and that any other implem= entation would still need a separate licence?=0A>>=0A>> Not extending to ot= her Profiles seems obvious enough - but not permitting=0A>> other implement= ations seems ...=A0 limiting.=0A>>=0A>> I know legalese likes to be ambiguo= us where that is in its favour, so it's=0A>> not clear if that is really th= e intent -- but it's not clear from this that=0A>> it is not either.=0A>>= =0A>> Can anyone clarify the actual intent of that language one way or the = other?=0A>>=0A>>=A0 =A0 Cheers,=0A>>=A0 =A0 Ron=0A>>=0A>>=0A>> ____________= ___________________________________=0A>> rtcweb mailing list=0A>> rtcweb@ie= tf.org=0A>> https://www.ietf.org/mailman/listinfo/rtcweb=0A> ______________= _________________________________=0A> rtcweb mailing list=0A> rtcweb@ietf.o= rg=0A> https://www.ietf.org/mailman/listinfo/rtcweb=0A=0A__________________= _____________________________=0Artcweb mailing list=0Artcweb@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/rtcweb --1230856681-480068995-1352591527=:92315 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Harald,=

Your interpretation is = correct. The license is given to an "implementation" with  in this
case means the new Internet Video Coding standard = or MPEG-4:Part 29 (WebVC).

Just to clarify the license in IEC/ISO policies is not given to= a reference software that
implements a particular s= tandard's specification, but to the technology that is part of the
text of the standard. Software implementing the standar= d should be developed and
optimized from m= anufacturers implementing the standard. Reference code is provided
for a reference only. Common practice at IEC/ISO is bugs fou= nd in the reference code
to be fix= ed and accepted in the reference code by the participants.

Regards,
Lazar.   

From:= Harald Alvestrand <harald@alvestrand.no>
To: rtcweb@ietf.org
Sent: Saturday, November 10, 2012 1:17 PM
<= span style=3D"font-weight: bold;">Subject: Re: [rtcweb] Incoming lia= ison statement from MPEG

On 11/10/2012 12:15 PM, Ron= wrote:
> Hi Lazar,
>
> On Fri, Nov 09, 2012 at 09:55:14P= M -0800, Lazar Bivolarski wrote:
>> Hi Ron,
>>
>>= ; The best interpretation would have to be from Fraunhofer HHI.
> Yea= h, I wasn't expecting that David could elaborate on that himself,
> h= e was clear about just being the messenger, but I figure if people
> = here are in contact with them, we might be able to get a more direct
>= ; clarification about that - for both their benefit and ours.
>
&g= t;> My understanding of this statement, as a participant in the ISO
&= gt;> Internet Video Coding project, is that the license is given to the<= br>>> MPEG-4 Part 29 (WebVC) standard only, which is a royalty-free>> standard and is equivalent to MPEG-4 AVC / H.264 Constrained
>> Baseline Profile.
>>
>> The lang= uage used in the Fraunhofer HHI's statement specifically
>> exclud= es the possibility of licensing their IP in other standards.
> Right,= that's what I understood the "other Profiles" exclusion to mean.
> I= t was the "other implementations" addition to that which isn't quite
>= ; so clear to me.
>
> By listing it separately I assume they me= an something different to
> "other Profiles" -- and the only 'obvious= ' interpretation I see at
> present is that they would only be licenc= ing the specific reference
> implementation that the IVC group produc= ed and not any other.
>
> I'm hoping to be wrong about that tho= ugh, since that would seem to
> preclude being able to port it to oth= er architectures if needed,
> fix bugs if found, or to further optimi= se the code for specific
> architectures to achieve acceptable performance on them.
>
> The latter seems kind of important si= nce it was stressed by some
> folk in the Video Codec group discussio= n that a reference codec is
> often a "toy" implementation, that is e= asy to read and perform
> conformance tests with, but not really suit= able for real world
> real-time deployment.  Even a reasonably o= ptimised one couldn't
> really hope to be optimal for every architect= ure present and
> future - so the ability to make "other implementati= ons" of the
> licenced Profile does seem fairly essential to it being= usefully
> RF rather than just ostensibly, but not very practically = so.
>
> Unless of course they mean something entirely different= by the
> word "implementation", which is the bit I was hoping somebo= dy
> might be able to shed some more light on for us -- since I do> accept that's also quite possible, it's just not something
> that we can guess for ourselves in any meaningful way wi= thout
> Fraunhofer HHI telling us what _they_ intended it to mean.
It wouldn't be totally unreasonable to assume that "implementation" refers to the phrase a little earlier: "for use in an internet video
= codec that implements solely the Constrained Baseline Profile" - that
i= s, if the codec implements (for instance) full Baseline, you need a
lic= ense from Fraunhofer, even if the difference between constrained
Baseli= ne and full Baseline is not covered by Fraunhofer's patents.

Of cour= se, this is uninformed speculation. I have no idea what
Fraunhofer's pa= tents are; if they want to tell us more about what the
license means, t= hey'll tell us.

>
>    Thanks,
>  &nbs= p; Ron
>
>
>
>> ________________________________=
>>  From: Ron <ron@debian.org>
>> To: rtcweb@ie= tf.org
>> Sent: Wednesday, November 7, 2012 12:48 AM
>&g= t; Subject: Re: [rtcweb] Incoming liaison statement from MPEG
>>&n= bsp;
>> On Tue, Nov 06, 2012 at 09:29:13AM +0100, David Singer w= rote:
>>> As an example of the patent statements received, I am= pleased to be able to
>>> forward the following from Fraunhofe= r HHI (forwarded with permission):
>>>
>>> Begin fo= rwarded message:
>>>
>>>> Subject: Re: [rtcweb] = Incoming liaison statement from MPEG
>>>> Date: November 5, = 2012 23:37:57 GMT+01:00
>>>>
>>>> Dear all,>>>>
>>>> we, Fraunhofer HHI, have submitted a= statement for IVCT that declares our
>>>> IPR under condition 2 (RAND) of the ISO patent policy. However, we have
>>&= gt;> also submitted an additional statement to ISO with the following co= ntents
>>>> (and I believe others did as well):
>>&= gt;>
>>>> "In the event that the Patent Holder holds gran= ted and/or pending
>>>> applications for patents, the use of= which would be required to implement
>>>> the Constrained B= aseline Profile proposed in N 12733 and the Constrained
>>>>= Baseline Profile is approved as the new proposed IVCT royalty-free
>= >>> Standard, Patent Holder is prepared to grant a Type 1 license = comparable to
>>>> option 1, including reciprocity and reser= vation of rights suboptions
>>>> therein, of the Patent Stat= ement and Licensing Declaration for ITU-T /ITU-R
>>>> Recomm= endation and ISO/IEC Deliverable (FORM: 1 March 2007) for use in an
>>>> internet video codec that implements solely the Con= strained Baseline
>>>> Profile, provided that all other pate= nt holders do the same. The license
>>>> would not extend to= other Profiles or other implementations."
>> Does "The license wo= uld not extend to ... other implementations" really mean
>> that t= hey would licence *just* the reference implementation produced by that
&= gt;> group, and that any other implementation would still need a separat= e licence?
>>
>> Not extending to other Profiles seems ob= vious enough - but not permitting
>> other implementations seems .= ..  limiting.
>>
>> I know legalese likes to be ambi= guous where that is in its favour, so it's
>> not clear if that is= really the intent -- but it's not clear from this that
>> it is n= ot either.
>>
>> Can anyone clarify the actual intent of that language one way or the other?
>>
>> = ;   Cheers,
>>    Ron
>>
>>
&g= t;> _______________________________________________
>> rtcweb m= ailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mai= lman/listinfo/rtcweb
> __________________________________________= _____
> rtcweb mailing list
> rtcweb@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/rtcweb

_____________________________= __________________
rtcweb mailing list
rtcweb@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/rtcweb


<= /div> --1230856681-480068995-1352591527=:92315-- From gunnar.hellstrom@omnitor.se Mon Nov 12 01:06:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDB521F8539 for ; Mon, 12 Nov 2012 01:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhggIl8LxtZk for ; Mon, 12 Nov 2012 01:06:32 -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 B8EA621F8532 for ; Mon, 12 Nov 2012 01:06:22 -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 ; Mon, 12 Nov 2012 10:06:13 +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 259263A161 for ; Mon, 12 Nov 2012 10:06:12 +0100 (CET) Message-ID: <50A0BC04.6090200@omnitor.se> Date: Mon, 12 Nov 2012 10:06:12 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------050508010608060406040700" Subject: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 09:06:34 -0000 This is a multi-part message in MIME format. --------------050508010608060406040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Real time sessions with video and audio are often accompanied with some form of text communication. It is mentioned in a couple of places in RTCWEB related specifications, but I see a need to get the specifications of how text should be handled up to the level of specification of the other media. The real-time requirements are slightly lower on text communication than on video and audio, so I realize that it can be carried by mechanisms already available in the web browser environment. But even if that will be the case, it needs to be considered and described, because text communication is part of the real-time communication concepts that RTCWEB belongs to. I know three kinds of text communication: Real-time text: Real-time text is text transmitted while it is being typed or created.*The recipient can read the sender's text as it is written, without waiting. *Text messaging: Text messaging is text collected to complete messages and sent as a whole when completed by specific user action.***The recipient can read the sender's text *soon after it is transmitted. Timed text: Timed text is text sent together with with information about the intended timing of the display, often related to another medium, such as audio or video. The recipient can read the text presented timely to events in the other media. Real-time text for conversational use has the timing requirement that end-to-end latency shall not be more than 2 seconds for usable text, and one second for good usability. This is clearly lower than the requirements on audio and video that traditionally is 400 ms for usable end-to-end latency. Real-time text is briefly mentioned in a requirement in draft-ietf-rtcweb-data-channel http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 All three text communication forms are mentioned in http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt I am most eager to see the use of real-time text specified in relation to RTCWEB, but it might be good to touch all three types. I suggest that it starts with requirements and use cases in http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/ I propose to add real-time text to use case 4.2.1 so that it reads: 4.2.1. Simple Video Communication Service with audio and real-time text 4.2.1.1. Description Two or more users have loaded a video communication web application into their browsers, provided by the same service provider, and logged into the service it provides. The web service publishes information about user login status by pushing updates to the web application in the browsers. When one online user selects a peer online user, a 1-1 video communication session between the browsers of the two peers is initiated. The invited user might accept or reject the session.Audio and real-time text is also available during the session. During session establishment a self-view is displayed, and once the session has been established the video sent from the remote peer is displayed in addition to the self-view. During the session, each user can select to remove and re-insert the self-view as often as desired. Each user can also change the sizes of his/her two video displays during the session.Audio from each user is presented to the other user. While one user types in the real-time text area, it is nearly immediately presented to the other user. Each user can also pause sending of media (audio, video, or both) and mute incoming media An alternative is to add a small additional section in 4.2 " 4.2.x. Simple Video Communication Service with real-time text 4.2.x.1. Description This use-case has the audio and video communication of the Simple Video Communication Service use-case (Section 4.2.1 ). But in addition to this, the users can send and receive real-time text. While one user types in the real-time text area, it is nearly immediately presented to the other user. " A couple of requirements then need to be added in the A and F ranges in 5.2 and 5.3, but I want to start with this initial proposal. Gunnar Hellstrom --------------050508010608060406040700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Real time sessions with video and audio are often accompanied with some form of text communication.

It is mentioned in a couple of places in RTCWEB related specifications, but I see a need to get the specifications of how text should be handled up to the level of specification of the other media.

The real-time requirements are slightly lower on text communication than on video and audio, so I realize that it can be carried by mechanisms already available in the web browser environment. But even if that will be the case, it needs to be considered and described, because text communication is part of the real-time communication concepts that RTCWEB belongs to.

I know three kinds of text communication:

Real-time text:

Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

Text messaging:

Text messaging is text collected to complete messages and sent as a whole when completed by specific user action. The recipient can read the sender's text soon after it is transmitted.

Timed text:

Timed text is text sent together with with information about the intended timing of the display, often related to another medium, such as audio or video. The recipient can read the text presented timely to events in the other media.


Real-time text for conversational use has the timing requirement that end-to-end latency shall not be more than 2 seconds for usable text, and one second for good usability. This is clearly lower than the requirements on audio and video that traditionally is 400 ms for usable end-to-end latency.

Real-time text is briefly mentioned in a requirement in draft-ietf-rtcweb-data-channel
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02

All three text communication forms are mentioned in http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt

I am most eager to see the use of real-time text specified in relation to RTCWEB, but it might be good to touch all three types.


I suggest that it starts with requirements and use cases in
http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/


I propose to add real-time text to use case 4.2.1 so that it reads:


4.2.1.  Simple Video Communication Service
 with audio and real-time text


4.2.1.1.  Description


   Two or more users have loaded a video communication web application
   into their browsers, provided by the same service provider, and
   logged into the service it provides.  The web service publishes
   information about user login status by pushing updates to the web
   application in the browsers.  When one online user selects a peer
   online user, a 1-1 video communication session between the browsers
   of the two peers is initiated.  The invited user might accept or
   reject the session. Audio and real-time text is also available
   during the session.

   During session establishment a self-view is displayed, and once the
   session has been established the video sent from the remote peer is
   displayed in addition to the self-view.  During the session, each
   user can select to remove and re-insert the self-view as often as
   desired.  Each user can also change the sizes of his/her two video
   displays during the session.  Audio from each user is presented to 
   the other user. While one user types in the real-time text area, it
   is nearly immediately presented to the other user. Each user can
   also pause sending of media (audio, video, or both) and mute incoming
   media


An alternative is to add a small additional section in 4.2
"
4.2.x.  Simple Video Communication Service with real-time text



4.2.x.1.  Description


   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).

   But in addition to this, the users can send and receive real-time text.
   While one user types in the real-time text area, it
   is nearly immediately presented to the other user.
"
A couple of requirements then need to be added in the A and F ranges in 5.2 and 5.3, but I want to start with this initial proposal.

Gunnar Hellstrom




--------------050508010608060406040700-- From harald@alvestrand.no Mon Nov 12 04:14:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4057821F854B for ; Mon, 12 Nov 2012 04:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.109 X-Spam-Level: X-Spam-Status: No, score=-109.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 d44JkzZ-eQBa for ; Mon, 12 Nov 2012 04:14:15 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9421F851F for ; Mon, 12 Nov 2012 04:14:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADBF839E0FE for ; Mon, 12 Nov 2012 13:14:06 +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 9ve1E1AlGEvy for ; Mon, 12 Nov 2012 13:14:02 +0100 (CET) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0FE0539E03A for ; Mon, 12 Nov 2012 13:14:02 +0100 (CET) Message-ID: <50A0E85E.4020201@alvestrand.no> Date: Mon, 12 Nov 2012 13:15:26 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> In-Reply-To: <50A0BC04.6090200@omnitor.se> Content-Type: multipart/alternative; boundary="------------020700080200070709020304" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 12:14:17 -0000 This is a multi-part message in MIME format. --------------020700080200070709020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I would prefer this to be added as a separate specification, rather than done at this time. The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications. Harald On 11/12/2012 10:06 AM, Gunnar Hellström wrote: > Real time sessions with video and audio are often accompanied with > some form of text communication. > > It is mentioned in a couple of places in RTCWEB related > specifications, but I see a need to get the specifications of how text > should be handled up to the level of specification of the other media. > > The real-time requirements are slightly lower on text communication > than on video and audio, so I realize that it can be carried by > mechanisms already available in the web browser environment. But even > if that will be the case, it needs to be considered and described, > because text communication is part of the real-time communication > concepts that RTCWEB belongs to. > > I know three kinds of text communication: > > Real-time text: > > Real-time text is text transmitted while it is being typed or > created.*The recipient can read the sender's text as it is written, > without waiting. > > *Text messaging: > > Text messaging is text collected to complete messages and sent as a > whole when completed by specific user action.***The recipient can read > the sender's text *soon after it is transmitted. > > Timed text: > > Timed text is text sent together with with information about the > intended timing of the display, often related to another medium, such > as audio or video. The recipient can read the text presented timely to > events in the other media. > > > Real-time text for conversational use has the timing requirement that > end-to-end latency shall not be more than 2 seconds for usable text, > and one second for good usability. This is clearly lower than the > requirements on audio and video that traditionally is 400 ms for > usable end-to-end latency. > > Real-time text is briefly mentioned in a requirement in > draft-ietf-rtcweb-data-channel > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 > > All three text communication forms are mentioned in > http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt > > I am most eager to see the use of real-time text specified in relation > to RTCWEB, but it might be good to touch all three types. > > > I suggest that it starts with requirements and use cases in > http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/ > > > I propose to add real-time text to use case 4.2.1 so that it reads: > > > 4.2.1. Simple Video Communication Service > > with audio and real-time text > > > 4.2.1.1. Description > > > > Two or more users have loaded a video communication web application > into their browsers, provided by the same service provider, and > logged into the service it provides. The web service publishes > information about user login status by pushing updates to the web > application in the browsers. When one online user selects a peer > online user, a 1-1 video communication session between the browsers > of the two peers is initiated. The invited user might accept or > reject the session.Audio and real-time text is also available > during the session. > > During session establishment a self-view is displayed, and once the > session has been established the video sent from the remote peer is > displayed in addition to the self-view. During the session, each > user can select to remove and re-insert the self-view as often as > desired. Each user can also change the sizes of his/her two video > displays during the session.Audio from each user is presented to > the other user. While one user types in the real-time text area, it > is nearly immediately presented to the other user. Each user can > also pause sending of media (audio, video, or both) and mute incoming > media > > > An alternative is to add a small additional section in 4.2 > " > > > 4.2.x. Simple Video Communication Service with real-time text > > > > 4.2.x.1. Description > > > > This use-case has the audio and video communication of the Simple > Video Communication Service use-case (Section 4.2.1 ). > > But in addition to this, the users can send and receive real-time text. > While one user types in the real-time text area, it > is nearly immediately presented to the other user. > " > A couple of requirements then need to be added in the A and F ranges > in 5.2 and 5.3, but I want to start with this initial proposal. > > Gunnar Hellstrom > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020700080200070709020304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.

            Harald

On 11/12/2012 10:06 AM, Gunnar Hellström wrote:
Real time sessions with video and audio are often accompanied with some form of text communication.

It is mentioned in a couple of places in RTCWEB related specifications, but I see a need to get the specifications of how text should be handled up to the level of specification of the other media.

The real-time requirements are slightly lower on text communication than on video and audio, so I realize that it can be carried by mechanisms already available in the web browser environment. But even if that will be the case, it needs to be considered and described, because text communication is part of the real-time communication concepts that RTCWEB belongs to.

I know three kinds of text communication:

Real-time text:

Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

Text messaging:

Text messaging is text collected to complete messages and sent as a whole when completed by specific user action. The recipient can read the sender's text soon after it is transmitted.

Timed text:

Timed text is text sent together with with information about the intended timing of the display, often related to another medium, such as audio or video. The recipient can read the text presented timely to events in the other media.


Real-time text for conversational use has the timing requirement that end-to-end latency shall not be more than 2 seconds for usable text, and one second for good usability. This is clearly lower than the requirements on audio and video that traditionally is 400 ms for usable end-to-end latency.

Real-time text is briefly mentioned in a requirement in draft-ietf-rtcweb-data-channel
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02

All three text communication forms are mentioned in http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt

I am most eager to see the use of real-time text specified in relation to RTCWEB, but it might be good to touch all three types.


I suggest that it starts with requirements and use cases in
http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/


I propose to add real-time text to use case 4.2.1 so that it reads:


4.2.1.  Simple Video Communication Service
 with audio and real-time text


4.2.1.1.  Description


   Two or more users have loaded a video communication web application
   into their browsers, provided by the same service provider, and
   logged into the service it provides.  The web service publishes
   information about user login status by pushing updates to the web
   application in the browsers.  When one online user selects a peer
   online user, a 1-1 video communication session between the browsers
   of the two peers is initiated.  The invited user might accept or
   reject the session. Audio and real-time text is also available
   during the session.

   During session establishment a self-view is displayed, and once the
   session has been established the video sent from the remote peer is
   displayed in addition to the self-view.  During the session, each
   user can select to remove and re-insert the self-view as often as
   desired.  Each user can also change the sizes of his/her two video
   displays during the session.  Audio from each user is presented to 
   the other user. While one user types in the real-time text area, it
   is nearly immediately presented to the other user. Each user can
   also pause sending of media (audio, video, or both) and mute incoming
   media


An alternative is to add a small additional section in 4.2
"
4.2.x.  Simple Video Communication Service with real-time text



4.2.x.1.  Description


   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).

   But in addition to this, the users can send and receive real-time text.
   While one user types in the real-time text area, it
   is nearly immediately presented to the other user.
"
A couple of requirements then need to be added in the A and F ranges in 5.2 and 5.3, but I want to start with this initial proposal.

Gunnar Hellstrom






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

--------------020700080200070709020304-- From gunnar.hellstrom@omnitor.se Mon Nov 12 04:45:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D995B21F84C4 for ; Mon, 12 Nov 2012 04:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN9GNh8u0pWQ for ; Mon, 12 Nov 2012 04:45:46 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id E952D21F8485 for ; Mon, 12 Nov 2012 04:45:45 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 12 Nov 2012 13:45:37 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id ABFDC3A175 for ; Mon, 12 Nov 2012 13:45:37 +0100 (CET) Message-ID: <50A0EF72.8080309@omnitor.se> Date: Mon, 12 Nov 2012 13:45:38 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> In-Reply-To: <50A0E85E.4020201@alvestrand.no> Content-Type: multipart/alternative; boundary="------------060703000803080607090303" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 12:45:48 -0000 This is a multi-part message in MIME format. --------------060703000803080607090303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I think the opposite. Inclusion of real-time text from the beginning is crucial for successful deployment of RTCWEB. It is so often a reason appears in a voice or video call to also convey something by text, that it would be a mistake to launch something without it. It is not at all sure that the best alternative is to use the data channel for this purpose. The currently only standarized way to do real-time text is through RTP. It would be even easier than doing it in the data channel, to specify use of RTP for this purpose. Then, interoperability with other environments, and use for emergency services is also easily achieved. It is so simple and can be specified rapidly, while the gaps in other central RTCWEB specifications are filled. Gunnar ---------------------- On 2012-11-12 13:15, Harald Alvestrand wrote: > I would prefer this to be added as a separate specification, rather > than done at this time. > The reason being that this should be relatively easy to add on top of > the data channel functionality, but will definitely take some time to > specify, so should not be on the critical path for this round of > specifications. > > Harald > > On 11/12/2012 10:06 AM, Gunnar Hellström wrote: >> Real time sessions with video and audio are often accompanied with >> some form of text communication. >> >> It is mentioned in a couple of places in RTCWEB related >> specifications, but I see a need to get the specifications of how >> text should be handled up to the level of specification of the other >> media. >> >> The real-time requirements are slightly lower on text communication >> than on video and audio, so I realize that it can be carried by >> mechanisms already available in the web browser environment. But even >> if that will be the case, it needs to be considered and described, >> because text communication is part of the real-time communication >> concepts that RTCWEB belongs to. >> >> I know three kinds of text communication: >> >> Real-time text: >> >> Real-time text is text transmitted while it is being typed or >> created.*The recipient can read the sender's text as it is written, >> without waiting. >> >> *Text messaging: >> >> Text messaging is text collected to complete messages and sent as a >> whole when completed by specific user action.***The recipient can >> read the sender's text *soon after it is transmitted. >> >> Timed text: >> >> Timed text is text sent together with with information about the >> intended timing of the display, often related to another medium, such >> as audio or video. The recipient can read the text presented timely >> to events in the other media. >> >> >> Real-time text for conversational use has the timing requirement that >> end-to-end latency shall not be more than 2 seconds for usable text, >> and one second for good usability. This is clearly lower than the >> requirements on audio and video that traditionally is 400 ms for >> usable end-to-end latency. >> >> Real-time text is briefly mentioned in a requirement in >> draft-ietf-rtcweb-data-channel >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 >> >> All three text communication forms are mentioned in >> http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt >> >> I am most eager to see the use of real-time text specified in >> relation to RTCWEB, but it might be good to touch all three types. >> >> >> I suggest that it starts with requirements and use cases in >> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/ >> >> >> I propose to add real-time text to use case 4.2.1 so that it reads: >> >> >> 4.2.1. Simple Video Communication Service >> >> with audio and real-time text >> >> >> 4.2.1.1. Description >> >> >> >> Two or more users have loaded a video communication web application >> into their browsers, provided by the same service provider, and >> logged into the service it provides. The web service publishes >> information about user login status by pushing updates to the web >> application in the browsers. When one online user selects a peer >> online user, a 1-1 video communication session between the browsers >> of the two peers is initiated. The invited user might accept or >> reject the session.Audio and real-time text is also available >> during the session. >> >> During session establishment a self-view is displayed, and once the >> session has been established the video sent from the remote peer is >> displayed in addition to the self-view. During the session, each >> user can select to remove and re-insert the self-view as often as >> desired. Each user can also change the sizes of his/her two video >> displays during the session.Audio from each user is presented to >> the other user. While one user types in the real-time text area, it >> is nearly immediately presented to the other user. Each user can >> also pause sending of media (audio, video, or both) and mute incoming >> media >> >> >> An alternative is to add a small additional section in 4.2 >> " >> >> >> 4.2.x. Simple Video Communication Service with real-time text >> >> >> >> 4.2.x.1. Description >> >> >> >> This use-case has the audio and video communication of the Simple >> Video Communication Service use-case (Section 4.2.1 ). >> >> But in addition to this, the users can send and receive real-time text. >> While one user types in the real-time text area, it >> is nearly immediately presented to the other user. >> " >> A couple of requirements then need to be added in the A and F ranges >> in 5.2 and 5.3, but I want to start with this initial proposal. >> >> Gunnar Hellstrom >> >> >> >> >> >> >> _______________________________________________ >> 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 --------------060703000803080607090303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I think the opposite. Inclusion of real-time text from the beginning is crucial for successful deployment of RTCWEB.
It is so often a reason appears in a voice or video call to also convey something by text, that it would be a mistake to launch something without it.

It is not at all sure that the best alternative is to use the data channel for this purpose. The currently only standarized way to do real-time text is through RTP. It would be even easier than doing it in the data channel, to specify use of RTP for this purpose.

Then, interoperability with other environments, and use for emergency services is also easily achieved.

It is so simple and can be specified rapidly, while the gaps in other central RTCWEB specifications are filled.

Gunnar

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

On 2012-11-12 13:15, Harald Alvestrand wrote:
I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.

            Harald

On 11/12/2012 10:06 AM, Gunnar Hellström wrote:
Real time sessions with video and audio are often accompanied with some form of text communication.

It is mentioned in a couple of places in RTCWEB related specifications, but I see a need to get the specifications of how text should be handled up to the level of specification of the other media.

The real-time requirements are slightly lower on text communication than on video and audio, so I realize that it can be carried by mechanisms already available in the web browser environment. But even if that will be the case, it needs to be considered and described, because text communication is part of the real-time communication concepts that RTCWEB belongs to.

I know three kinds of text communication:

Real-time text:

Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

Text messaging:

Text messaging is text collected to complete messages and sent as a whole when completed by specific user action. The recipient can read the sender's text soon after it is transmitted.

Timed text:

Timed text is text sent together with with information about the intended timing of the display, often related to another medium, such as audio or video. The recipient can read the text presented timely to events in the other media.


Real-time text for conversational use has the timing requirement that end-to-end latency shall not be more than 2 seconds for usable text, and one second for good usability. This is clearly lower than the requirements on audio and video that traditionally is 400 ms for usable end-to-end latency.

Real-time text is briefly mentioned in a requirement in draft-ietf-rtcweb-data-channel
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02

All three text communication forms are mentioned in http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt

I am most eager to see the use of real-time text specified in relation to RTCWEB, but it might be good to touch all three types.


I suggest that it starts with requirements and use cases in
http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/


I propose to add real-time text to use case 4.2.1 so that it reads:


4.2.1.  Simple Video Communication Service
 with audio and real-time text


4.2.1.1.  Description


   Two or more users have loaded a video communication web application
   into their browsers, provided by the same service provider, and
   logged into the service it provides.  The web service publishes
   information about user login status by pushing updates to the web
   application in the browsers.  When one online user selects a peer
   online user, a 1-1 video communication session between the browsers
   of the two peers is initiated.  The invited user might accept or
   reject the session. Audio and real-time text is also available
   during the session.

   During session establishment a self-view is displayed, and once the
   session has been established the video sent from the remote peer is
   displayed in addition to the self-view.  During the session, each
   user can select to remove and re-insert the self-view as often as
   desired.  Each user can also change the sizes of his/her two video
   displays during the session.  Audio from each user is presented to 
   the other user. While one user types in the real-time text area, it
   is nearly immediately presented to the other user. Each user can
   also pause sending of media (audio, video, or both) and mute incoming
   media


An alternative is to add a small additional section in 4.2
"
4.2.x.  Simple Video Communication Service with real-time text



4.2.x.1.  Description


   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).

   But in addition to this, the users can send and receive real-time text.
   While one user types in the real-time text area, it
   is nearly immediately presented to the other user.
"
A couple of requirements then need to be added in the A and F ranges in 5.2 and 5.3, but I want to start with this initial proposal.

Gunnar Hellstrom






_______________________________________________
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

--------------060703000803080607090303-- From stefan.lk.hakansson@ericsson.com Mon Nov 12 05:01:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A5F21F8574 for ; Mon, 12 Nov 2012 05:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Kh4DniwKRNGF for ; Mon, 12 Nov 2012 05:01:55 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE3F21F856C for ; Mon, 12 Nov 2012 05:01:54 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-b8-50a0f3413b56 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 55.A3.11564.143F0A05; Mon, 12 Nov 2012 14:01:53 +0100 (CET) Received: from [150.132.142.241] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 12 Nov 2012 14:01:53 +0100 Message-ID: <50A0F340.3050809@ericsson.com> Date: Mon, 12 Nov 2012 14:01:52 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A0EF72.8080309@omnitor.se> In-Reply-To: <50A0EF72.8080309@omnitor.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvja7j5wUBBn+mW1qs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujANf+9gLJptVtBybzNjA2KzdxcjJISFgInH3z2RmCFtM4sK9 9WxdjFwcQgInGSWmf5zLCuGsZZRoav8FVsUroC1xfl4DO4jNIqAqsfPTeyYQm03ARmJt9xQw W1QgTGLNnkNMEPWCEidnPmEBsUUEhCW2vuoFiwsLWEtc2LCCsYuRA2hBhsTibjGQMKeAlkTH 7x5GEJtZwFbiwpzrLBC2vETz1tlgJwgJ6Eq8e32PdQKjwCwkG2YhaZmFpGUBI/MqRvbcxMyc 9HLDTYzAMDu45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wKhWXr7Kn0dFpHeia+H5xIS+0AmJSS5h80o8rwYZLDstf729ZpXcfodJpy2YPSwU07asnHbG i2dija3gskMn1RT/pkmmt/j7rr4rPfHPLNUPn2epzr6YorXIc9oUtriaKtfjcy89FN/AeTWv WY1p/aqYY2mR3iG/c2eoLNcpepaR8uz4rHUir5RYijMSDbWYi4oTAbpCdAgBAgAA Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 13:01:56 -0000 To me it seems that real-time text use can be solved using the data channel (with the accompanying W3C API). I'm not sure anything needs to be standardized (except if there are legal requirements meaning we must). Stefan On 11/12/2012 01:45 PM, Gunnar Hellström wrote: > I think the opposite. Inclusion of real-time text from the beginning is > crucial for successful deployment of RTCWEB. > It is so often a reason appears in a voice or video call to also convey > something by text, that it would be a mistake to launch something > without it. > > It is not at all sure that the best alternative is to use the data > channel for this purpose. The currently only standarized way to do > real-time text is through RTP. It would be even easier than doing it in > the data channel, to specify use of RTP for this purpose. > > Then, interoperability with other environments, and use for emergency > services is also easily achieved. > > It is so simple and can be specified rapidly, while the gaps in other > central RTCWEB specifications are filled. > > Gunnar > > ---------------------- > > On 2012-11-12 13:15, Harald Alvestrand wrote: >> I would prefer this to be added as a separate specification, rather >> than done at this time. >> The reason being that this should be relatively easy to add on top of >> the data channel functionality, but will definitely take some time to >> specify, so should not be on the critical path for this round of >> specifications. >> >> Harald >> >> On 11/12/2012 10:06 AM, Gunnar Hellström wrote: >>> Real time sessions with video and audio are often accompanied with >>> some form of text communication. >>> >>> It is mentioned in a couple of places in RTCWEB related >>> specifications, but I see a need to get the specifications of how >>> text should be handled up to the level of specification of the other >>> media. >>> >>> The real-time requirements are slightly lower on text communication >>> than on video and audio, so I realize that it can be carried by >>> mechanisms already available in the web browser environment. But even >>> if that will be the case, it needs to be considered and described, >>> because text communication is part of the real-time communication >>> concepts that RTCWEB belongs to. >>> >>> I know three kinds of text communication: >>> >>> Real-time text: >>> >>> Real-time text is text transmitted while it is being typed or >>> created.*The recipient can read the sender's text as it is written, >>> without waiting. >>> >>> *Text messaging: >>> >>> Text messaging is text collected to complete messages and sent as a >>> whole when completed by specific user action.***The recipient can >>> read the sender's text *soon after it is transmitted. >>> >>> Timed text: >>> >>> Timed text is text sent together with with information about the >>> intended timing of the display, often related to another medium, such >>> as audio or video. The recipient can read the text presented timely >>> to events in the other media. >>> >>> >>> Real-time text for conversational use has the timing requirement that >>> end-to-end latency shall not be more than 2 seconds for usable text, >>> and one second for good usability. This is clearly lower than the >>> requirements on audio and video that traditionally is 400 ms for >>> usable end-to-end latency. >>> >>> Real-time text is briefly mentioned in a requirement in >>> draft-ietf-rtcweb-data-channel >>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 >>> >>> All three text communication forms are mentioned in >>> http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt >>> >>> I am most eager to see the use of real-time text specified in >>> relation to RTCWEB, but it might be good to touch all three types. >>> >>> >>> I suggest that it starts with requirements and use cases in >>> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/ >>> >>> >>> I propose to add real-time text to use case 4.2.1 so that it reads: >>> >>> >>> 4.2.1. Simple Video Communication Service >>> >>> with audio and real-time text >>> >>> >>> 4.2.1.1. Description >>> >>> >>> >>> Two or more users have loaded a video communication web application >>> into their browsers, provided by the same service provider, and >>> logged into the service it provides. The web service publishes >>> information about user login status by pushing updates to the web >>> application in the browsers. When one online user selects a peer >>> online user, a 1-1 video communication session between the browsers >>> of the two peers is initiated. The invited user might accept or >>> reject the session.Audio and real-time text is also available >>> during the session. >>> >>> During session establishment a self-view is displayed, and once the >>> session has been established the video sent from the remote peer is >>> displayed in addition to the self-view. During the session, each >>> user can select to remove and re-insert the self-view as often as >>> desired. Each user can also change the sizes of his/her two video >>> displays during the session.Audio from each user is presented to >>> the other user. While one user types in the real-time text area, it >>> is nearly immediately presented to the other user. Each user can >>> also pause sending of media (audio, video, or both) and mute incoming >>> media >>> >>> >>> An alternative is to add a small additional section in 4.2 >>> " >>> >>> >>> 4.2.x. Simple Video Communication Service with real-time text >>> >>> >>> >>> 4.2.x.1. Description >>> >>> >>> >>> This use-case has the audio and video communication of the Simple >>> Video Communication Service use-case (Section 4.2.1 ). >>> >>> But in addition to this, the users can send and receive real-time text. >>> While one user types in the real-time text area, it >>> is nearly immediately presented to the other user. >>> " >>> A couple of requirements then need to be added in the A and F ranges >>> in 5.2 and 5.3, but I want to start with this initial proposal. >>> >>> Gunnar Hellstrom >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From Jim.Barnett@genesyslab.com Mon Nov 12 06:06:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD26D21F85B4 for ; Mon, 12 Nov 2012 06:06:07 -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 GccOrk9bkNY5 for ; Mon, 12 Nov 2012 06:06:06 -0800 (PST) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id C4C5321F85AF for ; Mon, 12 Nov 2012 06:06:06 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id qACE5wfJ006211; Mon, 12 Nov 2012 06:05:58 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 06:05:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 06:04:28 -0800 Message-ID: In-Reply-To: <50A0F340.3050809@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3A1eeFq3mVKjlFSimxnhRCMLq0SQAB4SVg References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> From: "Jim Barnett" To: "Stefan Hakansson LK" , X-OriginalArrivalTime: 12 Nov 2012 14:05:55.0818 (UTC) FILETIME=[D557B4A0:01CDC0DE] Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 14:06:07 -0000 I think that Stefan is right. In the case of peer-to-peer = communication, we are leaving the signaling up to the two end-points, = and we can certainly expect them to figure out what to do with text = (over the data channel) as well. In the case of communication with a = legacy device (i.e., one that expects to send or receive text), it will = be up to the webRTC endpoint to adapt to the device's text API. I don't = see why we would need to specify anything in either case. =20 If it eventually turns out that a) there are common peer-to-peer use = cases involving text and b) it takes a lot of complicated JS coding to = get them to work, then we can add API-level support in a future = specification. But the new API surface wouldn't enable anything that = couldn't already be done over the data channel. =20 - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Stefan Hakansson LK Sent: Monday, November 12, 2012 8:02 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions To me it seems that real-time text use can be solved using the data = channel (with the accompanying W3C API). I'm not sure anything needs to be standardized (except if there are = legal requirements meaning we must). Stefan On 11/12/2012 01:45 PM, Gunnar Hellstr=F6m wrote: > I think the opposite. Inclusion of real-time text from the beginning=20 > is crucial for successful deployment of RTCWEB. > It is so often a reason appears in a voice or video call to also=20 > convey something by text, that it would be a mistake to launch=20 > something without it. > > It is not at all sure that the best alternative is to use the data=20 > channel for this purpose. The currently only standarized way to do=20 > real-time text is through RTP. It would be even easier than doing it=20 > in the data channel, to specify use of RTP for this purpose. > > Then, interoperability with other environments, and use for emergency=20 > services is also easily achieved. > > It is so simple and can be specified rapidly, while the gaps in other=20 > central RTCWEB specifications are filled. > > Gunnar > > ---------------------- > > On 2012-11-12 13:15, Harald Alvestrand wrote: >> I would prefer this to be added as a separate specification, rather=20 >> than done at this time. >> The reason being that this should be relatively easy to add on top of = >> the data channel functionality, but will definitely take some time to = >> specify, so should not be on the critical path for this round of=20 >> specifications. >> >> Harald >> >> On 11/12/2012 10:06 AM, Gunnar Hellstr=F6m wrote: >>> Real time sessions with video and audio are often accompanied with=20 >>> some form of text communication. >>> >>> It is mentioned in a couple of places in RTCWEB related=20 >>> specifications, but I see a need to get the specifications of how=20 >>> text should be handled up to the level of specification of the other = >>> media. >>> >>> The real-time requirements are slightly lower on text communication=20 >>> than on video and audio, so I realize that it can be carried by=20 >>> mechanisms already available in the web browser environment. But=20 >>> even if that will be the case, it needs to be considered and=20 >>> described, because text communication is part of the real-time=20 >>> communication concepts that RTCWEB belongs to. >>> >>> I know three kinds of text communication: >>> >>> Real-time text: >>> >>> Real-time text is text transmitted while it is being typed or=20 >>> created.*The recipient can read the sender's text as it is written,=20 >>> without waiting. >>> >>> *Text messaging: >>> >>> Text messaging is text collected to complete messages and sent as a=20 >>> whole when completed by specific user action.***The recipient can=20 >>> read the sender's text *soon after it is transmitted. >>> >>> Timed text: >>> >>> Timed text is text sent together with with information about the=20 >>> intended timing of the display, often related to another medium,=20 >>> such as audio or video. The recipient can read the text presented=20 >>> timely to events in the other media. >>> >>> >>> Real-time text for conversational use has the timing requirement=20 >>> that end-to-end latency shall not be more than 2 seconds for usable=20 >>> text, and one second for good usability. This is clearly lower than=20 >>> the requirements on audio and video that traditionally is 400 ms for = >>> usable end-to-end latency. >>> >>> Real-time text is briefly mentioned in a requirement in=20 >>> draft-ietf-rtcweb-data-channel >>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 >>> >>> All three text communication forms are mentioned in=20 >>> http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt >>> >>> I am most eager to see the use of real-time text specified in=20 >>> relation to RTCWEB, but it might be good to touch all three types. >>> >>> >>> I suggest that it starts with requirements and use cases in=20 >>> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requ >>> irements/ >>> >>> >>> I propose to add real-time text to use case 4.2.1 so that it reads: >>> >>> >>> 4.2.1. Simple Video Communication Service >>> >>> with audio and real-time text >>> >>> >>> 4.2.1.1. Description >>> >>> >>> >>> Two or more users have loaded a video communication web = application >>> into their browsers, provided by the same service provider, and >>> logged into the service it provides. The web service publishes >>> information about user login status by pushing updates to the = web >>> application in the browsers. When one online user selects a = peer >>> online user, a 1-1 video communication session between the = browsers >>> of the two peers is initiated. The invited user might accept or >>> reject the session.Audio and real-time text is also available >>> during the session. >>> >>> During session establishment a self-view is displayed, and once = the >>> session has been established the video sent from the remote peer = is >>> displayed in addition to the self-view. During the session, = each >>> user can select to remove and re-insert the self-view as often = as >>> desired. Each user can also change the sizes of his/her two = video >>> displays during the session.Audio from each user is presented to >>> the other user. While one user types in the real-time text area, = it >>> is nearly immediately presented to the other user. Each user = can >>> also pause sending of media (audio, video, or both) and mute = incoming >>> media >>> >>> >>> An alternative is to add a small additional section in 4.2 " >>> >>> >>> 4.2.x. Simple Video Communication Service with real-time = text >>> >>> >>> >>> 4.2.x.1. Description >>> >>> >>> >>> This use-case has the audio and video communication of the = Simple >>> Video Communication Service use-case (Section 4.2.1 = ). >>> >>> But in addition to this, the users can send and receive = real-time text. >>> While one user types in the real-time text area, it >>> is nearly immediately presented to the other user. >>> " >>> A couple of requirements then need to be added in the A and F ranges >>> in 5.2 and 5.3, but I want to start with this initial proposal. >>> >>> Gunnar Hellstrom >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From gunnar.hellstrom@omnitor.se Mon Nov 12 06:21:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8633121F85AD for ; Mon, 12 Nov 2012 06:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOM1WMJf0eZl for ; Mon, 12 Nov 2012 06:21:51 -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 07EA721F85A4 for ; Mon, 12 Nov 2012 06:21:50 -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, 12 Nov 2012 15:21:10 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 9CF913A146 for ; Mon, 12 Nov 2012 15:21:10 +0100 (CET) Message-ID: <50A105D7.2000901@omnitor.se> Date: Mon, 12 Nov 2012 15:21:11 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 14:21:52 -0000 I do not see the logic here. You propose that real-time text shall be left to the peers to agree on. Why are you then specifying audio and video, when such agreements can be left to the peers? Or the opposite: What makes the text codec in need of less standardization than audio and video? It is the same need, both sides must know how to code and decode the medium, some presentation characteristics, and on what transport to send it and how it is identified when sending so that the other end will use the proper decoder. What is the difference? And why use the data channel that says that it is for non-media. Real-time text is a conversational medium. ( This can of course easily be amended by opening the data channel also for media by some changed wording in the spec, I agree that real-time text could be transported over that channel if you see any preference for that over the RTP transport. ) Gunnar ------------------ On 2012-11-12 15:04, Jim Barnett wrote: > I think that Stefan is right. In the case of peer-to-peer communication, we are leaving the signaling up to the two end-points, and we can certainly expect them to figure out what to do with text (over the data channel) as well. In the case of communication with a legacy device (i.e., one that expects to send or receive text), it will be up to the webRTC endpoint to adapt to the device's text API. I don't see why we would need to specify anything in either case. > > If it eventually turns out that a) there are common peer-to-peer use cases involving text and b) it takes a lot of complicated JS coding to get them to work, then we can add API-level support in a future specification. But the new API surface wouldn't enable anything that couldn't already be done over the data channel. > > - Jim > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK > Sent: Monday, November 12, 2012 8:02 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions > > To me it seems that real-time text use can be solved using the data channel (with the accompanying W3C API). > > I'm not sure anything needs to be standardized (except if there are legal requirements meaning we must). > > Stefan > > On 11/12/2012 01:45 PM, Gunnar Hellström wrote: >> I think the opposite. Inclusion of real-time text from the beginning >> is crucial for successful deployment of RTCWEB. >> It is so often a reason appears in a voice or video call to also >> convey something by text, that it would be a mistake to launch >> something without it. >> >> It is not at all sure that the best alternative is to use the data >> channel for this purpose. The currently only standarized way to do >> real-time text is through RTP. It would be even easier than doing it >> in the data channel, to specify use of RTP for this purpose. >> >> Then, interoperability with other environments, and use for emergency >> services is also easily achieved. >> >> It is so simple and can be specified rapidly, while the gaps in other >> central RTCWEB specifications are filled. >> >> Gunnar >> >> ---------------------- >> >> On 2012-11-12 13:15, Harald Alvestrand wrote: >>> I would prefer this to be added as a separate specification, rather >>> than done at this time. >>> The reason being that this should be relatively easy to add on top of >>> the data channel functionality, but will definitely take some time to >>> specify, so should not be on the critical path for this round of >>> specifications. >>> >>> Harald >>> >>> On 11/12/2012 10:06 AM, Gunnar Hellström wrote: >>>> Real time sessions with video and audio are often accompanied with >>>> some form of text communication. >>>> >>>> It is mentioned in a couple of places in RTCWEB related >>>> specifications, but I see a need to get the specifications of how >>>> text should be handled up to the level of specification of the other >>>> media. >>>> >>>> The real-time requirements are slightly lower on text communication >>>> than on video and audio, so I realize that it can be carried by >>>> mechanisms already available in the web browser environment. But >>>> even if that will be the case, it needs to be considered and >>>> described, because text communication is part of the real-time >>>> communication concepts that RTCWEB belongs to. >>>> >>>> I know three kinds of text communication: >>>> >>>> Real-time text: >>>> >>>> Real-time text is text transmitted while it is being typed or >>>> created.*The recipient can read the sender's text as it is written, >>>> without waiting. >>>> >>>> *Text messaging: >>>> >>>> Text messaging is text collected to complete messages and sent as a >>>> whole when completed by specific user action.***The recipient can >>>> read the sender's text *soon after it is transmitted. >>>> >>>> Timed text: >>>> >>>> Timed text is text sent together with with information about the >>>> intended timing of the display, often related to another medium, >>>> such as audio or video. The recipient can read the text presented >>>> timely to events in the other media. >>>> >>>> >>>> Real-time text for conversational use has the timing requirement >>>> that end-to-end latency shall not be more than 2 seconds for usable >>>> text, and one second for good usability. This is clearly lower than >>>> the requirements on audio and video that traditionally is 400 ms for >>>> usable end-to-end latency. >>>> >>>> Real-time text is briefly mentioned in a requirement in >>>> draft-ietf-rtcweb-data-channel >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 >>>> >>>> All three text communication forms are mentioned in >>>> http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt >>>> >>>> I am most eager to see the use of real-time text specified in >>>> relation to RTCWEB, but it might be good to touch all three types. >>>> >>>> >>>> I suggest that it starts with requirements and use cases in >>>> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requ >>>> irements/ >>>> >>>> >>>> I propose to add real-time text to use case 4.2.1 so that it reads: >>>> >>>> >>>> 4.2.1. Simple Video Communication Service >>>> >>>> with audio and real-time text >>>> >>>> >>>> 4.2.1.1. Description >>>> >>>> >>>> >>>> Two or more users have loaded a video communication web application >>>> into their browsers, provided by the same service provider, and >>>> logged into the service it provides. The web service publishes >>>> information about user login status by pushing updates to the web >>>> application in the browsers. When one online user selects a peer >>>> online user, a 1-1 video communication session between the browsers >>>> of the two peers is initiated. The invited user might accept or >>>> reject the session.Audio and real-time text is also available >>>> during the session. >>>> >>>> During session establishment a self-view is displayed, and once the >>>> session has been established the video sent from the remote peer is >>>> displayed in addition to the self-view. During the session, each >>>> user can select to remove and re-insert the self-view as often as >>>> desired. Each user can also change the sizes of his/her two video >>>> displays during the session.Audio from each user is presented to >>>> the other user. While one user types in the real-time text area, it >>>> is nearly immediately presented to the other user. Each user can >>>> also pause sending of media (audio, video, or both) and mute incoming >>>> media >>>> >>>> >>>> An alternative is to add a small additional section in 4.2 " >>>> >>>> >>>> 4.2.x. Simple Video Communication Service with real-time text >>>> >>>> >>>> >>>> 4.2.x.1. Description >>>> >>>> >>>> >>>> This use-case has the audio and video communication of the Simple >>>> Video Communication Service use-case (Section 4.2.1 ). >>>> >>>> But in addition to this, the users can send and receive real-time text. >>>> While one user types in the real-time text area, it >>>> is nearly immediately presented to the other user. >>>> " >>>> A couple of requirements then need to be added in the A and F ranges >>>> in 5.2 and 5.3, but I want to start with this initial proposal. >>>> >>>> Gunnar Hellstrom >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Mon Nov 12 06:38:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB08321F85C4 for ; Mon, 12 Nov 2012 06:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 iwNFUlgmwHKq for ; Mon, 12 Nov 2012 06:38:46 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D625821F8530 for ; Mon, 12 Nov 2012 06:38:45 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-ce-50a109f4c218 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C2.82.11564.4F901A05; Mon, 12 Nov 2012 15:38:45 +0100 (CET) Received: from [150.132.141.66] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Mon, 12 Nov 2012 15:38:44 +0100 Message-ID: <50A109F4.6010208@ericsson.com> Date: Mon, 12 Nov 2012 15:38:44 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> <50A105D7.2000901@omnitor.se> In-Reply-To: <50A105D7.2000901@omnitor.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje5XzoUBBg9WM1qs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAP73rEW9HBUXP6R18C4g62LkZNDQsBEYt+hT8wQtpjEhXvr geJcHEICJxklNl/awwThrGGUOH+gjxWkildAW2L59E9MIDaLgKrE99N7wOJsAoES1///AouL CkRJ/Nh6lh2iXlDi5MwnLCC2iICwxNZXvWA1wgLWEhc2rGCEWPCWUeLzq7VARRwcnAJaEk1v wC5iFrCVuDDnOguELS/RvHU2WFxIQFfi3et7rBMYBWYhWTELScssJC0LGJlXMbLnJmbmpJcb bmIEhtnBLb91dzCeOidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaW GZUrO08fUvDIe35mW+nSx+LsSc8Xtoe/2GMra/7shd8OQSOlr0XMf814H99fUhRVH3qPySD6 6KJGjucinbnW7YsXuKu5b/QryHSPjLfkz9D6lmr4UTDYdf+XDAOpT0r2lxfLaZg9PvmS6aOf 467PWlPsHi1V1jn7rj9gDktk6ZH7RzZKyiixFGckGmoxFxUnAgB9SRWPAQIAAA== Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 14:38:46 -0000 On 2012-11-12 15:21, Gunnar Hellström wrote: > I do not see the logic here. > You propose that real-time text shall be left to the peers to agree on. > Why are you then specifying audio and video, when such agreements can be > left to the peers? Because, as it looks right now, among other reasons, it is not really feasible to handle all media processing (video coding, RTP encapsulation, jitter management, decoding, rate adaptation, ...) in JS right now. So we need to specify the exact formats so implementations interop. My analogy would be that we leave it up to the application do decide how it uses the "raw" media streams/tracks (playing out, recording, mixing, ....) in the same way as we leave it to the application how it uses the "raw" data channel (RT-text, send an image, game date, ...). Another difference is that the app creates the text (perhaps as a result of user typing) to be sent over the data channel, while devices such as cameras and microphones creates the audio and video. From adam@nostrum.com Mon Nov 12 07:34:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A8B21F85C4 for ; Mon, 12 Nov 2012 07:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.05 X-Spam-Level: X-Spam-Status: No, score=-101.05 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, SPF_PASS=-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 p4J0AtqpRfHZ for ; Mon, 12 Nov 2012 07:34:54 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F221F85AC for ; Mon, 12 Nov 2012 07:34:53 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qACFYqfT041538 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 12 Nov 2012 09:34:53 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A1171C.2020005@nostrum.com> Date: Mon, 12 Nov 2012 09:34:52 -0600 From: Adam Roach 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: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> <50A105D7.2000901@omnitor.se> <50A109F4.6010208@ericsson.com> In-Reply-To: <50A109F4.6010208@ericsson.com> Content-Type: multipart/alternative; boundary="------------060002030905090408080500" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 15:34:54 -0000 This is a multi-part message in MIME format. --------------060002030905090408080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 11/12/12 08:38, Stefan Håkansson LK wrote: > On 2012-11-12 15:21, Gunnar Hellström wrote: >> I do not see the logic here. >> You propose that real-time text shall be left to the peers to agree on. >> Why are you then specifying audio and video, when such agreements can be >> left to the peers? > > Because, as it looks right now, among other reasons, it is not really > feasible to handle all media processing (video coding, RTP > encapsulation, jitter management, decoding, rate adaptation, ...) in > JS right now. So we need to specify the exact formats so > implementations interop. > > My analogy would be that we leave it up to the application do decide > how it uses the "raw" media streams/tracks (playing out, recording, > mixing, ....) in the same way as we leave it to the application how it > uses the "raw" data channel (RT-text, send an image, game date, ...). > > Another difference is that the app creates the text (perhaps as a > result of user typing) to be sent over the data channel, while devices > such as cameras and microphones creates the audio and video. This is a very good explanation of what makes real-time text different (no processor-intensive codecs, no specialized access to hardware like cameras and microphones), but you didn't quite drive it all the way to its logical conclusion. Actually, I'd like to throw in one more characteristic of real-time text: it is not as sensitive to latency as voice and video. This means that relaying it through a web server is eminently possible. The key ramification of these three facts, taken together, is that _real time text is possible today_, without any of the WebRTC extensions. Trivial evidence of this is the existence of web tools like etherpad and typewith.me. I'm not saying that we should ignore the work necessary to make real-time text go directly browser-to-browser. I *am* agreeing with earlier comments that it should be a lower priority. Such an effort would be adding a second, supplemental way of sending text in real-time. I'd like to see work put into getting the first and only way of sending audio and sending video finished before we start allocating resources towards specifying additional means of doing something that is already possible. /a --------------060002030905090408080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/12/12 08:38, Stefan Håkansson LK wrote:
On 2012-11-12 15:21, Gunnar Hellström wrote:
I do not see the logic here.
You propose that real-time text shall be left to the peers to agree on.
Why are you then specifying audio and video, when such agreements can be
left to the peers?

Because, as it looks right now, among other reasons, it is not really feasible to handle all media processing (video coding, RTP encapsulation, jitter management, decoding, rate adaptation, ...) in JS right now. So we need to specify the exact formats so implementations interop.

My analogy would be that we leave it up to the application do decide how it uses the "raw" media streams/tracks (playing out, recording, mixing, ....) in the same way as we leave it to the application how it uses the "raw" data channel (RT-text, send an image, game date, ...).

Another difference is that the app creates the text (perhaps as a result of user typing) to be sent over the data channel, while devices such as cameras and microphones creates the audio and video.

This is a very good explanation of what makes real-time text different (no processor-intensive codecs, no specialized access to hardware like cameras and microphones), but you didn't quite drive it all the way to its logical conclusion.

Actually, I'd like to throw in one more characteristic of real-time text: it is not as sensitive to latency as voice and video. This means that relaying it through a web server is eminently possible.

The key ramification of these three facts, taken together, is that real time text is possible today, without any of the WebRTC extensions. Trivial evidence of this is the existence of web tools like etherpad and typewith.me.

I'm not saying that we should ignore the work necessary to make real-time text go directly browser-to-browser. I *am* agreeing with earlier comments that it should be a lower priority. Such an effort would be adding a second, supplemental way of sending text in real-time. I'd like to see work put into getting the first and only way of sending audio and sending video finished before we start allocating resources towards specifying additional means of doing something that is already possible.

/a
--------------060002030905090408080500-- From eburger@standardstrack.com Mon Nov 12 07:43:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0477821F856C for ; Mon, 12 Nov 2012 07:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpGqsISKEr-K for ; Mon, 12 Nov 2012 07:43:05 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 5165721F84D8 for ; Mon, 12 Nov 2012 07:43:05 -0800 (PST) Received: from 84.sub-174-252-119.myvzw.com ([174.252.119.84]:1477 helo=biz104.inmotionhosting.com) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TXwAA-0000wF-Og; Mon, 12 Nov 2012 07:43:03 -0800 Message-ID: From: "Eric Burger" To: adam@nostrum.com, rtcweb@ietf.org Date: Mon, 12 Nov 2012 10:43:19 -0500 X-Mailer: Motorola android mail 1.0 MIME-Version: 1.0 X-Priority: 3 References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> <50A105D7.2000901@omnitor.se> <50A109F4.6010208@ericsson.com> <50A1171C.2020005@nostrum.com> In-Reply-To: <50A1171C.2020005@nostrum.com> Content-Type: multipart/alternative; boundary="Motorola-A-Mail-6tuw7az6RA0Of-bz" 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 15:43:06 -0000 --Motorola-A-Mail-6tuw7az6RA0Of-bz Content-Type: text/plain; Format="Flowed"; DelSp="Yes"; charset="US-ASCII" Content-Transfer-Encoding: 7bit Wild*ssed counter proposal: getting the signaling and API right with a codec that does not require too much codec-level negotiation, arguments about quality, or arguments about intellectual property, seems like an incredibly reasonable first step to delivering something that people can use, instead of writing books about. If we cannot get RTT to work, we will never get VP8 to work. -- Sent from my mobile device. Thanks be to lemonade! http://www.standardstrack.com/ietf/lemonade/ -----Original message----- From: Adam Roach To: rtcweb@ietf.org Sent: Mon, Nov 12, 2012 15:35:08 GMT+00:00 Subject: Re: [rtcweb] Text communication in RTCWEB sessions --Motorola-A-Mail-6tuw7az6RA0Of-bz Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHt3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IGJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt9PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweCI+V2lsZCpz c2VkIGNvdW50ZXIgcHJvcG9zYWw6IGdldHRpbmcgdGhlIHNpZ25hbGluZyBhbmQgQVBJIHJpZ2h0 IHdpdGggYSBjb2RlYyB0aGF0IGRvZXMgbm90IHJlcXVpcmUgdG9vIG11Y2ggY29kZWMtbGV2ZWwg bmVnb3RpYXRpb24sIGFyZ3VtZW50cyBhYm91dCBxdWFsaXR5LCBvciBhcmd1bWVudHMgYWJvdXQg aW50ZWxsZWN0dWFsIHByb3BlcnR5LCBzZWVtcyBsaWtlIGFuIGluY3JlZGlibHkgcmVhc29uYWJs ZSBmaXJzdCBzdGVwIHRvIGRlbGl2ZXJpbmcgc29tZXRoaW5nIHRoYXQgcGVvcGxlIGNhbiB1c2Us IGluc3RlYWQgb2Ygd3JpdGluZyBib29rcyBhYm91dC48YnI+PGJyPklmIHdlIGNhbm5vdCBnZXQg UlRUIHRvIHdvcmssIHdlIHdpbGwgbmV2ZXIgZ2V0IFZQOCB0byB3b3JrLjxicj48YnI+LS08YnI+ U2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UuIFRoYW5rcyBiZSB0byBsZW1vbmFkZSEgPGEgaHJl Zj0iaHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZS8iPmh0dHA6Ly93 d3cuc3RhbmRhcmRzdHJhY2suY29tL2lldGYvbGVtb25hZGUvPC9hPjwvZGl2Pjxicj48YnI+LS0t LS1PcmlnaW5hbCBtZXNzYWdlLS0tLS08YnI+PGJsb2NrcXVvdGUgc3R5bGU9IjsgYm9yZGVyLWxl ZnQ6IDJweCBzb2xpZCByZ2IoMTYsIDE2LCAyNTUpOyBtYXJnaW4tbGVmdDogNXB4OyBwYWRkaW5n LWxlZnQ6IDVweDsiPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHgiPjxiPkZyb206IDwvYj5BZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0 OzxiPjxicj5UbzogPC9iPnJ0Y3dlYkBpZXRmLm9yZzxiPjxicj5TZW50OiA8L2I+TW9uLCBOb3Yg MTIsIDIwMTIgMTU6MzU6MDggR01UKzAwOjAwPGI+PGJyPlN1YmplY3Q6IDwvYj5SZTogW3J0Y3dl Yl0gVGV4dCBjb21tdW5pY2F0aW9uIGluIFJUQ1dFQiBzZXNzaW9uczxicj48YnI+PC9kaXY+PC9i bG9ja3F1b3RlPjwvYm9keT48L2h0bWw+DQo= --Motorola-A-Mail-6tuw7az6RA0Of-bz-- From randell-ietf@jesup.org Mon Nov 12 08:22:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052AE21F84CD for ; Mon, 12 Nov 2012 08:22: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 deofCwMIYwzD for ; Mon, 12 Nov 2012 08:22:19 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7C421F85CB for ; Mon, 12 Nov 2012 08:22:19 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3576 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TXwmA-0002YE-3l for rtcweb@ietf.org; Mon, 12 Nov 2012 10:22:18 -0600 Message-ID: <50A1219E.9020509@jesup.org> Date: Mon, 12 Nov 2012 11:19:42 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 16:22:20 -0000 On 11/12/2012 9:04 AM, Jim Barnett wrote: > I think that Stefan is right. In the case of peer-to-peer communication, we are leaving the signaling up to the two end-points, and we can certainly expect them to figure out what to do with text (over the data channel) as well. In the case of communication with a legacy device (i.e., one that expects to send or receive text), it will be up to the webRTC endpoint to adapt to the device's text API. I don't see why we would need to specify anything in either case. This may help you: at Atlanta, I gave an (impromptu) discussion on DataChannels in rtcweb. One thing I proposed adding to the existing implementation is a separate "protocol" field, similar to WebSockets. Most uses of DataChannels will be for application-specific protocols between two instances of the same app. However, since we have heterogeneous applications that may end up talking to each other, having one open a DataChannel with label "Chat" doesn't help (in the hetereogeneous case) if the two apps don't know what protocol the data in the "Chat" channel is. So with a protocol field, you can specify that the "Chat" channel is a specific chat protocol, and if both sides implement it, then you're set. A Text/Chat protocol (and maybe a file transfer protocol) seem like an idea set to specify as an example. Wherever possible, I'd prefer to specify them as "Foo over a DataChannel (reliable/unreliable)", to avoid re-implementing the wheel and easing implementation. > If it eventually turns out that a) there are common peer-to-peer use cases involving text and b) it takes a lot of complicated JS coding to get them to work, then we can add API-level support in a future specification. But the new API surface wouldn't enable anything that couldn't already be done over the data channel. > > - Jim > -- Randell Jesup randell-ietf@jesup.org From worley@shell01.TheWorld.com Mon Nov 12 09:15:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961E421F85EA for ; Mon, 12 Nov 2012 09:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_05=-1.11, 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 N-isK9WOso6k for ; Mon, 12 Nov 2012 09:15:08 -0800 (PST) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 920BA21F85D5 for ; Mon, 12 Nov 2012 09:15:07 -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 qACHENNs007727 for ; Mon, 12 Nov 2012 12:14:25 -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 qACHEMIv918213 for ; Mon, 12 Nov 2012 12:14:23 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qACHEMoq914291; Mon, 12 Nov 2012 12:14:22 -0500 (EST) Date: Mon, 12 Nov 2012 12:14:22 -0500 (EST) Message-Id: <201211121714.qACHEMoq914291@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 17:15:08 -0000 There are lots of suboptimal ways to do text communication. The deaf advocates are adamant that real-time text is needed, and the advocates have the ear of the regulators. So if RTCWEB is going to be used in any situation where regulators have a say, RTT will need to be supported. Especially for emergency communications. In regard to the basic technology, T.140-over-RTP is already defined (see RFC 4103 and RFC 5194). So RTT can be easily supported by the SDP that we are interchanging. Presumably any needed synchronization can be supported by whatever synchronization mechanism we are defining for audio and video. (It *is* general purpose, isn't it?) The new work is to discern the needed APIs so the Javascript can manage RTT streams. (I don't know whether this needs to be done with the audio and video work, or can be deferred until later.) The crucial point is to avoid implementing text communication in one of the many poor ways that it has been implemented before... Dale From gunnar.hellstrom@omnitor.se Mon Nov 12 09:57:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6259321F8679 for ; Mon, 12 Nov 2012 09:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLf2LGsJnmR6 for ; Mon, 12 Nov 2012 09:56:57 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 60FBB21F860C for ; Mon, 12 Nov 2012 09:56:54 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 12 Nov 2012 18:56:47 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 791BE3A119 for ; Mon, 12 Nov 2012 18:56:47 +0100 (CET) Message-ID: <50A13860.8050900@omnitor.se> Date: Mon, 12 Nov 2012 18:56:48 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> In-Reply-To: <201211121714.qACHEMoq914291@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 17:57:02 -0000 Dale, Good reasoning. The need for synchronization with audio and video is very relaxed for RTT. I would assume that a second out of synch is easily accepted. The one second end-to-end latency is probably slightly more demanding, even if it also easy compared to audio and video requirements. Since RTT is already available on RTP in RFC 4103 with presentation according to T.140, it is tempting to use it. Just moving to AVPF. It is lightweight with time sampled transmission every 300 ms, and there is reliability included. So, if SDP interchange is specified now, ( where?) RTT can be easily be adopted. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2012-11-12 18:14, Dale R. Worley wrote: > There are lots of suboptimal ways to do text communication. The deaf > advocates are adamant that real-time text is needed, and the advocates > have the ear of the regulators. So if RTCWEB is going to be used in > any situation where regulators have a say, RTT will need to be > supported. Especially for emergency communications. > > In regard to the basic technology, T.140-over-RTP is already defined > (see RFC 4103 and RFC 5194). So RTT can be easily supported by the > SDP that we are interchanging. Presumably any needed synchronization > can be supported by whatever synchronization mechanism we are defining > for audio and video. (It *is* general purpose, isn't it?) > > The new work is to discern the needed APIs so the Javascript can > manage RTT streams. (I don't know whether this needs to be done with > the audio and video work, or can be deferred until later.) > > The crucial point is to avoid implementing text communication in one > of the many poor ways that it has been implemented before... > > Dale > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Mon Nov 12 09:59:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E43C21F8748 for ; Mon, 12 Nov 2012 09:59:24 -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 HFk3Q7o7-te8 for ; Mon, 12 Nov 2012 09:59:23 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 71E4021F8679 for ; Mon, 12 Nov 2012 09:59:23 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1993 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TXyI7-0008Vf-2d for rtcweb@ietf.org; Mon, 12 Nov 2012 11:59:23 -0600 Message-ID: <50A1385F.4000709@jesup.org> Date: Mon, 12 Nov 2012 12:56:47 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> In-Reply-To: <201211121714.qACHEMoq914291@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 17:59:24 -0000 On 11/12/2012 12:14 PM, Dale R. Worley wrote: > There are lots of suboptimal ways to do text communication. The deaf > advocates are adamant that real-time text is needed, and the advocates > have the ear of the regulators. So if RTCWEB is going to be used in > any situation where regulators have a say, RTT will need to be > supported. Especially for emergency communications. > > In regard to the basic technology, T.140-over-RTP is already defined > (see RFC 4103 and RFC 5194). So RTT can be easily supported by the > SDP that we are interchanging. Presumably any needed synchronization > can be supported by whatever synchronization mechanism we are defining > for audio and video. (It *is* general purpose, isn't it?) Well, the MediaStreams don't support any track types (currently) other than video and audio. While possible, doing so would be a significant amount of work. In practice, we're talking at most 10's of ms of sync difference - a few frames at most, which should not affect RTT enough to be an issue. Subtitles (for pre-recorded info) might be a different case, with scene changes and the like. The SDP would support T140, but the codebases of the two existing primary implementations does not currently. > The new work is to discern the needed APIs so the Javascript can > manage RTT streams. (I don't know whether this needs to be done with > the audio and video work, or can be deferred until later.) My suggestion is instead of trying to jam an existing hack to "run a reliable protocol over an unreliable channel" into the implementations, to instead define running a well-known reliable-channel text protocol over a reliable DataChannel (or unreliable, if that makes more sense). > The crucial point is to avoid implementing text communication in one > of the many poor ways that it has been implemented before... Agreed. I'm just not convinced T140-over-RTP is the right solution. And yes, I've worked with the HoH/Deaf community before in VRS/Videophones and VRS interop (H.323 - now THERE was a bad decision forced by the dominant player aka Sorenson). -- Randell Jesup randell-ietf@jesup.org From stpeter@stpeter.im Mon Nov 12 10:42:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FAE21F878E for ; Mon, 12 Nov 2012 10:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 z4Nx8TYr6S7u for ; Mon, 12 Nov 2012 10:42:50 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BEE7721F8765 for ; Mon, 12 Nov 2012 10:42:50 -0800 (PST) Received: from [64.101.72.39] (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B2A2D40062; Mon, 12 Nov 2012 11:46:53 -0700 (MST) Message-ID: <50A14328.9060002@stpeter.im> Date: Mon, 12 Nov 2012 11:42:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Randell Jesup References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> In-Reply-To: <50A1385F.4000709@jesup.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 18:42:51 -0000 On 11/12/12 10:56 AM, Randell Jesup wrote: > On 11/12/2012 12:14 PM, Dale R. Worley wrote: >> There are lots of suboptimal ways to do text communication. The deaf >> advocates are adamant that real-time text is needed, and the advocates >> have the ear of the regulators. So if RTCWEB is going to be used in >> any situation where regulators have a say, RTT will need to be >> supported. Especially for emergency communications. >> >> In regard to the basic technology, T.140-over-RTP is already defined >> (see RFC 4103 and RFC 5194). So RTT can be easily supported by the >> SDP that we are interchanging. Presumably any needed synchronization >> can be supported by whatever synchronization mechanism we are defining >> for audio and video. (It *is* general purpose, isn't it?) > > Well, the MediaStreams don't support any track types (currently) other > than video and audio. While possible, doing so would be a significant > amount of work. > > In practice, we're talking at most 10's of ms of sync difference - a few > frames at most, which should not affect RTT enough to be an issue. > Subtitles (for pre-recorded info) might be a different case, with scene > changes and the like. > > The SDP would support T140, but the codebases of the two existing > primary implementations does not currently. > >> The new work is to discern the needed APIs so the Javascript can >> manage RTT streams. (I don't know whether this needs to be done with >> the audio and video work, or can be deferred until later.) > > My suggestion is instead of trying to jam an existing hack to "run a > reliable protocol over an unreliable channel" into the implementations, > to instead define running a well-known reliable-channel text protocol > over a reliable DataChannel (or unreliable, if that makes more sense). > >> The crucial point is to avoid implementing text communication in one >> of the many poor ways that it has been implemented before... > > Agreed. I'm just not convinced T140-over-RTP is the right solution. And > yes, I've worked with the HoH/Deaf community before in VRS/Videophones > and VRS interop (H.323 - now THERE was a bad decision forced by the > dominant player aka Sorenson). Another option is RTT over XMPP: http://xmpp.org/extensions/xep-0301.html Given that there are plenty of JavaScript libraries for XMPP, that seems like a rather easy approach. See also http://realjabber.org/ Peter -- Peter Saint-Andre https://stpeter.im/ From gunnar.hellstrom@omnitor.se Mon Nov 12 11:02:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAB821F8682 for ; Mon, 12 Nov 2012 11:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKCcRgy3GYKZ for ; Mon, 12 Nov 2012 11:02:43 -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 AA4F121F8612 for ; Mon, 12 Nov 2012 11:02:42 -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, 12 Nov 2012 20:02:05 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 03C123A0DF for ; Mon, 12 Nov 2012 20:02:05 +0100 (CET) Message-ID: <50A147AD.6080001@omnitor.se> Date: Mon, 12 Nov 2012 20:02:05 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> In-Reply-To: <50A14328.9060002@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 19:02:45 -0000 On 2012-11-12 19:42, Peter Saint-Andre wrote: > Another option is RTT over XMPP: > > http://xmpp.org/extensions/xep-0301.html > > Given that there are plenty of JavaScript libraries for XMPP, that seems > like a rather easy approach. See alsohttp://realjabber.org/ Yes, that is the obvious other option. XEP-0301 need then to move on from its experimental state. Do you mean that the transport of XMPP would be done beside RTCWEB, coordinated just by a specification saying "This is a way to do RTT together with an RTCWEB session?" Or would there be any more clear link or use of RTCWEB mechanisms? Gunnar From igor.faynberg@alcatel-lucent.com Mon Nov 12 11:03:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BED321F8682 for ; Mon, 12 Nov 2012 11:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z01GNZa6TbZS for ; Mon, 12 Nov 2012 11:03:32 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 980AD21F8612 for ; Mon, 12 Nov 2012 11:03:32 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id qACJ3Svb002116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Nov 2012 13:03:28 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qACJ3RvU006239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Nov 2012 13:03:28 -0600 Received: from [135.244.35.68] (faynberg.lra.lucent.com [135.244.35.68]) by umail.lucent.com (8.13.8/TPES) with ESMTP id qACJ3RJC019351; Mon, 12 Nov 2012 13:03:27 -0600 (CST) Message-ID: <50A147FF.2000003@alcatel-lucent.com> Date: Mon, 12 Nov 2012 14:03:27 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> In-Reply-To: <50A0BC04.6090200@omnitor.se> Content-Type: multipart/alternative; boundary="------------030408080106080200030009" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:03:33 -0000 This is a multi-part message in MIME format. --------------030408080106080200030009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 11/12/2012 4:06 AM, Gunnar Hellström wrote: > ... > Real-time text is text transmitted while it is being typed or > created.*The recipient can read the sender's text as it is written, > without waiting. > > *ietf.org/mailman/listinfo/rtcweb In this case, would that mean that when I type something and then want to correct it, backspaces would be transmitted, too? If so, I doubt it is useful. The second case, with the user having control over sending of the message, is much better. Igor --------------030408080106080200030009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 11/12/2012 4:06 AM, Gunnar Hellström wrote:
...
Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

ietf.org/mailman/listinfo/rtcweb

In this case, would that mean that when I type something and then want to correct it, backspaces would be transmitted, too?  If so, I doubt it is useful.   The second case, with the user having control over sending of the message, is much better.

Igor
--------------030408080106080200030009-- From igor.faynberg@alcatel-lucent.com Mon Nov 12 11:04:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88521F8682 for ; Mon, 12 Nov 2012 11:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZiLhoF9Or9l for ; Mon, 12 Nov 2012 11:04:33 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E2EBB21F8612 for ; Mon, 12 Nov 2012 11:04:32 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id qACJ4V4g013816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Nov 2012 13:04:32 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qACJ4VQb012012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Nov 2012 13:04:31 -0600 Received: from [135.244.35.68] (faynberg.lra.lucent.com [135.244.35.68]) by umail.lucent.com (8.13.8/TPES) with ESMTP id qACJ4RZb008700; Mon, 12 Nov 2012 13:04:31 -0600 (CST) Message-ID: <50A1483B.5050700@alcatel-lucent.com> Date: Mon, 12 Nov 2012 14:04:27 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> In-Reply-To: <50A0E85E.4020201@alvestrand.no> Content-Type: multipart/alternative; boundary="------------000102040307070009020409" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:04:34 -0000 This is a multi-part message in MIME format. --------------000102040307070009020409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit +1 Igor On 11/12/2012 7:15 AM, Harald Alvestrand wrote: > I would prefer this to be added as a separate specification, rather > than done at this time. > The reason being that this should be relatively easy to add on top of > the data channel functionality, but will definitely take some time to > specify, so should not be on the critical path for this round of > specifications. > > Harald > > On 11/12/2012 10:06 AM, Gunnar Hellström wrote: >> Real time sessions with video and audio are often accompanied with >> some form of text communication. >> >> It is mentioned in a couple of places in RTCWEB related >> specifications, but I see a need to get the specifications of how >> text should be handled up to the level of specification of the other >> media. >> >> The real-time requirements are slightly lower on text communication >> than on video and audio, so I realize that it can be carried by >> mechanisms already available in the web browser environment. But even >> if that will be the case, it needs to be considered and described, >> because text communication is part of the real-time communication >> concepts that RTCWEB belongs to. >> >> I know three kinds of text communication: >> >> Real-time text: >> >> Real-time text is text transmitted while it is being typed or >> created.*The recipient can read the sender's text as it is written, >> without waiting. >> >> *Text messaging: >> >> Text messaging is text collected to complete messages and sent as a >> whole when completed by specific user action.***The recipient can >> read the sender's text *soon after it is transmitted. >> >> Timed text: >> >> Timed text is text sent together with with information about the >> intended timing of the display, often related to another medium, such >> as audio or video. The recipient can read the text presented timely >> to events in the other media. >> >> >> Real-time text for conversational use has the timing requirement that >> end-to-end latency shall not be more than 2 seconds for usable text, >> and one second for good usability. This is clearly lower than the >> requirements on audio and video that traditionally is 400 ms for >> usable end-to-end latency. >> >> Real-time text is briefly mentioned in a requirement in >> draft-ietf-rtcweb-data-channel >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 >> >> All three text communication forms are mentioned in >> http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt >> >> I am most eager to see the use of real-time text specified in >> relation to RTCWEB, but it might be good to touch all three types. >> >> >> I suggest that it starts with requirements and use cases in >> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/ >> >> >> I propose to add real-time text to use case 4.2.1 so that it reads: >> >> >> 4.2.1. Simple Video Communication Service >> >> with audio and real-time text >> >> >> 4.2.1.1. Description >> >> >> >> Two or more users have loaded a video communication web application >> into their browsers, provided by the same service provider, and >> logged into the service it provides. The web service publishes >> information about user login status by pushing updates to the web >> application in the browsers. When one online user selects a peer >> online user, a 1-1 video communication session between the browsers >> of the two peers is initiated. The invited user might accept or >> reject the session.Audio and real-time text is also available >> during the session. >> >> During session establishment a self-view is displayed, and once the >> session has been established the video sent from the remote peer is >> displayed in addition to the self-view. During the session, each >> user can select to remove and re-insert the self-view as often as >> desired. Each user can also change the sizes of his/her two video >> displays during the session.Audio from each user is presented to >> the other user. While one user types in the real-time text area, it >> is nearly immediately presented to the other user. Each user can >> also pause sending of media (audio, video, or both) and mute incoming >> media >> >> >> An alternative is to add a small additional section in 4.2 >> " >> >> >> 4.2.x. Simple Video Communication Service with real-time text >> >> >> >> 4.2.x.1. Description >> >> >> >> This use-case has the audio and video communication of the Simple >> Video Communication Service use-case (Section 4.2.1 ). >> >> But in addition to this, the users can send and receive real-time text. >> While one user types in the real-time text area, it >> is nearly immediately presented to the other user. >> " >> A couple of requirements then need to be added in the A and F ranges >> in 5.2 and 5.3, but I want to start with this initial proposal. >> >> Gunnar Hellstrom >> >> >> >> >> >> >> _______________________________________________ >> 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 --------------000102040307070009020409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Igor

On 11/12/2012 7:15 AM, Harald Alvestrand wrote:
I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.

            Harald

On 11/12/2012 10:06 AM, Gunnar Hellström wrote:
Real time sessions with video and audio are often accompanied with some form of text communication.

It is mentioned in a couple of places in RTCWEB related specifications, but I see a need to get the specifications of how text should be handled up to the level of specification of the other media.

The real-time requirements are slightly lower on text communication than on video and audio, so I realize that it can be carried by mechanisms already available in the web browser environment. But even if that will be the case, it needs to be considered and described, because text communication is part of the real-time communication concepts that RTCWEB belongs to.

I know three kinds of text communication:

Real-time text:

Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

Text messaging:

Text messaging is text collected to complete messages and sent as a whole when completed by specific user action. The recipient can read the sender's text soon after it is transmitted.

Timed text:

Timed text is text sent together with with information about the intended timing of the display, often related to another medium, such as audio or video. The recipient can read the text presented timely to events in the other media.


Real-time text for conversational use has the timing requirement that end-to-end latency shall not be more than 2 seconds for usable text, and one second for good usability. This is clearly lower than the requirements on audio and video that traditionally is 400 ms for usable end-to-end latency.

Real-time text is briefly mentioned in a requirement in draft-ietf-rtcweb-data-channel
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02

All three text communication forms are mentioned in http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt

I am most eager to see the use of real-time text specified in relation to RTCWEB, but it might be good to touch all three types.


I suggest that it starts with requirements and use cases in
http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/


I propose to add real-time text to use case 4.2.1 so that it reads:


4.2.1.  Simple Video Communication Service
 with audio and real-time text


4.2.1.1.  Description


   Two or more users have loaded a video communication web application
   into their browsers, provided by the same service provider, and
   logged into the service it provides.  The web service publishes
   information about user login status by pushing updates to the web
   application in the browsers.  When one online user selects a peer
   online user, a 1-1 video communication session between the browsers
   of the two peers is initiated.  The invited user might accept or
   reject the session. Audio and real-time text is also available
   during the session.

   During session establishment a self-view is displayed, and once the
   session has been established the video sent from the remote peer is
   displayed in addition to the self-view.  During the session, each
   user can select to remove and re-insert the self-view as often as
   desired.  Each user can also change the sizes of his/her two video
   displays during the session.  Audio from each user is presented to 
   the other user. While one user types in the real-time text area, it
   is nearly immediately presented to the other user. Each user can
   also pause sending of media (audio, video, or both) and mute incoming
   media


An alternative is to add a small additional section in 4.2
"
4.2.x.  Simple Video Communication Service with real-time text



4.2.x.1.  Description


   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).

   But in addition to this, the users can send and receive real-time text.
   While one user types in the real-time text area, it
   is nearly immediately presented to the other user.
"
A couple of requirements then need to be added in the A and F ranges in 5.2 and 5.3, but I want to start with this initial proposal.

Gunnar Hellstrom






_______________________________________________
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
--------------000102040307070009020409-- From adam@nostrum.com Mon Nov 12 11:23:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC67621F86D0 for ; Mon, 12 Nov 2012 11:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.367 X-Spam-Level: X-Spam-Status: No, score=-101.367 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, SPF_PASS=-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 j0gMriiG93J3 for ; Mon, 12 Nov 2012 11:23:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id F0A7F21F8512 for ; Mon, 12 Nov 2012 11:23:39 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qACJNc3p063900 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 13:23:38 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A14CB9.8020706@nostrum.com> Date: Mon, 12 Nov 2012 13:23:37 -0600 From: Adam Roach 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: Eric Burger References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> <50A105D7.2000901@omnitor.se> <50A109F4.6010208@ericsson.com> <50A1171C.2020005@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 19:23:41 -0000 On 11/12/12 09:43, Eric Burger wrote: > Wild*ssed counter proposal: getting the signaling and API right with a > codec that does not require too much codec-level negotiation, > arguments about quality, or arguments about intellectual property, > seems like an incredibly reasonable first step to delivering something > that people can use, instead of writing books about. I look forward to the UTF-8 versus UTF-16 battle. :) /a From gunnar.hellstrom@omnitor.se Mon Nov 12 11:29:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A08121F86D0 for ; Mon, 12 Nov 2012 11:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT121XlyFIUK for ; Mon, 12 Nov 2012 11:29:55 -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 7BE1E21F8695 for ; Mon, 12 Nov 2012 11:29:54 -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 ; Mon, 12 Nov 2012 20:29:44 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id B985D3A10E for ; Mon, 12 Nov 2012 20:29:44 +0100 (CET) Message-ID: <50A14E2A.5030205@omnitor.se> Date: Mon, 12 Nov 2012 20:29:46 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A147FF.2000003@alcatel-lucent.com> In-Reply-To: <50A147FF.2000003@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000803000407070502050604" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 19:29:56 -0000 This is a multi-part message in MIME format. --------------000803000407070502050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Yes, backspaces are transmitted. I can assure that it is useful. And it needs not to be compared to messaging. It is intended for real conversational use of text, without the artificially created pauses for composing complete messages occurring in messaging. Just let the text go as you type it, with slight delay for time-sampling as for audio and video. It provides a rapid and smooth way to have the conversing parties synchronized in thoughts. There is of course still scope for traditional messaging even if I am more interested to see the real-time text implemented together with the other real-time media in RTCWEB. And there is even work on the way to introduce correction in already sent messages in traditional messaging. It is in XMPP XEP-0308. http://xmpp.org/extensions/xep-0308.html Also that is useful, and reduces stress, frustration and extra typing. It is usually when you have just completed and sent your message that you discover the mistake and want to correct it. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2012-11-12 20:03, Igor Faynberg wrote: > > > On 11/12/2012 4:06 AM, Gunnar Hellström wrote: >> ... >> Real-time text is text transmitted while it is being typed or >> created.*The recipient can read the sender's text as it is written, >> without waiting. >> >> *ietf.org/mailman/listinfo/rtcweb > > In this case, would that mean that when I type something and then want > to correct it, backspaces would be transmitted, too? If so, I doubt > it is useful. The second case, with the user having control over > sending of the message, is much better. > > Igor > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------000803000407070502050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Yes, backspaces are transmitted.

I can assure that it is useful.

And it needs not to be compared to messaging. It is intended for real conversational use of text, without the artificially created pauses for composing complete messages occurring in messaging. Just let the text go as you type it, with slight delay for time-sampling as for audio and video.
It provides a rapid and smooth way to have the conversing parties synchronized in thoughts.



There is of course still scope for traditional messaging even if I am more interested to see the real-time text implemented together with the other real-time media in RTCWEB. And there is even work on the way to introduce correction in already sent messages in traditional messaging. It is in XMPP XEP-0308.  http://xmpp.org/extensions/xep-0308.html    Also that is useful, and reduces stress, frustration and extra typing. It is usually when you have just completed and sent your message that you discover the mistake and want to correct it.

Gunnar
___________________________________________________
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2012-11-12 20:03, Igor Faynberg wrote:


On 11/12/2012 4:06 AM, Gunnar Hellström wrote:
...
Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

ietf.org/mailman/listinfo/rtcweb

In this case, would that mean that when I type something and then want to correct it, backspaces would be transmitted, too?  If so, I doubt it is useful.   The second case, with the user having control over sending of the message, is much better.

Igor


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

--------------000803000407070502050604-- From richard@shockey.us Mon Nov 12 11:42:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FEC21F8748 for ; Mon, 12 Nov 2012 11:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjBQElgh8E8a for ; Mon, 12 Nov 2012 11:42:00 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 2F18521F85C0 for ; Mon, 12 Nov 2012 11:42:00 -0800 (PST) Received: (qmail 20962 invoked by uid 0); 12 Nov 2012 19:41:29 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 12 Nov 2012 19:41:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=KIppaOpJ7sxMCmXQnocpZwW8SUMEbg7Zw16mdo5BGkA=; b=KnaBVvAuvRZVEufdm7bWT1tyrx3HhYXAvJIjmYisHIPDhWdMYkbNCGytBr7eg1d82D3w4maUdZhPmoH/eqaqfE52Fb1OKXpWrabRLLQyl/phhbqe/Htz+q0ZjnUmS+Xh; Received: from [71.191.243.130] (port=57608 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TXzsv-00025V-J9; Mon, 12 Nov 2012 12:41:29 -0700 From: "Richard Shockey" To: "'Dale R. Worley'" , References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> In-Reply-To: <201211121714.qACHEMoq914291@shell01.TheWorld.com> Date: Mon, 12 Nov 2012 14:41:27 -0500 Message-ID: <003001cdc10d$b55d7930$20186b90$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3A+UbA3SK4dNzfQMqYolZ+iaM1fAAE+Qrw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 19:42:01 -0000 Dale is right ..you can delay the discussion but not the requirement. The regulators will insist on this. http://transition.fcc.gov/cgb/dro/cvaa.html http://europa.eu/legislation_summaries/information_society/legislative_frame work/l24216a_en.htm -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: Monday, November 12, 2012 12:14 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions There are lots of suboptimal ways to do text communication. The deaf advocates are adamant that real-time text is needed, and the advocates have the ear of the regulators. So if RTCWEB is going to be used in any situation where regulators have a say, RTT will need to be supported. Especially for emergency communications. In regard to the basic technology, T.140-over-RTP is already defined (see RFC 4103 and RFC 5194). So RTT can be easily supported by the SDP that we are interchanging. Presumably any needed synchronization can be supported by whatever synchronization mechanism we are defining for audio and video. (It *is* general purpose, isn't it?) The new work is to discern the needed APIs so the Javascript can manage RTT streams. (I don't know whether this needs to be done with the audio and video work, or can be deferred until later.) The crucial point is to avoid implementing text communication in one of the many poor ways that it has been implemented before... Dale _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From stpeter@stpeter.im Mon Nov 12 11:43:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1803321F8765 for ; Mon, 12 Nov 2012 11:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVWjHmfkYV8R for ; Mon, 12 Nov 2012 11:43:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 79A3A21F874A for ; Mon, 12 Nov 2012 11:43:33 -0800 (PST) Received: from [64.101.72.39] (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E1C5C40062; Mon, 12 Nov 2012 12:47:36 -0700 (MST) Message-ID: <50A15163.4080604@stpeter.im> Date: Mon, 12 Nov 2012 12:43:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A147AD.6080001@omnitor.se> In-Reply-To: <50A147AD.6080001@omnitor.se> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 19:43:34 -0000 On 11/12/12 12:02 PM, Gunnar Hellström wrote: > On 2012-11-12 19:42, Peter Saint-Andre wrote: >> Another option is RTT over XMPP: >> >> http://xmpp.org/extensions/xep-0301.html >> >> Given that there are plenty of JavaScript libraries for XMPP, that seems >> like a rather easy approach. See alsohttp://realjabber.org/ > > Yes, that is the obvious other option. > XEP-0301 need then to move on from its experimental state. Yes, I expect that to happen in the relatively near future. Certainly before RTCWEB is baked. :) > Do you mean that the transport of XMPP would be done beside RTCWEB, > coordinated just by a specification saying "This is a way to do RTT > together with an RTCWEB session?" Or would there be any more clear link > or use of RTCWEB mechanisms? One possibility is to negotiate an XMPP chat session via SDP, as Robert Sparks once proposed a long time ago: https://datatracker.ietf.org/doc/draft-sparks-simple-jabber-sessions/ Peter -- Peter Saint-Andre https://stpeter.im/ From Jim.Barnett@genesyslab.com Mon Nov 12 11:50:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5666721F8618 for ; Mon, 12 Nov 2012 11:50: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 PHvOa4KFq8Fh for ; Mon, 12 Nov 2012 11:50:49 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 83E6F21F85F5 for ; Mon, 12 Nov 2012 11:50:49 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id qACJoYWo015422; Mon, 12 Nov 2012 11:50:35 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 11:50:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 11:48:45 -0800 Message-ID: In-Reply-To: <003001cdc10d$b55d7930$20186b90$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3A+UbA3SK4dNzfQMqYolZ+iaM1fAAE+QrwAAA3PyA= References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <003001cdc10d$b55d7930$20186b90$@us> From: "Jim Barnett" To: "Richard Shockey" , "Dale R. Worley" , X-OriginalArrivalTime: 12 Nov 2012 19:50:13.0169 (UTC) FILETIME=[EE155210:01CDC10E] Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 19:50:50 -0000 Yes, but is that a requirement on us, or on the people who roll out services using webRTC? If RTT can be done via a bunch of (potentially ugly) JS code and the data channel, then it's the service providers' problem to write that ugly JS code. There's no requirement for the W3C/IETF to provide native support for RTT as long as it's possible to implement it on top of our standards. - Jim P.S. I intend this as an argument for looking at RTT later, not for skipping it altogether. =20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, November 12, 2012 2:41 PM To: 'Dale R. Worley'; rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions Dale is right ..you can delay the discussion but not the requirement. The regulators will insist on this.=20 http://transition.fcc.gov/cgb/dro/cvaa.html http://europa.eu/legislation_summaries/information_society/legislative_f rame work/l24216a_en.htm -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: Monday, November 12, 2012 12:14 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions There are lots of suboptimal ways to do text communication. The deaf advocates are adamant that real-time text is needed, and the advocates have the ear of the regulators. So if RTCWEB is going to be used in any situation where regulators have a say, RTT will need to be supported. Especially for emergency communications. In regard to the basic technology, T.140-over-RTP is already defined (see RFC 4103 and RFC 5194). So RTT can be easily supported by the SDP that we are interchanging. Presumably any needed synchronization can be supported by whatever synchronization mechanism we are defining for audio and video. (It *is* general purpose, isn't it?) The new work is to discern the needed APIs so the Javascript can manage RTT streams. (I don't know whether this needs to be done with the audio and video work, or can be deferred until later.) The crucial point is to avoid implementing text communication in one of the many poor ways that it has been implemented before... 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 From igor.faynberg@alcatel-lucent.com Mon Nov 12 11:51:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6D021F86E5 for ; Mon, 12 Nov 2012 11:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zGHkDRrFbDU8 for ; Mon, 12 Nov 2012 11:51:04 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9A21F86D3 for ; Mon, 12 Nov 2012 11:51:04 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id qACJp3S1003742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Nov 2012 13:51:03 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qACJp2MX014044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Nov 2012 13:51:03 -0600 Received: from [135.244.35.68] (faynberg.lra.lucent.com [135.244.35.68]) by umail.lucent.com (8.13.8/TPES) with ESMTP id qACJp2Z6007459; Mon, 12 Nov 2012 13:51:02 -0600 (CST) Message-ID: <50A15325.1010504@alcatel-lucent.com> Date: Mon, 12 Nov 2012 14:51:01 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A147FF.2000003@alcatel-lucent.com> <50A14E2A.5030205@omnitor.se> In-Reply-To: <50A14E2A.5030205@omnitor.se> Content-Type: multipart/alternative; boundary="------------040704060403070300040002" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:51:05 -0000 This is a multi-part message in MIME format. --------------040704060403070300040002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thanks for a quick reply! (Meanwhile, I was assured by Keith Drage that this feature is needed by deaf--something I was not aware of, so I need to catch up on learning. I imagine this would be used in speech-to-text conversion and transmission.) Of course, thanks to my advanced age, I remember the Unix "Write" application that did just that. My bad experience with it was that 22 years ago I used that very application to communicate with my big boss, and I wrote something without counting to 1,000. I should have counted: The backspaces did not help... So I walked to Dennis Ritchie's office, told him what happened, and suggested that "Write" ought to display messages only when Return is hit. Surprisingly, he immediately agreed with me, but System 5 was already out of his immediate control. He promised to follow-up through the Unix Consortium, but soon that entity disappeared from our radar screen. Inferno and Plan 9 though transmitted only full messages. This is what prompted my question. Now it has been answered! Igor On 11/12/2012 2:29 PM, Gunnar Hellström wrote: > Yes, backspaces are transmitted. > > I can assure that it is useful. > > And it needs not to be compared to messaging. It is intended for real > conversational use of text, without the artificially created pauses > for composing complete messages occurring in messaging. Just let the > text go as you type it, with slight delay for time-sampling as for > audio and video. > It provides a rapid and smooth way to have the conversing parties > synchronized in thoughts. > > > > There is of course still scope for traditional messaging even if I am > more interested to see the real-time text implemented together with > the other real-time media in RTCWEB. And there is even work on the way > to introduce correction in already sent messages in traditional > messaging. It is in XMPP XEP-0308. > http://xmpp.org/extensions/xep-0308.html Also that is useful, and > reduces stress, frustration and extra typing. It is usually when you > have just completed and sent your message that you discover the > mistake and want to correct it. > > Gunnar > ___________________________________________________ > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 > On 2012-11-12 20:03, Igor Faynberg wrote: >> >> >> On 11/12/2012 4:06 AM, Gunnar Hellström wrote: >>> ... >>> Real-time text is text transmitted while it is being typed or >>> created.*The recipient can read the sender's text as it is written, >>> without waiting. >>> >>> *ietf.org/mailman/listinfo/rtcweb >> >> In this case, would that mean that when I type something and then >> want to correct it, backspaces would be transmitted, too? If so, I >> doubt it is useful. The second case, with the user having control >> over sending of the message, is much better. >> >> Igor >> >> >> _______________________________________________ >> 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 --------------040704060403070300040002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for a quick reply!  (Meanwhile, I was assured by Keith Drage that this feature is needed by deaf--something I  was not aware of, so I need to catch up on learning.  I imagine this would be used in speech-to-text conversion and transmission.)

Of course, thanks to my advanced age, I remember the Unix "Write" application that did just that.  My bad experience with it was that 22 years ago I used that very application to communicate with my big boss, and I wrote  something without counting to 1,000.  I should have counted:  The backspaces did not help... 

 So I walked to Dennis Ritchie's office, told him what happened, and suggested that "Write" ought to display messages only when Return is hit. Surprisingly, he immediately agreed with me, but System 5 was already out of his immediate control.  He promised to follow-up through the Unix Consortium, but soon that entity disappeared from our radar screen.  Inferno and Plan 9 though transmitted only full messages.

This is what prompted my question. 

Now it has been answered!

Igor


On 11/12/2012 2:29 PM, Gunnar Hellström wrote:
Yes, backspaces are transmitted.

I can assure that it is useful.

And it needs not to be compared to messaging. It is intended for real conversational use of text, without the artificially created pauses for composing complete messages occurring in messaging. Just let the text go as you type it, with slight delay for time-sampling as for audio and video.
It provides a rapid and smooth way to have the conversing parties synchronized in thoughts.



There is of course still scope for traditional messaging even if I am more interested to see the real-time text implemented together with the other real-time media in RTCWEB. And there is even work on the way to introduce correction in already sent messages in traditional messaging. It is in XMPP XEP-0308.  http://xmpp.org/extensions/xep-0308.html    Also that is useful, and reduces stress, frustration and extra typing. It is usually when you have just completed and sent your message that you discover the mistake and want to correct it.

Gunnar
___________________________________________________
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2012-11-12 20:03, Igor Faynberg wrote:


On 11/12/2012 4:06 AM, Gunnar Hellström wrote:
...
Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

ietf.org/mailman/listinfo/rtcweb

In this case, would that mean that when I type something and then want to correct it, backspaces would be transmitted, too?  If so, I doubt it is useful.   The second case, with the user having control over sending of the message, is much better.

Igor


_______________________________________________
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
--------------040704060403070300040002-- From gunnar.hellstrom@omnitor.se Mon Nov 12 12:05:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AFC21F8626 for ; Mon, 12 Nov 2012 12:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVDOkbHO1pBZ for ; Mon, 12 Nov 2012 12:05:33 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id BB52E21F857C for ; Mon, 12 Nov 2012 12:05:32 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 12 Nov 2012 21:05:19 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 6B5EE3A170 for ; Mon, 12 Nov 2012 21:05:19 +0100 (CET) Message-ID: <50A15681.1060102@omnitor.se> Date: Mon, 12 Nov 2012 21:05:21 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A147FF.2000003@alcatel-lucent.com> <50A14E2A.5030205@omnitor.se> <50A15325.1010504@alcatel-lucent.com> In-Reply-To: <50A15325.1010504@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000202030707060501070209" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 20:05:35 -0000 This is a multi-part message in MIME format. --------------000202030707060501070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Igor, Thanks for the explanation. And I am striving for the communicating users to get back the rights to display their mistakes ;-) It is true that the feature is often mentioned in relation to accessible communication, but it is a generally usable feature. Gunnar On 2012-11-12 20:51, Igor Faynberg wrote: > Thanks for a quick reply! (Meanwhile, I was assured by Keith Drage > that this feature is needed by deaf--something I was not aware of, so > I need to catch up on learning. I imagine this would be used in > speech-to-text conversion and transmission.) > > Of course, thanks to my advanced age, I remember the Unix "Write" > application that did just that. My bad experience with it was that 22 > years ago I used that very application to communicate with my big > boss, and I wrote something without counting to 1,000. I should have > counted: The backspaces did not help... > > So I walked to Dennis Ritchie's office, told him what happened, and > suggested that "Write" ought to display messages only when Return is > hit. Surprisingly, he immediately agreed with me, but System 5 was > already out of his immediate control. He promised to follow-up > through the Unix Consortium, but soon that entity disappeared from our > radar screen. Inferno and Plan 9 though transmitted only full messages. > > This is what prompted my question. > > Now it has been answered! > > Igor > > > On 11/12/2012 2:29 PM, Gunnar Hellström wrote: >> Yes, backspaces are transmitted. >> >> I can assure that it is useful. >> >> And it needs not to be compared to messaging. It is intended for real >> conversational use of text, without the artificially created pauses >> for composing complete messages occurring in messaging. Just let the >> text go as you type it, with slight delay for time-sampling as for >> audio and video. >> It provides a rapid and smooth way to have the conversing parties >> synchronized in thoughts. >> >> >> >> There is of course still scope for traditional messaging even if I am >> more interested to see the real-time text implemented together with >> the other real-time media in RTCWEB. And there is even work on the >> way to introduce correction in already sent messages in traditional >> messaging. It is in XMPP XEP-0308. >> http://xmpp.org/extensions/xep-0308.html Also that is useful, and >> reduces stress, frustration and extra typing. It is usually when you >> have just completed and sent your message that you discover the >> mistake and want to correct it. >> >> Gunnar >> ___________________________________________________ >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> On 2012-11-12 20:03, Igor Faynberg wrote: >>> >>> >>> On 11/12/2012 4:06 AM, Gunnar Hellström wrote: >>>> ... >>>> Real-time text is text transmitted while it is being typed or >>>> created.*The recipient can read the sender's text as it is written, >>>> without waiting. >>>> >>>> *ietf.org/mailman/listinfo/rtcweb >>> >>> In this case, would that mean that when I type something and then >>> want to correct it, backspaces would be transmitted, too? If so, I >>> doubt it is useful. The second case, with the user having control >>> over sending of the message, is much better. >>> >>> Igor >>> >>> >>> _______________________________________________ >>> 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 --------------000202030707060501070209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Igor,
Thanks for the explanation.
And I am striving for the communicating users to get back the rights to display their mistakes ;-)

It is true that the feature is often mentioned in relation to accessible communication, but it is a generally usable feature.

Gunnar



On 2012-11-12 20:51, Igor Faynberg wrote:
Thanks for a quick reply!  (Meanwhile, I was assured by Keith Drage that this feature is needed by deaf--something I  was not aware of, so I need to catch up on learning.  I imagine this would be used in speech-to-text conversion and transmission.)

Of course, thanks to my advanced age, I remember the Unix "Write" application that did just that.  My bad experience with it was that 22 years ago I used that very application to communicate with my big boss, and I wrote  something without counting to 1,000.  I should have counted:  The backspaces did not help... 

 So I walked to Dennis Ritchie's office, told him what happened, and suggested that "Write" ought to display messages only when Return is hit. Surprisingly, he immediately agreed with me, but System 5 was already out of his immediate control.  He promised to follow-up through the Unix Consortium, but soon that entity disappeared from our radar screen.  Inferno and Plan 9 though transmitted only full messages.

This is what prompted my question. 

Now it has been answered!

Igor


On 11/12/2012 2:29 PM, Gunnar Hellström wrote:
Yes, backspaces are transmitted.

I can assure that it is useful.

And it needs not to be compared to messaging. It is intended for real conversational use of text, without the artificially created pauses for composing complete messages occurring in messaging. Just let the text go as you type it, with slight delay for time-sampling as for audio and video.
It provides a rapid and smooth way to have the conversing parties synchronized in thoughts.



There is of course still scope for traditional messaging even if I am more interested to see the real-time text implemented together with the other real-time media in RTCWEB. And there is even work on the way to introduce correction in already sent messages in traditional messaging. It is in XMPP XEP-0308.  http://xmpp.org/extensions/xep-0308.html    Also that is useful, and reduces stress, frustration and extra typing. It is usually when you have just completed and sent your message that you discover the mistake and want to correct it.

Gunnar
___________________________________________________
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2012-11-12 20:03, Igor Faynberg wrote:


On 11/12/2012 4:06 AM, Gunnar Hellström wrote:
...
Real-time text is text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.

ietf.org/mailman/listinfo/rtcweb

In this case, would that mean that when I type something and then want to correct it, backspaces would be transmitted, too?  If so, I doubt it is useful.   The second case, with the user having control over sending of the message, is much better.

Igor


_______________________________________________
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

--------------000202030707060501070209-- From randell-ietf@jesup.org Mon Nov 12 12:29:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABD521F8753 for ; Mon, 12 Nov 2012 12:29:57 -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 3xSuhE-yc565 for ; Mon, 12 Nov 2012 12:29:56 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1EC21F86F4 for ; Mon, 12 Nov 2012 12:29:56 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2846 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TY0do-0000wR-5l for rtcweb@ietf.org; Mon, 12 Nov 2012 14:29:56 -0600 Message-ID: <50A15BA8.2080403@jesup.org> Date: Mon, 12 Nov 2012 15:27:20 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A147FF.2000003@alcatel-lucent.com> <50A14E2A.5030205@omnitor.se> <50A15325.1010504@alcatel-lucent.com> In-Reply-To: <50A15325.1010504@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 20:29:57 -0000 On 11/12/2012 2:51 PM, Igor Faynberg wrote: > Thanks for a quick reply! (Meanwhile, I was assured by Keith Drage > that this feature is needed by deaf--something I was not aware of, so > I need to catch up on learning. I imagine this would be used in > speech-to-text conversion and transmission.) > > Of course, thanks to my advanced age, I remember the Unix "Write" > application that did just that. My bad experience with it was that 22 > years ago I used that very application to communicate with my big > boss, and I wrote something without counting to 1,000. I should have > counted: The backspaces did not help... Write(1) is one-way, talk(1) is two-way, but with real-time view of typing like Write. On 11/12/2012 2:48 PM, Jim Barnett wrote: > Yes, but is that a requirement on us, or on the people who roll out > services using webRTC? If RTT can be done via a bunch of (potentially > ugly) JS code and the data channel, then it's the service providers' > problem to write that ugly JS code. There's no requirement for the > W3C/IETF to provide native support for RTT as long as it's possible to > implement it on top of our standards. > > - Jim > P.S. I intend this as an argument for looking at RTT later, not for > skipping it altogether. I agree with Jim here - we-the-rtcweb-working-group do not have to spec out the solution to a specific country's legislative VRS/text requirements here, but should provide a mechanism for someone providing a service using these protocols to comply with (most) of those standards around the world. We can't follow all such legal requirements, as they are myriad and ever-changing, which is why good, generic transports and programmability are an excellent answer to the issue, especially as a start, and encourage people building responses to those requirements to do so in a standard way (preferably through a standards body, even an appropriate IETF working group). For example, the current VRS spec requires implementation of H.323 and ENUM... (and H.263 for video). I'll note that other country-specific telecom-regulation-requirements fall into this bucket as well, which I have no wish to bake into the core spec. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Richard Shockey > Sent: Monday, November 12, 2012 2:41 PM > To: 'Dale R. Worley'; rtcweb@ietf.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions > > > Dale is right ..you can delay the discussion but not the requirement. > The regulators will insist on this. > > http://transition.fcc.gov/cgb/dro/cvaa.html > > http://europa.eu/legislation_summaries/information_society/legislative_f > rame > work/l24216a_en.htm > -- Randell Jesup randell-ietf@jesup.org From salvatore.loreto@ericsson.com Mon Nov 12 12:56:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D8E21F85AF for ; Mon, 12 Nov 2012 12:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.971 X-Spam-Level: X-Spam-Status: No, score=-105.971 tagged_above=-999 required=5 tests=[AWL=0.278, 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 2MvzFCnvNnhE for ; Mon, 12 Nov 2012 12:56:39 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9FD21F84D3 for ; Mon, 12 Nov 2012 12:56:37 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-3d-50a162843ebe Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 00.D6.06323.48261A05; Mon, 12 Nov 2012 21:56:36 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 12 Nov 2012 21:56:35 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9746D244F for ; Mon, 12 Nov 2012 22:56:35 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A884C53897 for ; Mon, 12 Nov 2012 22:56:34 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5A58752F90 for ; Mon, 12 Nov 2012 22:56:34 +0200 (EET) Message-ID: <50A16282.2040608@ericsson.com> Date: Mon, 12 Nov 2012 22:56:34 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A147AD.6080001@omnitor.se> <50A15163.4080604@stpeter.im> In-Reply-To: <50A15163.4080604@stpeter.im> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvjW5L0sIAgwu7hCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt3Ph9gLDnFWfDnUxtTA+Ii9i5GTQ0LAROLnvB+MELaYxIV7 69lAbCGBk4wSv1+4dTFyAdkbGCVe/GpggXAuMEo8/vaVEcI5zCgxY98LKOcMo8SX5o9MIP28 AtoSjx7/BZvLIqAqMfvNRBYQm03ATOL5wy3MILaoQLLE2k9P2CHqBSVOznwCViMiICyx9VUv 2BxhAWuJCxtWMELctJVRYslZcxCbU0BLYt3Ul2BxZgELicVvDrJD2PISzVtnM0P8oyZx9dwm ZoheLYnes51MExhFZiFZNwtJ+ywk7QsYmVcxsucmZuakl5tvYgQG88Etvw12MG66L3aIUZqD RUmcV091v7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxrK55zPE99lN+XFv0QpuwafuH/50 WP4JT5669XmRtdou5glODqofa2KuJfUfFSo4OWfmGyWn6YXtdwrWZWrpGHopOF3f9SDH++ZE /1gFv/l+O+6/9YuX5przRVTmxWtmt1VrNtxVmG+1W1Ig/NWP9R+/WHBHnTnJO33jlIQ396d6 n14Z3HyVjVOJpTgj0VCLuag4EQBgLiZRNAIAAA== Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 20:56:40 -0000 On 11/12/12 9:43 PM, Peter Saint-Andre wrote: > On 11/12/12 12:02 PM, Gunnar Hellström wrote: >> On 2012-11-12 19:42, Peter Saint-Andre wrote: >>> Another option is RTT over XMPP: >>> >>> http://xmpp.org/extensions/xep-0301.html >>> >>> Given that there are plenty of JavaScript libraries for XMPP, that seems >>> like a rather easy approach. See alsohttp://realjabber.org/ >> Yes, that is the obvious other option. >> XEP-0301 need then to move on from its experimental state. > Yes, I expect that to happen in the relatively near future. Certainly > before RTCWEB is baked. :) > >> Do you mean that the transport of XMPP would be done beside RTCWEB, >> coordinated just by a specification saying "This is a way to do RTT >> together with an RTCWEB session?" Or would there be any more clear link >> or use of RTCWEB mechanisms? > One possibility is to negotiate an XMPP chat session via SDP, as Robert > Sparks once proposed a long time ago: > > https://datatracker.ietf.org/doc/draft-sparks-simple-jabber-sessions/ the other way would be run XMPP over WebSocket http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01 /Sal -- Salvatore Loreto, PhD www.sloreto.com From stpeter@stpeter.im Mon Nov 12 13:11:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9875621F85AF for ; Mon, 12 Nov 2012 13:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 LIpaBrz9uwMx for ; Mon, 12 Nov 2012 13:11:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DE0D821F852D for ; Mon, 12 Nov 2012 13:11:52 -0800 (PST) Received: from [64.101.72.39] (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 21D4840062; Mon, 12 Nov 2012 14:15:57 -0700 (MST) Message-ID: <50A16617.3050700@stpeter.im> Date: Mon, 12 Nov 2012 14:11:51 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Salvatore Loreto References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A147AD.6080001@omnitor.se> <50A15163.4080604@stpeter.im> <50A16282.2040608@ericsson.com> In-Reply-To: <50A16282.2040608@ericsson.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 21:11:53 -0000 On 11/12/12 1:56 PM, Salvatore Loreto wrote: > On 11/12/12 9:43 PM, Peter Saint-Andre wrote: >> On 11/12/12 12:02 PM, Gunnar Hellström wrote: >>> On 2012-11-12 19:42, Peter Saint-Andre wrote: >>>> Another option is RTT over XMPP: >>>> >>>> http://xmpp.org/extensions/xep-0301.html >>>> >>>> Given that there are plenty of JavaScript libraries for XMPP, that >>>> seems >>>> like a rather easy approach. See alsohttp://realjabber.org/ >>> Yes, that is the obvious other option. >>> XEP-0301 need then to move on from its experimental state. >> Yes, I expect that to happen in the relatively near future. Certainly >> before RTCWEB is baked. :) >> >>> Do you mean that the transport of XMPP would be done beside RTCWEB, >>> coordinated just by a specification saying "This is a way to do RTT >>> together with an RTCWEB session?" Or would there be any more clear link >>> or use of RTCWEB mechanisms? >> One possibility is to negotiate an XMPP chat session via SDP, as Robert >> Sparks once proposed a long time ago: >> >> https://datatracker.ietf.org/doc/draft-sparks-simple-jabber-sessions/ > > the other way would be run XMPP over WebSocket > http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01 Indeed. The XMPP WG might be recharted "soon" to take that on as a WG item. Peter -- Peter Saint-Andre https://stpeter.im/ From gunnar.hellstrom@omnitor.se Mon Nov 12 14:26:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF5C21F86EB for ; Mon, 12 Nov 2012 14:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drPYEySQ9Ef9 for ; Mon, 12 Nov 2012 14:26:04 -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 6566D21F86F3 for ; Mon, 12 Nov 2012 14:26:03 -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 ; Mon, 12 Nov 2012 23:25:55 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 2681D3A04E for ; Mon, 12 Nov 2012 23:25:55 +0100 (CET) Message-ID: <50A17774.9050004@omnitor.se> Date: Mon, 12 Nov 2012 23:25:56 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A147FF.2000003@alcatel-lucent.com> <50A14E2A.5030205@omnitor.se> <50A15325.1010504@alcatel-lucent.com> <50A15BA8.2080403@jesup.org> In-Reply-To: <50A15BA8.2080403@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 22:26:05 -0000 I am not talking about this for any specific requirements of a country. And not specfically from the accessibility point of view, even if it is included in the picture. All have a need for text communication occasionally or often in a call with voice or video. And the less wait time it causes, the more popular it will be. Same with the standards it uses. The more wide spread and interoperable it is, the more happy users it will get. And we can be proactive. Making a global solution usable for all should satisfy also the accessibility side better than any national solution. After the discussions today, I can see four solutions. It might be good to take them all a bit further to check pros and cons: 1. RFC 4103/T.140 in RTP/AVPF and SDP exchange in the same way as for video. 2. T.140 and something RFC4103-like in RTCWEB data channel and a specific protocol id. 3. XMPP XEP-0301 negotiated with SDP as an expired draft proposes, and transmitted by JS 4. XMPP XEP-0301 transmitted by JS / Websockets and negotiated in XMPP, and just specified to be used for this purpose. All 4 are variants fulfilling the use case extending the video telephony use case that I proposed to be extended by audio and real-time text. ( audio might have been there, but very vaguely described ) Gunnar On 2012-11-12 21:27, Randell Jesup wrote: > On 11/12/2012 2:51 PM, Igor Faynberg wrote: >> Thanks for a quick reply! (Meanwhile, I was assured by Keith Drage >> that this feature is needed by deaf--something I was not aware of, >> so I need to catch up on learning. I imagine this would be used in >> speech-to-text conversion and transmission.) >> >> Of course, thanks to my advanced age, I remember the Unix "Write" >> application that did just that. My bad experience with it was that >> 22 years ago I used that very application to communicate with my big >> boss, and I wrote something without counting to 1,000. I should >> have counted: The backspaces did not help... > > Write(1) is one-way, talk(1) is two-way, but with real-time view of > typing like Write. > > On 11/12/2012 2:48 PM, Jim Barnett wrote: >> Yes, but is that a requirement on us, or on the people who roll out >> services using webRTC? If RTT can be done via a bunch of (potentially >> ugly) JS code and the data channel, then it's the service providers' >> problem to write that ugly JS code. There's no requirement for the >> W3C/IETF to provide native support for RTT as long as it's possible to >> implement it on top of our standards. >> >> - Jim >> P.S. I intend this as an argument for looking at RTT later, not for >> skipping it altogether. > > I agree with Jim here - we-the-rtcweb-working-group do not have to > spec out the solution to a specific country's legislative VRS/text > requirements here, but should provide a mechanism for someone > providing a service using these protocols to comply with (most) of > those standards around the world. We can't follow all such legal > requirements, as they are myriad and ever-changing, which is why good, > generic transports and programmability are an excellent answer to the > issue, especially as a start, and encourage people building responses > to those requirements to do so in a standard way (preferably through a > standards body, even an appropriate IETF working group). > > For example, the current VRS spec requires implementation of H.323 and > ENUM... (and H.263 for video). > > I'll note that other country-specific telecom-regulation-requirements > fall into this bucket as well, which I have no wish to bake into the > core spec. > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Richard Shockey >> Sent: Monday, November 12, 2012 2:41 PM >> To: 'Dale R. Worley'; rtcweb@ietf.org >> Subject: Re: [rtcweb] Text communication in RTCWEB sessions >> >> >> Dale is right ..you can delay the discussion but not the requirement. >> The regulators will insist on this. >> >> http://transition.fcc.gov/cgb/dro/cvaa.html >> >> http://europa.eu/legislation_summaries/information_society/legislative_f >> rame >> work/l24216a_en.htm >> > From silviapfeiffer1@gmail.com Mon Nov 12 15:31:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FB621F86B8 for ; Mon, 12 Nov 2012 15:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG0T8IWp5Cct for ; Mon, 12 Nov 2012 15:31:12 -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 2641021F8625 for ; Mon, 12 Nov 2012 15:31:12 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7578727vbb.31 for ; Mon, 12 Nov 2012 15:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4oNMEA2kWGaSsuD001tu3vxxd5YXzOs048slxDCne8s=; b=pP4NoQ/vu7V8I+Cd1xgfl/UdmOxhJykaHEOIR6bn1DHY+DjjcysJAodtmvWaLFSQ8w 69AOTrPXDdFHipRe5ko0Y8zj6xabeFkyd9K1dal0sAbA8Bb6xVsRrki3pnnwXuYY66C2 IOs11JxXky4mvLhNWXsPKnwIMPCSlO8KwECTe8QSaSze9U9bNiH0kdMWiYk8qdqI8nXx 3DXtl4WIWRhJeH3H15ONtZsdDgaIoCjU4ltKAsVBIQC1GSC5k4tCJKm+9ajASRKlVirh BvZ2H6YV8xuAoTUiZCpuEqr0l3XVzrqLgkrQlFsFCeREH6i1mEzXt78XxqBD5cVUavEB JuIw== Received: by 10.220.225.132 with SMTP id is4mr2731508vcb.47.1352763071183; Mon, 12 Nov 2012 15:31:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.78.135 with HTTP; Mon, 12 Nov 2012 15:30:51 -0800 (PST) In-Reply-To: <50A17774.9050004@omnitor.se> References: <50A0BC04.6090200@omnitor.se> <50A147FF.2000003@alcatel-lucent.com> <50A14E2A.5030205@omnitor.se> <50A15325.1010504@alcatel-lucent.com> <50A15BA8.2080403@jesup.org> <50A17774.9050004@omnitor.se> From: Silvia Pfeiffer Date: Tue, 13 Nov 2012 10:30:51 +1100 Message-ID: To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= Content-Type: multipart/alternative; boundary=14dae9ccd52c52b9c104ce54b221 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2012 23:31:13 -0000 --14dae9ccd52c52b9c104ce54b221 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to enter WebVTT or more generically the TextTrackCue API of HTML into this discussion as a format for specifying timed text snippets - in particular for captions/subtitles, but also generally for any timed text requirements. They are being supported by all browsers, so should be relevant to WebRTC. The way I can see this being used is that you can look at a TextTrackCue as a "frame" of text with time stamps that can be transferred as a text entity over something like XMPP. In fact, Apple's HLS [1] is using WebVTT to transport captions. If we're starting to talk about baseline formats for timed text/data in WebRTC, WebVTT sounds like a pretty good candidate to me. Combined with a protocol that includes backspace and other live text editing features, I think it can provide for the transfer of richer text and not just plain text. Regards, Silvia. [1] http://tools.ietf.org/html/draft-pantos-http-live-streaming-10 On Tue, Nov 13, 2012 at 9:25 AM, Gunnar Hellstr=F6m < gunnar.hellstrom@omnitor.se> wrote: > I am not talking about this for any specific requirements of a country. > And not specfically from the accessibility point of view, even if it is > included in the picture. > > All have a need for text communication occasionally or often in a call > with voice or video. > And the less wait time it causes, the more popular it will be. > > Same with the standards it uses. The more wide spread and interoperable i= t > is, the more happy users it will get. > And we can be proactive. Making a global solution usable for all should > satisfy also the accessibility side better than any national solution. > > > After the discussions today, I can see four solutions. It might be good t= o > take them all a bit further to check pros and cons: > > 1. RFC 4103/T.140 in RTP/AVPF and SDP exchange in the same way as for > video. > > 2. T.140 and something RFC4103-like in RTCWEB data channel and a specific > protocol id. > > 3. XMPP XEP-0301 negotiated with SDP as an expired draft proposes, and > transmitted by JS > > 4. XMPP XEP-0301 transmitted by JS / Websockets and negotiated in XMPP, > and just specified to be used for this purpose. > > > All 4 are variants fulfilling the use case extending the video telephony > use case that I proposed to be extended by audio and real-time text. ( > audio might have been there, but very vaguely described ) > > > Gunnar > > > > > > > > > > > On 2012-11-12 21:27, Randell Jesup wrote: > >> On 11/12/2012 2:51 PM, Igor Faynberg wrote: >> >>> Thanks for a quick reply! (Meanwhile, I was assured by Keith Drage tha= t >>> this feature is needed by deaf--something I was not aware of, so I nee= d to >>> catch up on learning. I imagine this would be used in speech-to-text >>> conversion and transmission.) >>> >>> Of course, thanks to my advanced age, I remember the Unix "Write" >>> application that did just that. My bad experience with it was that 22 >>> years ago I used that very application to communicate with my big boss,= and >>> I wrote something without counting to 1,000. I should have counted: = The >>> backspaces did not help... >>> >> >> Write(1) is one-way, talk(1) is two-way, but with real-time view of >> typing like Write. >> >> On 11/12/2012 2:48 PM, Jim Barnett wrote: >> >>> Yes, but is that a requirement on us, or on the people who roll out >>> services using webRTC? If RTT can be done via a bunch of (potentially >>> ugly) JS code and the data channel, then it's the service providers' >>> problem to write that ugly JS code. There's no requirement for the >>> W3C/IETF to provide native support for RTT as long as it's possible to >>> implement it on top of our standards. >>> >>> - Jim >>> P.S. I intend this as an argument for looking at RTT later, not for >>> skipping it altogether. >>> >> >> I agree with Jim here - we-the-rtcweb-working-group do not have to spec >> out the solution to a specific country's legislative VRS/text requiremen= ts >> here, but should provide a mechanism for someone providing a service usi= ng >> these protocols to comply with (most) of those standards around the worl= d. >> We can't follow all such legal requirements, as they are myriad and >> ever-changing, which is why good, generic transports and programmability >> are an excellent answer to the issue, especially as a start, and encoura= ge >> people building responses to those requirements to do so in a standard w= ay >> (preferably through a standards body, even an appropriate IETF working >> group). >> >> For example, the current VRS spec requires implementation of H.323 and >> ENUM... (and H.263 for video). >> >> I'll note that other country-specific telecom-regulation-**requirements >> fall into this bucket as well, which I have no wish to bake into the cor= e >> spec. >> >> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.**org] >>> On Behalf >>> Of Richard Shockey >>> Sent: Monday, November 12, 2012 2:41 PM >>> To: 'Dale R. Worley'; rtcweb@ietf.org >>> Subject: Re: [rtcweb] Text communication in RTCWEB sessions >>> >>> >>> Dale is right ..you can delay the discussion but not the requirement. >>> The regulators will insist on this. >>> >>> http://transition.fcc.gov/cgb/**dro/cvaa.html >>> >>> http://europa.eu/legislation_**summaries/information_society/** >>> legislative_f >>> rame >>> work/l24216a_en.htm >>> >>> >> > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --14dae9ccd52c52b9c104ce54b221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to enter WebVTT or more generically the TextTrackCue API of HT= ML into this discussion as a format for specifying timed text snippets - in= particular for captions/subtitles, but also generally for any timed text r= equirements. They are being supported by all browsers, so should be relevan= t to WebRTC.

The way I can see this being used is that you can look at a TextTrackCu= e as a "frame" of text with time stamps that can be transferred a= s a text entity over something like XMPP.

In fact, Apple's HLS [= 1] is using WebVTT to transport captions.

If we're starting to talk about baseline formats for timed text/dat= a in WebRTC, WebVTT sounds like a pretty good candidate to me. Combined wit= h a protocol that includes backspace and other live text editing features, = I think it can provide for the transfer of richer text and not just plain t= ext.

Regards,
Silvia.

[1] http://tools.ietf.org/html/draft-pantos-= http-live-streaming-10


On Tue, No= v 13, 2012 at 9:25 AM, Gunnar Hellstr=F6m <gunnar.hellstrom@omni= tor.se> wrote:
I am not talking about this for any specific= requirements of a country.
And not specfically from the accessibility point of view, even if it is inc= luded in the picture.

All have a need for text communication occasionally or often in a call with= voice or video.
And the less wait time it causes, the more popular it will be.

Same with the standards it uses. The more wide spread and interoperable it = is, the more happy users it will get.
And we can be proactive. Making a global solution usable for all should sat= isfy also the accessibility side better than any national solution.


After the discussions today, I can see four solutions. It might be good to = take them all a bit further to check pros and cons:

1. RFC 4103/T.140 in RTP/AVPF and SDP exchange in the same way as for video= .

2. T.140 and something RFC4103-like in RTCWEB data channel and a specific p= rotocol id.

3. XMPP XEP-0301 negotiated with SDP as an expired draft proposes, and tran= smitted by JS

4. XMPP XEP-0301 transmitted by JS / Websockets and negotiated in XMPP, and= just specified to be used for this purpose.


All 4 are variants fulfilling the use case extending the video telephony us= e case that I proposed to be extended by audio and real-time text. =A0( aud= io might have been there, but very vaguely described )


Gunnar










On 2012-11-12 21:27, Randell Jesup wrote:
On 11/12/2012 2:51 PM, Igor Faynberg wrote:
Thanks for a quick reply! =A0(Meanwhile, I was assured by Keith Drage that = this feature is needed by deaf--something I =A0was not aware of, so I need = to catch up on learning. =A0I imagine this would be used in speech-to-text = conversion and transmission.)

Of course, thanks to my advanced age, I remember the Unix "Write"= application that did just that. =A0My bad experience with it was that 22 y= ears ago I used that very application to communicate with my big boss, and = I wrote =A0something without counting to 1,000. =A0I should have counted: = =A0The backspaces did not help...

Write(1) is one-way, talk(1) is two-way, but with real-time view of typing = like Write.

On 11/12/2012 2:48 PM, Jim Barnett wrote:
Yes, but is that a requirement on us, or on the people who roll out
services using webRTC? =A0If RTT can be done via a bunch of (potentially ugly) JS code and the data channel, =A0then it's the service providers&= #39;
problem to write that ugly JS code. =A0There's no requirement for the W3C/IETF to provide native support for RTT as long as it's possible to<= br> implement it on top of our standards.

- Jim
P.S. =A0I intend this as an argument for looking at RTT later, not for
skipping it altogether.

I agree with Jim here - we-the-rtcweb-working-group do not have to spec out= the solution to a specific country's legislative VRS/text requirements= here, but should provide a mechanism for someone providing a service using= these protocols to comply with (most) of those standards around the world.= =A0We can't follow all such legal requirements, as they are myriad and= ever-changing, which is why good, generic transports and programmability a= re an excellent answer to the issue, especially as a start, and encourage p= eople building responses to those requirements to do so in a standard way (= preferably through a standards body, even an appropriate IETF working group= ).

For example, the current VRS spec requires implementation of H.323 and ENUM= ... (and H.263 for video).

I'll note that other country-specific telecom-regulation-require= ments fall into this bucket as well, which I have no wish to bake into the = core spec.

-----Original Message-----
From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
Of Richard Shockey
Sent: Monday, November 12, 2012 2:41 PM
To: 'Dale R. Worley'; rtcweb@ietf.org
Subject: Re: [rtcweb] Text communication in RTCWEB sessions


Dale is right ..you can delay the discussion but not the requirement.
The regulators will insist on this.

h= ttp://transition.fcc.gov/cgb/dro/cvaa.html

http://europa.eu/legislation_summaries/i= nformation_society/legislative_f
rame
work/l24216a_en.htm



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

--14dae9ccd52c52b9c104ce54b221-- From gonzalo.camarillo@ericsson.com Mon Nov 12 23:38:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8837321F88CC for ; Mon, 12 Nov 2012 23:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.092 X-Spam-Level: X-Spam-Status: No, score=-106.092 tagged_above=-999 required=5 tests=[AWL=0.157, 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 clpvgZoFRZsM for ; Mon, 12 Nov 2012 23:38:04 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8283021F87C7 for ; Mon, 12 Nov 2012 23:38:03 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-5b-50a1f8daff00 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3C.05.11564.AD8F1A05; Tue, 13 Nov 2012 08:38:02 +0100 (CET) Received: from [131.160.36.86] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 13 Nov 2012 08:38:01 +0100 Message-ID: <50A1F8D9.9040101@ericsson.com> Date: Tue, 13 Nov 2012 09:38:01 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20121112220017.18613.37012.idtracker@ietfa.amsl.com> In-Reply-To: <20121112220017.18613.37012.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.5 X-Forwarded-Message-Id: <20121112220017.18613.37012.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RvfWj4UBBm1HhCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtYjxgWbRSs+frjO2MA4TaiLkZNDQsBEYuquZjYIW0ziwr31 YLaQwElGiWW9Gl2MXED2akaJx7dvsXcxcnDwCmhLtG5QAKlhEVCV+PH0OyuIzSZgIbHl1n0W EFtUIEri0MaD7CA2r4CgxMmZT8DiIgLCEltf9TKB2MICKRItrw4zQexylFgwYTlYDaeAk0Tb 6+MsEPdISrx9/4oZwvaVuNx0BmwXs4CmROv23+wQtrxE89bZzBBztCWWP2thmcAoNAvJ6llI WmYhaVnAyLyKkT03MTMnvdxwEyMwJA9u+a27g/HUOZFDjNIcLErivFxJ+/2FBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MOa6HP6osPrpt7Rra8ua2f/u9PrP8Jn7mvUC06O2hhwlejMZ37O3 BEzzKfn6z9hUdpl5Rekx+S3z7wtf/zcjpCsrIcR746EJXfbrhK1X2hhV2Fut/TljaemNC0ca XHZO2LVd4HH8vNikOjnTfTLiuxTsp+pP7ZvhGxUg5nrWrnzqLjYLySP/k5VYijMSDbWYi4oT AU84j4EXAgAA Subject: [rtcweb] Fwd: New Liaison Statement, "W3C's position on RTCWEB mandatory to implement video codec" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 07:38:04 -0000 FYI. Gonzalo -------- Original Message -------- Subject: New Liaison Statement, "W3C's position on RTCWEB mandatory to implement video codec" Date: Mon, 12 Nov 2012 14:00:17 -0800 From: Liaison Statement Management Tool To: Cullen Jennings , Ted Hardie , "Magnus Westerlund" CC: @ietfa.amsl.com>, <, Robert Sparks , Real-T@ietfa.amsl.com>, , , Mark Nottingham , <>, Philippe Le Hégaret , Tho@ietfa.amsl.com>, @ietfa.amsl.com> Title: W3C's position on RTCWEB mandatory to implement video codec Submission Date: 2012-11-03 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1215/ From: W3C (Philippe Le Hégaret ) To: Real-Time Communication in WEB-browsers (Cullen Jennings , Ted Hardie , Magnus Westerlund ) Cc: Gonzalo Camarillo ,Robert Sparks ,Real-Time Communication in WEB-browsers Discussion List ,Mark Nottingham Reponse Contact: Philippe Le Hégaret , Thomas Roessler Technical Contact: Purpose: For information Body: We understand that the IETF rtcweb Working Group is expecting to select a mandatory-to-implement video codec. W3C believes that there should be a royalty-free standard web infrastructure which should include Real Time Communications on the Web. W3C is not expressing any preference among the codecs based on the technical merits of the proposals before the working group. We wish to bring a few background facts to participants' attention. In 2011 W3C approached MPEG-LA, the licensing authority for the generally-known patent pool for H.264, with a proposal for royalty-free licensing of the H.264 baseline codec, to be referenced for use by the HTML5 video tag. MPEG-LA was receptive to this proposal; however, the proposal was turned down by a narrow margin within the MPEG-LA membership. Whatever codec the rtcweb Working Group might choose, we encourage the Working Group to work toward technologies that implementers can be confident are available on a royalty-free basis and W3C is willing to work with the IETF in achieving this. Regards, For Tim Berners-Lee, Director, and Jeff Jaffe, CEO, Philippe Le Hégaret and Thomas Roessler, IETF Contacts for W3C Attachments: No document has been attached From gunnar.hellstrom@omnitor.se Mon Nov 12 23:43:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85F121F88A0 for ; Mon, 12 Nov 2012 23:43:44 -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=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il4blDL4h6XH for ; Mon, 12 Nov 2012 23:43:44 -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 8196D21F883E for ; Mon, 12 Nov 2012 23:43:43 -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 ; Tue, 13 Nov 2012 08:43:34 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 4A6C33A185 for ; Tue, 13 Nov 2012 08:43:34 +0100 (CET) Message-ID: <50A1FA27.9050109@omnitor.se> Date: Tue, 13 Nov 2012 08:43:35 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------010104030700030305080706" Subject: [rtcweb] Video use case in draft-ietf-rtcweb-use-cases-and-requirements lacks audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 07:43:45 -0000 This is a multi-part message in MIME format. --------------010104030700030305080706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The requirements and use cases document draft-ietf-rtcweb-use-cases-and-requirements-09 starts with a use case 4.2.1 "Simple Video Communication Service". It is not at all obvious from the text that this service provides audio as well as video. Audio is only mentioned in a couple of paranthesis in section 4.2.1. I suggest to clearly state in section 4.2.1.1 that audio is included. Proposed changed 4.2.1.1 ------------------------------------------------------------------------------------------- 4.2.1. Simple Video Communication Service 4.2.1.1. Description Two or more users have loaded a video communication web application into their browsers, provided by the same service provider, and logged into the service it provides. The web service publishes information about user login status by pushing updates to the web application in the browsers. When one online user selects a peer online user, a 1-1 communication session with video and audio between the browsers of the two peers is initiated. The invited user might accept or reject the session. During session establishment a self-view is displayed, and once the session has been established the video sent from the remote peer is displayed in addition to the self-view. During the session, each user can select to remove and re-insert the self-view as often as desired. Each user can also change the sizes of his/her two video displays during the session. Audio is also exchanged between the parties. Each user can also pause sending of media (audio, video, or both) and mute incoming media. ------------------------------------------------------------------------------------------ Similarly, 4.3.1 Telephony terminal description would need mentioning that the call provides video and audio communication. I can only deduct that from requirement F1 that says that the camera is used, and F5 saying that good audio and video rendering is required. Nothing in 4.3.1 says what media is provided. (Was video intended in this use case?) Please add. (I will return separately to the proposals from yesterday to add the text medium.) Regards Gunnar --------------010104030700030305080706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The requirements and use cases document draft-ietf-rtcweb-use-cases-and-requirements-09
starts with a use case 4.2.1 "Simple Video Communication Service".

It is not at all obvious from the text that this service provides audio as well as video. Audio is only mentioned in a couple of paranthesis in section 4.2.1. I suggest to clearly state in section 4.2.1.1 that audio is included.

Proposed changed 4.2.1.1
-------------------------------------------------------------------------------------------
4.2.1.  Simple Video Communication Service



4.2.1.1.  Description


   Two or more users have loaded a video communication web application
   into their browsers, provided by the same service provider, and
   logged into the service it provides.  The web service publishes
   information about user login status by pushing updates to the web
   application in the browsers.  When one online user selects a peer
   online user, a 1-1 communication session with video and audio
   between the browsers of the two peers is initiated.  The invited 
   user might accept or reject the session.

   During session establishment a self-view is displayed, and once the
   session has been established the video sent from the remote peer is
   displayed in addition to the self-view.  During the session, each
   user can select to remove and re-insert the self-view as often as
   desired.  Each user can also change the sizes of his/her two video
   displays during the session. Audio is also exchanged between the
   parties. Each user can also pause sending of media (audio, video, 
   or both) and mute incoming media.
------------------------------------------------------------------------------------------

Similarly, 4.3.1 Telephony terminal description would need mentioning that the call provides video and audio communication.
I can only deduct that from requirement F1 that says that the camera is used, and F5 saying that good audio and video rendering is required. Nothing in 4.3.1 says what media is provided.  (Was video intended in this use case?) 
Please add.

(I will return separately to the proposals from yesterday to add the text medium.)

Regards
Gunnar

--------------010104030700030305080706-- From stefan.lk.hakansson@ericsson.com Mon Nov 12 23:48:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1367121F88B8 for ; Mon, 12 Nov 2012 23:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 OQ441pjeQAIO for ; Mon, 12 Nov 2012 23:48:12 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0721F88A0 for ; Mon, 12 Nov 2012 23:48:11 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-63-50a1fb3aed35 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 46.66.11564.A3BF1A05; Tue, 13 Nov 2012 08:48:11 +0100 (CET) Received: from [150.132.142.241] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 13 Nov 2012 08:48:10 +0100 Message-ID: <50A1FB3A.6010803@ericsson.com> Date: Tue, 13 Nov 2012 08:48:10 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A1FA27.9050109@omnitor.se> In-Reply-To: <50A1FA27.9050109@omnitor.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvja7174UBBlc2s1us/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKvrNrEV7BepmLHxO2sD40SBLkZODgkBE4lFc1oYIWwxiQv3 1rN1MXJxCAmcZJT42nqLBcJZyyjxYMEDNpAqXgFtic/XT7OA2CwCqhJf2pewgthsAjYSa7un MIHYogJhEmv2HGKCqBeUODnzCVi9iICwxNZXvUBxDg5hgSSJG1d8QMJCApoSvXsesIPYnAJa EiuWtYLZzAK2EhfmXGeBsOUlmrfOZoao15V49/oe6wRGgVlINsxC0jILScsCRuZVjOy5iZk5 6eWGmxiBYXZwy2/dHYynzokcYpTmYFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gTF8+6+i7KaAIocSPslopcsHdog7mF5VfMMl3O4RsLlHnemXoLfBq6f8K7d0GPP+eR/FdaWq w8y1cuXbrPJ7kQc0TmxmvVZb7dN+QY9Jhat8q0Pgsp2qLBNULtuW8u50u1Dx6MWuxr98Mu7l blN1Oe2l+q2FfS2/rmj9KD1t2+Z951os2GdUK7EUZyQaajEXFScCAJmCTcgBAgAA Subject: Re: [rtcweb] Video use case in draft-ietf-rtcweb-use-cases-and-requirements lacks audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 07:48:13 -0000 Gunnar, thanks. I will update the document. Stefan On 11/13/2012 08:43 AM, Gunnar Hellström wrote: > The requirements and use cases document > draft-ietf-rtcweb-use-cases-and-requirements-09 > starts with a use case 4.2.1 "Simple Video Communication Service". > > It is not at all obvious from the text that this service provides audio > as well as video. Audio is only mentioned in a couple of paranthesis in > section 4.2.1. I suggest to clearly state in section 4.2.1.1 that audio > is included. > > Proposed changed 4.2.1.1 > ------------------------------------------------------------------------------------------- > > > 4.2.1. Simple Video Communication Service > > > > 4.2.1.1. Description > > > > Two or more users have loaded a video communication web application > into their browsers, provided by the same service provider, and > logged into the service it provides. The web service publishes > information about user login status by pushing updates to the web > application in the browsers. When one online user selects a peer > online user, a 1-1 communication session with video and audio > between the browsers of the two peers is initiated. The invited > user might accept or reject the session. > > During session establishment a self-view is displayed, and once the > session has been established the video sent from the remote peer is > displayed in addition to the self-view. During the session, each > user can select to remove and re-insert the self-view as often as > desired. Each user can also change the sizes of his/her two video > displays during the session. Audio is also exchanged between the > parties. Each user can also pause sending of media (audio, video, > or both) and mute incoming media. > > ------------------------------------------------------------------------------------------ > > Similarly, 4.3.1 Telephony terminal description would need mentioning > that the call provides video and audio communication. > I can only deduct that from requirement F1 that says that the camera is > used, and F5 saying that good audio and video rendering is required. > Nothing in 4.3.1 says what media is provided. (Was video intended in > this use case?) > Please add. > > (I will return separately to the proposals from yesterday to add the > text medium.) > > Regards > Gunnar > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From duerst@it.aoyama.ac.jp Mon Nov 12 23:58:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC7321F88E0 for ; Mon, 12 Nov 2012 23:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.804 X-Spam-Level: X-Spam-Status: No, score=-101.804 tagged_above=-999 required=5 tests=[AWL=1.386, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, 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 hmRRpse6Rb2L for ; Mon, 12 Nov 2012 23:58:33 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2B21E21F88DC for ; Mon, 12 Nov 2012 23:58:32 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAD7wKqE026784 for ; Tue, 13 Nov 2012 16:58:21 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6776_cd4f_e436c8bc_2d67_11e2_96bf_001d096c5782; Tue, 13 Nov 2012 16:58:19 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33080) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 13 Nov 2012 16:58:20 +0900 Message-ID: <50A1FD99.3030501@it.aoyama.ac.jp> Date: Tue, 13 Nov 2012 16:58:17 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Adam Roach References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> <50A105D7.2000901@omnitor.se> <50A109F4.6010208@ericsson.com> <50A1171C.2020005@nostrum.com> <50A14CB9.8020706@nostrum.com> In-Reply-To: <50A14CB9.8020706@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 07:58:34 -0000 On 2012/11/13 4:23, Adam Roach wrote: > On 11/12/12 09:43, Eric Burger wrote: >> Wild*ssed counter proposal: getting the signaling and API right with a >> codec that does not require too much codec-level negotiation, >> arguments about quality, or arguments about intellectual property, >> seems like an incredibly reasonable first step to delivering something >> that people can use, instead of writing books about. > > I look forward to the UTF-8 versus UTF-16 battle. :) The IETF is very strongly UTF-8. The W3C is very strongly UTF-8 on the wire, but of course UTF-16 in JavaScript. So these battles are over. Regards, Martin. From oej@edvina.net Tue Nov 13 00:55:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE75021F8617 for ; Tue, 13 Nov 2012 00:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoriFGX3FSWW for ; Tue, 13 Nov 2012 00:55:28 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E824F21F844D for ; Tue, 13 Nov 2012 00:55:24 -0800 (PST) Received: from [192.168.40.36] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C6427754A8AA; Tue, 13 Nov 2012 08:55:21 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_D7B82CC5-EFEA-4F79-BD48-9C3F3CA9FE81" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <50A0E85E.4020201@alvestrand.no> Date: Tue, 13 Nov 2012 09:55:24 +0100 Message-Id: References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 08:55:30 -0000 --Apple-Mail=_D7B82CC5-EFEA-4F79-BD48-9C3F3CA9FE81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 12 nov 2012 kl. 13:15 skrev Harald Alvestrand : > I would prefer this to be added as a separate specification, rather = than done at this time. > The reason being that this should be relatively easy to add on top of = the data channel functionality, but will definitely take some time to = specify, so should not be on the critical path for this round of = specifications. T.140 is a codec in the RTP flow and is implemented in Asterisk and a = couple of Video SIP phones. I see no reason to move it to the data channel, that would limit = interoperability. Much easier - and faster - to implement in the RTP subsystem as it is = already covered by SDP offer/answer. /O >=20 > Harald >=20 > On 11/12/2012 10:06 AM, Gunnar Hellstr=F6m wrote: >> Real time sessions with video and audio are often accompanied with = some form of text communication. >>=20 >> It is mentioned in a couple of places in RTCWEB related = specifications, but I see a need to get the specifications of how text = should be handled up to the level of specification of the other media. >>=20 >> The real-time requirements are slightly lower on text communication = than on video and audio, so I realize that it can be carried by = mechanisms already available in the web browser environment. But even if = that will be the case, it needs to be considered and described, because = text communication is part of the real-time communication concepts = that RTCWEB belongs to. >>=20 >> I know three kinds of text communication: >>=20 >> Real-time text:=20 >>=20 >> Real-time text is text transmitted while it is being typed or = created. The recipient can read the sender's text as it is written, = without waiting. >>=20 >> Text messaging:=20 >>=20 >> Text messaging is text collected to complete messages and sent as a = whole when completed by specific user action. The recipient can read the = sender's text soon after it is transmitted. >>=20 >> Timed text: >>=20 >> Timed text is text sent together with with information about the = intended timing of the display, often related to another medium, such as = audio or video. The recipient can read the text presented timely to = events in the other media. >>=20 >>=20 >> Real-time text for conversational use has the timing requirement that = end-to-end latency shall not be more than 2 seconds for usable text, and = one second for good usability. This is clearly lower than the = requirements on audio and video that traditionally is 400 ms for usable = end-to-end latency. >>=20 >> Real-time text is briefly mentioned in a requirement in = draft-ietf-rtcweb-data-channel >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02 >>=20 >> All three text communication forms are mentioned in = http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt >>=20 >> I am most eager to see the use of real-time text specified in = relation to RTCWEB, but it might be good to touch all three types. >>=20 >>=20 >> I suggest that it starts with requirements and use cases in=20 >> = http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requiremen= ts/ >>=20 >>=20 >> I propose to add real-time text to use case 4.2.1 so that it reads: >>=20 >>=20 >> 4.2.1. Simple Video Communication Service with audio and real-time = text >>=20 >> 4.2.1.1. Description >>=20 >> Two or more users have loaded a video communication web = application >> into their browsers, provided by the same service provider, and >> logged into the service it provides. The web service publishes >> information about user login status by pushing updates to the web >> application in the browsers. When one online user selects a peer >> online user, a 1-1 video communication session between the = browsers >> of the two peers is initiated. The invited user might accept or >> reject the session. Audio and real-time text is also available >> during the session. >>=20 >> During session establishment a self-view is displayed, and once = the >> session has been established the video sent from the remote peer = is >> displayed in addition to the self-view. During the session, each >> user can select to remove and re-insert the self-view as often as >> desired. Each user can also change the sizes of his/her two video >> displays during the session. Audio from each user is presented to=20= >> the other user. While one user types in the real-time text area, = it >> is nearly immediately presented to the other user. Each user can >> also pause sending of media (audio, video, or both) and mute = incoming >> media >>=20 >>=20 >> An alternative is to add a small additional section in 4.2 >> " >> 4.2.x. Simple Video Communication Service with real-time text >>=20 >> 4.2.x.1. Description >>=20 >> This use-case has the audio and video communication of the Simple >> Video Communication Service use-case (Section 4.2.1). >>=20 >> But in addition to this, the users can send and receive real-time = text. >> While one user types in the real-time text area, it >> is nearly immediately presented to the other user. >> " >> A couple of requirements then need to be added in the A and F ranges = in 5.2 and 5.3, but I want to start with this initial proposal. >>=20 >> Gunnar Hellstrom >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_D7B82CC5-EFEA-4F79-BD48-9C3F3CA9FE81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 harald@alvestrand.no>:
=20 =20
I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a = codec in the  RTP flow and is implemented in Asterisk and a couple = of Video SIP phones.
I see no reason to move it to the data = channel, that would limit = interoperability.

Much easier - and faster - to = implement in the RTP subsystem as it is already covered by SDP = offer/answer.

/O


            = Harald

On 11/12/2012 10:06 AM, Gunnar Hellstr=F6m wrote:
Real time sessions with video and audio are often accompanied with some form of text communication.

It is mentioned in a couple of places in RTCWEB related specifications, but I see a need to get the specifications of how text should be handled up to the level of specification of the other media.

The real-time requirements are slightly lower on text communication than on video and audio, so I realize that it can be carried by mechanisms already available in the web browser environment. But even if that will be the case, it needs to be considered and described, because text communication is part of the real-time communication concepts that RTCWEB belongs to.

I know three kinds of text communication:

Real-time text:

Real-time text is text transmitted while it is = being typed or created. The recipient = can read the sender's text as it is written, without waiting.

Text messaging:

Text messaging is text collected to complete messages and sent as a whole when completed by specific user = action. The recipient can read the sender's text soon after it is transmitted.

Timed text:

Timed text is text sent together with with information about the intended timing of the display, often related to another medium, such as audio or video. The recipient can read the text presented timely to events in the other media.


Real-time text for conversational use has the timing requirement that end-to-end latency shall not be more than 2 seconds for usable text, and one second for good usability. This is clearly lower than the requirements on audio and video that traditionally is 400 ms for usable end-to-end latency.

Real-time text is briefly mentioned in a requirement in = draft-ietf-rtcweb-data-channel
http= ://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02

All three text communication forms are mentioned in http://t= ools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt

I am most eager to see the use of real-time text specified in relation to RTCWEB, but it might be good to touch all three types.


I suggest that it starts with requirements and use cases in
http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-a= nd-requirements/


I propose to add real-time text to use case 4.2.1 so that it reads:


4.2.1.  =
Simple Video Communication Service with =
audio and real-time text

4.2.1.1.  Description

   Two or more users have loaded a video communication web application
   into their browsers, provided by the same service provider, and
   logged into the service it provides.  The web service publishes
   information about user login status by pushing updates to the web
   application in the browsers.  When one online user selects a peer
   online user, a 1-1 video communication session between the browsers
   of the two peers is initiated.  The invited user might accept or
   reject the session. Audio and real-time text =
is also available
   during the session.

   During session establishment a self-view is displayed, and once the
   session has been established the video sent from the remote peer is
   displayed in addition to the self-view.  During the session, each
   user can select to remove and re-insert the self-view as often as
   desired.  Each user can also change the sizes of his/her two video
   displays during the session.  Audio from each =
user is presented to=20
   the other user. While one user types in the real-time text area, it
   is nearly immediately presented to the other user. Each =
user can
   also pause sending of media (audio, video, or both) and mute =
incoming
   media


An alternative is to add a small additional section in 4.2
"
4.2.x.  =
Simple Video Communication Service with real-time text

4.2.x.1.  Description

   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).

   But in addition to this, the users can send and receive real-time =
text.
   While one user types in the real-time text area, it
   is nearly immediately presented to the other user.
"
A couple of requirements then need to be added in the A and F ranges in 5.2 and 5.3, but I want to start with this initial proposal.

Gunnar Hellstrom






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

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

= --Apple-Mail=_D7B82CC5-EFEA-4F79-BD48-9C3F3CA9FE81-- From harald@alvestrand.no Tue Nov 13 01:53:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6575121F8672 for ; Tue, 13 Nov 2012 01:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.076 X-Spam-Level: X-Spam-Status: No, score=-110.076 tagged_above=-999 required=5 tests=[AWL=0.522, 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 DRwBqC1+c8FS for ; Tue, 13 Nov 2012 01:53:49 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CEB2121F8545 for ; Tue, 13 Nov 2012 01:53:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7AC6739E151; Tue, 13 Nov 2012 10:53:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSuFALpZy-4c; Tue, 13 Nov 2012 10:53:41 +0100 (CET) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AC26F39E091; Tue, 13 Nov 2012 10:53:41 +0100 (CET) Message-ID: <50A218FF.9050104@alvestrand.no> Date: Tue, 13 Nov 2012 10:55:11 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Olle E. Johansson" References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050804050508060703080007" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 09:53:50 -0000 This is a multi-part message in MIME format. --------------050804050508060703080007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/13/2012 09:55 AM, Olle E. Johansson wrote: > > 12 nov 2012 kl. 13:15 skrev Harald Alvestrand >: > >> I would prefer this to be added as a separate specification, rather >> than done at this time. >> The reason being that this should be relatively easy to add on top of >> the data channel functionality, but will definitely take some time to >> specify, so should not be on the critical path for this round of >> specifications. > T.140 is a codec in the RTP flow and is implemented in Asterisk and a > couple of Video SIP phones. > I see no reason to move it to the data channel, that would limit > interoperability. > > Much easier - and faster - to implement in the RTP subsystem as it is > already covered by SDP offer/answer. > Anything is possible, if someone is willing to do it. Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services? I don't understand T.140 - so I can't do the work. Someone who wants it should. --------------050804050508060703080007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:

12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alvestrand.no>:

I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a codec in the  RTP flow and is implemented in Asterisk and a couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit interoperability.

Much easier - and faster - to implement in the RTP subsystem as it is already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services?

I don't understand T.140 - so I can't do the work. Someone who wants it should.

--------------050804050508060703080007-- From gunnar.hellstrom@omnitor.se Tue Nov 13 02:20:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5799121F8477 for ; Tue, 13 Nov 2012 02:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2kcDUxDQDoQ for ; Tue, 13 Nov 2012 02:20:15 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id B022121F846D for ; Tue, 13 Nov 2012 02:20:10 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 13 Nov 2012 11:20:01 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id A73A73A0DF for ; Tue, 13 Nov 2012 11:20:01 +0100 (CET) Message-ID: <50A21ED3.2060002@omnitor.se> Date: Tue, 13 Nov 2012 11:20:03 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> In-Reply-To: <50A218FF.9050104@alvestrand.no> Content-Type: multipart/alternative; boundary="------------090102040707040403090509" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 10:20:16 -0000 This is a multi-part message in MIME format. --------------090102040707040403090509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am of course willing to contribute. Gunnar On 2012-11-13 10:55, Harald Alvestrand wrote: > On 11/13/2012 09:55 AM, Olle E. Johansson wrote: >> >> 12 nov 2012 kl. 13:15 skrev Harald Alvestrand > >: >> >>> I would prefer this to be added as a separate specification, rather >>> than done at this time. >>> The reason being that this should be relatively easy to add on top >>> of the data channel functionality, but will definitely take some >>> time to specify, so should not be on the critical path for this >>> round of specifications. >> T.140 is a codec in the RTP flow and is implemented in Asterisk and >> a couple of Video SIP phones. >> I see no reason to move it to the data channel, that would limit >> interoperability. >> >> Much easier - and faster - to implement in the RTP subsystem as it is >> already covered by SDP offer/answer. >> > Anything is possible, if someone is willing to do it. > > Olle and Gunnar, can you undertake to write a complete specification > for how to use T.140 with RTCWEB, including how it should fit in with > the API specification, and whether or not it supports the needs that > Gunnar has claimed for text services? > > I don't understand T.140 - so I can't do the work. Someone who wants > it should. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090102040707040403090509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I am of course willing to contribute.

Gunnar


On 2012-11-13 10:55, Harald Alvestrand wrote:
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:

12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alvestrand.no>:

I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a codec in the  RTP flow and is implemented in Asterisk and a couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit interoperability.

Much easier - and faster - to implement in the RTP subsystem as it is already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services?

I don't understand T.140 - so I can't do the work. Someone who wants it should.



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

--------------090102040707040403090509-- From worley@shell01.TheWorld.com Tue Nov 13 07:48:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F293921F86F1 for ; Tue, 13 Nov 2012 07:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=0.277, 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 aJFNUjJkkr3r for ; Tue, 13 Nov 2012 07:47:59 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id D328A21F86AD for ; Tue, 13 Nov 2012 07:47:56 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qADFl4AV020960 for ; Tue, 13 Nov 2012 10:47:06 -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 qADFl3KR977501 for ; Tue, 13 Nov 2012 10:47:04 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qADFl3Sc971105; Tue, 13 Nov 2012 10:47:03 -0500 (EST) Date: Tue, 13 Nov 2012 10:47:03 -0500 (EST) Message-Id: <201211131547.qADFl3Sc971105@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <50A1FD99.3030501@it.aoyama.ac.jp> (duerst@it.aoyama.ac.jp) Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 15:48:00 -0000 > From: Adam Roach > > I look forward to the UTF-8 versus UTF-16 battle. :) > From: "Martin J. DC > > The IETF is very strongly UTF-8. The W3C is very strongly UTF-8 on the > wire, but of course UTF-16 in JavaScript. So these battles are over. RFC 4103 specifies that text/t140 is encoded in UTF-8. Of course, the API can present it to the Javascript in whatever way it wants. There are a bunch of CJK extension sets above 0x10000, though, so UTF-16 may be problematic. Dale From fluffy@cisco.com Tue Nov 13 08:11:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D3721F876C for ; Tue, 13 Nov 2012 08:11: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 1ZsRLHLBtkoO for ; Tue, 13 Nov 2012 08:11:37 -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 B70D821F8769 for ; Tue, 13 Nov 2012 08:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1669; q=dns/txt; s=iport; t=1352823097; x=1354032697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ILrIMbLoCXS1Br0AKk29Pf2PtTtiBk/1WEmYCnmqcjw=; b=NyoWFMnS97ceHaOamtR+9tHEf3uIkbu2EULpUY+3Xkaj6/KKtHytLSD/ z0xai8mWMkceHG6QMobq539PVtC4ZV0psY0rrEBsiL+l3e0534DZL/LtX 0kF6XZW3h3ofWpTJPpdADX3cGDYEUHZAxPNOlurOeEzDvFWP/C/fVBX/Q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAC9wolCtJV2a/2dsb2JhbABEw22BCIIeAQEBAwESAWYFCwIBCA4KCiQyJQIEAQ0FCBqHYgYLmgiPZZAtBIwqhXNhA4glnC+Ba4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141914819" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 13 Nov 2012 16:11:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qADGBZvx015758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Nov 2012 16:11:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Tue, 13 Nov 2012 10:11:34 -0600 From: "Cullen Jennings (fluffy)" To: Thomas Roessler , Philippe Le Hegaret Thread-Topic: W3C's position on RTCWEB mandatory to implement video codec Thread-Index: AQHNwbmMR8soTZxid0GFkMfKWRn6tw== Date: Tue, 13 Nov 2012 16:11:31 +0000 Message-ID: References: <1351872308.2346.635.camel@chacal> <75485203-4F91-4C70-AD26-F6A8AFDD9AA1@w3.org> In-Reply-To: <75485203-4F91-4C70-AD26-F6A8AFDD9AA1@w3.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19360.002 x-tm-as-result: No--41.483800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3191EA35DC85A247B79474FF5318F547@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "public-ietf-w3c@w3.org" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] W3C's position on RTCWEB mandatory to implement video codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 16:11:38 -0000 This has been entered in the IETF liaison tool at=20 https://datatracker.ietf.org/liaison/1215/ On Nov 2, 2012, at 10:59 AM, Thomas Roessler wrote: > Redirecting to the correct address of the W3C/IETF coordination list. >=20 >=20 >=20 > On 2012-11-02, at 17:05 +0100, Philippe Le Hegaret wrote: >=20 >> We understand that the IETF rtcweb Working Group is expecting to select >> a mandatory-to-implement video codec. >>=20 >> W3C believes that there should be a royalty-free standard web >> infrastructure which should include Real Time Communications on the Web. >>=20 >> W3C is not expressing any preference among the codecs based on the >> technical merits of the proposals before the working group. We wish to >> bring a few background facts to participants' attention. >>=20 >> In 2011 W3C approached MPEG-LA, the licensing authority for the >> generally-known patent pool for H.264, with a proposal for royalty-free >> licensing of the H.264 baseline codec, to be referenced for use by the >> HTML5 video tag. MPEG-LA was receptive to this proposal; however, the >> proposal was turned down by a narrow margin within the MPEG-LA >> membership. >>=20 >> Whatever codec the rtcweb Working Group might choose, we encourage the >> Working Group to work toward technologies that implementers can be >> confident are available on a royalty-free basis and W3C is willing to >> work with the IETF in achieving this. >>=20 >> Regards, >>=20 >> For Tim Berners-Lee, Director, and >> Jeff Jaffe, CEO, >> Philippe Le H=E9garet and Thomas Roessler, IETF Contacts for W3C >>=20 >>=20 >>=20 >=20 >=20 From adam@nostrum.com Tue Nov 13 08:33:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4851C21F8754 for ; Tue, 13 Nov 2012 08:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.762 X-Spam-Level: X-Spam-Status: No, score=-101.762 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-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 VgcbN8mh3nhA for ; Tue, 13 Nov 2012 08:33:58 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D392221F8718 for ; Tue, 13 Nov 2012 08:33:57 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qADGXsYp087893 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 10:33:54 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A27672.9050801@nostrum.com> Date: Tue, 13 Nov 2012 10:33:54 -0600 From: Adam Roach 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: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no><50A0EF72.8080309@omnitor.se> <50A0F340.3050809@ericsson.com> <50A105D7.2000901@omnitor.se> <50A109F4.6010208@ericsson.com> <50A1171C.2020005@nostrum.com> <50A14CB9.8020706@nostrum.com> <50A1FD99.3030501@it.aoyama.ac.jp> In-Reply-To: <50A1FD99.3030501@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2012 16:33:59 -0000 On 11/13/12 01:58, "Martin J. Dürst" wrote: > On 2012/11/13 4:23, Adam Roach wrote: >> On 11/12/12 09:43, Eric Burger wrote: >>> Wild*ssed counter proposal: getting the signaling and API right with a >>> codec that does not require too much codec-level negotiation, >>> arguments about quality, or arguments about intellectual property, >>> seems like an incredibly reasonable first step to delivering something >>> that people can use, instead of writing books about. >> >> I look forward to the UTF-8 versus UTF-16 battle. :) > > The IETF is very strongly UTF-8. The W3C is very strongly UTF-8 on the > wire, but of course UTF-16 in JavaScript. So these battles are over. Yeah, the smiley face was supposed to convey that the the comment was meant as tongue-in-cheek. /a From martin.thomson@gmail.com Tue Nov 13 16:46:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD23E21F8428 for ; Tue, 13 Nov 2012 16:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.833 X-Spam-Level: X-Spam-Status: No, score=-3.833 tagged_above=-999 required=5 tests=[AWL=-0.234, 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 WBrndMrnZY4k for ; Tue, 13 Nov 2012 16:46:42 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0A21F8233 for ; Tue, 13 Nov 2012 16:46:39 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2897894lbk.31 for ; Tue, 13 Nov 2012 16:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CH6ZuaP5jO0tqNvY1uDsGFa4JeiQdRuS3GFPO4pjZ9M=; b=T8Bt4x3LwOV7oJDO+spjs13mdLBn2e7bW2jytT2RllWmzHTh7dswY4QFWvn5ccqs0r NW7pFB4B6I3BlwiisdZPC3hUAwvtzMtRPPytHubdGTGdnIhz+xpemxPMSUNIlX7zvv9R V+Zc4r1lcjgAEMUF6TTttb9G85/hu7fDPjatHOclqiNgkfaDWs3wKmyN+974NbFEtJur R95zCT+T0thBydGcdiSpM4/3IDVm2iEmwmxQTgKeVp1QV/6JFfSyodThGEeYV6gtXqD6 xeC5t4jPu7ScQvuhj+ICtbuNfYa4Dkd3r42gWrivaSk/Cuy+JrkCXFhhxPjyJ9etVDNl 91lQ== MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr6360583lab.2.1352853996748; Tue, 13 Nov 2012 16:46:36 -0800 (PST) Received: by 10.112.83.2 with HTTP; Tue, 13 Nov 2012 16:46:36 -0800 (PST) Date: Tue, 13 Nov 2012 16:46:36 -0800 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Rehydration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Nov 2012 00:46:43 -0000 Preconditions: Two peers, each have the following state: * open candidates * remote candidates with consent state * nominated candidate pairs * (optionally) DTLS session negotiated * outbound media streams for which consent has been given * inbound and outbound media streams, some of which have media flowing Trigger: One peer refreshes the page, or navigates to a page on the same origin. Desired Outcome: An analogue of the above state is created with minimal latency and no user interaction from the peer that did not refresh. The recreated session cannot re-use an SRTP key stream that may have already been used. Session continuation is OK, but restarting with the same keys would expose the session. In other words, don't re-use your security descriptions. The proposal made in the meeting (slide 11 of http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-11.pdf) proposes the following process: * Store old local description * Refresh page and create new PeerConnection * [Load old local description] * Apply old local description as offer * createOffer("RestartSession") to get new local description with new ICE and crypto * Apply new local description as offer and send it * Apply received answer as remote description It wasn't clear what properties are imparted as a result of setting a previously built description. It's also unclear if this is even feasible. We decided that setLocalDescription can only be called from a createOffer/createAnswer callback at the W3C meeting. Any new SDP will be completely incompatible with the old SDP. This proposal adds nothing if you are willing to pay the price of a round trip. Several, if you consider the need to re-run the DTLS handshake. It is possible to re-use some state at the non-refreshed peer: consented streams, open candidates. That is already necessary. Everything else must be rebuilt. The peer that refreshes must gather candidates and obtain consent for user media. Both peers still need consent for new candidate pairs and the DTLS handshake must be re-run. Media would need to be re-attached to the connection in a consistent fashion, for which it is non-obvious how. Other related state must also be recreated, such as whether particular streams are currently paused. Optimizations on ICE startup time are the only real possibility in this proposal. Prioritize the candidates that were previously in use. Avoid allocating relays if you weren't using them. These are of such marginal utility that I'd argue for SDP editing if applications cared to do this. Assuming that we can agree on an API for discovering which candidate pairs were nominated. If you are serious about rehydration, then we already have a far superior solution: * Request a handle to the RTCPeerConnection instance * Store the handle * Refresh or navigate * Load the handle * Recover the RTCPeerConnection instance using the handle No signaling would be necessary. The handle would have a very short lifetime after navigation to avoid resource exhaustion. The handle would also have to be origin-bound. It would be necessary to sever the ties to the old page when navigation occurs to avoid leakage (event handlers and output tags). It might not even be necessary to reacquire consent either. I tend to think that this alternative is probably more useful for navigation than it would be for refresh. Being able to navigate while continuing a communication session would be nice. On the other hand, refresh is often used to "fix" "broken" pages. Having the page restore a "broken" RTCPeerConnection instance would be annoying. Breaking handles on a "hard" refresh would be advisable if we pursued this solution. --Martin From harald@alvestrand.no Tue Nov 13 23:49:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEA021F841A for ; Tue, 13 Nov 2012 23:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.05 X-Spam-Level: X-Spam-Status: No, score=-110.05 tagged_above=-999 required=5 tests=[AWL=0.549, 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 LJ6+4+wAYPGB for ; Tue, 13 Nov 2012 23:49:10 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5B21F8685 for ; Tue, 13 Nov 2012 23:49:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B26AC39E130 for ; Wed, 14 Nov 2012 08:49:06 +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 VrBAS0xa7Uoe for ; Wed, 14 Nov 2012 08:49:05 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:f1a7:8f70:3a07:f9d9] (unknown [IPv6:2001:470:de0a:27:f1a7:8f70:3a07:f9d9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DC03A39E062 for ; Wed, 14 Nov 2012 08:49:04 +0100 (CET) Message-ID: <50A34CF0.40408@alvestrand.no> Date: Wed, 14 Nov 2012 08:49:04 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.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] Rehydration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Nov 2012 07:49:10 -0000 I'm somewhat leery of the rehydration concept - to me it seems like a lot of coding to get into a state that is unlikely to work reliably anyway. But anyway, since we're discussing it.... One problem with a "handles" based proposal is the question of where the context has to live - at the moment, Chrome is a multiprocess browser, and most of the context lives in the rendering process. Chrome's model says that if Bad Things (tm) happen, it's OK to let the rendering process die. Refreshing the page after a crash will (of course) mean that there's a new rendering process. Implementing a system of "recoverable handles" will then mean either that all the recoverable state has to live outside the rendering process or that rehydration will sometimes work and sometimes not. The last outcome is one I would like to avoid. On 11/14/2012 01:46 AM, Martin Thomson wrote: > Preconditions: > Two peers, each have the following state: > * open candidates > * remote candidates with consent state > * nominated candidate pairs > * (optionally) DTLS session negotiated > * outbound media streams for which consent has been given > * inbound and outbound media streams, some of which have media flowing > Trigger: > One peer refreshes the page, or navigates to a page on the same origin. > Desired Outcome: > An analogue of the above state is created with minimal latency and > no user interaction from the peer that did not refresh. > The recreated session cannot re-use an SRTP key stream that may have > already been used. Session continuation is OK, but restarting with > the same keys would expose the session. In other words, don't re-use > your security descriptions. > > The proposal made in the meeting (slide 11 of > http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-11.pdf) > proposes the following process: > * Store old local description > * Refresh page and create new PeerConnection > * [Load old local description] > * Apply old local description as offer > * createOffer("RestartSession") to get new local description with new > ICE and crypto > * Apply new local description as offer and send it > * Apply received answer as remote description > > It wasn't clear what properties are imparted as a result of setting a > previously built description. It's also unclear if this is even > feasible. We decided that setLocalDescription can only be called from > a createOffer/createAnswer callback at the W3C meeting. Any new SDP > will be completely incompatible with the old SDP. > > This proposal adds nothing if you are willing to pay the price of a > round trip. Several, if you consider the need to re-run the DTLS > handshake. It is possible to re-use some state at the non-refreshed > peer: consented streams, open candidates. That is already necessary. > > Everything else must be rebuilt. The peer that refreshes must gather > candidates and obtain consent for user media. Both peers still need > consent for new candidate pairs and the DTLS handshake must be re-run. > Media would need to be re-attached to the connection in a consistent > fashion, for which it is non-obvious how. Other related state must > also be recreated, such as whether particular streams are currently > paused. > > Optimizations on ICE startup time are the only real possibility in > this proposal. Prioritize the candidates that were previously in use. > Avoid allocating relays if you weren't using them. These are of such > marginal utility that I'd argue for SDP editing if applications cared > to do this. Assuming that we can agree on an API for discovering > which candidate pairs were nominated. > > If you are serious about rehydration, then we already have a far > superior solution: > * Request a handle to the RTCPeerConnection instance > * Store the handle > * Refresh or navigate > * Load the handle > * Recover the RTCPeerConnection instance using the handle > > No signaling would be necessary. The handle would have a very short > lifetime after navigation to avoid resource exhaustion. The handle > would also have to be origin-bound. It would be necessary to sever > the ties to the old page when navigation occurs to avoid leakage > (event handlers and output tags). It might not even be necessary to > reacquire consent either. > > I tend to think that this alternative is probably more useful for > navigation than it would be for refresh. Being able to navigate while > continuing a communication session would be nice. On the other hand, > refresh is often used to "fix" "broken" pages. Having the page > restore a "broken" RTCPeerConnection instance would be annoying. > Breaking handles on a "hard" refresh would be advisable if we pursued > this solution. > > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Wed Nov 14 09:06:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095AF21F86FC for ; Wed, 14 Nov 2012 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.817 X-Spam-Level: X-Spam-Status: No, score=-3.817 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 0ehoncuiUdy6 for ; Wed, 14 Nov 2012 09:06:39 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4CE21F8721 for ; Wed, 14 Nov 2012 09:06:38 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so583450lah.31 for ; Wed, 14 Nov 2012 09:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+Mxv74sPg0iFQJ5dHMZGUHQs2qmh18+aAsSTW9nq5oE=; b=ficSO8qa7lo80YDEJSi3XpObeHcBzTj00oJ4lxMGO0ArMtE1pKbC/ExnNm7ZFl95XJ nd4lxlvtdrTKLSA1YhmS5Amqx4x1PFpBbYioNcHhjYNBx/jNzw3lGRnIfKySsBtBLCTw x1HpSSi+xxZGo/SPSpTLxKYj0bCyN3/mmLR0LgZ1hkuPM+gYr7IssffkOQPcsKMoMiJg 6+KwjadNWJ0hdqE8h8CDpfoJFTfZ4ZytZSUqSR0fNf5QLblP+L7sjpI+750NMIQGuHEO uyIIMQtZMPS0UtmfZ/ZV+TSaT7xpzBsyzEH9Lva8WQk9uAMicbh3zK/wuuarPrRJKoXq DA+Q== MIME-Version: 1.0 Received: by 10.112.43.70 with SMTP id u6mr7047617lbl.59.1352912797834; Wed, 14 Nov 2012 09:06:37 -0800 (PST) Received: by 10.112.83.2 with HTTP; Wed, 14 Nov 2012 09:06:37 -0800 (PST) In-Reply-To: <50A34CF0.40408@alvestrand.no> References: <50A34CF0.40408@alvestrand.no> Date: Wed, 14 Nov 2012 09:06:37 -0800 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Rehydration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Nov 2012 17:06:40 -0000 In 13 November 2012 23:49, Harald Alvestrand wrote: > I'm somewhat leery of the rehydration concept - to me it seems like a lot of > coding to get into a state that is unlikely to work reliably anyway. But > anyway, since we're discussing it.... I actually agree with you. I wrote this as a follow up to the action I took in the meeting. I can understand the usability advantages, but I'd rather focus effort on making startup faster under all conditions. > Implementing a system of "recoverable handles" will then mean either that > all the recoverable state has to live outside the rendering process or that > rehydration will sometimes work and sometimes not. That's OK. If we were to pursue something like this, an application would have to be prepared for the handle to be invalid. For more reasons than that. Reload might take too long; the application might be loaded after a long time away; the computer or browser might have just started up; etc... In the end, sometimes work, sometimes not is one price you would have to pay for this. From dromasca@avaya.com Thu Nov 15 10:04:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574AF21F84F9 for ; Thu, 15 Nov 2012 10:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WguiGZ69986c for ; Thu, 15 Nov 2012 10:04:24 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 335C621F850A for ; Thu, 15 Nov 2012 10:04:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4gAKUvoFDGmAcF/2dsb2JhbABEhAO+SgEDAQECgQCBCIIgAQEDEh4KUQEVFQYMDAdQBwEEEwgBGYdoC5l7hCucAIwvgQ8xgUmCRmEDnAmKNoJwgWM X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="332726295" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Nov 2012 12:59:42 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Nov 2012 13:01:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Nov 2012 19:04:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: performance metrics directory Thread-Index: Ac3DW6K84Xpvc99fSxCADltlTyPDbw== From: "Romascanu, Dan (Dan)" To: Subject: [rtcweb] performance metrics directory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Nov 2012 18:04:25 -0000 During the discussion about performance statistics last week in Atlanta I mentioned the performance metrics directorate and promised to provide pointers. The wiki page is available at http://www.ietf.org/iesg/directorate/performance-metrics.html and the mail list is pm-dir@ietf.org.=20 Regards, Dan From pkyzivat@alum.mit.edu Thu Nov 15 14:10:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657E421F8A15 for ; Thu, 15 Nov 2012 14:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, 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 tKBBPcxIcJiq for ; Thu, 15 Nov 2012 14:09:59 -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 32F5321F8A0B for ; Thu, 15 Nov 2012 14:09:52 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id Pnkf1k0020QuhwU54y9rm1; Thu, 15 Nov 2012 22:09:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id Py9r1k00D3ZTu2S3Ny9r1x; Thu, 15 Nov 2012 22:09:51 +0000 Message-ID: <50A5682E.2060103@alum.mit.edu> Date: Thu, 15 Nov 2012 17:09:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> In-Reply-To: <50A14328.9060002@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Nov 2012 22:10:00 -0000 On 11/12/12 1:42 PM, Peter Saint-Andre wrote: > Another option is RTT over XMPP: > > http://xmpp.org/extensions/xep-0301.html Another option is RTT over a datachannel. But then why not audio and video over datachannels too? Thanks, Paul From Jim.Barnett@genesyslab.com Thu Nov 15 15:17:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826BB11E809B for ; Thu, 15 Nov 2012 15:17: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 sldImvtDUYD2 for ; Thu, 15 Nov 2012 15:17:17 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 87FF821F841D for ; Thu, 15 Nov 2012 15:17:17 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id qAFNHBEN021679; Thu, 15 Nov 2012 15:17:11 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Nov 2012 15:16:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Nov 2012 15:15:16 -0800 Message-ID: In-Reply-To: <50A5682E.2060103@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3Dffdn0/4n9HCeQsKMqBHmYeJTPwACQPcg References: <201211121714.qACHEMoq914291@shell01.TheWorld.com><50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A5682E.2060103@alum.mit.edu> From: "Jim Barnett" To: "Paul Kyzivat" , X-OriginalArrivalTime: 15 Nov 2012 23:16:50.0523 (UTC) FILETIME=[4AB8AAB0:01CDC387] Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Nov 2012 23:17:20 -0000 There will certainly be uses for audio over a datachannel - when talking to a speech recognition system, for example. - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, November 15, 2012 5:10 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions On 11/12/12 1:42 PM, Peter Saint-Andre wrote: > Another option is RTT over XMPP: > > http://xmpp.org/extensions/xep-0301.html Another option is RTT over a datachannel. But then why not audio and video over datachannels too? Thanks, Paul _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From erik@hookflash.com Thu Nov 15 15:41:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7B21F0C73 for ; Thu, 15 Nov 2012 15:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaUHEzRcJ1yp for ; Thu, 15 Nov 2012 15:41:56 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEA41F0C6A for ; Thu, 15 Nov 2012 15:41:56 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so1449794iaf.31 for ; Thu, 15 Nov 2012 15:41:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=qwOoTftScK4PBvWaIE5GhDY6o7XOjlGSPXKwvBYkHKI=; b=p4wVeDD2eeoNk7sQeerebBOC6cXtzxiFBz6MjZlSubfF/SRIPQNkLuzMn42G0XRkRL CH5WpNiG80WCOSWa/mSXMbAbaKMaNUM0KQLM0MicWnHcQTsPwVOY2Q4OXE0+8ecWwL/0 66hTJOgYQvGxXoOoMFQdhFTuqXPW6HgLTxchAvqx0byTWhZ+cG5MV72yODAUPisGdcgm nPRTXtMvoCkLfqKETaHHfaOaPhxa1zp4XBL19injtOtzfXSNL7cv/26Y1JTJwcn+0swH i3SVDip0/7lk6mV2BevZvHr+N5oYAybWRNBhuq7jtSt6P0bbpMbuPEDtnBsg0QnVdueD i8gw== MIME-Version: 1.0 Received: by 10.50.169.102 with SMTP id ad6mr1492388igc.10.1353022915761; Thu, 15 Nov 2012 15:41:55 -0800 (PST) Received: by 10.50.88.230 with HTTP; Thu, 15 Nov 2012 15:41:55 -0800 (PST) In-Reply-To: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A5682E.2060103@alum.mit.edu> Date: Thu, 15 Nov 2012 15:41:55 -0800 Message-ID: From: Erik Lagerway To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=e89a8f2343514457ac04ce9132f0 X-Gm-Message-State: ALoCoQmWgqju+ljQLiNCAmmkAK0uMP1zJVwXiryoLWY+pnsOEjuoyVXgVjbJwoBMhUiL02Mb1Mgv Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Nov 2012 23:41:57 -0000 --e89a8f2343514457ac04ce9132f0 Content-Type: text/plain; charset=ISO-8859-1 Maybe we should focus on getting the datachannel working in a browser before we start discussions around RTT? Not saying RTT is not important just wonder if now is the right time to start in on those discussions. Cheers, Erik On Thu, Nov 15, 2012 at 3:15 PM, Jim Barnett wrote: > There will certainly be uses for audio over a datachannel - when talking > to a speech recognition system, for example. > > - Jim > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, November 15, 2012 5:10 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions > > On 11/12/12 1:42 PM, Peter Saint-Andre wrote: > > > Another option is RTT over XMPP: > > > > http://xmpp.org/extensions/xep-0301.html > > Another option is RTT over a datachannel. > > But then why not audio and video over datachannels too? > > Thanks, > Paul > > _______________________________________________ > 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 > -- *Erik Lagerway | *Hookflash * | @elagerway | m 1.604.562.8647* --e89a8f2343514457ac04ce9132f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maybe we should focus on getting the datachannel working in a browser befor= e we start discussions around RTT? Not saying RTT is not important just won= der if now is the right time to start in on those discussions.

Cheers,
Erik

On Thu, Nov 15, 2012 at 3:15 PM, Jim Barnett <= ;Jim.Barnet= t@genesyslab.com> wrote:
There will certainly be uses for audio over = a datachannel - when talking
to a speech recognition system, for example.

- Jim

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf
Of Paul Kyzivat
Sent: Thursday, November 15, 2012 5:10 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Text communication in RTCWEB sessions

On 11/12/12 1:42 PM, Peter Sa= int-Andre wrote:

> Another option is RTT over XMPP:
>
> http://xmpp.org/extensions/xep-0301.html

Another option is RTT over a datachannel.

But then why not audio and video over datachannels too?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

_______________________________________________
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



--
= Erik Lage= rway | <= /span>Hookflash= | <= a style=3D"color:rgb(0,0,0)" href=3D"http://twitter.com/elagerway" target= =3D"_blank">@elagerway | m 1.604.562.8647
--e89a8f2343514457ac04ce9132f0-- From randell-ietf@jesup.org Thu Nov 15 20:50:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC79221F8472 for ; Thu, 15 Nov 2012 20:50:31 -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 Q8pDiQZNpea7 for ; Thu, 15 Nov 2012 20:50:31 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2543221E8045 for ; Thu, 15 Nov 2012 20:50:30 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3612 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TZDsr-000Gg2-U8 for rtcweb@ietf.org; Thu, 15 Nov 2012 22:50:29 -0600 Message-ID: <50A5C60F.9020603@jesup.org> Date: Thu, 15 Nov 2012 23:50:23 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A5682E.2060103@alum.mit.edu> 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Nov 2012 04:50:32 -0000 On 11/15/2012 6:41 PM, Erik Lagerway wrote: > Maybe we should focus on getting the datachannel working in a browser > before we start discussions around RTT? Not saying RTT is not > important just wonder if now is the right time to start in on those > discussions. http://mozilla.github.com/webrtc-landing/data_test.html :-) You'll want the current Firefox Nightly (http://nightly.mozilla.org/) or a local build from the mozilla-central repo -- Randell Jesup randell-ietf@jesup.org From magnus.westerlund@ericsson.com Fri Nov 16 07:11:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF58521F87E4 for ; Fri, 16 Nov 2012 07:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 RSsIcoYb7i96 for ; Fri, 16 Nov 2012 07:11:15 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 142DA21F8777 for ; Fri, 16 Nov 2012 07:11:14 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-1f-50a65790f9fd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 89.9C.26143.09756A05; Fri, 16 Nov 2012 16:11:12 +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; Fri, 16 Nov 2012 16:11:12 +0100 Message-ID: <50A6578F.3050501@ericsson.com> Date: Fri, 16 Nov 2012 16:11:11 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvje6E8GUBBn+2mFus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBMbF7AW9HBVbF92lq2BcTpHFyMnh4SAiUTb0nZWCFtM4sK9 9WxdjFwcQgInGSVWv9jBDuEsZ5TobT/CBFLFK6AtcfDFIbAOFgFVib8734LZbAIWEjd/NLKB 2KICwRJ7jq1lhKgXlDg58wkLiC0ioC5x+eEFdhBbWEBX4sf0y0wQmyUl3r5/xQxiMwvoSUy5 2sIIYctLNG+dDRYXAtrb0NTBOoGRfxaSsbOQtMxC0rKAkXkVI3tuYmZOernRJkZgQB3c8lt1 B+OdcyKHGKU5WJTEea237vEXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMhgzLEtT/7qjKft IfMf/tjSYxkTfGGGbLCf+s/vRee2fGESWj9t+TzrnOtmcre7OFryBNour9id48y37MTOX1b/ /irqxUf8s8wQuVJ1cp7srInXbq89EGZQqHSEd732lvZHMVLPPP/VP/2cbXzGOOnCg22hT480 pJzZMi+tNnHutLiJSg/m2K5SYinOSDTUYi4qTgQAM4f2QfYBAAA= Subject: [rtcweb] Doodle poll for Face to Face Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Nov 2012 15:11:21 -0000 WG, We chairs have discussed with our W3C counter parts and are considering a co-located 3 day long face to face interim meeting. We would share the time approximately even and also switch back and forth between the group to be able to deal with both sides of some issues. We have two hard rules that makes the time window for when the meeting is at all possible to be only three weeks at the end of January and beginning of February. The meeting is planned to be run Tuesday to Thursday for three full days. Our main focus will be JSEP and SDP related. So please provide input on what dates that works for you by next Friday (23rd of Nov) by filling in the below Doodle: http://www.doodle.com/wvzp6ue9awn7wpni Any additional comments, suggestions or volunteering for hosting are welcome. 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 ekr@rtfm.com Fri Nov 16 14:10:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795C421F85FE for ; Fri, 16 Nov 2012 14:10:36 -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 hSUYbkpD1mZC for ; Fri, 16 Nov 2012 14:10:30 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5253821F84A1 for ; Fri, 16 Nov 2012 14:10:30 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2613931lah.31 for ; Fri, 16 Nov 2012 14:10:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Gu8kidv+D+Zoh16j8rt/E1iUV7MyKdXL6z04JOLdgRY=; b=QlLb5II40EAxHzqbwcC0WcNpnQLJtEGrw1S3zijJI9JZB189a2AUlR+9cUSRz0g9aw Zg03FHGsNmecZjvTJ7SXMFtkgOrXb13cOYO2Ac7aHm6AejjBKuS7EXfYMuuD1ImjK4mL SXfZq267xpk+Xhcnt/cQxcDfPYGiRXsMP5hkG8ZQon0lihxzA2oFphpv+vkNp8TqkToZ ymaPm099P0pmkmg4YwiJ/2p6/DSFeCvv8BYc2hxATrCtewi0nYqDF/Z1ifl0ljz/m9lD bHFujtV0uwssthB78rizMSe2sbr+QonC6IrNly3o8Oz+25Ce5TaKyZWJNWDtBTIsOHKs 2wGA== Received: by 10.152.103.38 with SMTP id ft6mr5425033lab.40.1353103829138; Fri, 16 Nov 2012 14:10:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.18.228 with HTTP; Fri, 16 Nov 2012 14:09:48 -0800 (PST) X-Originating-IP: [63.245.220.224] In-Reply-To: <50A6578F.3050501@ericsson.com> References: <50A6578F.3050501@ericsson.com> From: Eric Rescorla Date: Fri, 16 Nov 2012 14:09:48 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d040715fd147def04cea409d1 X-Gm-Message-State: ALoCoQnX9xZWfF6bQag7Qp0FRw/QOGt3VWqBgpulkWCfXTpdqdvhuW3kgsUHmhoELr1V7EiGH3Gi Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle poll for Face to Face Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Nov 2012 22:10:36 -0000 --f46d040715fd147def04cea409d1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chairs, I thought when we planned the last interim we agreed that future interims would happen in deterministic locations. Before we figure out when it is, can the chairs please announce *where* it will be. I just finished re-ran my venue rotation software and it spits out "East Coast" as the next location. Given that the last IETF was in Atlanta and the next is in Orlando, I would suggest either NYC, Washington DC, or Boston (though NYC is probably out due to cost.) In any case, can the chairs please specify *which* East Coast city it will be in? -Ekr On Fri, Nov 16, 2012 at 7:11 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > We chairs have discussed with our W3C counter parts and are considering > a co-located 3 day long face to face interim meeting. We would share the > time approximately even and also switch back and forth between the group > to be able to deal with both sides of some issues. > > We have two hard rules that makes the time window for when the meeting > is at all possible to be only three weeks at the end of January and > beginning of February. The meeting is planned to be run Tuesday to > Thursday for three full days. > > Our main focus will be JSEP and SDP related. > > So please provide input on what dates that works for you by next Friday > (23rd of Nov) by filling in the below Doodle: > > http://www.doodle.com/wvzp6ue9awn7wpni > > Any additional comments, suggestions or volunteering for hosting are > welcome. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d040715fd147def04cea409d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chairs,

I thought w= hen we planned the last=A0interim=A0we agreed that future
interims would happen= in deterministic locations. Before we
figure out when it is, can the chairs please announce *where*
it will be.

I just fini= shed re-ran my venue rotation software and it spits
out "East Coast" as the next location.=A0Given that the last
IETF was in Atlanta = and the next is in Orlando, I would suggest
either NYC, Washingto= n DC, or Boston (though NYC is probably
out due to cost.)
In any case, can the chairs please=A0specify *which* East Coast city
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13.= 333333969116211px;background-color:rgb(255,255,255)">it will be in?

-Ekr
<= br>
On Fri, Nov 16, 2012 at 7:11 AM, Magnus Weste= rlund <magnus.westerlund@ericsson.com> wrote:
WG,

We chairs have discussed with our W3C counter parts and are considering
a co-located 3 day long face to face interim meeting. We would share the time approximately even and also switch back and forth between the group to be able to deal with both sides of some issues.

We have two hard rules that makes the time window for when the meeting
is at all possible to be only three weeks at the end of January and
beginning of February. The meeting is planned to be run Tuesday to
Thursday for three full days.

Our main focus will be JSEP and SDP related.

So please provide input on what dates that works for you by next Friday
(23rd of Nov) by filling in the below Doodle:

http:/= /www.doodle.com/wvzp6ue9awn7wpni

Any additional comments, suggestions or volunteering for hosting are
welcome.

Cheers

Magnus Westerlund

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

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

--f46d040715fd147def04cea409d1-- From gunnar.hellstrom@omnitor.se Sat Nov 17 15:33:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B584521F84D3 for ; Sat, 17 Nov 2012 15:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz8GqIM6c2G8 for ; Sat, 17 Nov 2012 15:33:53 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 8AC3021F85FC for ; Sat, 17 Nov 2012 15:33:50 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 18 Nov 2012 00:33:39 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 76ECF3A1DF for ; Sun, 18 Nov 2012 00:33:38 +0100 (CET) Message-ID: <50A81ED2.9010604@omnitor.se> Date: Sun, 18 Nov 2012 00:33:38 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> In-Reply-To: <50A21ED3.2060002@omnitor.se> Content-Type: multipart/mixed; boundary="------------070102030808040700000001" Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 23:33:53 -0000 This is a multi-part message in MIME format. --------------070102030808040700000001 Content-Type: multipart/alternative; boundary="------------060706090209010903010606" --------------060706090209010903010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I have proposals for adding real-time text to the use cases document. I hope it is OK with a word file with changemarks to show the change proposals. (attached ) The new medium is proposed to be added straight into current use cases. /Gunnar On 2012-11-13 11:20, Gunnar Hellström wrote: > I am of course willing to contribute. > > Gunnar > > > On 2012-11-13 10:55, Harald Alvestrand wrote: >> On 11/13/2012 09:55 AM, Olle E. Johansson wrote: >>> >>> 12 nov 2012 kl. 13:15 skrev Harald Alvestrand >> >: >>> >>>> I would prefer this to be added as a separate specification, rather >>>> than done at this time. >>>> The reason being that this should be relatively easy to add on top >>>> of the data channel functionality, but will definitely take some >>>> time to specify, so should not be on the critical path for this >>>> round of specifications. >>> T.140 is a codec in the RTP flow and is implemented in Asterisk and >>> a couple of Video SIP phones. >>> I see no reason to move it to the data channel, that would limit >>> interoperability. >>> >>> Much easier - and faster - to implement in the RTP subsystem as it >>> is already covered by SDP offer/answer. >>> >> Anything is possible, if someone is willing to do it. >> >> Olle and Gunnar, can you undertake to write a complete specification >> for how to use T.140 with RTCWEB, including how it should fit in with >> the API specification, and whether or not it supports the needs that >> Gunnar has claimed for text services? >> >> I don't understand T.140 - so I can't do the work. Someone who wants >> it should. >> >> >> >> _______________________________________________ >> 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 --------------060706090209010903010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I have proposals for adding real-time text to the use cases document.
I hope it is OK with a word file with changemarks to show the change proposals. (attached )

The new medium is proposed to be added straight into current use cases.


/Gunnar


On 2012-11-13 11:20, Gunnar Hellström wrote:
I am of course willing to contribute.

Gunnar


On 2012-11-13 10:55, Harald Alvestrand wrote:
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:

12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alvestrand.no>:

I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a codec in the  RTP flow and is implemented in Asterisk and a couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit interoperability.

Much easier - and faster - to implement in the RTP subsystem as it is already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services?

I don't understand T.140 - so I can't do the work. Someone who wants it should.



_______________________________________________
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

--------------060706090209010903010606-- --------------070102030808040700000001 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-rtcweb-use-cases-and-requirements-09 plus rtt integrated.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="draft-ietf-rtcweb-use-cases-and-requirements-09 plus rtt int"; filename*1="egrated.docx" UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lE1Pg0AQhu8m/geyVwPbejDGlPag9ahN rPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX0QI8KmtS1k96LAIjbabMLGWv08f4 lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6MHSSW69FoFs/407IDzEDft3r 3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI+cJk31zirUNClZt3sFAO rwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4kNPWVmvNWAiJlrsuk OdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNMvv6CcVfouFXu RFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ou3dgqiq Yxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAekRq3 8wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Y y4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANa Xg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQCK5FEYdwEAAI4E AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKxU0WrCMBR9H+wfSt5t1G0qYhXmdPgwBq7i S2HE9KYNtklJrpv+/aLSqZu6PfSlkJvknJNz72lvsM4z7wOMlVoFpOHXiQeK61iqJCCzcFzr EM8iUzHLtIKAbMCSQf/2pjeFjKG7ZFNZWM+hKBuQFLHoUmp5Cjmzvi5AuR2hTc7QLU1CC8aX LAHarNdb1BxjkP4JpjeJA2Im8R3xwk3hmP/G1kJIDk+ar3JQeIaCWkB0L7MOk5kEMCBlxXc6 CT0voV2lBHTWwIF/t6S7b+OahuYFDbnkRlst0Oc6p3sHti9vn5pLLW4ysHOJ6UgI4Hhswc+t azoaF3ScafU/2rFjPpixF3mNvlUlvdAKQ7bIjtrxXbom4qFKEakbbpNJtTzYIGQGLkV02I1m 1kUzel4pxUxUTraN3l9zJVGb2j6aJo4mo3AcTcPhfPQYGcGbnfp9CfiiYxef0RrBKHZxyLfH K8vZJyzefkXtqFi6S0/+Iv0vAAAA//8DAFBLAwQUAAYACAAAACEA+RHm/QnVAAD2zwsAEQAA AHdvcmQvZG9jdW1lbnQueG1s7H1tU9tKtu73W3X/Q5c/3MmuCsQ2hBDOCVO8JDvMZGdzApnU zDA1JdsN1kGWvCUZwvk197fcX3af1ZLsbtktS7JsJNPMZAPGllrd6309a63//PPPkcMeuB/Y nvuh1dlttxh3+97Adu8+tL5ff9o5bLEgtNyB5Xgu/9B64kHrz8f/+3/95+PRwOtPRtwNGS7h BkeP4/6H1jAMx0dv3gT9IR9Zwe7I7vte4N2Gu31v9Ma7vbX7/M2j5w/edNudtvhp7Ht9HgS4 35nlPlhBK77caP5q3pi7uNet54+sMNj1/Ls3I8u/n4x3cPWxFdo927HDJ1y7fZBcxvvQmvju UbygnemC6CNH0YLib8kn/LmnWHDf6JPn8Q6IO77xuYM1eG4wtMezxyh7NTziMFnSQ9ZDPIyc 5H2P487+3P2mj5znDM596xFHMbvg3OUWbMYg+tDIifaBznd2qukrdtpZDxOfCF1iuoY8S1Dv maxkZNnu9DLltkbeXHDEKvT9q+9NxtPljO3Vrnbh3k+vRYxZYGXtA8F58qMFhS4wx7pXQ2vM W2zUP7q4cz3f6jlY0WNnnxFFto4hLHre4Im+j9njEYTN4NuHVrt9ePj2/P3bVvLSOb+1Jk5I fzloH5x0TsQnx5c+fTAYW31QJt7b45AAuD5EVfLLyST04jfEr1u3IQcni/eIn1NveUPXHNgP FwNc5MFyPrQO3h929vbf77fEn/zorv4nzw0DvMUK+jZO7Myb+Db32Vf+SHfnVhCeBLb1oXVt j3hAL7Nv3sgC1T0eDU/cYP4jfWy1fBVxN8cSTybWwV1awRtsEy0B3+MNELtQl2U9HgmxL04F RzH2ecD9B946ZhV90YOH0TZEm1CceHAERGmXRE/vunvv377fKD112weH+3udA5WgCp/0Vfjk cDyKoA3scyemz4Qw9SS4hLI2e4Q4CzrBNP2usPqeH7MJXdd2iUntQcLxk3Dogf1/nbiu5bPP 3HGC0PdGxJYDKwTFwv7o7nQ6O53D63b7qL131G7/Q5CHH5ONEFAS2cQr158f0esPOxwy6L6x F1hOwCCnmDUY2GQVMO+W+dxydkJIChbyn2GaxPEMGlKPl5GsTJKT6l+aRuok3IrztfhEJJ7H Cnd8vv7ty6VP2gHGU8gHEacoQr4apswmgm/XZz8+nrIfnn9PCkuo/dxS8WyXffacUY/7d2n6 2L6tIlN/XoVcuFDdLg93YDrehrl3Trzxapcp2wYC8z3v9qNPbB0+jcH5wRjS4Cq0/DCWpJJc yj7Yz9a95QaB5+a6xUdXEOB20jidkTvgA/INw0lwxC7ciO0g6SxnyZn9uss++vb93E5u51Z9 /Dm2YR4dsXPe58TYrPv+NSP9s2Sb4j9jq/ovY6sWi4N8u7TwXX+ZuJx130W7rTBtQVKLHZXn 0Dxbu9J5F6+O2nwJTSpElbJxFdtk2IkN93kVQ74t7//Ncu1gCC0lDP026SYcfWx1wrLkPfaN zEdyNNmZNxpNXLsv4k3se8B3+lYA/xNxOrzrjwkEDkXmAmV5BSlpK85nqTVw51sjjTHgV3qA CJLdhjs2D293/LD/yHs7k+TYdnBsO750bDvt97thykFYYMnQ2stZGc2RZ82gwuOTHvxLqz/n 0xWx2c2hHM0Lx0QGkvCKQ3J57XWt6L4e2gGbZi8GPOj7dg/SE0zJepCjA8lRR5pAkrRTlt19 wZL1VGwRIhrhkLPpjrwWv053FeEPjw24bz9gY2XZ9oI3Tnl0jTzX6CI9Y1DYSWSe+CDP9WN9 oZoqmVfXsFHoiQPv+d4jQr+vhelBBHFyeUFEMWC9J8FQ1njsxIZKwEJPWePLskiUR6/2+P+Y 8EDVPZrrV3b8ZGn2kRvxPYeN+MC2EAlAeHMk6AAhVovxn/0h0hqcUWYAed+AAqMPNoIGykYY GpCDUxnmaCaTHveelF1d9/ETp8esv5IqNDZPtTbPMfQH4nGUbAjJyvmNj1YSueZ8qj0fjTJl TNikqcg3zi+Y9EY25TKY7bLbieOQ0BWRVrePrCClm8CKCusbgVqJQBXKilBRahBl3YIVjKuc Jgy1JO2XymPfOoOzIZKbj0fxT9civdHjdwC9SKnRRZ9PLnlJEAk5Ob4wy7nz/SpOlVz6uCXp 9CjX2mnhB6torrU7y7Ve+tMwV3RhOeiFfGjoXyNRqmGaz3+//Pjty8XXv7LWre1wwM7enB3d 3HyHvRHc3ESp35ubBKOFl/79+8i1Q8/fQdICgDZ/cHNz8fH6081NlLG7uen1x++Ad6MDmN48 WpHwOZNdS+2Z5iACPrZ85JqVs5B8VzW89BmH5zs2QD3YkccMoUP2/unZJXt3mJNOkpS7Es0q cDvN4yH9o3uyTEtFc5hkT+Z8IM2CNkn43S0k/PdNIfz3OemkZoR/bAxlkdqoB0pDI4YYEtky +gApFR/aLoZyJNGt2L7m0zezjy60Lke4y32xsA1kYK+t4J598nyYpq9Is/6yy9hXLwTcaWiF zIOl6rM7QsEGbGQ9sShGaEPL271JaKxYkmsCJTeHWSkdFogpNyUxF16/stDQjEusYMohEZgn AEFcI3Tg4NDJR+1PfJ8qCKZMpyzUeDKVeDICRhUwe7OODBheOcxaOzJ7dbHnYhQ/BVApn3jP /V1KGYtaF5FBDt7EPPOmAeZagafJSSvGplOLFsriWV+WaJ2ql1gUkk0nuGmaBQ4YbFN7ECG2 YZz8tEeTEWmowP7JRshzDFXp+bL2L8WcC82HUolLeP15rl2ZaUJWZw9J6zEELB+8RmJ67Fh9 +glIfa8XeA6nWCtSl5GxKpkyITJbao7F0EAl5gnVQ6yHCI5hbV6EMHwQPEcaGmUZvo1zRxaa MtQzozORCgRUuOUwSPvqgsxBV3LQKMqAg2w56zlsjUMPvsZx923hhHKIdOGEwh91GbyTFvlH lFoBcdwBpB3stpTVFTx5ky3LCFzTXlaK4FK1OpJhyI5xAbZnACfNoe1N+K1G4bfjM2/85Nt3 w5ACRECHGLajGuSax0Znh/aq/0tUwkJhPnbtTxDPoRQOpCtDIgs1UlC6A4R27FsbBhVELf6y yhk3AwesUUIsHQqpzoJOLFRlb9edpI5SvhTMO4HMFWxMtpMoAR8YOVsjOaslSBUDHSFN/pv3 Q7KWUrS0CEBAOeoa5GH36xK3MwAEfXy3ZjE7DUsk2mum0P4UsC/8LuWvFPQIGq62LgmxK0BQ KCuj7kaoZ4eAEHt0Hjc/esmBsVfNEZWizU4dsFpxUiAkm5HzWXoDVQLcRUmcDXxjc3IbmY+R kzpqJiCPf6GICL+9JXMgLvOheCnC4coDvSxRqDy6xsAuFQMfT3pJgUyee1QWC08g4okHAWv+ 0kE/Hg5L/sFGIyt4bPgl+fNLFvN5zqXU2feRiSJUt5pY0FBX8ZM/RlmW8LyfUIoXVTmyJ3Qw S1w2snngtgF/0xeNCyNAOV5BPbpaTmR4vZIQeKr+rbKD1ti0ogQkYWDw95k3EL0DxmjlSW3t gK2momUEaG7RHAsMDz8weTsbQT8rhG9ooBIasN2+MxmowbB1E8KVPUIVpgjFnV6dsy+RqSW6 kJGESISDqDJRzlzv1dXA+0eT11qUH9w4rBVAYqJYZAcRCdrAWpcPXEVrZfs5j7pu9umuMUVn vTE1oqOUOZKO0WuuXdwQ0einKG8ggixMCjWQWUIQHUTJRb2wMEu8ScgeLd+33BDI4ZWs0eak ac1KcySUm2SXFEn8qAVigCc85akNS7pHvmYcKTlHzcYUYehSt9cwetLKLmqFN5+bT3Vv++el hRrDzr8U/ZQcc8/z7qntu5BwcSHiO7IEXGtErYjx0Z1utFOlm03n6URGNzpFy4P7U9GPWpTt bbjXaG4bTCo7zCrOm1otmmOUKi5bjKyeeLO1Jk/O+2qeY6UKyr7nAPsTt1P7JL4iopgkL7rw gnJwlGYvFNqM6zZiQylrizWPytVqyoTGoWmnFB5VyhZpKFUu+bAhui4lXo5TmJ+U3MCvKOXd oV55i7+ihpBovamcXiJZcoqLckp5bdv6olZfa5LO4ntdEfs6oSFxyG+zEGukDggEtDjioFoj L4pymy01mst3x9c0jYRKOc5QxrFqU1Rzivw5DN3c0pMsvul4GWl6g8bs2mTPCDQWqV20Eg1c yBKa2v3H9Fs0qKPYRq5kqmfqzeOOYqvpA9I1i1IudhuoIoWa5g0mIlzMdgv/r0HoPHQUqQ3F C0+1CcH5OgXlCxpozTUSFjMrfMicsqcG6qUTjTp7/mZccjYMfZJqr1/UWEDz9QvM3AcqvKAS jMLaBfqpQSRfl/5z01CoUTBkP0ZVfhqZqEQ6jYJpELfVpemdrGDQuKX2CmYv5xk3xYHB+EEb fTRfgoKpS18go2BQHKsOxtXWnxkFM45LMcU03pzCR6OtNxkgw6To+sQLmoTnq1PIIAkfRjZg ZmRvsdMNDwQdnON5ZiX8l2Z5MHWpyjIKxiiYDKgdmo4v5lYBs2iQiqklZHy3CWmY/V2TiJmq oyYFyQQ2sgaFv0bFGBXzElRMHfP8+7tNyMRglTlNiaaEyk6j6Yg7obcTT0ubDcycKpPFGIAm qZjaJfrhVhEl1RrX8rZGtG7yMOTIZB3Ip9NO591Bq3Tfq/jzCaoqGrx1uNc9756Ki8YSTQ2Y aAdvdYsm+99dd/eOugeVT96SczEQ33k9meW7uUZAmVhnzrNuiqIRcGvO/oaeix6ArvLM6qto /OpCddMkki+a7F8nyQs0WU4l86y0nqlkpJVtgs6NkiElQ9InbeYWqQpVNQTVr2Ff4+MLqeN5 JApS8m3hHVBdFtW/RYjf0iH7LLHzmn09uX7z6QeKQqxQWZQhByKH5EvZGk2Zbqma/p7j9e/V cnnN5Ssjh+/nlwu1zWJHZ0nCRhJSpXKU8eerMryKgmDWroUQ0SbaWebqLN/GNVpcBynqVqo0 pJUZLYT+mnHJsop2IGFZVfN8EjmkhdK4pIU6opTMqaEWijUQ+hmmmq0ZNZSoIPqeYtTqSMJy HO9xs2qIGo0WQUCnH14npeqghooC04waQscko4bQtX3DLUqycAORGkqjl6qTOTVUQ3eO17Mc RpMSVhx6soXFVhtRRCAvairm59F0lXlEOs9n8etNUkRFMZtGERlFVLMWAiR2yB9Kx0q3WhGh QpD7mIcYqI1ojTe0ESVkiQ7bm3WHCoXk5oNywyfM9XJs954w+m5/6Plxrz2BL0Pn6NDznz60 OlE2U2r8pjb6+pxcJkfnteN3ipIGbU4XIaLeW9MLLTOmnwG8nfPXFZe1Xu1PunWCuk+rOyD2 cwZQl+/mGgOopJ4yvVdpdZsIolZR5bE8ZY3pBf0+hrKm7eHqFHMfc2DRaZSpfcnWnR+ZF651 5ts6QeZF3h0AS9ILyzIeEktoInZrZNhDRXOBXZL804dWuy2tbBPMamw6sulyHoiGVDZZB9mt E2Jf1pRYV+0ZjzSlajY+L/NtSlOmyHtORcLhcJxSybz/8q5yXbyyYFnKUWkS59YJ+290paui ozSincutt42ubJiurFPpgawrm2Ckkq6sk6G6GV0ZDbkLhpZP02xjZdMgJbNXFPt/eN1uH7W7 a8H+CyUDHqy9Xfg+ZcMYh6zbPjjc3+sc7McY4GXwX1KNVUPQ0qcyZ7be+daolNVau9x/JHZo TrxCicbg2EjChf+MQn3K3q8/zrc4v7/41UwVJIFkNWZsdoSiWhT0Xu1qcXKqoOXbuMaYYFrY KSpIWpmJCW4SBd1p78YlM4xwQR7rK9VzMVJLSG9FeBjBvRHBbRNOYcdD7tlCglk5gXWL7z4w y+QiLBbXs1czBbcU6y8luOPPJ+mDqG5YumgsLNQMsrZueK9o+YrxHQDXyhTc82dRGvCgIRAT oFIaWjYrQLVXFKm/To6TA1SdtTYdK+LIleaX8JgiWJ2G9iU73izo4DPKQPkT+xVDUlGvyx+5 v1SxkYpLaVzFZpVEn0Z0ZTslFeu2olDkdXKaiIvRSA7av1ojFTrtnEds3JJNuSU5D6QOPFdX UF9nrf3ONqnd0r0idBJ4E+xZIEGzYe3228QJ7bHlh08LvfiZs6b+1CBOqx0Mb70GpNySZAUD sVbGoQkZNcx3qysQr7PWsTeb1G7pHhRGuzlHwdjqcxTXzKZ4SNrNc3cQlOTsjvy4RzscsgcP lcSpqHWk5Rqk3WoHnFuvAVmVdquTcWi0W8O0W12hczQHiETXesImm9Ru6dYWRrst0m7nqB31 7d4k5AP22ySw++zUcgdLo5PN0W77tUPsGe0mt83UBNJM3k0yQZul2/aLApTWmQuYZd3W6rZV ZFPuz/UFbIjWWlwnDxxoPISB7bBff7yhbthIfU0CuExWwJeMyG6QjqkdsmO9QYqKqL1TpwCE 8aAapmXqie3YyzuFYXn+fo1oWOiZrZsod80dPh567hMDaHFku+j0p+abFv/WIC1TP4xFE2wq o2WoH1StOo82iOfqibHYa8hIOawz51nXDEGh9WdSjzMX0Czf6uETH/CfuS5fWbOHM4DscynJ RHWmlqdzTjUxnU0CEvfrB9lYa2S9KpesTlFz45I1zCWrJ2Rjb7cJZiq5ZHWKhxSAG2qVZTQR r++5t9znbp/quYKnIOSjCDzRRx9cP27IjrDgVBM1SMvUDzphtAyRT2xOagwRk1xSkktZ/CaV Rms2M9uqq7b2fb8obGKdHe+T1JIZRVmM4arQLN/4HxPb5yNokGCqNxIvZfn35lD826LwhXVS fFRY1QR676TnCSiuqiTUNhF3MH5MdgdY6ThqoGPeFoUvrJPjpjomb1pp+V6uMa30NjupJK1t E2xXhZ75lbtofuHMfJPluiV5R4N0TFH4wjop3uiYljp99PFIIxSNF6N4MY3SMUXBC+vkuJmO yVm3K8lxDWmuVcdkppSktTVFxyQQOb+4T9MgHVMUvLBOijc6xugYzJ5ZPO378ShrbGqDOK4o dGGdHDfTMTlzMZIcfw4dk5mJkdbWFB1zcnnBSugX8mUaRPFFc/7rpPhIxzShNWons8Xehond xMoaxG9F8/3r5LdEw0AG0A4uq1+VyHrz+iVzmqC0sqZol4uTryfszHMDmu1thTZ+KhIxaxDF F833r5PihYbp5uwkKVHV5um9m9klUlraJgjeaJgG8Vsd8/05J/FJZL15jsucwietbBMMV0Ue 5or3J76NBnPltExzKP6gdvl+o2FMu4KjB8v5MBczLBsnW176mI0pq7Z18UHRfP8m2hW8y5vv X76Xa8zFYJVZklVaW1P0zAUQyd5g0icfpiCuLOdOaGyBjVJ80Xz/Oim+kBcjUZRmH9dI7dle jLS0TRC78WKy8/3ScWgoZaMcVzTfv06OSyJl7xpRRIpV5pSsm2C7KnyZJN+fcmUS3FjW95w7 UQeKL5rvXyfFRzomJ7plueRYp46pE7EbHdMoHVM0379OjpvpmJz5/mflundbV3n5g/fYyXjs 2H2RjkmHzbZExxTN96+T4o2OmYsPacwQg1tWcMtZNp0UqddsZrYXE39eHWB5uNc97562qCtQ bDLnHGB5UMd8PzKytIO1zvcf5jzjpngwJ4OBTREyFMagl+dO1MszS6eof8u5G3Wg+Prl+3N6 Mcslx7N5MdLSNkHwxotpEL/VMd/fBAxnnSCcVcTITvr3rvfo8MFdqRr/5lD8u/rl+3N67JIY 12jqdWqYOgH0jYZpEL8VzfavE8GZRMnyzip+VpbLnlUsLW0TRl0FOuZsiBIwzr54dwUT/ZEz 0yCSL5ruXyfJR2GynE3KJKJ6BhWT2QpTWtom6N2omAbxW9Fk/zr5bapimlAnkD0weMMsV4GK +cajxpeYdKNGwPL91iCSL5rtXyfJRyqmCSj9bp1g+gVVzOHh2/P3b0UWYXwpuk+Pr8InB3Nx I7Dw5+vfvlz6/NbzR1aI6YKtN5RwoLM59bl1f0p/4eK1SkYTmNU3Zu8P2gcnnZPaUA6I0ve8 248+tQgMn8aY/nznW6Or0PLDiGgFdS+08u58/hS9R02h0WugyPgz4fFnzxn1uH/3mvGQWc5u SrIvXMDCLv++wmM5b7+4PzP1Fqevjz/H6KQZsHPe57RI1n3/mnXbnW705+l//3kJ3mXdfylr T9iu53n3I8u/F7uGfbQHH1rvBCDFxaxszNPGZ3f2YhmQpCM/tNrtWIwkL53zW2vihPSX2pGJ TAZZx61xVeYztdoMrEo+09Sm5hw///3y47cvF1//ylotduOwZLO1edGc99U8x0pRvb7neMRn op7kk/iKiGKSvOh6Lo9eytpjXemJQpz5LTjNoypIhcejhMjBmVhtTOIRp4+FckuoeAFhX/r0 YoxySt73XNQOuRRHP+LHqABIQxugP7FIGEY3nYlGkh6R7TBtz6rsk0SoOsE39yhFMQoLMEHi toUF7eJHhEo5RlEJ910e7pz71m04FaizH75dn+0QYmvx118mLuQuBLJC3InkHSfEVILoNmrD zZ1U0dy65qTKEl3zN7BosvQZNvC5JFwmUeSWOSkxeVg0V1fRhm9LR7LDWuZeOnlLLaX4k8Ze WMk00pMs6ZAOlqnIfxg3suSXFhd7HarG/AzHxnds9365baV5uJQxlNca1lhqu+yriAzYD5wV DpPl3AjNg8wb4gs2MnkpskdKQyYP65d7MYExIp+YSTQkotB6HkOh1npOMqMzhYzGvySrNIvj lpduZHNcyinSeQDq0ne+X0WSLG1WHhbNvixQ0tPoTdphkXDGms2aOePkic+yL42otYSSUZ2M lJKRTrohSubCjQLQJdRMg0i+aPZlnSRfKPsiEZRGEq/RpMrOvkhL2wStGyVzMgmHnh/8iaG6 APHooETStEEsW6diTcOymyhd22iwTTWWyFJKbF4SNBRzLShwzOpNstpQDnlSBubQ6rYPDvf3 Ogf7UxeMNsbInME3KQ5gJKaRmEZiGokpoA5GYvpoDv9tQY7aSEwDiDTeiYHSwoA0QGDjlRsI ufGtjKVgSifinIuJKZiYgikZMvF7U2yGFI6xkE3eymQfTPbhyMTSTHFxgmA1FrKxkI2FXIGF XLt644VV4aYsPVUkGZWl7+UvSz8Uxa5SWXqMYsgqpJSSVLUjk7yFOBqA7Tw2nxyNpeGXIkh4 uSw9o/NXzvtqnmMloPCWlaWDxHOWpTeFsNVitpx9L56v8FraVgMDWgMMKOnEILcbORSV/5Fc n9bdRAC1bRDtKgcMMZVXRITmzf/Ho2DM+3+zXDsYoopRwE/asn30eKQRoZmqoMr7F+5oMjvP PE1NqlyqZqtW0jY9cXK9s0B8V3RPW3xFR1u0JcrxXIGwpFFz70mCE9dSiVIbuagpChhRPJhs mOS+fQ7qDY93GZMHtSplHy8K195YY1RTFQ7b/npoB2zg9Scj7oZMTMpxw4BZ7JY/StNGvFv2 iI4p1mzGVcDCoYXuWj5fhR62cEeV7QAitUC3s3ntMhMP4TH/yfsTtPbLcwP0TJqXCpmX1xTY 2i5ooed7jwFalVnoxIQJNAwdBZ2d0B5x1vdGo4mbjD3rW2OrZzsYVsODXWWZBcXEFpLFqRXw AcOY63DIZ4z1Wvw65b8B91E6G2CD/5igSxzxJP3iWDh2FnpmS4WA8h9463i+Sr46TsMRKVut 4eLKmEzmLyKPk8sLIpEB6z3Ni11wJL0n/sxKbNZsZ2kLhcQ1DlbD+/Khk9Zl5HoNWGsZocI7 cRxNGDNTIRx/cnNduzgXHLeEJjGmA3XqRO01X7tAG/Cg79u9zdsOKQpSeihJJf8at2/eQ076 BC3o7rhqI5MK+uPBD4sMtqoambxtRB+TK96n8YQMq8153jVs8WB0YYWBQ2Q0pGBIpprR+B3k mWbrQjKSJD144k61Clss7owPkuLO6gxme6mpQD2+i1sKGuJIPUedtUoFTUPXoFVyzpxbrqFX CsxmyoXjmVbJHD4nrdFoFfcuSUFwl+I/SfiIRF+JLiRb6mFNwy23iHtS4yPYLjqvaxbqgrdl W4rkMQpF2Q5NlKSU7xmE2PhRkOf6lWkVim4OrNBi/GdfDKtD3uPb4kAcAuX2g9V/eq0s0NCD sh0L6CEdjKjOAgnsO8xHR8fdu1xrmBLNwhVM/7qqFdvj4SPnSsBOhD4olyLcfh8TSvq7wo7t T3wf8V7nibleqDyEoStlOxbQVcYEmWwjo++5KH/k/roiI8e7ytILnmSzfdKarn4RmOW9aDWv glm6UQLNgFlkQ1ILU5gP1UkBgCrhCKXBLGgNTrw4/XxkHYtVrmmpmqjmSj5TT2A9qgezzEXu yuwJtjf2wTSPzqO0NL2Prp+wIvQt/Baa8ANGFA8oK94qqUeAWc489wGaFiFL1cB8UdJ5S327 e46UqecPAtb67fvVdet19J19/V38/O3jf32/+PbxnF6/+nzy5cv0h+gdq2jrLdxR7NHv37/E u0U/zfbx7Pfffvv49Tzayt9O/o6NJAeq9fvl9cXvX0++tJhIVNsrsdgWbqlCYVWasklUI88N KnNwKAAfeqzHcdqYuoVsJiFVLEDKkowjkUFqSTWO174vOjNnXb3dW7e2w4/evHlzdnRz8x2+ YnBz8+vEdS3/5uY8huvhpX//PnLt0PN3ghDcZ/mDm5uLj9efbm4w4+zHx9Obm15/3MkoAlmQ TyXFrFHfK1ku2Y7Y6dkl62SOgN9woHflFNbrJpF90bk5dSd7/7bf7XSQfCHRs8jkrw3hf/t0 xmipOWVkDXMcW6ik/5nzNDRyct4ZXkBuyUsr4lbe12UAT1Uaa8q6Nx5r3bT+OjXoMVpGoI9h UIBpgD/3UJYwIOwxzTSbAmbZF/7AneAGZZBNYP6a8X4BtXf8LxPcJGMpnm9Zi1YxSURFrtR7 L+YVqcHNLZoNXmV4KLc8LxMdy1FrNbVUNMCX2bizuMg7qdTLAHSsaamarVrJRVhXcHMOQFJm TyoIbiYDHMrcPgf1iOAmaqFtuIQvIbh5ctpuvxWei+jQFBlSqRel0nD1L5cEIY5fovNYvxQH c8PmE1HuUuOoup2jdvsfUXxcdaa10xnfl5o03+2KG0lUKi1dlH1bYnjYh1YUkWCfUWIAxIY3 auEBAaEArp0GqO90Ojsd4Snql06Pk3BW9D2Nncar8dlIqygF1o5XIZ5Lejh1L+UFZU2C/jat gQv5z/Ao7TDkvb5FMo8eXPwXT0gflB60FH5QPkDVzZAIfqEnSafo3kU05n/yqPzs8cgK+rb9 ofU37g8s16IzHp4gbT57JV9OKvgffDIazxDnVoMh5X3ES32HWz5dWtRnf2iBwjz6FWEw50Pr k/iKlqUel5b0O+1S48O7e2naV+2LVTYo5zYV35RsBqJ51kSjLPQtNxjZIYVoH4eILzI7ZCj/ 7XHAZliIkdUoUPRZH9ArvGXOuJ8jzk67VLRU3mKJTarb52WV/uskxOQokNz0p5ytOlXb9qCh JMPMk1oQV6sIiXoQ78s8UzDvAiEnLMzCFo9kQ0GNzRuosuQrpmi1HUzWKdfwCJd+ZJrhcciI 7bRLRR5l6U+QdFy4qsdfh+KMqpD69tim/hh9i5DiFmrxUZwUAM3C/T8hEEnKFTnPSJs++qRh 3dfs0caE3UnIHi24Y+6dqk/x2EvJ4kqezkGtN/gO8IoP3Id23gnGVp+XMtT09FN8A9NjCDPM sVJTs2VLNqaWBuxKYgRE39MODdlj/+//Kg5DInjwfUwsUUfQ4cwp6bSL+q/vrsH23Xc6/5XI WNqz2N2TMWCq0S+/P8tHU/YYnil3prKrqGMsP4EQWjH3nnPo+3b7cK973j1tSUI9a8VYyDVk xvH16TktMflV7IHYCbwivi8ghuhGieyQwhvSEjYZy+i0y0UE2sWIQaa+os7/3NnlPCZ916Sr qDxlXV5/p13O7Y8CRDJ5ihGA805/FnGmTL+E0lLhsjh6kPdCiYCTYxudTlEPvfRBHs+iNamO RXM9deYNwE5RLzda5vtZICEvvR27oYXgLZxxUWz2mvHdu132gAIFD+i6ycD2yD+HARJ3XyLD Q5FxyTbj+7zoUOOf8uxciUA2Kjo65UzrQqKjzluh5x5adYmCzZqWXOQ0Z2q6+kU51U5HOD9q UjVO7+R82lrDZtQY1Qttf5qBm5Qk+ga2qpZJ1TmwZpk9gZyLLQlNPnlpxQhxogisy+5ClWci sqpA4O700cFPRbPPKlhkvEWHALePR5Fs+Pev3qnVv4+WmEiSWb0LvTdyfub1dSwOEwNMNvXr OZ8reTx1M4SvmBKUu3E75S0UlXvP3Cl6pfvD+A19ck2L4k/2caJauJ1eMKy0WI3EqKew3C3Q LVq/K1WIy7dLxaX+/nlBKKZdNLnLtbbw9L5HVkRNtIuOQWfTGh9gBNDPoCca3M6cU9XRRp+V SIGalhkb6vl4CzyOEhyAS+l73u1HnzIPlO3/0Kq0KxcgBf2h2kiHysOinsbzcIItMHi2wXwp Kwc4u/Ucx3ukaFXSRcMSsEPRzSTuFN8DyAQ4fXRmEdB9YUKrUdOF8Rm96buFMjUPkwqTel5x Zx7escfYmUN5y7TXsl45QElSFISiqdbF5cP+juc6T8ojmhNXtkMjlht74gfmxJGZ31Rn52fn 8cEE2YggRIxDoWrD5Mp2bBWTPyIh1aNmD6867YBhNMyyR023fZNDddkq7LeevVx7icsXb2lw /AaOzC/K2g3VKtuxVVSL1gkYYzOjW5ilwIgL+v0rUZmhhpekth4s37bgneyITPvOH9BidojW i2jY6Pn3AXv1iPk7Dg+ClQRETTOaOf1Ws/oKW+IXVC1m759v72sXY1jor2scRDX1mXd072fP GfW4fwfIEaDMThqrvHABCy2uUrfXZJvi0eMff44hiwN2zvucFsm6718zqi9cOJp8P/9o8k4n PZs8zo3klI+1o5O8drUmczbftkTK3GXZ6YXThmPrju8gMUzW5vTDEQZY3DLnfTXPsVIGUEHH y3WHRefDaog6ZWCveGQ54BFmODkA9aEZTh6xVwIqTL4Tp+UUd802SRorrHVYDLY07FK6K/qz BxWRULrjAdUpJw6ZIjYL2tLm6PNqmfD5c0a3sPUekS+Uzl5U0mEqAvt+fkmpRO8x1a7f0IPC HtsVtksiMlROiRbDT6JRAXvV3B6znU6piqm2VFF86U8r5uarC6cGtcYClZpIVdRkFi379t8d 4ql09nyCYSVUlNTHdR32e5afEh6jcSCtNMUu01Lc1PoWtkj5DOSMj0EzMaY3636a50sZ7fmF 80qxyC3UguucAe7dpogkfwwkiyR01tzXk2s16FJQp9XUOF8MCRcFnGlI+PbOW1kJT6uRIZmx GjUIN1zp/gW0SYvdOKyVtCTcz5pdLAV4qlysZrNWCgj1RHVJ9RNXsD8pCSMrgty7AjmxcgXN 4TyyLPf980LCT5F8RRv7ndDb6UU/EiJwQVHNNgs+UdY9J/i2uBpm/5mrYVa6/yqir1w9zErL bZjwK1IRo9+XKsTf+6XiT3//vOLvyh6hfw/7G9XyszNvNJq41LkcbVrZFfcf7D5PKQMQH7wm 0WipW65PgtSAQPa/pD4hC/2b4WoPq3E6lafDoeHxyAaQn7JUm4W9qBmAsCc2+JTHIhoxK3Yp 1okhNtaT9Ta0srMrujcs0GZbrM/ePrM+W+n+q+mzchptpQU3TqMV0Wn6nalAp4E3lxXF6++f V6edixlfY1JiafFuirsg3EVj48/Xv3259DmGl4ws6rwbnQsBIE6hPu5P6S8VQp3gDUq+dZlI FGPXj6LP0AgLIx/ND9jQeuDM8awBsjJW1JAIRV+yEUMVoHHN16r0sIWBSoU9qkzPYOqe2sFK c/GFWK0y1IHGl7bPYg8+eM0QFaX+VAPWQ2KGmmJaI+qMKSza5I++GA2p7EFBJ9+QRG6uPna8 u7tUfnTdREFUGLdEjQ4enVBjwgh2IU9AF8nEezg6bDzpOXYwTDVTMSShcIjmzDSoz0xWPrbd SP2kFbXmHpUJC6tH/W9JhUB53GFuF+rEwgkazj+BBoIhlQ5PxjQvQgzzIvEBMlF2wRCFsh2a AytFFDptrblHZUQhxgLzqQqBfPgx5C7KhalkGHnVyOaADnF4H+MnLDbm3Fd2wRCFsh2aAytF FNEJ5Ll8ZfRA4gEGAsOsmIWWJZpuBRQm6wEIwkEoJCYS+0NZ6GKy0PbL3ahNIce5irZNF+1E 97TDf8ihwKOLWB5tQdwme2UvQNnbSmlss5l1ohcUdQkxgh7t+D+NxxITTtIISvmUirYrj04p dzQyW2F/U1q8irbzlhPEc7b7zgQG9xxaAIsXhFDI9Z61rV5/41f9I8/IVj6BUk3GYz4R1L8q CygcgDWKHQanJXHbVI+nOJquf0x9YyWykG33wUZ8IDKXRvbdEIU4/T4fh+j5m15JkTPeqJzT P/zsjHO7MppUwhqBzz7/bxgdym5rJF9l6o/EU6zi5li6yDHXFACUs7ZgC4n0fOKTg5OYL4Cz o94Ybu+IBolYZN/e7jzY/JFU0sAOxo71xAciUgI7GF4yCEMhRGIgkmgvd0eV7dDwZSmrNz6j PNevjO+HADD3yJ6dEgZkPwkD0e4d5AEqoRZu4jWfjzxMuSZPCOSirNOQhbIdVZLFlCvz3KEy woB/bA0GYoIrtU6L9EMsK+Asx2JFUhuo2bX6Q2WNhiiU7aiSKMhdzXPxyuiB2qlFwRAiB5IE yMVQ9x2f78AixTQolUZoEpV3iwlU+EFZqCEKZTuqJIoBD1C2NMhz/eJ0cQyu/wgOjzwDIgfh C/aHForkorO3/wchVDRiGtrBmyF0BPm7Qo8oKypHALG3I+YlS9iheviLNfYlYu2h8qCG6IoT hcY3GkRGp6QdQDwKEaiYq1JjsGQfW/aFJeoo7wufxPP0YBXDBOLgKkoXcBR/ga5FKiEOIKvg K2o6ar1WHxX0HrvsclihaPFVFNiRiq9WeORjOhgwrm/18WgIbiPD7mLwsfPE7JHoRBRy/DxG uwt6eBiEkQHgiacfW374NOckLnjEUgOy1nqquoPJzb/HCyTg2AI9kKU8IEcrVbBjhB0NiNxU G0pBuyk5s96CqVdiHtbrSM2lGF+VcUVnqUUML80BX4XhU1IK47uohBXYmZ7tRvBfqG1wt9qq eya5MAkQtxcw4L1SMOC9+Qc5X2VmIZ6gB3FEZ421iTGG9DMYOXqlUOT1+BdhyY4mcG5tF7tC jDxPS7hykdCHCYXVDFB2IcbMI48HpWZbDujdipwWFUMG09b1QuodTc33QiSoUyZ1QTrYwqDi P1MydpgUIzNfCAn/YiDSJqHnOaE9/tD6P39MvPA/Lj5ef2KXnmP3n6gv9494e8Ft0d9pXhF8 h9DznzDYuZXmYbUYrEABtCi47h621VlROMbputO30icQqInPv+asHyMXcHSNBZrCGiaTPjKE p1DCFI0vtCNKxXkf7TyXnjpjsu4tV5xSse6tSuumM1ySe7RXdCRnpdbSXBQzdm5yuwkat3jE LZRTCbUj+scIi4ucq1fh0Pcmd2gsolCGUTTKdmiiFqV4MKnFznODKSfmPv/j1yz0J6JzVMq2 QLTM5c4v7IH79i1hlWMTZGVrcwutjDxnU+rwPd8GDHSzIbFpEi0KoogQEoXPKQEXmZsIlY8s 1x5PHIEKUp6+oCQwrkfNXI/r2MT4E7KtUdsBlNXaGEcUQT3EZCLV84xEQ5KeXYUYjGTIL7f7 CJQg4Klst0btlNIKtkvIHkRUEb+gDCuCMI/WExt5A/vWjmLM9Bo5qNQGHm5ookd6T8qiCgoE QwP5aQBhMGWrKzt/jVUIz4MK75NSFd84lwJfFAGIx1fhExoWNNu5lGoc2J39QHUmU5eTfvLG Y88P0YoBPA9vAAGQMUPt0tzoRMP0eRizlEnIf469AIGoPDcoLvk1nE9nf4FeooMBMm3T4iOZ WqKoPJvZjEY4bJNwOIGuT5CZlFa1+/bYAuKO0BUczgERSPJ3OIpkGoT2iBsi2CYiuMYhE1Im CkGOYA4i9TAhYZQqbh9wshMEwgbm4i1ACSCVkXXPAzPNeEPTjKnfzkZVxOygPfR7RaqWsNxP iCyNEK2GhJh6kyK+MHv3A8SH5wdGUmyTpPg9qUqlsABUxMTFcDAxP4xh1D330aWehiC7cDFR qgjIFTKegTfipDMC1D5DlSjEW9CebHZUyay+wphYQcqpXfihSDJPTTu/vFFWbwuMstoTVcVR MzYxXUmM/UEEBR68H9iDb1SsGHNi8pLUd652dJI3aqRpEZbZHjkLY4DsROgTqknjOUrN86N2 x/FmC4Dj9MPHJO2jRyA1mAMNq3mOJFuWFHmLq0mXVFkkhczYtlFWoPGo1n0p6OPSlzr5Pze5 4/SjIQ1YSATkK1pbfnjdRmG5BEGOQnR6OibqS+4a0WIy7ynuDpDsibJRWrqaid7pVafPUrRK W/MsKiHPblj0GZ911Jeym8kWS1J2o5bQ/FEVBftrjqrokZDJkpAfkViWSqr5DhatHXiGHZTI rX5KPeEJ5ZhlsZMIral4KVrKUNGO61s1zJXTFLFo9axDcguA/Xu+fNw9jXUrHgkHMobCFjOv 9M6DazrwHl0KdqE3dYjKExO1EAIqUpKNz4BNoxaopXI8dBunPDdH2zVq4vk1mqvFTuIcyLUP iBwAMMiPv8Iwml8MKWwTKVCoW27BOPKQ80SYUiQ6/phYDmVA45xXkhZ/dev1Jwh6uyx+wyoh rPrpIkntZIpljSO4Rj2QqmRbNwxCFFIJ5SBKhn8RNIEo9k6UF0GCFpBJjpYk2ygSFg6o2tPN acFII9FWO8uErbUBJhG96nENV2oHroleZEZhqrz/NPCiYda5qI00pGq3U25Q1To2bKVwT0+Q 5loGVdEeKdI/iW7F4QQFK5RBSlFcgohQQzEQO3KoK+FOmLtTj2D5tJaVTiakdgvnkHgPsJa+ 8T8mqJWilk0vOIGzUd0NVk6Oer9cwWs090Ywg16xJ0EJlZD1789yCD91XrNPXfzbw799/HuL fwf4d4h/7/Gv08Z/uuI/9Kcuvb5HP+3Ru/YOU6wlb0G5uiPN6J9Pp5g9e9CSlECJB07VWmMj sV4RZJwPy8Y3TNx+STVKS6lHJxF508vVQEmbvtoOY6zppz2im30imX2irn1V/GZuuj7Ls9H4 o560Et6j77RT22BN6Z82S3Kc4GxPIDlOIDlOIDlOIBROIBNO3uEfpMQJqOCEpMdJh97Zobd2 6T3dgwyZUa7B8OFRu/2PSDYk/EpJFIlREVGm48p8VISZTrrqfOXtItbEJBFg16mmEhmd+VFY 2+surDQkTmP8FXEXVro/ZH2xJK/sLkA5EO9NryFU31yuN+XdrLRczXbV1llQdZVqYeXeF2xx LG80j7/cVdjfj7z16HAWuiornYtwFZYPdnzNEE998+kH4iqAEvcQib0P2PfzS0WCF9SFNdXk i4WjSBEvEI5mTmBcXdNOfN6IRjUEX0Q8ruQCT0VbmWhK18wJRF9GGAaiKQd31aMNjzH2G//r KMyfKSL1R1mFiHy7VETq72/mBL5s7+UaLYOoeEIMcac25pYz8gL0ehpQGW2fGj1F7Qv1OlJh g4I6cKNhKb3TQ6uObYuV3X5lOzR5n1JVdldxqev0tF6lbqUMtXjX3Xv/9r3wBXPrItlnjD+f vKRDe6h7uvP9KpZFaRDIfgXApQg4OMVERUZ7dGz51d2Nw1qyK4DgHG3j9AKSK5A8u4RDJOrQ bOdKpry6jWl9cxXVJDDSO3NaR7PK2PBWbfUUuDTrrpqnTFnsslmedbXwOAVG0DAGkgTzyizz whr7RgwsTCp6UB8OySZMdzGiTHRrVJjHiC1lOzSnU0psiQx0nqtXdvY46xlE5uQ67bOhK4R1 e2v3d5VFFaSARjlvAvK4yHnb3tjWShavRvY1xXkrFd1ax4atpBJ7a0yFw31TmP8Znbd38/pO 1dkZqfj8zptJhfNba+KEZMpt1OeAXQkDTZSM7BfFQYu2jPvROMK6p8K771MMJT94qe7d8YML f0y2cQsns5SFRaa+MPLn85ZLU93xOsQcDWkd689+S7v5thSioigZyTcshV+Qj29ln3qVVPrS Q6XVrf8E9U4MWZ7kxW6HBWqAALmBAIpgEiGIRFW8LYde2V+c/i840+Vlpv/fSsXXcnxI1KuC Q2UVpEfnbNS2WC5SMu3alfKmFbhIK90f+ql8+h9HTbw3vYYU85NUVcoMX2m5mu2qrYO0l5JN cpwv975gi1dN/4MrheVb6v553SN9aoPFMXeg9+LUv+ditpPoPx6wYRiOlX3aDg2+EADwVoOO 2jMAgC0EANCplhCRLyqGhD1SmD9T1+p3pgohuRwjpb9/XiF5zoO+b4+pN5by2Nsh87bBvNOb g1nwZQMASHxvAwBYBCBI/J5VAQBvK2gyYwAABgAwh8YzAADhs0qOazlFoGj17QEA6By3bUYB vFxr5qsX8iP2g0D6Vs+bhOzH1Z8ZO/MmzoCGAqA3tIVps1YPUxF66NSz493eYlYpjWG3g9Gf FRbYDsN2sTMvwHjzgJA90xthK515AwhZhuYH5SvM/4zOfNz0NSPiWYUzbwAhzw8IeVu0FWGT ACF7agGxmt5cBQkjDN3EKy1V3axwOtQ88kCa7PtS7EC8jucFhKwCr8mNK5IAIQerIFCqcVYM IAQailqCS+04agpJfrnOSOHOEIpgUiTmwcoYrJUk5kvsB3EgMDjzTlKcbNkGss6dyc+RJNIg HIpg5ldCWEzBHJp4YGb7OCS3ifem1zCAEOxGjN2Iyp33U7Ipwz3RH+PsohpqSVWXJcELVAZB fAkQNbiyHoCQO8froTo2abSKDtLUedNXtgnPOw8y1oPHmq3Azeqfb0SQ2Xuz9wZFTq7lMzd8 LzJIQLW+8oxLoQEDnz1n1OP+3WuGeXWWs6soHE3abmFlbanba4wrdDukr48/x+i0GqD1ap/T IlkXve+67U43+vP0v/+8tO44OygwGutAQmeLaU1x2dw2WOFZ6VqNnZRpVWddb2rhag5yzkqO NzuPeZx1X81zrIR/3rbRWKDxCOBSxGZsUMFBXgmXTOPcOUedfjgVGrMfvl2f7fzgvdkLyk9/ mWDQJwkdRTIaU/wJOe84u/n5+rcvlz6/9fyRFWKiSORSEauf+ty6P6W/rMGgStw5pe3mgQZY vm+A5VuYi6ZTzaNLVONktRL4deienghCrKdPP/ZIEV3Pl4sGby4LtlSRizbA8s32JNAbaqQl q4JBG2C5AZZTwHcuX19xZ7kDAyxXRrcU6PEWHr+4znIvyg+otXOo10JZ5UoC2kttSgcDzPZJ uvqFGI2XzsTQHz2MPbNCG+g/7wHhKMfy77hiWxUkhy3cUGU7NPHDUn3/7riHKafjITWRzXOT hUHKMkRiwYcN2CsMweQP3GVRos55SjWgLHjyzc6wbCHdngTBZEScLdp6Xpx9ZI+24xDCHw0n B6/xMvh/xDEQNXrHIhGhkGVBgtjCLVW2o0pR8Ej1F3muXpkMcOx7Tp2rqeCDij3wY5yhh56A KkDm/ur6+1cxMfP6+7evQntwzFJ9heoQZaWGLJTtqJIswJJ5rl0ZUVjjMQajRu3Me773CIvh P3DwTtxdGaNzH6GthpiWy18F4p0QJWRGjC0/xGRdZbGGLpTtaDJdkPKAdOjzIIBCwejI30GZ PiMzwoP6QDCcPVrohk/KZk6OKLtgiGKxVLXdvjMZwEafjMceeIm29OLyYV/IX/yAcWmOZ6kq wuylQlpVMhiAa5bbBz3nuUN14hcoPp8PJu4AN39SgQsFD7um1vjiBJem2BLN/OO8mwzNjp8s eUmC99fa4NxAviYT81Dl/QtjJOR2gXSqJsGVJJrnmjWI0UnYo5TgyUAT6xNMkBmrtpc7MMWW hKwWY6667YPD/b3ONOcX5YH0ARgS2UmGQyDvEplFNXk1EWNgZawqAo6XK7bsiJaqIgu6fCuS bMeyrcsKcJYbRJ3OGMsPXq7YMnrwueSN1PU6Zj79thBc8bXC6aAZrKzJxZYH5YotC5KRdHzv yhVbSscnznAFkjS1luBrU2t5tDZ8WBVis3CtJc24TpshMtuVK7iU2E5Wh4Wl5kssuHynKbiM x1tuA9Q75aboK+W2veASmA0yDMBwURdvU3A582aigsu3iuGkisjcZDS7qAYEyaN5e/Q+MhOS AAZiPondDK5chgFciYxzD+DGPFLuj30bIXkrGCNmHyg7hEcogptvUgTpnVT8Isca3hqI9BZC pOlUSwhHfZykvC5ZqTxnnRBp7JHC/JniUb8zVYjH5QMK9PfPcTJCPJre25se26YPapCeiZxp OWipf39WrOf/s/etvW0j2bZ/hdCHOwkQpyXZ8esgBpyHOznT3eNJPB3MtAcHlFSyOKFIDUnZ cf/6u3YVKbMoFlV8SKbpCpBOR3L4qNq1n2uvvQaRDp25A5BaUqTePJhCOgUlTWCrCwrVFlRa jiYrZsnMbZ0bNFYwe0rzvY94G5e9jGZ+8Lb389LzIMafmOvCwffnPXiTEztib3vUmLc3GOwN jq/6mGw4fJhYdRnAzxQa+T34WG9Y8jdyTFeBwsa+VTPf23W878JnLzpEegGBto7LzvcuqYta 6o53IedQJASR4jhZgkJZR9tVwgY7cuym0NSNKdIVWDwOHIHzAjB4SWgfgEMfoOOOZz1EmSGA QEAGSWtQUqqNhdXXH7sWCYIPUweBxyVgugw45mvyMOUGgD8BIk5s/+s6omAUXIMN5XK4V03B nafPuoCIY6PRWGKBXuDbx3fghweO3LoDzwBwoy66GGj0ESHX6oiB0Qj6GmHsz+dLL154adG3 bS+gBTiPDdCe9nKCuQEY+CeLRVokIDVhzalYRiz0xQKnVAaKblsapghgYCdQAUYfAbwFyOXC 9u4RpN/ZwQQaA//PfiA57aGrYMFYAMfhatV6IAmu8R+k5VDsXCWXMvJ1Lt2YSzmhNgLefsju rQlbuD7GglqpVhJhUhD9wvmkBhQIDgaSAPsa3EsPakRCWo4mRWLEojvGPJ3rNyYXtM8OVapI GXh4AD/4zlHu9EWiJYwnSTmdOI36yIx92oZHGSpfYWen8BfuyEsQTYiuP8au469ErzRfROhB 9KkvUTSd3TnRDDKxEgdJQI0+kJajSX0Atw5NPNyP17lHYzph6blwEckE3Fs3sBuiA+0h0yCc TEpGpOxHLR3RQX/ys2eNEZEBz4veLKjSOZlcRgEb/iZSOXHglvLN0boneJkn1gj2WTYF5qTp nIJKzlhi6HRu0NgxWyOA4AcOR57UMvr36ODN7Fvhi8Evm06dMX0WRrZxyXoLELey4Jb1zsCm qLNvlQRDhFE6l29MLCAFTpDvkyH5B+/c4Ykdz494DyL31GO3PdshZzRGykARxcIytmqrAIi3 f3I5Csj/8e+SFLvQzdLGm9WUlqNJT2fsOnAvdC7f3DHzEQYj7gEnByIgeLyxFIBm1GU/HKhd HDXoGJDyiJR7EiVJT2lkQlqOJmWC8lc6Fy8vEWeU8CJdwDyQbdCJT3tqlBETXtrIR9yT2X1r 7bGMCOjsUiXru+Mc2dj3POB0ERMDFYJZvLDEydRly2X2bWIbEk2Q5Euo8BpZ82UoazAjGFsT jNGWNIMiZ7LpPQDvdt1KEr7wUYsZgdJF6xblVZ3ihRBFQNinzs0SwSiJeUwvE3IyqqTInIr4 6UhIj2iEW1qOJg1fnIXVuX5jAkENCg7Fl7l8KNxeongQQi1iMPmIWUJuOVGV9JwlxeJpowzM 0zeIkSgpOa3LGJpJOvqTdI5KTNI54nTJYqwlH+5yLLCiXYc6KvCuhawyRcgifURyr2ddu1Yv Xmyd1p6i+yreo1arTtcm6UDGBZZ8Y0fgJcDq/X6GkfyxSJdAqCGQ76veS04dVQ9UT5VWtTzB SqzuekaeByf1INsR97gkXezSQtE1+Q/iD4l7/GHEz+qqq3cpy7+S0yDA76u4Ydl3JHKSR5s0 JK1mssQpsdupJ7S+VWUZYxRbVXZLErGjPzlAIFmZHEahlq9gWZaYR1jBlLi1zvkD4aagXJG2 Oa12sqryuCxNTkMrXtTeJ0VyTUa09njmgMVY5/qNRbSon2+6X/W0DUycnyRQtPAZ/FaNvduc IUE5oYaPK+RuYhjBdOmNqTJou050z3E90vvrKKlWH7HUaVIr6kcRb4/tGOGL9N0SMAHnT8Jo okaR4PYUWRwEZv4yAF0wAfuMUEjIgdx8l0DhEEgeHRVQJJQhzTRW1II77dRdUh+WrP+SsKnw THbiBx9zYikRf8tkHoYOVhBR9uPgLY4wFAFvYeAuRyX1xgeWDvSzu6oT8Tf5wIoFq5UhGHEO oO3MO3zTGjpYnM1NXEdNkHkEQENMrC/sv0ughueoCsndsCU9i5YqvzbmE3GUV2qYk82VSK0c XQ33Tw9K8njWB5dXo4MtIDY85mRSFV+c+4xJbEZReWliw6y7hC3heaf1gD++dHK3lC8tf3OZ eY7ttxWkxags7UUlMUrfsOy0w/QN+fbV9vsNH2ycnEiJpFHCDZYusby1hbQ0H6ykmDjhzMpU lM3Crx25RIdlNFXs4KoDCspRE0/tkfRw8A/UWjMWxOSO7RfR/CCJFwvWg6SYrr+NvoV6F5Ow UBbrjMdfi0NT4fGXCZFq3R/iKGhcFfCoT/+8/Pjll8+//dWKa6HpEAmni8R7dQ1Rhsqaqh0s V2sDpEPp+FcUIyxxcUDNNlLBHh9tDI9qiZE2Faw9RvIttMacJkxaHDprJDqaGqKlZjtfJ/Kq XI5ONCywHWSBPTQssOAAhBvDZ9PkzxHCGkmHv1AzqhM3TWjGGESV9lszFkt9f8MCW0Jjt69U XTtUWWOBtd25H0YW+nUwdBLTs5OOcTUdrHQMStrADq7oVzSyOmM+CXqPWpGsp8SketwAdsQw qb4erhuHJCimMDyG/KUOr6yvP90vWPBYTKqEQpg40ymIDjyIMacZskX/FEhEDAHdjprVRXwh F2cUMJ7GoCgJ9CAOcSbLIOmSi2nmTuvo+pbGO5rRWgctFZ10iedwI8jqJrDnlVrjJiyxiRyD ASyGYDjlZhIdukSNIcnWtkU9BIQtsF3pnsZ3kZZDsQWV9v8x2uDsib0AJ0BovfgIzE+AR3i1 UcCrowi/ORfOpuWrCBxEGv49elKXGM7wMoYJSsdWuq0RYmk5mhRiocR0Lt+YRYb3JYxxYoiT roGYdepBskdxjzv5aFCnRPomPamRC2k5mpSLMLIDmS1AcfXGxMIGlYGzsNYdtDz1AGoUMr7S 6xtpkJZDsV+VTB3ByefAkSN34srUXoq7NCYVcchAGRuie9z0hq20dYoiHp+ZQMjdROGB5WWE jnXoR6DYfEDapLc14i0th0Lwqol3BnWuuHZjQo1N9yzaYbJo1jj2g2KrmCQnV1aRywl+mswl sb74U2khjFxIy5Gzd1mlUKYTXo1CICzJFh1khdIYQ2oC+4bJ8P6cl6awtjGB5W08cb6EiFnA +rqE8CLeJOoxf3kz4y0IcY5FdP9Iu2KEVFoOxX5VUl5bTaqdyXJWchtbmh3LRQOc8H7HPDSA aSPpXhvJ4WvA1elIlkNJ1ao5K0Bl7UVJtaaNBGfTtJHEyI1h//D4YH9weBAviaCVULsppLLp ZzRU9wfmpgC1SXEvhXjdab1gwsAyfepM3vYGJ7zFr3SLhZiFySVn8/rIWBf1zxc18JbuLTl8 ZV0MjzOuAVTS6sXrNNXwUmyyi6mNTZVoC1/z7JX0YEJZKgRJ7iD5kpIZ+ZtH7S05qdapU1KM 0ttXrZklNcNVd68U0YJl1ekt2Qh9j4XrcTe1Wv9OqU3N1Z2yYLdJ5NWnuoQxSL/QTvX+5qdv QlU32M5yUq2dJXXKaynp59jOcqJoZ4nx9F2AP8joqVmtPgBF5PE02lmw1eUDtW0sV2sDNbmb TdaO2mIE01C3nQWnclOYVmtfFMO1UR9UA3mtGLpaDyahvYpa0PO/+18lzzonG5hGVeR6Hxt9 M/Ict9+5vdlYJ0+fn3RTtOAcmRacDrbg0K5W0OXPKumGNcrohkotME1oc9OCs8VcW8fDK9OC k+RcY9rf2omcjFZoroa9cpCkJmBC2zy9Vp+Ttrb6FPTkp4P/VBONImarFYSovTUCM3zFaCEw CloHaPVZ65BXPGUcMsj+8aO2+uick2ZxEYRL86fW35ec2FS6f+L8diEhUSg8yvyztBw5gU7l 7osMCkpx6cZ2OtaSa42Pa3o4CzZKu2+FS3hWMiyU4/ziS78EtHBhj8DIGjnA7RACezJhE9P6 1JYoucRmKo8atT5xpDymsBKsFDSyt46/5COz+ABBfIqmR47shgAIuDVEYcRmjjexbOmoGs0l LYdCvVQDbPnzue/pXL4x7QWCZdH8jt73ABhStFMIWVguFn6A2aKLwPEDKIc/OVk472MT85xr 4b86WDfC1PRkwjHN6xUn7i+rsegBLV0W0EudK5u2u41mQ6FpQiE00hsZdSEtR5Pqgs+AzfQC KK7flL6IO26EMYGpoK4EANUj+zsNHb7F6HcgkLmSwAHY9OJPT7I5Z730Wka8peVQiF8la0jd DToXb0q2U72Htw6cIEhwjnXEHAKL910sQ2q7SDR6LWvYUjS0Zmxqnr5BQtaS+sSs/eOtfet8 2LWMQ0EKRc7LPQyTK84WfPLd+YgFN68sFlm2Kys9he7PVc+Vbq/wOi3x6+OPBTj+Q+sDGzN6 SGt48soa9gfD+Pvkjz8uyUU51p/jOeynGkD4aMkTgWbQ1I+tkxPdxJMi0VwIDiqSn1VHhWIj 17hr48XWqQwX3VfxHrUS5h2b40kyLpjMynC6tlqyK6mYx5tTmQLGG6O+BaOehzKCdeihfLXe 2neEJjAOWOuCipcPQr0JTQpVWmgSmrx/aROSpj+nXdWxJU0+sGLBatmeERfN7UyIwhplYu60 t6C9MghjamJG6WxuwozWwn9xCvQPzEyIYlN76UbUBrZTe/7QDTXsV2tmK9Wp00QdrUwX3wE1 8L2h/2xo5Rv26zSfcfRQGoIRNx/pooq61so37NfprOMKRx1KUHJGoLbSwlunzYxvk+5eKcKm eq18G5vV6OnaBBfXdMmethO9U02sI/BpL0D980Ut0M311QF8S257xa5vftpqacxn2Fc37Cv6 6mIouOahbLVYZ5zbWg1JCre/TJxU6/614iS03lAMsLrGGf1NKICUqdrBcrU2SsoSM6S1o/a6 NBEjbbuv7kyrhc66czDKPZzZxKAuhY/kMXEHIq1wY9OcfNT+zFd+7kjRoXZsOtQ62KFGu1pB K9bKUCiMSHu1Yls61IZ906FmOtTuTqsFKnKHGicXBxTIXk4c3yL0zy0As+BmBVZ36YH3mHfG ANtJeCHRbV7HArbaQ662ntJyKEAClQBiv/ONeC9tRNKN8RSb1Ib9tjapFdi+xIvLTHrahu0q FD+pSW2tU1rxlE+6Sa0bvnUXMgeFgqnM2r4DYzcacpKmAcHu7YSvrLV5QWPb49EVA/IUfTq8 M6dmpGXsTDpmL9zAs4kTLlz7frdIe0iBhTk+P82w2+E4YODT5lG2bS0YC9I4fJKO8cz30Wxq pqC83dHAOkp2yENGFJ5NLvyxUN4UCoP8S5pSGrBYHl5ZC0xiSZotYhl5wT8LmYuWbcanj+Hf SR5YSbNhFIW+oqC2GGmttywTLy0/ECbBtlZbvukBqnfd2IuFSwHP5hZFfo/GJD/Wv+C+pTQj nQOuAqUXLSnVLa0O5iYaByn4cRrOdGxAap1MNBqQ2qZp9JB86fAn1amYUedrdI+2xFg2CvCO 0Bl1QWo4mwakFq90FzOOKZzPgGOFS4MO9k/7/X8JIVF7fWS9mqKDKgNS4/i0Y4DU9vuZA5V+ 8WroPPHiddEW+c5whrMTy4fn5WXq9WrjRoBTnBt6TK7y4aAaBrCkcKU3tRpMLrWpKSiAWrCL AEF1COg3biovOosjtZDswaerX3+5DNjUDzC2ECGSOJrUafQuYPb3d/TNFtoPNNNcLfVLNZ++ g7FiadTaK6DDsunn9LmrhhZNnbt0Krs02Pc5QtcGHC243uTToS5ObcyRBgu1onLzNKBrKKCR I4MDFwVX7EdkoGsPQU50RvyNJxlHL53d0hajh4sqpIV53LDSz5ElTvIaSAlBfdHkpiFO5abI qRYCkrf3bGZ/FzmlqYOAkf0QAxOlBcIbrLuU3QCwDRSQ3hMDYOtgXol2tYJufFYANqyRdPgf Ma+0Gdhba2fi5kcUjZwFAZik1+6Gznu+MYsBsIlUUFMZNelwKEp6BsDGnTqOiS+RIz2+6vdP +6mBZ5cBvELhXr6f2d4NS/5GbuTKrc/PCloPBDLXrtVL18oKbF86nm4Ny/qaHVI8pQGwPVR6 2p3Z62BuTAlgoxI9YSFCkEsDuYZgkAOnAzBzObfMomgLoKYIidaJpFtLOh4dXFJpOZo0NY7s 4iku3RhkgySAB9XhfRixeQJSmoB3fMxlY/JaetWSO9/SNHmS5uDOwCrRwUHdOelHA9/oZJht 4Bub4Bsn7YFvxDWAgiRoE2G24Rh6fI6hIUfRlQhNjq6G+6cHJSvsaUGqWBUfEGcQQTLwm0iE CKNBFEIE0wCj6cWgj/8M+X9S8A18tr8vmVQeLiVGaFgHvMIr/ekApHTZUXow2HoEcjyuW0+t byzsx8/xqGiNYR1ETBWOoWEdeAjfPv4fkRCpKJf7JHwHJHcHJKIHMgSv3qbS0xmOIYj2re2i NtY/PD7YHxwexBWyTdtGzjP9TEknuoPhUzW0BkE2DiQVJevO2lCpWrrzOUI2hhwlsx4zJXDb LuT2tYvtXcdsUH8Dnb5VdpdrMuFJpczWDtYrj1mjOql+ZtjliBv+7bC2DrLw3bQfqr1w2IO6 eHgc3G2jOjKKOnd/cvNY2uugceAiRQUiZoDI5YhAQpRnv3gXk+Nh1Nqev2AB+qkC5Eldt2ZH 71PKiQ0VkLxB32BPOpgU49taQcfXyr0okGl5Ol6tLXeqw1uDPsHx3KTFa22NQZ88CuO2OvBP IkgZ8KT++aK2jqs7Py7+zWwU+1z/5gaN6LB3GBOIrybOdMoCNLJbd2xkJS3FgCCB+AK2nMiV TFFwRyQGo/vKzlQV2XjY+sQVijc8CLtYDexCkFplmy3rCtXftS22QJhBaoAFY9/zVvQUoT9n 1pzZdP5HYMTpMApbUyBa6sg/i6dvXU40N7xVgA3lAPf5zfQ7KTHTb5hqfuBj5rqUWizS2oqw qLC9q+h6q6ydIiPygMns9SyCZSarrRMPFt1Y8SK14ruuTfWDlCOQ61JdqJqO+0xuh8eivQ+B PY2SSaCpP79cvd/7hngk/9f/Lj3GR4lK7nLJZTVm/fHa6ltn1tMZpyIlp8wzc+2Zam8t4ycU 3vDM8yUp3zZSdA4UMMICwceANIBlj3yEAQ8Q4ghtAILkjMDEI4ZceRA4SCnwAezSs5Y8kR2U iq+fL00o3RY0SRPZtN/+dvXx1PqVDgmOOCDVqBIRmpoTwUZEDspjZ2tu39PZ8BhD/syIQJdE 4AL1QWaPZzyrap2DgpF4gH2LmOkFntH5E+rQ9nwozUD81Dt/RHzCcceFUZILTIZH+ZX1zuDh ScuhsG+KELvYdCLXveM+izCyo2WYtp8AM5GE/AUNNnG9ebEcuU44Q8tN8s36cxrLuTWhEFuk c/lc1EKhxCli7rQ7BS0AZfDa+uTfwamCvUhUhhhcgQ8mbOp4XIGYwsuOCi8MQiEOpbzkCmXU nGCEFjnX8B/CMbAnxk/okp/Aqy42qinTpTcmUgfbdaJ7C14CpgxQPLVJB1VnhsbVtS7emCCr iX2k5zBm7WvsBDzJeThDQycgc1feAy+ICPC7gOcUugbdmIdDs07sW9txYS6Nuep10lw5YbhE cMJhsTE0wLnllgvzBu676KPk9okPFX3iAE8OxXnXrMC3Oq0p128KyNk1QNiKCmBhKbPJ+5cu fUqMNLStOjXQJp9YsWK1aqajrfY1tKZVHMdzF5hY0SoesP8uMehnDphkWMehfdo1x50qMhxm tOlxatL9rraKH6Fvd5idXZ5+cdMlXpcRPr2au+4S3zdd4obTH5x5SR8588hkIQfCu/ooF2K6 xKn+U6lLvC/ZYalBfN80iG9xckZusLSvahAfdDZUqsWGrnD8y4RKte5fL1QqYO+kjEguCeas 1vMq1isvUCqDvJJjuV02F64RilZZuMSU3J0q1odtpP3Hwd0URtXaOLQWZhR17v7kFiLk3akn QErg3id//J3dWz9ToeZ3h91lJoaWrFi0NMDL19mqpu+BafruYtM3batJcOU742ig5dNYBlik jL5KQ4MzGknddN2EZjZN34Z46+60sKiowBshpPIsgM72ZsK4jd3liHCIqN0Bzx1PjSZsN7Dc 6PD0qJgXWpHtUhs4kCjLCH/zX0kHoaQh3GmuUL1G9NSCri19jNU/X9RILy2HAhlUCaa4Y4wi xiq6e5EzZ6+scAYUmg06cIz0Hi/D0LqBG0RSMrEWrn1PjOGrGd8kRNISGImQlqNJiZjbHgZg bml2/dlr0REun3eoB8u25v6IRm8tZj46rMTWgyNiDKkIbDSE41PpnY0ISMvRpAhMA9+LdK6e GzpV0XBTe0zNDHT4afehJgJLfCaHcCU3vaUhUReK91V2WZx97hHEWib2DIA7Dr9H/uKVRcXO xQIIZK4ASBaEAnhloStMEsmSomCcAm0v5OwWuYgsA51CvzSmAQiUSh5A2iUglbDyAdImwyiF LqG/xJxtDkvmEgBAfBDB4nPncBmQFPDPRzSUG5+TqKSlgX7QqIbdtDVpoLtvAnvemFpI7ATn D7Otwd4gj08TXuXfPPeeS0bKdzBCsRuhECZaWu1tmwu0rZAakGIG4IMRSUy4MPBvEVlSKJlM HBI/LD2mcSKk5VDsWqXMAo/jdK5eXlecCRtA/IB+srmSVwlJoPQCuAKcaIbQcuGMo2XA9hxv T3ois/3ScjS6/WLJda5fXgAUucdotpyPPHQIJEKRsgVxHGG9CJk73SMP9+VKUUgPaWRCWo4m ZSLWxzrXb0wmYkOxCjDJakiKQ/IkM4pDelIjGNJyNCkYKf0c/6/OrRqTkTW9EUtLns6QHqyk SJh0VIO0T00wqnybMdEOy+NLHH7f27vxEXDmBZnoo721IypWQYVQylqoljoCYZJS+kmpR0tK JwlISkfwomUYwa+YUzsixtmCngpk1pCIRGe8wF+MTOwm8BQ7Ia22wiw1ZisghnO+3zm+JToW I8ejBkbIBBiYuHhgmgf9vPSQJe2GURP6aoKKy9JaNyYQZxQwXK3cx1gLjO0FhZYTayTST1xN xbWrlf/A1YZTq33LyIC+DIg9eawKxssk+swmp0RKAgQctjVyqLLhTQCB8D1JXI1qkJZDcXor ZaSyWlhx7cZMReIRhOOAMe+VSEathzqwDnHaAv6nSGuSbZGWwUiFtByKnaskFQJmoHP5xgRD eJS8vgWZXHmO8cd5GSoCScWpbOlJS8rF0w5AzdM3GD6XlJzWuR+5rRwKBSBDp5/RMIQ/LgHl swb9EsMQ9teGIXSoja4ItKRoYypsiyu6Xuk2NzEMQa9PoujGihfJ61dLu9TyIcn0o3VtGAKk XLRDr0+dj61MMqf5Mnjb6/ePhvsnbzgpTxA6ky8f2PRRprahu/E9KNBxphN6igZY0QhKpJYn 2InVXc/I95AayPHX3IVSdhQ+KN/VVVfvwtdXUJK+7f289DyAQD8x10Wk7c97+LEJ0q80En0w 3BsACXJ81e+f9oen/f6/eho3LPuO1JfzaMMiNondTn2hta06KMuKotiqsltCTosub0HLV7As vcojrOBjablCqUhaajaqnayqPChLwdLQij9KW8+uUx1Sqoti2qSgJnJeL3Kyoi95PqRONNu6 mCTtTqmF+FEEYj3tJK28IqHSWMYjP8WVTZM/QHOkh3vqoWqLxSKLnN6+HGTTXaipnIuS+twP I8uZL/wgsqkXNK6yUoEepdYFRlzIhR0jFtIpUWydIiVSqJ7OMqUqxaUb1A4JJovMBeH9ExMi cBjptmFC+CYk5gK6Ja2CEQppORQ7V0koeHP2X+QipuL6jUlG7FeEDF3hM+eGZtosAscPiBIY DWGQEzSRC01heoK61BP0GaYgtFhIEArHJgQFNpq0wtifz5eeMxYjSzAGDqOOCGtxB47UCIrC TIx/Kw8u+SOjEFYJm1ReiyRHkTZcz38mkVfq3ycfSTF3KiUjW5u9f3yNiZ/WYrSyrJU5MdqK 5lBkyh5yVpynLwqu2A8VIVNqPi2mq7HTn3766f3p9fU/MD0pvL4WGanr6w/+eMnZeK+v/+9v c8+J/GAvhMsysYPJ9fXnj1cX19eYIfrt47vr62A6Hh73wQl47Vu96x59aV36GMqEphTP+hbL LCzeNSbi0katssbiufkaJqubWvCCDauV55U3Ks6R8owfZcO+XLynt9EUqPifFeaVi+6nEEgm 84ppO9dn/+6ihchl1zrgJJQeumnf9iSe8YGhj+8mu5ahj6dW8dNb233bk6luSW8dvB6+BrvW MKu4UhZK1lIFswigo2PFpqefkgMKlxgPyDnFcTw38R6q2b00ZiGA99CyPjBBH//F0MejftfB VOHFgBjc8Xsfvw/w+w1+H+L3MX6f4PegT//hPO/0f/uy3S4ZKO+03qT2CuipdQtArS5fpFSP +m2LMsW5xNXY7HNs/zm2/5y2/3wAITkfQErOSRDOh/uSCuyGDCQalic1VjpWRQrd3fk5tbhy FcZsPfpLCW7GZta6/yruUbT2pkIzBFOuJfu1ldyfWs+rWK+84Ks6Ui0Dwhlxr2H0PuR/SpCc Pv8l3Ipl4gh5oE8SHxWqGOEelXCO1AvXhHP03Emhf126kbMAA859HtPJs9HfKoJoePJCprtA opbRoLW8foVGKqPBa92/pgY3BNHKaS2rEBayL51/hKJqc6zezCa0tCGINgTRRbDRotDlc1zS Ryl3b4yqPlV6qLSjHuRsZUcXS8egZBjTwVzAC2k9UqBcvZLBuo2AC8mBzql/n3xUu8bDGwzq wXwbqfGsRRFPoALzlfFp7hbPaGpuetvqMC95ZfdHhEKOaJtGh7xAfcwfXF8QxodgiQ+RyfzN l17UnHZpORQIjEoIjzGK7YHt6ly/MYQHaqu3QHXABDjere/eQiT2uDUYBf4dvqSWWGaPZxaF RM4YkRFhwyA7MhDFSIXOrlWSil1jBAM2Zs4tSDQEroeTaRD3CmfeIDYNH85CABngGiItF6Qt rgzVRgYAsjXBuGMjnWs3pirSMECwKJDLmFUScCm5LglYuID1cDBcxBCHjwED2BEfD4tAgHOz U6lYLiRFAf0QK5Ag7CLgowtpr8J0tKIAYFkIG/1ggvMNciXmoQ1yjMjRi9Ag6Nw4GB0CTKiA C0MvSZOG4DLwAFMSS+MwSMvRpBtpLyeO7LMrrt6YZeCuwcSZTllAjGwpVzEEc0b8MfjB74jv Dz8CKYpR5tIiGJmQlkOxa9WcyO3JhJgpRAEENpsmhiC34GP4NzDCrguVMFpGRNeIeVJAC1tj 0T9Nw6fgQEjva7ZfWo4mt391CHXu0JhakPSAHWC2lGuPH9pHXtw6QbS03ZdW4PtzxA6wMPZk 4kRIPEjPaQRDWo4mBSN7BhXXbkwkXHbLXMo18PCBWyordG48Gx+ShNiT/yzDiPJSDP0lGDDg /IClMI4k1Zni1uvF1+geYVWMtvx09esvlwEtFlQuFi4uzoJ35h1YzL6L2S4csDBxbj8TBpKD NKtWT+SSVzVH8hwtI5RBmDKbqBu5E8lzkSnHkoJLGA2L/VjAV2Dc1yQnUnShSMfBaAdpORQn uJLXwInada7emH6ISRn5Rseca6I4JXHGj5cBOZrwKMMFhJx8yQXLzExss1igVo+DKMDIZRlk jq6G+6cHbzjrCj/X6kNIS9D+CahyIlkhvo0JGHUxImCdQVVqWJWLd4PBEYfCZHmH4m92o5fT 8lKWpaeCvOQenZYshY60p5brTVmmnPRycXBHCuGhvndRuf1LMnPXiqj1jYKgERk2EQmRpxPd gZ+UO0TcY2bJ7DXBOQlnyIbHxBsyo3s0WK7JLd73jLT0RjKtFCTbAMobJHNswiv6SEU2YeVi 6oU4j4p2+5DYrSeC9CyhIhVxlA2xidlrJTtdUho6iMmQlkNhVSo5RVPM15MTF4qrN2azaIqW XHBRZFXIa06YakPnT7amKYyGSAKgJxg3mZ78ppzZp9STDxwpZLYFeK2e6cnP6W01Pfm93cRA auc7CXONz/ObH7FT65vIksFrXCF8kVYXSVcWzPmUgyDVlgz/UnKWzDpKy6Hw7ir5jpiMYvNS ucPkNVfcpDEXEqlVAu1JUA38NQ4xVh/zQm6IHH0WhmhkYmsyQZnL3QoD5mStMqgY845cJEAc 9CfFD2kRJaiHKNfzr9bTwUYstiYWdBR1Lt6YiiBo56YbIt3uupU0H2kaTP2daN2hsXdKIKyE X0XSzSY8ImRa6yEqvWa4APDBdhF7a92j/IuevbJ4DTWulNIQG+lO5kRKy6Gwq5X2FrVonWuX 31MF5I60saiQr6DXq5RgItiuz1E2SUE9xuMSliKSntWIhbQcTYoFoAu7RdtxZ14y1Rh96Ftz ZodUTn8QG64ofrJpcC7Amc84Gfi0ix1P++lbV1qozgfyMDxFnYygZvFPvjsfsQBTrFlk2a58 8BSqJ9dqyPwEmrdXWBNL/Pr4YwHWyxD8ZGNGD2kNQVZEI13i7+M/4slVgxKTq97wAQ+C9VDM UuoQ10/Rhldhfii6Hsq5ujSpgosnWW0lg6lmDVvxInmkOmrigwxpjkSTc8F/VaPJUYh1xqyn n6tojRWvymRy04TaCoczwetAykX3c5lSWut0YHqZKimZx5vM1BkMQ0vNeiLzPERaST0nhs5h tB0aRtsuMtrStupYE1l3FNC2atCmKlRyLesz4gjJbVG2tYbR9s2+sKlqtV5vawyjraBjSdme Vpv0Is9HRb5vgawWNLWbGW3pp4jS9GJAzLcDor4dEPft4PCV5IzlppzUKNJ4QWFxCGp7Scw3 j4WxfcP520tALgRo9GDXmOwUu/DwjbT2fJDBynhzLtaKr8NDh3hTvmQ2JWa2KZQ25Ksv9hFi XhwQCfIBCc+BzHUJOXl+ANaWOn/Pt7s9l88ZdN7nRZzOUIDnpADPoQCl85er++I9Tw5Tt43J OcwBsV5LyyKrJd5X8Xhq6XwoP1y39FB+GJcaLi8NJon9xy4c/0xIoiZLrh6SrPP1pRJsTd6/ dCYws6kVQrhtrFdeCFc9C59JMG41xNvPqK+CAEu9cFAsdUeWvDnaGOCp768h6AjwMm+auz8a RYpZvedQZHmtFCu37+25Dmgm+Ihjao2wbn0HXDTSZDrpbUpa45b6ZvkanbeP5iTm9g1PdxcT c7StFbS6moxaQzk8ucQcFkk6/3J7XsZAq5emCb19vFFvq++vsTVxYi4cB86iLm1KS9VeF3zS wgyJyuSBSlNA+AHJFSTdI/w5ocGVBPFZBMBT+kug+T0muHP4nO4E8s+p2KRTUNIKdjDBKS2H AodRCRnIHRCdq+c6UFWkgxrFiZqXJCFF2yz6hyVPiNOoJBIE6aDp3dKjGrmQlqNJucDu6Fy7 MakAsJ9zDEAwwDKQdpQFM2/S7zGJXWaBLp2ziWObJqCdsbSKjorNUPgbNJo3JhqRf8Mgjpg+ TRETj51Cfwlciz/6D0jtibr5AgPd2Q97vnCZIPKMf2AqybBRF9JyNKkubJ0rNycRtvfdmvu3 xJ7EAeYum2LGOzp+iB7H8okWnswLnEuiJ5mDl416KBLpNZ0Hu+N1Bm/i/c71Bd98OAxE+JvW HSQTIuPCDYecOCqpHUzM0TIWmr8vnfF3nmCIzkgb8YRnbi6wkqO8XEzsCOjj2HMVZijCR1n3 Q6FWG1N+cf/zBO2PsIEz+5ZZxAwGYV8Ejh+gXULSxSXF2sRO6UR5YXxzBqo/OR7Z9tav9JfR XG1hbpATdIXyosyWGHacZ8mOU5YO8fiq3z/tDzlUK67aCjw/SnTvOTe5sHtiMUsUYA07jmHH mXxJgXqMb9sy31aw45D5T+jwUTUO2I0dTCgG5q3UccM1PN4xzbfCx0imItmKtCkiY/xb4xai 8ICg8Jb1ztAr2EsV5nOSz70HCiLUMjirczw9LJ17Mmsqram0HApvuFL09SiudsJUkOSPFj7O VczDgXSS443dJQ2iFASX0rubqEtajhxRyPKxNBepr4hMwGeSGceheo5VcJ77FKtvtUNDhatP AXs8FgL652/QyRhGmFYnPejspYuBhQ/5bGkdjVhJy5GznVR5qKRhRrJ9VFy6OVGwyOsWJQ2y 60nBgqcuI+S3/0fYHP5TQiigcsIIk0UMa86OZhLGDDU6IteYXODgB2wOMkS3k6wnuUjAQ850 n4sE7BAPgzZ4SwM8pcC1lUF31wJvlUguCJ4HGd1tWnRthGcxyJN5BLSjgoVI3ERnfET7fmta dHE8eS9y2vtpUphNi65p0UVv5aCgOxffHps2NdntuRhSW+qQOpn3DyQfpWSUYLJ9Lcv25TZ0 6jZzonNRp5s93vTn0tFJqwcVYp0P5b6obhyVfK+aT1/I8aoPhDnvAjo944bUauBqwKeudf96 PjV4H8gGrC4iPEpeJtxSh6divZ5ux6RsROXCvragPfjxivVhG3naDgcb/e1agtb6jskPDjLv DoZvI7f+6zJ0xta7mlzRLXVx8vV2ioxSCpsPTF9kF/siaVsr6O5a+RuFbsrT3eqof5fd7Fgk KcQp1M7qpWlCO8cpSfW6NEJYZvoi+x2Eon6mBsjUdCNgeKk7ARZuRLVBfEN4ecJuiE/vZlQk ovrQnFMe80nz0kEoGcB0cE2l5VCU7SpVBG15DoHi0o1VfhJkT2QtZvcQCdvluB6qYVOL02++ NcbgcEw3wjgkYFgCkhZqinwF/EEYMduUBeX82PbkwnV1rt2YYCQwFEC5sPWRtVwQ4gSKg4Uz a2qHM0jIMwaEt9S310yvmKdvMPn61I1hLvpIYbvkjITmgIUOzXcYlpjvcJjiABcTBzrEGlfU c6KI8wpxAkXXW6UXFQC3T/+8/Pjll8+//dXqpec7YPnJYq7+dX5ysujGihepFbB2bb4DpFwA Ccx8BxZ4LNr7ENhoC1//9eXq/d43Nlr/gn/yv0swtNFYGcnJK2lajFk3Zh0BY1N9bciIj5cA n/ve6YpbaY8z49xh9ukocNjUvUdvCP8pZM1tsCEgafD3JRux8cae6CwUO53aKlLK0dkdGwXR WDooOWEyv34cDpU8RyZfob8Zc8YipI427Uaj3Cw8axVZN35khcvFwg8ipCq++ghLBQOH70Eu aWhvwNApnxrdLT2lEYoX4Jt+aU1Y4NxSQ0nccERn2F4sXCSDKA20IjJJhsHa4Xd+zuPZmWZN d9SMtNuhmVHAYn0uSK9C58ZDFhCKX/z9BbJBRJ8V2KC5Qasf1C0bz17iIH7y72ggukHO7Sgz iPMqncEcW9io9kX6VzAshjPeNoQOkekywFMEW7T5NoTvHnnnTW+atvpyua7Qp1BElpDrCUxI MCf+ZN6IKd3fWBBpORSCp0glFe7HWcpohzo3aSzv/WLV9sRe37wm8tAJQ3Vsi6I9d0r5siWk +mzv/91E/4MjYX+HPo7noHOl7bugFJLW1ciytBxNyjI3mDpXb0yIhbEOaZ7u+PXLLpZp8kFM fA5VHvjUTF3sJojJTF3c2NKFvq6M7kkH93JBpwBEBPtQdyjHYYwBr3R/jf5E09JlWrqKW7qk g1DS43nayfUOpjRNwxIUKQlxU/n+88FJBw9IvqfIR3xmPcUO1eczdn0/7u5YD7o17KqiDF5Y z2/y/qsKviJLs1b/f2hg0MMANPmwisWqhRkY8U74bUzllvsS5dSC9qo04Rq+2dh9VEuEuWv4 LvDviJ57z/r5209fBZw1SWbKSaZuuAb5mo9PEV3TfB3u8qnVtqY4zmV0X63719F91Vp8aj2u Yrnaqv3K9Peo16UJ/Xe4Uf+p769hwrn+u2IuW8x8794SJQ1bRpR3WenlzvHF2LsOqz11P5qG vCjOcRm1V+v+9dReNcVX64EVC9ZexVdG9alXpgnVt3lUr/r+GqIcZwVNa2MXWxvPMZBpxLsV V7bNX7DABmOlZbsu/H3LiUILMMbIn7MACCefz/ezLYAIAWHkAUGdpEcH82rScjRZB412i2Cy x0RJTlA1B4S3CPcw9Jp6Gs+ncH/QyRY6NLkN7Y43MZcySUYAaItH/bBjGVRT0jkyYpEu8qxn nR7sRnSWZdlQiFxjxfGAjRkAj9ho14V6ENNhQ3sOXlzgPABwu5thfBv6o1Fasy3PD+bAvQk1 Ix0NIxLScii2rRL6h6IU+fwprl5eKM6gAb7RBttcAAj1GgsERjtimhWdfHQ3EwjWmaD1GZOt 6GeAdbvzICzSKxsJkJZDsUeVJGDXoEZ+/ue255FpiFUAmp2Fc8HFMel87yKaRrNtuINWzUzB aqp6+EdGF2ByroAjvO31+0fD/ZM3Jz0ihVNEyuuphZx/n3x0GWQuGkNTZEdj7x9f46xaMqoK /96ZvO0ND497+F97Gc18XOnnpeehc+QTgz8QBf6cvqOxi/hBNOTtDQZ7AzMFi7Yz3rqr+wXW plZqQ94o2qW0R/jl4v3wuL/GjIcnCEJn8iV/7+VyVYYmquh+CoFkMmWevj/7b2Mh6JzHsITF 1+ieRk6c3tru296nq19/uQwYJo3M7QhMe+J8Unf8O/SbfH9H3zTYwykXNIuEIFLUlokCJ2Kn 1jeaAt7j3iGfgFoqiJA0o3EapeVo0mkUsZrO5cvHDQr5SHuIPeSayEucM9ujVlj0T937S55Q mDjUO2V5y/mIkPjUwEjfS49qBENajiYFA9sQ6Fy8abHAQJW44rbKSs4QXcztCVosb23H5T2V 9HSg30LIyzvq7HFUC43QQS9dZ+8qhZmbJ3U12jrnoo/sFaYuUXoBqSZQaz1IAekEyj2inW6M 3tvv6MhFspqSVEJfZEZFGW2xNaEgfjudizemLbDPvIeYW41U3glT3yEQmPjnowERkzUhC8he fZ7y7NSmJ+SdkJUOBd2HbUy/Ndtp6RiVt6N2Yc+X3Q6FnW1MuJFgzzFwXISFO0QuE0hEiIOU TSDfF6KZeI5IwPSQ70godu4gkY6h0hvnln2wgsLULReUfpk8zCmknxZu00+S2jNGUFoOxVGu ZASSoojODRrTFVNk37hmiCvzVK2FW0SDSRfMp2qteKzEGsauNP0z6TmNXEjL0aRc7Lowk8Jp cMlYhkuE0qvS3AvnNXvNvxABVGxS4DllH9TIxNZkIqc4rhC5xjQF3+2XsBAwI4iYYvcZ/oP0 kiX3vKUtfvk4/hMqU+Tg+E2re+da3QmobDrdizvd+RpJh19O/svloS03up9sRPM3AWkVtG1f 2H+XDqY3A6tSK4ZuqfJ7vtCECxpNOqRBm/h9gN9v8PsQvzFR8OIEvwd8FCf/jzynphtm7/nu /Fpnu2oMp6TvntWuP21tZZ6+wSL/s5L71hX3zPSIgIXWB2DKqbRvDWGYCTUm07z/cQmEizXY LzE94qj/EN+J6REdmqBbhMRRwLHW8YGpCbNF1yvdSpistpkecaoLelPsGZMhdEkeA0kgpC44 EBNSbqZHnEZnnz30JJnpEYRFJnOe/MlxhGnYZ+w4JR99YFN76UYECG2pS5XIPK/BrKQ+d0j6 foczd7XICxTapdAiZNI9te5f2oKk+Ieq5e1qPa5iuWrhtUfbYyAqQ0+pXhdojbr0lEfbnoCe DyFFjVMK43MqJ0VQniYFPTq7YBP2Q+txcis5jT5M/nJZ74EFkJ6wG/FfvqHIncoOQ2F4SzpY 5KFd1Qk6MqesVinhyRmL1vCWHJmR7MP+4fHB/mDF6yxaCdXBeEXXvnU5L92wWN1UdA6ENyO+ idCiuSlpkMsddRqBnUIQVgAsPmeY3o7ip+t8Z9bX72i+I2C4gYO/3RE2kno0JIcjx0NrtEuA 4OC8G+Ty69Vvcc8QJy7hQiOwkIO9435/78afksNGMDn+nZjIIz1sSe+og2dNWg7F3lWCSGaO oOLSuY6yWkfenaq0RjJ/bcbiMXeO50TUV4YU/HwBlqMVenLTGxfFE4VPdsbFTevyjb3259+/ 8H45zspiQH3ovOZgt+CW9c5QZaDlCe37kEPgQguYAawRGosehnOB6wq8NoShFUoC6sWzb50b QKwNSHKcXc9Nwk2avpK2wEbJ4MRifVFSbz+p9GdqMLqUKutwAnQbQVqZBGit+9dLgFZLgdZ6 4KcX1bZlRs9RPAMhHeI0mW8wM3rMjJ4VdJEDHGXJ74bZM9DFc4BWzwFaPX9G0MX8FH7uTML9 192dNaMu0mmwNSssdxlXp9b9a7k6labN1HpcxXK1tta7nwmvCtwM9brARtSu9W4eRai+v4YY czfnd3QpgsHD96YIyL0x5XDD+zBic9HYPEbHRoD0DWV6mUxP0w0rmK8P8ydvvUb/TkwGloB7 Uqie5KMU3qfVicomPWbFES+jEWvFUvU0oilp2pv61iD5+lpRvZVNaMXNU7jU99fVih+YGcXQ yVEMHvizb2zP+dOOHJ8I1FHctK3b2AjO50vPGYuvYivIGfLC5WLhB6hemNT+zlLRLIxQTHLC GTWNZnRPbj9HY8Uc8DLMAdh1FnYAXnUhG5CTEAITrij3E8do5TnJ5deSzlGrHYXCapsCALcZ L1i5RpHjihZXKeQe68K3OZOrHyV3saX1jeeb6LnCgAQd1VGpVhbT/1hQF8wezyxSF84YWgMM eSHzdsvOBwo+ezlxfAvk4MyeWy8iguDQ3BAWzGu13BvVlI7/i7WHP9WRtsYM1dz3fDB1YosZ /nzzGqnq169fWxO2gPhRJA8PBx6LReQLCzKjJKvGhdmZC5PSCNuRi7OXhLKjLU7cEWEcgbUi 1Sd/aM2dH/B2zf7vbP+5Rt7OzivcLqH9Q+tFQtQbT47C1pM+gN+M8WIhoDXRElk9F/S+k4nF plNm6Jx3JhXhcjzbqVCAzHvT/aqD7cIFwmXbjQNqrfuUt3/QcyTQ5FXRdMQ7O8Cfa04XRiFB w8l+V0kP3jg7+s7OY2k3jL5z4G6DkFew8SYmkAYjmvCtS1NNyIfZFGWFcYIm0QrkDK2coAu/ VsnKaAN9bUDaeJP2b7QBIeVcI85h1sy5mYF5N/TdJU/tirxdmrabwmHbcu3gxuTqZHy2zsZV ypHcOd7Ev9O5fAWn4BVZAtAtJyNrKLrFNOU1IRD03Sv2djMgc3euLqbSuhnYQGO5WkUIJESO WpHIfAhTgD9cCnEgMJh3FGf0eaKM3EnTprYzgUCDBznvGSd92yLBpxk53h4PIqIZ5lt5GGsk 5IAm6yL6GUeYtuzev7JGNgarUOIMH7KMSTPBhI4mr2QoME/KucUYY50bVDAV1HzIU1/rhz+2 C3ys0XgGIASzkC6NjIuwIxdhGiA9jdy0u6W9V5iJF1AKFCugfgtgWyhq/lO4D+HLeEKeM6ea /2pKHv3whGH+iySiRiVIy6HQ5JVUwtrADMXFy6sDhUjw5s0EDBLX0RA/CN8BRoG6ExNtscTQ dZcLUIwdsT1pIYxcSMuh2LpKcrHjjuZU3ABZwCzmyCSZupZkkjBhNPyST7QjtkNAn8F4eOcH 36EHImsJLAWnvkAm4eYGnmMIt1GSdHPwpeVo8uBPMUHgLkuspbhBY0YBHuEEEzFvLHvMS2dx vTXhwoRjiVGHlHoOyYPE3DrQYtyHABGiuiathBEMaTkU+1bJIoit0bl8Y2JB3qDD+VAfNARn NbjngcQKvIjk1O9OENE4qEuMwgCdgfSYbRYKYOpXXKCHxPNsLyOYv7e9n5eeB3aPTwzz7iLQ etB3NAvvbY9IpfcGg73B0dVw//Tg8LTf/5domFDjZmgJBCeTdrJZ4b9hDHqsql/8fvnbSw0z jekUh/0P9PxB6Ey+pDo34m92Y+jSK320/ZXOFbqWLIWOnKSX67jGctHm1pe5L8x29yJnDp4S 9iPip992MT0ZA7/YD5FQWCtJ4w3o5ukX4ZOySp+wI37CmniRwF44EwKEICwGdHB9Rhl/5lzR eXJ8x88XEPs5oro53FYkXIiViXc3iDRIuvch9mQgwnfwuSJ7AYF4MnZLR4XUP/Z/SOsBRZIY EeoIPBrun7w56dG51O6My/n3yUeXMLrSRePOUvlN9/7xVdhafPteJDJjAvtjPqahhHI5vur3 T/vDB+VyGQgG/NWlz+j148eAZoiCK1J+P+buKQBBGb6iT/+8/Pjll8+//dXqTVGvO/3pp5/e n15f/4Oc5utr4U1cX3/wx0s+H+z6+v/+NgdrmB/shUi/TVAvuL7+/PHq4vr6y9X7bx/fXV8H 0/HwuI+m9Wvf6l336Evr0ge73D1l7r/FMguv/bqnJitNVjeztooNq9WtLG8U7dLD6kVnXy7e 09toClS86HL35ieo7ABhyvdN3pZSIJk8BkH7gJz9W8PP6qqFeNoNH0/76VsHzsltSlPEs/Lp RSLpfvPBjc4++S7N77l5ZSEVZbvywVME1LkRb6XbK7R7PETo448F1K7ukKGDEkOGjlODKMTY m7gDuOtunMISFTbVF1maEnYaltW1eslq6/B9F91Y8SK1TOrYd1GOiQnWL/gvcYSWyYceUGEa p0oh1llrzGOsTdzRutY1IZ3A4cTT8iFDkHIzZMgMGYqFgDt5FGx3Z8hQ17W1Kvoh2mvQHz80 hwo4IkVjFISDbQCl5dG9ACPgkwe2nVeEV5L0UMn0S+tcJO2oQqGUt9hVLqJj589MoqOMV1Vk AlXSgXISECge8GdJG4PctBfDGLPiY6RC4peWlkOxZQpPvHDTzsALgjM6dXYvFby7yYeOCAqU A1caadmQFsJoC2k5mpSLia9z6dzYq1DgFHqPysoz+xZQ91URetP9q3f0PUhe+BetuzT2muMA gyJ4YhpIG3RJUjGC7c2B1ZWew8i1tBxNyjXagQnUwmTGCMUdGtt3BHKuf4PunM8fQjmpUXKr TUarwZHlTRRHf/MjdopGDBSdgJHZGwNcTy3nBLoHyDpgPOHP0faCYYtjLKd2CAYV3p4hCXpJ YTDer7a7fRYC1Tae7fjYX4B2GeUasI4G9wves0fMW2zi2LxRA1/ZI8dFUwB3jQPYvwDig/8a YNWOsPmwBVHg8N4Y6SRu2yBcfIv7tzAjhv1wSB0w7DsK1kl7J4H30crFPDFwaPZ0YFVq/4/0 W1NIKJ3tqhQRiYY6ncs35h4gRo77xqAu1ht9BTOEEA+5/VN6SmM9pOVQHOFKMsFbIHSu3phI CO8gPLXsl4IHJKEJGPtLVxCFAHmZaQlHc98ykh7TyIS0HE3KRAgE9M6HEgqx4HlTnhqJu39T QvGfJYwJAZ6ozxNcAPfIr0C5SMtgpEJajialAiuvc+3G9IRsD+KgIoQiyFUbnB8idED+ikDF aIodOZkI92ag1t2pXBCTlNKZICcjV3BMQSYL7dtiQWbXqiK2Ff+fvW9RihvJtv0VBREnLo4A ux5gHueaG9iYNjPdbgbwdMwZn5hQqRJKg0qqllRg5uvv2impUEpKld71cDqix4Mol6TMnWu/ 1+YKIqKLQGDKSCBFwEHGPxUYGILcKtUhLEeTqgO+aEjtU+QWjWmQyKQgmyEUEaRobc9wxqh2 QguQk40VYgRVyUWRTavkfOjiSktErjF5CAOX6f6IGVUIFSxyWNM4dVSWxPdhUZg0oBYbW5+i vys+CHWoBqGG1We9eNGOtAQst2xPLMic1BpgUrrML7mrRcr9mnzgNsoDRyimez4dffL430Kx YI//oT17Pi1bLHh2gBlQkPwEmsUD7YVXBjohrOWXLABs1Eiy+Ms4zuNUdx8BZbGzyV+j0v2L z8JB4ypqlG5iKRvh/UsqtzUFv4LQ3WlWCUd5sdV8HnWJHp6gBTdoEORC0k3g+ZLPS8X01CH+ w2zNy0P89x7/IdlzeYz/TvBfv0f/Q1f69OOgJ8iT0Bh5zEdTVnxvOjZCY1asrTc8e/JVeUY1 6p7wYBB07MgZXUtr+6UNtNhJ6jK+pn6j2HOEIf/Zrf8CLsNQpXy5++3Xa5chMjXVfRQIBmhF 9dgfMd7h8SP9pnCqNy5FfLBdxdUsLEXxG1brHG+ur1WDJJKMHZDIHZBwHojoXW9TScLa30G5 kJIoqhrh0xZPz/K1b6JQ4hySeT7Af4BNPpIYsCkdS4xf9Y8EZBIhsxqHQOzMhVB1k4CqYpCJ 9xAfLveEhdZAdMcYBcNm2wlr+vTZLh5nURBdvC3qsUpY5INwhmv6YBewiCWmehnnrtb9oVqL 9loHPVyRcwfFT4ix+Pfcign8Bm4lhYUHghUyqfWokqWq1fXVllt3mEDTHIdKviZY3toO3XFg 6VW6fwHx5SOft9yRy4Y4zq+SgLgtnuY8XDHI1br/AqQk5fAxQokEyFWb5FzrYTcK5spMcZav ShNAd7IU6OT3Lwp0vzCbigYFbMezp333bTVCOw1Wpe2pSE5ozZsqbOS15KFRQ61zvk7RBsrO CSXlYxYELYlEmP82Kj+nnF0dgdjCJRWWIxEwWzMmo5N1YTIieoTItEaEkpZwobVipnXk1lbn GKrOKlKCE8g/C98lIQqZN89MpYo+VplbS3T8ptIhvRWWUGmbtoLa3Wibr7/ffT7VAtY83fNA UDaGNkHjASkcYv3VwI0H3jE+PiBo7Gc/mDGnnn7qX6kjDNuvaTLhpVIRSFj+LSw3jA7Xce4/ u5QBIk7LDzvVBpCdoQn/jwnDlrt83w19FjQmmTRO19EwKMLinWw0M8ZAt7gRTa0TnqckFqjt jwdB5Med0nRx009Y88ZkQKKldDQoLbb/lccj6kaIgQNa3QAWrlj+rESiyG5VQgScfWpLEflT 2hYHgAEphoztj0gc5jY8E+uFD2cHZSP0hv0grIESCWE5JDtWSSS8F89n0yJfn2ni5kPQHhHr OnMfGX4wQVOxqOHMGI0k9Kn7eRyym26jeZgZcD2JsfZFjtLhFpcM1opWSWKIZbJKte6/cF0l ai4n4IrqUDpRi2+IOb/yvFKth5Us1nrmlcqUCspXBQtcN7OE87isVFB+/6IB148u5qfBSpba YyW125om0QuWCm7202+h/3Hz+W/7VxchYS3+uvh8++nm6vru6vevglVQUkq3cKX26/1RqzlD uxJzn9jOGeTssv8qc/T/7mI+wm/fbu9oVkjAY+FQUEmbmobrzCboQ6RJZKILo2RTXMsWOxAN 9Ly4HbcXgfHMtGdzH6NGn0wMHKP40gNPY/pwKYKR1bV8CAVWKWhTaCWi1UA8YXloxfuoQ7FU UJWYeyIuI/0kSFqToQ2MXxNzDZIvLx/YkHiEgCVdw4R0F3DFwx1chGyDaRTy+Hp+9zMT+W22 4b/ZT792+i0zCSWJX4pZ9J9vLMhhibEgJ7G+5GBQxfsgwlHQO187QSma7pLEv3KDhXmx60Xo TgL1qeBftNpFAn95N5a8SK1AntDpuwVjQSDlCNttk9NXDeOiecv7F65+76ctKw2j4fb/YKOM 39Clv8zB6UPTaQULrOSybrZi3Oyn31i0lg1+0LSUH1ryQh1R3sLlvByKZ/+OWHqmJnVPR4ET TitMrpIWRd2QgFcVGSLPm7iKLfqsVLztOpbVVo3GmYqTiTtbEl9SH1eAI8bJDsSjkhcnc5nB QKKyp8EbRFRXhfXTRILiYraIOy6jGixBmNuOlsUipBrXP7s7wVPsoDAIQX7MdxGep6RhuoXa vDNpoBJNcZ5A28IA6hYuBG803pxEQdR6wdIt3P6U7il5QZ0mUVUdiucpX1URPGoPjjPW/pzr NH9DraawmuJatqip9PnY7HbQGM1S4Gz+GuZt2KncjnOvRGE1ogDWL8/hw06EHWhbV1kQAwt1 zffav8mTRgcDBGSmG48YQG45NCislpOlYlKFSdzkgXQyFpvqrk5C293Hi1P0PqHhDTXsuvYq hRqXjP8nCKOyWktaKamPq+UU0PXyvSiPeWbLBMgE/kQ+8oWQSVWjrK4aJdAVgjB3pKj4BA90 eRrsfm5pz/pLLfWkHCuFUNTEIs/hXB4tQSgvmmuJgTJhGkKLhi0q2VTx6R1mhwl+3uDTpC13 ebxENsfMp7nzzxN4enoknDwmJdYSKrtOXMgWPX4KBnaqN2HW03DxMD8xhtX0MgW1tPAMav9T arDkBbWcol1/Ih4okGvwImKQKRChwsjxJwg9Gc6U2uQp4oC+6geH/5CKiCnhFNeyRXAKs1iC MDdm15/tacyYOJqho4jcsjihzqJMY6qPFSSJxlJnu64/6Wb3kzypv+DJMcfaGNOf5+6IDj+X j/HcVZQZoDISALUzYUDNDk1h56ezJRyo5RWpgPKaB5T/9u3zLfVbn2pfnGdtOjcmnMQTdWCa N+Gzm9ELazGU+AZcOoKQKV3f2UF/ZiNh6RvT85ImgxhTlkoqiOBe0tdIfVzYR3WEMHpJOEWp pEIUsvNebGPiOrb5n8AYVcnvVVkdK6yD+ImtEWVLKVvqXp9bPpFXb2EqTNAC+EHQkxJ7R9K3 Ky/OIHZSZUuNzacrGlr6pFsfdga998cHw/77g5CQLKhdkS8hmSxN1bekjKOSFwQZUbbUZV9k NkrZUjFiIz41Hf1Y8WYstZyrCeOsgi7EQykhhrFw0hCPnH5j7qIJwrdUjUbCri6JSamPq1Ml nKrLvkholAdSYR5UYZQkTJO0mVq0mjrHKF75MIW9a4LOX8FUSDgrr31K4U7JCwqmEjAlNrDn wRRvWlvqsGAahWVV8li8GUJeaP0JIl/CRmU4Rvw+IbOYsomTELls9WgmSaVNYvf3KN/yinx/ o7RvVIIRKcha4bEtjCmUhMDUx4XNVGfpsi/22Odh4hQdUnNUD/kg1+XNKWotBf3SGS4l5itm KIxqY5gkJilPDjSCR5sd8FZP32C4ftOhV5FOgn9duwDrynSErtXByR5nfxMx8J/X+gPT+u/L kE4OdxDGDsaIBzSIR4p0Mmpg4PNeYkNf5CH92LwYCapLSCePCk2bybuxIp0E/U18x6LpTfAR INrmGAmak2H4gTKTstfamlekk8+njSThSirGzTZK1lqk80BOBe1O5ctDItxUPvmyLzLr5Dmo BlrUYW8o/9Q6RXxxdd3pG+ufKjhS8bIl7eh9kTEjD44CAkItTMurYNlqgmWvdRDCDrQdNAs4 vrIa+koaeAqTFCYtwySRIyMPk6bmDwVIq7WOuq+1D1FIpRJV20+bbCh9kQ4lD4ZiJN2YxflD 0MxKP4pB9BYrwDxnnhh+2rZZ5Iz+TSUV2u6UjU0drnpAfOgy3zVRvjrmjM1KHFZjKusgqpl0 TI8DEXQx0xCCEEw5ZJ6PQb2mN4EscBlRwrAaYQiMhl3vjbABbePDswlmGgghrw7FzTV+obkK BOVNKW9qmTclcifdBiOhOUuSMNkomic+08GF6qOPef4wEc6KMmQ6M2RQiwADwvAxAUbYgrbh 6t502bNuWfVIuhUoKVBaAkqDnnCWrvwFc9cMVMzmCP0UoHOBW8UJJ0OHf4FZwplQsCQsJX4Q lkcCGZUKyKnhpciXN1Y9/gw88tG7AAIvFe1R0Z42oz2DJY3JEckL/LrAfA88fsxmmupqFpco m0lA2i0CGpUQyXDGzCjy7eUh6ezNIpwDYtGpY1svWigE8OVHLxr7AaZBRS24MmpBn1lsNnFs cdqURN+V339JnanH3CcTExlr6SNV5dZg6f3zqUvWZth+Ki/jyqPlTyLWK+vgL2+P+n3FMCcC fMq/KXlBQGxlwF8OUoQD6Et7pbfUaTAJOUS2/mQ+qAnUK1M54piDtlXNxd1vl9pI92BuXP39 Rp0ZIXFQEnFSH1fLKSzn5UBOJjCdYxRNjJjJY+j8ADq5yu8R1WLSihBkTIIWldwesN0z2+jW 8J3bLrNMniWgvAG15Gqg6Lq/Nw1STSI0Kp3emSx0PgFm5DrP8IJqOUAqRaAU0rIUgZzJ4fbL 799+vYirJF9/xCiY8ZNuA5nEnJmCos6gKEF4LdF4jYViFoNGMANmpo9MTB430cS9S1E6ywyC dDbznx33UdDESiI6kwgb8dmWCIcoPkspQtNxse//YRqmvxhsL5xGTkOgUoRwauM723gk7VwH mwND1WrJTj1TFojofqRMipIXFEgmXGJ5q25ogcw9psERc8Y0bQoz78NCBbWQwkJ2Bjre3KRq W9H+a9sKQQaYV3iG7MRa0CZJArHL3qqyhQRVcWeywBsWhYPYtiBg8NzMQpzegzHyhtcqhSgR 9vHPdIRMMEHXFQ0iZZR0JhPmfacCQXXfr2gQSIGnBfMIOWR4DLVuji08lBKHklZL6uNqOQXt ezkQW/wltZZT54nxbiXNsZmm3OYVM45ATdyD8kSQ5bYVGEXxg5YpkgHh1gqVUjBT8oJazgQq FW/yN20EeBBIIJuqzjJudtWVevoGa8Y2Hc8UXWtxutajMnStB0m61mNF1xon/yxaamnaiIXd sR8yYkEJXeuxomstXs4qYaZFdU58x7LoWvkkvU3HwLgoKrpWRdcKedgmkW6mkF2wlyUOZKUS NN0w2EwsAJR8fXP5/oBBA4RfPGymPYPcI6BH5Y3sNmNjVstB2MKqpM5iq0iDFJG1xoRhQawy xUhIFIDYVA5k6C54d8aaaWu3V9cqP6zyw622jC4hCFu0jPIifstEXDVoHa0Zx1AwtVN5Blr3 acF0i6qyUkrGTlMfFzSNWs7Lgcjxk0dVGDRvvJIAqaUU4tKd2Uup4sS2rWfK7nAaMrKOOCUZ QmgoXmJUuPT1/I5InxSTwarKVUaWY4hVym3Lw7eL66h/RxnKylBu01Ae9gRYzVNPVFFJ4OQZ LmO2tpvwKpWuF1YSPwj6W4IZ1QI8Rb65MXceI6ENk1oJdZfppJFeheCNhgrLZ2LW1TWDub6e mMeiZKI7maDGGgOjvhNFaxK5a0w6wtJKD3UpMcGg/o8HZjNXMSKsjBEhq+K9MWlQHR4JczTl CJe8IEC6ws3L4RLStxjpARkm4egj7fbu21e1lKvxm5Ox08bARsL3dfft5is23n1SdftJJVMS fFIfV0dIOEKXwywWqJBtIeDHjTIKfM4EoRBvMyERVWsprGVnFnEWMrQNSTB7SRvBU+KElFGr Ox92gXZEn7fBK4FYjUDQ5A9h7VuXBoqWBKSURJhNCa6xtmu+ZW+5q6Q6OVbayRHuSEu1EWdv VOhWhW5bDd2WpIWLOMIECFSeZmf2SPdpxRgFXJBeVPxgmQM5U+5PyQvqRAkG3eVQzg/227fb u4irfWmCBJkHy6qUIeHcQ6AeKhQP57dpLCCeYNpSANsZwLYa8JbEoCIyK2XsKWOvVWNPTnjE IZXZnP4VoVBK1XLY29MeMKRM9HgVGnWGRsiSC3ZB28EG13yYoNredI351PN1VI95PASJcSgU kkLePj1yVYlDd+Lggqo70QPTtkjQcJy5vYADXrqBWo2IC61u074qdq9e7N65M+gyg0EdjLWJ DjYZcImgKQdVXFPdNmdzIi2nwUkCYClw6Awc9I4nJYHvzH9RJqsyWVs1WUVyq1Rpqcv+zQwf Je9QU8TJGEztSxYRKBTqDIXa00lnexrDuHXmalMQst6jD3RPQxUx1zqoIDVtkgRcVPpHCKR1 tvMJzd+2XQp1FyTDX7gh4gemcfi28Fd4gbHpM6WhlIZqVUMVJzpTvXmY4yhjDEriVIutD+3p KEmAN7c37/KPoDUPxe8JKn1ltiSFQtDtEg1TKdejWxamHhX5+sZyPBPfn+16mHIRZFiVnlJ6 qlU9tYTNIlYLbziWRV4VIsA+zcA2PGVUi8LZGS6h3oYcnE6BCdqKjGfgku3NMAWSwv4LYpNg /o7wPEpNdSYOI4y7QsRVWH6JGmxMT9EAQm8PlOFEv0U9eaBmMqeQSu3PuY6ZXC+QD+GBlDx0 Jg9hYbCw/I3Jg2rP67w97/Jjv3/0njhqXc8c31ywe31u+R92ej3xN9exSzRncXbN2TJnt/6L xfCvn3Trw86Xu99+vXYZmNtwWqFEQqZbDFD8iLDZ40f6TWHOZRC+4nvN8YedwckhPaA+9zEi +MPOL3Pb1l3tC6qsUDvjTOl3cLDQTDTo9Qf7/f5+/+huMDwdHp32ev8TPIOc+5CwI3iX+A35 ilS8IS1PnEpUfm/4pmcli/ZSHxdOIl4Gb3FG12Z8l7A0fF9juxddWtOtPup6q8EQXFm2Sm21 xFXXtMthcbYlNIOMceB8IkJGZ46bSn5u+v6f1NiOd7Qf8uOWddSHvV6NGzaz/50p7ydTHKrd mOKWiDZmNkbsDog4vXIraNAG1j5sOpYspi2KmyOX73Xx0B4/MGGpZSrwsdlnZtjr1xDhSmdm UOOGzZyZlB4seWG71OawN6yxI5VEgM816MJCkmAL1OZBT0TOVK4+FmHimZBX2OFwsG0y0LGV POx1ZiVLZUAUgBYzOKuo0l8kcaorrGv4S0lXbj2dvGGvYct//9tt4Pu51+4nmM0P5KaSOzns 1Tb5kw7jsFfTbIVpisfkjtvicaOf+N/cR91Yt27Yr2NlV9FP/To2kTJRmg/iDPt1jMZKIlDH JmpGBC4PRD4oLc9ECWud94h0AW0QvA9iy0yUfh2rsZIM1LGJmpGBpImSdHnLTF6TxzYolGg4 9hMTA0Jte/gJizq0koKxrzyNA7dfkOHiodHSLr4WDzdUN5nWMi467NextSudnDrmWDMnp6RL n/q4IHiwnTY8zNOvY7ZWEoE6Rm0zInB5IFKY5SrQAP+0B8cZR5niLROBQddm9GD1ZnRSfwpb KtFvlSryFrqsyB0aK3YIMjnoeM6YoiA8yOYD2KBrD2Cweg+gS+n1HN5OL0iN5IA0Jr4We2IW aLTvtX+bSPm7vHl7phuPzNcsx8NkvW2zxAYd+DCbG+gZ1HG4qhgpgzqGcTNGSvKMf3V8dqr9 EjNDYglPjvemp43ZPea30WTBxHltLQUaPObV3bf9O+2GUZc9s1E3A+p97fLtUa/3Flf1EEOS TmrLD8VRJEIQLM5U/6ENer3kU6Rc5epUS9OlpffN8iuh8kk7OfkvLYDGBCi26RTzXY9tbLDU MYTWsN79/0Ifq+7N3VThb8sb74D6Bd2VIJ4lmlOtr6Gndo4WOnHnt8D0qeNNV4LFOs5iM7CY 8sdLXhBwMVcEjo8PL4IawWQRY/gbeqH2Kxbl0TnS52F6J12Xp56+gWrRxtd+7WhiUsovZ2Rp ten1XxxrOmLuA9reMRrJEg33Mo5Epdvn5/g//5iZGC+oXYAQhh5SG5zswUToJ8JD/7xGsbHW P/7fJHjwYzdynMep7j7y8ECUDR7wKJetT2kaAf71fv8krFuOKmUphS4/pGsnKEVV9r01Rl7c xVuG/+/uZYY1GLEH06YVAGgFX8XVQZDylh8zHl713TsqTP0xtTIYS7/84/rzza9XX/+q7exo 3y1tsdpc2SM4G/zr8jeWvIjHQBiDunDZu4hS+gUv72Kk8mOw+ehIoyFhQV37Jf8T/GIeXbQd m391XsWpvPlYkM9ooZevseRVYcjH3zKSc3j5eFpe8wApD7Z0qf4JSkaOBsOTQ34ykip1hfIu L+kYlg2MHt/1eqe9Ae8QCOU7FPmoWiSQw0hrB1tDEsHXQ1ik2PkQZerBZS+B1IjnJuc9ysZb M96DP47QlxE9B53o8IUyqkwohXhlI4YDhv/9C/QIg3Mt9efm7tP+H2yUuh5c+MscI8kJlQXx JuuHHmoWrV4GoAoLGn0ulopboSGXs1tlA5oZu7VU6rZ39cpGZ+usXgSJguof8lBeoPo99B8j FLJ/+HYYHNk8aY0J5grhMIL8BEZJ4Wgy7GehUXAN4Q7j76DV8yY4fbybqxf//oWRgN8WNxdE OKx3/4WBUNS8iO9oEROjyYeV6OlaJskIUPF8Ovrk8b8FA6XH/wQbWdZAOYPEC3AtWiOFVyVS Lgv5SErKciMF55G/W9yCLXz/Z5icS0TYP3uraefXVwjH/jmHO4EAqC/GAYuAbezwr1ArxQ8n PXUEAssU7dY8/VoDr2jvxfdK7hJo2s3nv+1fXbzaVhefbz/dXF3fXf3+VTihJaV0C1eqZCgx 9XG1nDNEU2gI5c4Z5O08o0yVrHzCyt9o9gWCTzQHjLIEaMumZAYIO9QiCov4em6D/ycsjyR8 VqlQJVbnWOQeiAKk1WoVgKJ+FO+RU7VEQyRJEhA3mZqelxzhrUCqM4FI1dhmxoobkwMi5jcQ L3X1gKt/ahquM5sgHoafPWS0Z3Mf+e0nE1XsbwUJVTKR0kQlL6jlFDD3PBH/p/6K5YpLe2Yj tZDCQnaGVStUXqgPBl+MpU2c58UwiQdmA8eShGcKpzqTh45JnAXlxCceQ5uNlZYS2QZLKqXU xxW4CuB6Ls485U0MSks9RIFmtkg3B1k2WQI5iUkttvuvgZaCg40KakO3NBeRU0xIw7AJxXuY IMhLioQAPE363Kvgf9jl22+9aAsjZWG20ADHrEdShktnEhGNpioico253vfgO9R0PhZZTWpP YEHKCil5QdhIdZDOxXHIymipVuiVxKPtNFpM2/RNYmgmni1lqaC9gqpJ4ymWpBwIaNO8pfIu sA6K3KUx5YSWohmCwMipE9ljoKWUZy2KQUmdlPq4sKFKSZ2LA6aVklJKSlIeBkSK4r/kWQdj G5G+RO+Jtms4Y2a8UWdrNRqr4/QlWEEp5htVMUR+NJkufkOKa7PrwrawXihpfX39/e7zKdcW QT8s+AsidBizGWxYUBrY2vOEAStchQsrwoVEiZHESm7QfoUWwNiZB4d8GeqLR2t0QLhPY8bj hS9KJFYjEo54GNuWCLIUUCsQZ5ZTDo1yaFqcmncujh9XDo1yaOQODR9LHuglwZ+BW6MU1GoU VFZSrm0tJTouGho3iYcrdHEz4oAqbJR0B4TTItmuSqXaE13sL5J8d2Mm7AizGmlcoj6y0Mmn CpuSUfhUPLXkBUFQ1Dk6F0fRF7BW1AKuRi+ZNsU6kZkTNqBtOMrwn4gqMoyrqB6i1WUJFzqC emA7lQma7RzGXLVn05+EiULtOaEqFbp2ZqV4c4MGTtzPrW4lwdVsx1cBFRVQaTOgciweozvV IVSl91NcRPqpCFRU8plWWHs9Bffou7lNf70qKbS4Kid6lRVNi7qiXU/M0TdmvoIX5I8JPOeF YYLEjxhVEaRdmSZJOBCWR7ItlcCAjmKRL28sgoLYiT8HA/Xc8zVUCkTeGhF18wSggoJVQsFK iu7D1C/Ns1LGqjJW2zRWT0RgVcbqqTJWM8l0qZwRjP3Emx8vul9YMILOLGmvbHb1mnp6xkn0 xubTFdH/ci7HQe/98QGGCEYEe0GjrfxskcRUYJRbu8rBTCIciSEqMg1GnLlL6g/Otoc0/aQE afqQj/mJkaZjMh2Xum1gTZUfCym3Zcek6TQHkBB+wYl6Rj+VYmtvg6FU4CTdAtJ0SDmEuqT2 XDsMlLOpFsW4lbGCbw1Z6WYbJWst0nlovQZMIh03t6iuSy8jPlWyyif18Tre1BYenvN+T4hT qDCFClNkz/xZhCngiFGJAVEDEHfNgtJInawow8CJmIVjhR+E5Wkyr5JgkpJ8dWNZlUViLQrg azEmGxVUV0H1NoPqfZHdfLm2Ek7dNrl/a24rr0+RKipUUQ2g5GA1yikjx962goqpI+r6tR1w L9oP6KOJFJZSUkpJtaqkRCZzpaR43moNqWHXTElNzIeJ0lOr0VOW43Xb3kdM9WAmMYy5qkRK 8OulYnYlL6gzJJyh877IWb5cH/FKFDVYI9lx2llEZ4Vl83Trl6WxKoxntCxJ7UWuY3qGkD4Y eSzzP5yVRzipGX4Bv09jkSt2f4/JsMRoKdxXRQW6E+z52BQXP2PTH1x92tieB/6nml2lVOyH Vl0+kWFbqViVRZNm0cbMhxriNlbAWIh2FD0FjEordaaVQh0hGAWN6aUzFW1U0cZWVY/Im61U j1I9UtWjj/9NzZA+Gk2U6jldg5JCpXqKtq9ENfHLPv+cs60l44ipjwsWgjLQzvsiw6lSPUr1 SFXP1PwReDkRSb+yi5Vd3KpdLBIaXoL7henGJOIrWwxi3OPmUHyGq4J5IX/UmR+OwuInc9wt R4iOyQBj8OaZ9yYqhPwJRsigZkjnJGrmyGLhsAAlEqsRidYzYaALIrMlJgO/fbu9I7qYVxlQ m7+izbe8bpNF4FWNKCyDWkHqceCYEPhpvN+B5ENJxGokYtStcpjb5p9zprnMQrb6CQQdGIVo WZqD+IkikjvN6s7rzFZ4Bexuy7aQq8HEMbIKGAhvIQYz3fVflC+jfJlWfRmR+VQaaKFJEQbG XJnelM/EC0f4KnW1GnWF9khh6RtLKkrmyLwaLabnQGdhMuLY9AwXCWfNmMztRxSc3mtj3dcV YCnAahWwRPY7KWBNmW57i/GdquT0pys5NTFj3qBp8zCmNP9lxgiheDWM5pkPti7S2KucS9LA 3i2iYCpW6jLYEkW+vnyx5tlesMdvuMdNtU9hWBa00Fnj7tW+J/e9yL5U2vYuGLqFh1d7m8oz l7ygllMw788HPeG0XPmvFODo8uJRfY47CP3bJs0HRtiPIn9qHYV1FBYRPwjLI3FlKkGOy7yZ Y48T07kldyivbCTOEmX8YukFCu6ljBExtqSQqjOR6JjTJhi5OmH/x8McK8viYX/EepEFnCEf aEMnJsetKVnoTBZarZGTgAPpB04c4jHfJ3GYz5AZMhzbRuk+jZPf5T7KnoCJJWVis4kk1dMr bm6o6KAcU3Fzw4bRLpjBpiPkhAYne9qg1xdpQLR/XusPDNfLcHO/3wHte5ybu6+4uUMi51IU 2Qt2bQnef/nH9eebX6++/lXb2dG+W9rODHu1P+grbu7iddcSGnJmj+M7NnKcx6nuPsKOh2ib 4w87w+F7xc2NsvUzxc1N5pQbDauI/j77v9AzkBXXM8c3H3Z6vdD0iC5tDbP4FtILd+YkUOFo S8ViCFbzip83QakgJSl4HjXtNNbxBtTm7xDxQ6UAUoLQo+3IURgXMFA7THWimjcfwU2kxFWU xHqVDyUSq4kpYieEpW9bJkau8+zB9KficSobp1JBHj5SlRaq0qLNSotBWUZkAinhaJQMWylF VV1RxfINwha0jU6ERt4jV08RUFGEc8bcqYmMmGMLT6MEojOztWPLhewTqgdkNgowMHXS9XUi n3GZriGm/fpbJQ6rsVocV1j5tmHhmdrdYnIA7j8qxqL8BupGZ5b+AkOWy4XwWAofOsOH4LAK q9+2UOgeMp6zOVhCoqIsxZ6n2PNaZc8biJmSO2ipeD+2FjYGo7khVi0sHAoFSZ1B0gptWNDB Gub9i+axJ+bqlnZ79+0r9WS+S+hNJQ1Jabj7dvMVy+Zi3Yj/lnrYVGBCBSZaDUxUYR1XoL4a x2MNQJ28z5lrOq7pvwCilCSsThJehMVv2+GgSJQz9x8cqrMLi/0404JqVNSNZENYydaA1MeF nVV20vmgIHG36qyGsPDSjDyCxaTZKUibBEcqZXxX11l9b1pMBURUQKTdgIjI6SzrYCKTKWa5 KaspqS07wyOX3btIpRTBu8YamPicS/Zj5vBR3CQLV9eaPh6jFFn1LSnfvlXfvgrxr3A4lOnZ GTbFNISwBRJ7rDF8QpjRGfEEM2GT5yOx6Pmm4Wm7nFCNidw4SiA6E4hEcKV1OXCRtZk5ro+a AxT9G45loYkO3EQgUSPJCCtS3gjCqcShM3GwGRsnDmPrIuFoDFgwJeKXP+cYB4iQH8pnKUFh Gioz0b13NRxcDD5Srxlvsoh3VAi/uebtF8El3pYRtv/d+i+oeX0+5YOev9z99us1DGLHxf7i nIcda2io+ohCo8eP9JvCvZNo3ML3Bm1CR/SA+tyfOO6HnV/mtq272hcMokTM0JnS7xAwhAdA nXf7/f5+/+huMDwdHpz2ev8TPIN8NCXBTfAu8Rse17ghLU/QohZ8r/zeeQGV84HIYn4HvMxM jcfiUwGfVhJN8V5ndG2WbqcRtvhmTTf/pMZevKN3lm9A5uYf9GrcsJnN70wDgDFyTKQHgsy0 rQOABdY+dABq5dkPlKFNHU62TJYifjVNx9g2XIIP0ExaAb4OK8PXwaDGDZuR4FT6oeQFQSBx THNE4Pjw4uSQXpg02AWzYpoqvCggW/BxjoWt67Axs/AIXIcdDCvtSSkdlg3ywvqsbCmWg3D0 9FGfME8PLJbvgJYv6If3AiaOfd48DLCKdjm/Q3StuxdcwY6aoP1cormeQb7NjL8T0e8E783N rl7YRB0maSTd2CP2YNrRJ5OHvMn746j67h0he/ZIoFTH/et+cqapxb/nVkuq2b/JR5UslcfA 7Q2LsthqfUFbqAsl+hjs2Yjv3OiTx/+Gz0uEMuFG9ehP8LF5dNF2bH6jPDuFesTfC5AompiF 1wRnLF9KlvfsHxwELxA3cQvfv4D4+hjMoV2dfz3XPjk2EB31flSXXiuwvdmUNWuNXHJcz/Nu 7j5eCOIcYX9BLN/s/VzTp8/Wu9yyEvXuUQAABfdqraW3SeCSKJP117uIrtBhVHoXrgNbmEiB c+CfHQlAtUK9e9iB3r1lxpyXYW697s1GuxjrVmSVHr3dIuatBN4NV+xn1Lr/Aq/K+hm0oxUQ r9bDSpTDWnoaWJ/imCdflSZ8jdDFz/E15Pcv7GvYyCKM55zdU3jvn8ooXWszrZqTca5NkWA0 TGeOTFKC83lqPkx8PtArloim/ij48pS/AqWjbaoZFIl85O/32m2QqdV2L36/faMhzacbNFzI 1r6e36F9GMVwiP7gMM1dBvYs1PfbWFLQ44wZJXjTsf2MrJQ0YLmNMopJl8TIsExSPRQf276F 4XMopxlZFP2LOidqURFv4ZIKGC7JZW1E6XmChXwvyo/RmQIDmW4hWzaOSQQKa155qms1ea5p hGIbIg7VVNlH3cPuBowcryOLx6ibCf011/QePRpoDhqy0HPhhPbAXTBJmInxqSUtGwUScQM0 dwfPoh0pgkKNFVzi2Mci5YupahHjExXfJQygnxgeNhvc1NMXriCTH1TCP4rvbToOKvb94uz7 /RLs+we84DDOvj/YnpyH/Fg8n0rCVLk5jLzvKx2jC9j3Ub9EZ3Pxr7MrAfJuLHmRWvE2IZd/ yf8EUlE2ly8JWCZMhqI2h+RVC2TyeSJv0zEwvkxiePvBZS/BBuVJimLfR6EKhGAL2fezczy8 tjuR0X67RfguHoJJrQC5BFty9UGT919oAAlkSmvJjrCjRXRIkw8rWaxaOmfUUjUZ1idH3RRe lQg3pJZDAS10HGC0HMfriTCvJ/sYkrRvfVr75w2RUYNMFPBAEAzt8UGvIeV0XIemhIBF0kDD g+lNg0aZh2jCH7rPhMOwTSZRrukjQdUWJ75SpAqJDGG5JTH6xqJjAethmIHS4DE6cxepKEzv MCZgR9cMfYoiU96iOjUN15lNUJL7EwfItjDcWx4ckMpEGpiIyShBDNZMBREis0aRI1wpzeaD m7zIlzeGD0FquigwEGk+Et0kEsJTKqWxuyMsiATWK8nExGlJJM523iik76YZTm6J0NEJym3j ToD887mdBaXNQMJ2To3sokTFA6+WPRbkWB1sYTmaPNZg87aLfHljUI957jOL+QyFNNht55FR xQQZpCE19jIjUXhYJRjCcjQpGMkzKPnuxuRC2f2YrqrsftQrqqDATxUUIOcuGLWj7WL3X0ci oQOYD/Y0/TdUxioOTBJwT6kBYTkkUF3J7F8VgV1iBlYkIYgVBbEjXmElYyspU9G82dU8SmEA GVSgiDttMraHFmPJnQeKXpXFnsb1Ay64DPR1pDlQkB2bosfLcMFph/ghUEMXEFIpDGE5mlQY ASYX+frGXIdQI+zuIEalgknnOyqYpIJJeQG6IoezkrG4fsGkfH0hLITSCcJyNKkTYmq5yD0a UwwJEyDs3go9CJV0+Hn1BJKHjgteK4o5656HTlnkmBM5T4UHRc5qJT0R+u1Fvr8xLKCcMWkD FJbAOsD/cTHPdGZS4sG0fWaDhpukAVeZ+aRqT35iI5KQAK29lvMcCArPTgqyqqBBWI4mTYWO 5yNgJi8NNeZbzm3FgP84goGxNtGfmGY7vjZC8SIqF2dzC7SUY233cnio6ha2FiVoLgN3Ipm9 sA5QvDo2dQ1GJckDpayDoRpceEK9oeoWOipR43tRBIUaMyDCfXfJVHDZeE+b275pcVMCJqRj mBwXAtPmlSNkSgZGMpeu9EeRnatkWhKdvjfRH8XKQImGakw2UN5usDHcCNAcmf4ktC+nDkas cOodrkVGjNlU8YzCZ+9+blnipF8lE63JxL1JXN1tjdk5U4GEbQ0kZFoBr2aiZrMHxwfugxyb OlxCCBDkWB1rYTkkQFwJ6uHRF/nuxkA+sPqA4UgnBtx0WoqNDWPVHAiIq0Htm75Zk21tTWsT spt6+ZCgZFPvMOgs3IaeuMIdmQVYLyV9qpvQ1IshKnTqFm3BZ/QTrz8I/iesIhenabTRAb2m Tb3DBCZVWhVa0mAhJZICJ4ROVrT00YkE1mGoRTDt5qSDpl4+Di1Wc6Gaey2fZuBsaVlWgsGM QiHxJt8wVkLx0kVRPzItiJSMeRWO6upIkLkmoKIMl1Rua85ZEI3qeqpcEB9TRZmbZLYd8lGL otkW0kFsodH2c071At0OIU05k62NpVpLk+04gcI5Bpt8TRow2HASOdNMpfsX8Dk4C8v5eAy3 1LF1i7qn9w2Q2qqxXtsUvrpFDZ6L3dUzNjpIZvIwNNorjLkHRmNMejtH6yWRFs8cFEIIhwFS /fO0Uqyp1i6ohTf76dfOXypjiouBoaKUh18cazpi7sOexqjaREwiSMKkmaHMSreXdhjyudef f8zM4rSugxK0rod8EHOc1nWLIoR5PpkkjpMb8cv7voUxJ9nJFC1fQOtaLHqXd2PJi9Qy7baN 1hVSHgTnlmrPa5fCRecfe71DPjGcBmjHB0R3CowIOX5C/vyBRTHE4Jn0uT9x8Jy/zG1bd7Uv zLLg4ztTGgc9RtHDh51Brz/Y7/f3+8d3vd7poMfHppNVFQYx5fIU2M3BXYNwZkQKHsaRcQ++ JsJCxb5ahn7pdyk7/VvyLrIbln1HGih8hcJT12b+/oWr3/scesX/ubn7tE8x1uw/f5nbTKO1 L220CasZLfEFu9fnQfyyU2sivVV80vjqxK6I2bvmK8hnxq73CsbErVOUyz2oEQlSdCaEbY7D Tgoq+dzK7ld8JX1eyHAnqNfKGKzyDZC/zCJYwbnfKBNv2oY1p6J9ZONd9uccBiuvtUNxnsmb fhf/pDQ6rrVkxoSwykK22AwOtkZhqduWibF5f49KTNRXYgqXBxIpbdfCKDwN3eBjx5iTNPDS HAzBQ0zE0uFJU20e+2F6fjI1UgTylVhUKtPJPoeNCcfZnhbtekAk5s29N4hqXYIRIOIaQ8sP b+UgarlFXEyQVbX/wnJIdmcd91/i/1K7F2Y0UqvGiKGV51R4P7XdfRwR7VuUAgCCPuguz9K/ oqpn+nMOoChqnqDsbcQoi2/aTyatKnVOqjWdIUyGcaxs5yxy0dpjYEWqxkPqRlh0yUHNDBTm mgtnOwhEvn14uyBwd2bM3hN+0kZzamUI6hsxAlV4EHWiuAAIayLZnEooqmM49lNL9a5QoRFt P+16sM/8fjjtKN/hYvf6GcNykDja097ij/C+Sga4DOz+hpnME/as/VWf36Nn8M1/a4t0G8Y1 81y8HwS7yJhPpRq8GSJslYQE9Vmubwh7Ivv+8gghUbRTxpQ1bSAIKqiCAanXzyf9vrZ7jaCa 9pHp86ljg8kwsTvgNQwCnBQHvvzY7x+93yGpkITZ0/mCjH8fXQqCF8fDwcXgI//SzHDs/rfb sPAgFdPgM/hKxDSO7gbD08H7ePg3LFKNvvo1xhurR5FIViyFMfH92em7d8/Pz29N5t+/ddyH d1PdtPZ115gAF99B8t9B9OkvjOMlp/Dd1HugqPrh24k/teQVMNFiFVv/WmmOfAVc6B0LSk+4 0WKs+svLDG6waT8G2533NBLpQyFnmNhAkYpC+yyNL5zno8Hw5PCk+nkO/30kosF5jn1p2fPM 566VOM88BdIbbOx5ji2VRKKzznMphVz5iPlnAV4lTnT2zTO1dY1bZ4Nk4lFkotwFuEApFg10 wnq9d4itA07pfKahA+vWZzPkMbU/GHKZYkxSgdaQLJNfHQM1YjfMAAtSWJqPn3i/MkrHw4u7 f3Em9ptT7SKqFQM3878sx/+XICdqRbPUQOoYP7j6tJJN35bDLzG6qLuVLCsePENEXdhrmTNR 6cXqwl+e/SKjwkWu6BnOFeWMZvORZRr77b3fCpyxlHeREsPqvqV1Pn+Ye2J9qEweMtVVpf1S LUMJx5KDzS2b+YyqB6n6gyK56LszXAxVoS70mePp1mmun7ncLsr3M5u2S3nr8CbbpX20/JXw M5evf5ZdGreIath+WX5mAgVXafkpeyLLnpDtiMSt6fT4vuctZOr4jlHG6N4hyPJhp8Xjmwp7 Jc5uKZVfA0bqmm81bi14rwvoTayD7MSsmfcqMcN3Uc0E9qg3RB2mccQWXk+BJAfJKhHho+EB 19RqPYWEBV/Ppd5eZS/WooCDsOQZvgN9e3nX4eyN8L3qaBzw3BMGaj8w23jRdE44x+clIQ2p jyzEyXY/ou4cBR9JL6GU8sh16M7OR85ILBDJ2HHujpbf8mzQTHm/ggpYs9zae94IVcJoWr/c 2sHRcQmfZ/n6t2g0hT6PABQIMUeJlUTurwsTQcHUero5klT4e96dVeK4rl/qrNxxXWmIonye P3q5vBMeeyV1wlHJ+Xz6pFsfdpgd5fQTrXdFE3DZ2hjH+5AMkU/WnL1yTbSZULhxbDOx/9n2 TFMGh/YZw7M3y+oo2wTZttXhO47lvdb0UKnOu82p1cl6+oQEKhtj0Ht/fDDsvz9YqFYCFrnz QJZR2PxbG4HW08aQV9xhkQDL62Bm3JsWQ8Xdu0+n37+jTcD1vn8P+r+/f78Im6tw6V+/T23T d9x9z0egCg7l9+9Xn+8uv39H4/Ifnz9+/z6mxuZ9qtnbR7se2/eZxXjcwTbY/qIzaL8Hb4gO zoLV4LU8VjhAMRUuiXxnOREpLZATxqgRliz8rgmIyHy8Vx0Vd1Ji769MmC5MmPdkwizbr+pJ 9RsHdUqFvv5VHmqC4rK75ZwNOWYTmQFmYmiG63gin1hG0KdamE9iZe5+mlsWehb+wmwblUwe iu0TbygAyPIoRH7qLPz30ZmsW2H9vmyfftv2WHnPazgYblgUSHjHgsKi0LYLtN04c60S6cNa FVSXO74x+6OE/dVQ4YrKfJ8Jme9etHd5GBbbMYVhXWDYEVmMtwxdSKb/ohk68nD6u5GOsvTE NmWa/ZUqadFYRk5Yke9vzIycezp4whK3XGtTawua2Q6UqRUEkfI8EYliYqp3LcVVkHd8Y4pD sqL5nlL470VPKfaloTYSdzInMrYFvWuljm9sqSTrnxXqUqaW0DhWI5onmlqH4d4VPDHK1OrC 1DomU+tXHXVO2hTEleZMd2FyhXwVG2WblG2AWL8w0OGwt8lhoGW+pcyyVQe9i4O+NC60ZmHd o7IdET/neU55wHmJlBqqfF1aFXoRSOZZETFRVuDSBbic8ColHV3BBmhj0FNZcHckVnm+V9Rw /uho46uIDwa9jQ5qpAyHAGwW3kNBYVJHvYujvnF2RNmq47WzIzbpeBNh2OJ51bnFcA/z6Yrm CfMy4VWW8fV70NGfSTnPXBMkzjMH1B0Yrr5RqnrdSm+FMohlaiw4G0f9rfLxQ1WtjvoaHfWN U9FlK3bXUEV3cKxTrn5OmWENTz/O/XkwCN8rcb4zH+U1Lx4lrFRP4Arq9TmZ0a/O834wueFH PK5P3jlNNrWd8UYVHhxtfI3nwcFmB/cTAKBi+au05Zcq+OWJ7/wQW8OFB+DjhkpYh5acLOKu QnZ7ueO7fP1V4cGpH9A8EVP/q+kQ68yoYcMsQofc54r2Lg/DYjum4ohdxBH7RO//22vJgWCa +BPMeMA4dRpSh6wC5yXGsJwxM8zZZMPSCxtfM3lwcHi0YTGLvJOukoNgbQmag8XCwbYoDNbT Wll4ZuK45qONr5EseVxjik+SjW3RVCkfP42wKO+Ex15J6fJOdDkR4n+2iReNz4vUbXRtOE4w LNTBxLNg7B3//aaq8Y0vLzw4eL9pqYe8Q67UuFLjIe8SXwhRjR+XrR5cO66xksc1pvM2Qo2H WJR3wmOvtIZq/Pj48OLkcIfiFSHVzuzWf4ECDHP9X+5++/XaZRjoPcUoQ8aHfuGj6Pj7iFHb jx/pNwyT3RrKG5bkQlzTpx85zuNUdx95CydW0hx/2Bke8wI9G12gRAqOmZqOvX8SmO+wMF4n /4XvFF3alFHjYphrMugHr5b2zZ5PUdtr/F23TW8SSVkv7rSVmHgoDbPVu/+Ce0jCNBIbR7ij fbe02H7yOpTFv49xF7X0qG2g5Iif59Enj/9tOBbmp4dw0ON/gq2dRxdtx2ay3caBDlHPPztJ wmSVNXn9QsmrC92dz6fRWURsFs8bnUT+ZvIOuXri45/Bjzg3Hm3nGQzLD2yKdKVIhbMdMLcN sJXGp1cBk42O0rQLjJT7OHdt5vvaBBOkXPZkMpo6Rxz9qCrA4B36QcOINM251/wJ8RHhL4SD mQ2eJ4PVkof3vffn/fO1Udo44rGTXG1FE9CQWZlRiREBU8yKfHdm6qbKq4wdY04HntICjhdt v8fFZMRAT2XamKo3c1wd1hQN1YbsaPu9w7fCUyqAWJ0N2oQ4i3Mn+eZDpJ/McRwWQHp4j4HQ pj1DbImQ456x8Ug3Hvcwla6OOCh8KAxIZzQEUFjrtmnqoC7YmEhaTFQwobiJWwfq9JMGWQcP tInTv0ye8pobc3XO2RcddW/jQt/fmEYrdLdKuvncemIeKvkSox0zTiBfscbeiLD2Dkjc3pth n8bmUsOj2bea6E986mOgZSJkERSL8MIlbQylVIorlRVM6uWUwz+xGlnTUGBBH3mzn37toKGM +ygGLh9c9lIklvXFsWjq7sOexqi2Szx4GQpMynRc6faSuCQvUUEK+8fMBMGXdsGMcDTwyR6N Bx6Evw//+uc18fYNhv+bqRWiuJkYw+ZdqEEMm3IA+4OQyr+gmK+doBSFdEmsMV1+XDAQsogQ S3YyFWGOVrtIfDnPhJS8SK3iGCFCfMn/VIsQSxZDkM/i9rnkVVmc/S87Pjygx98m86gSyJxd UZstYpz7FzS6QQQP/hNGO+z/wUYZv6FLf5nbgBfAjrB/JZd1sxXjZj/9xqK1PHAviGKGmlae OSkw/2yVnnlijAOCp3G/Vh8jeIbcOYJnNDRG2NCS2PITyndOr22e1eCfGTrIFIXFzjg9UiM3 /7tF47nkJiqIbbD8prhxJYfYO+Q3H7V/OHMNNbLsibkvKA+gRBcycVowDIqHvedgKn8JcqLC CReErKQwqBNd1KHBiQ5TD8J6N3eo9xbZLB6BNKeU/+KlEGGCXLc8zQmkgseuIBSwN5E4FR6o pABsNhqs6dNnhwI4iY1YztbndVyQIVTauJ45viHmhPClokuqnm2iu3e8ZzQ3eiC6bPUKkkpH G6L6RGxokYBDk88q8dprBShGLRW09XsCVonas/CiAOLCEjnJuxeIWAyDgEsc/Qvfv0BBJq9o C0vTf3UehLf+qRB6Cw2Mf95cftI+X1zd/X6jff397vOpdm0xWPsoTJpCY1PxmgcmdV6wrD1P UME0m48sFO+ipi07dFwQ/tdU2xV8+i2UhOCAe9q960yTuXEZU4oEstKqLdL/MTKl6FLd0YnH a0O81fyo3ICYLjYfF7UL+y77c44MD68c2u+h1ZcAeaHkeeg60ATRCscWneI7kk2rpWPzXXxu 4QfDf4u8kaBgoB4l76H6aZa1xZZUzlsIaglRKpMZzhdpR9MCwFxajlUtLCZJhu0whEO9MWrM Z1DAOxRk2XkGGPh6eIGKm9CwxVyGMvNUjZPsKEkgoVscXxt6tIZw3L03Bsc9aKe1x2fYgPSk icMiE5YucFd0pvKPYq2QkcK8uNeYv9DAvBvuFXSLeabN+08twrWkYZoC9OopvGc2gnHyL1hX iXOQfY/y5ahn/x3Eu/8/e1fbnLaSpf9KFx92kiqDETh+u2VqSRxizyS5LtuZ7O54akoI2Wgs JK4k7Ov59fucloRpUIMkJAxK50sS4iB19+nz+pznxD0ir00heh9qG3lycV+V9QaMYNVZ5C5p 9V/SfHX2U5YYbip//Gx/WrmedeV31aKKBR3//KKUb208O05z1f7nllco3+4ADURpHlCY1FKN nWq/lPnxTBRsTCq7e8Rq1zeRAqIux97PUK25jv0S8tyJlWKlxspUY8QFWo5IwFwNTM96QhQB m4iGxl77SN32zd32twgve60D5tvWwzCwX35j337c3Nb/6yH4jd1c/P7j6/ke6vi4/dS5WtOf dMsmLqyakonNycTmLYDODFuHzueZhhvU8UEOQy1GboziMHTCY6FE4D1Zhlljvv6CzAQ3CYJe UmagTDOw6T736LgJzEHS4LGRC0CP6xHNgcn+mOg2wXtAfhD9IHqa4SxE9kTJheAyppCL+ahg ISTN7VbCtIvuWgIGSIwZEp9dmMfZax9zUem2DtcyLKq8uGXAwJ0tL2al/S9trk9BaelsxTgQ f5O6rlB58UgwP6q8eFbLOwVEuXRzopRoGnNxI7xJtqfGfTQ90Jn5pwEc9wPceRQYNcT+pS0U XWaeO5hwfJFo8BMckZlSqpK90o7kjco8AICb3PXzX8CKE3iWwb53b0M40kFDY7OSske1IJOi DVfYBiUVi8GErIy7FTX/rZkrUpBzhZr/wdFxqU5TFiMjooAvgDv3bMt5DOHCy4u9wATQSoTr 9bbOUgZMgKQIR16sqQ+UnTmLSMehL2N+VsmWlWj638THCcw/wcrogIgTyWtKVM4J+MLtmk+9 pIdLoPnNun+xwgRpqscUlkXhrKOgG6Vk3Ah8czrHGmAQlfAaylouWsuF88+dWSO6T2G7lzu0 62u3EUi1xxObM4v2UYp1eOslHPhpFbcWJfD/zhP4n9ACiDbMBPlUggHBuIkqGntx2npaBv0g HKvaLGE7JFK+O1FwbCE4XzMp0L7nPqOMwfyhO7GpGP5vtMNEavXdAOHy+xAAASpoYSeUYFRK vRqYeIHS977l0PnjDyN3YN1bKIZD2YIEvx54E7iXYADXveBF1BpKLuYrXr32odoUYVOE7aiM Fp362aRJ0aRACUXkbjwdlBC80wwE6CaqxfDEL6+ELVDqs0z1CSIdwBZFgyURusKikpSu6KLn peRC0BRlygVB/YTtLlsoWLel/OkqI8jSRJ/xlWfPVjBklIsVZFCZgjKvfFzsE7a85Gtfe/WP Vz02fwIuO7YpdXJPki3ttdsReulAWJYSYGE7JMK1OzmCsWdhgkeIcAzRsBhkYOojKkiy2oVr PJov7AHD/oCVxWQor0Y5OEadFHvCRii5KFOxwcfdcL/MrFxQZoiLA1IDiG/MUB5ia7iVClCJ I8Sx1z6IdHhb3VUh7hC2o2AdfrnZWkmv1dpjNcpJXP79usbCLpeazs5vv/VYH3p6wP9BDIXU 9ShTAn6MoTE3rK9XrWct3zPVlxeWXOm12mRt0K1DVeewIgEHeMoUxPyJMcRkOQJVCW+mpLpM HyTwQNji+fpGp8ztlYhqGHuBG9LBCVKUYA7EtpF1QyueLBbYbwAChMLgxLGea1Ny2bbmWKqV bJcp2+DwFeGXCUIwA9ldH+EA/UZeNX3nWpZZNQep5iDOULw29yDY955P9UkwdL2z2peJ4+ge u8BMUaQD3BH9G/k01GGhteqaVteq1RyE1igyAhVqDhKL0tBYinuweXh80NYOo1FfEVxUjh0m k3sFY5/R9O62St7tt986DrQsIEwR4v7rDfA7SGZhTmbtPyGTNDvA70PYClB11uPUvS7lDvAD w6XMXqZ8sGQha3H3Vm6A3wkJdUb7s3U6cDZezqfj1AA/EgLusPySTslWi7TcgcQAOkl1vdxe pGtAFUfAIZLQBFx/8CuY6IsUlrVFo46QpH3X0y+1qBzRa2vv9xh90pp+0nrPa1PvutMfE163 Skovn4Qg39Vttd6vsyvKmVfZoUKyQyeYn/QLZ4eWeLuSrEoZ3u1SNdLJRoYjAlVVdkhRx1DY tlTC3sSV2TxNZAxrYrUH2+1jOu88QeBW4p3Wr0jpvu8a1gJuQflhZdYdCSQuOHhl1x19GmQL ob65/fF9//bH9Xcu3ijrC2+hDl3YDsmh7A7I91WnYS6t6QHbCQyvDlSDEfibUmerdrRYjMWr NuONGMLDlXSXqdLiNklhyyU3qLDkA8EfHTN4dr3HVyJfYCz8CaA0L1zb8WyD0nhv4sXdDsUu qLLFQUhEcbgV79nt0xhQHdMfLj99ZqT90PRucLkA/7tpzyE2lZooU03ohuF6AyQp7SzTa9SZ pFGreR2TGxOEDwsRQNmXla6mcGHHQ4/D1m3r0WToJ3UNtHdTW32M+x3rjmo+Ehtty7yqI+vP NFJXmDEPBz86oNivMcxLY/pkYLmECO+br1p71RtxdzLXRYAsitFQwgUo1lkFiVt5y/HHGGsB Wor/8OkWqZ6T/SQ76j5u7j7aiOE3CsIHQ5TuT8I5zXuMP57pg3+DI4gmN3MHCjqCNPS7geUb E5+ajiDU0OyCvCnrXaaaxij7YKXiKhTEbjnqeIW2wsXjlaFuJfWhjY4pPtG2pahHo99O9/ef n58blhncN1zvYX+EqVx13TOGmNu2j4mm++G89X1j4mEidLA/8h+awPIeN4bByJaj0bamPrf2 GoW7tlMVuwrCdxZveiK6JpcDCv937qwTvzu7lybJ/cw9bKtVVmvLVBY3uo3nNldZ3VBb+ftX EzAyG/tj/ls9HMe8j84ZDRH2flNrtnZMaeVYZUqhipowRFhoBnZ3iR01nUGEnM3ev/FLaKut vuRtdcnpfCLZvsWsg7PaWrj4pbiODimkueuaaHAkxiz33Q06XA2mefSrrZP4c5vQIxkwFp21 YJsV1EBpDlkiX8uF901GL0zr6TQudgiaCqQ+wEcxQEUJPE2YLSwsV6U9Fr3lt7c/YbsY9EY4 zhF6xRqc1donB1tmfLIHxUfN5o75l/nXKFy0tw2Ks5gHlS7fXLo8aVRzQkmn0MzonFguuFO7 VJ3qtZs8xd9tacKylFkTtkMiUrvj1FAdngJ9mnVuYKAOfBsMMvRpJjovHfqErBq7VNsB4z2l Z4X1K3HYJS8HHS3b0c+TOy3+4XDXsmjZvZx4jcJFe1svR13zxWu+YN7Jl8il+OeGwEpsyms2 JCXXgqwNmVT+7DBaUv302TS+9RP48TJKgOpBVT2oxfSggqNrO2xWQRN2s3VsIi9BZqBCDGXi YIGdMmtKqW2ZUpvzkIqzyMgvf3P9IM33F2aWjaHuPJh+xN4dAukQc40nQTho7Fx32MeJh4YX 8b0yWuYKlhkWfbPtTTRvzcD4vCFY86T66KvpGucUgEysNlGHVNd87jCK1faYNp3m+wvT9hhq HmAED5qyI70vPF0dtrAdkog4V7AN037QaDW0hpjXljyisPP+xOcaYNqusDB1zsJ2SA4h7znf uCOxFUHy/YUdcji8IppIj2YJggWgg+mg0SZ5I7CAjknLgfhSSgbKlIFemi/PLgCdutC8OAln v7B3vkltjdR9jnOHx/4Xn9dM3jeE11BHLmyH5FrmvfZde7Tp2E23bdZNFgniIwgwUZ3VbpFj /Wn2Wffqkn37cXMr7IESicUorjgPD99EYw6FHZdIXXZdIAHYNxqNmvBAdcTCdkj2P/etP07z 7YWdLvoiwSsx2GPdE1L4UfM6LruBjz3WPeboCdce4AeEF1NSIGxH0VKgfUjz9QWKQXT0wlPV GQvbUfAZ91wvzdcXdsYjF+QxAzMA9sXf49c66ne2XAeN0a77WGIjvz6X7U3Yy2JpCagS7Jn+ GCAgc+rECvutpLtMV2UBYpVw4jOoRXUYi4chS9NK2sY22369NRO38hYANO3oqPJI83iNguJT xWpFmJyfMDnsOPHDYm5KudoKjcWHLv2yMwLRlkqHVSEEjjgWXik1pdTyK7U5PVZcxg5lus9x iTQLv5Hyh8s8ktCGiTXM5fEJ1MuacOXnoclJxcBZbt/XnyzzmVnourX8sa2/hG0pUUE3DM55 2U3YBCUTizFScTcV9MuDLDd0fYnQ+y5Acai5uM/Ugw3cuudTqiLMyfIMjWfWYbFNlF2sYK3a 225jPtXbF4hYzahG1N6/3d5vHcg1i7oVqVV+vYnAH9JPBD5o8hFlsxOBD9VE4FcSrPS2dhrf SqrZF/979fn66+X3v7Fajd3ZYOjWH8x6C905sug4pdsnSXGsxXxUsYnAJOVqIjCGmqqJwHTZ ONqcnJGr7DR3u+2UbJ1ZXze2LXcicDLmuOx4nYLxwzl0dUbXWZ1zasHqIFF2HWKRhJxH2adM MIEa2ELcGuCNk/v7sKxBZ3+kzv5M5DlKczC5YW8EMk/zgMLgMMFQDzhVzMSJke7+0J0A6QZo O03rAFuMb/Vtjh4x9SfTH4BBBvkZ4S2VRigzJ7dxADRycMzA/B6f1aP82x8NxnrakTr0MdBU pvdk1jplnjg3A8JmF2YBOvUY3kqNLGhloVwr3fWB6RuehRtPxiAwjSEpBIzOde1JAGwc/sBG E2OoaO9Ec1CmGGyaRT6CQbOajwmjZuwM4OrfxEIQWgPLtgIL2oHm8DkuKjgO0wVpVfagTLFY aDorTjmsVV1Rjn5GR1+4M4UdYnLOL6qgocRKHUtCv5t+j+tONVga+0SqHveZjMDP9qcSsdDh SIVVWzALh1ZapUyt8vOLePlLlkfG3l2bU1+kq33gnmbYZdvVjikmwSTLsOUWPThcLuvN1nq9 lyphVmAVL305QsZdx9iOwigPmlszd+tNiMwwwocU97TM1KG/hcZPMtyhjMLQ8qkC2ajZ5qdn yLoOtpAcRim1LVNqq3ya3NSib5QdXrWe/EzoyDl4hjWm/EKqh2RPe3b2Yz7sebd3D24u4lxd zLcqH3PVQawnvfdILDjGZnv3keDaRCjzr81PnR64xoTP76UZ2/MCLhxkRrlWNmXLbMrOOspb M+2xPEfZoItfp5CArtyuOcXx2wvqAt68xJFXDjBA6s+nT7p9VjOdGJwXg3fi3wkuN57dwUih xh+dm/f6xA7Oas2myppmypq+RdMKIdUcon8D91Mw4d0Jlw5M7ogPVREuTkY7qw5/6w9fpH1K yIrmD38uxyu5T2bz33GKhZTM8+ny7EeNyrq1wJv4QavZPGm2xGUoMRVubcKprhPmdDcO44kR G6x2Y43GQOsQQRrRV41GM8AeABcsw9xj37u3+72fqPHogbANSirKLLD0bdd43Gxv3Y/zq1pE cmR6FhjOmIOGS+HME0Q/v0KDI5zqy7PncZKLmqzXOhQeqCRY2I6Ew91VvXaOsXaAJ00CCPG3 iW8Z7CPgMbWQwauawt1VgLtKY297rQNikZ7BYgCEF6rpe88dUSs0h2GKRl244ErflWmxBfdJ 2HeJYi3MrhHGFK4ae7aCIeoUwOfU3TEN8USeF6hMG53yyqEXgZhpzmd3cPnR1D5WQywBsKXr AIob6wNfHX2Vjz4w/wQfBmfFuDxnmCM1oOtO8fwIKUMLqKjgJVQMhukEHmG0CZHukXwIl0AZ h1KNAxokhO1ebhPUYaTZrLwK+jrLUWTJo80gFJlvWw/DwBZHC2U8V1VYVYXVIkapHjRBZVj1 UapRaRKsIKQ7drSw2pzTe6qw2moeHh+0tcODkNwlqijL6xmkYlVhteyGw/qcnCaSHBUW4F6b /hCN5rY5OGV/RZGKBc/wb3V0njx47mTs0xjzabzD3vVbfZ7p67e+/NwXXjSj/a1gwRVO7g0P AN7/FpHmoVCNYWkMeXzDukem9HUjEUzEk8yG5ihGQCILpfZU6OwtM3C4t/Un1xN3fHnskMFh ldRJEDxSR1cfMctUGtg7oVYoSEDC++SvCoVpNMNaREvIHpNdzXTeC++vtIKwHQn7vE4daLOm IkL8cAFetar8QkoZ94ldpohKriYMXU9TU6U2l9HbrPRGdD5cemcrPWizxQh4wmwTdvv89ps4 21IpsFVXfXcUWCwCtd7/tE/Z7RAtEOzm4vcfX8+JYEeH2zseU4YXmoCM9MhyrNFkBKiGOc8G pKSiTMdsoAcijYXEbGb3TiSqn26+bwYB570eA63lOKZBxR6fan4uu7m82iPeFU7SRKIB8hmA IPiPCNdDyUWZcjFHdlW2VODUV5qo/H6OoXsYVA9CL0GAEtbEH1GYqNPdQuXaIY2HWhXCUnMA YpnvIB7SSwWkPW92nTDrPNDy3GdU5YRnq0ta5iUFMkzY7QSJJo+hMIEGFgOGnJEbx+I2PFWX r6oXT6PgBfFSl3nxMssqGxLuh01OajxoHmxLuSzvpMZmq1X5SY3TNQp3baeaEatZYJg7j8Ta UC7sBkKgNN9dmNmeHf+sUsYVNde8/wocpsDRcTY7CBmSKuFsqTDLAtLjVWKXP8QaWUaqL88u 1J19Q0fVzkcUFa0H5TxHMZiIcrzomRSnrxZ65sqOM6wAsE/UxxE3z1JxpxKwXBrZM5/c1QQt xWYHAG0fWSH3JNJeVK5GcEXlaWGZyudelOyt9rk/bInPTROOIkB9/ahMMFkWPSMOBrt4wR0A zvsxxETJwVDPmJwTrUW4HFn0UP5HSxLZIjH82/rrGcASHZHxVOmXnWUZwuSyCoJhh6496pve Q90LDNAl1ycxV0+ZOmyWkCO/ouiE9JvSFczpLpkZU2xDBbMN7Xb/gXr7Arsndt3c5Xe2fr0p rIf/FBRufPR9130c6d4jDxRhQa3BWe2gCRf5+XR2CutR6JRWndAsdZ0i5TDUacOKxGuWTGFd EqGkfLBkIWoKKzJuM1KuprCqKawFEDjutlNSwXqVYOokeZFcqVHwr69EZhUKMjn3MJuHkSlm BogAHsJxKHPrk8VOEiuw2bL7cSUDc8sM7sWgfGci8jnhWXCil5W91kgH0I6lenRiUWyNB6+8 sCUtWEjZZFw5fBTeI070wL2PmnZ0WJvx/HJvhkQhmKBRC10hpH7iyKDqvr58JNGqs9qdvoMf vlmnMa5hSy0VjIEq99zBxJgbMqwOvTqHLvJF8fPHoM4FQlp15JU88lWLWmbsltccacZBqm9P NOBLv1uSHuFCy94lUiL670+pa7Lea33YY13tsL4mV6aK4QpMLGeowEqOfocHA55UMuCR1fF2 h5pHuoI5pSaLprewEqlSN7O16qUmprPx1M23qKm3bwbPpukQqC12xpCEnukEj7wz9m5OEDNF 5ssXf6GDJVJEiSakxWYhfco9XITaFXggXfuJOnnnobsrDiWDXe3sMQz9aGuawriL2OBVl2x3 ovuZQA94wIlngRUWHeQ+Bn+gN5E3kXME/FbplQwiLHENVx1g/ghnA5dSeHmlY6FjlZbyx7ph bnDOwcqEeKEVrE+2Ts3+BtdIIZEFPCGPwTuyo0/hAIEQRfd9jDIdEM01Wh3MP6HSMOpDXZiN 0dL1X4TNTvBFChUMnfVDjgT27hbHvurZ+dU6nN+BJTZvJ6xt1vnNYKTIzzpWflaVNdhnzF9w QZliw7vyvJifh4g0jVndJiZHM9r23U4/bunbJ4IbNWSsYnBj3BKkadXBN4rF4WErWtpifuD5 FCrP+LvuWP4QO8Ln2TbjOnA4YVJSL14EkEiL0+s9PzN+cuZAuUGZfgGva4fJopLeVbJXa0Eu +6jKP5/2P/n8d8O1QRcWn1STfoViO4k/dFzHDD9aPG4opCiDGXQ0bc7azqbRUgvQ6zdK1i7g CrCOCGuM+hBemCONcRn50nI9P4UABx1QTF2b9yDccwyziho63lQBwA19hh0OAdyvV6JRXS3X fmMtt9bzp0pKkvBYQIkLR5pDz631tpK7vqV6rpFB08m3pQhNF0noEk0nf35aTfc9nEj+ZFZb 5/260LR/zNntZO3fetX+nnlfv+59amnayaKlXe4kRP9N8sRZI97K+NXJeu6frMQcwEdPHzhz dIyFJgFuGnus9jcTc9lcb+BzSmdiscA4C+yjT0mtS2dA+S4xEZExTKxgwRcp4PjXtfnHxPLM EYbasa/mk2n7mF09J3/kACdBYyVmaTFUSfj/8UdXHuFtj9ut89bH2kyYIN6T+o+bSN6vvLBd Hv8/9GarNpGpb4w10ObREUydlJlIKt63OZSy5CjW8hDEI6D9f7XJQefjpyumHaSUlE3gODIk EJOV4W7J/dZQK95btnm6v7//6fTuDuBnz7+7+zJxHN27uzt3DZQXnAAf/ev3kUMpvbofIIuH 7PDd3eXn297d3fXtp5+fP97defcGt5jbL/kwLoxedTdlH8nzb7pnDJl2cnLUENaQ0TBuaQZS eaqkpnkSK6nRXOP8UGGeIvZUj0HUupATWq7+yVPFfxPkJznd9CHjVycrZ3iql92PfBzZ5eeb L3D8SH2wKxcFzRciHPwJLyYI4V875sFUjUaHNDlJ1I5o8kUplvm7W+bFdPaE25dRe1c7rPmm v7AWkvVVNHDJCYgZ/pCZXGWUJqiCTZyrkayVuZOES4uR60xEWuTzp5FdsrFjy9LPyDTRvZ9+ xUxwWNLbSnZrreCyz/2NMspsjZagFsWwMPUhkg+1tCCbotAWMfiUmn6+dIhnGUAvlYAOeCbp +MP5yQeeSeLji5FwvAlebBN5E15tv7j99vUKfi/fNGDdQud0rD+YHz1Tf/xI/1JgV9YvY5Q7 3UkwxIDVvzBApDExy69k5bcKdnRpXCexR2WWCT4NPcsPSqsTSFZ0EbF8Crbil7mtkk1h7DMG 3fm+66htESDAwnbIali52I0uLM/XcSWD0tCykrOewyMp0c96xgudabm7mP7qek9zw+BlMoYS cCHpNPSAtA5azVVrngGfKwHpWQ4u6lrdESplXqBvLUZ2+dyazyPdsk/B8xb6II24Yf2/MS2T G8KG4Y6EW5LxHuz2ie/221cwxXkTmPeY5ypIpMxW5PNH9EfdWfAAZY+IzFHGO1HBc1F+Mzob sjck5W8w+6r3XXRco0fIhJMyZ5VXiOv6hkM5z5vqnf06sU2dsZMjrXW8Suspb9UE/ubJrHWA 7rt5NgfmWnG8Mv7b6awiWQYfoGE/NoaxsVbuagWS/7t939TbF6gtdt2hzpIbE0uyv96UmKN/ Cn5NfPTJKA/O7B6C96hmWW8dRwXMWVx4dBXjj85hLiY2V5A7G3lJIAhLARvLMkJT9IQkO74A wIh3Ow32YtmDJQtZC0shNCn3+K9QKrI2KUs2Q5DP9MGTZKkpgBNcqOOLUIWaaz4dd+mgLOqY QT2cSBG37Lz+Dux8/afZf/1A+NNfJ44JEJwm4mEybqsy6xs260JD1FurcECg5tqtCmDaJZSa XEVCPqdPDaFtBMMiqQ3hWLNoKvm3YGCvRJktQBmmaF9h52ehdPOb0OJ0JjoHvJzVwmYXdmHa Ntgl3RE1gg7Qc3hWo7tX17S6dnTbap+2Dk+bzf/jyKQIWSZ//eRNoCnEX5D1clj3iir1jwt5 2jSXW1jm1gkYuFPwTpvf2xkBi/dE2Kil8sCbfzf/zsuEPHdCWlh1vBVv5UJONQFehLd7tgpo 91xT/8R7ImzUUvEooFUvzzsvE4+e7rkPOlrx2KHg3aVRIG8lDEvVZWwdsp8O74farssrHElC MSM30uQmcI1HqnEzph0eHCv8x1nNdChWCg0u3TK536Ay6oddrbs10Or0gaj8SCP4xwM5VQ19 3ADqgztVKp+u8ulv3AqgAu8NB94zbo3ae7X3UcIho0OsJEdJjpIc8qN3qe1O3Vp1a9WtVbeW dwi3mofHB22kR6JGm7DssDr5pDyFnWmzVvpe6Xul75W+V/r+NCW6RmlMpTGVxlQaU2lMpTF1 +6y23TRKylopa6WslbJWylqltVZb1xiSpYNInpsjxGzM9LXHzIDpdiMNuKo4mp0Qkf/5zzHo qX12bhrmqI9JvK2TPQ7NFwD77B9X6OlhrePkjqAKhWqRuMVgvZnS+6IgEq+A5TzgZ/ucnBEs jwQRDv/SnQRu9APR5/o9miZm/zz3I5x3dGA9XdJAvCUKwuu5GFyAnzF1P+j6ln5Wu7VGOMPv 5jO7dkc6x42tQLLHqERSxRHoe/3vxdq9CLLGv3f2ywWuS8cde5YTRHnslOvx/xPvC5ji+Wb5 /8EwnWiv4s+WXrlk5P1FMLLZSPceJ2OG2z2YGJhA3H9Zi8tE7Kt5q/V2wHgeLmyVbpEPPN6O lSSfHNMaWlPbY/oTyJL0PshU79HnMH9w0z4KomHtfdS0o0OOFZS0gS227kHG5qcMxR/JsNai GMqnBLW2hmN/GARjTEsJXNf2G5YZ3Ddc7yH86/5UjPblFM/xjqTb5LXaCtNqqgI0Rifdtsxd L5nExZpWUIYXL2PTsy3ncdPqUCL/c22Qs21NW60LhDOIa57EOH8lHMesHX+4IZvyfFbD0Jwm v4lD/PnwuB03Lz9gIg1+InDH+PxA41T2nvUwBAg1/mvfDQJ39Pp327yf+dehqQ/I6h81eYP0 vetyJyD668MkiHwCbs/QLkv2LOIrop8JfQLX+OJZ5BVASswrKzDwlu3DeDxzuESOFO+7gxf+ h0E036jz/wIAAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29yZC90aGVt ZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b 2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwd EiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uU SteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9 Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5ha sLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmW QPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcji V+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8A DWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+e HT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosv n/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2e ihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZi UsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5F HUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piV DX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hB N8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zERW+vE64 E7+DKRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV5cz2iUK9CHeyPHe5 COjbX5238CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKue0wZG6gpIzek abwl7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVKuYTDohmu pK3x0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6M7e6 Ec0URYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7S es/7qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL 0FHbazWXmx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMH UiHVFpaRDQ0zlYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSul fKKIGETBERqxidjH4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZcczSCGflVqdonskW bgpSIYN5K4kHulXKbpQ7vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7 AhoHUzsgWuB+F6YhqOCC2vwX5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7LEmW ETIRVRJXplbsETkkbKhr4Kre2z0UQaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPinOx+b zKCUW4dNQ5PbvxCxaA9mu6pdb5bne29ZET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw4 8OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11yPehtiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQp a9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz2Tm5eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeY z2TlL1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPktR7N04y8AAAD//wMAUEsDBBQABgAIAAAA IQDsq1Td4QMAANgIAAARAAAAd29yZC9zZXR0aW5ncy54bWycVttu4zYQfS/QfzD0XEcXX5Ko cRZ2vN51m7SLKIsF+kZJtEyYN5CUFffrOyTFaNO4i6BPpubMnLly6JsPz4yOjlhpIvgiSi+S aIR5JWrCm0X09WkzvopG2iBeIyo4XkQnrKMPtz//dNPlGhsDanoEFFznrFpEe2NkHse62mOG 9IWQmAO4E4ohA5+qiRlSh1aOK8EkMqQklJhTnCXJPOppxCJqFc97ijEjlRJa7Iw1ycVuRyrc /wQL9R6/3nItqpZhbpzHWGEKMQiu90TqwMb+LxukuA8kxx8lcWQ06HVp8iPNPt1OqPrF4j3h WQOpRIW1hgYx6tNliPAXmnT6huil1BdQ6tj7ji0VmKeJOw2Ra/rG/ky3fRfvSamQ8m2GAbBR sCrfNlwoVFIYqi6dRrcwUUeCuxH8ICDvcBnFVvi3EAyEEqsKOgczmiQegAzFrjDIYIC1xJS6 oa0oRuChyxuFGIzbIvISR2YUqg6P+EjsvGsnqvEOtdQ8obIwQgb36SSZejf7k9xj7gblL7gC QWGazTzOxZeWV6Z1Gr9jxSEKR1ztEXgzWBUSVSC8E9woQQNBLf4Q5g7ugYI2eSp/K2zSDiw4 kk/ikyL1lt9Bej5ca/ZNAYKfzTdi9s77AH3V+CPSZqkJ4iuF0eGxpdhn2ijRLVsjdsT4AN0l LPw1hrA4YtAMH0R/NR9EjW0tW0Xe9Ps/58UauB5CW8FR3OVDYrBoam0ztIdHIUzQTZLkKlle 9kW16HuQeTJfpktfvdc2l9nkenZ9DrmaZOtsdRa5mq2vz0awXCXJLDtns0mTebI+i6zS9HJ+ FtlMrjM3xVCbviIstwvki7q98acNTMuI+TreIVYqgkYPdsVARVleqsOK8ICXGFYs/h4p2jKA 47EHNEOUbmAiA+ACYHlNtFzjnaOlD0g1A2+voc5K4d789sJlryZWn5RopffWwYRueQ3i4C6d Tns+ws09YUGu27IIVhzWxHdQy+s/j8oSxkN5utzA64Jtfe4Rb8KU6OO4+GhVYdqoKuwLhB+Q lHDxQKVs0kVESbM3qZ1OA181vETuo2yyHsscBl8Wcx+ospmBdn+wCv4IWv1hkE2CbDLIYM96 vekgmwXZbJDNgwxewi6HpYMV7LMD3LpwtPKdoFR0uP4chIvojcgXwW2QLa9oW2OYhlpUesvt tvS7QO+RxNB2u/rgPorcCfpdqEfHHLbLIsI1MfD+S1Iz9GxXb+bmudem6CRa80rXMlll+Uo6 qpFBYO46+crYbYd/xQLbD1cEprU4sXLYl7/4vCjRpsASVqsRCiriFs2vjnn4S3L7DwAAAP// AwBQSwMEFAAGAAgAAAAhANiyfMPQAQAAlQYAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbOxV 227bMAx9H7B/MPTeyE49LzHiFMiKDgOGYei6D5BlORYmiYKkxEu/frQd59JuQALssU+SeDki eURqcfdbq2grnJdgCpJMYhIJw6GSZl2Qn08PNzMS+cBMxRQYUZCd8ORu+f7dos1bUf4QIaCl jxDF+FzzgjQh2JxSzxuhmZ+AFQaVNTjNAh7dmmrmfm3sDQdtWZClVDLs6DSOM7KHcZegQF1L Lu6Bb7QwofenTihEBOMbaf2I1l6C1oKrrAMuvMd8tBrwNJPmAJOkr4C05A481GGCydAhItpB oXsS9zutSKR5/mVtwLFSYQXbJCVLLF8lt36/Rm0uq4JM42yW3ibZoC+h2t3LLeq2TCE1hHbW WLyvog4H6TQ+yB/luvmr4gnsaH+0XkEIoF/IMaZV5bp7wtHHIPEEDf1zQfB54MYyjon0ew4K kC+2CTAEok6iu86zPIvoOl93mvs1rrQnYp90R8mnRqrqnJck/phN0w/ZPOmJe0HBsaRnBBzF b+X/93u5pPzZfJbcpvOhK96K/6rj/sfbH3hYLoZ1bIKLpF2vjF/GOE42RuIfIoaJADZILZ/F A7iVg9YL108yphS03799xgPec/KZLP8AAAD//wMAUEsDBBQABgAIAAAAIQBbQrG8Qw0AAARw AAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzsXdty2zgSfd+q/QeW3h3rLts1zpQv 8cRVTiYTObvPFAVbXFMEl6SseL5+Gw2QokhCbIiIHa+Th8gCQZxGd+OgAbCp337/vgycRxYn Pg9PO7133Y7DQo/P/fD+tPPt9urgqOMkqRvO3YCH7LTzxJLO7+//+Y/f1idJ+hSwxIEGwuRk HXmnnUWaRieHh4m3YEs3ebf0vZgn/C595/HlIb+78z12uObx/LDf7XXxryjmHksSQLtww0c3 6ajmltXWeMRCwLrj8dJNk3c8vj9cuvHDKjqA1iM39Wd+4KdP0HZ3nDXDTzurODxRAh3kAolb TqRA6iO7I670ogZX3nnJvdWShSkiHsYsABl4mCz8aNONfVuDLi4ykR53deJxGWT11lFvWMHL u0yxwWXsrsEUmwYrzdUoYy5vWgZSD8K+G6uWW+x1d3VGWUQ0kctAEWEbM5Nk6fph3sx+qikq F8ZDG//+I+arKBcn8tu1dh0+5G2JYWkgWXeMI6/YtcSogcrQnS7ciHWcpXdyfR/y2J0FING6 N3SER3beA1XMuXfJ7txVkCbia/wlVl/VN/y44mGaOOsTN/F8UM+tvwR2+czWzle+dMGS6xPm JulZ4ru1FxdnYVJ/mwf9K7d2KCADN7yHZh/d4LSTPB5MP2yD5EUzfw4tu/HB9KwDNx5iD7LP Qk+ivF+yVqnbQBBAF1NJm6AUdnfDvQc2n6Zw4bQD1IuF366/xD6PgctOO8fHqnDKlv5Hfz5n gqWziuHCn7N/L1j4LWHzTflfV8iRqkWPr8L0tNMfT9AUQTL/8N1jkeAqwAvdJUB/FjcAkQCp F3BQoJW/kUYWlFCx8L8ZZE8oCDRbh7JgrphXHJR/JxD2etUaqN/YI0tAg+cCGj4X0Oi5gGCu bvA6SzaaCKCiN2O7Ro4LsVDbJmRnCmOKLkXKPTl0ip0YHO8YcOIOHANGd6AzG92BXml0B7qX 0R3oJ0Z3VAzeqKuKfRvvqJhz5x2ei7Rb9qIBaoPkibd+GrDGEdNrSdRqSnO+uLF7H7vRwhFz c1nsXVQ/Xc1Smqg4GexP9dM05iJibeCQvhwGe88oH5bRwk18COybgFqq/lZET84fsQ8RcAPU SDpfpU/6CfhL4HpswYM5i51b9l1a1OD+z9yZRq6HS4QG4Vqa9ca/X6QOBJYiYGjUxFijdL0m ZPs3foI62BmLjDVdaWqcZMOxxi/1jX9ic3+1zFRDiKXGks8NzFyCaI6ixkNhouogbuyFMACl C3K6MO8Ctk+QX04u5u0LG1Pkl1PRnu0T5JcT157tNwevY2OmuYSdGYc0vCbGY/eCBzy+WwXZ GGikh4nxCM4haF0wHsR5+ySSmBiP4C36dM48D9adFD81tsWGRw1QjM0hUXCw0ftibJQS7fUM emRsoBJW3wCrHdcaABmT7lf26It9ZNPJAFk6jzUbh/NAowGYgkgx9F8rnjbH0H0N51FRrkPY 7EmYQ0MbaEYeFU35k5zvDGzcbuIzAGo3AxoAtZsKDYA0/qGPefI5kQ7SfnI0wDKm5XwWQ7cj M/PEmJlzILMpwNK8SYi/NKNX7wvVeZOAYmyg6rxJQDG2Tmkuy+dNApa1eZOApZk19DYqcqpJ p4znzSJQHgkQemSHvAlAdsibAGSHvAlA7cm7GcQeeROwjLkh59QieROAsIrJUj8HKpI3AciY GyTbqT2jbN7DVnbv71ggbwKKsYGq5E1AMbaOjrwJWFjFxBNKWDnVEbDskDcByA55E4DskDcB yA55E4DskDcBqD15N4PYI28CljE35JxaJG8CkDE95EBF8iYAYRUTbqglbxz1P5y8CSjGBqqS NwHF2DolQs2DVAKWsYFKWDl5E7CwiokzKCx0bpNO2SFvQo/skDcByA55E4DskDcBqD15N4PY I28CljE35JxaJG8CkDE95EBF8iYAGXNDLXnjYPzh5E1AMTZQlbwJKMbWKRFqznMELGMDlbBy 8iZgob+0Jm8CEFbZF8ikR3bIm9AjO+RNALJD3gSg9uTdDGKPvAlYxtyQc2qRvAlAxvSQAxXJ mwBkzA215I1j5IeTNwHF2EBV8iagGFunRKg5eROwjA1UwsqpjoBlh7wJQOiYrcmbAIRV9gDC UWRiJjvkTeiRHfImALUn72YQe+RNwDLmhpxTi+RNADKmhxyoSN4EIGNuEM/ZwvOi5MdTexon oD5nkD3VQAbsa4xEBVQd/MruWAyJiaz56ZCWgFkPDRA17kHt4jnnDw7twe6BxkHIUP4s8Dk+ 0v2ET+kUEhEGkx2ZBLd/XjgfZfpO5T50qe0nbyBDqpjsJDKCMFsU5EyfIkg4irIny0VrkAgl UsNUAhNWvIZ0JpWUJG4WWUpQERO1VDGe2ypU/BuSrxBHPqAMtWcMckUBq9fFEx759WyV8kRW UXjuXcog61PVwm+lStA8dEi1D7lrAibOstWynLRbyHkFsKUPGXAfVJ6aVGjydyZ6f5iVXIhE N+yOLCuklGH/GzSW60jZpIepXUUtbXKtUDkzFzLE/hQJXxUdBn74kJVnzV0s3FiKusm4yOqo hJOdqoc2QReodvHn15XICHTTG6Es2S5fpeLKzWOQtdsVF/R6VlmBF3wV+/D4OuQFCtdRSX+l UpHwVyySKpD/XyT4+cDiXBuDsYJG24II+5igrzVBX/bYzAT9lzABZnQ8kwlaevxAq+7BPuoe vIS60TFeh7plGm8dwShKM/Pu4UuoGx3jdah7pPXu0T7ePXoJdaNjvA51j7XqxpkBQgmj6XP8 EupGx/hp1O1BAOF6EFjtiO9UlmH+4DfmGJajPU0qIs7h1dhEpSRuNq5kva3EGCgCNWmm+FSk 3+2QGdPzdgamDlaRo7QqIOTzo0hNEkKcPAtkpAl/XIdziHXWKqKSEfT8uyubgusXLAg+ubHQ XcojfdWA3aXyaq+L2w6lpmY8TflSf3+MWXkoSV0DoNaiMPKr6IRe3+FqOWOxyvHTrgPEcr0y RCEZEcs1rkDVtF62LR/eRNywfolFzFwR6GN+BUUqcUatt7eUXb2HYn3iiZQosBsG9134d3Wl PDArFK/YAc8GQOhwQ5xb3/ErHgR8zeabbpbHarXGyyriCBRxhMsKSE5srQhvlcDgmIq3d5RX qlvLprJW1EWn52ymBbJvCEfLJM9QlGXzpXt2XVFLeYGKC6dsder+h8cfxYtSBMeVl67iYr50 heu4uKq900tStdwV95zD61GkUDNpcLXG2vLKwXh0dYx7M3gr7pDBmhBT0zbFU8j4BfWeK/ct LJ2PJELyd2HpjGWG/txsRrn00pmxb8mMalVYM0WojuYvYkGd/qRWHV4d9c4vhTPVWRUlL9hQ RVNbNsQy6zaU6zmdDQeWbKiWmm/Khi22sLbmleZxKBeJOhsOLdlQ9ef12dDH0eXXca3ZqHw+ i8p1qM6iI0sWVUvk12DRrRmyPxxcyTdZ1HFpRrFqhpxUZ8jns6Nc4OrsOLZkRzVbvAY77hiL L2jVrUOWzQLm9tPNl1icjcBLJlM2r65joIKzVUNGdcQ9kFLzm6C3xpDk1bA6fIHlOb5AED5h POBqR6xpRfwRcdj0P+4pp9FV6B0NVOClq9GfDFWoqasxGMP7TlAluhrDUbbs0NUYDY8bJB0P ew2STgb9BkmP+sMGSUFhaoGkkxTOxSYNova6x8cNsvZ6x7DjsFNpvT6I21BlMBk2iTscj1Bc CCmhS+gt6rwPnCQ7EtQdCGK5OhDc/L11HPhjj6ksBsJ147BC2eWh3pq6S6jSnuSRX7vKEWd5 YcID8Xbg6qJ167wVrucngptb5HGg+g4+2KzkLebcEakuag5e1R5kaYlfPLWunFSLk9Bdx6Ug sOb02eqpqEW91JyGKoZ423qpObZsPq98A/5Sc76o5oK37S81B4HNJ4BvwF9qTuxUkPKm/SWK WSWcF2VNAbx23t3vYRt7E4nY82ZxdZbNyokdm8l6uFdiT7iQrSP3vqrxrLxJODVORRvnMXMf zvGBNbgrm+/hU3NOSQ1Q/FC8kkucaZZDv82VJjGVc2ztVVzhP+FXzeqkbvuBo1YNjYV1EurP 02w6swgoffH6dHU2abfHi161w6Ls5+ovLJukQGqr8dEN/WQBmpGnjVLaNZvJ19OXygu7/2pC 39r9z8oi5v2r2qw937qP2VNlCGChia7145Hq4wt4Hro8EkWZiRT5qW/+DGqbVUCdh/8/WHwx qNE0lP3SNDyXC0qwN7YWwxpNQ9kvTVvX9KhG01D2S9O2NR3yCJ5Kqj50lJWbaFw/a2xFcfkG /bkLD9rwEF/QXp4r1DX59vY6IYr7TMWHRwqN2tmRh18MEw+lqSeOYFv9sn8uHbGy/Nzadc13 V0F60IyqrInZbt0F/PaP2PZT23qbAvxRH3kZ9bAJNLIzgGKgIcvscV5Znbvs1HZPtYAlFUzf TtXaqFHf5WeDNNusP4s9EvkzEGUzqOK6gbJj/bCltbPzbneEe5f6cUyN/twoChj89lwIP7gH J28H4mCiujKrr2W7D1lvkvf/AwAA//8DAFBLAwQUAAYACAAAACEA5UCy2Z0BAAAKAwAAEQAI AWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAjFLLbtswELwX6D8QvNMU5cJtBVkBmiLtoQGKxkGC3hhy7RDlQyVXUfz3 pSRbsdEcclzuzOzsLOuLZ2fJE8Rkgl9TsSgoAa+CNn63prebK/aJkoTSa2mDhzXdQ6IXzft3 tWorFSL8jKGFiAYSyUo+Vapd00fEtuI8qUdwMi0ywufmNkQnMZdxx1up/sgd8LIoVtwBSi1R 8kGQtbMiPUhqNUu2XbSjgFYcLDjwmLhYCP6CRYguvUoYOydIZ3Df5p0Odk+1tZqaM/o5mRnY 9/2iX442sn/B769/3IyrMuOHrBTQptaqQoMWGh3lFpkB3LKIqocH1iVgSiZILOfKIvztTJxW YcVnwsgdPJBfIC3bGAfkMjjXeaMk5hOR2yOXZG5GvXBrPo8chqsIEkNsvnXey0i+g7UJY3Aj 7Ngcrmhlwut88K0B/WX/Cv5/zECL8GSGT9Osan5a5tljzpMB0CQnV005Hzt3y8uvmyvalIUo mRBMfNyIVVUsq6L4Pdg74w9JTg/uYPJtiuWyKj+cKx4FmtHx+e9t/gEAAP//AwBQSwMEFAAG AAgAAAAhAC01phi9DAAAE20AAA8AAAB3b3JkL3N0eWxlcy54bWzsXdty2zgSfd+q/QeW3hPr Lts1zpTtxJtUORlP5Ow+UxRscU0RWpKy4vn6aTRAiiIJoWEidrxOHmIJBHCA7sZB49LUb79/ X0bePUvSkMcnnd7bbsdjccDnYXx70vl2ffHmsOOlmR/P/YjH7KTzwNLO7+/++Y/fNsdp9hCx 1IMK4vR4GZx0Flm2Oj44SIMFW/rpW75iMTy84cnSz+Brcnuw9JO79epNwJcrPwtnYRRmDwf9 bnfcUdUklFr4zU0YsPc8WC9ZnGH5g4RFUCOP00W4SvPaNpTaNjyZrxIesDSFTi8jWd/SD+Oi mt6wVtEyDBKe8pvsLXTmQLboQFQFxXtd/LSMOt4yOP50G/PEn0UgvE1v2HkHkpvz4D278ddR loqvyVWivqpv+OeCx1nqbY79NAjDk851uARhf2Eb7ytf+tC2zTHz0+w0Df3Gh4vTOG0uFqT1 AgcCMvLjW6j23o9OOun9m+mHXZAiaRbOoWY/eTM97UDBA+xB/rfUk1XRL5mr0m1QGKhvKq0I hMJuLnlwx+bTDB6cdMASMfHbp6sk5AlYyknn6EglTtky/BjO50wYbZ4xXoRz9p8Fi7+lbL5N //MCLVDVGPB1nJ10+uMJqiJK5x++B2wlbAfwYn8J0F9EAdAe2HgJBxu0DretkQkVVEz8Xw7Z EwICyTahLJgvhpmH7d8LhL1etwbqG3vkCGjwVEDDpwIaPRUQMKHB6hzpaCKAytaM9VoZLkwN bauQnSmNKXorMh7IoVPuxOBoz4ATJXAMWJVAY7YqgVZpVQLNy6oE2olViZrCjbKq6ddYoqbO vSUCH2m3akUDlAbJEq/DLGLGEdNrSdRqSvOu/MS/TfzVwhNzc7XZ+6h+up5ltKbiZPB4qp9m CY9vjRLpy2Hw6Bnlw3K18NMQHC0DWfVbiv5aOE7ev5JwboQaSeOr9Uk/AV9FfsAWPJqzxLtm 36VGLcp/4d505Qcwhxsb11Ktl+HtIvOmC3QYjGBjjdD1kpD1X4YpymCvLzLWdMVUOUmHY41d 6iv/zObhepmLhuBLjSWfW6i5AmH2osZDoaL6IDb2QiiA0gU5Xdh3AesntF9OLvb1Cx1T2i+n okfWT2i/nLgeWb/ZeR1bM817WPd6pOE1sR675zziyc06yseAkR4m1iO4gKB1wXoQF/WTSGJi PYJ36NM7DQJYd1Ls1FoXWx61QLFWh0TBwUbvi7VSKrTXs+iRtYIqWH0LrHZcawFkTbpf2X0o ttVsJwNk6cLXNA7ngUYCMAWRfOg/1zwz+9B9DedRUT7FsNmTMo+GNtCMPCqasic531nouN3E ZwHUbga0AGo3FVoAaexD7/MUcyIdpP3kaIFlTcvFLIZmR2bmiTUzF0B2U4CjeZPgf2lGr94W 6vMmAcVaQfV5k4BirZ3KXFbMmwQsZ/MmAUsza+h1VOZUm05Zz5tloMITIPTIDXkTgNyQNwHI DXkTgNqTtxnEHXkTsKy5oeDUMnkTgDCLzVK/ACqTNwHImhsk26k9o3zew1r27+84IG8CirWC 6uRNQLHWjo68CViYxcYSKlgF1RGw3JA3AcgNeROA3JA3AcgNeROA3JA3Aag9eZtB3JE3Acua GwpOLZM3AciaHgqgMnkTgDCLDTc0kjeO+h9O3gQUawXVyZuAYq2dCqEWTioBy1pBFayCvAlY mMXGGBQWGrdNp9yQN6FHbsibAOSGvAlAbsibANSevM0g7sibgGXNDQWnlsmbAGRNDwVQmbwJ QNbc0EjeOBh/OHkTUKwVVCdvAoq1diqEWvAcActaQRWsgrwJWGgvrcmbAIRZHgtk0yM35E3o kRvyJgC5IW8CUHvyNoO4I28CljU3FJxaJm8CkDU9FEBl8iYAWXNDI3njGPnh5E1AsVZQnbwJ KNbaqRBqQd4ELGsFVbAKqiNguSFvAhAaZmvyJgBhlkcA4SiyUZMb8ib0yA15E4Dak7cZxB15 E7CsuaHg1DJ5E4Cs6aEAKpM3AciaG8Q9W7gvSr6e2tMYAfWeQX6rgQzY1yiJCqg6+JXdsATi tJj5dkhLwLyHFoga86B28YzzO492sXugMRAyVDiLQo5Xuh/wlk4pEGEw2RNJcP3HufdRhu/U yqFJ7d68gQipcrCTiAjC4DloZ/awgoCjVX6zXNQGgVAiNEwFMGHGTxDOpIKSRGERpQQZMVBL JeO5rULFzxB8hTjygjLknjGIxAOsXhdPeOTX03XGU5lF4fk3GYMoPJULv1UyQfXQIVU/xK4J mCSPVstj0q4hBhDAliEEv31QcWpSoOlfedP7wzzlXAS6YXdkWimkDPtvkFghI6WTHoZ2laW0 jbVC4cx8iBD7QwR81WQYhfFdnp5Xd77wE9nUbcRFnkcFnOwVPdQJskCxi49f1yIY0M8uhbBk vXydiSeX91Feb1c80MtZRQWe83USwvV1iAsUpqOC/iqpIuCvnCRFIP8/T/HvHUsKaQzGChp1 C014jAr6WhX0ZY/tVNB/DhVgRMcTqaClxQ+04h48RtyD5xA3GsbLELcM420iGEVpdtY9fA5x o2G8DHGPtNY9eox1j55D3GgYL0PcY624cWYAV8Jq+hw/h7jRMH4acQfgQPgBOFZ7/DsVZVhc /MYYw6q3pwlFxDm87puokMTtxpXMtxMYA0kgJs0Un4nwuz1txvC8vY6ph1nkKK03EOL5sUmm FoKfPIukpwkfPsVz8HXg5Q7oUUkPev7dl1XB83MWRZ/9RMgu4yt91ojdZPJpr4vbDpWqZjzL +FJfPsGoPGxJUwUg1nJj5FfRCb284/VyxhIVUKhdB4jlem2IQjAipmtMgSppfdt2bHjrccP6 JRE+c61BH4sn2KQKZzRae8u2q/dQbI4DERIFekPnvgv/Li6UBeaJ4lUfYNkACB02+LnNHb/g UcQ3bL7tZnWs1nM8ryAOQRCHuKyA4MTWggjWKQyOqXh7R3WlurNsqkpFPfR63nZaINuGMLS8 5TmK0myxdM+fK2qpLlBx4ZSvTv3/8uSjeFGK4Ljq0lU8LJau8BwXV40lgzRTy11R5gxejyIb NZMKV2usHascjEcXR7g3g0VxhwzWhBiatk2eQsQviPdMmW9p6XwoEdK/SktnTLO0Z7Ma5dJL p8a+IzWqVWHDFKE6WryIBWX6k2p1eHHYO3svjKlJq9jykg6VN7WjQ0xzrkO5ntPpcOBIh2qp +ap02GILa2deMY9DuUjU6XDoSIeqPy9PhyGOrrCJa+1G5dNpVK5DdRodOdKoWiK/BI3uzJD9 4eBCvsmiiUtzilUz5KQ+Qz6dHuUCV6fHsSM9qtniJehxz1h8Rq3uHLJsFzDXny+vEnE2Am8p zNi8vo6BDN5ODunVEfdAKtVvnd4GRZJXw+rwBZbn+AJB+AvjAVc7Yk0r/I8Vh03/o54yGl2G 3uFAOV66HP3JULmauhyDMbzvBEWiyzEc5csOXY7R8MjQ0vGwZ2jpZNA3tPSwPzS0FASmFki6 lsK52MTQ1F736MjQ1l7vCHYc9gqt14fmGrIMJkNTc4fjETYXXEroElqLOu8DI8mPBHUHgpiu DgS3n3eOA3/sMZVDR7hpHNYouzrUW1N3BVXqkzzyG1c54iwvTnnkp02L1p3zVlBxcSK4LSKP A9V3sEGzkHeYc4+numg4eFV7kJUlfvnUunZSLU5C9x2XQoM1p89OT0UdyqXhNFQxxOuWS8Ox pfm88hXYS8P5opoLXre9NBwEmk8AX4G9NJzYKSflVdvLKmE1d16kmRx47bz7uMs27iYSsefN kvosm6cTOzaT+XCvxF3jYrZZ+bd1iefppsapcSrqOEuYf3eGF9agVD7fw1/NOSXVQQlj8Uou caZZdf22T0zNVMaxs1dxgf+EXZnFSd32A0OtKxoTm1qoP09zaczCoQzF69PV2aTbHi969Q6L tJ+rv7Bskg1SW433fhymC5CMPG2Urd2wmXw9fSW9tPuvJvSd3f88bcWCf9erdWdbtwl7qA0B TLSRtX48Um18AfehqyNRpNm0ojj1Le6gtlkFNFn4/4PGF4MGSUPaL0nDLRIQgruxtRg2SBrS fknauaRHDZKGtF+Sdi3pmK/gVlL90lGebiNx/ayx48UVG/RnPly04TG+oL06V6hn8u3tTY0o 7zOVL4+UKnWzIw8/oCQupakbR7Ct/r5/Jg2xtvzc2XUtdleh9SAZlVnjs137C/jtH7Htp7b1 tgn4oz7yMcph62jkZwBlR0OmueO8qjj36antnmoJSwqYvp2q1ZFR3tW7QZpt1p9FH6n8GYiq GlRy00DZs37YkdrpWbc7wr1L/Timen/+ahUx+DGwGH5/DE7e3oiDifrKrDmX6z7kvUnf/Q0A AP//AwBQSwMEFAAGAAgAAAAhABpPOHFOAgAAyggAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzM lU2P2jAQhu+V+h8i35c4IcsuaMOKpYvUSw8V7d0kDrEa25EnkOXfd2wHui0fJa22alCkMLFf zTx5Z/zw+CKrYMsNCK1SEg0oCbjKdC7UOiVfloubexJAw1TOKq14SnYcyOP0/buHdlJo1UCA +xVMZJaSsmnqSRhCVnLJYKBrrvBloY1kDf4161Ay821T32Ra1qwRK1GJZhfGlI5IJ2OuUdFF ITL+QWcbyVXj9oeGV6ioFZSihr1ae41aq01eG51xAKxZVl5PMqEOMlFyJCRFZjToohlgMaHP KLRSuD2i7klWJJDZ5ONaacNWFbJro4RMO3BBO1FMYnApJIfgE2+Dz1oy5RbUTGngEa7Zsiol NMbfiA7pLU3wjvEpIaFVykpmgDeHhdSHCyZFtdtHjdN162vRZOU+vmVG2MT8HhBrfLGBFU3J M6U0ni0WxEeilMwxcnefRF0kxqT8Ne4iw0MEHYSJOR23JPI6GEGdbpfLM/QWOiIy1xsjuLFM ztC4QwJjR8XSSHrRkDrnRvmaf8JRiBee92Ax/CcsmFzhVzrDwbrBu8K6A0n49N/QFTR+7YrE fs7kEPnhCucB9NIFV4ydu/q4QoGuGJxB8YQN4i2R9EbR2xIRln0EYjE/AeKK9ugLYslKbOgL GCwAOymSno6AVgCcaIwLcwJBxM+Hsrs5MaK3T7/2Rvw7EBHtPSe+cpMz9X+QmFlLjF6TsL0R nyARvUVvsErgmDjjiYU7M+wZ0r81/sATWPdxc8xONcf+NPmbKdEdIjD9DgAA//8DAFBLAwQU AAYACAAAACEAGH+u/CoCAABSBAAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVE2P2jAQvVfqf7ByD+FrgSLj VcWq2kPbRSUsZ+NMwGpip/ZAl/76HSdLCN2eymm+/Pz85hF+/1IW7ATOa2sW0aDXjxgYZTNt 9otok36JZxHzKE0mC2tgEZ3BR/fi4we+crYChxo8IwjjF9EBsZoniVcHKKXvUdtQJ7eulEip 2yc2z7WCB6uOJRhMhv3+JIEXBJNBFlctYNQgzk/4v6CZVYGff07PFREWPIWyKiSC+B7oFL3M YsmTtspTi7JIdQliOKF6m/GV3IMXwz5Pmohvrcu8GAymMxpsEr48SCcVkopiMprc0XCnwj9X VaGVRFJYfNPKWW9zZE+1Fiwg8KQ7wkmfNaij03gWBNVN+VdtiM5oFO5oYmLo5N7J6kCspnfj QLQt8LWSBSxJCpHLwgNPrgX+CDKseSU18eYnnJ9AoXXM6z+06GHEdtJDEHARnaTT0iAJGcaa pI6LyqMTqcaCsKnX5HXYHevGeiwG9QAFt4MBoOFAjVt29Q3+Kae34T/IDrpkaw4N1YZO5mSO sQbMY4fqN+zio4dY0et8TM6OHfw6agfBkz7uf2Ix28KO/QBZxMESbGnL8mjeVsg2l7OMztLU 9ew7BWo96S1/sSe8SpozNdqIdvnTb6rUPgSTvu3qtthx2VbjYV1JRVaYjiazYddvnR5fky8h IwNdEK8F/kiLdUW4lrxq9pBdZt43goOfm0+EGIx7ffrVlr3UyHLtf1e8AgAA//8DAFBLAQIt ABQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAAugMAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAIrkURh3AQAAjgQAABwAAAAAAAAAAAAAAAAA3gYA AHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA+RHm/QnVAAD2 zwsAEQAAAAAAAAAAAAAAAACXCQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEA MN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAADP3gAAd29yZC90aGVtZS90aGVtZTEueG1sUEsB Ai0AFAAGAAgAAAAhAOyrVN3hAwAA2AgAABEAAAAAAAAAAAAAAAAAquUAAHdvcmQvc2V0dGlu Z3MueG1sUEsBAi0AFAAGAAgAAAAhANiyfMPQAQAAlQYAABQAAAAAAAAAAAAAAAAAuukAAHdv cmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAFtCsbxDDQAABHAAABoAAAAAAAAA AAAAAAAAvOsAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1sUEsBAi0AFAAGAAgAAAAhAOVA stmdAQAACgMAABEAAAAAAAAAAAAAAAAAN/kAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAG AAgAAAAhAC01phi9DAAAE20AAA8AAAAAAAAAAAAAAAAAC/wAAHdvcmQvc3R5bGVzLnhtbFBL AQItABQABgAIAAAAIQAaTzhxTgIAAMoIAAASAAAAAAAAAAAAAAAAAPUIAQB3b3JkL2ZvbnRU YWJsZS54bWxQSwECLQAUAAYACAAAACEAGH+u/CoCAABSBAAAEAAAAAAAAAAAAAAAAABzCwEA ZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAkDAADTDgEAAAA= --------------070102030808040700000001-- From ekr@rtfm.com Sat Nov 17 15:47:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125D921F8687 for ; Sat, 17 Nov 2012 15:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 HiR3RxV2zznn for ; Sat, 17 Nov 2012 15:47:01 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46EFC21F863A for ; Sat, 17 Nov 2012 15:47:01 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so4147737obb.31 for ; Sat, 17 Nov 2012 15:47:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=QabAZBp6plMIt8XCE+OoshD8Za0HF/Nb87cFE5f0HP8=; b=XODGV9ixkI3GoFl62aWLWYdbbF9sz4Z/Dw3XQmGGy8Jm9zhEo35L8NwSRnAQ1OHCOp dwZzHKF1DJLeUmcunoSFqmVkQLeWgTO4+1shsESdSg5SomooY4Y4goa+c99XGYhZ+Bb1 hNXfkZy1HAUN6x2mfsXEFBgkxl9xbHuDlKaSNWgOLiGHD3rBF9lZDvzW/sPPqeIRjuc6 UKYzXbUNWHZdfWpaMJ1RYW8mKTstGqyY7tmKA2A/ABnMhguuVCNc7Kmml7rs2mol4P1g bEluQdso8/MwCVvz1p8V4wI9MXMp6v6PcfStyBxGrahSedr96Rg9oOrQTC30WLt5GIHB +k5g== Received: by 10.60.19.168 with SMTP id g8mr7090869oee.101.1353196020787; Sat, 17 Nov 2012 15:47:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.69.104 with HTTP; Sat, 17 Nov 2012 15:46:19 -0800 (PST) X-Originating-IP: [2620:101:8003:300:5a55:caff:fef1:5a11] In-Reply-To: <50A81ED2.9010604@omnitor.se> References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> <50A81ED2.9010604@omnitor.se> From: Eric Rescorla Date: Sat, 17 Nov 2012 15:46:19 -0800 Message-ID: To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= Content-Type: multipart/alternative; boundary=e89a8fb2062c216ae204ceb9808e X-Gm-Message-State: ALoCoQnFNJbNptK6XYoIUwa3An7bY1Z+8xVJiaqkbbUk1lzq/ELYMziQ4a62Esp5JzudzFH9WUrk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 23:47:02 -0000 --e89a8fb2062c216ae204ceb9808e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Nov 17, 2012 at 3:33 PM, Gunnar Hellstr=F6m < gunnar.hellstrom@omnitor.se> wrote: > I have proposals for adding real-time text to the use cases document. > I hope it is OK with a word file with changemarks to show the change > proposals. (attached ) > That's really pretty hard to use. Can you provide some sort of text diff instead? -Ekr > The new medium is proposed to be added straight into current use cases. > > > /Gunnar > > > On 2012-11-13 11:20, Gunnar Hellstr=F6m wrote: > > I am of course willing to contribute. > > Gunnar > > > On 2012-11-13 10:55, Harald Alvestrand wrote: > > On 11/13/2012 09:55 AM, Olle E. Johansson wrote: > > > 12 nov 2012 kl. 13:15 skrev Harald Alvestrand : > > I would prefer this to be added as a separate specification, rather than > done at this time. > The reason being that this should be relatively easy to add on top of the > data channel functionality, but will definitely take some time to specify= , > so should not be on the critical path for this round of specifications. > > T.140 is a codec in the RTP flow and is implemented in Asterisk and a > couple of Video SIP phones. > I see no reason to move it to the data channel, that would limit > interoperability. > > Much easier - and faster - to implement in the RTP subsystem as it is > already covered by SDP offer/answer. > > Anything is possible, if someone is willing to do it. > > Olle and Gunnar, can you undertake to write a complete specification for > how to use T.140 with RTCWEB, including how it should fit in with the API > specification, and whether or not it supports the needs that Gunnar has > claimed for text services? > > I don't understand T.140 - so I can't do the work. Someone who wants it > should. > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8fb2062c216ae204ceb9808e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 17, 2012 at 3:33 PM, Gunnar Hell= str=F6m <gunnar.hellstrom@omnitor.se> wrote:
=20 =20 =20
I have proposals for adding real-time text to the use cases document.
I hope it is OK with a word file with changemarks to show the change proposals. (attached )

That's really pretty hard to use. Can you provide some sort of= text diff
instead?

-Ekr
=A0
The new medium is proposed to be added straight into current use cases.


/Gunnar


On 2012-11-13 11:20, Gunnar Hellstr=F6m wrote:
=20
I am of course willing to contribute.

Gunnar


On 2012-11-13 10:55, Harald Alvestrand wrote:
=20
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:
=20
12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alvestrand.no= >:

=20
I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a codec in the =A0RTP flow and is implemented in Asterisk and a couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit interoperability.

Much easier - and faster - to implement in the RTP subsystem as it is already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services?

I don't understand T.140 - so I can't do the work. Someone = who wants it should.



_______________________________________________
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


--e89a8fb2062c216ae204ceb9808e-- From randell-ietf@jesup.org Sat Nov 17 16:56:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD51221F84D3 for ; Sat, 17 Nov 2012 16:56:14 -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 vgG2p8iGwh41 for ; Sat, 17 Nov 2012 16:56:14 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EEFA221F85FE for ; Sat, 17 Nov 2012 16:56:13 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:4449 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TZtBF-0004mH-3q for rtcweb@ietf.org; Sat, 17 Nov 2012 18:56:13 -0600 Message-ID: <50A83222.6000503@jesup.org> Date: Sat, 17 Nov 2012 19:56:02 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A5682E.2060103@alum.mit.edu> In-Reply-To: <50A5682E.2060103@alum.mit.edu> 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Nov 2012 00:56:14 -0000 On 11/15/2012 5:09 PM, Paul Kyzivat wrote: > On 11/12/12 1:42 PM, Peter Saint-Andre wrote: > >> Another option is RTT over XMPP: >> >> http://xmpp.org/extensions/xep-0301.html > > Another option is RTT over a datachannel. > > But then why not audio and video over datachannels too? Because congestion control for DataChannels is different (certainly so today), and we want to be able to negotiate audio and video channels that are compatible or easily translated into standard VoIP protocols (i.e. RTP/etc) for connecting to legacy equipment and gateways. You *can* do it. It doesn't mean you should. And the browser won't provide all the automatic low-level support for audio or video over datachannels. Also, if the sender is pushing the audio and video into datachannels from JS, you're pushing a LOT of time-critical data through JS. Not good. And SCTP has buffer-blocking issues still (they're working on a draft): large messages must be delivered before it will send a different message, so if I send a 10MB file, no audio or video would get through until it was done. -- Randell Jesup randell-ietf@jesup.org From gunnar.hellstrom@omnitor.se Sat Nov 17 23:05:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5321F8453 for ; Sat, 17 Nov 2012 23:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNr6RavcCpXG for ; Sat, 17 Nov 2012 23:05:12 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id DC4F521F843B for ; Sat, 17 Nov 2012 23:05:11 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 18 Nov 2012 08:05:03 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 85A9A3A19F for ; Sun, 18 Nov 2012 08:05:03 +0100 (CET) Message-ID: <50A888A0.5040208@omnitor.se> Date: Sun, 18 Nov 2012 08:05:04 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A5682E.2060103@alum.mit.edu> <50A83222.6000503@jesup.org> In-Reply-To: <50A83222.6000503@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Nov 2012 07:05:12 -0000 On 2012-11-18 01:56, Randell Jesup wrote: > And SCTP has buffer-blocking issues still (they're working on a > draft): large messages must be delivered before it will send a > different message, so if I send a 10MB file, no audio or video would > get through until it was done. Real-time text is also time-critical, even if less than audio and video. One second end to end is good. Two seconds is usable. Long occasional blocking disrupts the conversation and is dangerous in emergency situations. That is one reason why RTP was selected initially as the transport. That seems to be a good reason for doing it again on RTP. Gunnar From gunnar.hellstrom@omnitor.se Sat Nov 17 23:40:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A321F8462 for ; Sat, 17 Nov 2012 23:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[AWL=-1.883, BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs0Cbfojsa1y for ; Sat, 17 Nov 2012 23:40:47 -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 B7B2321F8461 for ; Sat, 17 Nov 2012 23:40:45 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 18 Nov 2012 08:40:04 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 20F943A10F; Sun, 18 Nov 2012 08:40:03 +0100 (CET) Message-ID: <50A890D4.800@omnitor.se> Date: Sun, 18 Nov 2012 08:40:04 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eric Rescorla References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> <50A81ED2.9010604@omnitor.se> In-Reply-To: Content-Type: multipart/mixed; boundary="------------050908010405050107070304" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 07:40:50 -0000 This is a multi-part message in MIME format. --------------050908010405050107070304 Content-Type: multipart/alternative; boundary="------------080908010705040002050401" --------------080908010705040002050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2012-11-18 00:46, Eric Rescorla wrote: > > On Sat, Nov 17, 2012 at 3:33 PM, Gunnar Hellström > > wrote: > > I have proposals for adding real-time text to the use cases document. > I hope it is OK with a word file with changemarks to show the > change proposals. (attached ) > > > That's really pretty hard to use. Can you provide some sort of text diff > instead? > How about the attached version as a start. You can do a diff against the -09 version. The main changes are in -The definitions -Use case simple video -Use case multi-part video -Use case multi-part video conference -Requirements F39 - F42 -Requirement A27 -Many requirement lists in use cases. /Gunnar > -Ekr > > The new medium is proposed to be added straight into current use > cases. > > > /Gunnar > > > On 2012-11-13 11:20, Gunnar Hellström wrote: >> I am of course willing to contribute. >> >> Gunnar >> >> >> On 2012-11-13 10:55, Harald Alvestrand wrote: >>> On 11/13/2012 09:55 AM, Olle E. Johansson wrote: >>>> >>>> 12 nov 2012 kl. 13:15 skrev Harald Alvestrand >>>> >: >>>> >>>>> I would prefer this to be added as a separate specification, >>>>> rather than done at this time. >>>>> The reason being that this should be relatively easy to add on >>>>> top of the data channel functionality, but will definitely >>>>> take some time to specify, so should not be on the critical >>>>> path for this round of specifications. >>>> T.140 is a codec in the RTP flow and is implemented in >>>> Asterisk and a couple of Video SIP phones. >>>> I see no reason to move it to the data channel, that would >>>> limit interoperability. >>>> >>>> Much easier - and faster - to implement in the RTP subsystem as >>>> it is already covered by SDP offer/answer. >>>> >>> Anything is possible, if someone is willing to do it. >>> >>> Olle and Gunnar, can you undertake to write a complete >>> specification for how to use T.140 with RTCWEB, including how it >>> should fit in with the API specification, and whether or not it >>> supports the needs that Gunnar has claimed for text services? >>> >>> I don't understand T.140 - so I can't do the work. Someone who >>> wants it should. >>> >>> >>> >>> _______________________________________________ >>> 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 > > --------------080908010705040002050401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-11-18 00:46, Eric Rescorla wrote:

On Sat, Nov 17, 2012 at 3:33 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I have proposals for adding real-time text to the use cases document.
I hope it is OK with a word file with changemarks to show the change proposals. (attached )

That's really pretty hard to use. Can you provide some sort of text diff
instead?

How about the attached version as a start.
You can do a diff against the -09 version.

The main changes are in
-The definitions
-Use case simple video
-Use case multi-part video
-Use case multi-part video conference
-Requirements F39 - F42
-Requirement A27
-Many requirement lists in use cases.

/Gunnar
-Ekr
 
The new medium is proposed to be added straight into current use cases.


/Gunnar


On 2012-11-13 11:20, Gunnar Hellström wrote:
I am of course willing to contribute.

Gunnar


On 2012-11-13 10:55, Harald Alvestrand wrote:
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:

12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alvestrand.no>:

I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a codec in the  RTP flow and is implemented in Asterisk and a couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit interoperability.

Much easier - and faster - to implement in the RTP subsystem as it is already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services?

I don't understand T.140 - so I can't do the work. Someone who wants it should.



_______________________________________________
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



--------------080908010705040002050401-- --------------050908010405050107070304 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-rtcweb-use-cases-and-requirements-09 plus rtt integrated.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="draft-ietf-rtcweb-use-cases-and-requirements-09 plus rtt int"; filename*1="egrated.txt" RTCWEB Working Group C. Holmberg Internet-Draft S. Hakansson Intended status: Informational G. Eriksson Expires: December 29, 2012 Ericsson June 27, 2012 //With real-time text proposals Nov 18 2012 by Gunnar Hellstrom// Web Real-Time Communication Use-cases and Requirements draft-ietf-rtcweb-use-cases-and-requirements-09.txt Abstract This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream and data exchange services provided by the browser. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 29, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Holmberg, et al. Expires December 29, 2012 [Page 1] Internet-Draft RTC-Web June 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Browser-to-browser use-cases . . . . . . . . . . . . . . . 5 4.2.1. Simple Video Communication Service . . . . . . . . . . 5 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP . . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Simple Video Communication Service, FW that only allows http . . . . . . . . . . . . . . . . . . . . . 6 4.2.4. Simple Video Communication Service, global service provider . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.5. Simple Video Communication Service, enterprise aspects . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.6. Simple Video Communication Service, access change . . 8 4.2.7. Simple Video Communication Service, QoS . . . . . . . 8 4.2.8. Simple Video Communication Service with sharing . . . 9 4.2.9. Simple Video Communication Service with file exchange . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.10. Simple video communication service with inter-operator calling . . . . . . . . . . . . . . . . 9 4.2.11. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 10 4.2.12. Multiparty video communication . . . . . . . . . . . . 11 4.2.13. Multiparty on-line game with voice communication . . . 12 4.2.14. Distributed Music Band . . . . . . . . . . . . . . . . 12 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 13 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 13 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Video conferencing system with central server . . . . 14 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 15 5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 22 7.3. Web Application Considerations . . . . . . . . . . . . . . 22 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Holmberg, et al. Expires December 29, 2012 [Page 2] Internet-Draft RTC-Web June 2012 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Holmberg, et al. Expires December 29, 2012 [Page 3] Internet-Draft RTC-Web June 2012 1. Introduction This document presents a few use-cases of web applications that are executed in a browser and use real-time communication capabilities. Based on the use-cases, the document derives requirements related to the browser and the API used by web applications in the browser. The requirements related to the browser are named "Fn" and are described in Section 5.2 The requirements related to the API are named "An" and are described in Section 5.3 The document focuses on requirements related to real-time media streams and data exchange. Requirements related to privacy, signalling between the browser and web server etc. are currently not considered. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Definitions Real-time text: text transmitted while it is being typed or created. The recipient can read the sender's text as it is written, without waiting.  Streams: Real-time communication containing media, e.g. video, audio or real-time text 4. Use-cases 4.1. Introduction This section describes web based real-time communication use-cases, from which requirements are derived. The following considerations are applicable to all use cases: o Clients can be on IPv4-only o Clients can be on IPv6-only o Clients can be on dual-stack o Clients can be on wideband (10s of Mbits/sec) o Clients can be on narrowband (10s to 100s of Kbits/sec) o Clients can be on variable-media-quality networks (wireless) Holmberg, et al. Expires December 29, 2012 [Page 4] Internet-Draft RTC-Web June 2012 o Clients can be on congested networks o Clients can be on firewalled networks with no UDP allowed o Clients can be on networks with any type (as described in RFC4787) of NAT. 4.2. Browser-to-browser use-cases 4.2.1. Simple Video Communication Service with real-time text 4.2.1.1. Description Two or more users have loaded a video communication web application into their browsers, provided by the same service provider, and logged into the service it provides. The web service publishes information about user login status by pushing updates to the web application in the browsers. When one online user selects a peer online user, a 1-1 video communication session between the browsers of the two peers is initiated. Real-time text can also be included. The invited user might accept or reject the session. During session establishment a self-view is displayed, and once the session has been established the video sent from the remote peer is displayed in addition to the self-view. During the session, each user can select to remove and re-insert the self-view as often as desired. Each user can also change the sizes of his/her two video displays during the session. As text is entered by either user in the real-time text area, the characters are nearly immediately presented to the other party. Each user can also pause sending of media (audio, video, real-time text or any combination of them) and mute incoming media It is essential that the communication cannot be wiretapped [RFC2804]. The users are provided with means that allow them to (through a separate, trusted communication channel) verify that the media origins from the other user and has not been manipulated. The user's browsers will reject all incoming media that has been created, injected or in any way modified by any entity not trusted by the service provider. The application gives the users the opportunity to stop it from exposing the IP address to the application of the other user. Any session participant can end the session at any time. The two users may be using communication devices of different makes, with different operating systems and browsers from different vendors. One user has an unreliable Internet connection. It sometimes loses Holmberg, et al. Expires December 29, 2012 [Page 5] Internet-Draft RTC-Web June 2012 packets, and sometimes goes down completely. One user is located behind a Network Address Translator (NAT). The web service monitors the quality of the service (focus on quality of audio and video) the end-users experience. 4.2.1.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26, A27 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 4.2.2.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1). The difference is that one of the users is behind a NAT that blocks UDP traffic. 4.2.2.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F29, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A27 4.2.3. Simple Video Communication Service, FW that only allows http 4.2.3.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1). The difference is that one of the users is behind a FW that only allows http traffic. Note: What about WS? Could it be a viable back-off mechanism? 4.2.3.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F37, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A27 4.2.4. Simple Video Communication Service, global service provider Holmberg, et al. Expires December 29, 2012 [Page 6] Internet-Draft RTC-Web June 2012 4.2.4.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1). What is added is that the service provider is operating over large geographical areas (or even globally). Assuming that ICE will be used, this means that the service provider would like to be able to provide several STUN and TURN servers (via the app) to the browser; selection of which one(s) to use is part of the ICE processing. Other reasons for wanting to provide several STUN and TURN servers include support for IPv4 and IPv6, load balancing and redundancy. 4.2.4.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F31, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A22, A27 4.2.5. Simple Video Communication Service, enterprise aspects 4.2.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 4.2.1). What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application session used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddle the boundary between the internal network and the external. The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want to have the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possibele to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to Holmberg, et al. Expires December 29, 2012 [Page 7] Internet-Draft RTC-Web June 2012 achieve by autoconfiguration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. 4.2.5.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F32, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A27 4.2.6. Simple Video Communication Service, access change 4.2.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1).The difference is that the user changes network access during the session: The communication device used by one of the users have several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. 4.2.6.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F26, F28, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A27 4.2.7. Simple Video Communication Service, QoS 4.2.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 4.2.6). The use of Quality of Service (QoS) capabilities is added: The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. Holmberg, et al. Expires December 29, 2012 [Page 8] Internet-Draft RTC-Web June 2012 4.2.7.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F24, F25, F26, F28, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A27 4.2.8. Simple Video Communication Service with sharing 4.2.8.1. Description This use-case has the audio and video communication of the Simple Video Communication Service use-case (Section 4.2.1). But in addition to this, one of the users can share what is being displayed on her/his screen with a peer. The user can choose to share the entire screen, part of the screen (part selected by the user) or what a selected applicaton displays with the peer. 4.2.8.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F30, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21, A27 4.2.9. Simple Video Communication Service with file exchange 4.2.9.1. Description This use-case has the audio and video communication of the Simple Video Communication Service use-case (Section 4.2.1). But in addition to this, the users can send and receive files stored in the file system of the device used. 4.2.9.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F30, F33, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21, A24, A27 4.2.10. Simple video communication service with inter-operator calling 4.2.10.1. Description Two users have logged into two different web applications, provided by different service providers. The service providers are interconnected by some means, but exchange Holmberg, et al. Expires December 29, 2012 [Page 9] Internet-Draft RTC-Web June 2012 no more information about the users than what can be carried using SIP. NOTE: More profiling of what this means may be needed. For each user Alice who has authorized another user Bob to receive login status information, Alice's service publishes Alice's login status information to Bob. How this authorization is defined and established is out of scope. The same functionality as in the the Simple Video Communication Service use-case (Section 4.2.1) is available. The same issues with connectivity apply. 4.2.10.2. Derived requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F27, F28, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A20, A27 4.2.11. Hockey Game Viewer 4.2.11.1. Description An ice-hockey club uses an application that enables talent scouts to, in real-time, show and discuss games and players with the club manager. The talent scouts use a mobile phone with two cameras, one front facing and one rear facing. The club manager uses a desktop, equipped with one camera, for viewing the game and discussing with the talent scout. Before the game starts, and during game breaks, the talent scout and the manager have a 1-1 video communication. Only the rear facing camera of the mobile phone is used. On the display of the mobile phone, the video of the club manager is shown with a picture-in- picture thumbnail of the rear facing camera (self-view). On the display of the desktop, the video of the talent scout is shown with a picture-in-picture thumbnail of the desktop camera (self-view). When the game is on-going, the talent scout activates the use of the front facing camera, and that stream is sent to the desktop (the stream from the rear facing camera continues to be sent all the time). The video stream captured by the front facing camera (that is capturing the game) of the mobile phone is shown in a big window on the desktop screen, with picture-in-picture thumbnails of the rear facing camera and the desktop camera (self-view). On the display of Holmberg, et al. Expires December 29, 2012 [Page 10] Internet-Draft RTC-Web June 2012 the mobile phone the game is shown (front facing camera) with picture-in-picture thumbnails of the rear facing camera (self-view) and the desktop camera. As the most important stream in this phase is the video showing the game, the application used in the talent scout's mobile sets higher priority for that stream. It is essential that the communication cannot be wiretapped [RFC2804]. 4.2.11.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F20, F34 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17, A23 4.2.12. Multiparty video communication 4.2.12.1. Description In this use-case is the Simple Video Communication Service use-case (Section 4.2.1) is extended by allowing multiparty sessions. No central server is involved - the browser of each participant sends and receives streams to and from all other session participants. The web application in the browser of each user is responsible for setting up streams to all receivers. In order to enhance intelligibility, the web application pans the audio from different participants differently when rendering the audio. This is done automatically, but users can change how the different participants are placed in the (virtual) room. In addition the levels in the audio signals are adjusted before mixing. Another feature intended to enhance the use experience is that the video window that displays the video of the currently speaking peer is highlighted. Real-time text can be exchanged between the parties, and displayed as it is typed. Each video stream received is by default displayed in a thumbnail frame within the browser, but users can change the display size. It is essential that the communication cannot be wiretapped [RFC2804]. Note: What this use-case adds in terms of requirements is capabilities to send streams to and receive streams from several peers concurrently, as well as the capabilities to render the video from all recevied streams and be able to spatialize, level adjust and mix the audio from all received streams locally in the browser. It also adds the capability to measure the audio level/activity. Holmberg, et al. Expires December 29, 2012 [Page 11] Internet-Draft RTC-Web June 2012 4.2.12.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F20, F25, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17, A27 4.2.13. Multiparty on-line game with voice communication 4.2.13.1. Description This use case is based on the previous one. In this use-case, the voice part of the multiparty video communication use case is used in the context of an on-line game. The received voice audio media is rendered together with game sound objects. For example, the sound of a tank moving from left to right over the screen must be rendered and played to the user together with the voice media. Quick updates of the game state is required, and have higher priority than the voice. It is essential that the communication cannot be wiretapped [RFC2804]. Note: the difference regarding local audio processing compared to the "Multiparty video communication" use-case is that other sound objects than the streams must be possible to be included in the spatialization and mixing. "Other sound objects" could for example be a file with the sound of the tank; that file could be stored locally or remotely. 4.2.13.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16, F18, F20, F23, F34 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17, A18, A23 4.2.14. Distributed Music Band 4.2.14.1. Description In this use-case, a music band is playing music while the members are at different physical locations. No central server is used, instead all streams are set up in a mesh fashion. Holmberg, et al. Expires December 29, 2012 [Page 12] Internet-Draft RTC-Web June 2012 Discussion: This use-case was briefly discussed at the Quebec webrtc meeting and it got support. So far the only concrete requirement (A17) derived is that the application must be able to ask the browser to treat the audio signal as audio (in contrast to speech). However, the use case should be further analysed to determine other requirements (could be e.g. on delay mic->speaker, level control of audio signals, etc.). 4.2.14.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A19 4.3. Browser - GW/Server use cases 4.3.1. Telephony terminal 4.3.1.1. Description A mobile telephony operator allows its customers to use a web browser to access their services. After a simple log in the user can place and receive calls in the same way as when using a normal mobile phone. When a call is received or placed, the identity is shown in the same manner as when a mobile phone is used. It is essential that the communication cannot be wiretapped [RFC2804]. Note: With "place and receive calls in the same way as when using a normal mobile phone" it is meant that you can dial a number, and that your mobile telephony operator has made available your phone contacts on line, so they are available and can be clicked to call, and be used to present the identity of an incoming call. If the callee is not in your phone contacts the number is displayed. Furthermore, your call logs are available, and updated with the calls made/ received from the browser. And for people receiving calls made from the web browser the usual identity (i.e. the phone number of the mobile phone) will be presented. 4.3.1.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 Holmberg, et al. Expires December 29, 2012 [Page 13] Internet-Draft RTC-Web June 2012 4.3.2. Fedex Call 4.3.2.1. Description Alice uses her web browser with a service something like Skype to be able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to hear the initial prompts from the fedex IVR and when the IVR says press 1, there should be a way for Alice to navigate the IVR. 4.3.2.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 4.3.3. Video conferencing system with central server 4.3.3.1. Description An organization uses a video communication system that supports the establishment of multiparty video sessions using a central conference server. The browser of each participant send an audio stream (type in terms of mono, stereo, 5.1, ... depending on the equipment of the participant) to the central server. The central server mixes the audio streams (and can in the mixing process naturally add effects such as spatialization) and sends towards each participant a mixed audio stream which is played to the user. The browser of each participant sends video towards the server. For each participant one high resolution video is displayed in a large window, while a number of low resolution videos are displayed in smaller windows. The server selects what video streams to be forwarded as main- and thumbnail videos respectively, based on speech activity. As the video streams to display can change quite frequently (as the conversation flows) it is important that the delay from when a video stream is selected for display until the video can be displayed is short. The organization has an internal network set up with an aggressive firewall handling access to the Internet. If users cannot physically access the internal network, they can establish a Virtual Private Network (VPN). Real-time text can also be exchanged rapidly as typed. It is essential that the communication cannot be wiretapped [RFC2804]. Holmberg, et al. Expires December 29, 2012 [Page 14] Internet-Draft RTC-Web June 2012 All participants are authenticated by the central server, and authorized to connect to the central server. The participants are identified to each other by the central server, and the participants do not have access to each others' credentials such as e-mail addresses or login IDs. Note: This use-case adds requirements on support for fast stream switches F7, on encryption of media and on ability to traverse very restrictive FWs. There exist several solutions that enable the server to forward one high resolution and several low resolution video streams: a) each browser could send a high resolution, but scalable stream, and the server could send just the base layer for the low resolution streams, b) each browser could in a simulcast fashion send one high resolution and one low resolution stream, and the server just selects or c) each browser sends just a high resolution stream, the server transcodes into low resolution streams as required. 4.3.3.2. Derived Requirements F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F17, F19, F20, F39, F40, F41, F42 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17, A27 5. Requirements 5.1. General This section contains the requirements derived from the use-cases in section 4. NOTE: It is assumed that the user applications are executed on a browser. Whether the capabilities to implement specific browser requirements are implemented by the browser application, or are provided to the browser application by the underlying operating system, is outside the scope of this document. 5.2. Browser requirements REQ-ID DESCRIPTION --------------------------------------------------------------- F1 The browser MUST be able to use microphones and cameras as input devices to generate streams. ---------------------------------------------------------------- F2 The browser MUST be able to send streams and data to a peer in the presence of NATs. Holmberg, et al. Expires December 29, 2012 [Page 15] Internet-Draft RTC-Web June 2012 ---------------------------------------------------------------- F3 Transmitted streams and data MUST be rate controlled. ---------------------------------------------------------------- F4 The browser MUST be able to receive, process and render streams and data ("render" does not apply for data) from peers. ---------------------------------------------------------------- F5 The browser MUST be able to render good quality audio and video even in the presence of reasonable levels of jitter and packet losses. TBD: What is a reasonable level? ---------------------------------------------------------------- F6 The browser MUST be able to handle high loss and jitter levels in a graceful way. ---------------------------------------------------------------- F7 The browser MUST support fast stream switches. ---------------------------------------------------------------- F8 The browser MUST detect when a stream from a peer is not received anymore ---------------------------------------------------------------- F9 When there are both incoming and outgoing audio streams, echo cancellation MUST be made available to avoid disturbing echo during conversation. QUESTION: How much control should be left to the web application? ---------------------------------------------------------------- F10 The browser MUST support synchronization of audio and video. QUESTION: How much control should be left to the web application? ---------------------------------------------------------------- F11 The browser MUST be able to transmit streams and data to several peers concurrently. ---------------------------------------------------------------- F12 The browser MUST be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- F13 The browser MUST be able to apply spatialization effects to audio streams. ---------------------------------------------------------------- F14 The browser MUST be able to measure the level in audio streams. Holmberg, et al. Expires December 29, 2012 [Page 16] Internet-Draft RTC-Web June 2012 ---------------------------------------------------------------- F15 The browser MUST be able to change the level in audio streams. ---------------------------------------------------------------- F16 The browser MUST be able to render several concurrent video streams ---------------------------------------------------------------- F17 The browser MUST be able to mix several audio streams. ---------------------------------------------------------------- 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. ---------------------------------------------------------------- F19 Streams and data MUST be able to pass through restrictive firewalls. ---------------------------------------------------------------- F20 It MUST be possible to protect streams and data from wiretapping. ---------------------------------------------------------------- F21 The browser MUST support an audio media format (codec) that is commonly supported by existing telephony services. QUESTION: G.711? ---------------------------------------------------------------- F22 There should be a way to navigate a DTMF based IVR ---------------------------------------------------------------- F23 The browser must be able to send short latency unreliable datagram traffic to a peer browser. ---------------------------------------------------------------- F24 The browser SHOULD be able to take advantage of available capabilities (supplied by network nodes) to prioritize voice, video and data appropriately. ---------------------------------------------------------------- F25 The browser SHOULD use encoding of streams suitable for the current rendering (e.g. video display size) and SHOULD change parameters if the rendering changes during the session ---------------------------------------------------------------- F26 It MUST be possible to move from one network interface to another one ---------------------------------------------------------------- F27 The browser MUST be able to initiate and Holmberg, et al. Expires December 29, 2012 [Page 17] Internet-Draft RTC-Web June 2012 accept a media session where the data needed for establishment can be carried in SIP. ---------------------------------------------------------------- F28 The browser MUST support a baseline audio and video codec ---------------------------------------------------------------- F29 The browser MUST be able to send streams and data to a peer in the presence of NATs that block UDP traffic. ---------------------------------------------------------------- F30 The browser MUST be able to use the screen (or a specific area of the screen) or what a certain application displays on the screen to generate streams. ---------------------------------------------------------------- F31 The browser MUST be able to use several STUN and TURN servers ---------------------------------------------------------------- F32 There browser MUST support that STUN and TURN servers to use are supplied by other entities than the service provided (i.e. the network provider). ---------------------------------------------------------------- F33 The browser must be able to send reliable data traffic to a peer browser. ---------------------------------------------------------------- F34 The browser MUST support priortization of streams and data. ---------------------------------------------------------------- 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. ---------------------------------------------------------------- F36 The browser MUST reject incoming media and data, either modified, created or injected, by any entity not trusted by the site. ---------------------------------------------------------------- F37 The browser MUST be able to send streams and data to a peer in the presence of FWs that only allows http(s) traffic. ---------------------------------------------------------------- F38 The browser MUST be able to collect statistics, related to the transport of audio and video between peers, needed to estimate quality of service. ---------------------------------------------------------------- ---------------------------------------------------------------- F39 The browser MUST be able to handle text entry via applications to generate real-time text streams. ---------------------------------------------------------------- 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. ---------------------------------------------------------------- F42 The browser MUST be able to convey good quality real-time text even in the presence of reasonable levels of jitter and packet losses. Note: Good quality real-time text is defined in ITU-T Recommendation F.700. Reasonable level jitter is max 200 ms for 99% packets. Reasonable level packet loss is 1% measured over more than 1 minute. ---------------------------------------------------------------- Holmberg, et al. Expires December 29, 2012 [Page 18] Internet-Draft RTC-Web June 2012 5.3. API requirements REQ-ID DESCRIPTION ---------------------------------------------------------------- A1 The Web API MUST provide means for the application to ask the browser for permission to use cameras and microphones as input devices. ---------------------------------------------------------------- A2 The Web API MUST provide means for the web application to control how streams generated by input devices are used. ---------------------------------------------------------------- A3 The Web API MUST provide means for the web application to control the local rendering of streams (locally generated streams and streams received from a peer). ---------------------------------------------------------------- A4 The Web API MUST provide means for the web application to initiate sending of stream/stream components to a peer. ---------------------------------------------------------------- A5 The Web API MUST provide means for the web application to control the media format (codec) to be used for the streams sent to a peer. NOTE: The level of control depends on whether the codec negotiation is handled by the browser or the web application. ---------------------------------------------------------------- A6 The Web API MUST provide means for the web application to modify the media format for streams sent to a peer after a media stream has been established. ---------------------------------------------------------------- A7 The Web API MUST provide means for informing the web application of whether the establishment of a stream with a peer was successful or not. ---------------------------------------------------------------- A8 The Web API MUST provide means for the web application to mute/unmute a stream or stream component(s). When a stream is sent to a peer mute status must be preserved in the stream received by the peer. ---------------------------------------------------------------- A9 The Web API MUST provide means for the web application to cease the sending of a stream Holmberg, et al. Expires December 29, 2012 [Page 19] Internet-Draft RTC-Web June 2012 to a peer. ---------------------------------------------------------------- A10 The Web API MUST provide means for the web application to cease processing and rendering of a stream received from a peer. ---------------------------------------------------------------- A11 The Web API MUST provide means for informing the web application when a stream from a peer is no longer received. ---------------------------------------------------------------- A12 The Web API MUST provide means for informing the web application when high loss rates occur. ---------------------------------------------------------------- A13 The Web API MUST provide means for the web application to apply spatialization effects to audio streams. ---------------------------------------------------------------- A14 The Web API MUST provide means for the web application to detect the level in audio streams. ---------------------------------------------------------------- A15 The Web API MUST provide means for the web application to adjust the level in audio streams. ---------------------------------------------------------------- A16 The Web API MUST provide means for the web application to mix audio streams. ---------------------------------------------------------------- A17 For each stream generated, the Web API MUST provide an identifier that is accessible by the application. The identifier MUST be accessible also for a peer receiving that stream and MUST be unique relative to all other stream identifiers in use by either party. ---------------------------------------------------------------- A18 The Web API MUST provide a mechanism for sending and receiving isolated discrete chunks of data. ---------------------------------------------------------------- A19 The Web API MUST provide means for the web application indicate the type of audio signal (speech, audio)for audio stream(s)/stream component(s). ---------------------------------------------------------------- A20 It must be possible for an initiator or a responder Web application to indicate the types of media he's willing to accept incoming streams for when setting up a connection (audio, Holmberg, et al. Expires December 29, 2012 [Page 20] Internet-Draft RTC-Web June 2012 video, other). The types of media he's willing to accept can be a subset of the types of media the browser is able to accept. ---------------------------------------------------------------- A21 The Web API MUST provide means for the application to ask the browser for permission to the screen, a certain area on the screen or what a certain application displays on the screen as input to streams. ---------------------------------------------------------------- A22 The Web API MUST provide means for the application to specify several STUN and/or TURN servers to use. ---------------------------------------------------------------- A23 The Web API MUST provide means for the application to specify the priority to apply for outgoing streams and data. ---------------------------------------------------------------- A24 The Web API MUST provide a mechanism for sending and receiving files. ---------------------------------------------------------------- A25 It must be possible for the application to refrain from exposing the IP address ---------------------------------------------------------------- A26 The Web API MUST provide means for the application to obtain the statistics (related to transport, and collected by the browser) needed to estimate quality of service. ---------------------------------------------------------------- A27 The Web API MUST provide a mechanisms for handling real-time text among the streams. ---------------------------------------------------------------- 6. IANA Considerations TBD 7. Security Considerations 7.1. Introduction A malicious web application might use the browser to perform Denial Of Service (DOS) attacks on NAT infrastructure, or on peer devices. Also, a malicious web application might silently establish outgoing, and accept incoming, streams on an already established connection. Based on the identified security risks, this section will describe security considerations for the browser and web application. Holmberg, et al. Expires December 29, 2012 [Page 21] Internet-Draft RTC-Web June 2012 7.2. Browser Considerations The browser is expected to provide mechanisms for getting user consent to use device resources such as camera and microphone. The browser is expected to provide mechanisms for informing the user that device resources such as camera and microphone are in use ("hot"). The browser is expected to provide mechanisms for users to revise and even completely revoke consent to use device resources such as camera and microphone. The browser is expected to provide mechanisms for getting user consent to use the screen (or a certain part of it) or what a certain application displays on the screen as source for streams. The browser is expected to provide mechanisms for informing the user that the screen, part thereof or an application is serving as a stream source ("hot"). The browser is expected to provide mechanisms for users to revise and even completely revoke consent to use the screen, part thereof or an application is serving as a stream source. The browser is expected to provide mechanisms in order to assure that streams are the ones the recipient intended to receive. The browser is expected to provide mechanisms that allows the users to verify that the streams received have not be manipulated (F35). The browser needs to ensure that media is not sent, and that received media is not rendered, until the associated stream establishment and handshake procedures with the remote peer have been successfully finished. The browser needs to ensure that the stream negotiation procedures are not seen as Denial Of Service (DOS) by other entities. 7.3. Web Application Considerations The web application is expected to ensure user consent in sending and receiving media streams. 8. Additional use-cases Several additional use-cases have been discussed. At this point Holmberg, et al. Expires December 29, 2012 [Page 22] Internet-Draft RTC-Web June 2012 these use-cases are not included as requirement deriving use-cases for different reasons (lack of documentation, overlap with existing use-cases, lack of consensus). For completeness these additional use-cases are listed below: 1. Use-cases regarding different situations when being invited to a "session", e.g. browser open, browser open but another tab active, browser open but active in session, browser closed, .... (Matthew Kaufman); discussed at webrtc meeting 2. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/ rtcweb/current/msg00525.html, followed up by Stephan Wenger 3. Local Recording and Remote recording (John): Discussed a _lot_ on the mail lists (rtcweb as well as public-webrtc) lAugust and September 2011. Concrete proposal: http://www.ietf.org/ mail-archive/web/rtcweb/current/msg01006.html (remote) and http: //www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html (local) 4. Emergency access for disabled (Bernard Aboba) http:// www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 5. Clue use-cases (Roni Even) http://tools.ietf.org/html/ draft-ietf-clue-telepresence-use-cases-01 6. Rohan red cross (Cullen Jennings); http://www.ietf.org/ mail-archive/web/rtcweb/current/msg00323.html 7. Security camera/baby monitor usage http://www.ietf.org/ mail-archive/web/rtcweb/current/msg00543.html 8. Large multiparty session http://www.ietf.org/mail-archive/web/ rtcweb/current/msg00530.html 9. Call center http://www.ietf.org/mail-archive/web/rtcweb/current/ msg04203.html 10. Enterprise policies http://www.ietf.org/mail-archive/web/rtcweb/ current/msg04271.html 11. Low-complex multiparty central node http://www.ietf.org/ mail-archive/web/rtcweb/current/msg04430.html 12. Multiparty central node that is not allowed to decipher http:// www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html 13. Enable company coop without being able to decipher http:// www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html 9. Acknowledgements Dan Burnett has reviewed and proposed a lot of things that enhances the document. Most of this has been incorporated in rev -05. Stephan Wenger has provided a lot of useful input and feedback, as well as editorial comments. Harald Alvestrand and Ted Hardie have provided comments and feedback on the draft. Holmberg, et al. Expires December 29, 2012 [Page 23] Internet-Draft RTC-Web June 2012 Harald Alvestrand and Cullen Jennings have provided additional use- cases. Thank You to everyone in the RTCWEB community that have provided comments, feedback and improvement proposals on the draft content. 10. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. o Removed informal ref webrtc_req; that document has been abandoned by the W3C webrtc WG. o Added use-case where one user is behind a FW that only allows http; derived req. F37. o Changed F24 slightly; MUST-> SHOULD, inserted "available". o Added a clause to "Simple video communication service" saying that the service provider monitors the quality of service, and derived reqs F38 and A26. Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 o Added "and data exchange" to 1. Introduction. o Removed cone and symmetric NAT from 4.1 Introduction, refers to RFC4787 instead. o Added text on enabling verifyication of that the media has not been manipulated by anyone to use-case "Simple Video Communication Service", derived req. F35 o Added text on that the browser should reject media (data) that has been created/injected/modified by non-trusted party, derived req. F36 o Added text on enabling the app to refrain from revealing IP address to use-case "Simple Video Communication Service", derived req. A25 o Added use-case "Simple Video Communication Service with file exchange", derived reqs F33 and A24 o Added priority of video streams to "Hockey game viewer" use case, added priority of data to "on-line game use-case", derived reqs F34 and A23 o In F22, "the IVR" -> "a DTMF based IVR". o Updated req F23 to clarify that requirements such as NAT traversal, prtoection from eavesdropping, rate control applies also to datagram. Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 Holmberg, et al. Expires December 29, 2012 [Page 24] Internet-Draft RTC-Web June 2012 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> A22) Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 o Added use-case "global service provider", derived reqs associated with several STUN/TURN servers o Added use-case "enterprise aspects", derived req associated with enabling the network provider to supply STUN and TURN servers o The requirements from the above are ICE specific and labeled accordingly o Separated the requirements phrased like "processing such as pan, mix and render" for audio to be specific reqs on spatialization, level measurement, level adjustment and mixing (discussed on the lists in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01648.html and http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/ 0102.html) o Added use-case on sharing as decided in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 o Added the list of common considerations proposed in mail http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html to the Introduction of the use-case section Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 o Most changes based on the input from Dan Burnett http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html o Many editorial changes o 4.2.1.1 Clarified o Some clarification added to 4.3.1.1 as a note o F-requirements updated (see reply to Dan's mail). o Almost all A-requirements updated to start "The Web API MUST provide ..." o A8 removed, A9 rephrased to cover A8 and old A9 o A15 rephrased o For more details, and discussion, look att the response to Dan's mail http://www.ietf.org/mail-archive/web/rtcweb/current/msg01177.html Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 o Editorials o Changed when the self-view is displayed in 4.2.1.1, and added words about allowing users to remove and re-insert it. Holmberg, et al. Expires December 29, 2012 [Page 25] Internet-Draft RTC-Web June 2012 o Clarified 4.2.6.1 o Removed the "mono" stuff from 4.2.7.1 o Added that communication should not be possible to eavesdrop to most use cases - and req. F17 o Re-phrased 4.3.3.1 to not describe the technical solution so much, and removed "stereo" stuff. Solution possibilities are now in a note. o Re-inserted API requirements after discussion in the W3C webrtc WG. (Re-phrased A15 and added A18 compared to version -02). Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 o Removed desrciption/list of API requirements, instead o Reference to W3C webrtc_reqs document for API requirements Changes from draft-ietf-rtcweb-ucreqs-01 o Changed Intended status to Information o Changed "Ipr" to "trust200902" o Added use case "Simple video communication service, NAT/FW that blocks UDP", and derived new req F26 o Added use case "Distributed Music Band" and derived new req A17 o Added F24 as requirement derived from use case "Simple video communication service with inter-operator calling" o Added section "Additional use cases" o Added text about ID handling to multiparty with central server use case o Re-phrased A1 slightly Changes from draft-ietf-rtcweb-ucreqs-00 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ Server); removed some specific use cases and added them instead as flavors to the base use case (Simple video communciation) o - Changed the fromulation of F19 o - Removed the requirement on an API for DTMF o - Removed "FX3: There SHOULD be a mapping of the minimum needed data for setting up connections into SIP, so that the restriction to SIP-carriable data can be verified. Not a rew on the browser but rather on a document" o - (see http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html for more details) o -Added text on informing user of that mic/cam is being used and that it must be possible to revoce permission to use them in section 7. Changes from draft-holmberg-rtcweb-ucreqs-01 Holmberg, et al. Expires December 29, 2012 [Page 26] Internet-Draft RTC-Web June 2012 o - Draft name changed to draft-ietf-rtcweb-ucreqs o - Use-case grouping introduced o - Additional use-cases added o - Additional reqs added (derived from use cases): F19-F25, A16-A17 Changes from draft-holmberg-rtcweb-ucreqs-00 o - Mapping between use-cases and requirements added (Harald Alvestrand, 090311) o - Additional security considerations text (Harald Alvestrand, 090311) o - Clarification that user applications are assumed to be executed by a browser (Ted Hardie, 080311) o - Editorial corrections and clarifications 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 11.2. Informative References Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Stefan Hakansson Ericsson Laboratoriegrand 11 Lulea 97128 Sweden Email: stefan.lk.hakansson@ericsson.com Holmberg, et al. Expires December 29, 2012 [Page 27] Internet-Draft RTC-Web June 2012 Goran AP Eriksson Ericsson Farogatan 6 Stockholm 16480 Sweden Email: goran.ap.eriksson@ericsson.com Holmberg, et al. Expires December 29, 2012 [Page 28] --------------050908010405050107070304-- From goran.ap.eriksson@ericsson.com Sun Nov 18 01:00:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8621F847C for ; Sun, 18 Nov 2012 01:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 x9JRdDRbT3To for ; Sun, 18 Nov 2012 01:00:43 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66D2A21F8473 for ; Sun, 18 Nov 2012 01:00:41 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-70-50a8a3b8d1e3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 96.0C.11564.8B3A8A05; Sun, 18 Nov 2012 10:00:40 +0100 (CET) Received: from ESESSHC014.ericsson.se (153.88.183.60) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 18 Nov 2012 10:00:40 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.001; Sun, 18 Nov 2012 10:00:40 +0100 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [rtcweb] Text communication requirements for RTCWEB Thread-Index: AQHNxRwISjtXZCeXlk2VH8Yk4Wqse5fuoH+AgACEXQCAACdIOg== Date: Sun, 18 Nov 2012 09:00:39 +0000 Message-ID: References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> <50A81ED2.9010604@omnitor.se> , <50A890D4.800@omnitor.se> In-Reply-To: <50A890D4.800@omnitor.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B1164502806C4A79A68ABC51A64F7772ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvje6OxSsCDD780rJY8focu8WO92dY LNb+a2d3YPZYsuQnk8fExZ+YPSY/bmMOYI7isklJzcksSy3St0vgyth77i9bwVW/iquX29kb GN84dTFyckgImEjM6F7EAmGLSVy4t56ti5GLQ0jgJKPEvpcPWSCcnYwS9+9ugMosYZTYteox I0gLm4C3xLQVZ1lBbBEBV4n/lx8yg9jMQPa5mVOYQGxhAQeJBWfmsUDUOErc6J7HBGE7SUz5 OYsdxGYRUJVo+bgUKM7BwStgL7HmdRLErgNMEn9a/oHVcwqoSXTPPgI2h1FAVuL+93ssELvE JW49mc8E8YKAxJI955khbFGJl4//sULUJEsc/34azOYVEJQ4OfMJWK+QgLbEhP5n7BMYxWYh GTULScssJC0QcT2JG1OnsEHY2hLLFr5mhrB1JWb8O8SCLL6AkX0VI3tuYmZOernhJkZgDB7c 8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJz68s5iDdZD WqandyYVs9+b+yP4Jduxi/v3BRr7P5q27kiOf9KehI1JF7f3VQglnKr6L5U9rf9cgSrjv8X3 u/dd6TcUjr5+Qy149S+dIhOPTcq9L3w6ZIrZXi5cvOD2go1bmc46bK372L7s6/JXuQnS2Yan 3/Pw65gvypt294uujL1rx6yS+ROVWIozEg21mIuKEwFpectDjwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 09:00:44 -0000 --_000_B1164502806C4A79A68ABC51A64F7772ericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A diff would have been better but I'll look into the proposal. One note though- You have added the real time text into the basic video cha= t example. The way this was structured was to move from basic-atomic- use c= ases, adding complexity such as more/other media&data streams in separate u= se cases. I would like to stick to that approach. Any thoughts about that. Regards G=F6ran Sent from my iPad On 18 nov 2012, at 08:40, "Gunnar Hellstr=F6m" > wrote: On 2012-11-18 00:46, Eric Rescorla wrote: On Sat, Nov 17, 2012 at 3:33 PM, Gunnar Hellstr=F6m > wrote: I have proposals for adding real-time text to the use cases document. I hope it is OK with a word file with changemarks to show the change propos= als. (attached ) That's really pretty hard to use. Can you provide some sort of text diff instead? How about the attached version as a start. You can do a diff against the -09 version. The main changes are in -The definitions -Use case simple video -Use case multi-part video -Use case multi-part video conference -Requirements F39 - F42 -Requirement A27 -Many requirement lists in use cases. /Gunnar -Ekr The new medium is proposed to be added straight into current use cases. /Gunnar On 2012-11-13 11:20, Gunnar Hellstr=F6m wrote: I am of course willing to contribute. Gunnar On 2012-11-13 10:55, Harald Alvestrand wrote: On 11/13/2012 09:55 AM, Olle E. Johansson wrote: 12 nov 2012 kl. 13:15 skrev Harald Alvestrand >: I would prefer this to be added as a separate specification, rather than do= ne at this time. The reason being that this should be relatively easy to add on top of the d= ata channel functionality, but will definitely take some time to specify, s= o should not be on the critical path for this round of specifications. T.140 is a codec in the RTP flow and is implemented in Asterisk and a coup= le of Video SIP phones. I see no reason to move it to the data channel, that would limit interopera= bility. Much easier - and faster - to implement in the RTP subsystem as it is alrea= dy covered by SDP offer/answer. Anything is possible, if someone is willing to do it. Olle and Gunnar, can you undertake to write a complete specification for ho= w to use T.140 with RTCWEB, including how it should fit in with the API spe= cification, and whether or not it supports the needs that Gunnar has claime= d for text services? I don't understand T.140 - so I can't do the work. Someone who wants it sho= uld. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_B1164502806C4A79A68ABC51A64F7772ericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A diff would have been better but I'll look into the proposal.

One note though- You have added the real time text into the basic vide= o chat example. The way this was structured was to move from basic-atomic- = use cases, adding complexity such as more/other media&data streams in s= eparate use cases.

I would like to stick to that approach. Any thoughts about that.

Regards
G=F6ran

Sent from my iPad

On 18 nov 2012, at 08:40, "Gunnar Hellstr=F6m" <gunnar.hellstrom@omnitor.se> wrote:=

On 2012-11-18 00:46, Eric Rescorla wrote:

On Sat, Nov 17, 2012 at 3:33 PM, Gunnar Hellstr= =F6m <gunnar.hellstrom@omnitor.se> wrote:
I have proposals for adding real-time text to the use cases document.<= br> I hope it is OK with a word file with changemarks to show the change propos= als. (attached )

That's really pretty hard to use. Can you provide some sort of text di= ff
instead?

How about the attached version as a start.
You can do a diff against the -09 version.

The main changes are in
-The definitions
-Use case simple video
-Use case multi-part video
-Use case multi-part video conference
-Requirements F39 - F42
-Requirement A27
-Many requirement lists in use cases.

/Gunnar
-Ekr
 
The new medium is proposed to be added straight into current use cases= .


/Gunnar


On 2012-11-13 11:20, Gunnar Hellstr=F6m wrote:
I am of course willing to contribute.

Gunnar


On 2012-11-13 10:55, Harald Alvestrand wrote:
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:

12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alv= estrand.no>:

I would prefer this to be added as a separate specification, rather th= an done at this time.
The reason being that this should be relatively easy to add on top of the d= ata channel functionality, but will definitely take some time to specify, s= o should not be on the critical path for this round of specifications.
T.140 is a codec in the  RTP flow and is implemented in Asterisk and a= couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit inter= operability.

Much easier - and faster - to implement in the RTP subsystem as it is = already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for ho= w to use T.140 with RTCWEB, including how it should fit in with the API spe= cification, and whether or not it supports the needs that Gunnar has claime= d for text services?

I don't understand T.140 - so I can't do the work. Someone who wants it sho= uld.



_______________________________________________
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


<draft-ietf-rtcweb-use-cases-and-requirements-09 plus rtt integrate= d.txt>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_B1164502806C4A79A68ABC51A64F7772ericssoncom_-- From randell-ietf@jesup.org Sun Nov 18 01:46:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2145221F8461 for ; Sun, 18 Nov 2012 01:46:52 -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 dyzo4ynLcLHm for ; Sun, 18 Nov 2012 01:46:51 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 32B6621F841C for ; Sun, 18 Nov 2012 01:46:51 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2444 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Ta1Sk-00042U-Bn for rtcweb@ietf.org; Sun, 18 Nov 2012 03:46:50 -0600 Message-ID: <50A8AE7F.4060003@jesup.org> Date: Sun, 18 Nov 2012 04:46:39 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A5682E.2060103@alum.mit.edu> <50A83222.6000503@jesup.org> <50A888A0.5040208@omnitor.se> In-Reply-To: <50A888A0.5040208@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Nov 2012 09:46:52 -0000 On 11/18/2012 2:05 AM, Gunnar Hellström wrote: > On 2012-11-18 01:56, Randell Jesup wrote: >> And SCTP has buffer-blocking issues still (they're working on a >> draft): large messages must be delivered before it will send a >> different message, so if I send a 10MB file, no audio or video would >> get through until it was done. > Note: that was in reply to "why not do audio and video over DataChannels?" > Real-time text is also time-critical, even if less than audio and > video. One second end to end is good. Two seconds is usable. Long > occasional blocking disrupts the conversation and is dangerous in > emergency situations. That is one reason why RTP was selected > initially as the transport. > > That seems to be a good reason for doing it again on RTP. Or use partially-reliable/unreliable DataChannels, though I should note that if a reliable channel can't deliver the message, an unreliable channel with hand-rolled partial-reliability (i.e. RTT over RTP) is unlikely to do better (or much better). However, lack of blocking means loss of a doesn't mean b is blocked from appearing, so any unreliable channel has an advantage over an in-order reliable channel. T.140 over a partially-reliable datachannel (or maybe an out-of-order reliable channel) is likely to be the equivalent (or better) to RFC 4351. The real question here is "*must* it be built into the browser", or is implementation in JS enough, since many/most uses of PeerConnection will not be interested in RTT? If JS is enough, that points strongly to DataChannels. I'll also note that rendering the text must be done in JS anyways, so we'd need to surface an API to pass it to the JS code, and the JS would need to implement a UI for it to be usable. If transparent interop without a gateway is needed (though that almost certainly fails for other reasons), then RFC 4351 is needed in the browser. If a gateway is used, and the data over the DataChannel is T.140 or close, than the gateway *could* put that into the audio stream - IF the media flows through the gateway, which it might not. -- Randell Jesup randell-ietf@jesup.org From silviapfeiffer1@gmail.com Sun Nov 18 01:57:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77821F8466 for ; Sun, 18 Nov 2012 01:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.983, 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 OR2eBAsJaA55 for ; Sun, 18 Nov 2012 01:57:35 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF1721F84A1 for ; Sun, 18 Nov 2012 01:57:35 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so1866374vcb.31 for ; Sun, 18 Nov 2012 01:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=43Mukwk2OyVH4LX1zoukCudh2/dw/drv5mLUMxBTcCk=; b=P56T3xo15olRsHJBUB1U8JrJc6QF3a7RsCFHZWA83UiKmB6DRbjKUqAevzpLwT6+NW jXXkLEvKLGIEYzo+bGauN8VSJW+6KdQNsga6CY5cTHpIlh4KHLoju6cmpJiSihTtZwg8 Ye/hRInagF3vxMziLllgr0v+Y+sOXOMkqNNhYf6TdGsqaH7GjZ3RMW7aOKthSyjSqeny WxfP10p44+frpdoZqV7lpLjOkWl0nijWe2+NY8joKOkeKoOy5ut6AwjFfISV/ZnmtZ3M 5qBxEk/zp0HiJv+2zJ9bwalQkxzBM3Ie+TRSssnXaO3ByGajQ5VNsQ41uGsuLD0J/WbL vjlQ== Received: by 10.58.137.229 with SMTP id ql5mr12690479veb.11.1353232654517; Sun, 18 Nov 2012 01:57:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.78.135 with HTTP; Sun, 18 Nov 2012 01:57:14 -0800 (PST) In-Reply-To: <50A8AE7F.4060003@jesup.org> References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A1385F.4000709@jesup.org> <50A14328.9060002@stpeter.im> <50A5682E.2060103@alum.mit.edu> <50A83222.6000503@jesup.org> <50A888A0.5040208@omnitor.se> <50A8AE7F.4060003@jesup.org> From: Silvia Pfeiffer Date: Sun, 18 Nov 2012 20:57:14 +1100 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=047d7b677816abc55d04cec207ce Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Nov 2012 09:57:36 -0000 --047d7b677816abc55d04cec207ce Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Nov 18, 2012 at 8:46 PM, Randell Jesup wrot= e: > On 11/18/2012 2:05 AM, Gunnar Hellstr=F6m wrote: > >> On 2012-11-18 01:56, Randell Jesup wrote: >> >>> And SCTP has buffer-blocking issues still (they're working on a draft): >>> large messages must be delivered before it will send a different messag= e, >>> so if I send a 10MB file, no audio or video would get through until it = was >>> done. >>> >> >> > Note: that was in reply to "why not do audio and video over DataChannels?= " > > > Real-time text is also time-critical, even if less than audio and video. >> One second end to end is good. Two seconds is usable. Long occasional >> blocking disrupts the conversation and is dangerous in emergency >> situations. That is one reason why RTP was selected initially as the >> transport. >> >> That seems to be a good reason for doing it again on RTP. >> > > Or use partially-reliable/unreliable DataChannels, though I should note > that if a reliable channel can't deliver the message, an unreliable chann= el > with hand-rolled partial-reliability (i.e. RTT over RTP) is unlikely to d= o > better (or much better). However, lack of blocking means loss of a doesn'= t > mean b is blocked from appearing, so any unreliable channel has an > advantage over an in-order reliable channel. T.140 over a > partially-reliable datachannel (or maybe an out-of-order reliable channel= ) > is likely to be the equivalent (or better) to RFC 4351. > > The real question here is "*must* it be built into the browser", or is > implementation in JS enough, since many/most uses of PeerConnection will > not be interested in RTT? If JS is enough, that points strongly to > DataChannels. I'll also note that rendering the text must be done in JS > anyways, this is not the case for captions: there already exists a specification for rendering of captions over the top of video in HTML, so not all RTT must be rendered in JS. Also, it would be possible to classify RTT and develop standard display mechanisms for specific types - e.g. a "chat text" type that is rendered in a "chat box". > so we'd need to surface an API to pass it to the JS code, and the JS woul= d > need to implement a UI for it to be usable. If transparent interop witho= ut > a gateway is needed (though that almost certainly fails for other reasons= ), > then RFC 4351 is needed in the browser. If a gateway is used, and the da= ta > over the DataChannel is T.140 or close, than the gateway *could* put that > into the audio stream - IF the media flows through the gateway, which it > might not. Regards, Silvia. --047d7b677816abc55d04cec207ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 18, 2012 at 8:46 PM, Randell= Jesup <randell-ietf@jesup.org> wrote:
On 11/18/2012 2:05 AM, Gunnar Hellstr=F6m wrote:
On 2012-11-18 01:56, Randell Jesup wrote:
And SCTP has buffer-blocking issues still (they're working on a draft):= large messages must be delivered before it will send a different message, = so if I send a 10MB file, no audio or video would get through until it was = done.


Note: that was in reply to "why not do audio and video over DataChanne= ls?"


Real-time text is also time-critical, even if less than audio and video. On= e second end to end is good. Two seconds is usable. Long occasional blockin= g disrupts the conversation and is dangerous in emergency situations. That = is one reason why RTP was selected initially as the transport.

That seems to be a good reason for doing it again on RTP.

Or use partially-reliable/unreliable DataChannels, though I should note tha= t if a reliable channel can't deliver the message, an unreliable channe= l with hand-rolled partial-reliability (i.e. RTT over RTP) is unlikely to d= o better (or much better). However, lack of blocking means loss of a doesn&= #39;t mean b is blocked from appearing, so any unreliable channel has an ad= vantage over an in-order reliable channel. =A0T.140 over a partially-reliab= le datachannel (or maybe an out-of-order reliable channel) is likely to be = the equivalent (or better) to RFC 4351.

The real question here is "*must* it be built into the browser", = or is implementation in JS enough, since many/most uses of PeerConnection w= ill not be interested in RTT? =A0If JS is enough, that points strongly to D= ataChannels. =A0I'll also note that rendering the text must be done in = JS anyways,

this is not the case for captions: there already exists a specific= ation for rendering of captions over the top of video in HTML, so not all R= TT must be rendered in JS.

Also, it would be possible to classify RT= T and develop standard display mechanisms for specific types - e.g. a "= ;chat text" type that is rendered in a "chat box".

=A0
so we'd need to surface an= API to pass it to the JS code, and the JS would need to implement a UI for= it to be usable. =A0If transparent interop without a gateway is needed (th= ough that almost certainly fails for other reasons), then RFC 4351 is neede= d in the browser. =A0If a gateway is used, and the data over the DataChanne= l is T.140 or close, than the gateway *could* put that into the audio strea= m - IF the media flows through the gateway, which it might not.

Regards,
Silvia.
=A0
--047d7b677816abc55d04cec207ce-- From gunnar.hellstrom@omnitor.se Sun Nov 18 02:20:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87021F841A for ; Sun, 18 Nov 2012 02:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TKm1pigUh+u for ; Sun, 18 Nov 2012 02:20:50 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 96E9821F8417 for ; Sun, 18 Nov 2012 02:20:49 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 18 Nov 2012 11:20:37 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 80D463A140 for ; Sun, 18 Nov 2012 11:20:37 +0100 (CET) Message-ID: <50A8B676.2070501@omnitor.se> Date: Sun, 18 Nov 2012 11:20:38 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> In-Reply-To: <50A218FF.9050104@alvestrand.no> Content-Type: multipart/alternative; boundary="------------040703060806030000080009" Subject: Re: [rtcweb] Text communication SDP in RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 10:20:51 -0000 This is a multi-part message in MIME format. --------------040703060806030000080009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For SDP, changes in line with the example below are proposed to get real-time text included in draft-nandakumar-rtcweb-sdp ---------------------- 5. WebRTC Session Description Examples A typical web based real-time multimedia communication session can be characterized as below: It has zero or more Media streams with any combination of Audio, Video and Real-time text MAY contain zero or more non-media data streams All the streams are secured with DTLS/SRTP ICE processing for NAT Traversal Sessions over IPv4-only, IPv6-only, dual-stack based clients. .... 5.1. Secure Two-Way Audio,Video,Real-time text and Data with RTCP Feedback This use-case allows two users to participate in a two-way communication session securely on their WebRTC enabled Web browsers. title WebRTC Session - 2-Way Secure Audio,Video,RTT with RTCP Feedback Alice->Bob: Offer(Audio:G.711,Opus,iLBC Video:H.264,VP8 RTT:T.140) Bob->Alice: Answer(Audio:Opus,DTMF Video:H.264 RTT:T.140) Alice->Bob: Two-way Opus Audio, H.264 Video, T.140 Real-time text note right of Alice Session also suports RTP/RTCP Mux, RTCP feedback (nack,pli) end note More specifically, this use-case demonstrates following aspects of a WebRTC session SRTP with DTLS based encryption RTP and RTCP Muxing RTCP based feedback and reduced size support ICE processing for NAT Traversal Audio Codec Offered : PCMU, Opus, iLBC Audio Codec Answered : Opus Video Codecs Offered: H.264, VP8 Video Codecs Answered: H.264 Real-time text Offered: T.140 Real-time text Answered: T.140 Data Channel Support The tables (4.1 and 4.2) below capture in detail, the initial SDP Offer and Answer messages exchanged. +------------------------------------------+------------------------+ | SDP Contents | RFC#/Notes | +------------------------------------------+------------------------+ /------Add the following after video SDP and before SCTP SDP-----/ | m=text 60109 RTP/SAVPF 105 104 | [RFC4566] | | c= IN IP4 24.23.204.141 | [RFC4566] | | a=rtpmap:105 RED/1000 | [RFC4102] | | a=rtpmap:104 T140/1000 | [RFC4103] | | a=fmtp:105 104/104/104 | [RFC4103] | | a=sendrecv | [RFC3264] - Alice can | | | send and recv rtt | | a=rtcp-mux | [RFC5761] - Alice can | | | perform RTP/RTCP | | | Muxing on port 54609 | | a=candidate:0 1 UDP 2113667327 | [RFC5245] - Host ICE | | 192.168.1.4 60109 typ host | Candidate | | a=candidate:1 1 UDP 694302207 | [RFC5245] - Server | | 24.23.204.141 60109 typ srflx raddr | Reflexive ICE | | 192.168.1.4 rport 60109 | Candidate for the | | | above host candidate | | a=candidate:0 2 UDP 2113667326 | [RFC5245] - Second | | 192.168.1.4 61778 typ host | Host Candidate | | a=candidate:1 2 UDP 1694302206 | [RFC5245] -Server | | 24.23.204.141 61778 typ srflx raddr | Reflexive Candidate | | 192.168.1.4 rport 61778 | for the Second Host | | | Candidate | | a=rtcp-fb:105 nack | [RFC5104] - Indicates | | | NACK RTCP feedback | | | support | /-------End of addition for real-time text---------------------/ +------------------------------------------+------------------------+ Table 1: 4.1 SDP Offer And similarly for the SDP answer and the other examples. If that is the accepted principle, we can go ahead and propose the complete changes. /Gunnar ----------------------------------------- On 2012-11-13 10:55, Harald Alvestrand wrote: > On 11/13/2012 09:55 AM, Olle E. Johansson wrote: >> >> 12 nov 2012 kl. 13:15 skrev Harald Alvestrand > >: >> >>> I would prefer this to be added as a separate specification, rather >>> than done at this time. >>> The reason being that this should be relatively easy to add on top >>> of the data channel functionality, but will definitely take some >>> time to specify, so should not be on the critical path for this >>> round of specifications. >> T.140 is a codec in the RTP flow and is implemented in Asterisk and >> a couple of Video SIP phones. >> I see no reason to move it to the data channel, that would limit >> interoperability. >> >> Much easier - and faster - to implement in the RTP subsystem as it is >> already covered by SDP offer/answer. >> > Anything is possible, if someone is willing to do it. > > Olle and Gunnar, can you undertake to write a complete specification > for how to use T.140 with RTCWEB, including how it should fit in with > the API specification, and whether or not it supports the needs that > Gunnar has claimed for text services? > > I don't understand T.140 - so I can't do the work. Someone who wants > it should. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040703060806030000080009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
For SDP, changes in line with the example below are proposed to get real-time text included in draft-nandakumar-rtcweb-sdp

----------------------
5.  WebRTC Session Description Examples

   A typical web based real-time multimedia communication session can be
   characterized as below:

      It has zero or more Media
      streams with any combination of Audio, Video and Real-time text
      MAY contain zero or more non-media data streams
      All the streams are secured with DTLS/SRTP
      ICE processing for NAT Traversal
      Sessions over IPv4-only, IPv6-only, dual-stack based clients.
....
5.1.  Secure Two-Way Audio,Video, Real-time text and Data with RTCP Feedback

   This use-case allows two users to participate in a two-way
   communication session securely on their WebRTC enabled Web browsers.

   title WebRTC Session - 2-Way Secure Audio,Video,RTT with RTCP Feedback
   Alice->Bob: Offer(Audio:G.711,Opus,iLBC Video:H.264,VP8 RTT:T.140)
   Bob->Alice: Answer(Audio:Opus,DTMF Video:H.264 RTT:T.140)
   Alice->Bob: Two-way Opus Audio, H.264 Video, T.140 Real-time text
   note right of Alice
     Session also suports RTP/RTCP Mux, RTCP feedback (nack,pli)
   end note

   More specifically, this use-case demonstrates following aspects of a
   WebRTC session
      SRTP with DTLS based encryption
      RTP and RTCP Muxing
      RTCP based feedback and reduced size support
      ICE processing for NAT Traversal
      Audio Codec Offered :  PCMU, Opus, iLBC
      Audio Codec Answered :  Opus
      Video Codecs Offered:  H.264, VP8
      Video Codecs Answered:  H.264
      Real-time text Offered: T.140
      Real-time text Answered: T.140
      Data Channel Support
   The tables (4.1 and 4.2) below capture in detail, the initial SDP
   Offer and Answer messages exchanged.

   +------------------------------------------+------------------------+
   | SDP Contents                             | RFC#/Notes             |
   +------------------------------------------+------------------------+
/------Add the following after video SDP and before SCTP SDP-----/  

   | m=text 60109 RTP/SAVPF 105 104           | [RFC4566]              |
   | c= IN IP4 24.23.204.141                  | [RFC4566]              |
   | a=rtpmap:105 RED/1000                    | [RFC4102]              |
   | a=rtpmap:104 T140/1000                   | [RFC4103]              |
   | a=fmtp:105 104/104/104                   | [RFC4103]              |
   | a=sendrecv                               | [RFC3264] - Alice can  |
   |                                          | send and recv rtt      |
   | a=rtcp-mux                               | [RFC5761] - Alice can  |
   |                                          | perform RTP/RTCP       |
   |                                          | Muxing on port 54609   |
   | a=candidate:0 1 UDP 2113667327           | [RFC5245] - Host ICE   |
   | 192.168.1.4 60109 typ host               | Candidate              |
   | a=candidate:1 1 UDP 694302207            | [RFC5245] - Server     |
   | 24.23.204.141 60109 typ srflx raddr      | Reflexive ICE          |
   | 192.168.1.4 rport 60109                  | Candidate for the      |
   |                                          | above host candidate   |
   | a=candidate:0 2 UDP 2113667326           | [RFC5245] - Second     |
   | 192.168.1.4 61778 typ host               | Host Candidate         |
   | a=candidate:1 2 UDP 1694302206           | [RFC5245] -Server      |
   | 24.23.204.141 61778 typ srflx raddr      | Reflexive Candidate    |
   | 192.168.1.4 rport 61778                  | for the Second Host    |
   |                                          | Candidate              |
   | a=rtcp-fb:105 nack                       | [RFC5104] - Indicates  |
   |                                          | NACK RTCP feedback     |
   |                                          | support                |
/-------End of addition for real-time text---------------------/
   +------------------------------------------+------------------------+

                          Table 1: 4.1 SDP Offer


And similarly for the SDP answer and the other examples.

If that is the accepted principle, we can go ahead and propose the complete changes.

/Gunnar
-----------------------------------------

On 2012-11-13 10:55, Harald Alvestrand wrote:
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:

12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alvestrand.no>:

I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a codec in the  RTP flow and is implemented in Asterisk and a couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit interoperability.

Much easier - and faster - to implement in the RTP subsystem as it is already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services?

I don't understand T.140 - so I can't do the work. Someone who wants it should.



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

--------------040703060806030000080009-- From gunnar.hellstrom@omnitor.se Sun Nov 18 03:34:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E166421F84C8 for ; Sun, 18 Nov 2012 03:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wubHG8C82TQj for ; Sun, 18 Nov 2012 03:34:34 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id F12D221F84C4 for ; Sun, 18 Nov 2012 03:34:33 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 18 Nov 2012 12:34:26 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 00D4D3A160; Sun, 18 Nov 2012 12:34:25 +0100 (CET) Message-ID: <50A8C7C3.3020201@omnitor.se> Date: Sun, 18 Nov 2012 12:34:27 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=F6ran_Eriksson_AP?= References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> <50A81ED2.9010604@omnitor.se> , <50A890D4.800@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 11:34:35 -0000 On 2012-11-18 10:00, Göran Eriksson AP wrote: > One note though- You have added the real time text into the basic > video chat example. The way this was structured was to move from > basic-atomic- use cases, adding complexity such as more/other > media&data streams in separate use cases. Yes, I prepared also the "sequential" variant, just adding the real-time text in a short clause among the other atomic additions. But I realized the risk for it to be seen as an addition for special cases, rather than one of the three important natural components of human conversation. You talk, you show, you write to each other. Both face-to-face and remotely. So, I preferred the upfront integrated variant, and sent that to the group. /Gunnar From goran.ap.eriksson@ericsson.com Sun Nov 18 04:13:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773CC21F84CF for ; Sun, 18 Nov 2012 04:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_54=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 DQHDAOOaIxBK for ; Sun, 18 Nov 2012 04:13:32 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 587AD21F84CC for ; Sun, 18 Nov 2012 04:13:32 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-bf-50a8d0eab074 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BC.C8.26143.AE0D8A05; Sun, 18 Nov 2012 13:13:30 +0100 (CET) Received: from ESESSHC005.ericsson.se (153.88.183.33) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 18 Nov 2012 13:13:30 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.001; Sun, 18 Nov 2012 13:13:29 +0100 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [rtcweb] Text communication requirements for RTCWEB Thread-Index: AQHNxRwISjtXZCeXlk2VH8Yk4Wqse5fuoH+AgACEXQCAACdIOoAAGjWAgAAbrKE= Date: Sun, 18 Nov 2012 12:13:29 +0000 Message-ID: <1A04203A-8314-4D07-A710-8518B11C0776@ericsson.com> References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> <50A81ED2.9010604@omnitor.se> , <50A890D4.800@omnitor.se> , <50A8C7C3.3020201@omnitor.se> In-Reply-To: <50A8C7C3.3020201@omnitor.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6rCysCDA6cs7JY8focu8WO92dY LNb+a2d3YPZYsuQnk8fExZ+YPSY/bmMOYI7isklJzcksSy3St0vgyri3fQ1zQYtQRVN3VQPj Yr4uRk4OCQETiaPrJzNB2GISF+6tZ+ti5OIQEjjJKLFvzxYoZyejxLOm2awQzhJGicmz97GD tLAJeEtMW3GWFcQWEXCV+H/5ITOIzQxkn5s5BWyssICDxIIz81ggahwlbnTPA4pzANl+El9e ZIGEWQRUJSb/b2EDsXkF7CVO3j0OVi4kMIVZYtueQJByTgEtiTkP7EHCjAKyEve/32OB2CQu cevJfKgHBCSW7DnPDGGLSrx8/I8VokZP4sbUKWwQtrbEsoWvmSFWCUqcnPkEapW2xIT+Z+wT GMVnIRk7C0n7LCTts5C0L2BkWcXInpuYmZNebrSJERhNB7f8Vt3BeOecyCFGaQ4WJXFe6617 /IUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwlj63cWZlrr05qdFjxf9WpaX3+l0mfLoc4v/k pn1T35uv71/NYHr0dpeLsP+eVW8NbkQuF2Z26XjEEsWx8qhqe2C03dH86Ak2FX1CnY6X3/T9 3XJZ4ZvbxpmczDwCcSf/LSy6+W9dVJrnk21T4twT7gQxvl3Tw3NcPELx9JaZcad2/zA51vdD XImlOCPRUIu5qDgRABTiuih0AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 12:13:33 -0000 What is "most natural" can be discussed and we could add a lot of stuff to = capture that, :-), but real time text chat for the hearing impaired is a re= levant use case in its own right as is a video and text chat case. Having audio, video and text chat is not the most basic use case- audio onl= y, video only or text chat only is. Hence, single stream cases are basic. P= erhaps not most natural, but still essential use cases to secure. Concerning what most important or natural, the use case draft is not govern= ing that. The draft was mainly intended for providing a common set of diffe= rent kinds of architecture, including supporting the spilt into API related= requirements and protocol requirements, which is useful when trying to coo= rdinate the w3c API work and that of IETF. For instance the objective of making an API that is easy to use for the ord= inary web developer who just want to enrich his web page with an 1-1 audio = or video chat component is one reason for having the "atomic" use case appr= oach. Another is when we move towards test spec time in the w3c, where many= test cases will be very basic, :-). So I would still like to keep this approach, adding the cases You describe = where appropriate, be that in the existing use case or as new ones. Would You like me to have a go at it, drafting a proposal? Regards G=F6ran Sent from my iPad On 18 nov 2012, at 12:34, "Gunnar Hellstr=F6m" wrote: > On 2012-11-18 10:00, G=F6ran Eriksson AP wrote: >> One note though- You have added the real time text into the basic video = chat example. The way this was structured was to move from basic-atomic- us= e cases, adding complexity such as more/other media&data streams in separat= e use cases. >=20 > Yes, I prepared also the "sequential" variant, just adding the real-time= text in a short clause among the other atomic additions. >=20 > But I realized the risk for it to be seen as an addition for special case= s, rather than one of the three important natural components of human conve= rsation. You talk, you show, you write to each other. Both face-to-face and= remotely. >=20 > So, I preferred the upfront integrated variant, and sent that to the grou= p. >=20 > /Gunnar From gunnar.hellstrom@omnitor.se Sun Nov 18 04:40:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626A321F84FA for ; Sun, 18 Nov 2012 04:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_40=-0.185, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I74a+HV3OUQY for ; Sun, 18 Nov 2012 04:40:29 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id F3ACA21F86BC for ; Sun, 18 Nov 2012 04:40:27 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 18 Nov 2012 13:40:15 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 22C673A13B; Sun, 18 Nov 2012 13:40:15 +0100 (CET) Message-ID: <50A8D730.4050707@omnitor.se> Date: Sun, 18 Nov 2012 13:40:16 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=F6ran_Eriksson_AP?= References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> <50A81ED2.9010604@omnitor.se> , <50A890D4.800@omnitor.se> , <50A8C7C3.3020201@omnitor.se> <1A04203A-8314-4D07-A710-8518B11C0776@ericsson.com> In-Reply-To: <1A04203A-8314-4D07-A710-8518B11C0776@ericsson.com> Content-Type: multipart/mixed; boundary="------------010709050506070106080306" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 12:40:34 -0000 This is a multi-part message in MIME format. --------------010709050506070106080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Yes, please have a go on it. You can use my initial effort on the atomic variant as a base. Attached. Gunnar On 2012-11-18 13:13, Göran Eriksson AP wrote: > What is "most natural" can be discussed and we could add a lot of stuff to capture that, :-), but real time text chat for the hearing impaired is a relevant use case in its own right as is a video and text chat case. > > Having audio, video and text chat is not the most basic use case- audio only, video only or text chat only is. Hence, single stream cases are basic. Perhaps not most natural, but still essential use cases to secure. > > Concerning what most important or natural, the use case draft is not governing that. The draft was mainly intended for providing a common set of different kinds of architecture, including supporting the spilt into API related requirements and protocol requirements, which is useful when trying to coordinate the w3c API work and that of IETF. > > For instance the objective of making an API that is easy to use for the ordinary web developer who just want to enrich his web page with an 1-1 audio or video chat component is one reason for having the "atomic" use case approach. Another is when we move towards test spec time in the w3c, where many test cases will be very basic, :-). > > So I would still like to keep this approach, adding the cases You describe where appropriate, be that in the existing use case or as new ones. > > Would You like me to have a go at it, drafting a proposal? > > Regards > Göran > > > > > Sent from my iPad > > On 18 nov 2012, at 12:34, "Gunnar Hellström" wrote: > >> On 2012-11-18 10:00, Göran Eriksson AP wrote: >>> One note though- You have added the real time text into the basic video chat example. The way this was structured was to move from basic-atomic- use cases, adding complexity such as more/other media&data streams in separate use cases. >> Yes, I prepared also the "sequential" variant, just adding the real-time text in a short clause among the other atomic additions. >> >> But I realized the risk for it to be seen as an addition for special cases, rather than one of the three important natural components of human conversation. You talk, you show, you write to each other. Both face-to-face and remotely. >> >> So, I preferred the upfront integrated variant, and sent that to the group. >> >> /Gunnar --------------010709050506070106080306 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-rtcweb-use-cases-and-requirements-09 plus rtt sequentially.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="draft-ietf-rtcweb-use-cases-and-requirements-09 plus rtt seq"; filename*1="uentially.txt" RTCWEB Working Group C. Holmberg Internet-Draft S. Hakansson Intended status: Informational G. Eriksson Expires: December 29, 2012 Ericsson June 27, 2012 Web Real-Time Communication Use-cases and Requirements draft-ietf-rtcweb-use-cases-and-requirements-09.txt Abstract This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream and data exchange services provided by the browser. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 29, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Holmberg, et al. Expires December 29, 2012 [Page 1] Internet-Draft RTC-Web June 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Browser-to-browser use-cases . . . . . . . . . . . . . . . 5 4.2.1. Simple Video Communication Service . . . . . . . . . . 5 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP . . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Simple Video Communication Service, FW that only allows http . . . . . . . . . . . . . . . . . . . . . 6 4.2.4. Simple Video Communication Service, global service provider . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.5. Simple Video Communication Service, enterprise aspects . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.6. Simple Video Communication Service, access change . . 8 4.2.7. Simple Video Communication Service, QoS . . . . . . . 8 4.2.8. Simple Video Communication Service with sharing . . . 9 4.2.9. Simple Video Communication Service with file exchange . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.10. Simple video communication service with inter-operator calling . . . . . . . . . . . . . . . . 9 4.2.11. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 10 4.2.12. Multiparty video communication . . . . . . . . . . . . 11 4.2.13. Multiparty on-line game with voice communication . . . 12 4.2.14. Distributed Music Band . . . . . . . . . . . . . . . . 12 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 13 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 13 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Video conferencing system with central server . . . . 14 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 15 5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 22 7.3. Web Application Considerations . . . . . . . . . . . . . . 22 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Holmberg, et al. Expires December 29, 2012 [Page 2] Internet-Draft RTC-Web June 2012 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Holmberg, et al. Expires December 29, 2012 [Page 3] Internet-Draft RTC-Web June 2012 1. Introduction This document presents a few use-cases of web applications that are executed in a browser and use real-time communication capabilities. Based on the use-cases, the document derives requirements related to the browser and the API used by web applications in the browser. The requirements related to the browser are named "Fn" and are described in Section 5.2 The requirements related to the API are named "An" and are described in Section 5.3 The document focuses on requirements related to real-time media streams and data exchange. Requirements related to privacy, signalling between the browser and web server etc. are currently not considered. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Definitions TBD 4. Use-cases 4.1. Introduction This section describes web based real-time communication use-cases, from which requirements are derived. The following considerations are applicable to all use cases: o Clients can be on IPv4-only o Clients can be on IPv6-only o Clients can be on dual-stack o Clients can be on wideband (10s of Mbits/sec) o Clients can be on narrowband (10s to 100s of Kbits/sec) o Clients can be on variable-media-quality networks (wireless) Holmberg, et al. Expires December 29, 2012 [Page 4] Internet-Draft RTC-Web June 2012 o Clients can be on congested networks o Clients can be on firewalled networks with no UDP allowed o Clients can be on networks with any type (as described in RFC4787) of NAT. 4.2. Browser-to-browser use-cases 4.2.1. Simple Video Communication Service 4.2.1.1. Description Two or more users have loaded a video communication web application into their browsers, provided by the same service provider, and logged into the service it provides. The web service publishes information about user login status by pushing updates to the web application in the browsers. When one online user selects a peer online user, a 1-1 video communication session between the browsers of the two peers is initiated. The invited user might accept or reject the session. During session establishment a self-view is displayed, and once the session has been established the video sent from the remote peer is displayed in addition to the self-view. During the session, each user can select to remove and re-insert the self-view as often as desired. Each user can also change the sizes of his/her two video displays during the session. Each user can also pause sending of media (audio, video, or both) and mute incoming media It is essential that the communication cannot be wiretapped [RFC2804]. The users are provided wiht means that allow them to (through a separate, trusted communication channel) verify that the media origins from the other user and has not been manipulated. The user's browsers will reject all incoming media that has been created, injected or in any way modified by any entity not trusted by the service provider. The application gives the users the opportunity to stop it from exposing the IP address to the application of the other user. Any session participant can end the session at any time. The two users may be using communication devices of different makes, with different operating systems and browsers from different vendors. One user has an unreliable Internet connection. It sometimes loses Holmberg, et al. Expires December 29, 2012 [Page 5] Internet-Draft RTC-Web June 2012 packets, and sometimes goes down completely. One user is located behind a Network Address Translator (NAT). The web service monitors the quality of the service (focus on quality of audio and video) the end-users experience. 4.2.1.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F35, F36, F38 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 4.2.2.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1). The difference is that one of the users is behind a NAT that blocks UDP traffic. 4.2.2.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F29 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 4.2.3. Simple Video Communication Service, FW that only allows http 4.2.3.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1). The difference is that one of the users is behind a FW that only allows http traffic. Note: What about WS? Could it be a viable back-off mechanism? 4.2.3.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F37 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 4.2.4. Simple Video Communication Service, global service provider Holmberg, et al. Expires December 29, 2012 [Page 6] Internet-Draft RTC-Web June 2012 4.2.4.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1). What is added is that the service provider is operating over large geographical areas (or even globally). Assuming that ICE will be used, this means that the service provider would like to be able to provide several STUN and TURN servers (via the app) to the browser; selection of which one(s) to use is part of the ICE processing. Other reasons for wanting to provide several STUN and TURN servers include support for IPv4 and IPv6, load balancing and redundancy. 4.2.4.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F31 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A22 4.2.5. Simple Video Communication Service, enterprise aspects 4.2.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 4.2.1). What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application session used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddle the boundary between the internal network and the external. The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want to have the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possibele to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to Holmberg, et al. Expires December 29, 2012 [Page 7] Internet-Draft RTC-Web June 2012 achieve by autoconfiguration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. 4.2.5.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F32 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 4.2.6. Simple Video Communication Service, access change 4.2.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1).The difference is that the user changes network access during the session: The communication device used by one of the users have several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. 4.2.6.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F26, F28 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 4.2.7. Simple Video Communication Service, QoS 4.2.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 4.2.6). The use of Quality of Service (QoS) capabilities is added: The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. Holmberg, et al. Expires December 29, 2012 [Page 8] Internet-Draft RTC-Web June 2012 4.2.7.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F24, F25, F26, F28 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 4.2.8. Simple Video Communication Service with sharing 4.2.8.1. Description This use-case has the audio and video communication of the Simple Video Communication Service use-case (Section 4.2.1). But in addition to this, one of the users can share what is being displayed on her/his screen with a peer. The user can choose to share the entire screen, part of the screen (part selected by the user) or what a selected applicaton displays with the peer. 4.2.8.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F30 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21 4.2.9. Simple Video Communication Service with file exchange 4.2.9.1. Description This use-case has the audio and video communication of the Simple Video Communication Service use-case (Section 4.2.1). But in addition to this, the users can send and receive files stored in the file system of the device used. 4.2.9.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F30, F33 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21, A24 4.2.10. Simple video communication service with inter-operator calling 4.2.10.1. Description Two users have logged into two different web applications, provided by different service providers. The service providers are interconnected by some means, but exchange Holmberg, et al. Expires December 29, 2012 [Page 9] Internet-Draft RTC-Web June 2012 no more information about the users than what can be carried using SIP. NOTE: More profiling of what this means may be needed. For each user Alice who has authorized another user Bob to receive login status information, Alice's service publishes Alice's login status information to Bob. How this authorization is defined and established is out of scope. The same functionality as in the the Simple Video Communication Service use-case (Section 4.2.1) is available. The same issues with connectivity apply. 4.2.10.2. Derived requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F27, F28 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A20 4.2.11. Hockey Game Viewer 4.2.11.1. Description An ice-hockey club uses an application that enables talent scouts to, in real-time, show and discuss games and players with the club manager. The talent scouts use a mobile phone with two cameras, one front facing and one rear facing. The club manager uses a desktop, equipped with one camera, for viewing the game and discussing with the talent scout. Before the game starts, and during game breaks, the talent scout and the manager have a 1-1 video communication. Only the rear facing camera of the mobile phone is used. On the display of the mobile phone, the video of the club manager is shown with a picture-in- picture thumbnail of the rear facing camera (self-view). On the display of the desktop, the video of the talent scout is shown with a picture-in-picture thumbnail of the desktop camera (self-view). When the game is on-going, the talent scout activates the use of the front facing camera, and that stream is sent to the desktop (the stream from the rear facing camera continues to be sent all the time). The video stream captured by the front facing camera (that is capturing the game) of the mobile phone is shown in a big window on the desktop screen, with picture-in-picture thumbnails of the rear facing camera and the desktop camera (self-view). On the display of Holmberg, et al. Expires December 29, 2012 [Page 10] Internet-Draft RTC-Web June 2012 the mobile phone the game is shown (front facing camera) with picture-in-picture thumbnails of the rear facing camera (self-view) and the desktop camera. As the most important stream in this phase is the video showing the game, the application used in the talent scout's mobile sets higher priority for that stream. It is essential that the communication cannot be wiretapped [RFC2804]. 4.2.11.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F20, F34 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17, A23 4.2.12. Multiparty video communication 4.2.12.1. Description In this use-case is the Simple Video Communication Service use-case (Section 4.2.1) is extended by allowing multiparty sessions. No central server is involved - the browser of each participant sends and receives streams to and from all other session participants. The web application in the browser of each user is responsible for setting up streams to all receivers. In order to enhance intelligibility, the web application pans the audio from different participants differently when rendering the audio. This is done automatically, but users can change how the different participants are placed in the (virtual) room. In addition the levels in the audio signals are adjusted before mixing. Another feature intended to enhance the use experience is that the video window that displays the video of the currently speaking peer is highlighted. Each video stream received is by default displayed in a thumbnail frame within the browser, but users can change the display size. It is essential that the communication cannot be wiretapped [RFC2804]. Note: What this use-case adds in terms of requirements is capabilities to send streams to and receive streams from several peers concurrently, as well as the capabilities to render the video from all recevied streams and be able to spatialize, level adjust and mix the audio from all received streams locally in the browser. It also adds the capability to measure the audio level/activity. Holmberg, et al. Expires December 29, 2012 [Page 11] Internet-Draft RTC-Web June 2012 4.2.12.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F20, F25 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17 4.2.13. Multiparty on-line game with voice communication 4.2.13.1. Description This use case is based on the previous one. In this use-case, the voice part of the multiparty video communication use case is used in the context of an on-line game. The received voice audio media is rendered together with game sound objects. For example, the sound of a tank moving from left to right over the screen must be rendered and played to the user together with the voice media. Quick updates of the game state is required, and have higher priority than the voice. It is essential that the communication cannot be wiretapped [RFC2804]. Note: the difference regarding local audio processing compared to the "Multiparty video communication" use-case is that other sound objects than the streams must be possible to be included in the spatialization and mixing. "Other sound objects" could for example be a file with the sound of the tank; that file could be stored locally or remotely. 4.2.13.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16, F18, F20, F23, F34 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17, A18, A23 4.2.14. Distributed Music Band 4.2.14.1. Description In this use-case, a music band is playing music while the members are at different physical locations. No central server is used, instead all streams are set up in a mesh fashion. Holmberg, et al. Expires December 29, 2012 [Page 12] Internet-Draft RTC-Web June 2012 Discussion: This use-case was briefly discussed at the Quebec webrtc meeting and it got support. So far the only concrete requirement (A17) derived is that the application must be able to ask the browser to treat the audio signal as audio (in contrast to speech). However, the use case should be further analysed to determine other requirements (could be e.g. on delay mic->speaker, level control of audio signals, etc.). 4.2.14.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A19 4.2.15. Simple Video Communication Service with real-time text 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). But in addition to this, the users can send and receive real-time text. While one user types in the real-time text area, it  is nearly immediately presented to the other user. 4.2.15.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21, F39,F40, F41, F42 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27 4.2.16. Multiparty video communication with real-time text 4.2.16.1. Description In this use-case is the Multiparty Video Communication Service use-case (Section 4.2.12) extended by including real-time text among the media. Each real-time text stream is identified in the API, so that the application can handle presentation of the real-time text in a suitable way. It is essential that the communication cannot be wiretapped [RFC2804]. 4.2.16.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F20, F25, F39, F40, F41, F42 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17, A 27 4.3. Browser - GW/Server use cases 4.3.1. Telephony terminal 4.3.1.1. Description A mobile telephony operator allows its customers to use a web browser to access their services. After a simple log in the user can place and receive calls in the same way as when using a normal mobile phone. When a call is received or placed, the identity is shown in the same manner as when a mobile phone is used. It is essential that the communication cannot be wiretapped [RFC2804]. Note: With "place and receive calls in the same way as when using a normal mobile phone" it is meant that you can dial a number, and that your mobile telephony operator has made available your phone contacts on line, so they are available and can be clicked to call, and be used to present the identity of an incoming call. If the callee is not in your phone contacts the number is displayed. Furthermore, your call logs are available, and updated with the calls made/ received from the browser. And for people receiving calls made from the web browser the usual identity (i.e. the phone number of the mobile phone) will be presented. 4.3.1.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 Holmberg, et al. Expires December 29, 2012 [Page 13] Internet-Draft RTC-Web June 2012 4.3.2. Fedex Call 4.3.2.1. Description Alice uses her web browser with a service something like Skype to be able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to hear the initial prompts from the fedex IVR and when the IVR says press 1, there should be a way for Alice to navigate the IVR. 4.3.2.2. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 4.3.3. Video conferencing system with central server 4.3.3.1. Description An organization uses a video communication system that supports the establishment of multiparty video sessions using a central conference server. The browser of each participant send an audio stream (type in terms of mono, stereo, 5.1, ... depending on the equipment of the participant) to the central server. The central server mixes the audio streams (and can in the mixing process naturally add effects such as spatialization) and sends towards each participant a mixed audio stream which is played to the user. The browser of each participant sends video towards the server. For each participant one high resolution video is displayed in a large window, while a number of low resolution videos are displayed in smaller windows. The server selects what video streams to be forwarded as main- and thumbnail videos respectively, based on speech activity. As the video streams to display can change quite frequently (as the conversation flows) it is important that the delay from when a video stream is selected for display until the video can be displayed is short. The organization has an internal network set up with an aggressive firewall handling access to the Internet. If users cannot physically access the internal network, they can establish a Virtual Private Network (VPN). It is essential that the communication cannot be wiretapped [RFC2804]. Holmberg, et al. Expires December 29, 2012 [Page 14] Internet-Draft RTC-Web June 2012 All participants are authenticated by the central server, and authorized to connect to the central server. The participants are identified to each other by the central server, and the participants do not have access to each others' credentials such as e-mail addresses or login IDs. Note: This use-case adds requirements on support for fast stream switches F7, on encryption of media and on ability to traverse very restrictive FWs. There exist several solutions that enable the server to forward one high resolution and several low resolution video streams: a) each browser could send a high resolution, but scalable stream, and the server could send just the base layer for the low resolution streams, b) each browser could in a simulcast fashion send one high resolution and one low resolution stream, and the server just selects or c) each browser sends just a high resolution stream, the server transcodes into low resolution streams as required. 4.3.3.2. Derived Requirements F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F17, F19, F20 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17 5. Requirements 5.1. General This section contains the requirements derived from the use-cases in section 4. NOTE: It is assumed that the user applications are executed on a browser. Whether the capabilities to implement specific browser requirements are implemented by the browser application, or are provided to the browser application by the underlying operating system, is outside the scope of this document. 5.2. Browser requirements REQ-ID DESCRIPTION --------------------------------------------------------------- F1 The browser MUST be able to use microphones and cameras as input devices to generate streams. ---------------------------------------------------------------- F2 The browser MUST be able to send streams and data to a peer in the presence of NATs. Holmberg, et al. Expires December 29, 2012 [Page 15] Internet-Draft RTC-Web June 2012 ---------------------------------------------------------------- F3 Transmitted streams and data MUST be rate controlled. ---------------------------------------------------------------- F4 The browser MUST be able to receive, process and render streams and data ("render" does not apply for data) from peers. ---------------------------------------------------------------- F5 The browser MUST be able to render good quality audio and video even in the presence of reasonable levels of jitter and packet losses. TBD: What is a reasonable level? ---------------------------------------------------------------- F6 The browser MUST be able to handle high loss and jitter levels in a graceful way. ---------------------------------------------------------------- F7 The browser MUST support fast stream switches. ---------------------------------------------------------------- F8 The browser MUST detect when a stream from a peer is not received anymore ---------------------------------------------------------------- F9 When there are both incoming and outgoing audio streams, echo cancellation MUST be made available to avoid disturbing echo during conversation. QUESTION: How much control should be left to the web application? ---------------------------------------------------------------- F10 The browser MUST support synchronization of audio and video. QUESTION: How much control should be left to the web application? ---------------------------------------------------------------- F11 The browser MUST be able to transmit streams and data to several peers concurrently. ---------------------------------------------------------------- F12 The browser MUST be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- F13 The browser MUST be able to apply spatialization effects to audio streams. ---------------------------------------------------------------- F14 The browser MUST be able to measure the level in audio streams. Holmberg, et al. Expires December 29, 2012 [Page 16] Internet-Draft RTC-Web June 2012 ---------------------------------------------------------------- F15 The browser MUST be able to change the level in audio streams. ---------------------------------------------------------------- F16 The browser MUST be able to render several concurrent video streams ---------------------------------------------------------------- F17 The browser MUST be able to mix several audio streams. ---------------------------------------------------------------- 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. ---------------------------------------------------------------- F19 Streams and data MUST be able to pass through restrictive firewalls. ---------------------------------------------------------------- F20 It MUST be possible to protect streams and data from wiretapping. ---------------------------------------------------------------- F21 The browser MUST support an audio media format (codec) that is commonly supported by existing telephony services. QUESTION: G.711? ---------------------------------------------------------------- F22 There should be a way to navigate a DTMF based IVR ---------------------------------------------------------------- F23 The browser must be able to send short latency unreliable datagram traffic to a peer browser. ---------------------------------------------------------------- F24 The browser SHOULD be able to take advantage of available capabilities (supplied by network nodes) to prioritize voice, video and data appropriately. ---------------------------------------------------------------- F25 The browser SHOULD use encoding of streams suitable for the current rendering (e.g. video display size) and SHOULD change parameters if the rendering changes during the session ---------------------------------------------------------------- F26 It MUST be possible to move from one network interface to another one ---------------------------------------------------------------- F27 The browser MUST be able to initiate and Holmberg, et al. Expires December 29, 2012 [Page 17] Internet-Draft RTC-Web June 2012 accept a media session where the data needed for establishment can be carried in SIP. ---------------------------------------------------------------- F28 The browser MUST support a baseline audio and video codec ---------------------------------------------------------------- F29 The browser MUST be able to send streams and data to a peer in the presence of NATs that block UDP traffic. ---------------------------------------------------------------- F30 The browser MUST be able to use the screen (or a specific area of the screen) or what a certain application displays on the screen to generate streams. ---------------------------------------------------------------- F31 The browser MUST be able to use several STUN and TURN servers ---------------------------------------------------------------- F32 There browser MUST support that STUN and TURN servers to use are supplied by other entities than the service provided (i.e. the network provider). ---------------------------------------------------------------- F33 The browser must be able to send reliable data traffic to a peer browser. ---------------------------------------------------------------- F34 The browser MUST support priortization of streams and data. ---------------------------------------------------------------- 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. ---------------------------------------------------------------- F36 The browser MUST reject incoming media and data, either modified, created or injected, by any entity not trusted by the site. ---------------------------------------------------------------- F37 The browser MUST be able to send streams and data to a peer in the presence of FWs that only allows http(s) traffic. ---------------------------------------------------------------- F38 The browser MUST be able to collect statistics, related to the transport of audio and video between peers, needed to estimate quality of service. ---------------------------------------------------------------- F39 The browser MUST be able to handle text entry via applications to generate real-time text streams. ---------------------------------------------------------------- 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. ---------------------------------------------------------------- F42 The browser MUST be able to convey good quality real-time text even in the presence of reasonable levels of jitter and packet losses. Note: Good quality real-time text is defined in ITU-T Recommendation F.700. Reasonable level jitter is max 200 ms for 99% packets. Reasonable level packet loss is 1% measured over more than 1 minute. ---------------------------------------------------------------- Holmberg, et al. Expires December 29, 2012 [Page 18] Internet-Draft RTC-Web June 2012 5.3. API requirements REQ-ID DESCRIPTION ---------------------------------------------------------------- A1 The Web API MUST provide means for the application to ask the browser for permission to use cameras and microphones as input devices. ---------------------------------------------------------------- A2 The Web API MUST provide means for the web application to control how streams generated by input devices are used. ---------------------------------------------------------------- A3 The Web API MUST provide means for the web application to control the local rendering of streams (locally generated streams and streams received from a peer). ---------------------------------------------------------------- A4 The Web API MUST provide means for the web application to initiate sending of stream/stream components to a peer. ---------------------------------------------------------------- A5 The Web API MUST provide means for the web application to control the media format (codec) to be used for the streams sent to a peer. NOTE: The level of control depends on whether the codec negotiation is handled by the browser or the web application. ---------------------------------------------------------------- A6 The Web API MUST provide means for the web application to modify the media format for streams sent to a peer after a media stream has been established. ---------------------------------------------------------------- A7 The Web API MUST provide means for informing the web application of whether the establishment of a stream with a peer was successful or not. ---------------------------------------------------------------- A8 The Web API MUST provide means for the web application to mute/unmute a stream or stream component(s). When a stream is sent to a peer mute status must be preserved in the stream received by the peer. ---------------------------------------------------------------- A9 The Web API MUST provide means for the web application to cease the sending of a stream Holmberg, et al. Expires December 29, 2012 [Page 19] Internet-Draft RTC-Web June 2012 to a peer. ---------------------------------------------------------------- A10 The Web API MUST provide means for the web application to cease processing and rendering of a stream received from a peer. ---------------------------------------------------------------- A11 The Web API MUST provide means for informing the web application when a stream from a peer is no longer received. ---------------------------------------------------------------- A12 The Web API MUST provide means for informing the web application when high loss rates occur. ---------------------------------------------------------------- A13 The Web API MUST provide means for the web application to apply spatialization effects to audio streams. ---------------------------------------------------------------- A14 The Web API MUST provide means for the web application to detect the level in audio streams. ---------------------------------------------------------------- A15 The Web API MUST provide means for the web application to adjust the level in audio streams. ---------------------------------------------------------------- A16 The Web API MUST provide means for the web application to mix audio streams. ---------------------------------------------------------------- A17 For each stream generated, the Web API MUST provide an identifier that is accessible by the application. The identifier MUST be accessible also for a peer receiving that stream and MUST be unique relative to all other stream identifiers in use by either party. ---------------------------------------------------------------- A18 The Web API MUST provide a mechanism for sending and receiving isolated discrete chunks of data. ---------------------------------------------------------------- A19 The Web API MUST provide means for the web application indicate the type of audio signal (speech, audio)for audio stream(s)/stream component(s). ---------------------------------------------------------------- A20 It must be possible for an initiator or a responder Web application to indicate the types of media he's willing to accept incoming streams for when setting up a connection (audio, Holmberg, et al. Expires December 29, 2012 [Page 20] Internet-Draft RTC-Web June 2012 video, real-time text, other). The types of media he's willing to accept can be a subset of the types of media the browser is able to accept. ---------------------------------------------------------------- A21 The Web API MUST provide means for the application to ask the browser for permission to the screen, a certain area on the screen or what a certain application displays on the screen as input to streams. ---------------------------------------------------------------- A22 The Web API MUST provide means for the application to specify several STUN and/or TURN servers to use. ---------------------------------------------------------------- A23 The Web API MUST provide means for the application to specify the priority to apply for outgoing streams and data. ---------------------------------------------------------------- A24 The Web API MUST provide a mechanism for sending and receiving files. ---------------------------------------------------------------- A25 It must be possible for the application to refrain from exposing the IP address ---------------------------------------------------------------- A26 The Web API MUST provide means for the application to obtain the statistics (related to transport, and collected by the browser) needed to estimate quality of service. ---------------------------------------------------------------- A27 The Web API MUST provide a mechanisms for handling real-time text among the streams. ---------------------------------------------------------------- 6. IANA Considerations TBD 7. Security Considerations 7.1. Introduction A malicious web application might use the browser to perform Denial Of Service (DOS) attacks on NAT infrastructure, or on peer devices. Also, a malicious web application might silently establish outgoing, and accept incoming, streams on an already established connection. Based on the identified security risks, this section will describe security considerations for the browser and web application. Holmberg, et al. Expires December 29, 2012 [Page 21] Internet-Draft RTC-Web June 2012 7.2. Browser Considerations The browser is expected to provide mechanisms for getting user consent to use device resources such as camera and microphone. The browser is expected to provide mechanisms for informing the user that device resources such as camera and microphone are in use ("hot"). The browser is expected to provide mechanisms for users to revise and even completely revoke consent to use device resources such as camera and microphone. The browser is expected to provide mechanisms for getting user consent to use the screen (or a certain part of it) or what a certain application displays on the screen as source for streams. The browser is expected to provide mechanisms for informing the user that the screen, part thereof or an application is serving as a stream source ("hot"). The browser is expected to provide mechanisms for users to revise and even completely revoke consent to use the screen, part thereof or an application is serving as a stream source. The browser is expected to provide mechanisms in order to assure that streams are the ones the recipient intended to receive. The browser is expected to provide mechanisms that allows the users to verify that the streams received have not be manipulated (F35). The browser needs to ensure that media is not sent, and that received media is not rendered, until the associated stream establishment and handshake procedures with the remote peer have been successfully finished. The browser needs to ensure that the stream negotiation procedures are not seen as Denial Of Service (DOS) by other entities. 7.3. Web Application Considerations The web application is expected to ensure user consent in sending and receiving media streams. 8. Additional use-cases Several additional use-cases have been discussed. At this point Holmberg, et al. Expires December 29, 2012 [Page 22] Internet-Draft RTC-Web June 2012 these use-cases are not included as requirement deriving use-cases for different reasons (lack of documentation, overlap with existing use-cases, lack of consensus). For completeness these additional use-cases are listed below: 1. Use-cases regarding different situations when being invited to a "session", e.g. browser open, browser open but another tab active, browser open but active in session, browser closed, .... (Matthew Kaufman); discussed at webrtc meeting 2. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/ rtcweb/current/msg00525.html, followed up by Stephan Wenger 3. Local Recording and Remote recording (John): Discussed a _lot_ on the mail lists (rtcweb as well as public-webrtc) lAugust and September 2011. Concrete proposal: http://www.ietf.org/ mail-archive/web/rtcweb/current/msg01006.html (remote) and http: //www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html (local) 4. Emergency access for disabled (Bernard Aboba) http:// www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 5. Clue use-cases (Roni Even) http://tools.ietf.org/html/ draft-ietf-clue-telepresence-use-cases-01 6. Rohan red cross (Cullen Jennings); http://www.ietf.org/ mail-archive/web/rtcweb/current/msg00323.html 7. Security camera/baby monitor usage http://www.ietf.org/ mail-archive/web/rtcweb/current/msg00543.html 8. Large multiparty session http://www.ietf.org/mail-archive/web/ rtcweb/current/msg00530.html 9. Call center http://www.ietf.org/mail-archive/web/rtcweb/current/ msg04203.html 10. Enterprise policies http://www.ietf.org/mail-archive/web/rtcweb/ current/msg04271.html 11. Low-complex multiparty central node http://www.ietf.org/ mail-archive/web/rtcweb/current/msg04430.html 12. Multiparty central node that is not allowed to decipher http:// www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html 13. Enable company coop without being able to decipher http:// www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html 9. Acknowledgements Dan Burnett has reviewed and proposed a lot of things that enhances the document. Most of this has been incorporated in rev -05. Stephan Wenger has provided a lot of useful input and feedback, as well as editorial comments. Harald Alvestrand and Ted Hardie have provided comments and feedback on the draft. Holmberg, et al. Expires December 29, 2012 [Page 23] Internet-Draft RTC-Web June 2012 Harald Alvestrand and Cullen Jennings have provided additional use- cases. Thank You to everyone in the RTCWEB community that have provided comments, feedback and improvement proposals on the draft content. 10. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. o Removed informal ref webrtc_req; that document has been abandoned by the W3C webrtc WG. o Added use-case where one user is behind a FW that only allows http; derived req. F37. o Changed F24 slightly; MUST-> SHOULD, inserted "available". o Added a clause to "Simple video communication service" saying that the service provider monitors the quality of service, and derived reqs F38 and A26. Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 o Added "and data exchange" to 1. Introduction. o Removed cone and symmetric NAT from 4.1 Introduction, refers to RFC4787 instead. o Added text on enabling verifyication of that the media has not been manipulated by anyone to use-case "Simple Video Communication Service", derived req. F35 o Added text on that the browser should reject media (data) that has been created/injected/modified by non-trusted party, derived req. F36 o Added text on enabling the app to refrain from revealing IP address to use-case "Simple Video Communication Service", derived req. A25 o Added use-case "Simple Video Communication Service with file exchange", derived reqs F33 and A24 o Added priority of video streams to "Hockey game viewer" use case, added priority of data to "on-line game use-case", derived reqs F34 and A23 o In F22, "the IVR" -> "a DTMF based IVR". o Updated req F23 to clarify that requirements such as NAT traversal, prtoection from eavesdropping, rate control applies also to datagram. Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 Holmberg, et al. Expires December 29, 2012 [Page 24] Internet-Draft RTC-Web June 2012 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> A22) Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 o Added use-case "global service provider", derived reqs associated with several STUN/TURN servers o Added use-case "enterprise aspects", derived req associated with enabling the network provider to supply STUN and TURN servers o The requirements from the above are ICE specific and labeled accordingly o Separated the requirements phrased like "processing such as pan, mix and render" for audio to be specific reqs on spatialization, level measurement, level adjustment and mixing (discussed on the lists in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01648.html and http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/ 0102.html) o Added use-case on sharing as decided in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 o Added the list of common considerations proposed in mail http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html to the Introduction of the use-case section Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 o Most changes based on the input from Dan Burnett http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html o Many editorial changes o 4.2.1.1 Clarified o Some clarification added to 4.3.1.1 as a note o F-requirements updated (see reply to Dan's mail). o Almost all A-requirements updated to start "The Web API MUST provide ..." o A8 removed, A9 rephrased to cover A8 and old A9 o A15 rephrased o For more details, and discussion, look att the response to Dan's mail http://www.ietf.org/mail-archive/web/rtcweb/current/msg01177.html Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 o Editorials o Changed when the self-view is displayed in 4.2.1.1, and added words about allowing users to remove and re-insert it. Holmberg, et al. Expires December 29, 2012 [Page 25] Internet-Draft RTC-Web June 2012 o Clarified 4.2.6.1 o Removed the "mono" stuff from 4.2.7.1 o Added that communication should not be possible to eavesdrop to most use cases - and req. F17 o Re-phrased 4.3.3.1 to not describe the technical solution so much, and removed "stereo" stuff. Solution possibilities are now in a note. o Re-inserted API requirements after discussion in the W3C webrtc WG. (Re-phrased A15 and added A18 compared to version -02). Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 o Removed desrciption/list of API requirements, instead o Reference to W3C webrtc_reqs document for API requirements Changes from draft-ietf-rtcweb-ucreqs-01 o Changed Intended status to Information o Changed "Ipr" to "trust200902" o Added use case "Simple video communication service, NAT/FW that blocks UDP", and derived new req F26 o Added use case "Distributed Music Band" and derived new req A17 o Added F24 as requirement derived from use case "Simple video communication service with inter-operator calling" o Added section "Additional use cases" o Added text about ID handling to multiparty with central server use case o Re-phrased A1 slightly Changes from draft-ietf-rtcweb-ucreqs-00 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ Server); removed some specific use cases and added them instead as flavors to the base use case (Simple video communciation) o - Changed the fromulation of F19 o - Removed the requirement on an API for DTMF o - Removed "FX3: There SHOULD be a mapping of the minimum needed data for setting up connections into SIP, so that the restriction to SIP-carriable data can be verified. Not a rew on the browser but rather on a document" o - (see http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html for more details) o -Added text on informing user of that mic/cam is being used and that it must be possible to revoce permission to use them in section 7. Changes from draft-holmberg-rtcweb-ucreqs-01 Holmberg, et al. Expires December 29, 2012 [Page 26] Internet-Draft RTC-Web June 2012 o - Draft name changed to draft-ietf-rtcweb-ucreqs o - Use-case grouping introduced o - Additional use-cases added o - Additional reqs added (derived from use cases): F19-F25, A16-A17 Changes from draft-holmberg-rtcweb-ucreqs-00 o - Mapping between use-cases and requirements added (Harald Alvestrand, 090311) o - Additional security considerations text (Harald Alvestrand, 090311) o - Clarification that user applications are assumed to be executed by a browser (Ted Hardie, 080311) o - Editorial corrections and clarifications 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 11.2. Informative References Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Stefan Hakansson Ericsson Laboratoriegrand 11 Lulea 97128 Sweden Email: stefan.lk.hakansson@ericsson.com Holmberg, et al. Expires December 29, 2012 [Page 27] Internet-Draft RTC-Web June 2012 Goran AP Eriksson Ericsson Farogatan 6 Stockholm 16480 Sweden Email: goran.ap.eriksson@ericsson.com Holmberg, et al. Expires December 29, 2012 [Page 28] Html markup produced by rfcmarkup 1.101, available from http://tools.ietf.org/tools/rfcmarkup/ --------------010709050506070106080306-- From goran.ap.eriksson@ericsson.com Sun Nov 18 04:43:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EE021F8432 for ; Sun, 18 Nov 2012 04:43:47 -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.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_54=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 hs7uectdiMs9 for ; Sun, 18 Nov 2012 04:43:47 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 872CC21F841C for ; Sun, 18 Nov 2012 04:43:46 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-37-50a8d80114b5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AA.6A.26143.108D8A05; Sun, 18 Nov 2012 13:43:45 +0100 (CET) Received: from ESESSHC005.ericsson.se (153.88.183.33) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 18 Nov 2012 13:43:45 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.001; Sun, 18 Nov 2012 13:43:44 +0100 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [rtcweb] Text communication requirements for RTCWEB Thread-Index: AQHNxRwISjtXZCeXlk2VH8Yk4Wqse5fuoH+AgACEXQCAACdIOoAAGjWAgAAbrKH///a3AIAAEbwB Date: Sun, 18 Nov 2012 12:43:43 +0000 Message-ID: <58950721-DA4B-4007-95D4-151C0C7B712A@ericsson.com> References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A21ED3.2060002@omnitor.se> <50A81ED2.9010604@omnitor.se> , <50A890D4.800@omnitor.se> , <50A8C7C3.3020201@omnitor.se> <1A04203A-8314-4D07-A710-8518B11C0776@ericsson.com>, <50A8D730.4050707@omnitor.se> In-Reply-To: <50A8D730.4050707@omnitor.se> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+JvjS7jjRUBBjv7NSxWvD7HbrHj/RkW i7X/2tkdmD2WLPnJ5DFx8Sdmj8mP25gDmKO4bFJSczLLUov07RK4Mmb8es9U8FS0YvbOKewN jBsFuxg5OSQETCT+npjGBGGLSVy4t56ti5GLQ0jgJKPE73mnoJydjBLtzZPYIZwljBINcyez gLSwCXhLTFtxlhXEFhFwlfh/+SEziM0MZJ+bOQVsrLCAg8SCM/NYIGocJW50z2OCsKMkdrRO AouzCKhKXPr7ECzOK2Av0fXuJ9SyF8wSS6fuBUtwCmhJXLt3hh3EZhSQlbj//R4LxDJxic9z H0D9ICCxZM95ZghbVOLl43+sEDV6EjemTmGDsLUlli18zQyxTFDi5MwnYHOEgOIT+p+xT2AU n4Vk7Cwk7bOQtM9C0r6AkWUVI3tuYmZOernRJkZgVB3c8lt1B+OdcyKHGKU5WJTEea237vEX EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKi78OX5v0pr7krlsN9utGfad1jd6JX377sNxyTW JbLVqIgW32Gwj8+YJmhYKP56k8faSO058lPWN76ffK34K6OpAf8hww3H5Wr9BGKYdRJPxLnN 2HzpeZWwsQh/uez/7pXH9QvcOmw37j7ksSf7+4IS5dD7Qm5yb9eYvJN3uGRZUVybyqhersRS nJFoqMVcVJwIADOCdzd4AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication requirements for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 12:43:47 -0000 Ok. G=F6ran 18 nov 2012 kl. 13:40 skrev "Gunnar Hellstr=F6m" : > Yes, please have a go on it. > You can use my initial effort on the atomic variant as a base. Attached. >=20 >=20 > Gunnar >=20 > On 2012-11-18 13:13, G=F6ran Eriksson AP wrote: >> What is "most natural" can be discussed and we could add a lot of stuff = to capture that, :-), but real time text chat for the hearing impaired is a= relevant use case in its own right as is a video and text chat case. >>=20 >> Having audio, video and text chat is not the most basic use case- audio = only, video only or text chat only is. Hence, single stream cases are basic= . Perhaps not most natural, but still essential use cases to secure. >>=20 >> Concerning what most important or natural, the use case draft is not gov= erning that. The draft was mainly intended for providing a common set of di= fferent kinds of architecture, including supporting the spilt into API rela= ted requirements and protocol requirements, which is useful when trying to = coordinate the w3c API work and that of IETF. >>=20 >> For instance the objective of making an API that is easy to use for the = ordinary web developer who just want to enrich his web page with an 1-1 aud= io or video chat component is one reason for having the "atomic" use case a= pproach. Another is when we move towards test spec time in the w3c, where m= any test cases will be very basic, :-). >>=20 >> So I would still like to keep this approach, adding the cases You descri= be where appropriate, be that in the existing use case or as new ones. >>=20 >> Would You like me to have a go at it, drafting a proposal? >>=20 >> Regards >> G=F6ran >>=20 >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On 18 nov 2012, at 12:34, "Gunnar Hellstr=F6m" wrote: >>=20 >>> On 2012-11-18 10:00, G=F6ran Eriksson AP wrote: >>>> One note though- You have added the real time text into the basic vide= o chat example. The way this was structured was to move from basic-atomic- = use cases, adding complexity such as more/other media&data streams in separ= ate use cases. >>> Yes, I prepared also the "sequential" variant, just adding the real-ti= me text in a short clause among the other atomic additions. >>>=20 >>> But I realized the risk for it to be seen as an addition for special ca= ses, rather than one of the three important natural components of human con= versation. You talk, you show, you write to each other. Both face-to-face a= nd remotely. >>>=20 >>> So, I preferred the upfront integrated variant, and sent that to the gr= oup. >>>=20 >>> /Gunnar >=20 > From gunnar.hellstrom@omnitor.se Sun Nov 18 11:55:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C121F8451 for ; Sun, 18 Nov 2012 11:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stAG8Echqg+k for ; Sun, 18 Nov 2012 11:55:12 -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 0095E21F842B for ; Sun, 18 Nov 2012 11:55:10 -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 ; Sun, 18 Nov 2012 20:55:01 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id C4BBF3A189 for ; Sun, 18 Nov 2012 20:55:01 +0100 (CET) Message-ID: <50A93D16.6010503@omnitor.se> Date: Sun, 18 Nov 2012 20:55:02 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> In-Reply-To: <50A218FF.9050104@alvestrand.no> Content-Type: multipart/alternative; boundary="------------090809020202050503010604" Subject: Re: [rtcweb] Text communication in RTCWEB sessions -job overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Nov 2012 19:55:13 -0000 This is a multi-part message in MIME format. --------------090809020202050503010604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit After a rapid browse, this is my view of what needs to be done to specify real-time text in RTCWEB and WebRTC. 1. draft-ietf-rtcweb-overview Make definition of Media to include real-time text Define the short form rtt Add rtt to descriptions in e.g. sections 2.1 and 2.2 non-critical 2. draft-ietf-rtcweb-use-cases-and-requirements add a couple of rtt use cases add requirements for rtt add api requirements for rtt important, initiated 3. draft-nandakumar-rtcweb-sdp add codec description for rtt add sdp for rtt for the use cases important, initiated 4. draft-x-rtcweb-rtt rtt specifics for rtt codec and rtp usage ( take inspiration from draft-ietf-rtcweb-audio ) new needed draft - not initiated 5. draft-ietf-rtcweb-jsep add rtt to API MediaHints clause 6.1.1 add rtt to examples in chapter 7. important 6. draft-ietf-rtcweb-rtpusage mention rtt add rtt to mixer discussion non-critical 7. draft-thomson-rtcweb-api-req mention rtt non-critical 8. draft-aboba-rtcweb-ecrit adjust rtt discussion for emergency calls to current status non critical 9. w3c.webrtc add rtt API, e.g. to Network Stream API important, urgent 10. w3c getusermedia add rtt to GetUserMedia API important, urgent Any more? Any less? /Gunnar On 2012-11-13 10:55, Harald Alvestrand wrote: > On 11/13/2012 09:55 AM, Olle E. Johansson wrote: >> >> 12 nov 2012 kl. 13:15 skrev Harald Alvestrand > >: >> >>> I would prefer this to be added as a separate specification, rather >>> than done at this time. >>> The reason being that this should be relatively easy to add on top >>> of the data channel functionality, but will definitely take some >>> time to specify, so should not be on the critical path for this >>> round of specifications. >> T.140 is a codec in the RTP flow and is implemented in Asterisk and >> a couple of Video SIP phones. >> I see no reason to move it to the data channel, that would limit >> interoperability. >> >> Much easier - and faster - to implement in the RTP subsystem as it is >> already covered by SDP offer/answer. >> > Anything is possible, if someone is willing to do it. > > Olle and Gunnar, can you undertake to write a complete specification > for how to use T.140 with RTCWEB, including how it should fit in with > the API specification, and whether or not it supports the needs that > Gunnar has claimed for text services? > > I don't understand T.140 - so I can't do the work. Someone who wants > it should. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090809020202050503010604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
After a rapid browse, this is my view of what needs to be done to specify real-time text in RTCWEB and WebRTC.

1. draft-ietf-rtcweb-overview   
     Make definition of Media to include real-time text
    Define the short form rtt
    Add rtt to descriptions in e.g. sections 2.1 and 2.2
    non-critical

2. draft-ietf-rtcweb-use-cases-and-requirements
    add a couple of rtt use cases
    add requirements for rtt
    add api requirements for rtt
    important, initiated

3. draft-nandakumar-rtcweb-sdp
    add codec description for rtt
    add sdp for rtt for the use cases
    important, initiated

4. draft-x-rtcweb-rtt
    rtt specifics for rtt codec and rtp usage
    ( take inspiration from draft-ietf-rtcweb-audio )
    new needed draft - not initiated

5. draft-ietf-rtcweb-jsep
    add rtt to API MediaHints  clause 6.1.1
    add rtt to examples in chapter 7.
   important

6. draft-ietf-rtcweb-rtpusage
    mention rtt
    add rtt to mixer discussion
    non-critical

7. draft-thomson-rtcweb-api-req
    mention rtt
    non-critical

8. draft-aboba-rtcweb-ecrit
    adjust rtt discussion for emergency calls to current status
    non critical

9. w3c.webrtc
    add rtt API, e.g. to Network Stream API
    important, urgent

10. w3c getusermedia
    add rtt to GetUserMedia API
    important, urgent


Any more?
Any less?


/Gunnar


On 2012-11-13 10:55, Harald Alvestrand wrote:
On 11/13/2012 09:55 AM, Olle E. Johansson wrote:

12 nov 2012 kl. 13:15 skrev Harald Alvestrand <harald@alvestrand.no>:

I would prefer this to be added as a separate specification, rather than done at this time.
The reason being that this should be relatively easy to add on top of the data channel functionality, but will definitely take some time to specify, so should not be on the critical path for this round of specifications.
T.140 is a codec in the  RTP flow and is implemented in Asterisk and a couple of Video SIP phones.
I see no reason to move it to the data channel, that would limit interoperability.

Much easier - and faster - to implement in the RTP subsystem as it is already covered by SDP offer/answer.

Anything is possible, if someone is willing to do it.

Olle and Gunnar, can you undertake to write a complete specification for how to use T.140 with RTCWEB, including how it should fit in with the API specification, and whether or not it supports the needs that Gunnar has claimed for text services?

I don't understand T.140 - so I can't do the work. Someone who wants it should.



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

--------------090809020202050503010604-- From harald@alvestrand.no Sun Nov 18 17:09:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E7E21F85C9 for ; Sun, 18 Nov 2012 17:09:54 -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=[AWL=-0.271, BAYES_05=-1.11, 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 NM5FEuX-Ku4z for ; Sun, 18 Nov 2012 17:09:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B43B021F847C for ; Sun, 18 Nov 2012 17:09:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6C0E39E179 for ; Mon, 19 Nov 2012 02:09:49 +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 83S42ieTS8d9 for ; Mon, 19 Nov 2012 02:09:49 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:6dda:6b4a:f4cd:3387] (unknown [IPv6:2001:470:de0a:27:6dda:6b4a:f4cd:3387]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8B14F39E15B for ; Mon, 19 Nov 2012 02:09:46 +0100 (CET) Message-ID: <50A986D9.5000705@alvestrand.no> Date: Mon, 19 Nov 2012 02:09:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A93D16.6010503@omnitor.se> In-Reply-To: <50A93D16.6010503@omnitor.se> Content-Type: multipart/alternative; boundary="------------030907060106030805090006" Subject: Re: [rtcweb] Text communication in RTCWEB sessions -job overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Nov 2012 01:09:54 -0000 This is a multi-part message in MIME format. --------------030907060106030805090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 11/18/2012 08:55 PM, Gunnar Hellström wrote: > After a rapid browse, this is my view of what needs to be done to > specify real-time text in RTCWEB and WebRTC. > > > > 4. draft-x-rtcweb-rtt > rtt specifics for rtt codec and rtp usage > ( take inspiration from draft-ietf-rtcweb-audio ) > new needed draft - not initiated This is the one that will have to make the compelling case that we know what we're talking about. So far, I'm not compelled - but as I said before, I don't understand T.140 or the case for picking that particular solution over the 5-6 other solutions proposed in this discussion. (I sure hope we're not going to revisit the RFC 4103 / RFC 4351 discussion; I don't know what it was, but I recognize the tracks of battles when I see them. Gunnar is an author on both documents, so I assume he can explain if needed.) Harald --------------030907060106030805090006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/18/2012 08:55 PM, Gunnar Hellström wrote:
After a rapid browse, this is my view of what needs to be done to specify real-time text in RTCWEB and WebRTC.



4. draft-x-rtcweb-rtt
    rtt specifics for rtt codec and rtp usage
    ( take inspiration from draft-ietf-rtcweb-audio )
    new needed draft - not initiated
This is the one that will have to make the compelling case that we know what we're talking about.
So far, I'm not compelled - but as I said before, I don't understand T.140 or the case for picking that particular solution over the 5-6 other solutions proposed in this discussion.

(I sure hope we're not going to revisit the RFC 4103 / RFC 4351 discussion; I don't know what it was, but I recognize the tracks of battles when I see them. Gunnar is an author on both documents, so I assume he can explain if needed.)

            Harald

--------------030907060106030805090006-- From duerst@it.aoyama.ac.jp Sun Nov 18 17:19:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F9D21F847B for ; Sun, 18 Nov 2012 17:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.61 X-Spam-Level: X-Spam-Status: No, score=-100.61 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QYAsCJHRFSb for ; Sun, 18 Nov 2012 17:19:52 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id C318021F8467 for ; Sun, 18 Nov 2012 17:19:51 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAJ1Jfhq027332 for ; Mon, 19 Nov 2012 10:19:42 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 78a5_3811_31d63ffc_31e7_11e2_9048_001d096c566a; Mon, 19 Nov 2012 10:19:41 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40308) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Nov 2012 10:19:43 +0900 Message-ID: <50A98925.2000809@it.aoyama.ac.jp> Date: Mon, 19 Nov 2012 10:19:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Dale R. Worley" References: <201211131547.qADFl3Sc971105@shell01.TheWorld.com> In-Reply-To: <201211131547.qADFl3Sc971105@shell01.TheWorld.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Nov 2012 01:19:53 -0000 On 2012/11/14 0:47, Dale R. Worley wrote: >> From: "Martin J. DC >> >> The IETF is very strongly UTF-8. The W3C is very strongly UTF-8 on the >> wire, but of course UTF-16 in JavaScript. So these battles are over. > > RFC 4103 specifies that text/t140 is encoded in UTF-8. Great to know. > Of course, the > API can present it to the Javascript in whatever way it wants. There > are a bunch of CJK extension sets above 0x10000, though, so UTF-16 may > be problematic. Just to avoid misunderstandings: UTF-16 can represent all Unicode codepoints, even U+10000 and above. For these, it needs 2 16-bit code units, so certain string manipulations have to be done with care. Regards, Martin. From bernard_aboba@hotmail.com Sun Nov 18 23:48:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337FF21F8643 for ; Sun, 18 Nov 2012 23:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 IJhH1fjMtHh0 for ; Sun, 18 Nov 2012 23:48:32 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07E21F862B for ; Sun, 18 Nov 2012 23:48:29 -0800 (PST) Received: from BLU002-W64 ([65.55.116.7]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Nov 2012 23:48:29 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_377092c7-8256-4eb5-a1be-937126ea5e86_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Harald Alvestrand , "rtcweb@ietf.org" Date: Sun, 18 Nov 2012 23:48:29 -0800 Importance: Normal In-Reply-To: <50A986D9.5000705@alvestrand.no> References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no>, , <50A218FF.9050104@alvestrand.no> <50A93D16.6010503@omnitor.se>,<50A986D9.5000705@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2012 07:48:29.0255 (UTC) FILETIME=[43D4AD70:01CDC62A] Subject: Re: [rtcweb] Text communication in RTCWEB sessions -job overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Nov 2012 07:48:33 -0000 --_377092c7-8256-4eb5-a1be-937126ea5e86_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said: "This is the one that will have to make the compelling case that we=0A= know what we're talking about." [BA] To understand what we're talking about=2C some uses cases would be hel= pful=2C in order to understand which of the following requirements apply: 1. Need to interoperate with existing RTT implementations (e.g. XEP-0301 or= RFC 4103). =20 2. Need to support "real-time text" capabilities as defined in M376 or the = Access Board requirements 2.0 (both still in draft).=20 3. Need to support "lip sync" between audio/video/text (as opposed to simpl= y replication of inter-character spacing). Requirement #1 can be supported in a JS library with an appropriate gateway= (e.g. BOSH/Websockets for XEP-0301=2C an SCTP to RTP gateway for RFC 4103)= without any support in the browser.=20 Requirement #2 can be supported via the data channel without a standard=2C = or by extracting parts of a standard (e.g. XEP-0301 RTT support) Requirement #3 may require native support=2C but a clarification of the use= case would be helpful. For example=2C in realtime conference with caption= ing=2C there is a time lag=2C so "lip syncing" of text to the audio/video (= as is possible in RFC 4103) may not in practice perform that much better th= an replication of inter-character spacing as is supported in XEP-0301=2C th= ough it would be considerably more complex to implement. =20 = --_377092c7-8256-4eb5-a1be-937126ea5e86_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said:

"This is the= one that will have to make the compelling case that we=0A= know what we're talking about."

[BA] To understand what we're ta= lking about=2C some uses cases would be helpful=2C in order to understand w= hich of the following requirements apply:

1. Need to interoperate wi= th existing RTT implementations (e.g. XEP-0301 or RFC 4103). =3B = =3B
2. Need to support "real-time text" capabilities as defined in M376= or the Access Board requirements 2.0 (both still in draft).
3. Need to= support "lip sync" between audio/video/text (as opposed to simply replicat= ion of inter-character spacing).

Requirement #1 can be supported in = a JS library with an appropriate gateway (e.g. BOSH/Websockets for XEP-0301= =2C an SCTP to RTP gateway for RFC 4103) without any support in the browser= .

Requirement #2 can be supported via the data channel without a st= andard=2C or by extracting parts of a standard (e.g. XEP-0301 RTT support)<= br>
Requirement #3 may require native support=2C but a clarification of = the use case would be helpful. =3B For example=2C in realtime conferenc= e with captioning=2C there is a time lag=2C so "lip syncing" of text to the= audio/video (as is possible in RFC 4103) may not in practice perform that = much better than replication of inter-character spacing as is supported in = XEP-0301=2C though it would be considerably more complex to implement. = =3B
= --_377092c7-8256-4eb5-a1be-937126ea5e86_-- From magnus.westerlund@ericsson.com Mon Nov 19 00:24:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E7721F8697 for ; Mon, 19 Nov 2012 00:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.169 X-Spam-Level: X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 mQkxpVDfGRux for ; Mon, 19 Nov 2012 00:24:44 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DA0E221F8686 for ; Mon, 19 Nov 2012 00:24:43 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-a0-50a9ecc94e99 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D1.2E.26143.9CCE9A05; Mon, 19 Nov 2012 09:24:42 +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; Mon, 19 Nov 2012 09:24:41 +0100 Message-ID: <50A9ECC9.5070404@ericsson.com> Date: Mon, 19 Nov 2012 09:24:41 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eric Rescorla References: <50A6578F.3050501@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RvfUm5UBBt97uCxWvD7HbrH2Xzu7 A5PHkiU/mTwmP25jDmCK4rJJSc3JLEst0rdL4Mr4t28RS8E2mYpbTxYwNzA2inUxcnJICJhI LD05kwXCFpO4cG89WxcjF4eQwElGiWULbrFAOMsZJT5Mms/axcjBwSugLbFzUyRIA4uAqsSE X1fYQGw2AQuJmz8awWxRgWCJPcfWMoLYvAKCEidnPgFbICKgIPHrzwkwm1lAXeLO4nPsILaw gJXEzK1TweJCAgUSJ/uXMIKs4hQIlJi6ywTiNkmJt+9fMUO06klMudrCCGHLSzRvnc0M0aot 0dDUwTqBUWgWks2zkLTMQtKygJF5FSN7bmJmTnq50SZGYKAe3PJbdQfjnXMihxilOViUxHmt t+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA48U0I8/2TuYckvqy3+WLGe+Nnt3Hsmoqo LXLy/48xJygvz/Wdo+D0m/+QqorVStsFsxz40hNbnu94aCluxT5nfu/jiEWPZed6Z/cXVZk9 dA94NWOvZeYhLaG7Hoslz11rn/7bM2ligsfD6P7yMPPG/52/u+XnMJrKrZ2kYCy27vnv5Qee 5fsosRRnJBpqMRcVJwIAHErJyyICAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle poll for Face to Face Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Nov 2012 08:24:45 -0000 Hi Eric, Yes, I know we agreed to a set location. Obviously we chairs didn't plan this early enough. We are once more in a squeeze between the W3C and the IETF rules. To be able to announce a W3C meeting of the week starting Monday 22 Jan W3C chairs needs to announce it no later than the 26th of Nov. Thus we wanted to get the poll going. The two hosting offers we currently have are for Orlando and Boston area. If there are more hosting offers please come forward ASAP. We will be do our best to settle the question of location prior to closing the polls. Cheers Magnus On 2012-11-16 23:09, Eric Rescorla wrote: > Chairs, > > I thought when we planned the last interim we agreed that future > interims would happen in deterministic locations. Before we > figure out when it is, can the chairs please announce *where* > it will be. > > I just finished re-ran my venue rotation software and it spits > out "East Coast" as the next location. Given that the last > IETF was in Atlanta and the next is in Orlando, I would suggest > either NYC, Washington DC, or Boston (though NYC is probably > out due to cost.) > > In any case, can the chairs please specify *which* East Coast city > it will be in? > > -Ekr > > On Fri, Nov 16, 2012 at 7:11 AM, Magnus Westerlund > > > wrote: > > WG, > > We chairs have discussed with our W3C counter parts and are considering > a co-located 3 day long face to face interim meeting. We would share the > time approximately even and also switch back and forth between the group > to be able to deal with both sides of some issues. > > We have two hard rules that makes the time window for when the meeting > is at all possible to be only three weeks at the end of January and > beginning of February. The meeting is planned to be run Tuesday to > Thursday for three full days. > > Our main focus will be JSEP and SDP related. > > So please provide input on what dates that works for you by next Friday > (23rd of Nov) by filling in the below Doodle: > > http://www.doodle.com/wvzp6ue9awn7wpni > > Any additional comments, suggestions or volunteering for hosting are > welcome. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gunnar.hellstrom@omnitor.se Mon Nov 19 00:54:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3605F21F8524 for ; Mon, 19 Nov 2012 00:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOysc+IdOlOr for ; Mon, 19 Nov 2012 00:54:48 -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 DE95421F84FC for ; Mon, 19 Nov 2012 00:54:47 -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, 19 Nov 2012 09:54:06 +0100 (CET) Received: from [192.168.0.244] (136.240.13.217.in-addr.dgcsystems.net [217.13.240.136]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 7E0633A220 for ; Mon, 19 Nov 2012 09:54:06 +0100 (CET) Message-ID: <50A9F3B0.90604@omnitor.se> Date: Mon, 19 Nov 2012 09:54:08 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A93D16.6010503@omnitor.se> <50A986D9.5000705@alvestrand.no> In-Reply-To: <50A986D9.5000705@alvestrand.no> Content-Type: multipart/alternative; boundary="------------060008070104080107030301" Subject: Re: [rtcweb] Text communication in RTCWEB sessions -job overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Nov 2012 08:54:49 -0000 This is a multi-part message in MIME format. --------------060008070104080107030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2012-11-19 02:09, Harald Alvestrand wrote: > On 11/18/2012 08:55 PM, Gunnar Hellström wrote: >> After a rapid browse, this is my view of what needs to be done to >> specify real-time text in RTCWEB and WebRTC. >> >> 4. draft-x-rtcweb-rtt >> rtt specifics for rtt codec and rtp usage >> ( take inspiration from draft-ietf-rtcweb-audio ) >> new needed draft - not initiated > This is the one that will have to make the compelling case that we > know what we're talking about. > So far, I'm not compelled - but as I said before, I don't understand > T.140 or the case for picking that particular solution over the 5-6 > other solutions proposed in this discussion. > > (I sure hope we're not going to revisit the RFC 4103 / RFC 4351 > discussion; I don't know what it was, but I recognize the tracks of > battles when I see them. Gunnar is an author on both documents, so I > assume he can explain if needed.) > > Harald Yes, now after the overview of what would be needed in RTCWEB and WebRTC to include RTT I agree that starting with "draft-x-rtcweb-rtt" would be good for clarifying requirements and alternatives and draw conclusions. For your info, all real-time text methods in IP environments transmit time-sampled text, with sample time of 300 -700 ms. 1. RFC 4103 uses RTP, with redundancy to get reliability, and declares the stream in SDP as text medium. T.140 is the text codec, just saying that text shall be transmitted by UTF-8 and specifying some control codes. There are two payload types combined RED for simple RFC 2198 type redundancy and T140 for the text itself. The recommended sample time is 300 ms. This is in use in SIP applications and also specified in emergency service specifications. 2. RFC4351 also uses RTP in a very similar way to send RTT. But it has SDP declaration as audio and is transmitted multiplexed with audio codecs in a similar way as RFC 4733. The main use was intended to be for reliable transport of legacy real-time text through IP between VoIP gateways, where the extra ports needed for a separate text RTP stream through separate ports would possibly be expensive. RFC4351 was given Historic status already from its approval in order to discourage from any other use. Transmission is UTF-8-coded. 3. XEP-0301 is a draft XMPP extension, that transmits time sampled text in XMPP Messages, but not as Body, but as RTT XML elements, so it can be sent and presented as a gradually built up message, and then replaced by the message when completed. The recommended sample time is 700 ms, and in order to avoid jerky impression, the presentation of keystrokes are timed within these transmission intervals. Transmission is UTF-8. Gunnar --------------060008070104080107030301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-11-19 02:09, Harald Alvestrand wrote:
On 11/18/2012 08:55 PM, Gunnar Hellström wrote:
After a rapid browse, this is my view of what needs to be done to specify real-time text in RTCWEB and WebRTC.

4. draft-x-rtcweb-rtt
    rtt specifics for rtt codec and rtp usage
    ( take inspiration from draft-ietf-rtcweb-audio )
    new needed draft - not initiated
This is the one that will have to make the compelling case that we know what we're talking about.
So far, I'm not compelled - but as I said before, I don't understand T.140 or the case for picking that particular solution over the 5-6 other solutions proposed in this discussion.

(I sure hope we're not going to revisit the RFC 4103 / RFC 4351 discussion; I don't know what it was, but I recognize the tracks of battles when I see them. Gunnar is an author on both documents, so I assume he can explain if needed.)

            Harald

Yes, now after the overview of what would be needed in RTCWEB and WebRTC to include RTT I agree that starting with "draft-x-rtcweb-rtt" would be good for clarifying requirements and alternatives and draw conclusions.

For your info, all real-time text methods in IP environments transmit time-sampled text, with sample time of 300 -700 ms.

1. RFC 4103 uses RTP, with redundancy to get reliability, and declares the stream in SDP as text medium. T.140 is the text codec, just saying that text shall be transmitted by UTF-8 and specifying some control codes. There are two payload types combined RED for simple RFC 2198 type redundancy and T140 for the text itself. The recommended sample time is 300 ms. This is in use in SIP applications and also specified in emergency service specifications.

2. RFC4351 also uses RTP in a very similar way to send RTT. But it has SDP declaration as audio and is transmitted multiplexed with audio codecs in a similar way as RFC 4733. The main use was intended to be for reliable transport of legacy real-time text through IP between VoIP gateways, where the extra ports needed for a separate text RTP stream through separate ports would possibly be expensive. RFC4351 was given Historic status already from its approval in order to discourage from any other use. Transmission is UTF-8-coded.

3. XEP-0301 is a draft XMPP extension, that transmits time sampled text in XMPP Messages, but not as Body, but as RTT XML elements, so it can be sent and presented as a gradually built up message, and then replaced by the message when completed. The recommended sample time is 700 ms, and in order to avoid jerky impression, the presentation of keystrokes are timed within these transmission intervals. Transmission is UTF-8.


Gunnar
--------------060008070104080107030301-- From randell-ietf@jesup.org Mon Nov 19 05:10:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E390521F8608 for ; Mon, 19 Nov 2012 05:10: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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVrLcV0-yuVL for ; Mon, 19 Nov 2012 05:10:43 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B2FA221F8557 for ; Mon, 19 Nov 2012 05:10:43 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2514 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TaR7a-000D8o-Mi; Mon, 19 Nov 2012 07:10:42 -0600 Message-ID: <50AA2FC6.6090409@jesup.org> Date: Mon, 19 Nov 2012 08:10:30 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A93D16.6010503@omnitor.se> In-Reply-To: <50A93D16.6010503@omnitor.se> Content-Type: multipart/alternative; boundary="------------060901000800000604070102" 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: Cc: "public-webrtc@w3.org" Subject: Re: [rtcweb] Text communication in RTCWEB sessions -job overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Nov 2012 13:10:57 -0000 This is a multi-part message in MIME format. --------------060901000800000604070102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 11/18/2012 2:55 PM, Gunnar Hellström wrote: > After a rapid browse, this is my view of what needs to be done to > specify real-time text in RTCWEB and WebRTC. > > 9. w3c.webrtc > add rtt API, e.g. to Network Stream API > important, urgent > > 10. w3c getusermedia > add rtt to GetUserMedia API > important, urgent W3C-ish stuff: This one would be complex, and probably shouldn't be in getUserMedia (though it could). A more equivalent API would be mediastream = video_element.captureStreamUntilEnded() - create a MediaStream from a video (or audio) element; you could do something like that. To implement this, there needs to be a DOM element to capture it via. The main options would be an element or a media element. But the are more issues, especially with a media element as a source, and serious UI issues if specified in them. A better question would be "What's the minimal (and most generic) API that covers the use cases, and do these abilites already exist?" I'll make an assertion: existing facilities for access to keystroke data (and certainly for text display) are sufficient, and the only API *needed* (and which covers all sorts of other use cases) would be the ability to insert/receive text data from a MediaStream from JS. E.g textstream = ; textstream.insert(key) (or keys). And the same in the other direction: textstream.ondata(function(keys, time) { do whatever with the keys }); I'd assert for text in a MediaStream that's a far more natural JS API - and so happens to also be very close to the API of a simple keystream over WebSocket or DataChannel. Another thing to note is that WebSockets and DataChannels are virtually identical (on purpose), so any work to standardize text chat over DataChannels would apply equally well to chat over WebSockets, which would have lots of real-world applications. This assumes that a MediaStream is the correct transfer mechanism (and correct API at the W3 level), which is definitely something I'd agree to at this point. I also wouldn't rule it out (I see some arguments in favor, as well as against) - but this needs to occur in public-webrtc@w3, and would do so before going too far down the path here assuming a MediaStream is the mechanism. For this part of the conversation, I strongly suggest it occur on public-webrtc, so reply there please. -- Randell Jesup randell-ietf@jesup.org --------------060901000800000604070102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/18/2012 2:55 PM, Gunnar Hellström wrote:
After a rapid browse, this is my view of what needs to be done to specify real-time text in RTCWEB and WebRTC.


9. w3c.webrtc
    add rtt API, e.g. to Network Stream API
    important, urgent

10. w3c getusermedia
    add rtt to GetUserMedia API
    important, urgent

W3C-ish stuff:
This one would be complex, and probably shouldn't be in getUserMedia (though it could).  A more equivalent API would be mediastream = video_element.captureStreamUntilEnded() - create a MediaStream from a video (or audio) element; you could do something like that.

To implement this, there needs to be a DOM element to capture it via.  The main options would be an <input> element or a media element.  But the are more issues, especially with a media element as a source, and serious UI issues if specified in them.

A better question would be "What's the minimal (and most generic) API that covers the use cases, and do these abilites already exist?"

I'll make an assertion: existing facilities for access to keystroke data (and certainly for text display) are sufficient, and the only API *needed* (and which covers all sorts of other use cases) would be the ability to insert/receive text data from a MediaStream from JS.  E.g textstream = <whatever>; textstream.insert(key) (or keys).  And the same in the other direction: textstream.ondata(function(keys, time) { do whatever with the keys });  I'd assert for text in a MediaStream that's a far more natural JS API - and so happens to also be very close to the API of a simple keystream over WebSocket or DataChannel. 

Another thing to note is that WebSockets and DataChannels are virtually identical (on purpose), so any work to standardize text chat over DataChannels would apply equally well to chat over WebSockets, which would have lots of real-world applications.

This assumes that a MediaStream is the correct transfer mechanism (and correct API at the W3 level), which is definitely something I'd agree to at this point.  I also wouldn't rule it out (I see some arguments in favor, as well as against) - but this needs to occur in public-webrtc@w3, and would do so before going too far down the path here assuming a MediaStream is the mechanism.

For this part of the conversation, I strongly suggest it occur on public-webrtc, so reply there please.

-- 
Randell Jesup
randell-ietf@jesup.org
--------------060901000800000604070102-- From randell-ietf@jesup.org Mon Nov 19 05:27:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF83321F85C2 for ; Mon, 19 Nov 2012 05:27: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=[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 wkIHIYNSruSp for ; Mon, 19 Nov 2012 05:27:49 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6821F85AF for ; Mon, 19 Nov 2012 05:27:49 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2732 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TaRO9-00024n-6y for rtcweb@ietf.org; Mon, 19 Nov 2012 07:27:49 -0600 Message-ID: <50AA33C8.4060903@jesup.org> Date: Mon, 19 Nov 2012 08:27:36 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50A0BC04.6090200@omnitor.se> <50A0E85E.4020201@alvestrand.no> <50A218FF.9050104@alvestrand.no> <50A93D16.6010503@omnitor.se> <50A986D9.5000705@alvestrand.no> <50A9F3B0.90604@omnitor.se> In-Reply-To: <50A9F3B0.90604@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions -job overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Nov 2012 13:27:50 -0000 On 11/19/2012 3:54 AM, Gunnar Hellström wrote: > > Yes, now after the overview of what would be needed in RTCWEB and > WebRTC to include RTT I agree that starting with "draft-x-rtcweb-rtt" > would be good for clarifying requirements and alternatives and draw > conclusions. > > For your info, all real-time text methods in IP environments transmit > time-sampled text, with sample time of 300 -700 ms. > > 1. RFC 4103 uses RTP, with redundancy to get reliability, and declares > the stream in SDP as text medium. T.140 is the text codec, just saying > that text shall be transmitted by UTF-8 and specifying some control > codes. There are two payload types combined RED for simple RFC 2198 > type redundancy and T140 for the text itself. The recommended sample > time is 300 ms. This is in use in SIP applications and also specified > in emergency service specifications. > > 2. RFC4351 also uses RTP in a very similar way to send RTT. But it has > SDP declaration as audio and is transmitted multiplexed with audio > codecs in a similar way as RFC 4733. The main use was intended to be > for reliable transport of legacy real-time text through IP between > VoIP gateways, where the extra ports needed for a separate text RTP > stream through separate ports would possibly be expensive. RFC4351 was > given Historic status already from its approval in order to discourage > from any other use. Transmission is UTF-8-coded. > > 3. XEP-0301 is a draft XMPP extension, that transmits time sampled > text in XMPP Messages, but not as Body, but as RTT XML elements, so it > can be sent and presented as a gradually built up message, and then > replaced by the message when completed. The recommended sample time is > 700 ms, and in order to avoid jerky impression, the presentation of > keystrokes are timed within these transmission intervals. Transmission > is UTF-8. I'd state (from this very short description) that XEP is a better match for web and webapps (and WebRTC), though XML is not necessarily an ideal encoding format for JS apps. But if interoperability with existing T.140-based infrastructure is important (and realize gateways will be involved!), then something easily transformed into RFC 4103/4351 might be preferred (if XEP can't be). (But this does not necessarily mean transmission over RTP is a *requirement* between a rtcweb UA and the gateway.) (Cue Hadriel's normal statement about gateways not always having access to the media channels.... ;-) Though he hasn't spoken about DataChannel gatewaying; it may make his head explode - sorry Hadriel.) -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Mon Nov 19 10:41:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5590221F86A8 for ; Mon, 19 Nov 2012 10:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_50=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 pVaP1akhjVLn for ; Mon, 19 Nov 2012 10:41:45 -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 192DD21F8616 for ; Mon, 19 Nov 2012 10:41:45 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5918903vbb.31 for ; Mon, 19 Nov 2012 10:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sC59WWA07Eu8YFMJjI2LloLrVV4/IN07KN7NPTGb4Bg=; b=guVL3P3rqAWLCpAv8jSWTRDx4xL1peB1pfF/niYKPA4nDcsjDHhjy5QC7Ho7O/r3zV JMA9YXarO/UWjMnP6paXdHl6YdJ1clq/TVT4nwJIyhFwuHK+kjCcrSqihNYgHU0tuqks cC5EvcL+GDx1r+xFAVKTm1/ANIQppIiVzKJoulpwAEMWHwZ8OCdJsKUerF2oGhwKTItK 4LIc/nuu3gxuwsQoHax83mkBv6JNTJdwWGKH2/bJ3J7e5A9dwA7LhVcU3TxXP8oX+zmj PyH+qjv/nsYbQI3V+Li9RjVVl48kAjVmYNSnKvMWuLTnpgH2Bgikq0MRiof9vYJyvvVD Eg0A== MIME-Version: 1.0 Received: by 10.220.223.13 with SMTP id ii13mr20142403vcb.2.1353350504463; Mon, 19 Nov 2012 10:41:44 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 19 Nov 2012 10:41:44 -0800 (PST) Date: Mon, 19 Nov 2012 10:41:44 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/mixed; boundary=14dae9cdc84f133e5b04cedd78b9 Subject: [rtcweb] Minutes for IETF 85 meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 18:41:48 -0000 --14dae9cdc84f133e5b04cedd78b9 Content-Type: text/plain; charset=ISO-8859-1 Please review the attached minutes and send comments by November 28th. Despite the valiant efforts of our minute takers (thanks Jean, Roni, Paul, and Richard!), there are a few question marks--please help us clear them up. thanks, Ted Hardie --14dae9cdc84f133e5b04cedd78b9 Content-Type: text/plain; charset=UTF-8; name="RTCWEBMinutesIETF85.txt" Content-Disposition: attachment; filename="RTCWEBMinutesIETF85.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9pxy10b0 77u/SUVURiA4NQ0KUlRDV0VCDQpDaGFpcnM6DQotIFRlZCBIYXJkaWUNCi0gQ3VsbGVuIEplbm5p bmdzDQotIE1hZ251cyBXZXN0ZXJsdW5kDQoNClNlc3Npb24gMQ0KTWludXRlIHRha2VyczogUm9u aSBFdmVuLCBKZWFuIE1haG9uZXkNCkphYmJlciBzY3JpYmU6IFBldGVyIFN0LiBBbmRyZQ0KTWVl dGVjaG8gUmVjb3JkaW5nOiBodHRwOi8vaWV0Zjg1LmNvbmYubWVldGVjaG8uY29tL2luZGV4LnBo cC9SZWNvcmRlZF9TZXNzaW9ucyNJRVRGODVfUlRDV0VCX1NFU1NJT05fSQ0KDQpBZG1pbmlzdHJp dmlhL3JlcG9ydHMgc2xpZGVzOmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODUvc2xp ZGVzL3NsaWRlcy04NS1ydGN3ZWItMC5wZGYNCk5vdGUgd2VsbCBwcmVzZW50ZWQuDQpCbHVlIHNo ZWV0cyBwYXNzZWQgYXJvdW5kLg0KDQpSZXBvcnQgZnJvbSBXZWJSVEMgRjJGIHNsaWRlczogaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9zbGlkZXMvc2xpZGVzLTg1LXJ0Y3dlYi0x LnBkZg0KUHJlc2VudGVyOiBIYXJhbGQgQWx2ZXN0cmFuZA0KDQpJbmZvIGFsc28gcHJlc2VudGVk IHRvIHRoZSBsaXN0LiANCkRlY2lzaW9uOiBEbyBub3QgY2hhbmdlIHRoZSBBUEkgaHVnZWx5IGF0 IHRoaXMgdGltZS4gDQpNaWNyb3NvZnQgaGFzIGJlZW4gd29ya2luZyBvbiB0aGUgQVBJIGFuZCBh cmUgZ29pbmcgYWhlYWQuIA0KDQpBY3Rpb25zIG5lZWRlZDoNClN0YXRlIGRpYWdyYW0gY2FuIGJl IHNldHRsZWQgYXQgdGhlIFczQy4gDQpJZiB5b3Ugd2FudCB0byBkbyBUcmlja2xlLUlDRSwgY3Jl YXRlIGFuIEFQSS4NCklmIHRoZSBJRVRGIHRoaW5rcyB0aGF0IHRoZSBwZXItdHJhY2sgcmVzb2x1 dGlvbiBpcyBhIGJhZCBpZGVhLCB0aGF0J3Mgb2suIE90aGVyd2lzZSBzcGVjaWZ5IHRoZSBtZWNo YW5pc20uICBXaGF0IHJhbmdlIG9mIHByaW9yaXR5IGFuZCB3aGF0IGhhcHBlbnMgd2hlbiB5b3Ug c2V0IGl0Pw0KDQpOZXh0IHN0ZXBzOg0KSW1wbGVtZW50IHRoZSBBUElzLg0KQ2hyb21lIGhhcyBp bmNvcnBvcmF0ZWQgcnRjd2ViDQoNCk5vIHF1ZXN0aW9ucyBvciBjb21tZW50cy4gDQoNClRlZCAt IE5COiBBbGwgdGhlIHdvcmsgb2YgVzNDIFdlYlJUQyBncm91cCB0YWtlcyBwbGFjZSBvbiBwdWJs aWMgbWFpbGluZyBsaXN0LiANCg0KU3VtbWFyeTogc2xpZGVzIHByZXNlbnRlZCwgdGVkJ3MgY29t bWVudC4NCg0KSUVURiBJUFIgUnVsZXMgc2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzg1L3NsaWRlcy9zbGlkZXMtODUtcnRjd2ViLTMucHB0DQpQcmVzZW50ZXI6IFNjb3R0 IEJyYWRuZXINCg0KRmlyc3QgYW5kIGxhc3QgYnVsbGV0cyBhcmUgaXJyZWxldmFudCAtIGV2ZXJ5 b25lIGhhcyB0byBmb2xsb3cgdGhlbS4NCkRvIHdoYXQgaXQgbWVhbnMsIG5vdCB3aGF0IGl0IHNh eXMuIA0KDQpJbiB0aGUgSUVURiwgd2Ugd2FudCB0byBhcHByb3ZlIHNwZWNpZmljYXRpb25zIHdp dGggbWluaW1hbCBvciBubyBlbmN1bWJyYW5jZXMuIFRoZXJlJ3Mgbm8gcmVxdWlyZW1lbnQsIGhv d2V2ZXIsIHVubGlrZSB0aGUgVzNDLg0KIA0KUnVsZSBzZXRzIGZvciBJUFIgLSBCQ1A3OSBhbmQg UkZDNjcwMSAoc2FuY3Rpb25zIGlmIHlvdSBkb24ndCBmb2xsb3cgdGhlIHJ1bGVzKQ0KDQpZb3Vy IElQUiBhcmUgcGF0ZW50cyBhbmQgcGF0ZW50cyBhcHBsaWNhdGlvbnMgb3duZWQsIGFzc2VydGFi bGUgb3IgbGljZW5zYWJsZSBieSB5b3Ugb3IgeW91ciBlbXBsb3llciBvciBzcG9uc29yIGFuZCBr bm93biBieSB5b3UuIFRoZSBlbXBsb3llciBjYW4ndCBrZWVwIHlvdSBpbiB0aGUgZGFyay4gDQoN CkphbWVzIFBvbGsgLSBJIm0gdW5mYW1pbGlhciB3aXRoLCAic2hvdWxkIGJlIGtub3duIg0KDQpT Y290dCAtICJyZWFzb25hYmx5IGtub3duIg0KDQpKYW1lcyAtIElmIEkgd29yayBpbiB0aGlzIHNw YWNlLCBzaG91bGQgSSBrbm93IHdoYXQgbXkgY29tcGFueSBpcyBkb2luZz8NCg0KU2NvdHQgLSB5 b3VyIGNvbXBhbnkgc2hvdWxkbid0IGtlZXAgeW91IGluIHRoZSBkYXJrLiBZb3UgZG9uJ3QgbmVl ZCB0byBiZSBhIGJ1c3lib2R5LiBOb3RlIHdlbGwgZGVmaW5lcyBhIGNvbnRyaWJ1dGlvbiAtIGFu eXRoaW5nIHlvdSBzYXkgb3Igd3JpdGUgdGhhdCBpcyBpbnRlbmRlZCB0byBhZmZlY3QgZGVsaWJl cmF0aW9ucy4gWW91IGFncmVlIGJ5IHJlZ2lzdGVyaW5nIGZvciB0aGUgbWVldGluZyBvciBieSBq b2luaW5nIHRoZSBtYWlsaW5nIGxpc3QuDQoNClRlZCAoYXMgaW5kaXZpZHVhbCkgLSBJZiB0aGUg Y2hhaXJzIGFzayBmb3IgY29uc2Vuc3VzIGFuZCBwYXJ0aWNpcGFudHMgc2VuZCBlbWFpbCwgdGhh dCBhZmZlY3RzIGRlbGliZXJhdGlvbnMuIElmIHBhcnRpY2lwYW50cyBodW0gaW4gYSBtZWV0aW5n LCBhcmUgdGhleSBjb250cmlidXRpbmc/DQoNClNjb3R0IC0gVGhhdCdzIGZ1enp5IGluIG91ciBw cm9jZXNzLiBCdXQgYnkgcmVnaXN0ZXJpbmcgZm9yIHRoZSBtZWV0aW5nIG9yIGpvaW5pbmcgIG1h aWxpbmcgbGlzdCB5b3UgaGF2ZSBhZ3JlZWQgdG8gdGhlIE5vdGUgV2VsbC4gQXBwbGllcyB0byBh bGwgY29udHJpYnV0aW9ucyBpbmRlcGVuZGVudCBvZiBzdGFuZGFyZHMgdHJhY2sgYmVjYXVzZSB5 b3UgZG9uJ3Qga25vdyBpZiBpdCB3aWxsIGJlIHN0YW5kYXJkcyB0cmFjay4NCg0KSWYgeW91IGhh dmUgeW91ciBvd24gSVBSIGluIHlvdXIgY29udHJpYnV0aW9uIC0geW91IG11c3QgZGlzY2xvc2Uu DQpJZiBpdCdzIHlvdXIgSVBSIGNvbnRyaWJ1dGVkIGJ5IGEgZmVsbG93IGVtcGxveWVlIC0gdGhl eSBtdXN0IGRpc2Nsb3NlIGl0LCB5b3UgZG9uJ3QgaGF2ZSB0by4gDQpJZiBpdCdzIHlvdXIgSVBS IGFuZCB5b3Ugbm90aWNlIGl0IGluIGEgY29udHJpYnV0aW9uIG9mIHNvbWVvbmUgZWxzZSBhbmQg eW91IHBhcnRpY2lwYXRlIC0geW91IG11c3QgZGlzY2xvc2UgaXQuIA0KSWYgeW91IHNlZSB5b3Vy IElQUiBpbiBzb21lIG90aGVyIGNvbnRyaWJ1dGlvbiwgYnV0IHlvdSBkb24ndCBwYXJ0aWNpcGFu dCAtIHdlIHdvdWxkIGxpa2UgZm9yIHlvdSB0byBkaXNjbG9zZS4gDQpJZiB5b3UgcG9pbnQgdG8g YW5vdGhlciBzdGFuZGFyZHMgYm9keSB3b3JrLCBhbmQgaXQgaGFzIElQUiAobm90IHlvdXJzKSAt IHlvdSBzaG91bGQgZGlzY2xvc2UuIA0KDQpTbGlkZTogUGFydGljaXBhdGUgDQoNClNpdHVhdGlv biAtIGVtcGxveWVyIHNhaWQgdG8gZW1wbG95ZWVzIHRoYXQgdGhleSB3ZXJlIG5vdCB0byBkaXNj bG9zZSBwYXRlbnQgYXBwbGljYXRpb25zLiBXZSBhc2tlZCB0aGF0IHRoZXkgbm90IHBhcnRpY2lw YXRlLiBJdCBoYXMgY2F1c2VkIHByb2JsZW1zIGluIGNvdXJ0IGNhc2VzLiBUaGUgbm9ybWFsIHBy YWN0aWNlIGlzIHRoYXQgdGhlIGNvbXBhbmllcyBkaXNjbG9zZSBldmVuIGlmIGVtcGxveWVlcyBh cmUgbm90IGFjdGl2ZS4gQXMgYSBzYWZldHkgcHJlY2F1dGlvbiAtIGFuZCB0aGUgY291cnRzIGFy ZSBzcGxpdCAtIGp1c3QgYmVpbmcgb24gdGhlIG1haWxpbmcgbGlzdCBpcyBhIG5lZWQgdG8gZGlz Y2xvc2UuIFRlZCdzIHF1ZXN0aW9uIGlzIGdvb2QgLSBpdCdzIGluIHRoZSBncmF5IGFyZWEuIFRo ZSBzcGlyaXQgb2YgQkNQNzkgaXMgdGhhdCBkaXNjbG9zdXJlcyBhcmUgaW1wb3J0YW50IHRvIHRo ZSBzdGFuZGFyZHMgcHJvY2Vzcy4gU29tZW9uZSBodW1taW5nIGlzIHBhcnRpY2lwYXRpbmcuIA0K DQpXZW5nZXIgLSBGb3IgdGhlIHJlY29yZCwgSSBkaXNhZ3JlZSB3aXRoIHRoZSBzdGF0ZW1lbnQu DQoNClNjb3R0IC0gSXQncyBub3QgY29uc2Vuc3VzLiBUaGUgSUVURiBsYXd5ZXIgaGFzIGFuIElE IHJlYWR5IHRvIGNvdmVyIHRoaXMgaXNzdWUuIFdlIHdpbGwgaGF2ZSB0byBzZWUuIEl0J3MgYW4g b3BlbiBpc3N1ZSBub3cuIFRoZSBydWxlcyBzYXkgaWYgeW91IHNpdCBvbiB5b3VyIGhhbmRzLCB5 b3UgZG9uJ3QgcGFydGljaXBhdGUuIA0KDQpTbGlkZTogRGlzY2xvc3VyZSBEZXRhaWxzDQoNClBh dGVudCAtIFBhdGVudCBudW1iZXIgYW5kIHRoZSBzcGVjaWZpYyBwYXJ0cyBvZiB0aGUgSUVURiBj b250cmliLiBBcHBzIGRvbid0IHJlcXVpcmUgdGhlIHNhbWUgZGV0YWlscy4NCkJsYW5rZXQgZGlz Y2xvc3VyZXMgYXJlIG5vdCBwZXJtaXR0ZWQgdW5sZXNzIG9mZmVyaW5nIHVuY29uZGl0aW9uYWwg ZnJlZSBsaWNlbnNlICAtIGUuZy4gbm8gcmVjaXByb2NpdHkuIA0KbGljZW5zaW5nIGluZm8gaXMg bm90IHJlcXVpcmVkIC0gbWlnaHQgd2FudCB0byBjaGFuZ2UgdGhhdCBhdCBzb21lIHBvaW50IC0g YnV0IGVuY291cmFnZWQuDQoNClBhcnRpY2lwYW50IC0gVGhlIGJsYW5rZXQgZGlzY2xvc3VyZSAt IGlzIHRoYXQgY29uc2Vuc3VzPw0KDQpTY290dCAtIEJsYW5rZXQgZGlzY2xvc3VyZSBmb3IgZnJl ZSBsaWNlbnNlIGlzIG9rDQoNCkhhcmFsZCAtIGRvIHdlIGhhdmUgSUVURiBjb25zZW5zdXMgdGhh dCBhICBmcmVlIGxpY2Vuc2UgbWVhbnMgbm8gcmVjaXByb2NpdHk/IA0KDQpTY290dCAtIHllcyAN Cg0KU2xpZGU6IFVzZSBvZiBEaXNjbG9zdXJlcw0KDQpXb3JraW5nIGdyb3VwcyBtYWtlIHVwIHRo ZWlyIG93biBtaW5kcy4gQ2Fubm90IGtub3cgYWJvdXQgY2xhaW1zIG9mIElQUnMgbm90IGRpc2Ns b3NlZC4gVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRvIHVuZGVyc3RhbmQgdGhhdCBub3QgYWxsIElQ UiBjbGFpbXMgYXJlIGFjY3VyYXRlIC0gc29tZSBhcmUgd2lzaGZ1bCB0aGlua2luZy4gVW50aWwg aXQgZ2V0cyB0byBjb3VydCwgeW91IGRvbid0IGtub3cgd2hhdCB0aGUgcGF0ZW50cyBjb3Zlci4g DQoNClBldGVyIFNhaW50LUFuZHJlIC0gQ2hhbmdlICJhbGwgSVBSIG1heSBub3TigKYiIHRvICJt aWdodCBub3QiIG9uIHRoZSBVc2Ugb2YgRGlzY2xvc3VyZXMgc2xpZGUuIFdlIHdyb3RlIGFuIFJG QyBvbiBlYXJseSBJUFIgZGlzY2xvc3VyZXMuDQoNClJhbmRhbGwgU3Rld2FydCAtIFdoYXQgYWJv dXQgZm9ybWVyIGVtcGxveWVlciA/DQoNClNjb3R0IC0gSWYgeW91IGhhdmUgbm8gc3RvY2ssIHN0 b2NrIG9wdGlvbnMgd2l0aCB5b3VyIGZvcm1lciBlbXBsb3llci4gTm8gY29uc2Vuc3VzLiBJZiB5 b3Uga25vdyBhYm91dCBpdCwgZGlzY2xvc2UuIEFueW9uZSBjYW4gbWFrZSBhIDNyZCBwYXJ0eSBJ UFIgZGlzY2xvc3VyZS4NCg0KS2VpdGggLSBXaGF0IGFib3V0IElQUiBpbiBub3JtYXRpdmUgcmVm ZXJlbmNlcz8NCg0KU2NvdHQgLSBIYXMgYmVlbiBkaXNjdXNzZWQsIG5vIGNvbnNlbnN1cy4gVW5s aWtlIElUVSB3aGljaCByZXF1aXJlcyB0cmFjaW5nLiBJZiB5b3UgZG8ga25vdyBvZiBzb21ldGhp bmcsIHRlbGwgdGhlIHdvcmtpbmcgZ3JvdXAuIEl0J3MgYSAzcmQgcGFydHkgZGlzY2xvc3VyZSwg dGhlIHdvcmtpbmcgZ3JvdXAgbmVlZHMgdG8ga25vdy4gTVBFRyAtIHRoZXJlcyBhIHppbGxpb24g cGF0ZW50cyBvbiB0aGF0LiBJdCdzIG5vdCBtYW5kYXRvcnkgLSB3b3JraW5nIGdyb3VwIHJlcXVp cmVzIGRpc2Nsb3N1cmUsIGJ1dCB5b3UgYXJlIG5vdCByZXF1aXJlZC4gDQogDQpXZW5nZXIgLSBJ J2xsIHB1c2ggYmFjayBvbiAzcmQgcGFydHkgZGlzY2xvc3VyZXMgLSBpdCdzIHVzZWZ1bCBmb3Ig d2cgdG8gaGF2ZSBhcyBtdWNoIGluZm8gYXMgdGhleSBjYW4gZ2V0LiBQcm92aWRpbmcgYWR2aWNl IG9yIGVuY291cmFnaW5nIDNyZCBwYXJ0eSBkaXNjbG9zdXJlcyB3aXRob3V0IHRlbGxpbmcgZm9s a3MgdGhhdCB0aGUgdGhlcmUgYXJlIHJpc2tzLiBJZiB0aGUgcGF0ZW50IGdvZXMgdG8gY291cnQs IHlvdSB3aWxsIGdldCBhIGNhbGwuIElmIHlvdSBjaGFuZ2Ugam9icywgeW91ciBjb250cmFjdCBk b2Vzbid0IGFsbG93IHlvdSBkaXNjbG9zZSBjb25maWRlbnRpYWwgaW5mby4gDQoNClNjb3R0IC0g WW91IGFyZSByaWdodCBvbiB0aGUgMXN0IHBvaW50LiBPbiB0aGUgMm5kIC0gaWYgdGhlIHBhdGVu dCBpcyBwdWJsaXNoZWQsIGl0J3Mgbm90IGNvbmZpZGVudGlhbC4gWW91IHdpbGwgYmUgY2FsbGVk IGlmIHlvdSBmaWxlIHRoZSBkaXNjbG9zdXJlLiANCg0KV2VuZ2VyIC0gSSB3YXNuJ3QgcmVmZXJy aW5nIHRvIHBhdGVudHMsIHlvdSB1c2luZyBpbmZvIHdoaWxlIGJlaW5nIG9uIHRoZSBqb2IgLSBp ZiB5b3Ugd3JvdGUgdGhlIGFwcGxpY2F0aW9uLCBhbmQgdGhlbiBtYWRlIHB1YmxpYyBzdGF0ZW1l bnRzIHRvIHRoZSBkZXRyaW1lbnQgb2YgeW91ciBlbXBsb3llciwgdGhlbi4uDQoNClNjb3R0IC0g dGhhdCdzIGEgd2FybmluZyBmb3IgZm9sa3MgZGlzY2xvc2luZyAzcmQgcGFydHkuDQoNClNwZW5j ZXIgLSB3ZSdyZSBvcHRpbWl6aW5nIGluIDIgZGltZW5zaW9ucyAtIGFza2luZyBsb3RzIG9mIGRl dGFpbHMgb2YgU2NvdHQgaXMgZ29vZCBiZWNhdXNlIGl0IHR1bmVzIHRoZSBJRVRGIHBvbGljeS4g DQoNClNjb3R0IC0gdGhlIElFVEYncyByb2xlIGlzIHRvIG1ha2UgZ29vZCB0ZWNoLCBub3Qgd29y cnkgYWJvdXQgY291cnRzLiANCg0KU3BlbmNlciAtIElmIEkgZW5kIHVwIGluIGNvdXJ0IGJ5IHdh bGtpbmcgYSBmaW5lIGxpbmUgYW5kIHRoZXkgcnVsZSBhZ2FpbnN0IGl0LiANCg0KU2NvdHQgLSBC ZSBiZXR0ZXIgdG8gZm9sbG93IHRoZSBzcGlyaXQuDQoNClRlZCAgLSBJJ2xsIHB1c2ggYmFjayBv biBXZW5nZXIgLSB3ZSdyZSBkZWFsaW5nIHdpdGggcHVibGlzaGVkIHBhdGVudHMgd2hlcmUgdGhl IGxhbmRzY2FwZSBpcyB3ZWxsIGtub3duLiBPdXIgcHJvcG9zYWxzIHJlZmVyZW5jZSBzcGVjaWZp Y2F0aW9ucyB0aGF0IGhhdmUgd2VsbC1rbm93biBsaWNlbnNlcy4gSG93ZXZlciwgd2UgaGF2ZSBu byBkaXNjbG9zdXJlcy4gV2UgaGF2ZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byB0aGVzZSBzcGVj cy4gSXQgd291bGQgaGF2ZSBiZWVuIGJldHRlciBpZiB0aGVyZSBoYWQgYmVlbiAzcmQgcGFydHkg ZGlzY2xvc3VyZXMgcmVnaXN0ZXJlZC4gM3JkIHBhcnR5IGRpc2Mgd291bGQgYmUgdmFsdWFibGUu IElmIG5vIG9uZSBlbHNlIGRvZXMsIEkgd2lsbCBtYWtlIHRoZSBkaXNjbG9zdXJlcyBteXNlbGYu IElmIG90aGVycyBoYXZlIDNyZCBwYXJ0eSBJUFIgdGhhdCB5b3UgY2FuIGV4cGxhaW4gd2h5IHlv dSBjYW4ndCBkaXNjbG9zZSwgY29tZSB0byBtZS4gDQoNCkJlcm5hcmQgLSBTb21lIG9mIHRoZSBk cmFmdHMgcmVmZXJlbmNlIG90aGVyIHN0YW5kYXJkcyBkb2NzIHdpdGggSVBSDQoNClNjb3R0IC0g V2UgaGF2ZSB0byBiZSBjYXJlZnVsIHdpdGggcHV0dGluZyBsaXN0cyBpbnRvIFJGQ3MuICBXZSBk b24ndCB3YW50IGEgaW5kaWNhdGlvbiB0aGF0IGl0J3MgYSBmdWxsIGxpc3RpbmcuIFJGQ3MgY2Fu J3QgYmUgY2hhbmdlZC4gQmV0dGVyIHRvIGNhcHR1cmUgdGhlIGluZm8gZWFybGllci4NCg0KV2Vu Z2VyIC0gSSB3b3VsZG4ndCBoYXZlIGlzc3VlcyBvbiBwYXRlbnRzIHdpdGggbGljZW5zZXMuIEl0 J3Mgbm90IGhlbHBmdWwgdGhhdCB0aGUgYWJzZW5jZSBvZiBpdCBtZWFucyBILiAyNjQgaXMgZW5j dW1iZXJlZC4gSWYgd2UgcHV0IGVuY3VtYnJhbmNlcyBvbiBldmVyeXRoaW5nIGl0IGRvZXNuJ3Qg bWFrZSBzZW5zZS4gDQoNClNjb3R0IC0gVGhlIElQUiBpbiBSVFAgcGF5bG9hZHMgaGFzIGNvbWUg dXAgaW4gdGhlIHBhc3QuIFRoZSBjb25jbHVzaW9uIGlzIHRoZSBwYXlsb2FkIGlzIGFuIGVudmVs b3BlLCBhbmQgaXQgaXMgbm90IGEgcHJvYmxlbS4gVGhlIHF1ZXN0aW9uIG9mIHVzaW5nIFggaXMg YSBzZXBhcmFibGUgaXNzdWUuIFVzaW5nIFggYXMgcGFydCBvZiBzdGFuZGFyZCBpcyBkaWZmZXJl bnQgdGhhbiB0cmFuc3BvcnRpbmcgWC4gIA0KDQpKU0VQIERvY3VtZW50IFVwZGF0ZSAobm9uLVNE UClzbGlkZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODUvc2xpZGVzL3NsaWRl cy04NS1ydGN3ZWItMi5wZGYNClByZXNlbnRlcjogSnVzdGluIFViZXJ0aQ0KDQpTbGlkZTogVzND IFN0YXR1cw0KDQpnZXRVc2VyTWVkaWEgdGltaW5nIC0gYSBwcm9wb3NhbCAtIGdldCBhIG1lZGlh IHN0cmVhbSBpbW1lZGlhdGVseSBidXQgZG9lc24ndCBnZXQgZGF0YSB1bnRpbCB1c2VyIGdpdmVz IGFjY2VzcyB0byB0aGUgY2FtZXJhLg0KDQptdWx0aXBsZSBzdHJlYW1zL3RyYWNrcyAtIG5vIHdh eSB0byBkZXNjcmliZS4gTmVlZCBhIHdheSB0byBjb250cm9sIHdoYXQgZ2V0cyBzZW50Lg0KDQpE VE1GIEFQSSAtDQoNCk1hcnRpbiBUaG9tc29uIC0gd2UndmUgcmVzb2x2ZWQgdGhpcyBvbmUuIEhh cmFsZCBoYXMgYSBkcmFmdC4gDQoNCkN1bGxlbiAtIHdyb25nIHdvcmtpbmcgZ3JvdXAsIHdlJ3Jl IGV4cGVjdGluZyBhIHByb3Bvc2FsLiBEVE1GIGlzIGdvaW5nIGZvcndhcmQuIA0KDQpTbGlkZTog Q2hhbmdlcyB0byBKU0VQIC0wMg0KDQpNYXR0aGV3IEthdWZtYW4gLSBJdCdzIGEgYmFkIGlkZWEg LXlvdSBnZXQgYSBkZWxheWVkIGhlbGxvLiBZb3UgaGF2ZSB0byBiZSBhYmxlIHRvIHJlY2VpdmUu IA0KDQpKdXN0aW4gLSB5b3UgY2FuIGdldCB5b3VyIFNTUkNzIGdvaW5nIGJlZm9yZSB0aGUgaGVs bG8uDQoNClNsaWRlOiBEb2N1bWVudCByZXZpZXcgbm90ZXMNCg0KQ2hyaXN0ZXIgLSBhcmUgeW91 IGdvaW5nIHRvIHNob3cgdGhlIHN0YXRlIG1hY2hpbmUgYWdyZWVtZW50PyANCg0KSnVzdGluIC0g VGhlcmUgaXMgYSBwcm9wb3NhbCBkb2Mgb24gdGhlIFczQyBsaXN0LiANCkFDVElPTjogSnVzdGlu IHRvIHNlbmQgYSBsaW5rLiANCg0KU2xpZGU6IFByb3Bvc2FsIGZvciBTRFAgdGhhdCBNVVNUIGJl IGltcGxlbWVudGVkDQoNCk1hdHRoZXcgS2F1Zm1hbiAtIG5vdCBhbiBvcGVuIGlzc3VlIC0gcmVj ZWl2ZSBmcm9tIG90aGVyIHNpZGUgbm8gbWxpbmUuIE1TSUQgaXNzdWUgc2FtZSBhcyB0aGUgTm8g Wz8/XSBpc3N1ZS4NCg0KSnVzdGluIC0gYWdyZWUNCg0KU2xpZGU6IFByb3Bvc2FsIGZvciBTRFAg dGhhdCBNQVkgYmUgaW1wbGVtZW50ZWQNCg0KQ29sbGluIFBlcmtpbnMgLSBCZSBjYXJlZnVsIHdp dGggdGhlIE1BWSwgaWYgeW91IGFyZSB1c2luZyB0aGlzIG9wdGlvbmFsIFJUUCBmZWF0dXJlLCBv dGhlciBpdGVtcyBiZWNvbWVzIE1VU1QgKFJlZHVjZWQgc2l6ZSBSVENQIC0geW91IG11c3QgaW1w bGVtZW50IHRoZSBTRFApLiANCg0KSnVzdGluIC0gU28gd2UgbmVlZCB0byBzYXksIGlmIHlvdSBz dXBwb3J0IHRoaXMgZmVhdHVyZSwgdGhlbiB5b3UgTVVTVC4NCg0KQmVybmFyZCAtIElmIHlvdSBz dXBwb3J0LCB5b3UgbXVzdCBpbmNsdWRlIGl0IGluIHRoZSBvZmZlci4gDQoNClJhbmRlbGwgSmVz dXAgLSB5b3Ugd2FudCA1NTA2Lg0KDQpDaHJpc3RlciAtIFJGQzU4ODggaXMgbGlzdGVkIGFzIE1V U1QsIGlzIHRoZXJlIGEgc3BlY2lmaWMgdXNlPw0KDQpKdXN0aW4gLSBUaGUgZ3JvdXBpbmcgZnJh bWV3b3JrIGRlZmluZXMgbWlkLCB3aGljaCBtYWtlcyB0aGluZ3MgbGVzcyBmcmFnaWxlLiANCg0K TGVubm94IC0gU0RQIGhhcyBib3RoIG1pZCBhbmQgbGFiZWwNCg0KSnVzdGluIC0gbGFiZWwgaXMg aHVtYW4gcmVhZGFibGUuIFRoZSBtaWQgcmVmZXJlbmNlcyB0aGUgbWxpbmUuIA0KDQpMZW5ub3gg LSBpbiB0aGUgUlRQIHNwZWMgdGhlcmUncyBbPz9dIHJlZmVyZW5jZWQuIElmIHlvdSBkb24ndCBk byBydGNwIG11bHRpcGxleGluZyBbPz9dDQoNCkp1c3RpbiAtIGNvdmVyZWQgaW4gSUNFLg0KDQpM ZW5ub3ggLSBbPz9dIG5lZWRzIHRvIGJlIGV4cGxpY2l0IA0KDQpQYXVsIEt5eml2YXQgLSBJcyB0 aGlzIGV4aGF1c3RpdmUgbGlzdCBmb3IgU0RQPw0KDQpKdXN0aW4gLSB5ZXMuIA0KDQpMZW5ub3gg LSBpdCAgaW1wbGllcyBBVlBGLCB3aGljaCBpcyBub3QgbGlzdGVkIGhlcmUuIA0KDQpBQ1RJT046 IEFkZCBBVlBGIGFuZCBpdHMgbm9ybWF0aXZlIHJlZmVyZW5jZXMuIA0KDQpLYXVmbWFuIC0gd2Ug bmVlZCBhbiBleGhhdXN0aXZlIGxpc3Qgb2Ygd2hhdCBNVVNUIGJlIGltcGxlbWVudGVkLCBvdGhl cndpc2UgaXQgd2lsbCBob2xkIHVwIHRoZSBXM0Mgc3BlYy4NCg0KRWNrZWwgLSBTRFAgc2lnbmFs aW5nIGZvciBCRkNQIGZvciBjb250ZW50IHNoYXJpbmcgYW5kIFNDVFAgWz8/XS4NCg0KSnVzdGlu IC0gQkZDUCB3aWxsIGJlIGFuIGFwcGxpY2F0aW9uIGlzc3VlLiBJIGRvbid0IHdhbnQgdG8gcHJv dmlkZSBhIEJGQ1Agc3RhY2suIA0KDQpFY2tlbCAtIHRoZSBkcmFmdCBpcyBvbiB0aGUgcHB0DQoN ClJlc2NvcmxhIC0gV2h5IGlzIDY1NDQgb24gdGhlIGxpc3Q/DQogICAgICAgICAgICAgICAgICAg ICAgICAgIA0KSnVzdGluIOKAkyB0byBkbyBJQ0Ugd2hlcmUgVURQIGRvZXMgbm90IHdvcmsNCg0K UmVzY29ybGEgLSBXZSdsbCB0YWtlIHRoZSBkaXNjdXNzaW9uIHRvIHRoZSBsaXN0Lg0KDQpIYXJh bGQgLSB0aGUgc3BlYyBkb2Vzbid0IG5lZWQgdG8gbWVudGlvbiBldmVyeSBTRFAgc3BlYy4gNjIz NiAtIHNob3VsZCB3ZSBiZSBhYmxlIHRvIG5lZ290aWF0ZSBpbWFnZSByZXNvbHV0aW9uIC0gbmVl ZCB0byByZXNvbHZlLg0KDQpKdXN0aW4gLSBUbyBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24sIHdl IG5lZWQgdG8gYWRkIG1vcmUgUkZDcyB0byB0aGUgTVVTVCBpbXBsZW1lbnQgbGlzdC4gRm9yIFNE UCB0aGF0IE1BWSBiZSBpbXBsZW1lbnRlZCwgb3RoZXIgUkZDcyBiZWNvbWUgbWFuZGF0b3J5IHRv IGltcGxlbWVudC4gDQoNCioqKiANClNsaWRlOiBGb3JraW5nIHdpdGggUFJBTlNXRVINCg0KS2F1 Zm1hbiAtIElzIHRoaXMgc2VyaWFsIGZvcmtpbmc/IA0KDQpKdXN0aW4gLSB5ZXMNCg0KQ2hyaXN0 ZXIgLSBsb29rcyBnb29kLiBJc3N1ZSAtIFdoZW4geW91IHJlY2VpdmUgcHJhbnN3ZXIgZnJvbSB0 aGUgUFNUTiBhbmQgeW91IG9mZmVyIG9uIHRoYXQgbGVnLCB0aGF0J3Mgbm90IGNvdmVyZWQgaW4g dGhlIHN0YXRlIG1hY2hpbmUuIEN1bGxlbiBzYWlkIHRoYXQgaXQncyBhIHNpZ25hbGluZyBpc3N1 ZS4gDQoNCkthdWZtYW4gLSBpbiB0aGUgSlNFUCBBUEksIG5vdCBvbmx5IGNhbiB5b3Ugd2FpdCBm b3IgdGhlIGFuc3dlciwgeW91IGNhbiBnZW5lcmF0ZSBhIG5ldyBvZmZlciBiZWZvcmUgZ2V0dGlu ZyBhbiBhbnN3ZXIuIA0KDQpKdXN0aW4gLSBEb2VzIHRoaXMgaGFwcGVuIGVub3VnaCBpbiB0aGUg cmVhbCB3b3JsZD8gSSdsbCB0YWxrIGFib3V0IG1vcmUgaW4gdGhlIG5leHQgc2xpZGUuDQoNClJl c2NvcmxhIC0gSSBkb24ndCBoYXZlIGlzc3VlcyB3aXRoIHRoZSBzbGlkZSAtIGl0J3Mgbm90IGVu Zm9yY2VkIGF0IEpTRVAgbGF5ZXIsIEknbSBnb29kIHdpdGggaXQuDQoNCkN1bGxlbiAoYXMgaW5k aXZpZHVhbCkgLSB0aGUgc2lnbmFsaW5nIGNhbiBiZSBzZXJpYWxseSBvciBwYXJhbGxlbCBmb3Jr ZWQuIFRoZSBjYXNlcyB3aGVyZSB5b3UgaGF2ZSAxIG9yIDIgc3RyZWFtcyBvZiBtZWRpYSBhdCB0 aGUgc2FtZSB0aW1lLiBXaGF0IGFyZSB0aGUgdXNlIGNhc2VzIHRoYXQgd2UgY2FuJ3Qgc3VwcG9y dCB3aXRoIHByYW5zd2VyLiBTaW11bHRhbmVvdXMgMiBzdHJlYW1zIG9mIG1lZGlhIGNhbid0IGJl IGRlYWx0IHdpdGguIA0KDQpDaHJpc3RlciAtIEknbSB0YWtpbmcgYWJvdXQgc2VyaWFsIGZvcmtp bmcsIDEgc3RyZWFtIGF0IHRoZSB0aW1lLiANCg0KUmljaGFyZCBFemphayAtIEluIHNlcmlhbCBm b3JraW5nIGNhc2UsIGlmIHlvdSBuZWVkIHRvIHJlbmVnb3RpYXRlLCBhbmQgeW91IHRlcm1pbmF0 ZSBhbmQgdXNlIG9yaWdpbmFsIG9mZmVyIHRoYXQgaGFkIGJlZW4gZm9yd2FyZGVkLCB0aGF0IGNh c2UgZmFpbHMgd2l0aCBwcmFuc3dlci4gDQoNCkp1c3RpbiAtIHNvIEEgaGFzIGFuIG9mZmVyIHRv IEIgYW5kIEMgYW5kIEIgaGFzIHByYW5zd2VyIGFuZCB3YW50cyB0byByZW5lZ290aWF0ZS4gQSBo YXMgdG8gY2xvc2UgdG8gcmVuZWdvdGlhdGUuIEFueXRoaW5nIGNvbWVzIGZyb20gQyBpcyBTT0wu IA0KDQpKdXN0aW4gLSBBQ1RJT046IG5lZWQgdG8gZGVzY3JpYmUgdGhlIHVzZSB1c2UgY2FzZXMg d2UgY2FuJ3Qgc3VwcG9ydC4NCg0KQ2xvbmluZyAtIERldGFpbHMNCg0KS2FwbGFuIC0gR28gYmFj ayB0byB0aGUgRm9ya2luZyB3aXRoIFBSQU5TV0VSIHNsaWRlIC0gaG93IG9mdGVuIGRvZXMgdGhl IG9mZmVyIHRvIFBTVE4sIGl0IHNlbmRzIGEgUFJBTlNXRVIgLiAgSXQgd29uJ3QgaGFwcGVuIG9m dGVuLiBZb3Ugd291bGQgaGF2ZSB0byBnbyB0aHJvdWdoIGFuIGludGVybWVkaWFyeSBhbnl3YXkg LSB0aGV5IGNhbiBoYW5kbGUgaXQuIERvbid0IGNvbXBsaWNhdGUgd29ybGQgZm9yIHRoZSBicm93 c2VyIHNpZGUuICBPbiBjbG9uaW5nIC0gb24gdGhlIGJyb3dzZXIgY3NzZSAtIHRoZSBmb3JraW5n IGNhc2UgaXMgdXNlZnVsIC0gZGlzcGxheSAyIHNjcmVlbnMsIGNhbiBtaXguIFNJUCBvbmx5IHBp Y2tzIG9uZSBzdHJlYW0uIElmIGl0J3MgbG90IG9mIGNvZGUgYW5kIGJ1ZyBpbnRyb2R1Y3Rpb24g aW50byB0aGUgYnJvd3NlciwgSSB3b3VsZG4ndCBkbyBpdCBmb3IgUFNUTiBpbnRlcm9wZXJhYmls aXR5LiBUaGUgbWlkZGxlYm94ZXMganVzdCBwaWNrIG9uZSBzdHJlYW0gYW5kIHRoZSBjbGllbnRz IGRvbid0IHNlZSBpdC4gDQoNCkp1c3RpbiAtIHdlIGFncmVlIHRoYXQgZGlzcGxheWluZyBtdWx0 aXBsZSBzdHJlYW1zIG1pZ2h0IGJlIHVzZWZ1bC4gSG93ZXZlciwgaG93IHVzZWZ1bCBpcyBpdCB0 byBoZWFyIFVTIGFuZCBFdXJvIGRpYWwgdG9uZXMgYXQgdGhlIHNhbWUgdGltZT8NCg0KTWFydGlu IC0gZG8gUkZDWz8/XQ0KDQpKdXN0aW4gLSBhZ3JlZQ0KDQpNYXJ0aW4gLSBpZiB5b3UgYXJlIGNy ZWF0aXZlIHdpdGggU0RQIHN5bnRoZXNpcywgUFJBTlNXRVIgaXMgc3VmZmljaWVudCBmb3IgY2xv bmluZyBhbmQgdGhlIG11bHRpcGxlIHN0cmVhbXMuIFlvdSBkb24ndCBhZmZlY3QgYnJvd3NlciBz dGF0ZS4gWW91IGNhbiBtaXggb3IgZGlzcGxheSBpbiBkaWZmZXJlbnQgdGFncy4gRG9uJ3QgbmVl ZCBjbG9uaW5nLiBDYW4gc3VwcG9ydCBwYXJhbGxlbCBmb3JraW5nLiANCg0KQ2hyaXN0ZXIgLSBQ U1ROIGlzbid0IGdvaW5nIHRvIGdpdmUgbmV3IG9mZmVyLiBUaGUgUFNUTiBpc24ndCB0aGUgb25s eSByZW1vdGUgZW5kIHBvaW50LiBUaGVyZSBhcmUgbGVnYWN5IFNJUCBlbmRwb2ludHMuIFdvbid0 IGhhcHBlbiBvZnRlbi4gRm9ya2luZyB3aXRoIGNsb25pbmcgLSBpdCBkb2Vzbid0IG1lYW4gdGhh dCB3ZSdyZSBkZWFsaW5nIHdpdGggbXVsdGltZWRpYSwgb25seSBtZWRpYSB3aXRoIGxhdGVzdCBj bG9uZS4gV29yayBpbiBhIHNlcmlhbCBtYW5uZXIuIFdlIG5lZWQgdG8gZG9jdW1lbnQgbGltaXRh dGlvbnMuIA0KDQpMZW5ub3ggLSBvdGhlciB0aGFuIGRlbXV4LCANCg0KSnVzdGluIC0gSXQncyBs aWtlIGFub3RoZXIgcGVlciBjb25uZWN0aW9uIHNoYXJpbmcgDQpMZW5ub3ggLSB5b3UgaGF2ZSB0 byBrbm93IGJlZm9yZSBpbnN0YWxsaW5nIGFuc3dlciAxIHRoYXQgYW5zd2VyIDIgbWF5IGJlIGNv bWluZy4gSWYgeW91IGNsb25lLCBpdCBhcyBpZiBhbiBhbnN3ZXIgaGFkbid0IGJlZW4gcmVjZWl2 ZWQuIFN0ZXAgMyBvbiB0aGUgRm9ya2luZyB3aXRoIENsb25pbmcgc2xpZGUgaXNuJ3QgbmVjZXNz YXJ5LiANCg0KSnVzdGluIC0geW91IG5lZWQgYSBtYWdpYyB0aW1lb3V0Lg0KDQpSaWNoYXJkIC0g Z3JlYXQgaWYgeW91J3ZlIGFuc3dlcmVkIHRoZSBwYXJlbnQuIFRoZSB0aW1pbmcgb2Ygd2hlbiB0 byBjbG9uZSBuZWVkcyB0byBiZSBkaXNjdXNzZWQuIFBSQU5TV0VSIHN1cHBvcnRzIGNsb25pbmcs IGJ1dCBpZiBlbmQgcG9pbnRzIGRvIG11bHRpcGxlIFs/P10gYW4gaXNzdWUsIGl0IGFwcGxpZXMg d2hldGhlciBpdCdzIHNlcmlhbCBhbmQgcGFyYWxsZWwgZm9ya2luZy4gDQoNCk1hZ251cyAoYXMg Y2hhaXIpIGRpc2N1c3Npb24gaXMgY2xvc2VkIGFmdGVyIHRoaXMuIA0KDQpSYW5kZWxsIC0gcmVh bCB3b3JsZCBzaXR1YXRpb246IFRlbGVjb20gc2VuZHMgb2ZmZXIgdG8gdGhlIHNlcnZlci4gVGhl IHNlcnZlciBzYXlzIHRoZSBwZXJzb24gY291bGQgYmUgYXQgc2V2ZXJhbCBwbGFjZXMgKHRhYmxl dCBhbmQgcGhvbmUsIGV0YyksIG11bHRpcGxlIHBlb3BsZSBwaWNrIHVwLiBZb3UgZG9uJ3QgaGF2 ZSB0byBpbXBsZW1lbnQgdGhhdC4gUGFyYWxsZWwgZm9yayB3aXRoIG11bHRpcGxlIHN0cmVhbXMg bWFrZXMgc2Vuc2UuIGdvb2dsZSArIC0gaW52aXRlIHRvIGEgZ3JvdXAgLSBtdWx0aXBsZSBhbnN3 ZXIgYW5kIHBlb3BsZSBleHBlY3QgYSBicmlkZ2UgY29uZmVyZW5jZS4gTm9uZSB0ZWxjbyBjYXNl IC0gZG9uJ3QgaGF2ZSBtZWRpYSBzdHJlYW1zIGFzc29jaWF0aW9ucywgZ2FtaW5nIGNhc2VzLiBJ ZiB5b3UgY2FuIGRvIGl0IHdpdGggb3V0IGNsb25pbmcgZ3JlYXQuIEJ1dCBpdCB3b3VsZCB3b3Jr Lg0KDQpKdXN0aW4gLSBUaGUgc2VydmVyIGlzIGNvbm5lY3RpbmcgeW91IHRvIHNvbWVvbmUuIA0K DQpDdWxsZW4gLSB1c2UgY2FzZXMgLSBvbmUgc3RyZWFtIG9mIG1lZGlhIGF0IGEgdGltZS4gRm9y IGJyaWRnZSBsaW5lIGFwcGVhcmFuY2UgdXNlIGNhc2VzLCBwYXJhbGxlbCBmb3JraW5nIGRpZG4n dCB3b3JrIGFzIGEgZ2VuZXJhbCBzb2x1dGlvbi4gQSBtaXhlciBzZXRzIHVwIHRoZSBjb25mZXJl bmNlIGFuZCBtaXhlcyB0aGUgaW5mby4gVGhlIGdhbWluZyB1c2UgY2FzZSBpcyBzZXR0aW5nIHVw IHBlZXIgY29ubmVjdGlvbnMgaW4gYSBtZXNoLiBMZWF2ZSBjbG9uaW5nIHVudGlsIGxhdGVyLCB1 bnRpbCB3ZSBrbm93IHdlIG5lZWQgaXQuIA0KDQpSZXNjb3JsYSAtIHRoaXMgaXMgb3ZlciBlbmdp bmVlcmluZy4gVGhlIHJpc2sgaXMgbG93IHRoYXQgd2UgbmVlZCB0aGlzLg0KDQpLYXBsYW4gLSBJ dCdzIGEgcHJvYmxlbSBvZiBzaWduYWxpbmcsIGEgc2VydmVyIGNhbiB0ZWxsIHRoZSBicm93c2Vy IHRvIGNyZWF0ZSBhIHBlZXIgY29ubmVjdGlvbi4gV2hhdCBoYXBwZW5zIHRvIHRoZSBwcml2aWxl Z2VzPyANCg0KSnVzdGluIC0gdGhlIHByaXZpbGVnZXMgYXJlIG9uIHRoZSBtZWRpYSBzdHJlYW1z Lg0KDQpLYXBsYW4gLSBJJ2QgbGlrZSB0byBzYXkgZm9yZ2V0IGNsb25pbmcuDQoNCkp1c3RpbiAt IG5lZWQgbmV3IGNhbmRpZGF0ZXMgb24gbmV3IHBlZXIgY29ubmVjdGlvbi4gVGhlIGNsb25lIHdv dWxkIGtlZXAuIA0KDQpSalMgLSBJZiB5b3UgYWxsb3cgc2VyaWFsIGZvcmtpbmcgd2l0aCBTSVAs IHlvdSB3aWxsIGdldCBwYXJhbGxlbCBmb3JraW5nIGZvciBicmllZiBwZXJpb2RzIG9mIHRpbWUu IFRoaW5rIHRocm91Z2ggdGhlIHVzZSBjYXNlcy4gDQoNCkp1c3RpbiAtIHN1bW1hcml6aW5nIC0g SSB3YW50ZWQgdG8gaGVhciBzdXBwb3J0IGZvciBjbG9uaW5nLiBJIGRpZG4ndCBoZWFyIHRoYXQu IFBlZXIgYW5zd2VyIGRvZXMgd2hhdCB3ZSBuZWVkLiBJZiB3ZSBuZWVkIGNsb25pbmcgbGF0ZXIg LSB3ZSdsbCBkZWFsLiANCg0KTWFnbnVzIC0gSHVtIHRvIHNlZSBpZiBQUkFOU1dFUiBpcyBzdWZm aWNpZW50Pw0KDQpwcmFuc3dlciBzdWZmaWNpZW50PyBzdHJvbmdlciBodW0NCg0KUHJhbnN3ZXIg aXMgbm90IHN1ZmZpY2llbnQ/IHdlYWtlciBodW0NCg0KVGVkOiBOb3Qgc3Ryb25nIGNvbnNlbnN1 cy4gQUNUSU9OOiB0YWtlIHRvIHRoZSBsaXN0DQoNClF1aXJrcyBtb2RlOg0KDQp3aGF0IGlzIGFj dHVhbGx5IHNlbnQgdmVyc3VzIHdoYXQgaXQgbWVhbnQuIA0KDQpKdXN0aW4gLSB3ZSBzaG91bGQg YmUgc3RyaWN0LiBJZiB3ZSB0YWxrIHRvIGxlZ2FjeSwgdGhvdWdoIGdvIHRvIHF1aXJrcyBtb2Rl LiANCg0KVGhvbXNvbiAtIGFncmVlDQoNCkthdWZtYW4gLSBzaW5jZSB0aGUgYnJvd3NlciBpcyBu b3QgdGFsa2luZyB0byBlbmRwb2ludHMgZGlyZWN0bHksIHRoZSBtaWRkbGVib3ggY2FuIGZpeCBp dC4gV2hhdCBlcnJvciBzaG91bGQgd2UgcmFpc2U/IA0KDQpKdXN0aW4gLSBXaHkgY2FuJ3QgeW91 IHRhbGsgdG8gdGhlIFNJUCBkZXZpY2U/DQoNCkthdWZtYW4gLSBZb3UgY2FuIGZpeCBpbiB0aGUg amF2YSBzY3JpcHQuDQoNCkJlcm5hcmQgLSBJbiBjcmVhdGluZyB0aGUgb2ZmZXIsIHlvdSBkZXNj cmliZSB3aGF0IHlvdSBzdXBwb3J0LiBTdHJpY3QgaW4gd2hhdCB5b3Ugc2VuZCBhbmQgbGliZXJh bCB3aXRoIHdoYXQgeW91IHJlY2VpdmUuIERvbid0IGNyZWF0ZSBhIHF1aXJrcyBtb2RlIC0gdGhl cmUgd2lsbCBiZSBubyBlbmQgdG8gaXQuIENyZWF0ZSBwcmluY2lwbGVzIGZvciB3aGF0IHNlbmQg YW5kIHJlY2VpdmUuIA0KDQpKdXN0aW4gLSBCZWluZyBzdHJpY3Qgd2lsbCBrZWVwIHVzIHNhbmUu DQoNCkthcGxhbiAtIFF1aXJrcyBtb2RlIGNvbmNlcHQgLSBpZiB0aGUgamF2YXNjcmlwdCBuZWVk cyB0byBpbnRlcmNlcHQsIHRoYXQncyB3aGVyZSBpdCBzaG91bGQgaGFwcGVuLiBUaGUgYnJvd3Nl ciBzaG91bGQgcmVtYWluIGNsZWFuLiANCg0KSGFyYWxkIC0gaWYgc3BlY2lmeSBxdWlya3MgbW9k ZSwgdGhlbiB3ZSBoYXZlIGRlZmluZSBpdCBhbmQgaW1wbGVtZW50IGFuZCBsaXZlIHdpdGggaXQg Zm9yZXZlci4gcXVpcmtzIGhhdmUgbm8gcGxhY2UgaW4gY3JlYXRlIG9mZmVyLiBxdWlya3MgaXMg cmVzcG9uc2liaWxpdHkgb2YgdGhlIGphdmFzY3JpcHQgY29kZXIuIA0KDQpSYW5kZWxsIC0gSSBk b24ndCB1bmRlcnN0YW5kIGF2b2lkaW5nIHF1aXJrcyBtb2RlLiBIb3cgZG8geW91IGtub3cgeW91 IGFyZSB0YWxraW5nIHRvIGl0IHVudGlsIHlvdSBnZXQgdGhlIGFuc3dlci4gRG9uJ3QgaW1wbGVt ZW50IHF1aXJrcyBtb2RlLiBQdXNoIHRoYXQgb250byB0aGUgZ2F0ZXdheSAtIHNlcnZlciBvciBz aWduYWxpbmcgZ2F0ZXdheS4gS2VlcCB0aGluZ3MgY2xlYW4uIA0KDQpDdWxsZW4gLSBqYXZhc2Ny aXB0IHJlbW92ZXMgdGhlIEYgZnJvbSB0aGUgQVZQIHRvIGludGVyb3BlcmF0ZS4gSXQncyBjb21t b24uIEkgZG9uJ3QgY2FyZSBpZiB3ZSBkbyBpdCBvciBub3QuIFdlIG5lZWQgdG8gYmUgY29uc2lz dGVudCBvbiBlZGl0aW5nIHRoZSBTRFAuIA0KDQpNYWdudXMgLSBkaXNjdXNzaW9uIGNsb3NlZC4g DQoNCkp1c3RpbiAtIHRvIHN1bW1hcml6ZSAtIHdlIHNob3VsZG4ndCBnZW5lcmF0ZSBxdWlya3kg U0RQLCBhbmQgbGVhdmVzIGZpeGluZyBxdWlya3kgU0RQIHRvIHRoZSBhcHBsaWNhdGlvbi4gDQoN Ck1lZGlhU3RyZWFtIElEDQoNCkhvdyBkbyBzZW5kIGFuZCBkZW11eD8NCg0KSnVzdGluIC0gaXMg dGhlcmUgYW4gdzJjIElEIG5vdz8NCg0KTWFydGluIC0geWVzLg0KDQpKdXN0aW4gLSB0aGVzZSBz bGlkZSBhcmUgb2xkLg0KDQpTdHJlYW0gc2VsZWN0aW9uIE8vQQ0KDQpQcm9wb3NpbmcgYSAzd2F5 IGhhbmRzaGFrZQ0KDQpSb25pIC0gR28gYmFjayB0byBTdHJlYW0gU0RQIHNsaWRlLiBZb3UgYXNz dW1lIHRoYXQgeW91IGhhdmUgYWxsIHRoZSBTU1JDcyB0aGF0IHlvdSBjYW4gc2VuZC4gVGhlcmUg aXMgYSB0b3BvbG9neSB3aGVuIHRoZSBtaXhlciB3b24ndCBkaXN0cmlidXRlLiBZb3UgY2FuJ3Qg cHV0IGluIHRoZSBTRFAsIHlvdSBkb24ndCBrbm93LCBpdCBzb3VyY2VzIGZyb20gc29tZXBsYWNl IGVsc2UuIE5vbiBtaXhlciBjYXNlIC0gaWYgeW91IGhhdmUgc3lzdGVtIHdpdGggMyBjYW1lcmFz IGFuZCB5b3Ugd2FudCB0byBzZW5kIDEgc3RyZWFtIGFuZCBpdCdzIHN3aXRjaGVkPyBXaGljaCBT U1JDIGRvIHlvdSBnZXQ/IFlvdSBjaGFuZ2UgU1NSQyB3aXRoIGVhY2ggc3dpdGNoLiBOZWVkIHRv IGRpc2N1c3MuIFRoaXMgdG9wb2xvZ3kgd2FzIGRlZmluZWQuIA0KDQpUZWQgLSBBQ1RJT046IHdy aXRlIHVwIHRoZSB0b3BvbG9neSBhbmQgc2VuZCB0byBsaXN0LiANCg0KTWFydGluIC0gVGhpcyBp cyBhd2Vzb21lIC0gSSdtIGJlaW5nIHNhcmNhc3RpYy4gQ29tbWVudCAyMiBwcm9iYWJseSBhcHBs aWVzLiBZb3UgZG9uJ3Qga25vdyB3aGF0IFNTUkMgeW91IHdpbGwgdXNlLiBIYXZpbmcgaW1wbGVt ZW50ZWQgdGhpcyAtIGl0J3MgZGlmZmljdWx0IHRvIGdldCByaWdodC4gTGVnYWN5IG1heSB3YW50 IHRvIHNlbmQgbW9yZSB0aGFuIG9uZSBzdHJlYW0uIA0KDQpKdXN0aW4gLSB0aGVyZSdzIGEgY2Fz ZSB3aXRoIGEgcHJlc2VudGF0aW9uIGFuZCBtdWx0aXBsZSBtbGluZXMuIEkgaGF2ZW4ndCBoZWFy ZCB0aGF0IHlvdSBuZWVkIHRvIGhhbmRsZSBsb3RzIG9mIG11bHRpcGxlIFNTUkNzLiANCg0KTWFy dGluIC0geW91J3ZlIGhlYXJkIGl0IG5vdy4gDQoNCkthcGxhbiAtIGZyb20gbGVnYWN5IGRldmlj ZXMgdGhhdCBkb24ndCBzdXBwb3J0IGl0LiBUaGV5IG5lZWQgbXVsdGlwbGUgbWxpbmVzLiBXaHkg cmVjcmVhdGUgdGhlIHdoZWVsPyBZb3UgYXJlIHJlY3JlYXRpbmcgU0RQLiBXZSdsbCBoYXZlIGJ1 bmRsZS4gDQoNCkp1c3RpbiAtIGlmIHRoZSBhbnN3ZXIgaGFzIG1vcmUgbWxpbmVzIHRoYW4gb2Zm ZXI/IGNsdWUgc2FpZCB0aGF0IHRoZXkgd2lsbCBtdWx0aXBsZXggbWxpbmVzLg0KDQoNCkVja2Vs IC0gMS41IHJ0dCBvciBzaW11bHRhbmVvdXMgb2ZmZXJzIC0gY291bGQgY3JlYXRlIGdsYXJlLg0K DQpKdXN0aW4gLSBub3Qgc2ltdWx0YW5lb3VzLCBiYWNrIHRvIGJhY2sgb3Igc2VyaWFsIFs/P10N Cg0KRWNrZWwgLSBUaGF0J3MgZmluZS4gVGhlIG1zaWQgWz8/XSBhbmQgeW91IGRvbid0IGtub3cg dGhlIHNzcmMgYW5kIHlvdSByZWNlaXZlIGl0IGFueXdheS4gTmVlZCB0byBiZWhhdmUgbmljZWx5 IGluIHRoYXQgY2FzZS4gSXQncyBnb2luZyB0byBoYXBwZW4uIA0KDQpKdXN0aW4gLSB0aGVyZSdz IGxlZ2FjeSB0aGF0IGRvZXNuJ3Qga25vdyBhbnl0aGluZyBhYm91dCB0aGlzLiBGb3IgbW9kZXJu IC0gYWRkaW5nIGNvbXBsZXhpdHkgdG8gZGVhbCB3aXRoIGl0LiANCg0KQ2hyaXN0ZXIgLSB5b3Ug aGF2ZSBhIGdhdGV3YXkgd2l0aCBsZWdhY3kgb24gdGhlIG90aGVyIHNpZGUuIFNob3VsZCBhdm9p ZCB0aGUgZ2F0ZXdheSBpbnNlcnRpbmcgWz8/XS4gSWYgeW91IGRvbid0IGdldCBTU1JDIGluIGFu c3dlciwgYXNzdW1lIHRoYXQgaXQgc3VwcG9ydHMgMSBzdHJlYW0uDQoNCkp1c3RpbiAtIHJlbW90 ZS1TU1JDIFs/P10gZG9uJ3Qgd2FudCB0byBhc3N1bWUuIA0KDQpDaHJpc3RlciAtIG9mZmVyL2Fu c3dlciBoYXMgdG8gYmUgdGhlIHNhbWUgbnVtYmVyIG1saW5lcy4gUkZDMzI2NCBbPz9dDQoNClBh dWwgLSBZb3UgYXJlIGJhY2tpbmcgaW50byB0aGUgd2hvbGUgQ0xVRSBwcm9ibGVtLiBXZSBzaG91 bGQgbWVyZ2UgdGhlIGdyb3Vwcywgd2hpY2ggSSBkb24ndCBzdWdnZXN0LiBZb3UgbmVlZCB0byBz dG9wLiBJZiB5b3UgcmF0IGhvbGUgYW5kIHdlIHdpbGwgaGF2ZSAyIHNvbHV0aW9ucy4NCg0KVGVk LCB0byBQYXVsIC0gd2Ugd2lsbCBoYW5kIHlvdSB0aGUgcmF0IGhvbGVzLg0KDQpQYXVsIC0gdGhl IG1zaWQgZ2l2ZXMgeW91IGEgbm90LW1lYW5pbmdmdWwgbmFtZS4gDQoNCkp1c3RpbiAtIHdlIGRv bid0IGhhdmUgc29tZXRoaW5nIHRoYXQgc2F5cywgdGhpcyBpcyBhIHNvdXJjZS4gTVNpZCBkb2Vz IHRoYXQuIA0KDQpSb25pIC0gSSBob3BlIHRoaXMgaXNuJ3QgYWxsIHRoZSBvZmZlci4gSXQgbWlz c2luZyBbPz9dIHlvdSBkb24ndCBrbm93IHdoYXQgdGhlIHN0cmVhbXMgYXJlLiAgQXMgYSByZWNl aXZlciwgSWYgSSB3YW50IHRvIGNob3NlLCBJIGRvbid0IGtub3cgd2hhdCB0aGV5IHJlcHJlc2Vu dC4NCg0KSnVzdGluIC0gbmVlZCB0byBmaWd1cmUgdGhhdCBvdXQuIA0KDQogICAgICAgICAgDQpD b25zdHJhaW50cyByZWdpc3RyeSBfX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAyMCBtaW4N CmRyYWZ0LWJ1cm5ldHQtcml0Y3dlYi1jb25zdHJhaW50cy1yZWdpc3RyeQ0Kc2xpZGVzOiBzbGlk ZXMtODUtcnRjd2ViLTQNClByZXNlbnRlcjogRGFuIEJ1cm5ldHQNCg0KRGlzY3Vzc2luZyBjaGFu Z2luZyBjb25zdHJhaW50cyBidXQgZG9uJ3QgaGF2ZSBhIG1lY2hhbmlzbSB5ZXQuDQoNClJlc2Nv cmxhIC0gcXVlc3Rpb24gb24gdGhlIGV4YW1wbGUuIDEuMzMzIGNhbid0IGJlIHNhdGlzZmllZC4N Cg0KRGFuIC0gSSBkb24ndCB3YW50IHRvIGRpc2N1c3Mgc3BlY2lmaWMgY29uc3RyYWludHMuIFRo ZSByZWdpc3RyeSBkcmFmdCBkb2Vzbid0IGRlZmluZSBtaW5Bc3BlY3QgcmF0aW8sIHRoZSBXM0Mg ZHJhZnQgZG9lcy4NCg0KQWRhbSAtIGFzIGEgdXNlciBpbiB0aGUgc2VhdCwgSSBoYXZlIG11bHRp cGxlIG1pY3JvcGhvbmVzLCBjYW4gd2UgYnVpbGQgdXAgdGhlIGNvbnN0cmFpbnRzIGZvciB0aGUg dXNlciB0byB1c2U/DQoNCkRhbiAtIHRoZSBicm93c2VyIG1heSBhc3Npc3QgdGhlIHVzZXIgd2l0 aCB3aGF0IHRoZXkgd2FudC4gSXQncyBhYm91dCB0aGUgYXBwIG5lZWRzLCBub3QgbmVjZXNzYXJp bHkgdGhlIHVzZXIuIFRoZSBicm93c2VyIHdpbGwgYXNrIGZvciBwZXJtaXNzaW9uIGFuZCBsZXQg dGhlIHVzZXIgc2VsZWN0IHRoZSBzb3VyY2UuIA0KDQpPcGVuIGRpc2N1c3Npb24NCg0KDQpLYXVm bWFuIC0gcHJvY2VzcyBwb2ludCAtIHdoeSBoYXMgdGhpcyBiZWVuIGJyb3VnaHQgdXA/IEl0J3Mg YSByZWdpc3RyeSBmb3IgQVBJIG5vdCBvbiB0aGUgd2lyZS4gVzNDIGNhbiBtYWtlIHRoZSByZXF1 ZXN0IHRvIElBTkEgZm9yIHRoZSByZWdpc3RyeS4gDQoNCkRhbiAtIEkgc3RhcnRlZCB3aXRoIHRo YXQuIENoYWlycyBmb3IgYm90aCBncm91cHMgcmVjb21tZW5kZWQgdGhhdCBJIGRvIHRoaXMgd29y ay4NCg0KQmVybmFyZCAoYXMgaW5kaXZpZHVhbCkgLSB0YWxrIHRvIElBTkEgcmVwcyBoZXJlLiBN eSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgeW91IGhhdmUgdG8gdGhpbmsgYWJvdXQgd2hhdCB2 YWx1ZSB0aGUgaWV0ZiBjYW4gYnJpbmcgdG8gdGhpcy4gSWYgc2F5IENMVUUgY291bGQgdXNlIGl0 LCB0aGVuIHdlIHNob3VsZCBkbyBpdC4NCg0KQUNUSU9OIFRlZCAtIENoYWlycyB0byB0YWxrIHRv IElBTkEgYW5kIFczQyBjaGFpcnMgdG8gZGlzY3Vzcy4NCg0KDQpTZXNzaW9uIDINCk1pbnV0ZSB0 YWtlczogIFJpY2hhcmQgQmFybmVzLCBQYXVsIEt5eml2YXQNCk1lZXRlY2hvIHJlY29yZGluZzog aHR0cDovL2lldGY4NS5jb25mLm1lZXRlY2hvLmNvbS9pbmRleC5waHAvUmVjb3JkZWRfU2Vzc2lv bnMjSUVURjg1X1JUQ1dFQl9TRVNTSU9OXzINCg0KDQotLSBDaGFpcnMgaW50cm8NCi0tIE5vdGUg V2VsbA0KLS0gQWdlbmRhIEJhc2g6IFNlcmdlIHByb3Bvc2VzIHRvIGJhc2ggdGhlIGFnZW5kYQ0K ICAgIC0tIEdvb2dsZSBjb21taXRzIHRvIGFkZHJlc3NpbmcgSVBSIGlzc3VlcyBhcm91bmQgVlA4 IGJ5IE9ybGFuZG8NCiAgICAtLSBHb29nbGUgYXNrcyB0byBwb3N0cG9uZSB0aGlzIGRlY2lzaW9u IHRvIE9ybGFuZG8NCiAgICAtLSBbU2VlIHBvc3Rpbmcgb24gUlRDV0VCIG1haWxpbmcgbGlzdF0N CiAgICAtLSBUZWQ6IEFueSBvdGhlciBhZ2VuZGEgYmFzaGVzIFtoZWFyaW5nIG5vbmVdDQogICAg LS0gLi4uIENoYWlycyB3b3VsZCBsaWtlIHRvIHByb2NlZWQgd2l0aCBzdGF0cyBwcmVzbywgdGhl biBtZWV0IHdpdGggQURzIGZvciBhIG1pbnV0ZQ0KICAgIC0tIEthdWZtYW5uOiBXaGVuIGFyZSB5 b3UgZ29pbmcgdG8gdGFrZSBpbnB1dCBmcm9tIHRoZSByb29tIG9uIHRoYXQgYWdlbmRhIGJhc2g/ DQogICAgLS0gVGVkOiBJZiB0aGUgQURzIGRvbid0IHdhbnQgdG8gYWxsb3cgaXQsIHdlJ2xsIHN0 cmlrZSBpdA0KICAgIC0tIEthdWZtYW5uOiBJIGJlbGlldmUgdGhhdCB0aGVyZSdzIG11Y2ggbW9y ZSBpbXBvcnRhbnQgd29yayBmb3IgdGhlIFdHIHRvIGFkZHJlc3MgdGhhbiB0aGUgY29kZWMgc2Vs ZWN0aW9uIGlzc3VlDQogICAgLS0gLi4uIEhvd2V2ZXIsIGdpdmVuIHRoYXQgdGhlIEdvb2dsZSBw cm9wb3NhbCBzdWZmZXJzIGZyb20gc2VyaW91cyBJUFIgaXNzdWVzLCBJJ2QgbGlrZSB0byBtYWtl IHRoZSBkZWNpc2lvbiBub3cNCiAgICAtLSBEYXZpZCBCZW5oYW0gKD8pOiBJJ20gY29uY2VybmVk IHRoYXQgdGhlIHByZXNzIGlzIGdvaW5nIHRvIHNheSAiSUVURiBjYW4ndCBtYWtlIHVwIGl0cyBt aW5kIiwgc28gd2UgbmVlZCBhIHJlYXNvbg0KICAgIC0tIC4uLiBXaGF0IGlzIGl0IHdlJ3JlIHdh aXRpbmcgZm9yPw0KICAgIC0tIFNlcmdlOiBDYW4ndCByZWFsbHkgc2F5IG11Y2ggbW9yZSB0aGFu IHdoYXQgd2FzIGluIHRoZSBlbWFpbA0KICAgIC0tIC4uLiBOZWVkIGEgbGl0dGxlIGJpdCBtb3Jl IHRpbWUgdG8gbWFrZSBhIGZ1bGwgYW5kIGNsZWFyIHN0YXRlbWVudA0KLS0gSGFyYWxkOiBTdGF0 cyBBUEkNCiAgICAtLSBUaGlzIGlzIGFuIElFVEYgaXNzdWUgYmVjYXVzZSBpdCB0b3VjaGVzIElB TkENCiAgICAtLSBbWyBQcmVzZW50YXRpb24gXV0NCiAgICAtLSBDb25jZXJuIHRoYXQgc3VmZmlj aWVudGx5IGRldGFpbGVkIHN0YXRzIGNvdWxkIHJhaXNlIHNlY3VyaXR5IGlzc3VlcywgZS5nLiwg ZW5hYmxlIHJlY29uc3RydWN0aW9uIG9mIGVuY3J5cHRlZCB2b2ljZQ0KICAgIC0tIEthdWZtYW5u OiBGZWVsIHRoZSBzYW1lIHdheSBhYm91dCB0aGlzIGFzIHRoZSBvdGhlciBvbmUNCiAgICAtLSBF a3I6IFRoaW5rIHRoaXMgaXMgZmluZSB3b3JrLCBidXQgd2Ugc2hvdWxkbid0IHNwbGl0IHRoaW5n cyBiZXR3ZWVuIFczQyBhbmQgSUVURiB3aXRob3V0IHJlYXNvbg0KICAgIC0tIC4uLiBOb3Qgc3Vy ZSB3aGF0IHdlJ3JlIGFjY2VwdGluZyBoZXJlOyBpcyB0aGlzIGEgY29tbWl0bWVudCB0byBwdXQg dGhpbmdzIGluIHRoZSByZWdpc3RyeT8NCiAgICAtLSBIYXJhbGQ6IExvb2tpbmcgZm9yIGNvbnNl bnN1cyBmcm9tIFJUQ1dFQiB0aGF0IHdlIGRvbid0IHdhbnQgdG8gYmxvY2sgaXQsIHRoZW4gd2Ug Y2FuIHRha2UgaXQgYmFjayB0byBXM0MNCiAgICAtLSBFa3I6IFdlIG5lZWQgYSByZWdpc3RyeSBm b3Igc3RhdHMsIGdvIGZvcndhcmQNCiAgICAtLSBSb21hc2NhbnU6IFJlbGF0ZWQgdG8gcmVnaXN0 cnk6IFBNT0wgbWlnaHQgYmUgcmVsZXZhbnQsIHlvdSBzaG91bGQgY2hlY2sgdGhhdCBvdXQNCiAg ICAtLSBIYXJhbGQ6IFBsZWFzZSBzZW5kIGEgcG9pbnRlcg0KICAgIC0tIFJvbWFzY2FudTogVGhl IHJlY29tbWVuZGF0aW9uIGxhc3Qgd2VlayBpbiBMeW9uIGFib3V0IHJlbW92aW5nIHRoZSByZW1v dGUgcGFydCBkZXNlcnZlcyBzb21lIGRpc2N1c3Npb24NCiAgICAtLSAuLi4gQ291bGQgeW91IHJl Y2FwIHdoeSB0aGF0IHNlZW1lZCBnb29kLCBhbmQgaG93IHlvdSB3ZXJlIGNvbnZpbmNlZCBvdGhl cndpc2U/DQogICAgLS0gSGFyYWxkOiBUaGUgbW9zdCBpbXBvcnRhbnQgdGhpbmcgdG8gdGFsayBh Ym91dCBhcmUgdGhlc2UgZmxvd3MsIGFuZCB0aGV5IGhhdmUgdHdvIGVuZHMNCiAgICAtLSAuLi4g SSB3YXMgY29udmluY2VkIGJ5IE1hdHRoZXcgdGhhdCB3ZSBjb3VsZCBoYXZlIHR3byBvYmplY3Rz IHRoYXQgcG9pbnQgdG8gZWFjaCBvdGhlcjsgc2FtZSB0aGluZyB3aXRoIHNpbXBsZXIgbW9kZWwN CiAgICAtLSBSb21hc2NhbnU6IFRoYXQncyB0cnVlIGFib3V0IFJUUCBjb25uZWN0aW9ucywgYW5k IHJlbW90ZSBwYXJ0cyBvZiBhdHRyaWJ1dGVzIGFyZSBtb3JlIG5hdHVyYWwgdGhlcmUNCiAgICAt LSBIYXJhbGQ6IFdlIGhhdmUgdG8gbWVhc3VyZSBvdGhlciB0aGluZ3MgdGhhbiBSVFAsIGUuZy4s IElDRQ0KICAgIC0tIEthdWZtYW5uOiBUaGlzIGlzIGFuIEFQSSBpc3N1ZSwgc2hvdWxkIGJlIHJl c29sdmVkIGluIFczQw0KICAgIC0tIE8nQ2FsbGFoYW4gKE1veik6IFdlIGhhdmUgYSBsb3Qgb2Yg ZXhwZXJpZW5jZSB3aXRoIHRoZXNlIHNvcnRzIG9mIEFQSXM7IGJldHRlciB0byBoYXZlIHR5cGVk IERPTSBvYmplY3RzDQogICAgLS0gLi4uIE1pZ2h0IHdhbnQgdG8gY29uc2lkZXIgcmUtY2FzdGlu ZyB0aGlzIHRvIHVzZSB0aGF0IGRlc2lnbiBwYXR0ZXJuDQogICAgLS0gRWtyOiBVc2luZyB0aGlz IGZvciBlcnJvciByZWNvdmVyeSBtaWdodCBpbXBvc2UgYSBncmVhdGVyIGJ1cmRlbiBvbiB0aGlz IEFQSSB0aGFuIGp1c3QgZGlhZ25vc3RpYy9mb3JlbnNpYw0KICAgIC0tIEJlcm5hcmQ6IE1heWJl IHdlIGNvdWxkIG1lZXQgd2l0aCBJQU5BIHRvIGF2b2lkIHRoZSBuZWVkIHRvIHBhc3MgdGhpbmdz IGxpa2UgdGhpcyB0aHJvdWdoIHRoZSBJRVRGIGluIHRoZSBmdXR1cmUNCiAgICAtLSBIYXJhbGQ6 IFRoZXJlIHdpbGwgYmUgbG90cyBvZiBzdGF0cyB0aGF0IHBlb3BsZSB3YW50IHRvIGFkZC4uLg0K LS0gQ3VsbGVuOiBJbiBhIHNlY29uZCwgd2UncmUgZ29pbmcgdG8gdGFrZSBhIGNvbnNlbnN1cyBj YWxsIG9uIHdoZXRoZXIgcGVvcGxlDQogICAgLS0gQSBjb3VwbGUgb2YgcG9pbnRzIGNhbWUgdXAg aW4gY2hhaXJzJyBkaXNjdXNzaW9uIHdpdGggdGhlIEFEcw0KICAgIC0tIDEuIFBlb3BsZSBjYW1l IGhlcmUgdG8gZG8gdGhpcw0KICAgIC0tIDIuIFBlb3BsZSBhcmUgc3VnZ2VzdGluZyB0aGF0IHdl J3JlIGdvaW5nIHRvIGhhdmUgbmV3IGluZm9ybWF0aW9uIG9uIGFuIGltcG9ydGFudCB0b3BpYw0K ICAgIC0tIDMuIE1vcmUgdGhhbiBvbmUgcGVyc29uIGhhcyBtYWRlIGNvbW1lbnRzIHRoYXQgd2Ug aGF2ZSBtb3JlIGltcG9ydGFudCB0aGluZyB0byBkbw0KICAgIC0tIE9wZW5pbmcgbWljcyBmb3Ig Y29tbWVudHMgb24gYWdlbmRhIGJhc2gNCiAgICAtLSBXZW5nZXI6IFdoYXQgaXMgcmVxdWVzdGVk IGluIHRoaXMgZW1haWwgaXMgdG8gcG9zdHBvbmUgdGhlIGRlY2lzaW9uLCBub3QgdGhlIGRpc2N1 c3Npb247IGFsc28gcG9zdHBvbmluZyB0aGUgZGlzY3Vzc2lvbj8NCiAgICAtLSBDdWxsZW46IFll cywgYWxzbyBwb3N0cG9uaW5nIGRpc2N1c3Npb24NCiAgICAtLSBCZXJuYXJkOiBJZiBTZXJnZSdz IGNvbmNlcm4gaXMgdGhhdCB0aGUgSUVURiB3aWxsIGNvbWUgdG8gYmxpbmRpbmcgY29uc2Vuc3Vz IG9uIHRoaXMsIEkgY2FuIGFsbGF5IHlvdXIgZmVhcnMNCiAgICAtLSBDdWxsZW46IFJvYmVydCB3 aWxsIGp1ZGdlIHRoZSBjb25zZW5zdXMNCiAgICAtLSBNaWNoYWVsID8/PyAoQ2lzY28pOiBTb21l IG9mIHRoZSB0b3BpY3MgdGhhdCB5b3UncmUgZGVjaWRpbmcgb24gaGF2ZSBwcmVzZW50YXRpb25z IGFscmVhZHkgcG9zdGVkOyBjb250cmlidXRpb24gaGFzIGFscmVhZHkgYmVlbiBtYWRlDQogICAg LS0gLi4uIElzIHRoZSBkZWNpc2lvbiBvbiBkZWJhdGluZyBpdCBtb290Pw0KICAgIC0tIEN1bGxl bjogU3VyZSwgZHJhZnRzIGhhdmUgYmVlbiB3cml0dGVuLCBldGMuICBRdWVzdGlvbiBpcyBqdXN0 IGFib3V0IG1lZXRpbmcgdGltZS4NCiAgICAtLSBIVU06IEluIGZhdm9yIG9mIHRoZSBiYXNoPyAg W2xvdWRdDQogICAgLS0gSFVNOiBPcHBvc2VkPyAgW25vbmUgaW4gcm9vbSwgb25lIGluIGphYmJl cl0NCiAgICAtLSBSb2JlcnQ6IENsZWFyIGNvbnNlbnN1cw0KICAgIC0tIEVrcjogTWljcm8tYmFz aCBpbiBhZGRpdGlvbjsgY291bGQgd2UgZ28gYmFjayB0byB0aGUgTVNJRCBzbGlkZXM/DQotLSBK dXN0aW46IEpTRVAgVXBkYXRlIChUaGUgU2VxdWVsKQ0KICAgIC0tIFtbIHByZXNlbnRhdGlvbiB+ IE1lZGlhIHN0cmVhbSB0YXhvbm9teSBdXQ0KICAgIC0tIEpvbmF0aGFuIExlbm5veCBpcyB3cml0 aW5nIGEgLTAwIGRyYWZ0IG9uIHRlcm1pbm9sb2d5IGZvciBtZWRpYSBzdHJlYW1zDQogICAgLS0g VGVkOiBJcyBpdCBpbXBsaWNpdCB0aGF0IHRoaXMgaGllcmFyY2h5IFtvZiBtZWRpYSBzdHJlYW1z XSBpc24ndCBhbGwgcHJlc2VudCBpbiBhIGdpdmVuIGlzbnRhbmNlPw0KICAgIC0tIEp1c3Rpbjog WW91IG1heSBoYXZlIHNpdHVhdGlvbnMgd2hlcmUgdGhlcmUgbGV2ZWxzIGNvbGxhcHNlDQogICAg LS0gVGVkOiBJbXBvcnRhbnQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlbGF0aW9uc2hpcCBhbGxv d3MgZm9yIHRoZXNlIHVuaXRpZXMgLyBnYXBzDQogICAgLS0gRHJhZ2U6IEFzIEFWVEVYVCBjaGFp ciwgd2FudGVkIHRvIHB1dCBzb21lIGNvbnRleHQgYXJvdW5kIHRoaXMgZHJhZnQNCiAgICAtLSAu Li4gVmVyeSBwcm92aXNpb25hbCBmb3Igbm93LCBuZWVkIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGFi b3V0IHdoYXQgZ3JvdXAgdGhpcyBnb2VzIGluDQogICAgLS0gVGVkOiBTdWdnZXN0IGRvaW5nIHRo aXMgYXMganVzdCBkcmFmdC1sZW5ub3gtKiAuLi4/DQogICAgLS0gTGVubm94OiBPciBkcmFmdC1s ZW5ub3gtcmFpLSogLi4uDQogICAgLS0gUm9uaTogU2hvd3Mgd2Ugc3RpbGwgaGF2ZSBhIHByb2Js ZW0gdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVyZW50IHRlcm1pbm9sb2dpZXMNCiAgICAtLSBKdXN0 aW46IFRoYXQncyB3aHkgSSB3YW50ZWQgdG8gd3JpdGUgdGhpcyBkb3duDQogICAgLS0gS2V2aW4g R3Jvc3M6IEFjdHVhbGx5IHR3byBtb3JlIGxldmVscyBvZiBoaWVyYXJjaHkgYWJvdmUgdGhpczog Q2xvY2sgc291cmNlIGFuZCBpbnRlci1kZXN0aW5hdGlvbiBzeW5jaHJvbml6YXRpb24gKElETVMp DQogICAgLS0gSGFyYWxkOiBOZWVkIHRvIGJlIGNvbnNjaW91cyBvZiB0aGUgYm9yZGVycyB3ZSdy ZSBkcmF3aW5nDQogICAgLS0gLi4uIElmIEknbSBhbiBSVENXRUIgYXBwbGljYXRpb24gYW5kIEkg Z2V0IGEgYnl0ZSBzdHJlYW0gZnJvbSBzb21lYm9keSBlbHNlDQogICAgLS0gLi4uIFRoZW4gSSBt aWdodCBoYXZlIHRvIG1hcmsgdGhlIHN0cmVhbSB3aXRoIGEgZGlmZmVyZW50IENOQU1FDQogICAg LS0gLi4uIEZpbmUgd2l0aCB0aGF0LCBqdXN0IHdhbnQgdG8gbWFrZSBpdCBjb21wbGV0ZWx5IGV4 cGxpY2l0DQogICAgLS0gSnVzdGluOiBJZiB5b3UncmUgc2F5aW5nIHlvdSd2ZSBnb3QgdHdvIHN0 cmVhbXMgeW91IHdhbnQgdG8gY29tcG9zaXRlLCB5b3Ugd291bGQgcmUtd3JpdGUgdGhlIENOQU1F cz8NCiAgICAtLSAuLi4gVGhpbmsgbG9jYWwgcHJvY2Vzc2luZyBpcyAicG9zdC1DTkFNRSIgbGF5 ZXINCiAgICAtLSBIYXJhbGQ6IElmIHdlIGFncmVlIHRoYXQgYSBtZWRpYSBzdHJlYW0gaXMgb25s eSBzZW50IG91dCB3aXRoIGEgc2luZ2xlIENOQU1FLCB0aGF0J3MgZmluZSwgd2UganVzdCBuZWVk IHRvIGNsYXJpZnkNCiAgICAtLSBMZW5ub3g6IEp1c3Qgd2FudGVkIHRvIGNsYXJpZnkgdGhhdCB3 aGlsZSBJJ20gZWRpdG9yLCBhbGwgdGhlIG90aGVyIHZvbHVudGVlcnMgYXJlbid0IG9mZiB0aGUg aG9vaw0KICAgIC0tIC4uLiBUaGVyZSBhcmUgdGhpbmdzIHRoYXQgYXJlIHdyb25nIG9uIHRoaXMg c2xpZGUsIGJ1dCBpdCdzIGdvb2QgdG8gaGF2ZSBhIHNsaWRlDQogICAgLS0gLi4uIEl0IG1pZ2h0 IGJlIGEgbW9yZSBjb21wbGljYXRlZCBncmFwaCB0aGFuIGp1c3QgYSBoaWVyYXJjaHkNCiAgICAt LSAuLi4gWW91IG1pZ2h0IGRpdmlkZSB0aGluZ3MgYmV0d2VlbiB0aGUgbGV2ZWwgYXQgd2hpY2gg UlRDV0VCIG5lZWRzIHRvIGNhcmUgYW5kIGxvd2VyLWxheWVyIHRoaW5ncw0KICAgIC0tIEVrcjog SGlnaGVyLWxldmVsIHF1ZXN0aW9uLiAgSXMgaXQgcmVxdWlyZWQgdGhhdCB0aGUgYXJyYW5nZW1l bnQgb2YgSlMgb2JqZWN0IG9uIHNpZGUgQSBtYXRjaGVzIHRoZSBhcnJhbmdlbWVudCBvZiBKUyBv YmplY3RzIG9uIHNpZGUgQj8NCiAgICAtLSBKdXN0aW46IFNob3VsZCBiZTsgd2h5IHNob3VsZCB3 ZSBkbyBhbnl0aGluZyBkaWZmZXJlbnQ/DQogICAgLS0gQ3VsbGVuOiBXZSBuZWVkIHRvIGhhdmUg YSB3YXkgdG8gY29ycmVsYXRlIGEgdHJhY2sgb24gb25lIHNpZGUgd2l0aCBhIHRyYWNrIG9uIHRo ZSBvdGhlciBzaWRlDQogICAgLS0gLi4uIFRoZW4gdGhlIHF1ZXN0aW9uIGFyaXNlcyBvZiB3aGV0 aGVyIHlvdSBuZWVkIGFsbCB0aGUgb3RoZXIgbGV2ZWxzDQogICAgLS0gLi4uIEl0IHdvdWxkIGJl IHZlcnkgZmVhc2libGUgdG8gY2xhaW0gdGhlIG9ubHkgdGhpbmcgeW91IG5lZWQgaXMgdG8gbWFw IHRoZSBhY3R1YWwgUlRQIGNvbnN0cnVjdHMgdG8gYW4gaWRlbnRpZmllcg0KICAgIC0tIC4uLiBU aGVuIGFwcGxpY2F0aW9ucyBjb3VsZCBwdXQgdGhvc2UgdGhpbmdzIHRvZ2V0aGVyDQogICAgLS0g SnVzdGluOiBIZWFyIHlvdSBzYXlpbmcgdGhhdCB5b3UgbmVlZCB0byBzZW5kIGEgYnVuY2ggb2Yg bWV0YSBpbmZvcm1hdG9uIHRoYXQgdGhlIGFwcCB1c2VzIHRvIHBhdGNoIHRvZ2V0aGVyIHRoZSBt ZWRpYQ0KICAgIC0tIC4uLiBEb24ndCBoZWFyIHlvdSBzYXlpbmcgd2h5IHRoZSBhcnJhbmdlbWVu dCBzaG91bGQgYmUgZGlmZmVyZW50DQogICAgLS0gQ3VsbGVuOiBNaWdodCBoYXZlIGEgdmVyeSBn ZW5lcmljIHZpZGVvIGNvbmZlcmVuY2luZyBicmlkZ2UgdGhhdCdzIGp1c3QgbWl4aW5nIHZpZGVv IHN0cmVhbXMNCiAgICAtLSAuLi4gRW5kcG9pbnRzIG1pZ2h0IHVuZGVyc3RhbmQgdGhlIGRpZmZl cmVudCBncm91cGluZ3MgaW4gbW9yZSBkZXRhaWwNCiAgICAtLSAuLi4gTm90IG9idmlvdXMgdGhh dCB3ZSBoYWQgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBncm91cGluZyBzdHJ1Y3R1cmVzIGJlIHBl cnNlcnZlZA0KICAgIC0tIC4uLiBSYXRoZXIgdGhhdCB0aGUgaXRlbXMgaW4gdGhlIGdyb3VwaW5n cyBoYWQgdG8gYmUgbmFtZWQgc28geW91IGNvdWxkIHBvaW50IHRvIHRoZW0NCiAgICAtLSBFa3I6 IElmIEkgaGFkIGEgQ05BTUUgd2l0aCAyIG1lZGlhIHN0cmVhbXMsIHdvdWxkIHRoYXQgYmUgT0s/ DQogICAgLS0gSnVzdGluOiBZZXMsIGJ1dCBBUEkgaXMgbm90IHlldCBkZWZpbmVkDQogICAgLS0g U3BlbmNlcjogVGhhbmsgeW91IGZvciB0aGUgd29yayB0cnlpbmcgdG8gdW5pZnkgdGhlc2UgY29u Y2VwdHMNCiAgICAtLSAuLi4gQXJlIHRoZXJlIGFwcGxpY2F0aW9ucyBiZXNpZGVzIENMVUUgdGhh dCB5b3UgZ3V5cyB3ZXJlIHBsYW5uaW5nIG9uIHJlYWNoaW5nIG91dCB0bz8NCiAgICAtLSBKdXN0 aW46IE1haW5seSBqdXN0IHRyeWluZyB0byB3cml0ZSBhIGdsb3NzYXJ5DQogICAgLS0gS2F1Zm1h bm46IENvbW1lbnQgMjIgYXBwbGllcyBoZXJlIChDb21tZW50IDIyID09ICJNaWNyb3NvZnQganVz dCBtYWRlIGEgcHJvcG9zYWwgdGhhdCBkb2Vzbid0IGhhdmUgdGhpcyBwcm9ibGVtIikNCiAgICAt LSAuLi4gQWdyZWUgd2l0aCBDdWxsZW4gdGhhdCB3ZSBkb24ndCBuZWNlc3NhcmlseSBoYXZlIHRv IG1hcCB0aGVzZSB0aGluZ3MNCiAgICAtLSAuLi4gSWYgeW91IGRvbid0LCB0aGVuIHRoZSBlbmQt dG8tZW5kIGNvbnN0cmFpbnRzIHN0dWZmIG1pZ2h0IG5vdCB3b3JrIGNvbXBsZXRlbHkNCiAgICAt LSAuLi4gWW91J3JlIGFkZGluZyBzb21lIHN0dWZmIHRvIFNEUCB0byBkbyB0aGUgbWFwcGluZywg aXMgaXQgbWFuZGF0b3J5Pw0KICAgIC0tIEp1c3RpbjogTmVlZCB0byBiZSBsaWJlcmFsIGluIHdo YXQgeW91IGFjY2VwdA0KICAgIC0tIEthdWZtYW5uOiBDb25jZXJuZWQgdGhhdCB0aGUgcmVxdWly ZW1lbnRzIGFyZSBnb2luZyB0byBncm93LCBtYWtlIHRoZSBTRFAgbGVzcyBjb21wYXRpYmxlDQog ICAgLS0gTGVubm94OiBUaGUgTWVkaWFTdHJlYW1UcmFjayBpcyB0aGUgbG93ZXN0IGxldmVsIGF0 IHdoaWNoIEphdmFTY3JpcHQgaXMgbGlrZWx5IHRvIGhhbmRsZSB0aGluZ3MNCiAgICAtLSAuLi4g UXVlc3Rpb24gb2Ygc3RydWN0dXJlIGFib3ZlIHRoYXQgbGV2ZWwgaXMgbW9zdGx5IGFuIEFQSSBx dWVzdGlvbg0KICAgIC0tIC4uLiBFdmVyeXRoaW5nIGJlbG93IE1lZGlhU3RyZWFtVHJhY2sgc29y dCBvZiBjb2xsYXBzZXMNCiAgICAtLSBCZXJuYXJkOiBBcmUgeW91IHBsYW5uaW5nIHRvIGRlYWwg d2l0aCBsYXllciBjb2RpbmcgYXMgd2VsbA0KICAgIC0tIExlbm5veDogWWVzDQogICAgLS0gUm9u aTogV2UgaGF2ZSB0d28gaXNzdWVzOiAoMSkgSG93IHRvIGNvbWJpbmUgbXVsdGlwbGUgU1NSQ3Ms IGFuZA0KICAgIC0tIC4uLiAoMikgUmVsYXRpb25zaGlwIGF0IGEgaGlnaGVyIGxheWVyIGJldHdl ZW4gZGlmZmVyZW50IHR5cGVzIG9mIHN0cmVhbXMNCiAgICAtLSBIYXJhbGQ6IE1pbmltdW0gdGhp bmcgdGhhdCBTRFAgbmVlZHMgdG8gZG8gZm9yIFdlYlJUQyBpcyBwcm92aWRlIGEgaGFuZGxlIGZv ciB0aGUgTWVkaWFTdHJlYW1UcmFjaw0KICAgIC0tIC4uLiBUaGUgbmljZSB0aGluZyBhYm91dCBT RFAgaXMgdGhhdCBpdCdzIHRoaXMgY29udGludW91cyBmbG9vZCBvZiBleHRlbnNpb25zDQogICAg LS0gLi4uIFdlIG5lZWQgdG8gYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB3aXRoIGFwcGxpY2F0aW9u cyB0aGF0IGRvbid0IGhhdmUgYW5vdGhlciBjaGFubmVsDQogICAgLS0gLi4uIElmIGFsbCBhcHBs aWNhdGlvbnMgaGF2ZSBhIGJhY2stY2hhbm5lbCB3aGVyZSB0aGV5IGNhbiBzYXkgd2hpY2ggdHJh Y2tzIGJlbG9uZyBvbiB3aGljaCBzdHJlYW1zLCB3ZSBkb24ndCBuZWVkIGl0IGluIFNEUA0KICAg IC0tIFRob21zb246IENvbmNlcm5lZCB0aGF0IHRoZXJlJ3MgYW4gaW1wbGljaXQgYXNzdW1wdGlv biB0aGF0IHNpZ25hbGluZyB3aWxsIG9jY3VyIHByaW9yIHRvIHBsYXliYWNrDQogICAgLS0gLi4u IFRoZXJlIGFyZSBzaXR1YXRpb25zIHdoZXJlIHRoZSBzaWduYWxpbmcgc2hvd3MgdXAgYWZ0ZXIg dGhlIG1lZGlhDQogICAgLS0gLi4uIEhhdmUgd2UgbWFkZSB0aGUgZGVjaXNpb24gdG8gcmVxdWly ZSBleHBsaWNpdCBzaWduYWxpbmcgb2YgU1NSQ3M/DQogICAgLS0gSnVzdGluOiBJZiB3ZSBoYXZl IGEgc2luZ2xlIE0tbGluZSB3aXRoIG11bHRpcGxlIHZpZGVvcyBpbiBpdCwgdGhlbiB3ZSBuZWVk IGEgc2luZ2xlIFNTUkMgZm9yIGl0DQogICAgLS0gS3l6aXZhdDogVGhpcyBzZWVtcyBtb3JlIGFi b3V0IGNvbmNlcHRzIHRoYW4gY29kaW5nOyBzdWNoIGEgbWlzaC1tYXNoIG9mIHRlcm1pbm9sb2d5 IHRoYXQgd2UgY2FuJ3QgdGFsayB0byBlYWNoIG90aGVyDQogICAgLS0gLi4uIE5vdCBzdXJlIHRo YXQgYSBsb3Qgb2YgdGhpcyBzaG93cyB1cCBpbiBzaWduYWxpbmcNCiAgICAtLSBKdXN0aW46IFdl IGNhbiBkZWNpZGUgd2hhdCB0byBzaWduYWwgb25jZSB3ZSBhZ3JlZSBvbiB0aGUgZGF0YSBtb2Rl bA0KICAgIC0tIFtbIHByZXNlbnRhdGlvbiB+IG1hcHBpbmcgdG8gbS1saW5lcyBdXQ0KICAgIC0t IEthdWZtYW5uOiBNeSBwcm9ibGVtIHdpdGggdGhpcyB3aG9sZSBNU0lEIHRoaW5nIGlzIHRoYXQg aWYgSSBvZmZlciB0aHJlZSBtLWxpbmVzIGFuZCB5b3Ugd2FudCB0byByZXNwb25kIHdpdGggNSBt LWxpbmVzLCB5b3UgY2FuJ3QNCiAgICAtLSAuLi4gQnV0IGlmIHRoZSBzYW1lIGlzbid0IHRydWUg d2l0aCBNU0lEcy4gIFNlZW1zIGxpa2UgYSB3b3JrLWFyb3VuZC4NCg0KDQpEaXNjdXNzaW9uIG9m IGJ1bmRsZS4NCg0KDQpKdXN0aW46IG9mZmVyaW5nIGFuZCBhbnN3ZXJpbmcgZGlmZmVyZW50IG51 bWJlcnMgb2Ygc291cmNlcyB3aXRoaW4gbS1saW5lIGlzIG5vIHByb2JsZW0uDQoNCg0KQ2hyaXN0 ZXIgSG9sbWJlcmc6IHdoYXQgYWJvdXQgbGVnYWN5IHRoaW5ncyB0aGF0IGRvbuKAmXQgZG8gdGhp cyBzaWduYWxpbmcg4oCTIGp1c3Qgb2ZmZXIgMTAgbS1saW5lcz8NCg0KDQpKdXN0aW46IChleHBs YWlucyBhIGxlZ2FjeSB1c2UgY2FzZS4pDQoNCg0KICAgIC0tIEhhZHJpZWw6IFRoZSBwcm9ibGVt IHdpdGggdGhpcyBzbGlkZSBpcyB0aGF0IHRoZSBkZWZhdWx0IGlzICp3cm9uZyosIHRoZSBkZWZh dWx0IHNob3VsZCBiZSB3aGF0IFNEUCBkb2VzDQogICAgLS0gSnVzdGluOiBRdWVzdGlvbiBhYm91 dCB3aGF0IHlvdSB3YW50IHRvIGRvIGZvciB0aGUgZnV0dXJlDQogICAgLS0gSGFkcmllbDogVGhl IHJlYXNvbiB5b3Ugd2FudCBtdWx0aXBsZSBtLWxpbmVzIGlzIHRoYXQgdGhlaXIgcHJvcGVydGll cyBhcmUgZ29pbmcgdG8gY2hhbmdlIGZvciBwcm9wZXJ0aWVzIG90aGVyIHRoYW4gVHJhY2sgSUQN CiAgICAtLSBKdXN0aW46IE5vdCBhbGwgYXBwbGljYXRpb25zIGhhdmUgdG8gZGVhbCB3aXRoIHRo YXQsIGNhbiBzaWduYWwgdGhpbmdzIGxpa2UgcmVzb2x1dGlvbiBpbi1iYW5kLCBpbiB0aGUgY29k ZWMNCiAgICAtLSBIYWRyaWVsOiBUaGlzIGNhbiBjYXVzZSBwcm9ibGVtcyB3aXRoIGNvbW11bmlj YXRpbmcgd2l0aCB0aGUgUFNUTiB3b3JsZA0KICAgIC0tIEhhcmFsZDogWyBtaXNzZWQgXQ0KICAg IC0tIFJvYWNoOiBXaGlsZSBub2JvZHkgaGVyZSBoYXMgYSBncmVhdCBsb3ZlIGZvciBTRFAsIHdl IGNob3NlIGl0IGJlY2F1c2UgeW91IGdldCBzb21lIHRoaW5ncyB3aXRoIGl0LCBlLmcuLCBvZmZl ci9hbnN3ZXINCiAgICAtLSAuLi4gVGhpcyBwcm9wb3NhbCB0aHJvd3MgdGhhdCBvdXQsIHNvIHlv dSdsbCBwcm9iYWJseSByZS1kaXNjb3ZlciB0aGUgcHJvYmxlbXMgdGhhdCBvZmZlci9hbnN3ZXIg c29sdmVkDQogICAgLS0gSnVzdGluOiBTRFAgaGFzIHNvbWUgYXNzdW1wdGlvbnMgYmFzZWQgb24g dGhlIHRlY2hub2xvZ3kgb2YgdGhlIHRpbWUuICBUaGUgd29yayBpbiBDTFVFIGlzIGluIHRoaXMg ZGlyZWN0aW9uLg0KICAgIC0tIEVrcjogTGV0IG1lIHRyeSB0byByZWNhcCB3aGF0IHRoZSBwcm9w b3NlZCBiZW5lZml0cw0KICAgIC0tIC4uLiBBbnN3ZXIgY2FuIHJlc3BvbmQgd2l0aCBtb3JlIHRy YWNrcyB0aGFuIHRoZSBvZmZlcjsgb2ZmZXIgYWxzbyBkb2Vzbid0IGhhdmUgdG8gcHJlLWFsbG9j YXRlIHBvcnRzDQogICAgLS0gSnVzdGluOiBBbHNvLCB0aGUgc291cmNlcyB5b3VyIG9mZmVyaW5n IGRvbid0IGhhdmUgdG8gYWZmZWN0IHRoZSBvdGhlciBzaWRlDQogICAgLS0gRWtyOiBEbyBhbnkg Y3VycmVudCBhcHBsaWNhdGlvbnMgZG8gYW55dGhpbmcgc2Vuc2libGUgd2l0aCB0aGlzIHNvcnQg b2YgdGhpbmc/Pw0KICAgIC0tIC4uLiBUaGUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gb2ZmZXIg YnVuZGxlIGFuZCB1c2UgdGhhdCBmb3IgY2FwYWJpbGl0eSBkaXNjb3ZlcnkNCiAgICAtLSBSaWNo YXJkIEVqemFrOiArMSB0byBIYWRyaWVsLCBBZGFtLiAgVGhpcyBpcyBhbHNvIGFuIGlzc3VlIGlu IENMVUUuDQogICAgLS0gSnVzdGluOiBUaGlzIGRpcmVjdGlvbiBjYW1lIGZyb20gdGhlIENMVUUg ZGlzY3Vzc2lvbiBhdCB0aGUgcHJldmlvdXMgSUVURi4NCiAgICAtLSBDdWxsZW46IExldCdzIGJh Y2sgdXAgYW5kIHRyeSB0byBmb2N1cyBvbiB3aGF0IHRoZSBiZW5lZml0cyBvZiB0aGUgcmVzcGVj dGl2ZSBhcHByb2FjaGVzIGFyZQ0KICAgIC0tIE1hZ251czogVGhpbmsgdGhpcyBtaWdodCBtaXgg dXAgZGlmZmVyZW50IHVzZSBjYXNlczsgc3RyZWFtIHNlbGVjdGlvbiB2cy4gdHJhbnNwb3J0IHNl bGVjdGlvbg0KICAgIC0tIFJvbmk6IFRoaW5rIGluIENMVUUgd2UgZ290IHRvIGF0IGxlYXN0IDIg ZGlmZmVyZW50IHNlbGVjdGlvbnMNCiAgICAtLSBIYWRyaWVsOiBbIG1pc3NlZCBdDQogICAgLS0g Q2hhcmxlcyBFY2tlbDogQ29uY2VybiBhYm91dCB3aGV0aGVyIHlvdSBuZWVkIHRvIGtub3cgYW5k IHNpZ25hbCBTU1JDIHZhbHVlcyBhaGVhZCBvZiB0aW1lDQogICAgLS0gLi4uIElmIHlvdSBuZWVk IHNpZ25hbGluZyB0byBhcnJpdmUgYmVmb3JlIG1lZGlhLCB0aGVuIHRoYXQgY291bGQgYmUgYSBw cm9ibGVtDQogICAgLS0gVGVkOiBUaGVzZSBzbGlkZXMgaGF2ZSBiZWVuIHVwbG9hZGVkIHRvIHRo ZSBtZWV0aW5nIG1hdGVyaWFscyBzaXRlLCBhbHNvIHNvbWUgc2xpZGVzIGZyb20gUmFuZGFsbCBK ZXNzdXANCiAgICAtLSBbWyBwcmVzZW50YXRpb24gfiB0cmlja2xlIElDRSBdXQ0KICAgIC0tIFtb IHByZXNlbnRhdGlvbiB+IHJlaHlkcmF0aW9uIF1dDQoNCg0KICAgIC0tIFtbIC4uLiBzY3JpYmUg c3RlcHBlZCBvdXQgZm9yIGEgbW9tZW50IC4uLiBdXQ0KDQoNCiAgICAtLSBFa3I6IFdoYXQgc3Rh dGUgZG9lcyB0aGlzIHB1dCB0aGUgUGVlckNvbm5lY3Rpb24gaW4uICBJdCdzIG5vdCB0aGUgb3Jk aW5hcnkgT2ZmZXIgc3RhdGUNCiAgICAtLSBKdXN0aW46IFdhcyB0aGlua2luZyBpdCB3b3VsZCBi ZSBzb21ldGhpbmcgbGlrZSBTZW50T2ZmZXIsIGFuZCB5b3UgY291bGQgbXVuZ2UgdGhlIFNEUA0K ICAgIC0tIEVrcjogU28gaXQgd291bGQgYmUgYXMgaWYgSSBjYWxsZWQgc2V0TG9jYWwoKSB3aXRo IHRoZSByaWdodCBwYXNzd29yZC4gIFRha2luZyBvZmZsaW5lLCBidXQgdGhpcyBuZWVkcyB0byBi ZSB3b3JrZWQgb3V0DQogICAgLS0gVGhvbXNvbjogUHJldHR5IHN1cmUgd2UgY291bGQgd29yayBv dXQgc29tZXRoaW5nIHdpdGhvdXQgdGhpcyB0aGF0IHdvdWxkIGhhdmUgcHJldHR5IG11Y2ggdGhl IHNhbWUgdXNlciBleHBlcmllbmNlIHdpdGggbm8gQVBJIHNlcnZpY2UNCiAgICAtLSBUZWQ6IElz IHRoYXQgQ29tbWVudCAyMiBvciBhbiBvZmZlciB0byB3cml0ZSBhIGRyYWZ0Pw0KICAgIC0tIEN1 bGxlbjogQ291bGQgeW91IHdyaXRlIGFuIGVtYWlsIHRvIHRoZSBsaXN0IGV4cGxhaW5pbmcgaG93 PyBbWWVzXQ0KICAgIC0tIEthdWZtYW5uOiBXaG8gY2FsbHMgdGhpcz8gIFRoZSBzaWRlIHRoYXQg bGFzdCBjcmVhdGVkIGFuIG9mZmVyPyAgYW5zd2VyPyBbZWl0aGVyXQ0KICAgIC0tIC4uLiBTbyB3 aGF0IGhhcHBlbnMgd2hlbiB3ZSBib3RoIGRvIHRoaXMgYXQgdGhlIHNhbWUgdGltZT8gW25vdCB3 ZWxsIGRlZmluZWRdDQogICAgLS0gUmFuZGFsbCBKZXNzdXA6IFNlZW1zIGxpa2UgdGhlcmUncyBh biBlbm91cm1vdXMgbnVtYmVyIG9mIGVkZ2UgY2FzZXMgaGVyZQ0KICAgIC0tIC4uLiBCYXNpY2Fs bHkgYWdyZWUgd2l0aCBNYXJ0aW4gdGhhdCB5b3UgY2FuIGRvIHRoZSBzYW1lIFVYIHdpdGggZXhp c3RpbmcgQVBJcw0KICAgIC0tIEp1c3RpbjogSXQgd291bGQgdG90YWxseSB3b3JrIGZvciB0aGUg YXBwbGljYXRpb24gdG8gdHJlYXQgdGhlIG5ldyBjYWxsIGFzIGEgY29udGludWF0aW9uIG9mIHRo ZSBvbGQgY2FsbA0KLS0gUmFuZGFsbCBKZXNzdXA6IERhdGEgQ2hhbm5lbCBpc3N1ZXMNCiAgICAt LSBDb250ZW50aW9uIHdpdGggbWVkaWEgc3RyZWFtcw0KICAgIC0tIElkZWFzOg0KICAgICAgICAt LSBObyBjb250cm9sIG9yIHNpbXBsZSByYXRlIGNhcHMNCiAgICAgICAgLS0gU2xhdmUgdG8gbWVk aWEgY29uZ2VzdGlvbiBjb250cm9sDQogICAgICAgIC0tIExFREJBVA0KICAgICAgICAtLSBSTUNB VA0KICAgIC0tIExlbm5veDogT24gZ2l2aW5nIHRoaXMgYSAlIG9mIHRoZSBtZWRpYSBjb25nZXN0 aW9uIGNvbnRyb2wsIHRoYXQgY291bGQgbGVhZCB0byBpbnRlcmVzdGluZyBvc2NpbGxhdGlvbnMN CiAgICAtLSBSYW5kYWxsOiBXb3VsZCB3YW50IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgbGF5ZXIg dG8ga25vdyB3aGF0IHRoZSBkYXRhIGNoYW5uZWwgdHJpZWQgdG8gZG8NCiAgICAtLSBDb2xpbiBQ ZXJraW5zOiBNZWRpYSBjaGFubmVsIHdpbGwgYWxzbyBnb2luZyB0byBiZSBjb21wZXRpbmcgd2l0 aCBUQ1ANCiAgICAtLSAuLi4gUGVyaGFwcyB3ZSBzaG91bGQgYmUgYWRkcmVzc2luZyB0aGUgZ2Vu ZXJhbCBwcm9ibGVtIG9mIGhvdyB0byBtYWtlIHRoZSBtZWRpYSBzdHJlYW0gcm9idXN0DQogICAg LS0gUmFuZGFsbDogVW5saWtlIGdlbmVyaWMgdHJhZmZpYywgd2UgY2FuIGFjdHVhbGx5IGNvbnRy b2wgdGhpcyBvbmU7IHRoZSBhcHAgbWlnaHQgaGF2ZSBwcmlvcml0eSBwcmVmZXJlbmNlcw0KICAg IC0tIE1pY2hhZWwgPz8/OiBXZSBuZWVkIHRvIGNvbWUgdXAgd2l0aCBhbiBhY2NlcHRhYmxlIHNv bHV0aW9uIGluIHRoZSBmaXJzdCB2ZXJzaW9uDQogICAgLS0gLi4uIEZvciBtZSwgdGhlIGRhdGEg Y2hhbm5lbHMgZG9uJ3Qga2lsbCB0aGUgbWVkaWEgY2hhbm5lbHMgb24gdGhlIHNhbWUgUGVlckNv bm5lY3Rpb24NCiAgICAtLSBSYW5kYWxsIFN0ZXdhcnQ6IElmIHlvdSdyZSBnb2luZyB0byBkbyBz b21ldGhpbmcgbGlrZSB0aGlzLCBkb24ndCBwdXQgYSByYXRlIGxpbWl0ZXIsIHB1dCBpbiBhbiBB UEkgdG8gdGhlIGNvbmdlc3Rpb24gd2luZG93DQogICAgLS0gS2F1Zm1hbm46IFByaW9yaXRpemF0 aW9uIG9ubHkgZXhpc3RzIGlmIHRoZXJlJ3Mgc2hhcmVkIGNvbmdlc3Rpb24gc3RhdGUNCiAgICAt LSAuLi4gSW4gb3JkZXIgdG8gZ2V0IHByaW9yaXRpemF0aW9uLCB3ZSBuZWVkIHNoYXJlZCBjb25n ZXN0aW9uIHN0YXRlDQogICAgLS0gLi4uIE9uY2UgeW91IGhhdmUgc2hhcmVkIGNvbmdlc3Rpb24g c3RhdGUsIHNldmVyYWwgb2YgdGhlc2Ugb3B0aW9ucyBhcmUgbm8gbG9uZ2VyIHJlbGV2YW50DQog ICAgLS0gLi4uIEUuZy4sICJsb3NzLWJhc2VkLCBjYW4ga2lsbCBtZWRpYSIgaXMgbm90IGEgcHJv YmxlbQ0KICAgIC0tIEhhcmFsZDogQXQgdGhlIG1vbWVudCwgd2UgaGF2ZSBvbmUgcGllY2Ugb2Yg Y29uZ2VzdGlvbiBzdGF0ZSwgbmFtZWx5IHRoZSBjaXJjdWl0IGJyZWFrZXIgYWxnb3JpdGhtIHRo YXQgQ29saW4gaXMgc2hlcGhlcmRpbmcgdGhyb3VnaCBBVlRDT1JFDQogICAgLS0gLi4uIFN1Z2dl c3QgdGhhdCB0aGUgZGVmYXVsdCBpcyB0aGF0IHNlbnNpYmxlIHRoaW5ncyBoYXBwZW4gd2hlbiB5 b3UgaGF2ZSBubyBBUEkNCiAgICAtLSAuLi4gV2hhdCBzaG91bGQgcHJvYmFibHkgaGFwcGVuIGlz IHRoYXQgeW91IHdhdGNoIHRoZSBvbmUgcGllY2Ugb2Ygc3RhdGUgeW91IGhhdmUsIGFuZCBiYWNr IG9mZg0KICAgIC0tIE1hZ251czogWW91IGNhbiB1c2UgcXVpdGUgYSBsb3Qgb2YgdGhlIGF2YWls YWJsZSBiYW5kd2lkdGgNCiAgICAtLSBMYXJzIEVnZ2VydDogSSB0aGluayB3ZSBmdW1ibGVkIHdo ZW4gd2UgY2hhcnRlcmVkIFJNQ0FULiAgVGhhdCBuZWVkcyB0byBjb3ZlciBib3RoIGRhdGEgYW5k IG1lZGlhIGNoYW5uZWwNCiAgICAtLSBQaWVycyBP4oCZSGFubGFuOiBUaGUgYWN0dWFsIHJhdGUg Y29udHJvbCwgaG93IHlvdSBkbyB0aGlzIHdpdGggU0NUUCwgeW91IG1pZ2h0IG5lZWQgbW9yZSB1 c2UgYW5hbHlzaXMNCiAgICAtLU1pa2UgUmFtaGFsbz86IFdoYXQgdGhlIGNoYW5uZWxzIG5lZWQg dG8gaGF2ZSBpcyBhIHNoYXJlZCBjb25nZXN0aW9uICptZWFzdXJlKiAobm90IHN0YXRlKQ0KICAg IC0tIFtbIHByZXNlbnRhdGlvbiB+IGluaXRpYWwgY3JlYXRpb24gXV0NCiAgICAtLSBLYXVmbWFu bjogRG8geW91IG1lYW4gImNyZWF0aW5nIHRoZSBkYXRhIGNoYW5uZWwiIG9yICJjcmVhdGluZyBT Q1RQIGNoYW5uZWxzIg0KICAgIC0tIFJhbmRhbGw6IEkgbWVhbiBzZXR0aW5nIHVwIHRoZSBTQ1RQ IG92ZXIgRFRMUyBhdCB0aGUgYmVnaW5uaW5nLCB0aGVuIHNldHRpbmcgdXAgY3JlYXRlRGF0YUNo YW5uZWwgbGF0ZXINCiAgICAtLSBJbmNsdWRlIHByb3RvY29sIGZpZWxkIGZyb20gd2Vic29ja2V0 cz8gIEZvciBpbnRlcm9wIGJldHdlZW4gYXBwbGljYXRpb25zDQogICAgLS0gVGhvbXNvbjogVGhp cyBzZWVtcyB1c2VmdWwNCiAgICAtLSBIYXJhbGQ6IEp1c3QgY2xhcmlmeTogdGhlc2UgYXJlIG5v dCBNSU1FIHR5cGVzDQotLSBUZWQ6IENoYWlycyBhcmUgZGlzY3Vzc2luZyB3aGV0aGVyIHRvIGhh dmUgYW4gaW50ZXJpbSwgd2lsbCBjb21lIHRvIHRoZSBsaXN0IGZvciBkaXNjdXNzaW9uIChmMmYg LyB2aXJ0dWFsKQ0KICAgIC0tIFdlbmdlcjogV2lsbCB0aGUgaW50ZXJpbSAgYmUgYSBjb2RlYyBk ZWNpc2lvbiBtZWV0aW5nPw0KICAgIC0tIFRlZDogTm8NCg== --14dae9cdc84f133e5b04cedd78b9-- From randell-ietf@jesup.org Mon Nov 19 18:19:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC14321E8048 for ; Mon, 19 Nov 2012 18:19:34 -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 A9tPeMV6kQVZ for ; Mon, 19 Nov 2012 18:19:34 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 661B421E8034 for ; Mon, 19 Nov 2012 18:19:34 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:53791 helo=[192.168.1.3]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TadQz-000DZz-Hk; Mon, 19 Nov 2012 20:19:33 -0600 Message-ID: <50AAE8B5.8050601@jesup.org> Date: Mon, 19 Nov 2012 21:19:33 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , public-webrtc@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions -job overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Nov 2012 02:19:35 -0000 On 11/19/2012 8:10 AM, Randell Jesup wrote: > > This assumes that a MediaStream is the correct transfer mechanism (and > correct API at the W3 level), which is definitely something I meant "definitely not something I'd agree to at this point" (Thanks for pointing this out to me Harald) > I'd agree to at this point. I also wouldn't rule it out (I see some > arguments in favor, as well as against) - but this needs to occur in > public-webrtc@w3, and would do so before going too far down the path > here assuming a MediaStream is the mechanism. > > For this part of the conversation, I strongly suggest it occur on > public-webrtc, so reply there please. -- Randell Jesup randell-ietf@jesup.org From paalh@ifi.uio.no Mon Nov 19 23:26:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F153321F86E5; Mon, 19 Nov 2012 23:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYug9SRFDlSb; Mon, 19 Nov 2012 23:26:41 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 7542321F8733; Mon, 19 Nov 2012 23:26:41 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TaiE8-0002he-On; Tue, 20 Nov 2012 08:26:36 +0100 Received: from [77.88.71.190] (helo=mbpal.simula.no) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user paalh (Exim 4.80) (envelope-from ) id 1TaiE8-0007bK-Ez; Tue, 20 Nov 2012 08:26:36 +0100 From: =?iso-8859-1?Q?P=E5l_Halvorsen?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Nov 2012 08:26:35 +0100 Message-Id: <398F972C-890E-4184-A07C-EAA84AB859AF@ifi.uio.no> To: bloat@lists.bufferbloat.net, iccrg@cs.ucl.ac.uk, rmcat@ietf.org, rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 47 msgs/h 17 sum rcpts/h 47 sum msgs/h 17 total rcpts 217 max rcpts/h 47 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F61835792521E4AB03D62DC007175DBFAC438768 X-UiO-SPAM-Test: remote_host: 77.88.71.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 17 total 45 max/h 17 blacklist 0 greylist 0 ratelimit 0 Subject: [rtcweb] [NOSSDAV13]: Paper deadline in one week (26. November) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Nov 2012 07:26:42 -0000 ********* Paper submission deadline in ONE week ********** NOSSDAV 2013: ACM Workshop on Network and Operating Systems Support=20 for Digital Audio and Video Oslo, Norway, February 26 =97 27, 2013 http://nossdav2013.ndlab.net NEW: Authors of selected good papers will be invited to submit an extended = version of=20 their work and submit it to the ACM Transactions on Multimedia = Computing,=20 Communications and Applications (ACM TOMCCAP) journal. NEW:=20 Dr. Aljosa Smolic (Disney Research Zurich, Switzerland) will give a = keynote=20 entiteled "Advanced 3D Video Processing and Coding" at NOSSDAV 2013.=20 http://nossdav2013.ndlab.net/program.html = --------------------------------------------------------------------------= -------------- As in previous years, the workshop seeks papers in all areas of = multimedia networking and systems. Authors are especially encouraged to submit papers with real-world experimental results and real data sets. Topics of interest include (but are not restricted to): - Cloud and peer-to-peer system architectures - Media streaming, distribution and storage support - Multimedia communications and system security - Multi-core and many-core architecture support - Networked GPUs, graphics and virtual environments - Networked games / Real-time immersive systems - Operating system, middleware and network support - Web 2.0 systems and social networks - Wireless networks and embedded systems for multimedia applications =20 In particular, we are interested in soliciting papers that discuss system-level support for social media and social networking, papers that focus on improving performance with multi-core and many-core processors, as well as papers that focus on multimedia applications on mobile devices and/or in a cloud computing environment. Submitted papers must be original and should not be currently under review for any other publication. Authors of accepted papers will need to sign an ACM copyright release form and present their paper at NOSSDAV 2013 in person. The Proceedings of NOSSDAV 2013 will be published by ACM and distributed at the workshop electronically, and will also be included in the ACM Digital Library. * Paper Deadline: 26. November 2012 All paper submissions will be handled electronically in the NOSSDAV 2013 submission web site: http://submission.ndlab.net/nossdav13/ (also available from http://nossdav2013.ndlab.net) Best regards, Program Co-Chairs P=E5l Halvorsen, University of Oslo/Simula, Norway Laszlo B=F6sz=F6rmenyi, Klagenfurt University, Austria From magnus.westerlund@ericsson.com Wed Nov 21 01:40:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF70921F8495 for ; Wed, 21 Nov 2012 01:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.175 X-Spam-Level: X-Spam-Status: No, score=-106.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 m+UFQJJAsPGE for ; Wed, 21 Nov 2012 01:40:29 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBEF21F8203 for ; Wed, 21 Nov 2012 01:40:28 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-2c-50aca18b18f5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 51.F5.26143.B81ACA05; Wed, 21 Nov 2012 10:40:27 +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; Wed, 21 Nov 2012 10:40:26 +0100 Message-ID: <50ACA189.10104@ericsson.com> Date: Wed, 21 Nov 2012 10:40:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <50A6578F.3050501@ericsson.com> <50A9ECC9.5070404@ericsson.com> In-Reply-To: <50A9ECC9.5070404@ericsson.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+JvjW73wjUBBrOOCVmseH2O3WLtv3Z2 ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJXxbO5t9oLtrBXTz89hbGDcy9LFyMkhIWAi cebvZ2YIW0ziwr31bF2MXBxCAicZJU61N7JCOMsZJWZ8/8kGUsUroCnx8891sG4WAVWJH9v/ MIHYbAIWEjd/NILViAoES+w5tpYRol5Q4uTMJ2D1IgJmEg8n7AerYRZwlTg3cwpYr7CAucTk F/+glk1glFj1sZMdJMEpoCOxcMcxVojzJCXevn/FDNGsJzHlagsjhC0v0bx1NlhcSEBboqGp g3UCo9AsJLtnIWmZhaRlASPzKkb23MTMnPRyo02MwHA9uOW36g7GO+dEDjFKc7AoifNab93j LySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRaYPTi2PCL6fGa27WmFt/WOtDXaFtpJvGAb90 /wvSjcyXnlv8Yz4wz+bmxGZOowmbLK5ZTOdcz7b7rP5MpdByRuYTmoVVsltd5u+dxCTOtTJM QPpW06k2yUsOfDM7GSoSxSIMG0OPPnStDXvXKqFYvE77l8f1PSLTZlue237tUc/teTfWrnVU YinOSDTUYi4qTgQAUQl0VCUCAAA= Cc: "rtcweb@ietf.org" Subject: [rtcweb] Doodle poll for Face to Face Interim in Boston X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Nov 2012 09:40:30 -0000 WG, Please assume that the face to face meeting will be in Boston. We have not gotten all the confirmations to say 100% certain. So if you need to please update the poll. http://www.doodle.com/wvzp6ue9awn7wpni cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Nov 22 07:53:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7287621F8428 for ; Thu, 22 Nov 2012 07:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 4bcA0MvQKg6j for ; Thu, 22 Nov 2012 07:52:58 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC61921F81FF for ; Thu, 22 Nov 2012 07:52:56 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-5c-50ae4a52104c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CE.10.11564.25A4EA05; Thu, 22 Nov 2012 16:52:50 +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, 22 Nov 2012 16:52:50 +0100 Message-ID: <50AE4A4F.5080303@ericsson.com> Date: Thu, 22 Nov 2012 16:52:47 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RjfIa12Awas+GYu1/9rZLRrn2jkw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGZ83XGQuaOKsmD9pB0sDYz97FyMnh4SAicTC 39egbDGJC/fWs3UxcnEICZxklHg+9TEzhLOcUaJ17kxGkCpeAW2Jj/+2soDYLAKqEiv/zQPr ZhOwkLj5o5ENxBYV8JWYtecXE0S9oMTJmU/A6kUElCX2XtkBVsMsICyx4WIbWFxYwFBi8s85 QHEOoGUBEhe2VIGEOQUCJdbfe8MGcZykxKJpnSwQrXoSU662MELY8hLNW2czg9hCQKc1NHWw TmAUmoVk8ywkLbOQtCxgZF7FyJ6bmJmTXm64iREYqAe3/NbdwXjqnMghRmkOFiVxXq6k/f5C AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGCvE3NXXXdSuNOD8lcS96FTjZ52fxWH3i/csDxXe yhh8KZrdum+3iGj8peIzS7O3lKRaXJm8mUV+4sl5XG9keRXvJiQ+6zkZ0O746LLRcq0fiRMs 3r+bfqbKUH3vvnz3SxKqn+UDNhwIXb/oxe+uSbyRLkInJxf/DfXQmMjcMu/5uW+pkvW7HJRY ijMSDbWYi4oTAZaTGFkiAgAA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Minutes for IETF 85 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: Thu, 22 Nov 2012 15:53:00 -0000 Hi, I have comments about the following lines: > Ted - NB: All the work of W3C WebRTC group takes place on public > mailing list. I don't understand what NB means. I remember this as being a "Note to Everyone" > Matthew Kaufman - not an open issue - receive from other side no > mline. MSID issue same as the No [??] issue. I guess the last should be "Comment No 22" which is comment from the W3C meeting that along the lines. If you have done this according to Microsoft API proposal this would not be an issue. > -- Michael ???: We need to come up with an acceptable solution in the > first version I would guess that this is "Michael Tuexen" -- 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 tterriberry@mozilla.com Thu Nov 22 07:59:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6182121F8559 for ; Thu, 22 Nov 2012 07:59:55 -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 dWhZUj+0bWbx for ; Thu, 22 Nov 2012 07:59:54 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id CFE6D21F841E for ; Thu, 22 Nov 2012 07:59:54 -0800 (PST) Received: from [192.168.11.10] (pool-71-114-8-24.washdc.dsl-w.verizon.net [71.114.8.24]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 47333F217F for ; Thu, 22 Nov 2012 07:59:52 -0800 (PST) Message-ID: <50AE4BF7.2090101@mozilla.com> Date: Thu, 22 Nov 2012 07:59:51 -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: <50AE4A4F.5080303@ericsson.com> In-Reply-To: <50AE4A4F.5080303@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Minutes for IETF 85 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: Thu, 22 Nov 2012 15:59:55 -0000 Magnus Westerlund wrote: >> Ted - NB: All the work of W3C WebRTC group takes place on public >> mailing list. > > I don't understand what NB means. I remember this as being a "Note to > Everyone" http://en.wikipedia.org/wiki/Nota_bene From paalh@ifi.uio.no Thu Nov 22 14:24:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2921F8736; Thu, 22 Nov 2012 14:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8n-kMH5QmLD; Thu, 22 Nov 2012 14:24:32 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id A03A821F872A; Thu, 22 Nov 2012 14:24:31 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TbfCA-000556-Et; Thu, 22 Nov 2012 23:24:30 +0100 Received: from cm-84.209.55.238.getinternet.no ([84.209.55.238] helo=[10.0.1.4]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user paalh (Exim 4.80) (envelope-from ) id 1TbfCA-0003pE-1d; Thu, 22 Nov 2012 23:24:30 +0100 From: =?iso-8859-1?Q?P=E5l_Halvorsen?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Nov 2012 23:24:29 +0100 Message-Id: To: rmcat@ietf.org, rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 47 msgs/h 28 sum rcpts/h 48 sum msgs/h 28 total rcpts 338 max rcpts/h 55 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 40711DB5F35F27FCDC9C081625AC18ED00B9B534 X-UiO-SPAM-Test: remote_host: 84.209.55.238 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 28 total 78 max/h 28 blacklist 0 greylist 0 ratelimit 0 Subject: [rtcweb] [NOSSDAV13]: Deadline extension - 3. December X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Nov 2012 22:24:32 -0000 Due to multiple requests and the Thanksgiving holiday, the NOSSDAV 2013=20= paper submission deadline is extended until 3. DECEMBER. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NOSSDAV 2013: ACM Workshop on Network and Operating Systems Support=20 for Digital Audio and Video Oslo, Norway, February 26 =97 27, 2013 http://nossdav2013.ndlab.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ As in previous years, the workshop seeks papers in all areas of = multimedia networking and systems. Authors are especially encouraged to submit papers with real-world experimental results and real data sets. Topics of interest include (but are not restricted to): - Cloud and peer-to-peer system architectures - Media streaming, distribution and storage support - Multimedia communications and system security - Multi-core and many-core architecture support - Networked GPUs, graphics and virtual environments - Networked games / Real-time immersive systems - Operating system, middleware and network support - Web 2.0 systems and social networks - Wireless networks and embedded systems for multimedia applications =20 In particular, we are interested in soliciting papers that discuss system-level support for social media and social networking, papers that focus on improving performance with multi-core and many-core processors, as well as papers that focus on multimedia applications on mobile devices and/or in a cloud computing environment. Submitted papers must be original and should not be currently under review for any other publication. Authors of accepted papers will need to sign an ACM copyright release form and present their paper at NOSSDAV 2013 in person. The Proceedings of NOSSDAV 2013 will be published by ACM and distributed at the workshop electronically, and will also be included in the ACM Digital Library. * Paper Deadline: 3. December 2012 All paper submissions will be handled electronically in the NOSSDAV 2013 submission web site: http://submission.ndlab.net/nossdav13/ (also available from http://nossdav2013.ndlab.net) Best regards, Laszlo B=F6sz=F6rmenyi, Klagenfurt University, Austria P=E5l Halvorsen, University of Oslo/Simula, Norway (Program Co-Chairs) From internet-drafts@ietf.org Thu Nov 22 23:50:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C4921F8872; Thu, 22 Nov 2012 23:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 ea7dCHns6bn7; Thu, 22 Nov 2012 23:50:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6321F8200; Thu, 22 Nov 2012 23:50:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121123075026.13110.29052.idtracker@ietfa.amsl.com> Date: Thu, 22 Nov 2012 23:50:26 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 07:50:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : WebRTC Audio Codec and Processing Requirements Author(s) : Jean-Marc Valin Cary Bran Filename : draft-ietf-rtcweb-audio-01.txt Pages : 6 Date : 2012-11-22 Abstract: This document outlines the audio codec and processing requirements for WebRTC client application and endpoint devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-audio-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmvalin@mozilla.com Fri Nov 23 00:02:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB0F21F8757 for ; Fri, 23 Nov 2012 00:02:18 -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 mVBZr8emjkUV for ; Fri, 23 Nov 2012 00:02:14 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 10BED21F872E for ; Fri, 23 Nov 2012 00:02:14 -0800 (PST) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id CB5B5F210A for ; Fri, 23 Nov 2012 00:02:11 -0800 (PST) Message-ID: <50AF2D82.1060409@mozilla.com> Date: Fri, 23 Nov 2012 03:02:10 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20121123075026.13110.29052.idtracker@ietfa.amsl.com> In-Reply-To: <20121123075026.13110.29052.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 08:02:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The only change in this new version is to fix this issue: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/1 On 11/23/2012 02:50 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Real-Time > Communication in WEB-browsers Working Group of the IETF. > > Title : WebRTC Audio Codec and Processing Requirements > Author(s) : Jean-Marc Valin Cary Bran Filename : > draft-ietf-rtcweb-audio-01.txt Pages : 6 Date > : 2012-11-22 > > Abstract: This document outlines the audio codec and processing > requirements for WebRTC client application and endpoint devices. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQry2CAAoJEJ6/8sItn9q9f7EIAKdSNAYps11+jBI8WhR02J7T mk5WlMSDQS7KrLV8vdIHOcJl81+wy/SjF3iYNIkbCyFdakiBB/MyJGnWlwOyHdpG /niGoWncs80AKcww2hPf0MHqoogPFwk+/ZMl0Z/xueR5pscObIbVqeMvYfVbHm90 6fFAwDOyqAWP0DDY0eT00k2cgLq779UopbfUzNBFwy/oGfCjFkALjxCK5u6D4LDn Ups/zB5fJGlqtzqiaJKm9jJCALNouSh5bwT4x3ig26+PMv8XaLJDV0RWJeDg5xYu ZGHbTUU13hQ2aayQ7vMif4uUF3mMbkgjHJ4qZ1uGrhaXPr8D0uZOo4z8OcfF6Z8= =6z4K -----END PGP SIGNATURE----- From harald@alvestrand.no Fri Nov 23 02:44:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7040E21F859D for ; Fri, 23 Nov 2012 02:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.136 X-Spam-Level: X-Spam-Status: No, score=-110.136 tagged_above=-999 required=5 tests=[AWL=0.463, 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 Y9qRnZHt8Mem for ; Fri, 23 Nov 2012 02:44:46 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D348021F859A for ; Fri, 23 Nov 2012 02:44:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0541B39E207 for ; Fri, 23 Nov 2012 11:44:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c04eZiz-9hIX for ; Fri, 23 Nov 2012 11:44:41 +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 3BBB939E1CC for ; Fri, 23 Nov 2012 11:44:41 +0100 (CET) Message-ID: <50AF5398.1040309@alvestrand.no> Date: Fri, 23 Nov 2012 11:44:40 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Nov 2012 10:44:46 -0000 I finally put aside time to read through this draft in detail again. I think we're close to where we need to be on this doc. But still some work to be done. Nits will be sent to the authors - I thought I'd raise some bigger issues here. First is the positioning of this draft. I believe that the draft should reference the W3C API document and say "that one is the authoritative reference for what the API looks like; this document shows how the calls from that API are actually affecting the media configuration and media bits on the wire". This is important enough that it needs to be clear from the abstract and from the intro. Second is a matter of wording: The document mentions quite a few things that are out of scope, such as the actual signalling, forking, decisions on what to accept and so on. I believe those mentions could be shortened - the mantra should be "the JS application decides what configurations to apply and when to apply them". The relationship to 3264 needs to be stated clearly - that when the application chooses to apply configuration updates in the way specified by RFC 3264, the results described in RFC 3264 happen. Third - SDP requirements. There are two changes that need to be made: - The requirements need to include BUNDLE and MSID - The configurable SDP parameters need to explain what "configurable" means, and list parameters in the format we talked about in Lyon: Parameters that MUST NOT be changed, parameters that MAY be changed, and conforming browsers MUST take appropriate notice, and parameters that MAY be changed and conforming browsers MAY take appropriate notice. A fourth matter is rehydration, but I'll return to that after running some experiments. From harald@alvestrand.no Mon Nov 26 01:52:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E78B21F86B3 for ; Mon, 26 Nov 2012 01:52:33 -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 eiOm3FUkyiVA for ; Mon, 26 Nov 2012 01:52:32 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5F321F86AC for ; Mon, 26 Nov 2012 01:52:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 462ED39E13F for ; Mon, 26 Nov 2012 10:52: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 wuRVdQDlHqjk for ; Mon, 26 Nov 2012 10:52:25 +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 89CC939E01E for ; Mon, 26 Nov 2012 10:52:25 +0100 (CET) Message-ID: <50B33BD8.8090000@alvestrand.no> Date: Mon, 26 Nov 2012 10:52:24 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Nit in draft-jesup-rtcweb-data-protocol: Format for DOMString X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Nov 2012 09:52:33 -0000 This is just a nit, but needs to be de-nitted: draft-jesup-rtcweb-data-protocol-03 doesn't say what the encoding for a DOMString in data messages is. It should be UTF-8, to match RFC 6455 (websockets) and other protocols. I suggest adding this information to the IANA considerations section of the document. Harald From Michael.Tuexen@lurchi.franken.de Mon Nov 26 03:08:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC221F86B1 for ; Mon, 26 Nov 2012 03:08:24 -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 x939eYwoXqbP for ; Mon, 26 Nov 2012 03:08:24 -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 2541621F84FA for ; Mon, 26 Nov 2012 03:08:23 -0800 (PST) Received: from [10.0.1.109] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 99FA31C0C069C; Mon, 26 Nov 2012 12:08:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <50B33BD8.8090000@alvestrand.no> Date: Mon, 26 Nov 2012 12:08:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B14011D-E5F8-47F1-A445-F7BD5119C47C@lurchi.franken.de> References: <50B33BD8.8090000@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Nit in draft-jesup-rtcweb-data-protocol: Format for DOMString X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Nov 2012 11:08:24 -0000 On Nov 26, 2012, at 10:52 AM, Harald Alvestrand wrote: > This is just a nit, but needs to be de-nitted: >=20 > draft-jesup-rtcweb-data-protocol-03 doesn't say what the encoding for = a DOMString in data messages is. It should be UTF-8, to match RFC 6455 = (websockets) and other protocols. >=20 > I suggest adding this information to the IANA considerations section = of the document. OK. I'll add it. Need to address a couple of comments from Magnus... Best regards Michael >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From partha@parthasarathi.co.in Mon Nov 26 09:35:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB9821F85EE for ; Mon, 26 Nov 2012 09:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW89a5Pq8JSX for ; Mon, 26 Nov 2012 09:35:09 -0800 (PST) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDBD21F8594 for ; Mon, 26 Nov 2012 09:35:09 -0800 (PST) Received: from userPC (unknown [122.179.44.19]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 8D4D23E2395; Mon, 26 Nov 2012 17:35:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1353951308; bh=z+4EaiVGO9xJGLfmGEwLsqSivnSMB3hfy1W6QPOVU+U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=XmYuOWKAtVwd1rkaJffxFOMQtq9xufGN6JGKGd0Gikv63unnhVb/3knWYsSnp9IZ8 ygY6OD3OsVN9M/9s25BzmwdBvf5SVYwKTG9kfC6jo8QmUGaI8dIHjDQYC45vyZuCBs oSdtupJRkfDSumdJPiREpSplS0adcwGvxXCIs1uA= From: "Parthasarathi R" To: "'DRAGE, Keith \(Keith\)'" , "'Bernard Aboba'" , =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>, <000601cdc996$ea6c0ec0$bf442c40$@co.in>, <50B266C5.90902@ericsson.com> In-Reply-To: Date: Mon, 26 Nov 2012 23:05:00 +0530 Message-ID: <000301cdcbfc$604f4fa0$20edeee0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CDCC2A.7A078BA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3LRTNgAq5uAGpzTmSHXiV6vqL1AgAdtimgAA+NzsA= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0209.50B3A84C.0138, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: rtcweb@ietf.org Subject: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Nov 2012 17:35:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01CDCC2A.7A078BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 There is a long discussion in MMUSIC whether Fax usecase has to be added = in RTCWeb or not (http://www.ietf.org/mail-archive/web/mmusic/current/msg09939.html).=20 =20 I=92m forwarding this mail to this WG to see the actual interest for fax usecase. =20 Thanks Partha =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: Monday, November 26, 2012 3:26 PM To: Bernard Aboba; Stefan H=E5kansson LK Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) =20 Be careful to address this issue from a worldwide context rather than a North America specific one. =20 There are still plenty of people raising fax issues from the Asian countries. =20 Keith =20 _____ =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: 25 November 2012 19:44 To: Stefan H=E5kansson LK Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) =20 Stefan said: > I don't think this goes for fax, I think fax these days is only used = by=20 > certain (few) organizations and only for certain types of = communication. >=20 > But if you think differently, please make a proposal on the rtcweb = mail list! [BA] Given the steep decline in landlines, POTS is on the road to = becoming economically non-viable by the end of the decade, if not sooner. Once = POTS shuts down, the legal and regulatory requirements which prop up the use = of fax will need to be re-thought. IMHO given the bleak future of fax, supporting it in WebRTC is not worth the effort.=20 BTW, support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-audio-01 instead of RFC 4734 (Fax, Modem and Text Telephony) which was cited (mistakenly) in -00. =20 Bernard "Spent several hours debugging T.38 last week" Aboba ------=_NextPart_000_0004_01CDCC2A.7A078BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

There is a long discussion in MMUSIC whether Fax usecase = has to be added in RTCWeb or not = (http://www.ietf.org/mail-archive/web/mmusic/current/msg09939.html).

 

I’m forwarding this mail to this WG to see the = actual interest for fax usecase.

 

Thanks

Partha

 

From:= mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = DRAGE, Keith (Keith)
Sent: Monday, November 26, 2012 3:26 PM
To: Bernard Aboba; Stefan H=E5kansson LK
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom = sought: Prioritization of codecs))

 

Be careful to address this issue from a worldwide context = rather than a North America specific one.

 

There are still plenty of people raising fax issues from the = Asian countries.

 

Keith

 

From:= mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Bernard Aboba
Sent: 25 November 2012 19:44
To: Stefan H=E5kansson LK
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom = sought: Prioritization of codecs))

 

Stefan = said:

> I don't think this goes for fax, I think fax these days is only used by =
> certain (few) organizations and only for certain types of = communication.
>
> But if you think differently, please make a proposal on the rtcweb = mail list!

[BA]  Given the steep decline in landlines, POTS is on the road to becoming economically non-viable by the end of the decade, if not = sooner.   Once POTS shuts down, the legal and regulatory requirements which = prop up the use of fax will need to be re-thought.  IMHO given the bleak = future of fax, supporting it in WebRTC is not worth the effort.

BTW, support for RFC 4733 (DTMF) is now required in = draft-ietf-rtcweb-audio-01 instead of  RFC 4734 (Fax, Modem and Text Telephony) which was = cited (mistakenly) in -00.  

Bernard "Spent several hours debugging T.38 last week" = Aboba

------=_NextPart_000_0004_01CDCC2A.7A078BA0-- From richard@shockey.us Mon Nov 26 14:34:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FD821F853B for ; Mon, 26 Nov 2012 14:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.964 X-Spam-Level: X-Spam-Status: No, score=-101.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Raghmm0cn0iV for ; Mon, 26 Nov 2012 14:34:17 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 8F15B21F862C for ; Mon, 26 Nov 2012 14:34:17 -0800 (PST) Received: (qmail 4696 invoked by uid 0); 26 Nov 2012 22:33:52 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 26 Nov 2012 22:33:52 -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:Cc:To:From; bh=fc0XBKCNnuU4Z575jNnpVCXKRBmiFqLxYTpKByoRzRU=; b=g4EI0mD6hY8Mgdn4RQVN/Z0C7k/mrwox/e05TY2d0MP540W7xNrUGSudBQYQkPiE2ZMczizNPDGDaSocMPNPhLvOtqdeKJJO1lFEgBBrfe1ydksYd8O2DI5H37IKPNL3; Received: from [71.191.243.130] (port=56300 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Td7FQ-0001mp-8h; Mon, 26 Nov 2012 15:33:52 -0700 From: "Richard Shockey" To: "'Parthasarathi R'" , "'DRAGE, Keith \(Keith\)'" , "'Bernard Aboba'" , =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>, <000601cdc996$ea6c0ec0$bf442c40$@co.in>, <50B266C5.90902@ericsson.com> <000301cdcbfc$604f4fa0$20edeee0$@co.in> In-Reply-To: <000301cdcbfc$604f4fa0$20edeee0$@co.in> Date: Mon, 26 Nov 2012 17:33:50 -0500 Message-ID: <017c01cdcc26$1c1e8c40$545ba4c0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01CDCBFC.33488440" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3LRTNgAq5uAGpzTmSHXiV6vqL1AgAdtimgAA+NzsAACmQvsA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Nov 2012 22:34:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_017D_01CDCBFC.33488440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well first .. fax is a globally significant real time PSTN service that = is NOT going away any time soon no matter what anyone in the IETF thinks. = In fact some of the current market statistics indicate low single digit = growth in the service irrespective of the decline in landlines.=20 =20 As Bernard correctly points out a good portion of the FAX traffic is generated by national regulatory requirements and the fact that the transaction cannot be repudiated since the call records kept by the = carrier are considered legally valid. =93All contract submissions must be = delivered by close of business XXX EST either by currier or FAX=94 =20 =20 Email is considered not secure and the SMTP transaction logs are not = legally valid in any jurisdiction I know of . That=92s the way it is. Don=92t = like it? You go try and change the laws here. =20 =20 The number of industries that rely on fax are endless and it a = particularly important service in nation states where non roman characters are used. Asia, Middle East etc. =20 =20 That said ..do you really want to go down this road? Probably not right = now since the non repudiation issue is the one requirement I doubt RTCWEB is prepared to address. However if the RTCWEB transaction gateways into the Public SIP Network than its another issue.=20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Parthasarathi R Sent: Monday, November 26, 2012 12:35 PM To: 'DRAGE, Keith (Keith)'; 'Bernard Aboba'; 'Stefan H=E5kansson LK' Cc: rtcweb@ietf.org Subject: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: = M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] =20 Hi all, =20 There is a long discussion in MMUSIC whether Fax usecase has to be added = in RTCWeb or not (http://www.ietf.org/mail-archive/web/mmusic/current/msg09939.html).=20 =20 I=92m forwarding this mail to this WG to see the actual interest for fax usecase. =20 Thanks Partha =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: Monday, November 26, 2012 3:26 PM To: Bernard Aboba; Stefan H=E5kansson LK Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) =20 Be careful to address this issue from a worldwide context rather than a North America specific one. =20 There are still plenty of people raising fax issues from the Asian countries. =20 Keith =20 _____ =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: 25 November 2012 19:44 To: Stefan H=E5kansson LK Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) =20 Stefan said: > I don't think this goes for fax, I think fax these days is only used = by=20 > certain (few) organizations and only for certain types of = communication. >=20 > But if you think differently, please make a proposal on the rtcweb = mail list! [BA] Given the steep decline in landlines, POTS is on the road to = becoming economically non-viable by the end of the decade, if not sooner. Once = POTS shuts down, the legal and regulatory requirements which prop up the use = of fax will need to be re-thought. IMHO given the bleak future of fax, supporting it in WebRTC is not worth the effort.=20 BTW, support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-audio-01 instead of RFC 4734 (Fax, Modem and Text Telephony) which was cited (mistakenly) in -00. =20 Bernard "Spent several hours debugging T.38 last week" Aboba ------=_NextPart_000_017D_01CDCBFC.33488440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well first .. fax is a globally significant real time PSTN service = that is NOT going away any time soon no matter what anyone in the IETF = thinks.=A0=A0 In fact some of the current market statistics indicate low = single digit growth in the service irrespective of the decline in = landlines.

 

As Bernard correctly points out a good portion of the FAX traffic is = generated by national regulatory requirements and the fact that the = transaction cannot be repudiated since the call records kept by the = carrier are considered legally valid.=A0 “All contract submissions = must be delivered by close of business XXX EST either by currier or = FAX”=A0=A0

 

Email is considered not secure and the SMTP transaction logs are not = legally valid in any jurisdiction I know of . =A0That’s the way it = is. =A0Don’t like it? =A0You go try and change the laws here. = =A0=A0

 

The number of industries that rely on fax are endless and it a = particularly important service in nation states where non roman = characters are used.=A0 Asia, =A0Middle East etc.=A0 =

 

That said ..do you really want to go down this road? Probably not = right now since the non repudiation issue is the one requirement I doubt = RTCWEB is prepared to address. However if the RTCWEB transaction = gateways into the Public SIP Network than its another issue. =

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Parthasarathi R
Sent: Monday, November 26, 2012 12:35 = PM
To: 'DRAGE, Keith (Keith)'; 'Bernard Aboba'; 'Stefan = H=E5kansson LK'
Cc: rtcweb@ietf.org
Subject: = [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line = philosophy (Re: Wisdom sought: Prioritization of = codecs))]

 

Hi all,

 

There is a long discussion in MMUSIC whether Fax usecase has to be = added in RTCWeb or not (http://www.ietf.org/mail-archive/web/mmusic/current/msg09939.html).=

 

I’m forwarding this mail to this WG to see the actual interest = for fax usecase.

 

Thanks

Partha

 

 

Be= careful to address this issue from a worldwide context rather than a = North America specific one.

 

Th= ere are still plenty of people raising fax issues from the Asian = countries.

 

Ke= ith

 

From:= = mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 25 November 2012 = 19:44
To: Stefan H=E5kansson LK
Cc: mmusic@ietf.org
Subject: = Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: = Prioritization of codecs))

 

Stefan = said:

> I don't think this = goes for fax, I think fax these days is only used by
> certain = (few) organizations and only for certain types of communication.
> =
> But if you think differently, please make a proposal on the = rtcweb mail list!

[BA]  Given the steep decline in = landlines, POTS is on the road to becoming economically non-viable by = the end of the decade, if not sooner.   Once POTS shuts down, the = legal and regulatory requirements which prop up the use of fax will need = to be re-thought.  IMHO given the bleak future of fax, supporting = it in WebRTC is not worth the effort.

BTW, support for RFC 4733 = (DTMF) is now required in draft-ietf-rtcweb-audio-01 instead of  = RFC 4734 (Fax, Modem and Text Telephony) which was cited (mistakenly) in = -00.  

Bernard "Spent several hours debugging T.38 = last week" = Aboba

------=_NextPart_000_017D_01CDCBFC.33488440-- From bernard_aboba@hotmail.com Mon Nov 26 14:49:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C7221F8548 for ; Mon, 26 Nov 2012 14:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 jrFImxA5yheD for ; Mon, 26 Nov 2012 14:49:54 -0800 (PST) Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAB021F8542 for ; Mon, 26 Nov 2012 14:49:53 -0800 (PST) Received: from BLU002-W189 ([65.55.116.74]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Nov 2012 14:49:53 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_579aa960-c1b0-4057-adf2-a90fb25c6065_" X-Originating-IP: [131.107.0.112] From: Bernard Aboba To: Richard Shockey Date: Mon, 26 Nov 2012 14:49:53 -0800 Importance: Normal In-Reply-To: <017c01cdcc26$1c1e8c40$545ba4c0$@us> References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>, <000601cdc996$ea6c0ec0$bf442c40$@co.in>, <50B266C5.90902@ericsson.com> <000301cdcbfc$604f4fa0$20edeee0$@co.in>, <017c01cdcc26$1c1e8c40$545ba4c0$@us> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2012 22:49:53.0092 (UTC) FILETIME=[59338840:01CDCC28] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Nov 2012 22:49:54 -0000 --_579aa960-c1b0-4057-adf2-a90fb25c6065_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard said: "Probably not right now since the non repudiation issue is the one requirem= ent I doubt RTCWEB is prepared to address. However if the RTCWEB transactio= n gateways into the Public SIP Network than its another issue." [BA] Excellent point. Converting an incoming fax to TIFF/JPEG/PDF for disp= lay on the Web or email is a useful feature=2C but those converted files wi= ll not be admissable. Similarly=2C writing a Web application to send faxes= from an uploaded file is also useful (and is doable without WebRTC)=2C but= the uploaded file also will not be admissable (though the received fax mig= ht be). Given this=2C it is not even clear to me that implementing T.38 in= the browser would actually help=2C because the received fax would need to = be digitally stored and displayed in some way=2C and once the conversion is= done=2C the non-repudiation property is lost. = --_579aa960-c1b0-4057-adf2-a90fb25c6065_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Richard said:

"Probably not right now since the non repudia= tion issue is the one requirement I doubt RTCWEB is prepared to address. Ho= wever if the RTCWEB transaction gateways into the Public SIP Network than i= ts another issue."

[BA] Excellent point. =3B Converting a= n incoming fax to TIFF/JPEG/PDF for display on the Web or email is a useful= feature=2C but those converted files will not be admissable. =3B Simil= arly=2C writing a Web application to send faxes from an uploaded file is al= so useful (and is doable without WebRTC)=2C but the uploaded file also will= not be admissable (though the received fax might be). =3B Given this= =2C it is not even clear to me that implementing T.38 in the browser would = actually help=2C because the received fax would need to be digitally stored= and displayed in some way=2C and once the conversion is done=2C the non-re= pudiation property is lost.
= --_579aa960-c1b0-4057-adf2-a90fb25c6065_-- From worley@shell01.TheWorld.com Mon Nov 26 15:02:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E13021F8541 for ; Mon, 26 Nov 2012 15:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[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 PsNvtBRC9p3Q for ; Mon, 26 Nov 2012 15:02:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0527121F84F2 for ; Mon, 26 Nov 2012 15:02:02 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qAQN1sAB012930 for ; Mon, 26 Nov 2012 18:01:56 -0500 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qAQN1sC31823106 for ; Mon, 26 Nov 2012 18:01:54 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qAQN1sC21812811; Mon, 26 Nov 2012 18:01:54 -0500 (EST) Date: Mon, 26 Nov 2012 18:01:54 -0500 (EST) Message-Id: <201211262301.qAQN1sC21812811@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <017c01cdcc26$1c1e8c40$545ba4c0$@us> (richard@shockey.us) References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>, <000601cdc996$ea6c0ec0$bf442c40$@co.in>, <50B266C5.90902@ericsson.com> <000301cdcbfc$604f4fa0$20edeee0$@co.in> <017c01cdcc26$1c1e8c40$545ba4c0$@us> Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Nov 2012 23:02:03 -0000 My experience is that fax is still used heavily, even over VoIP, especially in the legal world. Over PSTN, fax provides non-repudiation, and that isn't as easy to provide in a VoIP or WebRTC context. But I think other factors are important: - Unlike e-mail, fax provides real-time end-to-end confirmation to the sender that the receiver's device received the document. - Fax duplicates the structure of paper documents, with which users are extremely familar. In particular, fax images can include signature images. Of course, signature images are trivially easy to forge, but in most legal disputes, forgery is not a question, but instead, "deliberation" is -- Did the party formally consent to the document? Due to the immense cultural history of signatures, every party can generally assume that every other party has the same understanding of what affixing a signature implies. Based on these considerations, I expect fax to be an important form of communications for several more decades. Dale From ssokol@digium.com Mon Nov 26 15:56:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C791221F84DC for ; Mon, 26 Nov 2012 15:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 OLbYPT5hlxXv for ; Mon, 26 Nov 2012 15:56:44 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B60921F84D9 for ; Mon, 26 Nov 2012 15:56:43 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Td8XV-0007vX-Dx; Mon, 26 Nov 2012 17:56:37 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 60564D887B; Mon, 26 Nov 2012 17:56:37 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxV32kS9FJeV; Mon, 26 Nov 2012 17:56:36 -0600 (CST) Received: from zimbra.hsv.digium.com (zimbra.hsv.digium.com [10.24.55.203]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 6EF8FD8002; Mon, 26 Nov 2012 17:56:36 -0600 (CST) Date: Mon, 26 Nov 2012 17:56:36 -0600 (CST) From: Steve Sokol To: Richard Shockey Message-ID: In-Reply-To: <017c01cdcc26$1c1e8c40$545ba4c0$@us> Content-Type: multipart/alternative; boundary="=_ac2e9128-4296-4359-b4a8-08faa4de0a61" MIME-Version: 1.0 X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - GC23 (Mac)/7.1.3_GA_3346) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Nov 2012 23:56:46 -0000 --=_ac2e9128-4296-4359-b4a8-08faa4de0a61 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You describe fax as a "significant real time PSTN service" and you mention = that the reason fax is considered sacrosanct is, in part, the chain of cust= ody that carrier records represent. Since RTCWEB !=3D PSTN and since there = is no regulated entity charged with generating and retaining transactional = records for WebRTC sessions, I don't see how any kind of fax solution built= into/on RTCWEB would be "Fax" in the legal sense. More importantly, the entire RTCWEB/WebRTC project is focused on defining t= he future of communications. One of the greatest failings of every VoIP tec= hnology up to this point has been the tendency to recreate the PSTN rather = than defining an new paradigm. H.323 was PSTN-over-IP-v1.0. SIP has become = PSTN-over-IP-v2.0. Please don't distract us from building the future by req= uiring that we re-create the past. By actively deciding to not incorporate fax into any future protocol, we ma= y help drive the "right" fix this problem: changes in legislation, improvem= ents in authentication and encryption in email, or some other approach. ----- Original Message ----- > Well first .. fax is a globally significant real time PSTN service > that is NOT going away any time soon no matter what anyone in the > IETF thinks. In fact some of the current market statistics indicate > low single digit growth in the service irrespective of the decline > in landlines. > As Bernard correctly points out a good portion of the FAX traffic is > generated by national regulatory requirements and the fact that the > transaction cannot be repudiated since the call records kept by the > carrier are considered legally valid. =E2=80=9CAll contract submissions m= ust > be delivered by close of business XXX EST either by currier or FAX=E2=80= =9D > Email is considered not secure and the SMTP transaction logs are not > legally valid in any jurisdiction I know of . That=E2=80=99s the way it i= s. > Don=E2=80=99t like it? You go try and change the laws here. > The number of industries that rely on fax are endless and it a > particularly important service in nation states where non roman > characters are used. Asia, Middle East etc. > That said ..do you really want to go down this road? Probably not > right now since the non repudiation issue is the one requirement I > doubt RTCWEB is prepared to address. However if the RTCWEB > transaction gateways into the Public SIP Network than its another > issue. > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Parthasarathi R > Sent: Monday, November 26, 2012 12:35 PM > To: 'DRAGE, Keith (Keith)'; 'Bernard Aboba'; 'Stefan H=C3=A5kansson LK' > Cc: rtcweb@ietf.org > Subject: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: > M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] > Hi all, > There is a long discussion in MMUSIC whether Fax usecase has to be > added in RTCWeb or not ( > http://www.ietf.org/mail-archive/web/mmusic/current/msg09939.html ). > I=E2=80=99m forwarding this mail to this WG to see the actual interest fo= r > fax usecase. > Thanks > Partha > From: mmusic-bounces@ietf.org [ mailto:mmusic-bounces@ietf.org ] On > Behalf Of DRAGE, Keith (Keith) > Sent: Monday, November 26, 2012 3:26 PM > To: Bernard Aboba; Stefan H=C3=A5kansson LK > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: > Prioritization of codecs)) > Be careful to address this issue from a worldwide context rather than > a North America specific one. > There are still plenty of people raising fax issues from the Asian > countries. > Keith > From: mmusic-bounces@ietf.org [ mailto:mmusic-bounces@ietf.org ] On > Behalf Of Bernard Aboba > Sent: 25 November 2012 19:44 > To: Stefan H=C3=A5kansson LK > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: > Prioritization of codecs)) > Stefan said: > > I don't think this goes for fax, I think fax these days is only > > used by > > certain (few) organizations and only for certain types of > > communication. > > > > But if you think differently, please make a proposal on the rtcweb > > mail list! > [BA] Given the steep decline in landlines, POTS is on the road to > becoming economically non-viable by the end of the decade, if not > sooner. Once POTS shuts down, the legal and regulatory requirements > which prop up the use of fax will need to be re-thought. IMHO given > the bleak future of fax, supporting it in WebRTC is not worth the > effort. > BTW, support for RFC 4733 (DTMF) is now required in > draft-ietf-rtcweb-audio-01 instead of RFC 4734 (Fax, Modem and Text > Telephony) which was cited (mistakenly) in -00. > Bernard "Spent several hours debugging T.38 last week" Aboba > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=_ac2e9128-4296-4359-b4a8-08faa4de0a61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 12pt; colo= r: #000000'>
You describe fax as a "significant real time PSTN service"= and you mention that the reason fax is considered sacrosanct is, in part, = the chain of custody that carrier records represent. Since RTCWEB !=3D PSTN= and since there is no regulated entity charged with generating and retaini= ng transactional records for WebRTC sessions, I don't see how any kind of f= ax solution built into/on RTCWEB would be "Fax" in the legal sense.

More importantly, the entire RTCWEB/WebRTC project is foc= used on defining the future of communications. One of the greatest failings= of every VoIP technology up to this point has been the tendency to recreat= e the PSTN rather than defining an new paradigm. H.323 was PSTN-over-IP-v1.= 0. SIP has become PSTN-over-IP-v2.0. Please don't distract us from building= the future by requiring that we re-create the past.

By actively deciding to not incorporate fax into any future protocol= , we may help drive the "right" fix this problem: changes in legislation, i= mprovements in authentication and encryption in email, or some other approa= ch.

W= ell first .. fax is a globally significant real time PSTN service that is N= OT going away any time soon no matter what anyone in the IETF thinks. =   In fact some of the current market statistics indicate low single di= git growth in the service irrespective of the decline in landlines.

 

As Bernard correctly p= oints out a good portion of the FAX traffic is generated by national regula= tory requirements and the fact that the transaction cannot be repudiated si= nce the call records kept by the carrier are considered legally valid. = ; =E2=80=9CAll contract submissions must be delivered by close of business = XXX EST either by currier or FAX=E2=80=9D  

 

Email is considered not secure and t= he SMTP transaction logs are not legally valid in any jurisdiction I know o= f .  That=E2=80=99s the way it is.  Don=E2=80=99t like it?  = You go try and change the laws here.   

 

The number of industries that rely on fax= are endless and it a particularly important service in nation states where= non roman characters are used.  Asia,  Middle East etc. 

 

That said ..do yo= u really want to go down this road? Probably not right now since the non re= pudiation issue is the one requirement I doubt RTCWEB is prepared to addres= s. However if the RTCWEB transaction gateways into the Public SIP Network t= han its another issue.

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounc= es@ietf.org] On Behalf Of Parthasarathi R
Sent: Monday, No= vember 26, 2012 12:35 PM
To: 'DRAGE, Keith (Keith)'; 'Bernard Abo= ba'; 'Stefan H=C3=A5kansson LK'
Cc: rtcweb@ietf.org
Subject= : [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line phi= losophy (Re: Wisdom sought: Prioritization of codecs))]

 

Hi all,

 

There is a long discussion in M= MUSIC whether Fax usecase has to be added in RTCWeb or not (http://www.ietf.org/mail-archive/web/mmusic/current/msg09939.html= ).

 

I=E2=80=99m = forwarding this mail to this WG to see the actual interest for fax usecase.=

 

Thanks

Partha

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of DRAGE, Keith (Keith)
Sent: Monday, November 26, 201= 2 3:26 PM
To: Bernard Aboba; Stefan H=C3=A5kansson LK
Cc: mmusic@ietf.org=
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom so= ught: Prioritization of codecs))

&nbs= p;

Be careful to address this issue from a worldw= ide context rather than a North America specific one.

 

There are still plenty of people rais= ing fax issues from the Asian countries.

 

Keith

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bo= unces@ietf.org] On Behalf Of Bernard Aboba
Sent: 25 No= vember 2012 19:44
To: Stefan H=C3=A5kansson LK
Cc: mmusic@ietf.org
= Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: P= rioritization of codecs))

 

Stefan said:

> I don= 't think this goes for fax, I think fax these days is only used by
>= certain (few) organizations and only for certain types of communication.>
> But if you think differently, please make a proposal on the= rtcweb mail list!

[BA]  Given the steep decline in landlines, = POTS is on the road to becoming economically non-viable by the end of the d= ecade, if not sooner.   Once POTS shuts down, the legal and regulatory= requirements which prop up the use of fax will need to be re-thought. = ; IMHO given the bleak future of fax, supporting it in WebRTC is not worth = the effort.

BTW, support for RFC 4733 (DTMF) is now required in dra= ft-ietf-rtcweb-audio-01 instead of  RFC 4734 (Fax, Modem and Text Tele= phony) which was cited (mistakenly) in -00.  

Bernard "Spent s= everal hours debugging T.38 last week" Aboba

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

--=_ac2e9128-4296-4359-b4a8-08faa4de0a61-- From roman@telurix.com Mon Nov 26 16:35:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E1821F84D5 for ; Mon, 26 Nov 2012 16:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2zemeF03WbA for ; Mon, 26 Nov 2012 16:35:29 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9683A21F84D2 for ; Mon, 26 Nov 2012 16:35:29 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2370803dae.31 for ; Mon, 26 Nov 2012 16:35:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=O7da8msbDypnmf1Bc1Du75/YqAAYau/rnnrdsy2et3Y=; b=NplZ1W2T4JiZyIT6ogwKS9ZWkx9MzcHQZCU7FeHuQzd3mOWyzc7vFJsPfDQedZ02DZ +ec27c+hXV+K5jRn4xandqB8tEggICnWxO7NH6enTMpxhmX+TgOoNSb0j3NOtz+Jo0WW zFEYURv5pI0YEsivXmkfBWvQ8qUgfOzlcTSeHiOSDmd+7YMcISIxN/ynNyopqCR5l2TX 7NXMjvLWMee3CJZ+YP20TUZsZOHgZTL+1SbOTAYXpqL/TaJ9ZJeJb+/2Q42KmQDnMG8T fGKXyQbDIt5mmGdnK26Tb7G0qpYK/7ox1Eft6oozA7HZ3+CPcKD4mIUb0ciZ3ICNNojL KeZg== Received: by 10.68.137.198 with SMTP id qk6mr42653562pbb.60.1353976529300; Mon, 26 Nov 2012 16:35:29 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id sg7sm9569650pbb.50.2012.11.26.16.35.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 16:35:28 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so8218557pbc.31 for ; Mon, 26 Nov 2012 16:35:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.189.102 with SMTP id gh6mr42587593pbc.37.1353976528107; Mon, 26 Nov 2012 16:35:28 -0800 (PST) Received: by 10.68.42.8 with HTTP; Mon, 26 Nov 2012 16:35:27 -0800 (PST) In-Reply-To: References: <017c01cdcc26$1c1e8c40$545ba4c0$@us> Date: Mon, 26 Nov 2012 19:35:28 -0500 Message-ID: From: Roman Shpount To: Steve Sokol Content-Type: multipart/alternative; boundary=e89a8ff1bfb0fdf98904cf6f3938 X-Gm-Message-State: ALoCoQnzW7ogWoWGr0lVqw2Nq5QTfZEH3DsIU2BfltbEmbcdH4SBRxS0ZaxWCLQHRJi5OU8owL+c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Nov 2012 00:35:31 -0000 --e89a8ff1bfb0fdf98904cf6f3938 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Totally agree with Steve. I do not understand why we need T.38 fax. In the worst case send fax as an image over a datachannel or a simple POST to the server. For all practical purposes this would be no different then T.37 fax transmission. T.38 fax is complicated, unreliable, and should not exist for anything except legacy interop, which would be much better served by some sort of gateway. We would really complicated WebRTC code base by a feature that has no real use case. _____________ Roman Shpount On Mon, Nov 26, 2012 at 6:56 PM, Steve Sokol wrote: > You describe fax as a "significant real time PSTN service" and you mentio= n > that the reason fax is considered sacrosanct is, in part, the chain of > custody that carrier records represent. Since RTCWEB !=3D PSTN and since > there is no regulated entity charged with generating and retaining > transactional records for WebRTC sessions, I don't see how any kind of fa= x > solution built into/on RTCWEB would be "Fax" in the legal sense. > > More importantly, the entire RTCWEB/WebRTC project is focused on defining > the future of communications. One of the greatest failings of every VoIP > technology up to this point has been the tendency to recreate the PSTN > rather than defining an new paradigm. H.323 was PSTN-over-IP-v1.0. SIP ha= s > become PSTN-over-IP-v2.0. Please don't distract us from building the futu= re > by requiring that we re-create the past. > > By actively deciding to not incorporate fax into any future protocol, we > may help drive the "right" fix this problem: changes in legislation, > improvements in authentication and encryption in email, or some other > approach. > > ------------------------------ > > Well first .. fax is a globally significant real time PSTN service that i= s > NOT going away any time soon no matter what anyone in the IETF thinks. = In > fact some of the current market statistics indicate low single digit grow= th > in the service irrespective of the decline in landlines. > > > > As Bernard correctly points out a good portion of the FAX traffic is > generated by national regulatory requirements and the fact that the > transaction cannot be repudiated since the call records kept by the carri= er > are considered legally valid. =93All contract submissions must be delive= red > by close of business XXX EST either by currier or FAX=94 > > > > Email is considered not secure and the SMTP transaction logs are not > legally valid in any jurisdiction I know of . That=92s the way it is. D= on=92t > like it? You go try and change the laws here. > > > > The number of industries that rely on fax are endless and it a > particularly important service in nation states where non roman character= s > are used. Asia, Middle East etc. > > > > That said ..do you really want to go down this road? Probably not right > now since the non repudiation issue is the one requirement I doubt RTCWEB > is prepared to address. However if the RTCWEB transaction gateways into t= he > Public SIP Network than its another issue. > > > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Parthasarathi R > *Sent:* Monday, November 26, 2012 12:35 PM > *To:* 'DRAGE, Keith (Keith)'; 'Bernard Aboba'; 'Stefan H=E5kansson LK' > *Cc:* rtcweb@ietf.org > *Subject:* [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: > M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] > > > > Hi all, > > > > There is a long discussion in MMUSIC whether Fax usecase has to be added > in RTCWeb or not ( > http://www.ietf.org/mail-archive/web/mmusic/current/msg09939.html). > > > > I=92m forwarding this mail to this WG to see the actual interest for fax > usecase. > > > > Thanks > > Partha > > > > *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > *On Behalf Of *DRAGE, Keith (Keith) > *Sent:* Monday, November 26, 2012 3:26 PM > *To:* Bernard Aboba; Stefan H=E5kansson LK > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: > Prioritization of codecs)) > > > > Be careful to address this issue from a worldwide context rather than a > North America specific one. > > > > There are still plenty of people raising fax issues from the Asian > countries. > > > > Keith > > > ------------------------------ > > *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > *On Behalf Of *Bernard Aboba > *Sent:* 25 November 2012 19:44 > *To:* Stefan H=E5kansson LK > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: > Prioritization of codecs)) > > > > Stefan said: > > > I don't think this goes for fax, I think fax these days is only used by > > certain (few) organizations and only for certain types of communication= . > > > > But if you think differently, please make a proposal on the rtcweb mail > list! > > [BA] Given the steep decline in landlines, POTS is on the road to > becoming economically non-viable by the end of the decade, if not sooner. > Once POTS shuts down, the legal and regulatory requirements which prop up > the use of fax will need to be re-thought. IMHO given the bleak future o= f > fax, supporting it in WebRTC is not worth the effort. > > BTW, support for RFC 4733 (DTMF) is now required in > draft-ietf-rtcweb-audio-01 instead of RFC 4734 (Fax, Modem and Text > Telephony) which was cited (mistakenly) in -00. > > Bernard "Spent several hours debugging T.38 last week" Aboba > > _______________________________________________ > 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 > > --e89a8ff1bfb0fdf98904cf6f3938 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Totally agree with Steve.

I do not understand why we nee= d T.38 fax. In the worst case send fax as an image over a datachannel or a = simple POST to the server. For all practical purposes this would be no diff= erent then T.37 fax transmission. T.38 fax is complicated, unreliable, and = should not exist for anything except legacy interop, which would be much be= tter served by some sort of gateway. We would really complicated WebRTC cod= e base by a feature that has no real use case.
_____________
Roman Shpount


On Mon, Nov 26, 2012 at 6:56 PM, Steve S= okol <ssokol@digium.com> wrote:
<= div>You describe fax as a "significant real time PSTN service" an= d you mention that the reason fax is considered sacrosanct is, in part, the= chain of custody that carrier records represent. Since RTCWEB !=3D PSTN an= d since there is no regulated entity charged with generating and retaining = transactional records for WebRTC sessions, I don't see how any kind of = fax solution built into/on RTCWEB would be "Fax" in the legal sen= se.

More importantly, the entire RTCWEB/WebRTC project is f= ocused on defining the future of communications. One of the greatest failin= gs of every VoIP technology up to this point has been the tendency to recre= ate the PSTN rather than defining an new paradigm. H.323 was PSTN-over-IP-v= 1.0. SIP has become PSTN-over-IP-v2.0. Please don't distract us from bu= ilding the future by requiring that we re-create the past.

By actively deciding to not incorporate fax into = any future protocol, we may help drive the "right" fix this probl= em: changes in legislation, improvements in authentication and encryption i= n email, or some other approach.

Well first .. fax is a globally significant real time PSTN service that is = NOT going away any time soon no matter what anyone in the IETF thinks.=A0= =A0 In fact some of the current market statistics indicate low single digit= growth in the service irrespective of the decline in landlines.

=A0

As Bernard correctly p= oints out a good portion of the FAX traffic is generated by national regula= tory requirements and the fact that the transaction cannot be repudiated si= nce the call records kept by the carrier are considered legally valid.=A0 = =93All contract submissions must be delivered by close of business XXX EST = either by currier or FAX=94=A0=A0

=A0

Email is considered no= t secure and the SMTP transaction logs are not legally valid in any jurisdi= ction I know of . =A0That=92s the way it is. =A0Don=92t like it? =A0You go = try and change the laws here. =A0=A0

=A0

The number of industri= es that rely on fax are endless and it a particularly important service in = nation states where non roman characters are used.=A0 Asia, =A0Middle East = etc.=A0

=A0

That said ..do you rea= lly want to go down this road? Probably not right now since the non repudia= tion issue is the one requirement I doubt RTCWEB is prepared to address. Ho= wever if the RTCWEB transaction gateways into the Public SIP Network than i= ts another issue.

=A0

From:= rtcweb-bounce= s@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Parthasarathi R Sent: Monday, November 26, 2012 12:35 PM
To: 'DRAGE, K= eith (Keith)'; 'Bernard Aboba'; 'Stefan H=E5kansson LK'=
Cc: rtcweb@= ietf.org
Subject: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: = M-line philosophy (Re: Wisdom sought: Prioritization of codecs))]

=

=A0

Hi all,

=A0

There is a long discussion in MMUSIC whether = Fax usecase has to be added in RTCWeb or not (http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg09939.html).

=A0

I=92m forwarding this = mail to this WG to see the actual interest for fax usecase.

=A0

Thanks

P= artha

=A0

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces= @ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Monday, November 26, 2012 3:26 PM
To: Bernard Aboba;= Stefan H=E5kansson LK
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re= : M-line philosophy (Re: Wisdom sought: Prioritization of codecs))

=A0

Be careful= to address this issue from a worldwide context rather than a North America= specific one.

=A0

Ther= e are still plenty of people raising fax issues from the Asian countries.

=A0

Keith

=A0

Fr= om: mmusic= -bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Ab= oba
Sent: 25 November 2012 19:44
To: Stefan H=E5kansson LK
= Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: W= isdom sought: Prioritization of codecs))

=A0

Stefan said= :

> I don't think this goes for fax, = I think fax these days is only used by
> certain (few) organizations= and only for certain types of communication.
>
> But if you think differently, please make a proposal on the r= tcweb mail list!

[BA]=A0 Given the steep decline in landlines, POTS = is on the road to becoming economically non-viable by the end of the decade= , if not sooner. =A0 Once POTS shuts down, the legal and regulatory require= ments which prop up the use of fax will need to be re-thought.=A0 IMHO give= n the bleak future of fax, supporting it in WebRTC is not worth the effort.=

BTW, support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-a= udio-01 instead of=A0 RFC 4734 (Fax, Modem and Text Telephony) which was ci= ted (mistakenly) in -00. =A0

Bernard "Spent several hours debu= gging T.38 last week" Aboba


_______________________________________________=
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


--e89a8ff1bfb0fdf98904cf6f3938-- From francois.audet@skype.net Mon Nov 26 19:09:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A0921F8422 for ; Mon, 26 Nov 2012 19:09:10 -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 mH6+OhsCtmi9 for ; Mon, 26 Nov 2012 19:09:09 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40921F841B for ; Mon, 26 Nov 2012 19:09:09 -0800 (PST) Received: from mail167-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 03:09:06 +0000 Received: from mail167-ch1 (localhost [127.0.0.1]) by mail167-ch1-R.bigfish.com (Postfix) with ESMTP id E7B9F1A01A3; Tue, 27 Nov 2012 03:09:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -12 X-BigFish: VS-12(zz98dI9371Ic89bhd6eahc85eh1432Id799h14ffI853kzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673hz2fh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631hbe3k8f2n1155h) Received-SPF: pass (mail167-ch1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=francois.audet@skype.net; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail167-ch1 (localhost.localdomain [127.0.0.1]) by mail167-ch1 (MessageSwitch) id 1353985743639200_23111; Tue, 27 Nov 2012 03:09:03 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail167-ch1.bigfish.com (Postfix) with ESMTP id 992C04600E5; Tue, 27 Nov 2012 03:09:03 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 03:09:00 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.149]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 27 Nov 2012 03:08:59 +0000 From: Francois Audet To: Roman Shpount Thread-Topic: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] Thread-Index: AQHNzDcfAb7j8ljnAkSGHF5JS8L24Jf9AKjB Date: Tue, 27 Nov 2012 03:08:59 +0000 Message-ID: <926732C8-C4FE-441B-AA7B-BE55F766569A@microsoft.com> References: <017c01cdcc26$1c1e8c40$545ba4c0$@us> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_926732C8C4FE441BAA7BBE55F766569Amicrosoftcom_" MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Nov 2012 03:09:11 -0000 --_000_926732C8C4FE441BAA7BBE55F766569Amicrosoftcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Fax on H.323 was ridiculous back then, even more so over SIP. Now, with RTC= webit's totally Steam Punk! Next stop Telegraph over rtcweb? On Nov 26, 2012, at 16:35, "Roman Shpount" > wrote: Totally agree with Steve. I do not understand why we need T.38 fax. In the worst case send fax as an = image over a datachannel or a simple POST to the server. For all practical = purposes this would be no different then T.37 fax transmission. T.38 fax is= complicated, unreliable, and should not exist for anything except legacy i= nterop, which would be much better served by some sort of gateway. We would= really complicated WebRTC code base by a feature that has no real use case= . _____________ Roman Shpount On Mon, Nov 26, 2012 at 6:56 PM, Steve Sokol > wrote: You describe fax as a "significant real time PSTN service" and you mention = that the reason fax is considered sacrosanct is, in part, the chain of cust= ody that carrier records represent. Since RTCWEB !=3D PSTN and since there = is no regulated entity charged with generating and retaining transactional = records for WebRTC sessions, I don't see how any kind of fax solution built= into/on RTCWEB would be "Fax" in the legal sense. More importantly, the entire RTCWEB/WebRTC project is focused on defining t= he future of communications. One of the greatest failings of every VoIP tec= hnology up to this point has been the tendency to recreate the PSTN rather = than defining an new paradigm. H.323 was PSTN-over-IP-v1.0. SIP has become = PSTN-over-IP-v2.0. Please don't distract us from building the future by req= uiring that we re-create the past. By actively deciding to not incorporate fax into any future protocol, we ma= y help drive the "right" fix this problem: changes in legislation, improvem= ents in authentication and encryption in email, or some other approach. ________________________________ Well first .. fax is a globally significant real time PSTN service that is = NOT going away any time soon no matter what anyone in the IETF thinks. In= fact some of the current market statistics indicate low single digit growt= h in the service irrespective of the decline in landlines. As Bernard correctly points out a good portion of the FAX traffic is genera= ted by national regulatory requirements and the fact that the transaction c= annot be repudiated since the call records kept by the carrier are consider= ed legally valid. =93All contract submissions must be delivered by close o= f business XXX EST either by currier or FAX=94 Email is considered not secure and the SMTP transaction logs are not legall= y valid in any jurisdiction I know of . That=92s the way it is. Don=92t l= ike it? You go try and change the laws here. The number of industries that rely on fax are endless and it a particularly= important service in nation states where non roman characters are used. A= sia, Middle East etc. That said ..do you really want to go down this road? Probably not right now= since the non repudiation issue is the one requirement I doubt RTCWEB is p= repared to address. However if the RTCWEB transaction gateways into the Pub= lic SIP Network than its another issue. From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Parthasara= thi R Sent: Monday, November 26, 2012 12:35 PM To: 'DRAGE, Keith (Keith)'; 'Bernard Aboba'; 'Stefan H=E5kansson LK' Cc: rtcweb@ietf.org Subject: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line = philosophy (Re: Wisdom sought: Prioritization of codecs))] Hi all, There is a long discussion in MMUSIC whether Fax usecase has to be added in= RTCWeb or not (http://www.ietf.org/mail-archive/web/mmusic/current/msg0993= 9.html). I=92m forwarding this mail to this WG to see the actual interest for fax us= ecase. Thanks Partha From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Monday, November 26, 2012 3:26 PM To: Bernard Aboba; Stefan H=E5kansson LK Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prior= itization of codecs)) Be careful to address this issue from a worldwide context rather than a Nor= th America specific one. There are still plenty of people raising fax issues from the Asian countrie= s. Keith ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: 25 November 2012 19:44 To: Stefan H=E5kansson LK Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prior= itization of codecs)) Stefan said: > I don't think this goes for fax, I think fax these days is only used by > certain (few) organizations and only for certain types of communication. > > But if you think differently, please make a proposal on the rtcweb mail l= ist! [BA] Given the steep decline in landlines, POTS is on the road to becoming= economically non-viable by the end of the decade, if not sooner. Once PO= TS shuts down, the legal and regulatory requirements which prop up the use = of fax will need to be re-thought. IMHO given the bleak future of fax, sup= porting it in WebRTC is not worth the effort. BTW, support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-audio= -01 instead of RFC 4734 (Fax, Modem and Text Telephony) which was cited (m= istakenly) in -00. Bernard "Spent several hours debugging T.38 last week" Aboba _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_926732C8C4FE441BAA7BBE55F766569Amicrosoftcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Fax on H.323 was ridiculous back then, even more so over SIP. Now, wit= h RTCwebit's totally Steam Punk! Next stop Telegraph over rtcweb?

On Nov 26, 2012, at 16:35, "Roman Shpount" <roman@telurix.com> wrote:

Totally agree with Steve.

I do not understand why we need T.38 fax. In the worst case send fax a= s an image over a datachannel or a simple POST to the server. For all pract= ical purposes this would be no different then T.37 fax transmission. T.38 f= ax is complicated, unreliable, and should not exist for anything except legacy interop, which would be much b= etter served by some sort of gateway. We would really complicated WebRTC co= de base by a feature that has no real use case.
_____________
Roman Shpount


On Mon, Nov 26, 2012 at 6:56 PM, Steve Sokol <ssokol@digium.co= m> wrote:
You describe fax as a "significant real time PSTN service" a= nd you mention that the reason fax is considered sacrosanct is, in part, th= e chain of custody that carrier records represent. Since RTCWEB !=3D PSTN a= nd since there is no regulated entity charged with generating and retaining transactional records for WebRTC sessions, I= don't see how any kind of fax solution built into/on RTCWEB would be "= ;Fax" in the legal sense.

More importantly, the entire RTCWEB/WebRTC project is focused on defin= ing the future of communications. One of the greatest failings of every VoI= P technology up to this point has been the tendency to recreate the PSTN ra= ther than defining an new paradigm. H.323 was PSTN-over-IP-v1.0. SIP has become PSTN-over-IP-v2.0. Please don'= t distract us from building the future by requiring that we re-create the p= ast.

By actively deciding to not incorporate fax into any future protocol, = we may help drive the "right" fix this problem: changes in legisl= ation, improvements in authentication and encryption in email, or some othe= r approach.

Well first .. fax is a globally significant real tim= e PSTN service that is NOT going away any time soon no matter what anyone i= n the IETF thinks.   In fact some of the current market statistic= s indicate low single digit growth in the service irrespective of the decline in landlines.

 

As Bernard correctly points out a good portion of th= e FAX traffic is generated by national regulatory requirements and the fact= that the transaction cannot be repudiated since the call records kept by t= he carrier are considered legally valid.  =93All contract submissions must be delivered by close of bus= iness XXX EST either by currier or FAX=94  

 

Email is considered not secure and the SMTP transact= ion logs are not legally valid in any jurisdiction I know of .  That= =92s the way it is.  Don=92t like it?  You go try and change the = laws here.   

 

The number of industries that rely on fax are endles= s and it a particularly important service in nation states where non roman = characters are used.  Asia,  Middle East etc. 

 

That said ..do you really want to go down this road?= Probably not right now since the non repudiation issue is the one requirem= ent I doubt RTCWEB is prepared to address. However if the RTCWEB transactio= n gateways into the Public SIP Network than its another issue.

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Parthasarathi R
Sent: Monday, November 26, 2012 12:35 PM
To: 'DRAGE, Keith (Keith)'; 'Bernard Aboba'; 'Stefan H=E5kansson LK'=
Cc: rtcweb@ietf= .org
Subject: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: = M-line philosophy (Re: Wisdom sought: Prioritization of codecs))]

 

Hi all,

 

There is a long discussion in MMUSIC whether Fax use= case has to be added in RTCWeb or not (http://www.ietf= .org/mail-archive/web/mmusic/current/msg09939.html).

 

I=92m forwarding this mail to this WG to see the act= ual interest for fax usecase.

 

Thanks

Partha

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Monday, November 26, 2012 3:26 PM
To: Bernard Aboba; Stefan H=E5kansson LK
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought= : Prioritization of codecs))

 

Be careful to address this issue from a worldwide co= ntext rather than a North America specific one.

 

There are still plenty of people raising fax issues = from the Asian countries.

 

Keith

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 25 November 2012 19:44
To: Stefan H=E5kansson LK
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought= : Prioritization of codecs))

 

Stefan said:

> I don't think this goes for fax, I think fax th= ese days is only used by
> certain (few) organizations and only for certain types of communicatio= n.
>
> But if you think differently, please make a proposal on the rtcweb mai= l list!

[BA]  Given the steep decline in landlines, POTS is on the road to bec= oming economically non-viable by the end of the decade, if not sooner. &nbs= p; Once POTS shuts down, the legal and regulatory requirements which prop u= p the use of fax will need to be re-thought.  IMHO given the bleak future of fax, supporting it in WebRTC is not worth t= he effort.

BTW, support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-audio= -01 instead of  RFC 4734 (Fax, Modem and Text Telephony) which was cit= ed (mistakenly) in -00.  

Bernard "Spent several hours debugging T.38 last week" Aboba


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


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


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_926732C8C4FE441BAA7BBE55F766569Amicrosoftcom_-- From fluffy@cisco.com Mon Nov 26 20:28:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3BB21F85C3 for ; Mon, 26 Nov 2012 20:28:20 -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 4ehzUnCdkV3m for ; Mon, 26 Nov 2012 20:28:16 -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 2B50D21F8683 for ; Mon, 26 Nov 2012 20:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2142; q=dns/txt; s=iport; t=1353990496; x=1355200096; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XA3/Cl3az6stSEIKKFXbSCqQUYB/0AbaJDC6Bl6aG3E=; b=fWp7RxMNp7uQsu2SBNyJiNXl+R+ujSR8kAyE7WrKKvNfEgxoCaz5BSnc Rh0hAh6vaFu2JxWvJki2zih3uW4kc6eje9nnk55Ye2YT5hpfxQ/gxm+oK 1ARnuH9hbVOMx6L3oFC/TlSHZksiWJZdUG6JgAJAfu+oGPAvySh8GGyFQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIFABVAtFCtJXHA/2dsb2JhbABErViSUIEJgh4BAQEDAQEBAWsLBQsCAQgiGQsnCxwJAgQOBQiHcwMJBgyvbZA2BItOaQuDVWEDiCmMBI0IhRCCYg2BaBce X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146456542" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 27 Nov 2012 04:28:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAR4SBSV030121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 04:28:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 22:28:10 -0600 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] Thread-Index: AQHNzFeb1W5sywu/tUGKC94Fsvygyg== Date: Tue, 27 Nov 2012 04:28:10 +0000 Message-ID: References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>, <000601cdc996$ea6c0ec0$bf442c40$@co.in>, <50B266C5.90902@ericsson.com> <000301cdcbfc$604f4fa0$20edeee0$@co.in>, <017c01cdcc26$1c1e8c40$545ba4c0$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9BFC834F1650B24BBAB51A70F72B40A9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fax usecase in WebRTC [was FW: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Nov 2012 04:28:20 -0000 On Nov 26, 2012, at 15:49 , Bernard Aboba wrote= : > Richard said: >=20 > "Probably not right now since the non repudiation issue is the one requir= ement I doubt RTCWEB is prepared to address. However if the RTCWEB transact= ion gateways into the Public SIP Network than its another issue." >=20 > [BA] Excellent point. Converting an incoming fax to TIFF/JPEG/PDF for di= splay on the Web or email is a useful feature, but those converted files wi= ll not be admissable. Similarly, writing a Web application to send faxes f= rom an uploaded file is also useful (and is doable without WebRTC), but the= uploaded file also will not be admissable (though the received fax might b= e). Given this, it is not even clear to me that implementing T.38 in the b= rowser would actually help, because the received fax would need to be digit= ally stored and displayed in some way, and once the conversion is done, the= non-repudiation property is lost. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb I think this is arguing that T.37 fax is not admissible and T.38 is admissi= ble. Can anyone point at any case law to support that?=20 I would like to point out that fax is not a real time problem and thus may = not need all the optimizations of making it work browser to browser. Legacy= fax gets stored and buffered in all kinds of ways and no one notices. I al= ready read my faxes in a browser, and with GetUserMedia, I think I could wr= ite a web page that could send faxes too from my camera. Yes, the fax would= go through the web server, but since it is not a real time applications, t= hat seems like it might be OK.=20 I do believe that faxes will be around for a long time to come - the idea h= as been around for a long time. See the Bain patent from 169 years ago whic= h describes a fax machine.=20 My experience has been that VoIP fax deployments that use G.711 and mark it= voice band data have higher success rate for faxes that deployments that u= se T.38.=20 From worley@shell01.TheWorld.com Wed Nov 28 13:46:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F0521F84BB for ; Wed, 28 Nov 2012 13:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_81=0.6, 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 ZH6xkl4zrDkb for ; Wed, 28 Nov 2012 13:46:02 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40421F847B for ; Wed, 28 Nov 2012 13:46:02 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qASLjbVY005810 for ; Wed, 28 Nov 2012 16:45:39 -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 qASLjaNv1956104 for ; Wed, 28 Nov 2012 16:45:37 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qASLjanB1955372; Wed, 28 Nov 2012 16:45:36 -0500 (EST) Date: Wed, 28 Nov 2012 16:45:36 -0500 (EST) Message-Id: <201211282145.qASLjanB1955372@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <50A13860.8050900@omnitor.se> (gunnar.hellstrom@omnitor.se) References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Nov 2012 21:46:03 -0000 Catching up on various messages: > From: Igor Faynberg > > In this case, would that mean that when I type something and then want > to correct it, backspaces would be transmitted, too? If so, I doubt it > is useful. The second case, with the user having control over sending > of the message, is much better. There are possibilities for embarrassment with real-time text, in that you don't have time to reconsider your words between typing them and hitting RETURN (which would send them in a message-oriented text system). One response to this is that a similar possibility exists in voice/video communication. And one can always configure one's RTT system to delay sending text until it sees a RETURN. > From: Gunnar HellstrC6m > > The need for synchronization with audio and video is very relaxed for RTT. > I would assume that a second out of synch is easily accepted. > > The one second end-to-end latency is probably slightly more demanding, > even if it also easy compared to audio and video requirements. > > Since RTT is already available on RTP in RFC 4103 with presentation > according to T.140, it is tempting to use it. Just moving to AVPF. > > It is lightweight with time sampled transmission every 300 ms, and there > is reliability included. > So, if SDP interchange is specified now, ( where?) RTT can be easily be > adopted. The relevant RFCs seem to be: RFC 5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) This shows an example SDP, using the text/t140 media type for encoding the text and the text/red media type for providing reliability: m=text 11000 RTP/AVP 100 98 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98/98 This RFC seems to be the technology/policy statement by the deaf/RTT people (especially van Wijk). RFC 4103 RTP Payload for Text Conversation This gives the text/t140 format. RFC 4102 Registration of the text/red MIME Sub-Type RFC 2198 RTP Payload for Redundant Audio Data These give the text/red redundancy format. > From: Randell Jesup > > Well, the MediaStreams don't support any track types (currently) other > than video and audio. While possible, doing so would be a significant > amount of work. It shouldn't be much work unless the media-type-independent part of MediaStreams isn't cleanly separated from the media-type-dependent part. It should be just a matter of providing another subclass of MediaStreams. > The SDP would support T140, but the codebases of the two existing > primary implementations does not currently. We either implement it in the browsers or everybody gets to implement it in Javascript. > My suggestion is instead of trying to jam an existing hack to "run a > reliable protocol over an unreliable channel" into the implementations, > to instead define running a well-known reliable-channel text protocol > over a reliable DataChannel (or unreliable, if that makes more sense). Yes, text/red is a hack. But it's already used in the RTT world. (More about that below.) > From: "Richard Shockey" > > ... you can delay the discussion but not the requirement. The > regulators will insist on this. > > http://transition.fcc.gov/cgb/dro/cvaa.html > > http://europa.eu/legislation_summaries/information_society/legislative_frame > work/l24216a_en.htm Richard gets back to an important issue -- T.140-based RTT is being heavily lobbied for and gradually imposed by telephony regulators. The result is that any SIP systems we want to interoperate with will soon be using text/t140 and text/red. And note that in enterprise deployments, the WebRTC function of the server will generally be a gateway into the existing SIP-based call center systems. Within that context, the question is how to gateway SIP RTT into WebRTC. Of course, we could carry the RTT over a datastream. Or we could have the browser implement RTT in RTP and allow the RTP to bypass the gateway device, as it does with audio and video media. Since the RTT data stream has a lower bit rate and looser timing requirements than audio or video, it could probably be handled as a datastream by Javascript. But it seems to me that implementing it "natively" in the browser's WebRTC handling has advantages: - Because there is only one implementation per browser, there is less total implementation effort and the average implementation is more likely to work well. It will also have a consistent UI if the user uses the same browser with multiple web sites. - In my experience, though Javascript is supposed to be executed as a "soft real-time" process, browsers are not real-time at all. The UI of browsers often freezes for seconds at a time, and I suspect that Javascript execution is frozen as well. RTT handling is much more likely to actually be real-time if we put the UI-to-RTT-RTP code in the same module that handles the UI-to-audio-RTP and UI-to-video-RTP. Dale From keith.drage@alcatel-lucent.com Thu Nov 29 03:34:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9069B21F8826 for ; Thu, 29 Nov 2012 03:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.499 X-Spam-Level: X-Spam-Status: No, score=-109.499 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_81=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 FoG+nz0a0mrz for ; Thu, 29 Nov 2012 03:34:13 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 53EA621F87DA for ; Thu, 29 Nov 2012 03:34:13 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qATBXURD001618 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Nov 2012 12:33:53 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 29 Nov 2012 12:33:11 +0100 From: "DRAGE, Keith (Keith)" To: "Dale R. Worley" , "rtcweb@ietf.org" Date: Thu, 29 Nov 2012 12:33:08 +0100 Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3NsdmyY3n4229RQkqlaIgk5cZBWQAcwWZg Message-ID: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> In-Reply-To: <201211282145.qASLjanB1955372@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Nov 2012 11:34:16 -0000 > This RFC seems to be the technology/policy statement by the deaf/RTT > people (especially van Wijk). Not sure that is the most appropriate statement to make. RFC 5194 was a working group item of the sipping group, went through WGLC a= nd also IETF last call, and went to the IESG. That normally is taken to mea= n the document has IETF consensus. Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Dale R. Worley > Sent: 28 November 2012 21:46 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions >=20 > Catching up on various messages: >=20 > > From: Igor Faynberg > > >=20 > > In this case, would that mean that when I type something and then want > > to correct it, backspaces would be transmitted, too? If so, I doubt it > > is useful. The second case, with the user having control over sending > > of the message, is much better. >=20 > There are possibilities for embarrassment with real-time text, in that > you don't have time to reconsider your words between typing them and > hitting RETURN (which would send them in a message-oriented text > system). >=20 > One response to this is that a similar possibility exists in > voice/video communication. And one can always configure one's RTT > system to delay sending text until it sees a RETURN. >=20 > > From: Gunnar HellstrC6m > > > > The need for synchronization with audio and video is very relaxed for > RTT. > > I would assume that a second out of synch is easily accepted. > > > > The one second end-to-end latency is probably slightly more demanding, > > even if it also easy compared to audio and video requirements. > > > > Since RTT is already available on RTP in RFC 4103 with presentation > > according to T.140, it is tempting to use it. Just moving to AVPF. > > > > It is lightweight with time sampled transmission every 300 ms, and ther= e > > is reliability included. > > So, if SDP interchange is specified now, ( where?) RTT can be easily b= e > > adopted. >=20 > The relevant RFCs seem to be: >=20 > RFC 5194 > Framework for Real-Time Text over IP Using the Session Initiation > Protocol (SIP) >=20 > This shows an example SDP, using the text/t140 media type for encoding > the text and the text/red media type for providing reliability: >=20 > m=3Dtext 11000 RTP/AVP 100 98 > a=3Drtpmap:98 t140/1000 > a=3Drtpmap:100 red/1000 > a=3Dfmtp:100 98/98/98 >=20 > This RFC seems to be the technology/policy statement by the deaf/RTT > people (especially van Wijk). >=20 > RFC 4103 > RTP Payload for Text Conversation >=20 > This gives the text/t140 format. >=20 > RFC 4102 > Registration of the text/red MIME Sub-Type > RFC 2198 > RTP Payload for Redundant Audio Data >=20 > These give the text/red redundancy format. >=20 > > From: Randell Jesup > > > > Well, the MediaStreams don't support any track types (currently) other > > than video and audio. While possible, doing so would be a significant > > amount of work. >=20 > It shouldn't be much work unless the media-type-independent part of > MediaStreams isn't cleanly separated from the media-type-dependent > part. It should be just a matter of providing another subclass of > MediaStreams. >=20 > > The SDP would support T140, but the codebases of the two existing > > primary implementations does not currently. >=20 > We either implement it in the browsers or everybody gets to implement > it in Javascript. >=20 > > My suggestion is instead of trying to jam an existing hack to "run a > > reliable protocol over an unreliable channel" into the implementations, > > to instead define running a well-known reliable-channel text protocol > > over a reliable DataChannel (or unreliable, if that makes more sense). >=20 > Yes, text/red is a hack. But it's already used in the RTT world. > (More about that below.) >=20 > > From: "Richard Shockey" > > > > ... you can delay the discussion but not the requirement. The > > regulators will insist on this. > > > > http://transition.fcc.gov/cgb/dro/cvaa.html > > > > > http://europa.eu/legislation_summaries/information_society/legislative_fr= a > me > > work/l24216a_en.htm >=20 > Richard gets back to an important issue -- T.140-based RTT is being > heavily lobbied for and gradually imposed by telephony regulators. > The result is that any SIP systems we want to interoperate with will > soon be using text/t140 and text/red. And note that in enterprise > deployments, the WebRTC function of the server will generally be a > gateway into the existing SIP-based call center systems. >=20 > Within that context, the question is how to gateway SIP RTT into > WebRTC. Of course, we could carry the RTT over a datastream. Or we > could have the browser implement RTT in RTP and allow the RTP to > bypass the gateway device, as it does with audio and video media. >=20 > Since the RTT data stream has a lower bit rate and looser timing > requirements than audio or video, it could probably be handled as a > datastream by Javascript. But it seems to me that implementing it > "natively" in the browser's WebRTC handling has advantages: >=20 > - Because there is only one implementation per browser, there is less > total implementation effort and the average implementation is more > likely to work well. It will also have a consistent UI if the user > uses the same browser with multiple web sites. >=20 > - In my experience, though Javascript is supposed to be executed as a > "soft real-time" process, browsers are not real-time at all. The UI > of browsers often freezes for seconds at a time, and I suspect that > Javascript execution is frozen as well. RTT handling is much more > likely to actually be real-time if we put the UI-to-RTT-RTP code in > the same module that handles the UI-to-audio-RTP and > UI-to-video-RTP. >=20 > Dale > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From worley@shell01.TheWorld.com Thu Nov 29 07:42:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9121F889A for ; Thu, 29 Nov 2012 07:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.625, 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 0PyOwngkQV08 for ; Thu, 29 Nov 2012 07:42:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE7E21F8A8F for ; Thu, 29 Nov 2012 07:42:02 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qATFfCcR013752 for ; Thu, 29 Nov 2012 10:41:15 -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 qATFfCN42015068 for ; Thu, 29 Nov 2012 10:41:12 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qATFfCLQ2019244; Thu, 29 Nov 2012 10:41:12 -0500 (EST) Date: Thu, 29 Nov 2012 10:41:12 -0500 (EST) Message-Id: <201211291541.qATFfCLQ2019244@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: (keith.drage@alcatel-lucent.com) References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Nov 2012 15:42:04 -0000 > From: "DRAGE, Keith (Keith)" > > > This RFC seems to be the technology/policy statement by the > > deaf/RTT > > people (especially van Wijk). > > Not sure that is the most appropriate statement to make. > > RFC 5194 was a working group item of the sipping group, went through > WGLC and also IETF last call, and went to the IESG. That normally is > taken to mean the document has IETF consensus. That's true. But the point I'm focusing on is not whether this particular approach has IETF support. Rather, my point is that the technological approach documented in this RFC has the intense support of a lobbying group of significant power. Because of this lobbying power, much of the implementation of RTT in the phone network *will* be done by this method, and WebRTC will work far better if we align it with that reality. In this particular case, the fact that the document is IETF-approved is not its most significant feature. Dale From randell-ietf@jesup.org Thu Nov 29 19:51:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ABC21F8914 for ; Thu, 29 Nov 2012 19:51:40 -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 YE2s6iShRdzW for ; Thu, 29 Nov 2012 19:51:39 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0F021F88E9 for ; Thu, 29 Nov 2012 19:51:37 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1539 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TeHdY-00043r-KW for rtcweb@ietf.org; Thu, 29 Nov 2012 21:51:36 -0600 Message-ID: <50B82D25.3030806@jesup.org> Date: Thu, 29 Nov 2012 22:51:01 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> In-Reply-To: <201211282145.qASLjanB1955372@shell01.TheWorld.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 03:51:50 -0000 On 11/28/2012 4:45 PM, Dale R. Worley wrote: > Catching up on various messages: > >> From: Igor Faynberg >> >> In this case, would that mean that when I type something and then want >> to correct it, backspaces would be transmitted, too? If so, I doubt it >> is useful. The second case, with the user having control over sending >> of the message, is much better. > There are possibilities for embarrassment with real-time text, in that > you don't have time to reconsider your words between typing them and > hitting RETURN (which would send them in a message-oriented text > system). I think the things I saw mandated the user be able to switch between immediate and cooked modes. >> From: Randell Jesup >> >> Well, the MediaStreams don't support any track types (currently) other >> than video and audio. While possible, doing so would be a significant >> amount of work. > It shouldn't be much work unless the media-type-independent part of > MediaStreams isn't cleanly separated from the media-type-dependent > part. It should be just a matter of providing another subclass of > MediaStreams. Not so simply; MediaStreams in Firefox currently have a strong idea that data has a time for display and a duration. This could be worked around, and might need to for other reasons - but there was no design goal for carrying non-media data in MediaStreams. >> The SDP would support T140, but the codebases of the two existing >> primary implementations does not currently. > We either implement it in the browsers or everybody gets to implement > it in Javascript. Yes, though likely there would be library or two. (Though those have their own issues, for sure.) >> My suggestion is instead of trying to jam an existing hack to "run a >> reliable protocol over an unreliable channel" into the implementations, >> to instead define running a well-known reliable-channel text protocol >> over a reliable DataChannel (or unreliable, if that makes more sense). > Yes, text/red is a hack. But it's already used in the RTT world. > (More about that below.) > >> From: "Richard Shockey" >> >> ... you can delay the discussion but not the requirement. The >> regulators will insist on this. >> >> http://transition.fcc.gov/cgb/dro/cvaa.html >> >> http://europa.eu/legislation_summaries/information_society/legislative_frame >> work/l24216a_en.htm > Richard gets back to an important issue -- T.140-based RTT is being > heavily lobbied for and gradually imposed by telephony regulators. > The result is that any SIP systems we want to interoperate with will > soon be using text/t140 and text/red. And note that in enterprise > deployments, the WebRTC function of the server will generally be a > gateway into the existing SIP-based call center systems. Agreed, this is a very important point. (Note: I've only read part of the items linked, and not with a clear head and a marker.) Even without connection to SIP systems, the onus to provide mandated accessibility features may exist anyways, though with the onus being on "equipment manufacturers" and on "service providers" (FCC definitions). Note that regulations now apply to "non-interconnected VoIP" applications - stuff that never touches the PSTN (this can include TeamSpeak (games), private non-PSTN networks (the old WorldGate videophone network), etc. Games companies are having to argue about how much of their revenues should be attributed to VoIP and thus how much they contribute to the fees and TRS/etc funds. Thus far they're exempting free services and those that can't be separated from other primary uses like in games. http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-151A1.pdf para 86: "If software gives the consumer the ability to send and receive e-mail, send and receive text messages, make non-interconnected VoIP calls, or otherwise engage in advanced communications, then provision of that software is provision of ACS.183 The provider of that software would be a covered entity, and the service, including any provided through a small-scale or large-scale peer-to-peer system, would be subject to the requirements of the statute.184 This is true regardless of whether the software is downloaded to the consumer’s equipment or accessed in the cloud." and in the normative ( ;-)) text: "(iii) Real-time text connectability. Products that provide a function allowing voice communication and which do not themselves provide real-time text functionality shall provide a standard non-acoustic connection point for a real-time text device. *[snip]* b. If the ACS connects to VoIP via SIP it shall use a RTT format that is supported by the largest number of products and systems or allow connection of a device that supports that format. i. Note: At this time, the only RTT format that is widely used on VoIP via SIP and the only one named in emergency standards and guidelines is RFC 4103. c. If the ACS connects to VoIP using any other transport standard it shall provide real-time text using the real-time text interoperability standard chosen for and supported by the largest number of products on that transport. So, since we don't use SIP directly, this would not *mandate* RFC 4103 - we can effectively define and choose a standard for WebRTC/JSEP. But they would mandate that "we" (really service providers providing the applications) have such a standard and provide it. And has been pointed out, demands to interoperate with SIP/RFC4103 would exist, and also E911 is likely to want to standardize on RFC4103 (and, for another problem, H.263 or H.264). But the E911 folk are still talking about it so far as I know. They may have done this to ameliorate Sorenson and their huge investment in H.323 equipment, or to accommodate other non-SIP messaging systems. The Emergency Advisory Committee has also published something covering this: http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-312161A1.doc > > Within that context, the question is how to gateway SIP RTT into > WebRTC. Of course, we could carry the RTT over a datastream. Or we > could have the browser implement RTT in RTP and allow the RTP to > bypass the gateway device, as it does with audio and video media. > > Since the RTT data stream has a lower bit rate and looser timing > requirements than audio or video, it could probably be handled as a > datastream by Javascript. But it seems to me that implementing it > "natively" in the browser's WebRTC handling has advantages: > > - Because there is only one implementation per browser, there is less > total implementation effort and the average implementation is more > likely to work well. It will also have a consistent UI if the user > uses the same browser with multiple web sites. I'll note that virtually nothing in webrtc, let alone rtcweb, really touches on UI - UI is generally (and almost must be) handled by the JS application. Assuming the UI is tied to the signaling and media components/hardware is the classic SIP hardware UA way to look at it (or SIP software application). We'd need to define a way to inject keystrokes into the stream, and get them out (and perhaps process them into a displayable string). In theory the W3C could define RTT display elements you could hook an RTT media track to; or it could be subsumed into existing audio/video media elements (though there's still the input side, and this might be unduly restrictive of possible applications layouts and uses). > - In my experience, though Javascript is supposed to be executed as a > "soft real-time" process, browsers are not real-time at all. The UI > of browsers often freezes for seconds at a time, and I suspect that > Javascript execution is frozen as well. RTT handling is much more > likely to actually be real-time if we put the UI-to-RTT-RTP code in > the same module that handles the UI-to-audio-RTP and > UI-to-video-RTP. Well, in some cases the browser may be busy. This could either be handled directly in the Audio/Video element (with downsides), or in a JS worker (though modifying the DOM isn't possible from there, so it really probably doesn't help you). It may be best to not try to sidestep the browser being busy, since that can cause anything to stall. -- Randell Jesup randell-ietf@jesup.org From gunnar.hellstrom@omnitor.se Fri Nov 30 00:17:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0B21F89BC for ; Fri, 30 Nov 2012 00:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnC2g0K+W+M9 for ; Fri, 30 Nov 2012 00:17:58 -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 0FD6521F89B5 for ; Fri, 30 Nov 2012 00:17:56 -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 ; Fri, 30 Nov 2012 09:17:48 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 43B423A04E for ; Fri, 30 Nov 2012 09:17:48 +0100 (CET) Message-ID: <50B86BAF.8010201@omnitor.se> Date: Fri, 30 Nov 2012 09:17:51 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B82D25.3030806@jesup.org> In-Reply-To: <50B82D25.3030806@jesup.org> Content-Type: multipart/alternative; boundary="------------070400000604000902030902" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 08:17:59 -0000 This is a multi-part message in MIME format. --------------070400000604000902030902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2012-11-30 04:51, Randell Jesup wrote: > Not so simply; MediaStreams in Firefox currently have a strong idea > that data has a time for display and a duration. This could be worked > around, and might need to for other reasons - but there was no design > goal for carrying non-media data in MediaStreams. Real-time text is to be seen as media. When using RFC 4103 for transport, the samples are usually 300 ms. Usually they should be played asap but smoothed out during the sampling period. If needed they can be synchronized through time stamps with other media. 3GPP TS 26.114 Multimedia Telephony is a good example of a spec treating real-time text as any other media. It is of course a good habit to keep already received real-time text visible for some time. I hope that that does not conflict with the time and duration idea. There is an expired draft telling how that can be done. http://tools.ietf.org/html/draft-hellstrom-textpreview-08 That topic is also dealt with very briefly in the presentation standard ITU-T T.140 http://www.itu.int/rec/T-REC-T.140/en /Gunnar --------------070400000604000902030902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 2012-11-30 04:51, Randell Jesup wrote:
Not so simply; MediaStreams in Firefox currently have a strong idea that data has a time for display and a duration. This could be worked around, and might need to for other reasons - but there was no design goal for carrying non-media data in MediaStreams.
Real-time text is to be seen as media. When using RFC 4103 for transport, the samples are usually 300 ms. Usually they should be played asap but smoothed out during the sampling period. If needed they can be synchronized through time stamps with other media. 3GPP TS 26.114 Multimedia Telephony is a good example of a spec treating real-time text as any other media.

It is of course a good habit to keep already received real-time text visible for some time. I hope that that does not conflict with the time and duration idea. There is an expired draft telling how that can be done.
http://tools.ietf.org/html/draft-hellstrom-textpreview-08
That topic is also dealt with very briefly in the presentation standard ITU-T T.140 http://www.itu.int/rec/T-REC-T.140/en

/Gunnar




--------------070400000604000902030902-- From harald@alvestrand.no Fri Nov 30 00:30:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8799321F84F1 for ; Fri, 30 Nov 2012 00:30:54 -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 RsP2dGVLlvvS for ; Fri, 30 Nov 2012 00:30:53 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9D29A21F84ED for ; Fri, 30 Nov 2012 00:30:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09AFA39E1C9 for ; Fri, 30 Nov 2012 09:30: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 t+F+Xvt5UMC8 for ; Fri, 30 Nov 2012 09:30:49 +0100 (CET) Received: from [IPv6:2620:0:1072:a:4977:95e8:5532:be2e] (unknown [IPv6:2620:0:1072:a:4977:95e8:5532:be2e]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 01A5539E125 for ; Fri, 30 Nov 2012 09:30:48 +0100 (CET) Message-ID: <50B86EB8.2050700@alvestrand.no> Date: Fri, 30 Nov 2012 09:30:48 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> In-Reply-To: <201211282145.qASLjanB1955372@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 08:30:54 -0000 On 11/28/2012 10:45 PM, Dale R. Worley wrote: >> >From: "Richard Shockey" >> > >> >... you can delay the discussion but not the requirement. The >> >regulators will insist on this. >> > >> >http://transition.fcc.gov/cgb/dro/cvaa.html >> > >> >http://europa.eu/legislation_summaries/information_society/legislative_frame >> >work/l24216a_en.htm > Richard gets back to an important issue -- T.140-based RTT is being > heavily lobbied for and gradually imposed by telephony regulators. So we're being asked to incorporate a standard that * is not used yet * doesn't have technology push (the regulators need to mandate it) * doesn't have legal push (the regulators still haven't *decided* to impose it) * is not the obviously right technology choice because it has active lobbyists? I, for one, am happy to delay this one and take my chances. From magnus.westerlund@ericsson.com Fri Nov 30 01:02:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A1921F8523 for ; Fri, 30 Nov 2012 01:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 XrAqKvbfpIma for ; Fri, 30 Nov 2012 01:02:01 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1270921F850D for ; Fri, 30 Nov 2012 01:02:00 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-e9-50b876074b78 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D3.2B.11564.70678B05; Fri, 30 Nov 2012 10:01:59 +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; Fri, 30 Nov 2012 10:01:58 +0100 Message-ID: <50B87606.5030802@ericsson.com> Date: Fri, 30 Nov 2012 10:01:58 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+JvjS572Y4Agxs3jCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtFX79kL3rBVPN+6lL2B8QJrFyMnh4SAicSEh29YIGwxiQv3 1rN1MXJxCAmcZJSYM3cKK4SznFHi8JFuJpAqXgFtieU958A6WARUJebsms0MYrMJWEjc/NHI BmKLCvhKzNrzC6peUOLkzCdg9SIC6hKXH15gB7GFBXQllq84yQSxWVJi0bROsBpmAT2JKVdb GCFseYnmrRDzhYD2NjR1sE5g5J+FZOwsJC2zkLQsYGRexciem5iZk15uuIkRGFAHt/zW3cF4 6pzIIUZpDhYlcV6upP3+QgLpiSWp2ampBalF8UWlOanFhxiZODilGhhbggKLLZwycleX+3+7 O+uc6acLF948KP3/pFRyifmFzP7OTzaL1qltM+VgzxGy6Jmb65rXyv70sksrY9WTuiW+ATMm 3VfS/8n5e5eU/K4029LdfN9zM3ROzpLouaar4+T/tYLrf8VBlzeyCz819CR6S0qe3+a3jkeT 69UMx9zHkvd2MjQfe6DEUpyRaKjFXFScCAClEtgG9gEAAA== Subject: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 09:02:01 -0000 WG, This is the start of an one week+ call for consensus that will end on Sunday the 9th of December. The question for consensus is: Shall a use case be added regarding Text communication within the context of PeerConnection, i.e. not using the generic capabilites of WebRTC, but rather provide a specific media type and its transport. Please indicate your support or objections for this! 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 bernard_aboba@hotmail.com Fri Nov 30 01:06:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B682721F8594 for ; Fri, 30 Nov 2012 01:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.143, 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 jngYvuXDcEBp for ; Fri, 30 Nov 2012 01:06:54 -0800 (PST) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id CDA3821F846B for ; Fri, 30 Nov 2012 01:06:53 -0800 (PST) Received: from BLU002-W135 ([65.55.116.72]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Nov 2012 01:06:50 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d621502d-2909-446f-9678-afdbefd76d45_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Magnus Westerlund , "rtcweb@ietf.org" Date: Fri, 30 Nov 2012 01:06:49 -0800 Importance: Normal In-Reply-To: <50B87606.5030802@ericsson.com> References: <50B87606.5030802@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2012 09:06:50.0022 (UTC) FILETIME=[08400C60:01CDCEDA] Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 09:06:55 -0000 --_d621502d-2909-446f-9678-afdbefd76d45_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do not think that a use case on text communications would solve the probl= em by itself. The reality is that realtime text can be used in a number of= different ways=2C which will generate different implementation requirement= s. Rather than trying to boil this down into a single use case=2C it makes= more sense to me to have a document that explains the uses that are envisa= ged and the resulting implementation requirements. If we had such a docume= nt=2C the use case document could refer to it. =20 > Date: Fri=2C 30 Nov 2012 10:01:58 +0100 > From: magnus.westerlund@ericsson.com > To: rtcweb@ietf.org > Subject: [rtcweb] Consensus call on Text Communication >=20 > WG=2C >=20 > This is the start of an one week+ call for consensus that will end on > Sunday the 9th of December. The question for consensus is: Shall a use > case be added regarding Text communication within the context of > PeerConnection=2C i.e. not using the generic capabilites of WebRTC=2C but > rather provide a specific media type and its transport. >=20 > Please indicate your support or objections for this! >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies=2C Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm=2C Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_d621502d-2909-446f-9678-afdbefd76d45_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I do not think that a use case o= n text communications would solve the problem by itself. =3B The realit= y is that realtime text can be used in a number of different ways=2C which = will generate different implementation requirements. =3B Rather than tr= ying to boil this down into a single use case=2C it makes more sense to me = to have a document that explains the uses that are envisaged and the result= ing implementation requirements. =3B If we had such a document=2C the u= se case document could refer to it. =3B

>=3B Date: Fri=2C 30 Nov 2012 10:01:58 +0100
>= =3B From: magnus.westerlund@ericsson.com
>=3B To: rtcweb@ietf.org
&= gt=3B Subject: [rtcweb] Consensus call on Text Communication
>=3B
= >=3B WG=2C
>=3B
>=3B This is the start of an one week+ call fo= r consensus that will end on
>=3B Sunday the 9th of December. The ques= tion for consensus is: Shall a use
>=3B case be added regarding Text c= ommunication within the context of
>=3B PeerConnection=2C i.e. not usi= ng the generic capabilites of WebRTC=2C but
>=3B rather provide a spec= ific media type and its transport.
>=3B
>=3B Please indicate you= r support or objections for this!
>=3B
>=3B Cheers
>=3B >=3B Magnus Westerlund
>=3B
>=3B ----------------------------= ------------------------------------------
>=3B Multimedia Technologie= s=2C Ericsson Research EAB/TVM
>=3B ----------------------------------= ------------------------------------
>=3B Ericsson AB |= Phone +46 10 7148287
>=3B F=E4r=F6gatan 6 | Mobile +4= 6 73 0949079
>=3B SE-164 80 Stockholm=2C Sweden| mailto: magnus.wester= lund@ericsson.com
>=3B -----------------------------------------------= -----------------------
>=3B
>=3B ______________________________= _________________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org>=3B https://www.ietf.org/mailman/listinfo/rtcweb
=
= --_d621502d-2909-446f-9678-afdbefd76d45_-- From magnus.westerlund@ericsson.com Fri Nov 30 01:13:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7DF21F846C for ; Fri, 30 Nov 2012 01:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJnsfgjE5HiE for ; Fri, 30 Nov 2012 01:13:34 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6737021F8459 for ; Fri, 30 Nov 2012 01:13:33 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-76-50b878bc49ab Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9E.AB.06323.CB878B05; Fri, 30 Nov 2012 10:13:32 +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; Fri, 30 Nov 2012 10:13:32 +0100 Message-ID: <50B878BB.900@ericsson.com> Date: Fri, 30 Nov 2012 10:13:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvje6eih0BBh33xS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqkDZ5kLHrBWrL/1nbmBcSNLFyMnh4SAicS16SuYIGwxiQv3 1rN1MXJxCAmcZJRYMXcJlLOcUWLGun42kCpeAXWJu5cng9ksAqoSrW83gdlsAhYSN380gtmi Ar4Ss/b8YoKoF5Q4OfMJ2DYRoN7LDy+wdzFycAgLiEt8P5kAsVhSYtG0TrASZgE9iSlXWxgh bHmJ7W/nMIPYQgLaEg1NHawTGPlnIZk6C0nLLCQtCxiZVzGy5yZm5qSXm29iBIbTwS2/DXYw brovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGI99/ahkumWTV/V53 h5Qgz9LA05GXbS89sEoNfV17pzvN7ZFNh5LZgg/91h+PLDKe/WJpJLPhLTnbM5r3Tjnb90Yr tBR/zuqZx6nT/aBPJv3nJrtX3xJ2lBfdWRW2tuH6tfLtXL/4FiYbHbd5orSqi7Pj9+pNWtxH /2WXdeVtOadQJNyuJqOixFKckWioxVxUnAgA+hibBfUBAAA= Subject: [rtcweb] WebRTC and Fax X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 09:13:35 -0000 WG, I have reviewed the discussion on the Fax on both the MMUSIC list and on this list. My take away is that it very little support for adding fax to WebRTC. What I consider the main arguments around this are the following: - Fax can be viewed in a browser using other solutions not based on WebRTC - Fax signals going to or from the browser would still not have the legal mandate that a fax sent over POTS line and thus one of the main reasons for fax is anyway not fulfilled. If there is a proponent for Fax support in WebRTC present on the list they will need to step up and make a clearer argument to the WG why such a use case would be needed to be supported. Cheers Magnus Westerlund WG Chair From matthew.kaufman@skype.net Fri Nov 30 01:32:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B231021F8644 for ; Fri, 30 Nov 2012 01:32:21 -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 Xj6bA5sI7DJD for ; Fri, 30 Nov 2012 01:32:21 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 42B5521F863B for ; Fri, 30 Nov 2012 01:32:21 -0800 (PST) Received: from BY2FFO11FD003.protection.gbl (10.1.15.201) by BY2FFO11HUB033.protection.gbl (10.1.14.117) with Microsoft SMTP Server (TLS) id 15.0.568.11; Fri, 30 Nov 2012 09:32:19 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.568.11 via Frontend Transport; Fri, 30 Nov 2012 09:32:00 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.149]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Fri, 30 Nov 2012 09:31:28 +0000 From: Matthew Kaufman To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Consensus call on Text Communication Thread-Index: AQHNztlf/G1T6I+I00maWfq8hKt2rpgCHOIw Date: Fri, 30 Nov 2012 09:31:27 +0000 Message-ID: References: <50B87606.5030802@ericsson.com> In-Reply-To: <50B87606.5030802@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(51704002)(5343635001)(31966008)(47736001)(16406001)(54316002)(50466001)(50986001)(49866001)(51856001)(46102001)(47776002)(76482001)(53806001)(54356001)(56816002)(47446002)(23756002)(4396001)(74502001)(55846006)(47976001)(44976002)(33656001)(74662001)(56776001)(5343655001); DIR:OUT; SFP:; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06818431B9 Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 09:32:21 -0000 I'd like to know how WebVTT and WebRTC interact, if at all, before knowing = how to answer this. Matthew Kaufman > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Friday, November 30, 2012 9:02 AM > To: rtcweb@ietf.org > Subject: [rtcweb] Consensus call on Text Communication >=20 > WG, >=20 > This is the start of an one week+ call for consensus that will end on Sun= day > the 9th of December. The question for consensus is: Shall a use case be > added regarding Text communication within the context of PeerConnection, > i.e. not using the generic capabilites of WebRTC, but rather provide a sp= ecific > media type and its transport. >=20 > Please indicate your support or objections for this! >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From keith.drage@alcatel-lucent.com Fri Nov 30 05:07:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CCD21F84DC for ; Fri, 30 Nov 2012 05:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.069 X-Spam-Level: X-Spam-Status: No, score=-110.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 cL2oYh7voQ0p for ; Fri, 30 Nov 2012 05:06:52 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72521F8B9C for ; Fri, 30 Nov 2012 05:06:50 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAUD6U2T018474 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Nov 2012 14:06:42 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 30 Nov 2012 14:06:25 +0100 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "rtcweb@ietf.org" Date: Fri, 30 Nov 2012 14:06:23 +0100 Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3O1QsScVhYGroBRlmy6sdSwF/LUgAJds1Q Message-ID: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> In-Reply-To: <50B86EB8.2050700@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 13:07:01 -0000 It is used and implemented in my understanding. It has been used in trial circumstances on emergency calls in Sweden. It is specified as mandatory for networks to support, and interwork in SIP = calls over IMS, in support of emergency calls. It is the recognized mechani= sm in IMS for supporting hearing impaired callers in emergency situations. Now whether the implementation in webRTC is T.140, or something that is cap= ability of interworking to it is a different story, but I believe you do ne= ed to provide at least an equivalent capability at day 1. Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Harald Alvestrand > Sent: 30 November 2012 08:31 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions >=20 > On 11/28/2012 10:45 PM, Dale R. Worley wrote: > >> >From: "Richard Shockey" > >> > > >> >... you can delay the discussion but not the requirement. The > >> >regulators will insist on this. > >> > > >> >http://transition.fcc.gov/cgb/dro/cvaa.html > >> > > >> > >http://europa.eu/legislation_summaries/information_society/legislative_f= r > ame > >> >work/l24216a_en.htm > > Richard gets back to an important issue -- T.140-based RTT is being > > heavily lobbied for and gradually imposed by telephony regulators. > So we're being asked to incorporate a standard that >=20 > * is not used yet > * doesn't have technology push (the regulators need to mandate it) > * doesn't have legal push (the regulators still haven't *decided* to > impose it) > * is not the obviously right technology choice >=20 > because it has active lobbyists? >=20 > I, for one, am happy to delay this one and take my chances. >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gunnar.hellstrom@omnitor.se Fri Nov 30 05:07:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD09721F8512 for ; Fri, 30 Nov 2012 05:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1iNWT4RI-L2 for ; Fri, 30 Nov 2012 05:07:34 -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 629A321F84F2 for ; Fri, 30 Nov 2012 05:07:33 -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 ; Fri, 30 Nov 2012 14:06:55 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 0C4083A1EA for ; Fri, 30 Nov 2012 14:06:55 +0100 (CET) Message-ID: <50B8AF72.9060909@omnitor.se> Date: Fri, 30 Nov 2012 14:06:58 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> In-Reply-To: <50B86EB8.2050700@alvestrand.no> Content-Type: multipart/alternative; boundary="------------050806010907010504050207" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 13:07:34 -0000 This is a multi-part message in MIME format. --------------050806010907010504050207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-11-30 09:30, Harald Alvestrand wrote: > So we're being asked to incorporate a standard that > > * is not used yet Wrong, it is used, at least in Europe, and work well. > > * doesn't have technology push (the regulators need to mandate it) This is just because of lack of making conclusions of observations on how users are using IM today. Research reports indicate that all would be more happy being provided with real-time text than message-wise IM. Users need to adapt to the shortcomings of IM because no big service provider has yet provided real-time text together with other media in a conveniently available conversational tool. There is user push among accessibility users and relay service personnel who have acces to the technology. It is used and appreciated in text relay services, total conversation services, Sign relay services, IP text telephony services and captioned telephony services. > * doesn't have legal push (the regulators still haven't *decided* to > impose it) It is very uncommon for legal requirements to point at specific implementation standards. It is more common to require functionality -The requirements to provide the real-time text medium, -the requirement to provide it in calls with aidio and video, -the quality requirements on real-time text - and the interoperability requirements are all there in the legal requirements. And a hint that RFC 4103 is a suitable way to arrange the interoperability. > * is not the obviously right technology choice Why not? There is currently one well working standard, mainly intended for use in SIP. If IM is going to be enhanced to provide a real-time text feature within the IM services, the XMPP extension in creation might be a valid alternative because it is so well integrated in the IM environment. But for interworking with SIP, RFC 4103 seems to be the choice. One important indication is that it is included in the NG112 and NG911 specifications for emergency services. So, what does rtcweb want to be, IM with real-time media additions and SIP interworking, or real-time conversational service? Or both? Gunnar --------------050806010907010504050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-11-30 09:30, Harald Alvestrand wrote:
So we're being asked to incorporate a standard that

* is not used yet
Wrong, it is used, at least in Europe, and work well.

* doesn't have technology push (the regulators need to mandate it)
This is just because of lack of making conclusions of observations on how users are using IM today. Research reports indicate that all would be more happy being provided with real-time text than message-wise IM. Users need to adapt to the shortcomings of IM because no big service provider has yet provided real-time text together with other media in a conveniently available conversational tool.

There is user push among accessibility users and relay service personnel who have acces to the technology. It is used and appreciated in text relay services, total conversation services, Sign relay services, IP text telephony services and captioned telephony services.
* doesn't have legal push (the regulators still haven't *decided* to impose it)
It is very uncommon for legal requirements to point at specific implementation standards.
It is more common to require functionality

-The requirements to provide the real-time text medium,
-the requirement to provide it in calls with aidio and video,
-the quality requirements on real-time text
- and the interoperability requirements
 are all there in the legal requirements.

And a hint that RFC 4103 is a suitable way to arrange the interoperability.
 
* is not the obviously right technology choice
Why not?

There is currently one well working standard, mainly intended for use in SIP.

If IM is going to be enhanced to provide a real-time text feature within the IM services, the XMPP extension in creation might be a valid alternative because it is so well integrated in the IM environment.
But for interworking with SIP, RFC 4103 seems to be the choice. One important indication is that it is included  in the NG112 and NG911 specifications for emergency services.

So, what does rtcweb want to be, IM with real-time media additions and SIP interworking, or real-time conversational service?  Or both?


Gunnar

 
--------------050806010907010504050207-- From keith.drage@alcatel-lucent.com Fri Nov 30 05:20:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0C921F8552 for ; Fri, 30 Nov 2012 05:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.099 X-Spam-Level: X-Spam-Status: No, score=-110.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 sXVPqX2dSp3j for ; Fri, 30 Nov 2012 05:20:51 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B7AE521F8203 for ; Fri, 30 Nov 2012 05:20:50 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAUDK1RJ020390 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Nov 2012 14:20:44 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 30 Nov 2012 14:20:03 +0100 From: "DRAGE, Keith (Keith)" To: Matthew Kaufman , Magnus Westerlund , "rtcweb@ietf.org" Date: Fri, 30 Nov 2012 14:19:59 +0100 Thread-Topic: [rtcweb] Consensus call on Text Communication Thread-Index: AQHNztlf/G1T6I+I00maWfq8hKt2rpgCHOIwgAA/WPA= Message-ID: References: <50B87606.5030802@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 13:20:51 -0000 What do you mean by interact? What I do know is that a hearing impaired user may use RTT to support a voi= ce call, or support a RTT call with voice. It is not one or the other. Indeed if you look at the interworking between IMS and the PSTN, you will s= ee that in the PSTN side the mechanism is capable of real time switching be= tween the two. It is real time communication, rather than deferred (as in fax or IM or ema= il). Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Matthew Kaufman > Sent: 30 November 2012 09:31 > To: Magnus Westerlund; rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus call on Text Communication >=20 > I'd like to know how WebVTT and WebRTC interact, if at all, before knowin= g > how to answer this. >=20 > Matthew Kaufman >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Magnus Westerlund > > Sent: Friday, November 30, 2012 9:02 AM > > To: rtcweb@ietf.org > > Subject: [rtcweb] Consensus call on Text Communication > > > > WG, > > > > This is the start of an one week+ call for consensus that will end on > Sunday > > the 9th of December. The question for consensus is: Shall a use case be > > added regarding Text communication within the context of PeerConnection= , > > i.e. not using the generic capabilites of WebRTC, but rather provide a > specific > > media type and its transport. > > > > Please indicate your support or objections for this! > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Fri Nov 30 05:50:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A12F21F8AFE for ; Fri, 30 Nov 2012 05:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 VFz7-831-26J for ; Fri, 30 Nov 2012 05:50:43 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36C21F88FC for ; Fri, 30 Nov 2012 05:50:43 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-03-50b8b9b27bef Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DB.39.06323.2B9B8B05; Fri, 30 Nov 2012 14:50:42 +0100 (CET) Received: from [150.132.142.241] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 30 Nov 2012 14:50:42 +0100 Message-ID: <50B8B9B0.9000700@ericsson.com> Date: Fri, 30 Nov 2012 14:50:40 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> In-Reply-To: <50B8AF72.9060909@omnitor.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvje6mnTsCDJ4ul7dY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXMPfGYreM5csfvPU8YGxhbmLkZODgkBE4n9F26yQthiEhfu rWfrYuTiEBI4ySixdPUmRpCEkMBaRoknH0tBbF4BbYlZC9eCxVkEVCVOTO1lArHZBGwk1nZP AbNFBQIkFi85xw5RLyhxcuYTFhBbREBYYusriHphAWuJCxtWMEIsO88o8erfUrAGTgEtia75 +8EamAVsJS7MuQ5ly0s0b53NDHGQrsS71/dYJzAKzEKyYxaSlllIWhYwMq9iZM9NzMxJLzff xAgMtINbfhvsYNx0X+wQozQHi5I4r57qfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjCLG +ZMUSpjeXd70wu/l9dn3DotJRkv/WzRPNW2RoWzN7OJPHt58j9cue/Nl9pc5mlcY974uuFTA oZ8b3lm2TyG4IHPGnXkMKqbMV7bqbHoeL3yn7V48R9/Tax+CDj/KfqT94alb49PdoQuPX+f8 f25xtadviegTR49eQZsjd/fOmr5YxLBi/2slluKMREMt5qLiRACMIWieAgIAAA== Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 13:50:44 -0000 On 11/30/2012 02:06 PM, Gunnar Hellström wrote: > It is more common to require functionality > > -The requirements to provide the real-time text medium, > -the requirement to provide it in calls with aidio and video, > -the quality requirements on real-time text I think all those can be solved with the data channel (just send character by character) > - and the interoperability requirements Can't this be done with a GW (just as when interoperating rtcweb - PSTN)? From markybox@gmail.com Fri Nov 30 06:24:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560D521F85B4 for ; Fri, 30 Nov 2012 06:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 RV64neDFnhJh for ; Fri, 30 Nov 2012 06:24:23 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id BFA9121F859E for ; Fri, 30 Nov 2012 06:24:23 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so526943qad.10 for ; Fri, 30 Nov 2012 06:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mArNuFDRcwjKCxqQajyA9DCC/e3FohHfCCAnk1wysqo=; b=dzU+83q6FT3RpeBiCdo4rNbtOtB/i+OtIPFnGNjy41AEjogVqZck5q1TLTdQLKSbMI 02KGp8fPPMBTf6qsO/wE+PjZZCQyAThQBX4Av9rw/1CV4/aIsAmpU3fBX1jVEvTOcc9P 8J/PYj4MqXNc3s20/C31TADtuqFffl4vhzY6AOpinI6F3yu9dSFrQwnN8ngQkl9DDdGt S0avNO6GCQrZ/NhCRSXXu5FqjMc9DVAzRdLV9eS23gRkj98Y1e2E04e4YqgRN8u5/4Yf Ov1bIO4g4UzvxoyFIDzqdV5jOfM+mk2Je9RVue5wH0IR61dJcYd2o93tM1+Xk+E/eDmu qthg== Received: by 10.49.48.135 with SMTP id l7mr2514663qen.23.1354285463260; Fri, 30 Nov 2012 06:24:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.63.162 with HTTP; Fri, 30 Nov 2012 06:24:02 -0800 (PST) In-Reply-To: <50B8B9B0.9000700@ericsson.com> References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> <50B8B9B0.9000700@ericsson.com> From: Mark Rejhon Date: Fri, 30 Nov 2012 09:24:02 -0500 Message-ID: To: Stefan Hakansson LK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 14:24:24 -0000 (This is the author of XEP-0301, the XMPP-based real-time text standard) On Fri, Nov 30, 2012 at 8:50 AM, Stefan Hakansson LK wrote: > On 11/30/2012 02:06 PM, Gunnar Hellstr=F6m wrote: >> >> It is more common to require functionality >> >> -The requirements to provide the real-time text medium, >> -the requirement to provide it in calls with aidio and video, >> -the quality requirements on real-time text > > I think all those can be solved with the data channel (just send characte= r > by character) Not always. There are many use cases (e.g. mobile devices) where continuously sending character by character will not always show up continuously character by character on the destination device, for various reasons (e.g. needing to chunk data, needing to use BOSH, variable network latency, chunking issues of network congestion, etc) That's why XEP-0301 includes key press delay encoding capability, so that infrequent transmission can occur, while still having smooth playback of text. Although key press delay encoding is not marked as required in my spec, people can tell the difference between calm typing and panicked typing, if key press delays are completely preserved. Also with key press delay encoding, people can tolerate longer latencies during unavoidable conditions (e.g. many, including myself, can tolerate a 2 second lag or lag spike caused by network latency, e.g. satellite networks or extremely weak intermittent 1-bar mobile phone reception areas, etc) (I posted a link to the mailing list showing an animation, if web-linked message has not been filtered by the IETF servers.) It's on my RealJabber website, and is explained by section 6.1 "Text Presentation". Sincerely, Mark Rejhon Author of XEP-0301 -- XMPP In-Band Real-Time Text From markybox@gmail.com Fri Nov 30 07:35:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146C421F8B2A for ; Fri, 30 Nov 2012 07:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSQBrb9yCTrA for ; Fri, 30 Nov 2012 07:35:50 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 43E0F21F8B24 for ; Fri, 30 Nov 2012 07:35:46 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so601644qad.10 for ; Fri, 30 Nov 2012 07:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M8ky7CWmGW8KtQJYLCRP6VKLQathtB0gA+a2gw7AQPY=; b=I/4VstIzZobbMB0GEXoViJ5dErdR9JtXujYRDUy2nv8O4Jy41JSftyjkViOsN98HI+ LkqB92vsO4HS/9FVVAeOefgjHWv+Wd2PKY/apgwlFtH4NgEx1IuQ2imh1rPJLZNQrNy/ 4qcz4L9dEatTDXem6xwPYeARknnOadIRfx2FuNJjm+/QvJeOEEBP+rgllqWKl/dxXpoi 2SnjQEQaAdKb5mNqdtfJ7xoV4YPsKc5nAc1gZ7ki5n1YVncwdVNR1ldjXMdtiZ/Z1xGc r6IvHi3Mx1ZkaqI7Z287n2XJTV6eXafYgi9uxC/oz825tNyeGahP6y9pxZIiNMgShlbc a8ng== Received: by 10.224.182.203 with SMTP id cd11mr3673053qab.22.1354289745799; Fri, 30 Nov 2012 07:35:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.63.162 with HTTP; Fri, 30 Nov 2012 07:35:25 -0800 (PST) In-Reply-To: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> <50B8B9B0.9000700@ericsson.com> From: Mark Rejhon Date: Fri, 30 Nov 2012 10:35:25 -0500 Message-ID: To: Stefan Hakansson LK Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 15:35:51 -0000 (Adding relevant animations of real-time text, to see if it gets through IETF spam filters, this time.) On Fri, Nov 30, 2012 at 9:24 AM, Mark Rejhon wrote: > (I posted a link to the mailing list showing an animation, if web-linked > message has not been filtered by the IETF servers.) > It's on my RealJabber website, and is explained by section 6.1 "Text > Presentation". > > Sincerely, > Mark Rejhon > Author of XEP-0301 -- XMPP In-Band Real-Time Text An animation of real-time text from an actual implementation: http://www.realjabber.org/anim/real_time_text_demo.html This is a playback of my RealJabber demo program, running over an unmodified Google Talk server -- real-time text transmitted through somebody else's servers. So another secondary reason is we don't want to overload XMPP servers, so we do not transmit character at a time. We be polite to the XMPP server, and transmit at only one packet per second. But the typing still looks exactly original! (XEP-0301 is a real-time packetization of typing, like VoIP is a packetization of voice). Also observe how well real-time text "integrates" into the existing instant messaging metaphor -- even including message-edit-before-send capability, so recipient can see the sender editing the message before it gets sent ("committed") Another animation concept of real-time text running in JavaScript-based messaging systems: http://www.realjabber.org/anim/facebook_chat_concept.gif Thanks, Mark Rejhon Author of XMPP In-Band Real-Time Text http://www.xmpp.org/extensions/xep-0301.html From markybox@gmail.com Fri Nov 30 08:00:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0A721F8B69 for ; Fri, 30 Nov 2012 08:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 T-NSsbfZGcDi for ; Fri, 30 Nov 2012 08:00:25 -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 420FF21F8B64 for ; Fri, 30 Nov 2012 08:00:25 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so361146qca.31 for ; Fri, 30 Nov 2012 08:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=RQBcrGaKdG4E96NVn9o9NQlMNltm5mlT7koF10TgpDs=; b=V7MXp1WgqxzgtNqZB2k9r4IddL5lxPELBFdTEafJiEHpNy8nQf0Fq0OPjyY6WBFtFf hE1KNIFEfXjU1JDtRKNAnYtMdWt5fHnMsPEPBm9LUQyg3kz8jJFHTH+qul/r4jXlqAly jW0SjinOTXyqIxZSbRXlO12v1KAfpDvHcsks5N+79CUrUav/ji8EAOF+OjZ1rwPCR5FO c67Q76pMzdEiMuCLXDFhJUYeeH36FCNjYKNCDJlLOUZLQDlm+RNoTEvStqCb7bKg+Vcm w/R5i9c+T0Qb4DJXiQH0eE8CE15Ow5eYt+X0w0Rer4Mk3YVXtrEm0UgnFSK+U7kX3zxm fATw== Received: by 10.49.48.104 with SMTP id k8mr3035117qen.49.1354291222392; Fri, 30 Nov 2012 08:00:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.63.162 with HTTP; Fri, 30 Nov 2012 08:00:02 -0800 (PST) In-Reply-To: References: <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B686B9.90700@stpeter.im> <1967120335-1354139633-cardhu_decombobulator_blackberry.rim.net-363948593-@b5.c9.bise6.blackberry> From: Mark Rejhon Date: Fri, 30 Nov 2012 11:00:02 -0500 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:00:28 -0000 [This message was sent two days ago, but got filtered. Resending.] Hello, I'm the author of XEP-0301 -- the Real-Time Text XMPP Extension Protocol found at http://www.xmpp.org/extensions/xep-0301.html with animations/demo software found at http://www.realjabber.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions > Date: Wed, 28 Nov 2012 16:45:36 -0500 (EST) > From: worley@ariadne.com (Dale R. Worley) > To: rtcweb@ietf.org > > Catching up on various messages: > > > From: Igor Faynberg > > > > In this case, would that mean that when I type something and then > > want to correct it, backspaces would be transmitted, too? If so, I > > doubt it is useful. The second case, with the user having control > > over sending of the message, is much better. > > There are possibilities for embarrassment with real-time text, in that > you don't have time to reconsider your words between typing them and > hitting RETURN (which would send them in a message-oriented text > system). > > One response to this is that a similar possibility exists in > voice/video communication. And one can always configure one's RTT > system to delay sending text until it sees a RETURN. The XEP-0301 real-time text standard is oriented towards instant messaging, and it enables visibility of all message edits (including editing text in the middle of your sentence before sending your message). This is necessary in instant messaging programs to allow backwards compatibility with the user's pre-existing expectation of backspacing/editing their message before sending the messages. Examples of animations of how the real-time text integrates into existing chat systems: http://www.realjabber.org/anim/real_time_text_demo.html ...(screenshot animation from RealJabber -- comparision with and without real time, in messaging style metaphor) http://www.realjabber.org/anim/facebook_chat_concept.gif ...(concept animation of RTT being bolted-on into Facebook Chat, illustrating seamless add-on) ...(notice the "Fast Text Mode Enabled" notification) As the XEP-0301 standard is designed to be backwards compatible, as a client-only modification, and to run over existing XMPP networks with no server modifications. Users typically edit and backspace messages before sending, and that capability is kept even when real-time text is enabled, to preserve user experience with existing instant message interfaces. Also, there is an activation/deactivation mechanism available, too. The "I doubt it is useful" phrase (interpretable in multiple ways) caught my attention... Backspacing is useful text equivalent to a spoken "oops, let me repeat" on the telephone, when you made a mistake and need to repeat what you just said. On the same subject of telephone -- real-time text is also useful for placing a telephone call silently -- sometimes people need to urgently chat in real-time without waiting, but aren't allowed to use voice with phones (e.g. restaurants, hospitals, airplane WiFi, military covert chatting, emergency situations, bedroom, etc). It is noted that typing on touchscreen is fairly quiet. In private trials of my own software within my peer groups, people preferred real-time text calls over video phone calls, as a feature. People still appreciated the freedom to edit instant messages the way they used to (continued instant messaging UI familarity) even while the recipient is reading, and implementors can choose to provide a software feature to turn on/off real-time text even in mid-message-editing. Also, being optimized as an RTT enhancement to message-by-message chats, XEP-0301 also supports RTT group chats including mixed-mode chats (e.g. RTT only from the leader, teacher or lecturer into a groupchat, with everyone else message-by-message to prevent distractions), and remains compatible with RTT and non-RTT-supported clients, either with all the existing message-line editing features, including backspacing messages. Although T.140 RTT isn't derived from instant messaging, the context of how it can apply to instant messaging, is useful to know, and I should note that Gunnar has a transcoder between T.140 RTT and my XEP-0301 (We collaborate on the XEP-0301 spec, he is listed in the credits) which takes advantage of the backspacing capability. > > From: Gunnar Hellstrom > > > > The need for synchronization with audio and video is very relaxed > > for RTT. I would assume that a second out of synch is easily > > accepted. > > > > The one second end-to-end latency is probably slightly more > > demanding, even if it also easy compared to audio and video > > requirements. Synch with audio/video is not a major issue in my experience for real-time text. As long as the playout is smooth (both XEP-0301 and T.140 have different methods of smooth text output), many can tolerate a 2 second delay, as it's not as real-time critical as voice or audio. Ideally, 300ms or less is far better, of course, and both my standards and Gunnar's standards use that figure. > > My suggestion is instead of trying to jam an existing hack to "run > > a reliable protocol over an unreliable channel" into the > > implementations, to instead define running a well-known > > reliable-channel text protocol over a reliable DataChannel (or > > unreliable, if that makes more sense). > > Yes, text/red is a hack. But it's already used in the RTT world. > (More about that below.) On this topic, I should mention that XEP-0301 has a basic redundancy mechanism too (section 4.6 to 4.6.3), but it is very different from the way T.140/RFC4103 RTT does it, and it permits recovery in instant-messaging-releavant situations even a long time later (e.g. loss of WiFI reception that also leads to disconnection; and the reconnecting client (even on a separate device, separate software) receives the re-transmitted contents of a long instant message still being composed by the sender, without the sender noticing anything's amiss. (The sender just notices the recipient disconnect and reconnect while continuing to type a very long message that's much longer to write, than the T.140 redundancy windows) (The recipient sees the sender message-in-progress reappear upon reconnecting) As a final note, even if T.140 is decided to be integrated into WebRTC, that does not exclude other real-time text standards in the future. I'd like to make sure JavaScript implementations of instant messaging optimized real-time text standards (including XEP-0301, as it XML payload format is also usable outside XMPP too) should still be possible to be added by third party application developers taking advantage of WebRTC. Preferred if it's still possible integrate real-time text into the instant-messaging metaphor. Mark Rejhon Author of XEP-0301 -- XMPP based Real-Time Text From randell-ietf@jesup.org Fri Nov 30 08:14:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C91B21F8B25 for ; Fri, 30 Nov 2012 08:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=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 kb1sb7MJiTji for ; Fri, 30 Nov 2012 08:14:00 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CF29C21F8B13 for ; Fri, 30 Nov 2012 08:14:00 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2147 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TeTDz-0006eX-FQ for rtcweb@ietf.org; Fri, 30 Nov 2012 10:14:00 -0600 Message-ID: <50B8DB23.40704@jesup.org> Date: Fri, 30 Nov 2012 11:13:23 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> <50B8B9B0.9000700@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:14:01 -0000 On 11/30/2012 9:24 AM, Mark Rejhon wrote: > (This is the author of XEP-0301, the XMPP-based real-time text standard) > > On Fri, Nov 30, 2012 at 8:50 AM, Stefan Hakansson LK > wrote: >> On 11/30/2012 02:06 PM, Gunnar Hellström wrote: >>> It is more common to require functionality >>> >>> -The requirements to provide the real-time text medium, >>> -the requirement to provide it in calls with aidio and video, >>> -the quality requirements on real-time text >> I think all those can be solved with the data channel (just send character >> by character) > Not always. There are many use cases (e.g. mobile devices) where > continuously sending character by character will not always show up > continuously character by character on the destination device, for > various reasons (e.g. needing to chunk data, needing to use BOSH, > variable network latency, chunking issues of network congestion, etc) That's true, though in many of these cases we're talking about RTT+audio and/or video, so per-character typing is not where you'll have your problems. For RTT alone (no audio or video), in a very poor network, you're correct. However, I think Stefan was meaning you can send the data character-by-character but did not mean that's *all* you would send; I'm assuming this is in a protocol that can include things like intra-character delay, multiple characters, etc. In this situation, DataChannels are a pure transport (combined we hope with work to minimize delay by coordinating congestion control with the audio/video transport). The RTT protocol run over it could be simple or complex, and could be an existing protocol from elsewhere (or the guts thereof), like T.140 or XEP-0301, or something brand new. > That's why XEP-0301 includes key press delay encoding capability, so > that infrequent transmission can occur, while still having smooth > playback of text. Although key press delay encoding is not marked as > required in my spec, people can tell the difference between calm > typing and panicked typing, if key press delays are completely > preserved. Also with key press delay encoding, people can tolerate > longer latencies during unavoidable conditions (e.g. many, including > myself, can tolerate a 2 second lag or lag spike caused by network > latency, e.g. satellite networks or extremely weak intermittent 1-bar > mobile phone reception areas, etc) Nice demo. Slightly contrived of course. :-) I'll note that tolerance for true as-you-type RTT varies widely culturally and personally. Some people simply hate it because they don't want to expose intermediate "thoughts" they erase while before sending, and don't want the pressure of responding *now* after the other person says something. And a switch helps, but then it can lead to awkwardness of "why don't you just respond; why are you editing?" Also, I've noticed younger people/teens have moved further and further away from direct real-time interaction ("What do you mean I should *call* him on my phone?! We only text!") partly because the delays provided by text-chat gives a bit of a social safety net against nervousness and anxiety. The HoH community may well have different cultural standards/preferences about how to use interactive text communication than the general public as well, and emergency services may have different needs. -- Randell Jesup randell-ietf@jesup.org From bernard_aboba@hotmail.com Fri Nov 30 08:22:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A564C21F8A60 for ; Fri, 30 Nov 2012 08:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.77 X-Spam-Level: X-Spam-Status: No, score=-101.77 tagged_above=-999 required=5 tests=[AWL=-0.568, 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 LIm0H8-RM0Eu for ; Fri, 30 Nov 2012 08:22:06 -0800 (PST) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 59B3721F8595 for ; Fri, 30 Nov 2012 08:22:06 -0800 (PST) Received: from BLU401-EAS91 ([65.55.116.72]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Nov 2012 08:22:05 -0800 X-Originating-IP: [24.16.96.166] X-EIP: [w4KNxZ4p0Ag1WMtLQjAk2EpaKf/C4B0G] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-AD00A50A-DF29-446F-BB38-8F40A290E20B" Content-Transfer-Encoding: 7bit References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <50B86EB8.2050700@alvestrand.no> Date: Fri, 30 Nov 2012 08:24:28 -0800 To: Harald Alvestrand X-OriginalArrivalTime: 30 Nov 2012 16:22:05.0687 (UTC) FILETIME=[D6664870:01CDCF16] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:22:07 -0000 --Apple-Mail-AD00A50A-DF29-446F-BB38-8F40A290E20B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To be clear, there is US legislation (known as CVAA) that has a compliance d= eadline of October 7, 2013:=20 http://www.gpo.gov/fdsys/pkg/PLAW-111publ260/pdf/PLAW-111publ260.pdf The expectations for Advanced Communications Services are laid out in the AC= S Report and Order. Among other things, the expectation is that ACS will be m= ade accessible and usable by people with disabilities: http://www.fcc.gov/document/accessibility-rules-advanced-communications-serv= ices-0 However issuance of more specific rules is still pending. Among other thing= s, completion of the Access Board Section 255/508 refresh is still in progre= ss, the most recent draft of which is given below: http://www.access-board.gov/sec508/refresh/draft-rule.htm Disclaimer: I am not a lawyer, and do not speak on behalf of any govt agency= , or the FCC EAAC. If you need legal advice on CVAA obligations, get advice f= rom a competent telecommunications lawyer. On Nov 30, 2012, at 0:30, "Harald Alvestrand" wrote: > So we're being asked to incorporate a standard that >=20 > * is not used yet > * doesn't have technology push (the regulators need to mandate it) > * doesn't have legal push (the regulators still haven't *decided* to impos= e it) > * is not the obviously right technology choice >=20 > because it has active lobbyists? >=20 > I, for one, am happy to delay this one and take my chances. >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-AD00A50A-DF29-446F-BB38-8F40A290E20B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+VG8gYmUg Y2xlYXIsIHRoZXJlIGlzIFVTIGxlZ2lzbGF0aW9uIChrbm93biBhcyBDVkFBKSB0aGF0IGhhcyBh IGNvbXBsaWFuY2UgZGVhZGxpbmUgb2YgT2N0b2JlciA3LCAyMDEzOiZuYnNwOzwvZGl2PjxkaXY+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDE5cHg7IHdoaXRlLXNw YWNlOiBub3dyYXA7IC13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xvcjogcmdiYSgyNiwgMjYsIDI2 LCAwLjI5Njg3NSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmlsbC1jb2xvcjogcmdiYSgxNzUsIDE5 MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZnJhbWUtY29sb3I6IHJnYmEo NzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogbm9uZTsg Ij48YSBocmVmPSJodHRwOi8vd3d3Lmdwby5nb3YvZmRzeXMvcGtnL1BMQVctMTExcHVibDI2MC9w ZGYvUExBVy0xMTFwdWJsMjYwLnBkZiI+aHR0cDovL3d3dy5ncG8uZ292L2Zkc3lzL3BrZy9QTEFX LTExMXB1YmwyNjAvcGRmL1BMQVctMTExcHVibDI2MC5wZGY8L2E+PC9zcGFuPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+VGhlIGV4cGVjdGF0aW9ucyBmb3IgQWR2YW5jZWQgQ29tbXVuaWNhdGlv bnMgU2VydmljZXMgYXJlIGxhaWQgb3V0IGluIHRoZSBBQ1MgUmVwb3J0IGFuZCBPcmRlci4gQW1v bmcgb3RoZXIgdGhpbmdzLCB0aGUgZXhwZWN0YXRpb24gaXMgdGhhdCBBQ1Mgd2lsbCBiZSBtYWRl IGFjY2Vzc2libGUgYW5kIHVzYWJsZSBieSBwZW9wbGUgd2l0aCBkaXNhYmlsaXRpZXM6PC9kaXY+ PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMTlweDsgd2hp dGUtc3BhY2U6IG5vd3JhcDsgLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAy NiwgMjYsIDAuMjk2ODc1KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3 NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjog cmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBu b25lOyAiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZmNjLmdvdi9kb2N1bWVudC9hY2Nlc3NpYmlsaXR5 LXJ1bGVzLWFkdmFuY2VkLWNvbW11bmljYXRpb25zLXNlcnZpY2VzLTAiPmh0dHA6Ly93d3cuZmNj Lmdvdi9kb2N1bWVudC9hY2Nlc3NpYmlsaXR5LXJ1bGVzLWFkdmFuY2VkLWNvbW11bmljYXRpb25z LXNlcnZpY2VzLTA8L2E+PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SG93ZXZlciBp c3N1YW5jZSBvZiBtb3JlIHNwZWNpZmljIHJ1bGVzIGlzIHN0aWxsIHBlbmRpbmcuICZuYnNwO0Ft b25nIG90aGVyIHRoaW5ncywgY29tcGxldGlvbiBvZiB0aGUgQWNjZXNzIEJvYXJkIFNlY3Rpb24g MjU1LzUwOCByZWZyZXNoIGlzIHN0aWxsIGluIHByb2dyZXNzLCB0aGUgbW9zdCByZWNlbnQgZHJh ZnQgb2Ygd2hpY2ggaXMgZ2l2ZW4gYmVsb3c6PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxNXB4OyBsaW5lLWhlaWdodDogMTlweDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgLXdlYmtp dC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjk2ODc1KTsgLXdlYmtp dC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsg LXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMw NDY5KTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBub25lOyAiPjxhIGhyZWY9Imh0dHA6Ly93 d3cuYWNjZXNzLWJvYXJkLmdvdi9zZWM1MDgvcmVmcmVzaC9kcmFmdC1ydWxlLmh0bSI+aHR0cDov L3d3dy5hY2Nlc3MtYm9hcmQuZ292L3NlYzUwOC9yZWZyZXNoL2RyYWZ0LXJ1bGUuaHRtPC9hPjwv c3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkRpc2NsYWltZXI6IEkgYW0gbm90IGEgbGF3 eWVyLCBhbmQgZG8gbm90IHNwZWFrIG9uIGJlaGFsZiBvZiBhbnkgZ292dCBhZ2VuY3ksIG9yIHRo ZSBGQ0MgRUFBQy4gSWYgeW91IG5lZWQgbGVnYWwgYWR2aWNlIG9uIENWQUEgb2JsaWdhdGlvbnMs IGdldCBhZHZpY2UgZnJvbSBhIGNvbXBldGVudCB0ZWxlY29tbXVuaWNhdGlvbnMgbGF3eWVyLjwv ZGl2PjxkaXY+PGJyPk9uIE5vdiAzMCwgMjAxMiwgYXQgMDozMCwgIkhhcmFsZCBBbHZlc3RyYW5k IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vIj5oYXJhbGRAYWx2ZXN0 cmFuZC5ubzwvYT4mZ3Q7IHdyb3RlOjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu PlNvIHdlJ3JlIGJlaW5nIGFza2VkIHRvIGluY29ycG9yYXRlIGEgc3RhbmRhcmQgdGhhdDwvc3Bh bj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj4qIGlzIG5vdCB1c2VkIHlldDwvc3Bhbj48YnI+ PHNwYW4+KiBkb2Vzbid0IGhhdmUgdGVjaG5vbG9neSBwdXNoICh0aGUgcmVndWxhdG9ycyBuZWVk IHRvIG1hbmRhdGUgaXQpPC9zcGFuPjxicj48c3Bhbj4qIGRvZXNuJ3QgaGF2ZSBsZWdhbCBwdXNo ICh0aGUgcmVndWxhdG9ycyBzdGlsbCBoYXZlbid0ICpkZWNpZGVkKiB0byBpbXBvc2UgaXQpPC9z cGFuPjxicj48c3Bhbj4qIGlzIG5vdCB0aGUgb2J2aW91c2x5IHJpZ2h0IHRlY2hub2xvZ3kgY2hv aWNlPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPmJlY2F1c2UgaXQgaGFzIGFjdGl2 ZSBsb2JieWlzdHM/PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkksIGZvciBvbmUs IGFtIGhhcHB5IHRvIGRlbGF5IHRoaXMgb25lIGFuZCB0YWtlIG15IGNoYW5jZXMuPC9zcGFuPjxi cj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bh bj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48 YnI+PHNwYW4+cnRjd2ViIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-AD00A50A-DF29-446F-BB38-8F40A290E20B-- From keith.drage@alcatel-lucent.com Fri Nov 30 08:27:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE72121E804B for ; Fri, 30 Nov 2012 08:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.82 X-Spam-Level: X-Spam-Status: No, score=-109.82 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=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 6Qg6m-WYqJhN for ; Fri, 30 Nov 2012 08:27:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id CEBA621F8B54 for ; Fri, 30 Nov 2012 08:27:16 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAUGQkNf009628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 30 Nov 2012 17:27:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 30 Nov 2012 17:26:59 +0100 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" Date: Fri, 30 Nov 2012 17:26:57 +0100 Thread-Topic: [rtcweb] Text communication in RTCWEB sessions Thread-Index: Ac3PFb+hkvOkHpzCTT6CF8PznGzugwAAEqkw Message-ID: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> <50B8B9B0.9000700@ericsson.com> <50B8DB23.40704@jesup.org> In-Reply-To: <50B8DB23.40704@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:27:18 -0000 There is a key reason why real time text is the preferred media for text ra= ther than instant messaging for emergency calls. It is because the remote party (the PSAP) wants control of that delay, and = wants to keep it as short as possible. PSAP call takers want to gain the ma= ximum amount of relevant information in the minimal possible time. If a use= r spends time composing a response, the call taker wants to be able to resp= ond as soon as possible if they see the wrong, or inappropriate, response i= s being given, in order to get the appropriate response given. This is exac= tly what helps in speech conversation and is needed in the same scenario in= real time text. So 300 ms latency is probably fine. It might chunk a couple of characters, = or deal with a quick backspace to get rid of one mistyped character. Anythi= ng beyond that will merely delay the call taker providing you with an appro= priate emergency response. Instant messaging and real time text are complementary forms of text commun= ication. One does not replace the other. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Randell Jesup > Sent: 30 November 2012 16:13 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions >=20 > On 11/30/2012 9:24 AM, Mark Rejhon wrote: > > (This is the author of XEP-0301, the XMPP-based real-time text standard= ) > > > > On Fri, Nov 30, 2012 at 8:50 AM, Stefan Hakansson LK > > wrote: > >> On 11/30/2012 02:06 PM, Gunnar Hellstr=F6m wrote: > >>> It is more common to require functionality > >>> > >>> -The requirements to provide the real-time text medium, > >>> -the requirement to provide it in calls with aidio and video, > >>> -the quality requirements on real-time text > >> I think all those can be solved with the data channel (just send > character > >> by character) > > Not always. There are many use cases (e.g. mobile devices) where > > continuously sending character by character will not always show up > > continuously character by character on the destination device, for > > various reasons (e.g. needing to chunk data, needing to use BOSH, > > variable network latency, chunking issues of network congestion, etc) >=20 > That's true, though in many of these cases we're talking about RTT+audio > and/or video, so per-character typing is not where you'll have your > problems. >=20 > For RTT alone (no audio or video), in a very poor network, you're > correct. However, I think Stefan was meaning you can send the data > character-by-character but did not mean that's *all* you would send; I'm > assuming this is in a protocol that can include things like > intra-character delay, multiple characters, etc. >=20 > In this situation, DataChannels are a pure transport (combined we hope > with work to minimize delay by coordinating congestion control with the > audio/video transport). The RTT protocol run over it could be simple or > complex, and could be an existing protocol from elsewhere (or the guts > thereof), like T.140 or XEP-0301, or something brand new. >=20 > > That's why XEP-0301 includes key press delay encoding capability, so > > that infrequent transmission can occur, while still having smooth > > playback of text. Although key press delay encoding is not marked as > > required in my spec, people can tell the difference between calm > > typing and panicked typing, if key press delays are completely > > preserved. Also with key press delay encoding, people can tolerate > > longer latencies during unavoidable conditions (e.g. many, including > > myself, can tolerate a 2 second lag or lag spike caused by network > > latency, e.g. satellite networks or extremely weak intermittent 1-bar > > mobile phone reception areas, etc) >=20 > Nice demo. Slightly contrived of course. :-) I'll note that tolerance > for true as-you-type RTT varies widely culturally and personally. Some > people simply hate it because they don't want to expose intermediate > "thoughts" they erase while before sending, and don't want the pressure > of responding *now* after the other person says something. And a switch > helps, but then it can lead to awkwardness of "why don't you just > respond; why are you editing?" Also, I've noticed younger people/teens > have moved further and further away from direct real-time interaction > ("What do you mean I should *call* him on my phone?! We only text!") > partly because the delays provided by text-chat gives a bit of a social > safety net against nervousness and anxiety. >=20 > The HoH community may well have different cultural standards/preferences > about how to use interactive text communication than the general public > as well, and emergency services may have different needs. >=20 > -- > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From markybox@gmail.com Fri Nov 30 08:32:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8908621F85CD for ; Fri, 30 Nov 2012 08:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 DKVwN8IuYaBR for ; Fri, 30 Nov 2012 08:32:44 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EB78121F85A0 for ; Fri, 30 Nov 2012 08:32:43 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so655812qad.10 for ; Fri, 30 Nov 2012 08:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E7sp4d0TVlYl/HOIYWCMgLxunpYWPSPTm292hHOGpuI=; b=EOgg/AP7pL0YomAySsba21FSJjgbHhgieTYbYCsaFhu4f+txhrLJBA1weMCoDz7j0n FfJ6Gni9hbOer8QDGO5kkqS9MQ6v/gXCzadlZsjMY6/ul0eoY6d5L/kToAMsoEfkrGyb hndhJqCJSwVivNuRIcpq/cYNttkYmUZwQBHtwEP3BbR6iD4Zkt/YaFVwM647JKl3JVsM zWQrPybB1nlNc+S1eJ/vtBqiR6nK++hGrGTBIqXhxOc4cbuykg4FL6+BjvgDwLG5s+uA MFGREf5mFvwskGfMqLuDTn6HSgi0463wWHGUa3FEb2TuD5n98WuiWDVeY1rKjZ9gEnlh qHKA== Received: by 10.49.48.135 with SMTP id l7mr3250197qen.23.1354293163518; Fri, 30 Nov 2012 08:32:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.63.162 with HTTP; Fri, 30 Nov 2012 08:32:23 -0800 (PST) In-Reply-To: <50B8DB23.40704@jesup.org> References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> <50B8B9B0.9000700@ericsson.com> <50B8DB23.40704@jesup.org> From: Mark Rejhon Date: Fri, 30 Nov 2012 11:32:23 -0500 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:32:44 -0000 On Fri, Nov 30, 2012 at 11:13 AM, Randell Jesup wrote: > Nice demo. Slightly contrived of course. :-) I'll note that tolerance for > true as-you-type RTT varies widely culturally and personally. Some people > simply hate it because they don't want to expose intermediate "thoughts" > they erase while before sending, and don't want the pressure of responding > *now* after the other person says something. And a switch helps, but then > it can lead to awkwardness of "why don't you just respond; why are you > editing?" Also, I've noticed younger people/teens have moved further and > further away from direct real-time interaction ("What do you mean I should > *call* him on my phone?! We only text!") partly because the delays provided > by text-chat gives a bit of a social safety net against nervousness and > anxiety. > > The HoH community may well have different cultural standards/preferences > about how to use interactive text communication than the general public as > well, and emergency services may have different needs. Agreed. That's why my XEP-0301 specification supports any text smoothing method the implementer prefer -- and can be done independently of the interval transmission rate/limitations. You can do it character-at-a-time, delay-buffered (to allow corrections), captioning, transcription, bursts-at-a-time, words-at-a-time, fixed-smoothing, etc. In addition, I've included activation/deactivation methodologies in XEP-0301. Mark Rejhon Author of XEP-0301 In-Band Real-Time Text. From harald@alvestrand.no Fri Nov 30 08:35:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B522021F8786 for ; Fri, 30 Nov 2012 08:35:04 -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 PB2gE0HHKQYO for ; Fri, 30 Nov 2012 08:35:04 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F3FFC21F8B4F for ; Fri, 30 Nov 2012 08:35:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 27F7239E170 for ; Fri, 30 Nov 2012 17:34:49 +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 Tz2eoLifzOEm for ; Fri, 30 Nov 2012 17:34:48 +0100 (CET) Received: from [IPv6:2620:0:1072:a:4977:95e8:5532:be2e] (unknown [IPv6:2620:0:1072:a:4977:95e8:5532:be2e]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7AD1039E125 for ; Fri, 30 Nov 2012 17:34:48 +0100 (CET) Message-ID: <50B8E026.9090305@alvestrand.no> Date: Fri, 30 Nov 2012 17:34:46 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> In-Reply-To: <50B87606.5030802@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:35:04 -0000 On 11/30/2012 10:01 AM, Magnus Westerlund wrote: > WG, > > This is the start of an one week+ call for consensus that will end on > Sunday the 9th of December. The question for consensus is: Shall a use > case be added regarding Text communication within the context of > PeerConnection, i.e. not using the generic capabilites of WebRTC, but > rather provide a specific media type and its transport. > > Please indicate your support or objections for this! I object to adding such an use case. From markybox@gmail.com Fri Nov 30 08:42:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591A221F8B2F for ; Fri, 30 Nov 2012 08:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Dspii9915wRV for ; Fri, 30 Nov 2012 08:41:59 -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 06F9521F85CE for ; Fri, 30 Nov 2012 08:41:58 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so389634qca.31 for ; Fri, 30 Nov 2012 08:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vzArh5WcfuDC8Us9i3kPyCLJBjD2xmiG7M9MEBhQBnI=; b=KgoH67Fj0NBG/F9wW/5n79Cb1ZWLjqwrhrxJejeOjrTQpdn/ZPOkFyNooz2T0Szyyo 0pM/wWVhTM0ld+9ybYh4BgGJUb0+UXFXaKZuwwUTCN/XVPtgEynCFdKP49FWzVtFzPO9 6FOdH72gS10LfRkWc99WXnPuGS4XoZP9iiOfBoUip3exT+ibGeADdSJBu5cyI08agH+R DmBf9RWYTXk5uEtj95Ol4/iNnwc55AjoyOSnRbyxwJKVpDeF73TkCVuxaB8CoLd/bxyH 79OVrF5GxGfRGRPq3Wj79885H54lgJLXKoK34xP17dehqwV7TUEaydFHjd7kcYZaP+qk ifhg== Received: by 10.49.48.104 with SMTP id k8mr3266973qen.49.1354293718040; Fri, 30 Nov 2012 08:41:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.63.162 with HTTP; Fri, 30 Nov 2012 08:41:36 -0800 (PST) In-Reply-To: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> <50B8B9B0.9000700@ericsson.com> <50B8DB23.40704@jesup.org> From: Mark Rejhon Date: Fri, 30 Nov 2012 11:41:36 -0500 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:42:00 -0000 On Fri, Nov 30, 2012 at 11:26 AM, DRAGE, Keith (Keith) wrote: > Instant messaging and real time text are complementary forms of text communication. One does not replace the other. True. However, it's also an integration issue. -> You can handle real-time text separately of message-by-message (intersperse them). -> Or you can integrate real-time as part of the instant messaging methodology. The catch is protocols can be designed to make integration difficult or easier, so it becomes relevant as an interoperability issue. WebRTC should, ideally, be designed to permit either type of integration -- e.g. integrate real-time text into the existing message-by-message metaphor. This is where an understanding of the differences of T.140 and XEP-0301 becomes useful. T.140 is a continuous linear form of real-time text, similar to TTY/textphones, with no message breaks. XEP-0301 integrates real-time text into existing instant messages, with message boundaries. There are some linear ability with XEP-0301 if it is also combined with XEP-0308 Last Message Correction, so this helps T.140 transcoding to XEP-0301, to allow backspacing into the previous message, to maintain linear real-time text compatibility with T.140. (Gunnar Helstrom has also written a transcoder) (For those who missed it -- animation at http://www.realjabber.org/anim/real_time_text_demo.html -- useful for understanding real-time text from an instant messaging metaphor) Mark Rejhon Author of XEP-0301 In-Band Real-Time Text From richard@shockey.us Fri Nov 30 08:58:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBC721F8B5A for ; Fri, 30 Nov 2012 08:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4olCDNB3FPc1 for ; Fri, 30 Nov 2012 08:58:29 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 7BFB721F89BE for ; Fri, 30 Nov 2012 08:58:28 -0800 (PST) Received: (qmail 18060 invoked by uid 0); 30 Nov 2012 16:58:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 30 Nov 2012 16:58:06 -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=sGzOXleZy19olsTv6FQBoxb0SnbUqFeRVZZcR9FufHE=; b=RA3vluaX0blMHHKfzYO+0LyG2ACB6wxk9x4FrxY9oR1Uja/F2dvRhDUl5+hlqQyUcOdAAaNFFboaExNKc2nNSu+TospkgZxWMXngXbB2EjJGztXn662UwZsMAMVijbEF; Received: from [71.191.243.130] (port=53912 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TeTuf-00030y-U2 for rtcweb@ietf.org; Fri, 30 Nov 2012 09:58:06 -0700 From: "Richard Shockey" To: References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> In-Reply-To: <50B8AF72.9060909@omnitor.se> Date: Fri, 30 Nov 2012 11:58:03 -0500 Message-ID: <00ee01cdcf1b$dd1945a0$974bd0e0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01CDCEF1.F4433DA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3O+6tR+NpxAqL6T/SSNJXOWHyMnQAEOi7w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 16:58:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01CDCEF1.F4433DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Ok .. first =85 on the basic issue of the consensus call for Text Communications, IMHO this requirement needs to me met and MUST be incorporated into RTCWEB sessions at some point in time. =20 =20 This is simply unavoidable. =20 =20 Two I certainly support Bernard=92s approach here. Its clear there are multiple types of requirements for text messaging and we have multiple = ways if implementing them. Documenting those are the first step. Then = choose.=20 =20 Bernard also correctly points out the freight train of national = regulatory requirements coming from the US/Canada and additionally the EU as well. = =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Gunnar Hellstr=F6m Sent: Friday, November 30, 2012 8:07 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Text communication in RTCWEB sessions =20 On 2012-11-30 09:30, Harald Alvestrand wrote: So we're being asked to incorporate a standard that=20 * is not used yet Wrong, it is used, at least in Europe, and work well. * doesn't have technology push (the regulators need to mandate it)=20 This is just because of lack of making conclusions of observations on = how users are using IM today. Research reports indicate that all would be = more happy being provided with real-time text than message-wise IM. Users = need to adapt to the shortcomings of IM because no big service provider has yet provided real-time text together with other media in a conveniently available conversational tool.=20 There is user push among accessibility users and relay service personnel = who have acces to the technology. It is used and appreciated in text relay services, total conversation services, Sign relay services, IP text telephony services and captioned telephony services.=20 * doesn't have legal push (the regulators still haven't *decided* to = impose it)=20 It is very uncommon for legal requirements to point at specific implementation standards.=20 It is more common to require functionality -The requirements to provide the real-time text medium,=20 -the requirement to provide it in calls with aidio and video, -the quality requirements on real-time text - and the interoperability requirements are all there in the legal requirements. And a hint that RFC 4103 is a suitable way to arrange the = interoperability. =20 * is not the obviously right technology choice=20 Why not? There is currently one well working standard, mainly intended for use in SIP.=20 If IM is going to be enhanced to provide a real-time text feature within = the IM services, the XMPP extension in creation might be a valid alternative because it is so well integrated in the IM environment. But for interworking with SIP, RFC 4103 seems to be the choice. One important indication is that it is included in the NG112 and NG911 specifications for emergency services. So, what does rtcweb want to be, IM with real-time media additions and = SIP interworking, or real-time conversational service? Or both? Gunnar =20 ------=_NextPart_000_00EF_01CDCEF1.F4433DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Ok .. first … on the basic issue of the consensus call =A0for = Text Communications, =A0IMHO this requirement needs to me met and MUST = be incorporated into RTCWEB sessions at some point in time. = =A0

 

This is simply unavoidable. =A0=A0

 

Two=A0 I certainly support Bernard’s approach here. =A0Its = clear there are multiple types of requirements for text messaging and we = have multiple ways if implementing them. =A0Documenting those are the = first step. Then choose.

 

Bernard also correctly points out the freight train of national = regulatory requirements coming from the US/Canada and additionally the = EU as well. =A0

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Gunnar Hellstr=F6m
Sent: Friday, November 30, = 2012 8:07 AM
To: rtcweb@ietf.org
Subject: Re: = [rtcweb] Text communication in RTCWEB = sessions

 

On = 2012-11-30 09:30, Harald Alvestrand = wrote:

So = we're being asked to incorporate a standard that

* is not used = yet

Wrong, it is used, = at least in Europe, and work well.


* doesn't have technology push (the regulators = need to mandate it)

This is just = because of lack of making conclusions of observations on how users are = using IM today. Research reports indicate that all would be more happy = being provided with real-time text than message-wise IM. Users need to = adapt to the shortcomings of IM because no big service provider has yet = provided real-time text together with other media in a conveniently = available conversational tool.

There is user push among = accessibility users and relay service personnel who have acces to the = technology. It is used and appreciated in text relay services, total = conversation services, Sign relay services, IP text telephony services = and captioned telephony services.

* doesn't have legal push (the regulators still = haven't *decided* to impose it)

It is very uncommon for legal requirements to point at = specific implementation standards.
It is more common to require = functionality

-The requirements to provide the real-time text = medium,
-the requirement to provide it in calls with aidio and = video,
-the quality requirements on real-time text
- and the = interoperability requirements
 are all there in the legal = requirements.

And a hint that RFC 4103 is a suitable way to = arrange the interoperability.
 

* is not the obviously right technology choice =

Why not?

There is currently = one well working standard, mainly intended for use in SIP.

If IM = is going to be enhanced to provide a real-time text feature within the = IM services, the XMPP extension in creation might be a valid alternative = because it is so well integrated in the IM environment.
But for = interworking with SIP, RFC 4103 seems to be the choice. One important = indication is that it is included  in the NG112 and NG911 = specifications for emergency services.

So, what does rtcweb want = to be, IM with real-time media additions and SIP interworking, or = real-time conversational service?  Or = both?


Gunnar

 

------=_NextPart_000_00EF_01CDCEF1.F4433DA0-- From randell-ietf@jesup.org Fri Nov 30 09:05:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9A21F8B87 for ; Fri, 30 Nov 2012 09:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfaNIewWO52G for ; Fri, 30 Nov 2012 09:05:07 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0B41821F8B95 for ; Fri, 30 Nov 2012 09:05:07 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3853 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TeU1S-0006rx-JN for rtcweb@ietf.org; Fri, 30 Nov 2012 11:05:06 -0600 Message-ID: <50B8E71E.6030601@jesup.org> Date: Fri, 30 Nov 2012 12:04:30 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> <50B8B9B0.9000700@ericsson.com> <50B8DB23.40704@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] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 17:05:08 -0000 On 11/30/2012 11:26 AM, DRAGE, Keith (Keith) wrote: > There is a key reason why real time text is the preferred media for text rather than instant messaging for emergency calls. > Instant messaging and real time text are complementary forms of text communication. One does not replace the other. Sure, for emergency calls RTT is not surprising. However, that doesn't help us resolve this issue. We have two 'requirements' for text: Emergency Accessibility, and Accessibility to provide "equivalence" in FCC-ish terms. These may well not want to use the same solution. And even if they do in one country, they may not in another. And the required minimum solution may not be what the user prefers to use. We need to build something that can provide realtime communication to websites/web-apps/etc, and enable them to provide required and wished-for services to users all over the world, not just in the US or Europe (though those cover a large percentage of areas that mandate these functions for telephony). There are also ancillary "requirements" to gateway these conversations to existing infrastructures. (I'll note as an aside that the FCC is going to run into a thorny problem of "so, someone has a service with calling and it's based in Europe/Russia/Bangkok, and they don't comply with CVAA/E911/etc". Especially when it's free and there are no monetary payments they can hook into. I'm not going to try to solve it for them here.) I think standardizing "foo-over-DataChannels" for accessibility is the best solution, and then gateways can convert to "foo-over-SIP/RTP". (Note that there may be more than one "foo".) We agreed to add a "protocol" label to DataChannel creations, which should help inter-app interoperation for this by identifying the DataChannel is for "foo". This does mean that applications using webrtc that need to comply with CVAA/E911/etc (not all will) need to include "foo" in JS. For E911/etc they'll need to include support in their server-side code anyways for a bunch of other stuff to local PSAPs, etc. Alternatively we could provide support objects (at the W3C level) to help with providing RTT/whatever in JS; that would be there and not here. -- Randell Jesup randell-ietf@jesup.org From tterriberry@mozilla.com Fri Nov 30 09:51:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F98721F88C7 for ; Fri, 30 Nov 2012 09:51:41 -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 TzKGQdP6gWsa for ; Fri, 30 Nov 2012 09:51:39 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id AF5E421F85A4 for ; Fri, 30 Nov 2012 09:51:38 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 15E37F210E for ; Fri, 30 Nov 2012 09:51:38 -0800 (PST) Message-ID: <50B8F229.4010408@mozilla.com> Date: Fri, 30 Nov 2012 09:51:37 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B8E026.9090305@alvestrand.no> In-Reply-To: <50B8E026.9090305@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 17:51:41 -0000 Harald Alvestrand wrote: >> Please indicate your support or objections for this! > I object to adding such an use case. +1 From ted.ietf@gmail.com Fri Nov 30 10:17:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E253721F8A24 for ; Fri, 30 Nov 2012 10:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_20=-0.74, 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 ovRf4-yB5tOh for ; Fri, 30 Nov 2012 10:17:32 -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 04B9B21F89D7 for ; Fri, 30 Nov 2012 10:17:31 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so11156038vbb.17 for ; Fri, 30 Nov 2012 10:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=y6wN17UhlIvHb7xAmmWR30rE8t10Rp0/yliJ6/SkqX8=; b=s5IOSXMGm9RxpS57Bj/TWlW/VsT62HmT6Ogt0N0aN45LZJco1AEnZaJDMH49NjH0yN Ui+losBTN8b73DcrptgKBB0I19sIYWoYW+6nrzgX/QemULEZmf8UU572jY5/F61cNWHX vdl1cBQwHIJJVFDocEeESH702j11vHbDqgcDvd3Hur9CjAnVVdNK9mMR2+LY+R5zSa9D 2vo/ntrLjx+przDLs355Q2JumCImURQZukX91ycLrqa4sGWwEmVO0ivt8MpdPtYxS28I lEEhL8T0WqniMB2d2LISZyBEDTDgM9XbUl2plj8QnLWUfxaRNqCcMErhK5pRZxCgo1PD BiIg== MIME-Version: 1.0 Received: by 10.58.210.65 with SMTP id ms1mr1671926vec.59.1354299451259; Fri, 30 Nov 2012 10:17:31 -0800 (PST) Received: by 10.58.164.35 with HTTP; Fri, 30 Nov 2012 10:17:31 -0800 (PST) Date: Fri, 30 Nov 2012 10:17:31 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [rtcweb] Upcoming Interim meeting, co-located with 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: Fri, 30 Nov 2012 18:17:33 -0000 We will be holding an interim meeting, co-located with the relevant W3C folks, on February 5th-7th, 2013 in the Boston area. Many thanks to Hadriel Kaplan for hosting us. We have not yet established the time split between the groups; since one possible mechanism is for us to alternate morning and afternoon, please plan to be available for the full meeting time. regards, Ted Hardie, Cullen Jennings, Magnus Westerlund Details : Meeting site: Acme Packet 100 Crosby Drive Bedford, Massachusetts, 01730 TEL: 1-781-328-4400 http://www.acmepacket.com/company/contact-us/directions Breakfast, lunch and dinner will be provided on site. Hotels: The following are 15 minutes walk and also have complimentary shuttle service to/from Acme. Tell them you're staying for Acme Packet and you should get the discounted rate shown below. This may not be cheapest possible price, though, as prices fluctuate. DoubleTree by Hilton Hotel Doubletree discount price- $127 =96 corp. code 0002665706 Boston - Bedford Glen 44 Middlesex Turnpike Bedford, Massachusetts, 01730 TEL: 1-781-275-5500 http://doubletree3.hilton.com/en/hotels/massachusetts/doubletree-by-hilton-= hotel-boston-bedford-glen-BOSBFDT/index.html Hampton Inn Bedford - Burlington Hampton Inn discount price- $115 =96 corp. code 0002665706 25 Middlesex Turnpike Billerica, Massachusetts, 01821 TEL: 1-978-262-9977 http://hamptoninn3.hilton.com/en/hotels/massachusetts/hampton-inn-bedford-b= urlington-BOSBIHX/index.html Courtyard Boston Billerica Bedford Hotel is about 3 miles away, and also has an Acme discount and complimentary shuttle service to/from Acme (and it's a Marriott chain as compared to Hilton): Courtyard Marriott (Billerica) discount price- $130 =96 corp. code ACM 270 Concord Road Billerica, Massachusetts 01821 TEL: 1-978-670-7500 http://www.marriott.com/hotels/travel/bosbb-courtyard-boston-billerica-bedf= ord/ From bernard_aboba@hotmail.com Fri Nov 30 10:48:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B495121F8B72 for ; Fri, 30 Nov 2012 10:48:22 -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.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7PrgUY0rSY5 for ; Fri, 30 Nov 2012 10:48:21 -0800 (PST) Received: from blu0-omc4-s31.blu0.hotmail.com (blu0-omc4-s31.blu0.hotmail.com [65.55.111.170]) by ietfa.amsl.com (Postfix) with ESMTP id D482C21F8B1F for ; Fri, 30 Nov 2012 10:48:19 -0800 (PST) Received: from BLU002-W23 ([65.55.111.136]) by blu0-omc4-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Nov 2012 10:48:19 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c60b304e-5e18-45e4-8fbb-568a113ae25b_" X-Originating-IP: [131.107.0.116] From: Bernard Aboba To: Mark Rejhon , "rtcweb@ietf.org" Date: Fri, 30 Nov 2012 10:48:18 -0800 Importance: Normal In-Reply-To: References: <201211282145.qASLjanB1955372@shell01.TheWorld.com>, <50B686B9.90700@stpeter.im>, <1967120335-1354139633-cardhu_decombobulator_blackberry.rim.net-363948593-@b5.c9.bise6.blackberry>, , MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2012 18:48:19.0086 (UTC) FILETIME=[43C0BAE0:01CDCF2B] Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 18:48:22 -0000 --_c60b304e-5e18-45e4-8fbb-568a113ae25b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the additional detail=2C Mark. It is also perhaps useful to mak= e clear that XEP-0301 is compatible with a number of existing XMPP services= (including IM&P and MUC)=2C so that the RealJabber client can be run over = GoogleTalk (as an example) today. =20 Also=2C as was noted in the conversation surrounding the recent update to X= EP-0301=2C the document does describe a mechanism for encoding of RTT which= could be separated out from XMPP -- such as if someone wanted to use it to= encode/decode RTT just for use within their own website=2C without the nee= d to communicate with XMPP clients.=20 Given that XEP-0301 can be incorporated into web sites today (using the Str= ophe library=2C for example)=2C even sites that don't support WebRTC=2C one= of the questions we need to answer is exactly what functioning needs to be= native in the browser and what scenarios that would support=2C beyond what= is already possible with XEP-0301 today.=20 One scenario which seems beyond the XEP-0301 capability is the "911 RTT" sc= enario. This is not because of any limitation in XEP-0301 per se=2C but be= cause XMPP does not currently support emergency services. For example=2C t= he bare JID "911@example.com" could refer to an actual user within the exam= ple.com domain=2C so placing this bare JID within the "to:" field of an XMP= P message stanza would not necessarily result in a conversation with a PSAP= via an RFC 4103 gateway.=20 The other scenario which seems distinct is a scenario in which RTT is synch= ronized with audio/video. However=2C the discussion on this thread has p= ointed only to the need for loose synchronization=2C which would not necess= arily require peer-to-peer transport and also would not seem to require RFC= 4103 encoding in RTP=2C or even native RTTP support in the browser. =20 In terms of creating a new standard for RTT transport over the data channel= =2C I am sceptical. I could see utilizing the RTT encoding suggested in XE= P-0301 over a data channel=2C outside of XMPP stanzas. That would suffice = to provide RTT capabilities on a single site that is not attempting to fede= rate. =20 Going beyond that to creating an alternative transport for RFC 4103 does no= t seem helpful. If we are requiring a transport gateway to go from RTT ove= r SCTP to RFC 4103 over RTP=2C then we still have to touch every RTT packet= =2C as well as munging the SDP since an RFC 4103 endpoint will expect an "m= =3Dtext" line=2C not a data channel negotiation. This will introduce fragi= lity as well as latency. So I'm not clear that it gets us closer to implem= entation of any of the potential use cases.=20 > From: markybox@gmail.com > Date: Fri=2C 30 Nov 2012 11:00:02 -0500 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Text communication in RTCWEB sessions >=20 > [This message was sent two days ago=2C but got filtered. Resending.] >=20 > Hello=2C > I'm the author of XEP-0301 -- the Real-Time Text XMPP Extension > Protocol found at http://www.xmpp.org/extensions/xep-0301.html with > animations/demo software found at http://www.realjabber.org >=20 > > Subject: Re: [rtcweb] Text communication in RTCWEB sessions > > Date: Wed=2C 28 Nov 2012 16:45:36 -0500 (EST) > > From: worley@ariadne.com (Dale R. Worley) > > To: rtcweb@ietf.org > > > > Catching up on various messages: > > > > > From: Igor Faynberg > > > > > > In this case=2C would that mean that when I type something and then > > > want to correct it=2C backspaces would be transmitted=2C too? If so= =2C I > > > doubt it is useful. The second case=2C with the user having control > > > over sending of the message=2C is much better. > > > > There are possibilities for embarrassment with real-time text=2C in tha= t > > you don't have time to reconsider your words between typing them and > > hitting RETURN (which would send them in a message-oriented text > > system). > > > > One response to this is that a similar possibility exists in > > voice/video communication. And one can always configure one's RTT > > system to delay sending text until it sees a RETURN. >=20 > The XEP-0301 real-time text standard is oriented towards instant > messaging=2C and it enables visibility of all message edits (including > editing text in the middle of your sentence before sending your > message). This is necessary in instant messaging programs to allow > backwards compatibility with the user's pre-existing expectation of > backspacing/editing their message before sending the messages. >=20 > Examples of animations of how the real-time text integrates into > existing chat systems: >=20 > http://www.realjabber.org/anim/real_time_text_demo.html > ...(screenshot animation from RealJabber -- comparision with and > without real time=2C in messaging style metaphor) >=20 > http://www.realjabber.org/anim/facebook_chat_concept.gif > ...(concept animation of RTT being bolted-on into Facebook Chat=2C > illustrating seamless add-on) > ...(notice the "Fast Text Mode Enabled" notification) >=20 > As the XEP-0301 standard is designed to be backwards compatible=2C as a > client-only modification=2C and to run over existing XMPP networks with > no server modifications. Users typically edit and backspace messages > before sending=2C and that capability is kept even when real-time text > is enabled=2C to preserve user experience with existing instant message > interfaces. Also=2C there is an activation/deactivation mechanism > available=2C too. >=20 > The "I doubt it is useful" phrase (interpretable in multiple ways) > caught my attention... >=20 > Backspacing is useful text equivalent to a spoken "oops=2C let me > repeat" on the telephone=2C when you made a mistake and need to repeat > what you just said. On the same subject of telephone -- real-time > text is also useful for placing a telephone call silently -- sometimes > people need to urgently chat in real-time without waiting=2C but aren't > allowed to use voice with phones (e.g. restaurants=2C hospitals=2C > airplane WiFi=2C military covert chatting=2C emergency situations=2C > bedroom=2C etc). It is noted that typing on touchscreen is fairly > quiet. In private trials of my own software within my peer groups=2C > people preferred real-time text calls over video phone calls=2C as a > feature. People still appreciated the freedom to edit instant > messages the way they used to (continued instant messaging UI > familarity) even while the recipient is reading=2C and implementors can > choose to provide a software feature to turn on/off real-time text > even in mid-message-editing. >=20 > Also=2C being optimized as an RTT enhancement to message-by-message > chats=2C XEP-0301 also supports RTT group chats including mixed-mode > chats (e.g. RTT only from the leader=2C teacher or lecturer into a > groupchat=2C with everyone else message-by-message to prevent > distractions)=2C and remains compatible with RTT and non-RTT-supported > clients=2C either with all the existing message-line editing features=2C > including backspacing messages. >=20 > Although T.140 RTT isn't derived from instant messaging=2C the context > of how it can apply to instant messaging=2C is useful to know=2C and I > should note that Gunnar has a transcoder between T.140 RTT and my > XEP-0301 (We collaborate on the XEP-0301 spec=2C he is listed in the > credits) which takes advantage of the backspacing capability. >=20 >=20 > > > From: Gunnar Hellstrom > > > > > > The need for synchronization with audio and video is very relaxed > > > for RTT. I would assume that a second out of synch is easily > > > accepted. > > > > > > The one second end-to-end latency is probably slightly more > > > demanding=2C even if it also easy compared to audio and video > > > requirements. >=20 > Synch with audio/video is not a major issue in my experience for > real-time text. As long as the playout is smooth (both XEP-0301 and > T.140 have different methods of smooth text output)=2C many can tolerate > a 2 second delay=2C as it's not as real-time critical as voice or audio. > Ideally=2C 300ms or less is far better=2C of course=2C and both my > standards and Gunnar's standards use that figure. >=20 >=20 > > > My suggestion is instead of trying to jam an existing hack to "run > > > a reliable protocol over an unreliable channel" into the > > > implementations=2C to instead define running a well-known > > > reliable-channel text protocol over a reliable DataChannel (or > > > unreliable=2C if that makes more sense). > > > > Yes=2C text/red is a hack. But it's already used in the RTT world. > > (More about that below.) >=20 >=20 > On this topic=2C I should mention that XEP-0301 has a basic redundancy > mechanism too (section 4.6 to 4.6.3)=2C but it is very different from > the way T.140/RFC4103 RTT does it=2C and it permits recovery in > instant-messaging-releavant situations even a long time later (e.g. > loss of WiFI reception that also leads to disconnection=3B and the > reconnecting client (even on a separate device=2C separate software) > receives the re-transmitted contents of a long instant message still > being composed by the sender=2C without the sender noticing anything's > amiss. (The sender just notices the recipient disconnect and > reconnect while continuing to type a very long message that's much > longer to write=2C than the T.140 redundancy windows) (The recipient > sees the sender message-in-progress reappear upon reconnecting) >=20 > As a final note=2C even if T.140 is decided to be integrated into > WebRTC=2C that does not exclude other real-time text standards in the > future. I'd like to make sure JavaScript implementations of instant > messaging optimized real-time text standards (including XEP-0301=2C as > it XML payload format is also usable outside XMPP too) should still be > possible to be added by third party application developers taking > advantage of WebRTC. Preferred if it's still possible integrate > real-time text into the instant-messaging metaphor. >=20 > Mark Rejhon > Author of XEP-0301 -- XMPP based Real-Time Text > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_c60b304e-5e18-45e4-8fbb-568a113ae25b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks for the additional detail= =2C Mark. =3B It is also perhaps useful to make clear that XEP-0301 is = compatible with a number of existing XMPP services (including IM&=3BP an= d MUC)=2C so that the RealJabber client can be run over GoogleTalk (as an e= xample) today. =3B =3B

Also=2C as was noted in the conversa= tion surrounding the recent update to XEP-0301=2C the document does describ= e a mechanism for encoding of RTT which could be separated out from XMPP --= such as if someone wanted to use it to encode/decode RTT just for use with= in their own website=2C without the need to communicate with XMPP clients. =

Given that XEP-0301 can be incorporated into web sites today (using= the Strophe library=2C for example)=2C even sites that don't support WebRT= C=2C one of the questions we need to answer is exactly what functioning nee= ds to be native in the browser and what scenarios that would support=2C bey= ond what is already possible with XEP-0301 today.

One scenario whic= h seems beyond the XEP-0301 capability is the "911 RTT" scenario. =3B T= his is not because of any limitation in XEP-0301 per se=2C but because XMPP= does not currently support emergency services. =3B For example=2C the = bare JID "911@example.com" could refer to an actual user within the example= .com domain=2C so placing this bare JID within the "to:" field of an XMPP m= essage stanza would not necessarily result in a conversation with a PSAP vi= a an RFC 4103 gateway.

The other scenario which seems distinct is a= scenario in which RTT is synchronized with audio/video. =3B =3B Ho= wever=2C the discussion on this thread has =3B pointed only to the need= for loose synchronization=2C which would not necessarily require peer-to-p= eer transport and also would not seem to require RFC 4103 encoding in RTP= =2C or even native RTTP support in the browser. =3B

In terms of= creating a new standard for RTT transport over the data channel=2C I am sc= eptical. =3B I could see utilizing the RTT encoding suggested in XEP-03= 01 over a data channel=2C outside of XMPP stanzas. =3B That would suffi= ce to provide RTT capabilities on a single site that is not attempting to f= ederate. =3B

Going beyond that to creating an alternative trans= port for RFC 4103 does not seem helpful. =3B If we are requiring a tran= sport gateway to go from RTT over SCTP to RFC 4103 over RTP=2C then we stil= l have to touch every RTT packet=2C as well as munging the SDP since an RFC= 4103 endpoint will expect an "m=3Dtext" line=2C not a data channel negotia= tion. =3B This will introduce fragility as well as latency. =3B So = I'm not clear that it gets us closer to implementation of any of the potent= ial use cases.





>=3B From: markybox@gmail.com
>=3B Date: Fri=2C 30 Nov 2012 1= 1:00:02 -0500
>=3B To: rtcweb@ietf.org
>=3B Subject: Re: [rtcweb]= Text communication in RTCWEB sessions
>=3B
>=3B [This message w= as sent two days ago=2C but got filtered. Resending.]
>=3B
>=3B= Hello=2C
>=3B I'm the author of XEP-0301 -- the Real-Time Text XMPP E= xtension
>=3B Protocol found at http://www.xmpp.org/extensions/xep-030= 1.html with
>=3B animations/demo software found at http://www.realjabb= er.org
>=3B
>=3B >=3B Subject: Re: [rtcweb] Text communication= in RTCWEB sessions
>=3B >=3B Date: Wed=2C 28 Nov 2012 16:45:36 -050= 0 (EST)
>=3B >=3B From: worley@ariadne.com (Dale R. Worley)
>= =3B >=3B To: rtcweb@ietf.org
>=3B >=3B
>=3B >=3B Catching u= p on various messages:
>=3B >=3B
>=3B >=3B >=3B From: Igor = Faynberg <=3Bigor.faynberg@alcatel-lucent.com>=3B
>=3B >=3B >= =3B
>=3B >=3B >=3B In this case=2C would that mean that when I typ= e something and then
>=3B >=3B >=3B want to correct it=2C backspac= es would be transmitted=2C too? If so=2C I
>=3B >=3B >=3B doubt i= t is useful. The second case=2C with the user having control
>=3B &g= t=3B >=3B over sending of the message=2C is much better.
>=3B >=3B=
>=3B >=3B There are possibilities for embarrassment with real-time = text=2C in that
>=3B >=3B you don't have time to reconsider your wor= ds between typing them and
>=3B >=3B hitting RETURN (which would sen= d them in a message-oriented text
>=3B >=3B system).
>=3B >= =3B
>=3B >=3B One response to this is that a similar possibility exi= sts in
>=3B >=3B voice/video communication. And one can always conf= igure one's RTT
>=3B >=3B system to delay sending text until it sees= a RETURN.
>=3B
>=3B The XEP-0301 real-time text standard is ori= ented towards instant
>=3B messaging=2C and it enables visibility of a= ll message edits (including
>=3B editing text in the middle of your se= ntence before sending your
>=3B message). This is necessary in instan= t messaging programs to allow
>=3B backwards compatibility with the us= er's pre-existing expectation of
>=3B backspacing/editing their messag= e before sending the messages.
>=3B
>=3B Examples of animations = of how the real-time text integrates into
>=3B existing chat systems:<= br>>=3B
>=3B http://www.realjabber.org/anim/real_time_text_demo.htm= l
>=3B ...(screenshot animation from RealJabber -- comparision with an= d
>=3B without real time=2C in messaging style metaphor)
>=3B >=3B http://www.realjabber.org/anim/facebook_chat_concept.gif
>=3B = ...(concept animation of RTT being bolted-on into Facebook Chat=2C
>= =3B illustrating seamless add-on)
>=3B ...(notice the "Fast Text Mode = Enabled" notification)
>=3B
>=3B As the XEP-0301 standard is des= igned to be backwards compatible=2C as a
>=3B client-only modification= =2C and to run over existing XMPP networks with
>=3B no server modific= ations. Users typically edit and backspace messages
>=3B before sendi= ng=2C and that capability is kept even when real-time text
>=3B is ena= bled=2C to preserve user experience with existing instant message
>=3B= interfaces. Also=2C there is an activation/deactivation mechanism
>= =3B available=2C too.
>=3B
>=3B The "I doubt it is useful" phras= e (interpretable in multiple ways)
>=3B caught my attention...
>= =3B
>=3B Backspacing is useful text equivalent to a spoken "oops=2C l= et me
>=3B repeat" on the telephone=2C when you made a mistake and nee= d to repeat
>=3B what you just said. On the same subject of telephone= -- real-time
>=3B text is also useful for placing a telephone call si= lently -- sometimes
>=3B people need to urgently chat in real-time wit= hout waiting=2C but aren't
>=3B allowed to use voice with phones (e.g.= restaurants=2C hospitals=2C
>=3B airplane WiFi=2C military covert cha= tting=2C emergency situations=2C
>=3B bedroom=2C etc). It is noted th= at typing on touchscreen is fairly
>=3B quiet. In private trials of m= y own software within my peer groups=2C
>=3B people preferred real-tim= e text calls over video phone calls=2C as a
>=3B feature. People stil= l appreciated the freedom to edit instant
>=3B messages the way they u= sed to (continued instant messaging UI
>=3B familarity) even while the= recipient is reading=2C and implementors can
>=3B choose to provide a= software feature to turn on/off real-time text
>=3B even in mid-messa= ge-editing.
>=3B
>=3B Also=2C being optimized as an RTT enhancem= ent to message-by-message
>=3B chats=2C XEP-0301 also supports RTT gro= up chats including mixed-mode
>=3B chats (e.g. RTT only from the leade= r=2C teacher or lecturer into a
>=3B groupchat=2C with everyone else m= essage-by-message to prevent
>=3B distractions)=2C and remains compati= ble with RTT and non-RTT-supported
>=3B clients=2C either with all the= existing message-line editing features=2C
>=3B including backspacing = messages.
>=3B
>=3B Although T.140 RTT isn't derived from instan= t messaging=2C the context
>=3B of how it can apply to instant messagi= ng=2C is useful to know=2C and I
>=3B should note that Gunnar has a tr= anscoder between T.140 RTT and my
>=3B XEP-0301 (We collaborate on the= XEP-0301 spec=2C he is listed in the
>=3B credits) which takes advant= age of the backspacing capability.
>=3B
>=3B
>=3B >=3B &= gt=3B From: Gunnar Hellstrom <=3Bgunnar.hellstrom@omnitor.se>=3B
>= =3B >=3B >=3B
>=3B >=3B >=3B The need for synchronization with= audio and video is very relaxed
>=3B >=3B >=3B for RTT. I would a= ssume that a second out of synch is easily
>=3B >=3B >=3B accepted= .
>=3B >=3B >=3B
>=3B >=3B >=3B The one second end-to-end= latency is probably slightly more
>=3B >=3B >=3B demanding=2C eve= n if it also easy compared to audio and video
>=3B >=3B >=3B requi= rements.
>=3B
>=3B Synch with audio/video is not a major issue i= n my experience for
>=3B real-time text. As long as the playout is sm= ooth (both XEP-0301 and
>=3B T.140 have different methods of smooth te= xt output)=2C many can tolerate
>=3B a 2 second delay=2C as it's not a= s real-time critical as voice or audio.
>=3B Ideally=2C 300ms or les= s is far better=2C of course=2C and both my
>=3B standards and Gunnar'= s standards use that figure.
>=3B
>=3B
>=3B >=3B >=3B = My suggestion is instead of trying to jam an existing hack to "run
>= =3B >=3B >=3B a reliable protocol over an unreliable channel" into the<= br>>=3B >=3B >=3B implementations=2C to instead define running a well= -known
>=3B >=3B >=3B reliable-channel text protocol over a reliab= le DataChannel (or
>=3B >=3B >=3B unreliable=2C if that makes more= sense).
>=3B >=3B
>=3B >=3B Yes=2C text/red is a hack. But = it's already used in the RTT world.
>=3B >=3B (More about that below= .)
>=3B
>=3B
>=3B On this topic=2C I should mention that X= EP-0301 has a basic redundancy
>=3B mechanism too (section 4.6 to 4.6.= 3)=2C but it is very different from
>=3B the way T.140/RFC4103 RTT doe= s it=2C and it permits recovery in
>=3B instant-messaging-releavant si= tuations even a long time later (e.g.
>=3B loss of WiFI reception that= also leads to disconnection=3B and the
>=3B reconnecting client (even= on a separate device=2C separate software)
>=3B receives the re-trans= mitted contents of a long instant message still
>=3B being composed by= the sender=2C without the sender noticing anything's
>=3B amiss. (Th= e sender just notices the recipient disconnect and
>=3B reconnect whil= e continuing to type a very long message that's much
>=3B longer to wr= ite=2C than the T.140 redundancy windows) (The recipient
>=3B sees the= sender message-in-progress reappear upon reconnecting)
>=3B
>= =3B As a final note=2C even if T.140 is decided to be integrated into
&g= t=3B WebRTC=2C that does not exclude other real-time text standards in the<= br>>=3B future. I'd like to make sure JavaScript implementations of inst= ant
>=3B messaging optimized real-time text standards (including XEP-0= 301=2C as
>=3B it XML payload format is also usable outside XMPP too) = should still be
>=3B possible to be added by third party application d= evelopers taking
>=3B advantage of WebRTC. Preferred if it's still po= ssible integrate
>=3B real-time text into the instant-messaging metaph= or.
>=3B
>=3B Mark Rejhon
>=3B Author of XEP-0301 -- XMPP b= ased Real-Time Text
>=3B _____________________________________________= __
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
>=3B https:= //www.ietf.org/mailman/listinfo/rtcweb
= --_c60b304e-5e18-45e4-8fbb-568a113ae25b_-- From martin.thomson@gmail.com Fri Nov 30 10:49:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBB121F8B72 for ; Fri, 30 Nov 2012 10:49:24 -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 6b9XS0565Plp for ; Fri, 30 Nov 2012 10:49:24 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2021F8B75 for ; Fri, 30 Nov 2012 10:49:23 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so278472wey.31 for ; Fri, 30 Nov 2012 10:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=anC73ZOeHBRuIgCzm6DHi2b9/F13aIX6jqsffpjk0OM=; b=zmZ9fWqIV0AOCP/QvmHtvop430tGcW4d5ziEzV45Xp3dESEDK8SkqhSlnaV7gs+3ra zvE8gEaa0MQZoBW6Zcm6Z/z9DPWG35gAkVl77Vcv1JD3+WVdKRq9Xe/iUXRLQHuJmMsE KA0YVKGBRJC7xEG9X2Ro5HOSKS3V0ri7wqb2KHR1GMfdTmEgDRnJ+9RYHzPG6b77g/Gl +kCr5jUvbswP22j7kpZEHSeZm6bei8D0ApVH1VnyIUvuFTnJsmlJ9vgNxA3VAsr67auz L1pdHPinSV9v82jpj/mhteP7c6riRFSiSycxkkQqb7/O6zTXza8RT3bJ9q0MPt1xQk1L zuEA== MIME-Version: 1.0 Received: by 10.180.102.40 with SMTP id fl8mr3418663wib.22.1354301360118; Fri, 30 Nov 2012 10:49:20 -0800 (PST) Received: by 10.180.103.8 with HTTP; Fri, 30 Nov 2012 10:49:20 -0800 (PST) In-Reply-To: References: <50B87606.5030802@ericsson.com> Date: Fri, 30 Nov 2012 10:49:20 -0800 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 18:49:25 -0000 On 30 November 2012 01:06, Bernard Aboba wrote: > I do not think that a use case on text communications would solve the > problem by itself. The reality is that realtime text can be used in a > number of different ways, which will generate different implementation > requirements. Rather than trying to boil this down into a single use case, > it makes more sense to me to have a document that explains the uses that are > envisaged and the resulting implementation requirements. If we had such a > document, the use case document could refer to it. +1 At this point I have choice but to object. As pointed out in several different ways, submitting use cases in piecemeal to the list is insufficient. A document describing how RTT fits into the larger context might let me make a more informed choice about the right technical solution. From adam@nostrum.com Fri Nov 30 11:01:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047B321F8471 for ; Fri, 30 Nov 2012 11:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GidN6TnS4H+0 for ; Fri, 30 Nov 2012 11:01:13 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BE90521F84E1 for ; Fri, 30 Nov 2012 11:01:12 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAUJ0sT0059549 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 30 Nov 2012 13:00:55 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50B90266.4030003@nostrum.com> Date: Fri, 30 Nov 2012 13:00:54 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Thomson References: <50B87606.5030802@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 19:01:14 -0000 On 11/30/12 12:49, Martin Thomson wrote: > On 30 November 2012 01:06, Bernard Aboba wrote: >> I do not think that a use case on text communications would solve the >> problem by itself. The reality is that realtime text can be used in a >> number of different ways, which will generate different implementation >> requirements. Rather than trying to boil this down into a single use case, >> it makes more sense to me to have a document that explains the uses that are >> envisaged and the resulting implementation requirements. If we had such a >> document, the use case document could refer to it. > +1 > > At this point I have choice but to object. As pointed out in several > different ways, submitting use cases in piecemeal to the list is > insufficient. A document describing how RTT fits into the larger > context might let me make a more informed choice about the right > technical solution. I also agree with Bernard. While a coherent use case document would be helpful, I think the requirements would be far, far more important. I have a very strong suspicion that any reasonable set of requirements on user-perceived behavior can be satisfied using existing web browser technologies without imposing any additional work on the WebRTC specifications. Putting pen to paper to detail actual user experience requirements would show if and where my suspicions are wrong. /a From randell-ietf@jesup.org Fri Nov 30 11:30:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1A921F862E for ; Fri, 30 Nov 2012 11:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCOJgegA5QpD for ; Fri, 30 Nov 2012 11:30:41 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE3E21F8616 for ; Fri, 30 Nov 2012 11:30:40 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1317 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TeWIK-0007ko-DX for rtcweb@ietf.org; Fri, 30 Nov 2012 13:30:40 -0600 Message-ID: <50B9093C.40002@jesup.org> Date: Fri, 30 Nov 2012 14:30:04 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 19:30:41 -0000 On 11/30/2012 1:49 PM, Martin Thomson wrote: > On 30 November 2012 01:06, Bernard Aboba wrote: >> I do not think that a use case on text communications would solve the >> problem by itself. The reality is that realtime text can be used in a >> number of different ways, which will generate different implementation >> requirements. Rather than trying to boil this down into a single use case, >> it makes more sense to me to have a document that explains the uses that are >> envisaged and the resulting implementation requirements. If we had such a >> document, the use case document could refer to it. > +1 > > At this point I have choice but to object. As pointed out in several > different ways, submitting use cases in piecemeal to the list is > insufficient. A document describing how RTT fits into the larger > context might let me make a more informed choice about the right > technical solution. +1 A document would be a good start, looking at the constraints, available technologies and possible solutions. We've pointed out here that the problem and solution space is ... interesting, with lots of issues and needs to predict future needs. And lots of constraints. -- Randell Jesup randell-ietf@jesup.org From gunnar.hellstrom@omnitor.se Fri Nov 30 12:17:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49F821F8430 for ; Fri, 30 Nov 2012 12:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEJ21FLlVJjW for ; Fri, 30 Nov 2012 12:17:22 -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 DBECA21F841E for ; Fri, 30 Nov 2012 12:17:16 -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 ; Fri, 30 Nov 2012 21:17:08 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id AC24B3A141 for ; Fri, 30 Nov 2012 21:17:08 +0100 (CET) Message-ID: <50B91448.8080908@omnitor.se> Date: Fri, 30 Nov 2012 21:17:12 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> In-Reply-To: <50B90266.4030003@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 20:17:23 -0000 On 2012-11-30 20:00, Adam Roach wrote: > On 11/30/12 12:49, Martin Thomson wrote: >> On 30 November 2012 01:06, Bernard Aboba >> wrote: >>> I do not think that a use case on text communications would solve the >>> problem by itself. The reality is that realtime text can be used in a >>> number of different ways, which will generate different implementation >>> requirements. Rather than trying to boil this down into a single >>> use case, >>> it makes more sense to me to have a document that explains the uses >>> that are >>> envisaged and the resulting implementation requirements. If we had >>> such a >>> document, the use case document could refer to it. >> +1 >> >> At this point I have choice but to object. As pointed out in several >> different ways, submitting use cases in piecemeal to the list is >> insufficient. A document describing how RTT fits into the larger >> context might let me make a more informed choice about the right >> technical solution. > > I also agree with Bernard. While a coherent use case document would be > helpful, I think the requirements would be far, far more important. > > I have a very strong suspicion that any reasonable set of requirements > on user-perceived behavior can be satisfied using existing web browser > technologies without imposing any additional work on the WebRTC > specifications. Putting pen to paper to detail actual user experience > requirements would show if and where my suspicions are wrong. A document describing the requirements quite thoroughly both from users' view and technically, and describing some available implementations is ETSI EG 202 320 Duplex Universal Speech and Text http://www.etsi.org/deliver/etsi_eg/202300_202399/202320/01.02.01_60/eg_202320v010201p.pdf From gunnar.hellstrom@omnitor.se Fri Nov 30 13:17:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0921F8487 for ; Fri, 30 Nov 2012 13:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IjmxjYKba3s for ; Fri, 30 Nov 2012 13:17:14 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 60B0E21F8476 for ; Fri, 30 Nov 2012 13:17:14 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 30 Nov 2012 22:17:06 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id CDC373A13B for ; Fri, 30 Nov 2012 22:17:06 +0100 (CET) Message-ID: <50B92256.8050502@omnitor.se> Date: Fri, 30 Nov 2012 22:17:10 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B91448.8080908@omnitor.se> In-Reply-To: <50B91448.8080908@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 21:17:15 -0000 Also RFC 5194 describes the requirements quite well. There is also a short requirements chapter in draft XEP-0301, maybe much less describing the usage but more as a starting point for adding real-time text to the XMPP environment. See http://xmpp.org/extensions/xep-0301.html It is much better if the feature can be seen as being of mainstream interest as well as of accessibility interest rather than something introduced because of regulated accessibility requirements. But if that is not achievable right now, we need to fall back to pointing at accessiblity regulation to get it specified and implemented. I think we have repeated the basic requirements many times already, but here they are again: 1. The important things are that real-time text usage together with rtcweb/webrtc gets specified consistently enough to achieve wide-spread interoperable implementation together with audio and video in the same session. 2. Interworking with SIP calls with all three media and real-time text using RFC 4103 shall be possible. 3. Presentation of characters shall be possible within two seconds after keypress or other entry (but one second is preferred). 4. An entry and transmission rate up to 30 characters per second shall be supported( to allow also speech to text applications ) 5. Text needs to be able to be expressed in any character set internationally ( implying UTF-8 transmission). 6. Text needs to have not more than 0.2% errors in environments where video and audio are regarded usable. 7. It is valuable if places for possible text loss because of transmission errors can be shown in the received text. 8. Editing shall be possible, at least erasing text and appending text and new lines. 9. Addressing, calling and connection of all three media together shall be possible in one simple user operation. 10. Multiparty, call transfer, call hold shall be possible and act on all the established media. 11. Adding or deleting any of the three media shall be possible during a session. Usage will be any human text conversation spanning from occasional adding of small items of text during a voice or video call, to a call where the majority of conversational interaction is done by real-time text. Gunnar On 2012-11-30 21:17, Gunnar Hellström wrote: > On 2012-11-30 20:00, Adam Roach wrote: >> On 11/30/12 12:49, Martin Thomson wrote: >>> On 30 November 2012 01:06, Bernard Aboba >>> wrote: >>>> I do not think that a use case on text communications would solve the >>>> problem by itself. The reality is that realtime text can be used in a >>>> number of different ways, which will generate different implementation >>>> requirements. Rather than trying to boil this down into a single >>>> use case, >>>> it makes more sense to me to have a document that explains the uses >>>> that are >>>> envisaged and the resulting implementation requirements. If we had >>>> such a >>>> document, the use case document could refer to it. >>> +1 >>> >>> At this point I have choice but to object. As pointed out in several >>> different ways, submitting use cases in piecemeal to the list is >>> insufficient. A document describing how RTT fits into the larger >>> context might let me make a more informed choice about the right >>> technical solution. >> >> I also agree with Bernard. While a coherent use case document would >> be helpful, I think the requirements would be far, far more important. >> >> I have a very strong suspicion that any reasonable set of >> requirements on user-perceived behavior can be satisfied using >> existing web browser technologies without imposing any additional >> work on the WebRTC specifications. Putting pen to paper to detail >> actual user experience requirements would show if and where my >> suspicions are wrong. > A document describing the requirements quite thoroughly both from > users' view and technically, and describing some available > implementations is ETSI EG 202 320 Duplex Universal Speech and Text > http://www.etsi.org/deliver/etsi_eg/202300_202399/202320/01.02.01_60/eg_202320v010201p.pdf > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gunnar.hellstrom@omnitor.se Fri Nov 30 13:58:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C4121F85C7 for ; Fri, 30 Nov 2012 13:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFdzlPTybdZX for ; Fri, 30 Nov 2012 13:58:41 -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 10E4221F859E for ; Fri, 30 Nov 2012 13:58:40 -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 ; Fri, 30 Nov 2012 22:58:13 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 104693A1E1 for ; Fri, 30 Nov 2012 22:58:13 +0100 (CET) Message-ID: <50B92BF8.2090303@omnitor.se> Date: Fri, 30 Nov 2012 22:58:16 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> In-Reply-To: <50B90266.4030003@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 21:58:42 -0000 It has been said a number of times that the rtcweb data channel would be suitable for real-time text. I have also seen doubts about that expressed. One alerting doubt was that it did not seem to have well established implementations. And the protocol spec is very thick. It might take a long time before it is implemented with reliable function and good interoperability. Right? I would like to know more about the data channel. How much overhead is it per transmission? Is it possible to specify capability negotiation of features using the data channel? Does that require additions to the specs. There are indications that the data channel can be used in reliable and unreliable mode. Does the reliable mode have the risk for stalled communication that is common for reliable protocols? How is the mode controlled? In what way would it be better to use the data channel than RTP with redundancy? Gunnar On 2012-11-30 20:00, Adam Roach wrote: > On 11/30/12 12:49, Martin Thomson wrote: >> On 30 November 2012 01:06, Bernard Aboba >> wrote: >>> I do not think that a use case on text communications would solve the >>> problem by itself. The reality is that realtime text can be used in a >>> number of different ways, which will generate different implementation >>> requirements. Rather than trying to boil this down into a single >>> use case, >>> it makes more sense to me to have a document that explains the uses >>> that are >>> envisaged and the resulting implementation requirements. If we had >>> such a >>> document, the use case document could refer to it. >> +1 >> >> At this point I have choice but to object. As pointed out in several >> different ways, submitting use cases in piecemeal to the list is >> insufficient. A document describing how RTT fits into the larger >> context might let me make a more informed choice about the right >> technical solution. > > I also agree with Bernard. While a coherent use case document would be > helpful, I think the requirements would be far, far more important. > > I have a very strong suspicion that any reasonable set of requirements > on user-perceived behavior can be satisfied using existing web browser > technologies without imposing any additional work on the WebRTC > specifications. Putting pen to paper to detail actual user experience > requirements would show if and where my suspicions are wrong. > > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Fri Nov 30 14:21:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B932A21F8533 for ; Fri, 30 Nov 2012 14:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBs2dOqB1oP0 for ; Fri, 30 Nov 2012 14:21:44 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C4CFB21F852A for ; Fri, 30 Nov 2012 14:21:44 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2458 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TeYxr-000Bi5-Vq for rtcweb@ietf.org; Fri, 30 Nov 2012 16:21:44 -0600 Message-ID: <50B93153.50109@jesup.org> Date: Fri, 30 Nov 2012 17:21:07 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B91448.8080908@omnitor.se> <50B92256.8050502@omnitor.se> In-Reply-To: <50B92256.8050502@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 22:21:45 -0000 On 11/30/2012 4:17 PM, Gunnar Hellström wrote: > Also RFC 5194 describes the requirements quite well. > > There is also a short requirements chapter in draft XEP-0301, maybe > much less describing the usage but more as a starting point for adding > real-time text to the XMPP environment. > See http://xmpp.org/extensions/xep-0301.html > > It is much better if the feature can be seen as being of mainstream > interest as well as of accessibility interest rather than something > introduced because of regulated accessibility requirements. But if > that is not achievable right now, we need to fall back to pointing at > accessiblity regulation to get it specified and implemented. I think the protocols likely to be mandated for accessibility and emergency use are not what would likely be preferred by applications for general use (which likely would be much higher featured, and selected and controlled by the apps. > > I think we have repeated the basic requirements many times already, > but here they are again: > > 1. The important things are that real-time text usage together with > rtcweb/webrtc gets specified consistently enough to achieve > wide-spread interoperable implementation together with audio and video > in the same session. This is the strongest point, IMHO. Though most uses (excluding emergency uses) will be homogenous apps, not heterogeneous - Unlike SIP UAs and hard endpoints, many users will use the app for the service to contact someone on that service, not depend on federation to connect their in-the-home-hardware to someone elses different hardware UA. There will be exceptions to this where big services set up peering with others, or different apps from the same provider get used. Still, this is important to do - though depending on where and how it might not be directly part of rtcweb. > 2. Interworking with SIP calls with all three media and real-time text > using RFC 4103 shall be possible. > 3. Presentation of characters shall be possible within two seconds > after keypress or other entry (but one second is preferred). > 4. An entry and transmission rate up to 30 characters per second shall > be supported( to allow also speech to text applications ) > 5. Text needs to be able to be expressed in any character set > internationally ( implying UTF-8 transmission). > 6. Text needs to have not more than 0.2% errors in environments where > video and audio are regarded usable. > 7. It is valuable if places for possible text loss because of > transmission errors can be shown in the received text. > 8. Editing shall be possible, at least erasing text and appending text > and new lines. > 9. Addressing, calling and connection of all three media together > shall be possible in one simple user operation. > 10. Multiparty, call transfer, call hold shall be possible and act on > all the established media. > 11. Adding or deleting any of the three media shall be possible during > a session. The last several items are in the domain (largely or entirely) of the application and service provider providing it, unless we want to bake the display and text-entry directly into media elements. The application has to capture keystrokes somewhere, do any local editing, send them to the other side (via whatever - datachannel or "text" mediastream). I do NOT think we'll be baking those directly into the browser; it ties the hands of the apps too much. So likely (to support this) there will be JS libraries anyways - so that could also abstract from the app the actual channel used (DataChannel vs. MediaStreams) and also the actual protocol as well. If we bake it into the core, it is less likely to have bugs (and they'll get fixed faster, probably), but likely it will become a least-common-denominator that is painful for apps to rise above. If this is in a JS library, it can handle basic accessibility and emergency use, but people can add support for more than just the minimum fairly easily (fork it, etc). What I don't want is something where the UI interaction or display is locked down into the browser (type into the video element, fixed-style subtitle displays where there's no opportunity for UI improvements and alternate layouts/interactions). -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Fri Nov 30 14:37:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5A821F8607 for ; Fri, 30 Nov 2012 14:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJOoenTDN0eb for ; Fri, 30 Nov 2012 14:37:31 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id AC6CE21F8675 for ; Fri, 30 Nov 2012 14:37:31 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2486 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TeZD8-000G8i-M8 for rtcweb@ietf.org; Fri, 30 Nov 2012 16:37:31 -0600 Message-ID: <50B93506.3090509@jesup.org> Date: Fri, 30 Nov 2012 17:36:54 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50B87606.5030802@ericsson.com> <50B90266.4030003@nostrum.com> <50B92BF8.2090303@omnitor.se> In-Reply-To: <50B92BF8.2090303@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Consensus call on Text Communication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Nov 2012 22:37:32 -0000 On 11/30/2012 4:58 PM, Gunnar Hellström wrote: > It has been said a number of times that the rtcweb data channel would > be suitable for real-time text. > > I have also seen doubts about that expressed. > > One alerting doubt was that it did not seem to have well established > implementations. And the protocol spec is very thick. It might take a > long time before it is implemented with reliable function and good > interoperability. Right? The protocol spec is tiny (draft-jesup-rtcweb-data-protocol). If you're thinking SCTP, yes it's large - so are UDP and TCP, and it does a lot more. It's used a lot in telephony; very little on the open web. > I would like to know more about the data channel. > > How much overhead is it per transmission? Not a lot. The rtcweb DataChannel protocol adds nothing to a datagram. SCTP is slightly larger than TCP IIRC, not a lot. Ask Michael Tuexen or Randall Stewart; maintainers of SCTP and authors on the spec who are working with us. > Is it possible to specify capability negotiation of features using the > data channel? yes > Does that require additions to the specs. No, you can specify them at channel open time (see the draft), or (proposed) in negotiation (draft-mmusic-sdp-something). > There are indications that the data channel can be used in reliable > and unreliable mode. Does the reliable mode have the risk for stalled > communication that is common for reliable protocols? How is the mode > controlled? Reliable can stall (like any reliable protocol). You can specify partially-reliable which is probably what you really want: limited time or number of retransmissions (settable by the app). You can also specify only in-order delivery. You can even have out-of-order delivery with reliable (which removes almost all head-of-line blocking; you'll need some internal framing to properly deal with out-of-order delivery of course as with any such). > > In what way would it be better to use the data channel than RTP with > redundancy? Redundancy is a hammer; SCTP allows smarter options with retransmission only where needed. Reliable out-of-order delivery might be perfect for this use (as I believe it will eventually get the data through if the channel is in any way usable). You can have multiple channels used for different purposes, with different reliability settings. > > Gunnar > > > On 2012-11-30 20:00, Adam Roach wrote: >> On 11/30/12 12:49, Martin Thomson wrote: >>> On 30 November 2012 01:06, Bernard Aboba >>> wrote: >>>> I do not think that a use case on text communications would solve the >>>> problem by itself. The reality is that realtime text can be used in a >>>> number of different ways, which will generate different implementation >>>> requirements. Rather than trying to boil this down into a single >>>> use case, >>>> it makes more sense to me to have a document that explains the uses >>>> that are >>>> envisaged and the resulting implementation requirements. If we had >>>> such a >>>> document, the use case document could refer to it. >>> +1 >>> >>> At this point I have choice but to object. As pointed out in several >>> different ways, submitting use cases in piecemeal to the list is >>> insufficient. A document describing how RTT fits into the larger >>> context might let me make a more informed choice about the right >>> technical solution. >> >> I also agree with Bernard. While a coherent use case document would >> be helpful, I think the requirements would be far, far more important. >> >> I have a very strong suspicion that any reasonable set of >> requirements on user-perceived behavior can be satisfied using >> existing web browser technologies without imposing any additional >> work on the WebRTC specifications. Putting pen to paper to detail >> actual user experience requirements would show if and where my >> suspicions are wrong. >> >> /a >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Randell Jesup randell-ietf@jesup.org From gunnar.hellstrom@omnitor.se Fri Nov 30 22:59:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C449421F8564 for ; Fri, 30 Nov 2012 22:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX4Zgv-wr330 for ; Fri, 30 Nov 2012 22:59:04 -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 EF7EA21F84FB for ; Fri, 30 Nov 2012 22:59:01 -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, 1 Dec 2012 07:58:53 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 0AEE03A1DF for ; Sat, 1 Dec 2012 07:58:53 +0100 (CET) Message-ID: <50B9AAB0.10709@omnitor.se> Date: Sat, 01 Dec 2012 07:58:56 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201211121714.qACHEMoq914291@shell01.TheWorld.com> <50A13860.8050900@omnitor.se> <201211282145.qASLjanB1955372@shell01.TheWorld.com> <50B86EB8.2050700@alvestrand.no> <50B8AF72.9060909@omnitor.se> In-Reply-To: <50B8AF72.9060909@omnitor.se> Content-Type: multipart/alternative; boundary="------------060408060902010904010100" Subject: Re: [rtcweb] Text communication in RTCWEB sessions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 06:59:06 -0000 This is a multi-part message in MIME format. --------------060408060902010904010100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I said below that there are research indications that IM users would like real-time text functionality in IM, but I did not provide any references and explanations. Here they are: ---------------------------------------------------------------------------------------------------- Research references showing that mainstream IM users would be more happy with using real-time text: 1. RIM usability study show that mainstream users prefer real-time text over Instant Messaging. http://transition.fcc.gov/cgb/dro/EAAC/usability_study_results.pdf 2. Usage of IM research: http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf This research says that average message length in IM was just below 30 characters per message, and average rate was 6 messages per minute in the sessions they studied. That clearly indicates that users artificially shortens their messages in order to send something sooner than regular composition of complete messages would require. They squeeze the messaging tool to do a not fully satisfactory pseudo-real-time text behavior. 3. Do-it-yourself research: Ask a small group of people: a. Have you ever felt a bit of stress to complete your message or even shortened off your message when using Instant Messaging so that the other party would get a chance to take part of your thoughts soon enough? b. Have you ever thought when waiting for a message in IM that you would like to get a view of what the other party is typing? c. Have you ever experienced that you or the other party in an Instant Messaging exchange has typed a message while the other party is also composing a message, causing cross-posting and two threads in the same dialogue and a risk for misunderstanding of what response belongs to what question? If you see a smile of recognition or get a yes on at least one of these questions, you have identified a market case for introducing a real-time text feature in the Instant Messaging environment, or providing a real-time text feature in the real-time video and audio calls. I tried this sequence of questions on two persons last Tuesday, in a meeting on accessible emergency services, and I got both recognizing smiles and yes responses. Why not give users what they want? Gunnar --------------------------------------------------------------------------------------------- On 2012-11-30 14:06, Gunnar Hellström wrote: > On 2012-11-30 09:30, Harald Alvestrand wrote: >> So we're being asked to incorporate a standard that >> >> * is not used yet > Wrong, it is used, at least in Europe, and work well. >> >> * doesn't have technology push (the regulators need to mandate it) > This is just because of lack of making conclusions of observations on > how users are using IM today. Research reports indicate that all would > be more happy being provided with real-time text than message-wise IM. > Users need to adapt to the shortcomings of IM because no big service > provider has yet provided real-time text together with other media in > a conveniently available conversational tool. > > There is user push among accessibility users and relay service > personnel who have acces to the technology. It is used and appreciated > in text relay services, total conversation services, Sign relay > services, IP text telephony services and captioned telephony services. >> * doesn't have legal push (the regulators still haven't *decided* to >> impose it) > It is very uncommon for legal requirements to point at specific > implementation standards. > It is more common to require functionality > > -The requirements to provide the real-time text medium, > -the requirement to provide it in calls with aidio and video, > -the quality requirements on real-time text > - and the interoperability requirements > are all there in the legal requirements. > > And a hint that RFC 4103 is a suitable way to arrange the > interoperability. > >> * is not the obviously right technology choice > Why not? > > There is currently one well working standard, mainly intended for use > in SIP. > > If IM is going to be enhanced to provide a real-time text feature > within the IM services, the XMPP extension in creation might be a > valid alternative because it is so well integrated in the IM environment. > But for interworking with SIP, RFC 4103 seems to be the choice. One > important indication is that it is included in the NG112 and NG911 > specifications for emergency services. > > So, what does rtcweb want to be, IM with real-time media additions and > SIP interworking, or real-time conversational service? Or both? > > > Gunnar > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060408060902010904010100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I said below that there are research indications that IM users would like real-time text functionality in IM, but I did not provide any references and explanations. Here they are:

----------------------------------------------------------------------------------------------------
Research references showing that mainstream IM users would be more happy with using real-time text:


1. RIM usability study show that mainstream users prefer real-time text over Instant Messaging.
http://transition.fcc.gov/cgb/dro/EAAC/usability_study_results.pdf


2. Usage of IM research:
http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf

This research says that average message length in IM was just below 30 characters per message, and average rate was 6 messages per minute in the sessions they studied.
That clearly indicates that users artificially shortens their messages in order to send something sooner than regular composition of complete messages would require.  They squeeze the messaging tool to do a not fully satisfactory pseudo-real-time text behavior.

3. Do-it-yourself research:
Ask a small group of people:

a. Have you ever felt a bit of stress to complete your message or even shortened off your message when using Instant Messaging so that the other party would get a chance to take part of your thoughts soon enough?

b. Have you ever thought when waiting for a message in IM that you would like to get a view of what the other party is typing?

c. Have you ever experienced that you or the other party in an Instant Messaging exchange has typed a message while the other party is also composing a message, causing cross-posting and two threads in the same dialogue and a risk for misunderstanding of what response belongs to what question?

If you see a smile of recognition or get a yes on at least one of these questions, you have identified a market case for introducing a real-time text feature in the Instant Messaging environment, or providing a real-time text feature in the real-time video and audio calls.
I tried this sequence of questions on two persons last Tuesday, in a meeting on accessible emergency services, and I got both recognizing smiles and yes responses.

Why not give users what they want?

Gunnar

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

On 2012-11-30 14:06, Gunnar Hellström wrote:
On 2012-11-30 09:30, Harald Alvestrand wrote:
So we're being asked to incorporate a standard that

* is not used yet
Wrong, it is used, at least in Europe, and work well.

* doesn't have technology push (the regulators need to mandate it)
This is just because of lack of making conclusions of observations on how users are using IM today. Research reports indicate that all would be more happy being provided with real-time text than message-wise IM. Users need to adapt to the shortcomings of IM because no big service provider has yet provided real-time text together with other media in a conveniently available conversational tool.

There is user push among accessibility users and relay service personnel who have acces to the technology. It is used and appreciated in text relay services, total conversation services, Sign relay services, IP text telephony services and captioned telephony services.
* doesn't have legal push (the regulators still haven't *decided* to impose it)
It is very uncommon for legal requirements to point at specific implementation standards.
It is more common to require functionality

-The requirements to provide the real-time text medium,
-the requirement to provide it in calls with aidio and video,
-the quality requirements on real-time text
- and the interoperability requirements
 are all there in the legal requirements.

And a hint that RFC 4103 is a suitable way to arrange the interoperability.
 
* is not the obviously right technology choice
Why not?

There is currently one well working standard, mainly intended for use in SIP.

If IM is going to be enhanced to provide a real-time text feature within the IM services, the XMPP extension in creation might be a valid alternative because it is so well integrated in the IM environment.
But for interworking with SIP, RFC 4103 seems to be the choice. One important indication is that it is included  in the NG112 and NG911 specifications for emergency services.

So, what does rtcweb want to be, IM with real-time media additions and SIP interworking, or real-time conversational service?  Or both?


Gunnar

 


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

--------------060408060902010904010100--