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

Adam Roach <adam@nostrum.com> Fri, 31 May 2013 19:22 UTC

Return-Path: <adam@nostrum.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 21FBF21F8B64 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 12:22:17 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UylYCrtN9wm8 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 12:22:15 -0700 (PDT)
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 4BD2A21F898B for <rtcweb@ietf.org>; Fri, 31 May 2013 12:22:15 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4VJM8NE027813 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 31 May 2013 14:22:08 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51A8F85F.4090900@nostrum.com>
Date: Fri, 31 May 2013 14:22:07 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Mark Rejhon <markybox@gmail.com>
References: <CAA79oDkcKr6rWy=uJe2P7TuabiUeizJoHqtRMs=zYK7z3AW8OQ@mail.gmail.com>
In-Reply-To: <CAA79oDkcKr6rWy=uJe2P7TuabiUeizJoHqtRMs=zYK7z3AW8OQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
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:22:17 -0000

Mark:

This is all very neat. To be clear about what's being shown here:

  * This does not use RFC 4103 RTT-over-RTP
  * This text is transmitted over a traditional XMPP
    client->server->server->client architecture

Correct? If so -- and if this is being held out as a preferred 
technology for RTT -- then this is great news. As is shown by numerous 
live deployments (Gmail, Facebook, LiveJournal IM, etc), the model of 
[JS Client]->[Web Server]->[XMPP Server]->[XMPP Client] works quite 
well, and has been supported by existing web technologies since at least 
2006.

I'm glad to have a demonstration that this is a solved problem that we 
don't need to make special provisions for. Thanks.

/a

On 5/31/13 14:03, Mark Rejhon wrote:
> 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 <http://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 <http://jabber.org> and 
> gmail.com <http://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