Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes)

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 31 May 2013 19:09 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2439D21F99B3 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 12:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.998
X-Spam-Level:
X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOAyuSfbk2Nv for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 12:09:54 -0700 (PDT)
Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by ietfa.amsl.com (Postfix) with ESMTP id A24EF21F92C5 for <rtcweb@ietf.org>; Fri, 31 May 2013 12:09:50 -0700 (PDT)
Received: from BLU169-W71 ([65.55.111.137]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 31 May 2013 12:09:49 -0700
X-TMN: [pwaPbZ76iL5kaP0sZGdcBeJqI7ssQCCF]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W7138C68A20F97A00503CFC93920@phx.gbl>
Content-Type: multipart/alternative; boundary="_9b3daf0c-6f59-402c-90b8-0146721b67e1_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Mark Rejhon <markybox@gmail.com>
Date: Fri, 31 May 2013 12:09:49 -0700
Importance: Normal
In-Reply-To: <CAA79oDkcKr6rWy=uJe2P7TuabiUeizJoHqtRMs=zYK7z3AW8OQ@mail.gmail.com>
References: <CAA79oDkcKr6rWy=uJe2P7TuabiUeizJoHqtRMs=zYK7z3AW8OQ@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 31 May 2013 19:09:49.0607 (UTC) FILETIME=[6C251B70:01CE5E32]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2013 19:09:58 -0000

Thanks, Mark.  could you say a few words about the status of the XEP-0301 JavaScript implementation?  As I understand it, this was done as an extension to Strophe, which now supports the XMPP over Websockets draft in the beta builds.  
 
From: markybox@gmail.com
Date: Fri, 31 May 2013 15:03:51 -0400
To: ibc@aliax.net
CC: rtcweb@ietf.org
Subject: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes)

Although this is not 100% webrtc related, it has implications, since Gunnar (RFC4103) worked with me as the co-author of XEP-0301, so I want to write this to help people understand that RTT is not necessarily always peer-to-peer.


-- Federated network-to-network compatible.    Anything federated will interop with each other for RTT. (e.g. Lync RTT reaches Cisco WebEx RTT)
Neat Demonstration of XEP-0301 interoperability in multiple XMPP clients (including non-RTT)

This is a live demonstration of non-peer-to-peer RTT, but broadcast RTT sent through the same channels as full messages.

On one account on one computer, run two browser windows simultaneously:

1. Log onto your Google Talk via GMAIL account at http://www.gmail.com 2. Log onto your Google Talk via Gallaudet University's implementation: http://tap.gallaudet.edu/rtt/ ... (Same account) 


On a different account on a different computer:3. On a separate computer, log using a different, separate Google account at http://tap.gallaudet.edu/rtt/ (or use any RTT client such as the RealJabber.org client)


Observe the following interoperability:-- You can message from any #1, #2, or #3.-- Completed messages from #1/#2 (simultaneously logged into same account) will reach #3 and vice-versa

-- Messages from #3 will reach both #1 and #2 simultaneously.-- Real-time text doesn't show up in GMAIL, but does show up in RTT-compatible clients-- GMAIL keeps working merrily along, logging & archiving the completed messages.  GMAIL silently ignores the extraneous RTT XML


Observe that:-- Everything is routed through unmodified XMPP servers-- No server modifications  -- Not peer-to-peer.  No direct connections.  No firewall worries. 

-- If full messages make it through, real-time text also makes it through.-- Federated network-to-network compatible.    Anything federated will interop with each other for RTT.-- One end can be a jabber.org account, another end can be a Cisco WebEx account (if federated).   An RTT-enhanced Lync client transmits RTT to an RTT-enhanced WebEx.    Yes, federation is being abandoned by Google -- but others aren't.  You can still test RTT over federation between jabber.org and gmail.com using two separate copies of RealJabber.org client -- it works!


It bridges the mainstream and accessibility.   I got feedback for my XEP-0301 specification from several people at Microsoft (including Bernard Aboba), Facebook (Name requested to be private), Cisco (Paul E. Jones), and others.  See the names at http://xmpp.org/extensions/xep-0301.html#acknowledgments.  So you see, big names are on real-time text already on a 10-year roadmap.


It allows text to be used as conversationally as a telephone conversation, including in situations where speech is not practical (e.g. environments that must be quiet, environments too noisy to hear, restrictions on phone use, situations where speaking is a privacy or security concern, and/or when participant(s) are deaf or hard of hearing). It is also used for transmission of live speech transcription.  

It can also be turned on/off, for privacy considerations, and when you're not in as a chatty mood.
It also proved more popular and appealing than video: When I did a test among family and friends, when taught about real-time text ( http://www.fasttext.org -- The International Symbol of Real-Time Text), more people enabled the RTT feature than the video feature.  There is potential for RTT to be more popular than video, once people are more fully familiar with the feature, and when it's not intrusive (e.g. easy to turn on/off)


-- Gunnar Helstrom has also developed a bridge that fills the gap between RFC4103 and XEP-0301-- Vint Cerf received an accessibility demonstration involving real-time text demonstration as part of Raising The Floor, by Gregg Vanderheiden.

-- Real-time text was demonstrated at FCC text-to-911 as a standardized add-on to line-by-line SMS text messaging.  
I developed a method of presenting real-time text smoothly (non-bursty) despite only 1 packet every second, or every 2 seconds:

http://www.realjabber.org/anim/real_time_text_demo.gif 
Observe that the key press intervals are successfully (optionally) preserved.  (Many deafies like the natural typing feel)

It also can support word-at-a-time buffering, for those people who hate watching typing mistakes.
Closed captioning was thought of as a luxury in 1970's.  Now it's built into TV's.  Mainstream loves captioning nowadays.   In 10 years from now, this could become a mainstream feature.  It may not happen in 3 years, maybe not even 5 years.  But there is movement behind the scenes.  It is important to understand the implications of real-time text and its ability to be 100% seamlessly compatible with existing messaging networks, potentially as a more popular optional feature than Video.


Sincerely,Mark Rejhon

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