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

[Mark Rejhon <[e-mail]>]

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