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

From: Mark Rejhon <[email-masked]>
Date: Fri, 31 May 2013 15:03:51 -0400

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 May 2013 12:09:49 -0700

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: [email-masked]
Date: Fri, 31 May 2013 15:03:51 -0400
To: [email-masked]
CC: [email-masked]
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.

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.org and 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
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 May 2013 14:22:07 -0500

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.
> *This is a live demonstration of non-peer-to-peer RTT*, but broadcast 
> RTT sent through the same channels as full messages.
>
> *2. Log onto your Google Talk via Gallaudet University's 
> implementation: http://tap.gallaudet.edu/rtt/ ... (Same account) *
>
> *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)*
>
> -- Completed messages from #1/#2 (simultaneously logged into same 
> account) will reach #3 and vice-versa
> -- GMAIL keeps working merrily along, logging & archiving the 
> completed messages.  GMAIL silently ignores the extraneous RTT XML
>
> Observe that:
> -- 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!
>
> 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 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:
> 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
>
>

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 31 May 2013 15:31:57 -0400

Actually, it's not quite that simple.

Some countries made RFC4103 part of their government legislation.
There are two open real-time text standards that is necessary to make
provisions for, to cover world-wide usage.

Everytime SIP is used for anything, it should always use RFC4013.
If WebRTC implementations touch SIP and not XMPP, and utilize real-time
text, then it needs to use RFC4103, even if it has to use the sockets
feature.  Thus, we need to make sure that it's also usable for RFC4103.
So it's not a 100% solved problem; there is still a SIP need.

Thanks,
Mark Rejhon

On Fri, May 31, 2013 at 3:22 PM, Adam Roach <[email-masked]> wrote:

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

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 31 May 2013 16:04:00 -0400

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 <[email-masked]>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: [email-masked]
> Subject: [rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer
> RTT (for future webrtc standardization purposes)
>
> 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.
> account at http://tap.gallaudet.edu/rtt/ (or use any RTT client such as
> the RealJabber.org client)*
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 31 May 2013 14:31:40 -0600

On 5/31/13 1:31 PM, Mark Rejhon wrote:
> There are two open real-time text standards that is necessary to
> make provisions for, to cover world-wide usage.
> 
> If WebRTC implementations touch SIP and not XMPP, and utilize
> real-time text, then it needs to use RFC4103, even if it has to use
> the sockets feature.  Thus, we need to make sure that it's also
> usable for RFC4103. So it's not a 100% solved problem; there is
> still a SIP need.

Although I have not read the legislation that mandates use of RFC 4103
(and I'm not particularly interested in the Layer 8 issues), I don't
quite agree that one can't use SIP and XMPP in concert. For example,
one could use SIP to negotiate use of XMPP with XEP-0301 as the RTT
channel, similar to draft-sparks-simple-jabber-sessions from way back
in 2002:

http://tools.ietf.org/id/draft-sparks-simple-jabber-sessions-00.txt

That might not be palatable to the politicians, but it might be an
acceptable technical solution.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 01 Jun 2013 00:58:15 +0200

On 2013-05-31 22:31, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
Well formulated requirements do not say that you must always USE RFC 
4103 for real-time text.
The requirements rather say that you must SUPPORT RFC 4103 in SIP call 
control environment, and you must provide real-time text functionality 
with good flow, sufficiently short delay and sufficient reliability.
To support means to be possible to activate through negotiation.

So there is room for USING other protocols.

Gunnar

>
> Peter
>
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRqQisAAoJEOoGpJErxa2pCMoP/R4pRxPbfMcP3UF1WWTlYVcN
> qT+tlq2s4YFH8luttDzFf0V66yBQvPlJ1cedhxqJxlWZeK9xrsGqzVI2LVj4/mhP
> e64yGToTvdHTuayD+q41gXsrLcpTxaUviSCMOI/zr1Gqv5lfXUV/qXH9V195gmZ8
> V0EgRebCHhFPFiEKZknUfhFLrqrLBEQ4xGna+dvWZREMolRLx0qGdtdkWRJbWZEZ
> VqjG/S5JBQGGfON/Cmww/Rcfzb1nopEGC0ff/k7DgZFaHxX7CcjaFq2b9wOl7udf
> k8PposwpaZ5KNCpsUB7H7qdrqTUi11JHVUj3DLVmp9fZVwuZfT0+2aLiqYV9NsdJ
> l0werWpTeGTY8ynq8qlgecBv9LE4Oqh+u6PDoJf9TdmVtetS1vZHH/P77rUZ98Fp
> mgcXYxOxTDOXTq1/d2TVGylWXIV0kajxr1jKC5G40ksH85b9imkqSzirtLa/Wx3L
> y5RHiXjO0Uoj3ic65VrPYqNRKLYk1U2NHZ6+YvRVOPBuhsNcq2vTbQ3X2QlIOGk2
> FCd0CVxHUt98Ku5ypr1hHgjxDzDsqHvsAo5yyCWuDkHQHKeHGGGeDqasEmwourUt
> EC8nIcd5s4/Pc78+NPf3iOtLoyXQmSnqnubaWYyzP8lCe+ZhijfKYomYddlIKrzO
> kB8Vt6gf8mtWnuczRsAj
> =itx6
> -----END PGP SIGNATURE-----