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

Mark Rejhon <> Fri, 31 May 2013 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8336821F853A for <>; Fri, 31 May 2013 13:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.232
X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bJD7rbxh4wBs for <>; Fri, 31 May 2013 13:04:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::22b]) by (Postfix) with ESMTP id 6339921F91B7 for <>; Fri, 31 May 2013 13:04:21 -0700 (PDT)
Received: by with SMTP id b10so1471400vea.2 for <>; Fri, 31 May 2013 13:04:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/c2hlNUM8OmTVT6XlVOI7g54Lqg1nb+DwKfAAeVPkZk=; b=x+wWW1hwrrfLO652xsOwhkDk/o9+2t5Z0OlNM8Z248t9vtRf0I9+VT7PU5/egCl4iw FrgdHZBEUGmeD9zufx2NyJYQ7sVYU6JJp8hqXu01XF7AmqNQQze9ZMw194cD8dqbDZ0E lshDbBngdti87hBDvH+WoSMv1z7woLjd5Lwdx/h47BWN/X4VhKkFYXSrBbR3EFx49s9Z qfMP8yTK9vN5M7fVUJ1r+1vFBz8HbgZSZFMtdJmnnr+Ybyf1OW79fPOO4/gkw8EE65A1 BMmwKKqW4+unHBitnFXI0CcukRVLlPU0jGGNxNkuSIxSW+Pvl88mb2nYSOyqgDYWKI8R 9Ong==
X-Received: by with SMTP id mv2mr2735505vcb.22.1370030660714; Fri, 31 May 2013 13:04:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 31 May 2013 13:04:00 -0700 (PDT)
In-Reply-To: <BLU169-W7138C68A20F97A00503CFC93920@phx.gbl>
References: <> <BLU169-W7138C68A20F97A00503CFC93920@phx.gbl>
From: Mark Rejhon <>
Date: Fri, 31 May 2013 16:04:00 -0400
Message-ID: <>
To: Bernard Aboba <>
Content-Type: multipart/alternative; boundary=089e01177443dd055104de091ed4
Cc: Christian Vogler <>, "" <>
Subject: Re: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes)
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, 31 May 2013 20:04:23 -0000

Hello Bernard,

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

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.

Mark Rejhon

On Fri, May 31, 2013 at 3:09 PM, Bernard Aboba <>wrote;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:
> Date: Fri, 31 May 2013 15:03:51 -0400
> To:
> CC:
> 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 *
> *2. Log onto your Google Talk via Gallaudet University's implementation:
> ... (Same account) *
> On a different account on a different computer:
> *3. On a separate computer, log using a different, separate Google
> account at (or use any RTT client such as
> the 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 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
> using two separate copies of 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
>  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 (
> -- 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:
> 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