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

Adam Roach <> Fri, 31 May 2013 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21FBF21F8B64 for <>; Fri, 31 May 2013 12:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UylYCrtN9wm8 for <>; Fri, 31 May 2013 12:22:15 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 4BD2A21F898B for <>; Fri, 31 May 2013 12:22:15 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (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
Message-ID: <>
Date: Fri, 31 May 2013 14:22:07 -0500
From: Adam Roach <>
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 <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: "" <>
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 19:22:17 -0000


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 

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


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 *
> *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 <> and 
> <> 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