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

[Mark Rejhon <[e-mail]>]

Hello Bernard,

Cc: Christian Vogler (who I collaborated with, for his XEP-0301 RTT
Javascript)

Currently, it is BOSH based.
It is easy to modify to make it work over WebSockets.

WebSockets helps, but unlike for RFC4103 (which is still necessary to
support), it is not necessary to a continuous connection for XEP-0301.
 XEP-0301 is polled-compatible so works great over BOSH, and still looks
like a continuous connection because of the (optional/recommended) keypress
interval preservation feature of XEP-0301.  It successfully keeps typing
completely original-looking, despite intermittent transmission.  This is
even across a slow satellite connection (with background downloads
occuring), between two web browsers on the opposite sides of Earth, running
over unpredictable HTTP and XMPP networks.  Extreme moments of lag will
eventually show through as a momentary pause in conversation, followed by a
catchup of text, but reasonable ping variability in transmission (<1 second
jitter) become seamlessly invisible.

The packet rate is apparent not too much higher than rapid-fire short
instant messages such as "Hi" "hey" "sup?" "good" "you?" etc -- that often
perpetuate modern chats.  Servers are already hardened against this
transaction rate, so are pretty XEP-0301 friendly already.  That said, this
does not replace RFC4103, since some countries have an extensive
RFC4103-based infrastructure installed & are part of their law.

Thanks,
Mark Rejhon

On Fri, May 31, 2013 at 3:09 PM, Bernard Aboba <[e-mail]>wrote:

> 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: [e-mail]
> Date: Fri, 31 May 2013 15:03:51 -0400
> To: [e-mail]
> CC: [e-mail]
> 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.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
>
> _______________________________________________ rtcweb mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>