Subject: Re: [rtcweb] Text communication in RTCWEB sessions

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Nov 2012 12:14:22 -0500 (EST)

There are lots of suboptimal ways to do text communication.  The deaf
advocates are adamant that real-time text is needed, and the advocates
have the ear of the regulators.  So if RTCWEB is going to be used in
any situation where regulators have a say, RTT will need to be
supported.  Especially for emergency communications.

In regard to the basic technology, T.140-over-RTP is already defined
(see RFC 4103 and RFC 5194).  So RTT can be easily supported by the
SDP that we are interchanging.  Presumably any needed synchronization
can be supported by whatever synchronization mechanism we are defining
for audio and video.  (It *is* general purpose, isn't it?)

The new work is to discern the needed APIs so the Javascript can
manage RTT streams.  (I don't know whether this needs to be done with
the audio and video work, or can be deferred until later.)

The crucial point is to avoid implementing text communication in one
of the many poor ways that it has been implemented before...

Dale

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Nov 2012 18:56:48 +0100

Dale,
Good reasoning.

The need for synchronization with audio and video is very relaxed for RTT.
I would assume that a second out of synch is easily accepted.

The one second end-to-end latency is probably slightly more demanding, 
even if it also easy compared to audio and video requirements.

Since RTT is already available on RTP in RFC 4103 with presentation 
according to T.140, it is tempting to use it. Just moving to AVPF.

It is lightweight with time sampled transmission every 300 ms, and there 
is reliability included.
So, if SDP interchange is specified now, ( where?)  RTT can be easily be 
adopted.

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
[email-masked]
+46708204288

On 2012-11-12 18:14, Dale R. Worley wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Mon, 12 Nov 2012 12:56:47 -0500

> for audio and video.  (It *is* general purpose, isn't it?)

Well, the MediaStreams don't support any track types (currently) other 
than video and audio.  While possible, doing so would be a significant 
amount of work.

In practice, we're talking at most 10's of ms of sync difference - a few 
frames at most, which should not affect RTT enough to be an issue. 
Subtitles (for pre-recorded info) might be a different case, with scene 
changes and the like.

The SDP would support T140, but the codebases of the two existing 
primary implementations does not currently.

> the audio and video work, or can be deferred until later.)

My suggestion is instead of trying to jam an existing hack to "run a 
reliable protocol over an unreliable channel" into the implementations, 
to instead define running a well-known reliable-channel text protocol 
over a reliable DataChannel (or unreliable, if that makes more sense).

> of the many poor ways that it has been implemented before...

Agreed. I'm just not convinced T140-over-RTP is the right solution.  And 
yes, I've worked with the HoH/Deaf community before in VRS/Videophones 
and VRS interop (H.323 - now THERE was a bad decision forced by the 
dominant player aka Sorenson).

-- 
Randell Jesup
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Nov 2012 11:42:48 -0700

> dominant player aka Sorenson).

Another option is RTT over XMPP:

http://xmpp.org/extensions/xep-0301.html

Given that there are plenty of JavaScript libraries for XMPP, that seems
like a rather easy approach. See also http://realjabber.org/

Peter

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

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Nov 2012 20:02:05 +0100

On 2012-11-12 19:42, Peter Saint-Andre wrote:
> like a rather easy approach. See alsohttp://realjabber.org/

Yes, that is the obvious other option.
XEP-0301 need then to move on from its experimental state.

Do you mean that the transport of XMPP would be done beside RTCWEB, 
coordinated just by a specification saying "This is a way to do RTT 
together with an RTCWEB session?"  Or would there be any more clear link 
or use of RTCWEB mechanisms?

Gunnar

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 12 Nov 2012 14:41:27 -0500

Dale is right ..you can delay the discussion but not the requirement. The
regulators will insist on this. 

http://transition.fcc.gov/cgb/dro/cvaa.html

http://europa.eu/legislation_summaries/information_society/legislative_frame
work/l24216a_en.htm

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dale R. Worley
Sent: Monday, November 12, 2012 12:14 PM
To: [email-masked]
Subject: Re: [rtcweb] Text communication in RTCWEB sessions

There are lots of suboptimal ways to do text communication.  The deaf
advocates are adamant that real-time text is needed, and the advocates have
the ear of the regulators.  So if RTCWEB is going to be used in any
situation where regulators have a say, RTT will need to be supported.
Especially for emergency communications.

In regard to the basic technology, T.140-over-RTP is already defined (see
RFC 4103 and RFC 5194).  So RTT can be easily supported by the SDP that we
are interchanging.  Presumably any needed synchronization can be supported
by whatever synchronization mechanism we are defining for audio and video.
(It *is* general purpose, isn't it?)

The new work is to discern the needed APIs so the Javascript can manage RTT
streams.  (I don't know whether this needs to be done with the audio and
video work, or can be deferred until later.)

The crucial point is to avoid implementing text communication in one of the
many poor ways that it has been implemented before...

Dale

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Nov 2012 12:43:31 -0700

> XEP-0301 need then to move on from its experimental state.

Yes, I expect that to happen in the relatively near future. Certainly
before RTCWEB is baked. :)

> or use of RTCWEB mechanisms?

One possibility is to negotiate an XMPP chat session via SDP, as Robert
Sparks once proposed a long time ago:

https://datatracker.ietf.org/doc/draft-sparks-simple-jabber-sessions/

Peter

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

---

From: "Jim Barnett" <[email-masked]>
Date: Mon, 12 Nov 2012 11:48:45 -0800

Yes, but is that a requirement on us, or on the people who roll out
services using webRTC?  If RTT can be done via a bunch of (potentially
ugly) JS code and the data channel,  then it's the service providers'
problem to write that ugly JS code.  There's no requirement for the
W3C/IETF to provide native support for RTT as long as it's possible to
implement it on top of our standards.

- Jim
P.S.  I intend this as an argument for looking at RTT later, not for
skipping it altogether.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Shockey
Sent: Monday, November 12, 2012 2:41 PM
To: 'Dale R. Worley'; [email-masked]
Subject: Re: [rtcweb] Text communication in RTCWEB sessions

Dale is right ..you can delay the discussion but not the requirement.
The regulators will insist on this. 

http://europa.eu/legislation_summaries/information_society/legislative_f
rame
work/l24216a_en.htm

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dale R. Worley
Sent: Monday, November 12, 2012 12:14 PM
To: [email-masked]
Subject: Re: [rtcweb] Text communication in RTCWEB sessions

have the ear of the regulators.  So if RTCWEB is going to be used in any

In regard to the basic technology, T.140-over-RTP is already defined
(see RFC 4103 and RFC 5194).  So RTT can be easily supported by the SDP
that we are interchanging.  Presumably any needed synchronization can be
supported by whatever synchronization mechanism we are defining for
audio and video.
(It *is* general purpose, isn't it?)

The new work is to discern the needed APIs so the Javascript can manage
RTT streams.  (I don't know whether this needs to be done with the audio
and video work, or can be deferred until later.)

The crucial point is to avoid implementing text communication in one of
the many poor ways that it has been implemented before...

Dale

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 12 Nov 2012 22:56:34 +0200

> https://datatracker.ietf.org/doc/draft-sparks-simple-jabber-sessions/

the other way would be run XMPP over WebSocket
http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Nov 2012 14:11:51 -0700

> http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01

Indeed. The XMPP WG might be recharted "soon" to take that on as a WG item.

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2012 17:09:50 -0500

> http://xmpp.org/extensions/xep-0301.html

Another option is RTT over a datachannel.

But then why not audio and video over datachannels too?

	Thanks,
	Paul

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 15 Nov 2012 15:15:16 -0800

There will certainly be uses for audio over a datachannel - when talking
to a speech recognition system, for example.

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Thursday, November 15, 2012 5:10 PM
To: [email-masked]
Subject: Re: [rtcweb] Text communication in RTCWEB sessions

	Thanks,
	Paul

---

From: Erik Lagerway <[email-masked]>
Date: Thu, 15 Nov 2012 15:41:55 -0800

Maybe we should focus on getting the datachannel working in a browser
before we start discussions around RTT? Not saying RTT is not important
just wonder if now is the right time to start in on those discussions.

Cheers,
Erik

-- 
*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com>
* | @elagerway <http://twitter.com/elagerway> | m 1.604.562.8647*

---

From: Randell Jesup <[email-masked]>
Date: Thu, 15 Nov 2012 23:50:23 -0500

On 11/15/2012 6:41 PM, Erik Lagerway wrote:
> before we start discussions around RTT? Not saying RTT is not 
> important just wonder if now is the right time to start in on those 
> discussions.

http://mozilla.github.com/webrtc-landing/data_test.html

:-)

You'll want the current Firefox Nightly (http://nightly.mozilla.org/) or 
a local build from the mozilla-central repo

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Sat, 17 Nov 2012 19:56:02 -0500

> But then why not audio and video over datachannels too?

Because congestion control for DataChannels is different (certainly so 
today), and we want to be able to negotiate audio and video channels 
that are compatible or easily translated into standard VoIP protocols 
(i.e. RTP/etc) for connecting to legacy equipment and gateways.

You *can* do it.  It doesn't mean you should.  And the browser won't 
provide all the automatic low-level support for audio or video over 
datachannels.

Also, if the sender is pushing the audio and video into datachannels 
from JS, you're pushing a LOT of time-critical data through JS.  Not good.

And SCTP has buffer-blocking issues still (they're working on a draft): 
large messages must be delivered before it will send a different 
message, so if I send a 10MB file, no audio or video would get through 
until it was done.

-- 
Randell Jesup
[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 18 Nov 2012 08:05:04 +0100

On 2012-11-18 01:56, Randell Jesup wrote:
> And SCTP has buffer-blocking issues still (they're working on a 
> draft): large messages must be delivered before it will send a 
> different message, so if I send a 10MB file, no audio or video would 
> get through until it was done. 

Real-time text is also time-critical, even if less than audio and video. 
One second end to end is good. Two seconds is usable. Long occasional 
blocking disrupts the conversation and is dangerous in emergency 
situations. That is one reason why RTP was selected initially as the 
transport.

That seems to be a good reason for doing it again on RTP.

Gunnar

---

From: Randell Jesup <[email-masked]>
Date: Sun, 18 Nov 2012 04:46:39 -0500

>> get through until it was done. 

Note: that was in reply to "why not do audio and video over DataChannels?"

> Real-time text is also time-critical, even if less than audio and 
> video. One second end to end is good. Two seconds is usable. Long 
> occasional blocking disrupts the conversation and is dangerous in 
> emergency situations. That is one reason why RTP was selected 
> initially as the transport.
>

Or use partially-reliable/unreliable DataChannels, though I should note 
that if a reliable channel can't deliver the message, an unreliable 
channel with hand-rolled partial-reliability (i.e. RTT over RTP) is 
unlikely to do better (or much better). However, lack of blocking means 
loss of a doesn't mean b is blocked from appearing, so any unreliable 
channel has an advantage over an in-order reliable channel.  T.140 over 
a partially-reliable datachannel (or maybe an out-of-order reliable 
channel) is likely to be the equivalent (or better) to RFC 4351.

The real question here is "*must* it be built into the browser", or is 
implementation in JS enough, since many/most uses of PeerConnection will 
not be interested in RTT?  If JS is enough, that points strongly to 
DataChannels.  I'll also note that rendering the text must be done in JS 
anyways, so we'd need to surface an API to pass it to the JS code, and 
the JS would need to implement a UI for it to be usable.  If transparent 
interop without a gateway is needed (though that almost certainly fails 
for other reasons), then RFC 4351 is needed in the browser.  If a 
gateway is used, and the data over the DataChannel is T.140 or close, 
than the gateway *could* put that into the audio stream - IF the media 
flows through the gateway, which it might not.

-- 
Randell Jesup
[email-masked]

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sun, 18 Nov 2012 20:57:14 +1100

On Sun, Nov 18, 2012 at 8:46 PM, Randell Jesup <[email-masked]>wrote:

>>> large messages must be delivered before it will send a different message,
>>> so if I send a 10MB file, no audio or video would get through until it was
>>> done.
>>>
>>
>>
> that if a reliable channel can't deliver the message, an unreliable channel
> with hand-rolled partial-reliability (i.e. RTT over RTP) is unlikely to do
> better (or much better). However, lack of blocking means loss of a doesn't
> mean b is blocked from appearing, so any unreliable channel has an
> advantage over an in-order reliable channel.  T.140 over a
> partially-reliable datachannel (or maybe an out-of-order reliable channel)
> is likely to be the equivalent (or better) to RFC 4351.
>
> anyways,

this is not the case for captions: there already exists a specification for
rendering of captions over the top of video in HTML, so not all RTT must be
rendered in JS.

Also, it would be possible to classify RTT and develop standard display
mechanisms for specific types - e.g. a "chat text" type that is rendered in
a "chat box".

> so we'd need to surface an API to pass it to the JS code, and the JS would
> need to implement a UI for it to be usable.  If transparent interop without
> a gateway is needed (though that almost certainly fails for other reasons),
> then RFC 4351 is needed in the browser.  If a gateway is used, and the data
> over the DataChannel is T.140 or close, than the gateway *could* put that
> into the audio stream - IF the media flows through the gateway, which it
> might not.

Regards,
Silvia.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 28 Nov 2012 16:45:36 -0500 (EST)

Catching up on various messages:

> From: Igor Faynberg <[email-masked]>
> 

> In this case, would that mean that when I type something and then want 
> to correct it, backspaces would be transmitted, too?  If so, I doubt it 
> is useful.   The second case, with the user having control over sending 
> of the message, is much better.

There are possibilities for embarrassment with real-time text, in that
you don't have time to reconsider your words between typing them and
hitting RETURN (which would send them in a message-oriented text
system).

One response to this is that a similar possibility exists in
voice/video communication.  And one can always configure one's RTT
system to delay sending text until it sees a RETURN.

> From: Gunnar HellstrC6m <[email-masked]>
> 

The relevant RFCs seem to be:

RFC 5194
Framework for Real-Time Text over IP Using the Session Initiation
Protocol (SIP)

This shows an example SDP, using the text/t140 media type for encoding
the text and the text/red media type for providing reliability:

   m=text 11000 RTP/AVP 100 98
   a=rtpmap:98 t140/1000
   a=rtpmap:100 red/1000
   a=fmtp:100 98/98/98

This RFC seems to be the technology/policy statement by the deaf/RTT
people (especially van Wijk).

RFC 4103
RTP Payload for Text Conversation

This gives the text/t140 format.

RFC 4102 
Registration of the text/red MIME Sub-Type
RFC 2198
RTP Payload for Redundant Audio Data

These give the text/red redundancy format.

> From: Randell Jesup <[email-masked]>
> 

It shouldn't be much work unless the media-type-independent part of
MediaStreams isn't cleanly separated from the media-type-dependent
part.  It should be just a matter of providing another subclass of
MediaStreams.

> primary implementations does not currently.

We either implement it in the browsers or everybody gets to implement
it in Javascript.

> over a reliable DataChannel (or unreliable, if that makes more sense).

Yes, text/red is a hack.  But it's already used in the RTT world.
(More about that below.)

> From: "Richard Shockey" <[email-masked]>
> 
> ... you can delay the discussion but not the requirement. The

Richard gets back to an important issue -- T.140-based RTT is being
heavily lobbied for and gradually imposed by telephony regulators.
The result is that any SIP systems we want to interoperate with will
soon be using text/t140 and text/red.  And note that in enterprise
deployments, the WebRTC function of the server will generally be a
gateway into the existing SIP-based call center systems.

Within that context, the question is how to gateway SIP RTT into
WebRTC.  Of course, we could carry the RTT over a datastream.  Or we
could have the browser implement RTT in RTP and allow the RTP to
bypass the gateway device, as it does with audio and video media.

Since the RTT data stream has a lower bit rate and looser timing
requirements than audio or video, it could probably be handled as a
datastream by Javascript.  But it seems to me that implementing it
"natively" in the browser's WebRTC handling has advantages:

- Because there is only one implementation per browser, there is less
  total implementation effort and the average implementation is more
  likely to work well.  It will also have a consistent UI if the user
  uses the same browser with multiple web sites.

- In my experience, though Javascript is supposed to be executed as a
  "soft real-time" process, browsers are not real-time at all.  The UI
  of browsers often freezes for seconds at a time, and I suspect that
  Javascript execution is frozen as well.  RTT handling is much more
  likely to actually be real-time if we put the UI-to-RTT-RTP code in
  the same module that handles the UI-to-audio-RTP and
  UI-to-video-RTP.

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Nov 2012 12:33:08 +0100

> people (especially van Wijk).

Not sure that is the most appropriate statement to make.

RFC 5194 was a working group item of the sipping group, went through WGLC and also IETF last call, and went to the IESG. That normally is taken to mean the document has IETF consensus.

Keith

> Sent: 28 November 2012 21:46
> To: [email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 29 Nov 2012 10:41:12 -0500 (EST)

> From: "DRAGE, Keith (Keith)" <[email-masked]>
> 
> RFC 5194 was a working group item of the sipping group, went through
> WGLC and also IETF last call, and went to the IESG. That normally is
> taken to mean the document has IETF consensus.

That's true.  But the point I'm focusing on is not whether this
particular approach has IETF support.

Rather, my point is that the technological approach documented in this
RFC has the intense support of a lobbying group of significant power.
Because of this lobbying power, much of the implementation of RTT in
the phone network *will* be done by this method, and WebRTC will work
far better if we align it with that reality.

In this particular case, the fact that the document is IETF-approved
is not its most significant feature.

Dale

---

From: Randell Jesup <[email-masked]>
Date: Thu, 29 Nov 2012 22:51:01 -0500

> hitting RETURN (which would send them in a message-oriented text

I think the things I saw mandated the user be able to switch between 
immediate and cooked modes.

> part.  It should be just a matter of providing another subclass of

Not so simply; MediaStreams in Firefox currently have a strong idea that 
data has a time for display and a duration. This could be worked around, 
and might need to for other reasons - but there was no design goal for 
carrying non-media data in MediaStreams.

> We either implement it in the browsers or everybody gets to implement

Yes, though likely there would be library or two. (Though those have 
their own issues, for sure.)

> gateway into the existing SIP-based call center systems.

Agreed, this is a very important point.

(Note: I've only read part of the items linked, and not with a clear 
head and a marker.)

Even without connection to SIP systems, the onus to provide mandated 
accessibility features may exist anyways, though with the onus being on 
"equipment manufacturers" and on "service providers" (FCC definitions). 
Note that regulations now apply to "non-interconnected VoIP" 
applications - stuff that never touches the PSTN (this can include 
TeamSpeak (games), private non-PSTN networks (the old WorldGate 
videophone network), etc. Games companies are having to argue about how 
much of their revenues should be attributed to VoIP and thus how much 
they contribute to the fees and TRS/etc funds. Thus far they're 
exempting free services and those that can't be separated from other 
primary uses like in games.

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-151A1.pdf
para 86:
"If software gives the consumer the ability to
send and receive e-mail, send and receive text messages, make 
non-interconnected VoIP
calls, or otherwise engage in advanced communications, then provision of 
that software is
provision of ACS.183 The provider of that software would be a covered 
entity, and the
service, including any provided through a small-scale or large-scale 
peer-to-peer system,
would be subject to the requirements of the statute.184 This is true 
regardless of whether
the software is downloaded to the consumer’s equipment or accessed in 
the cloud."

and in the normative ( ;-)) text:

    "(iii) Real-time text connectability. Products that provide a
    function allowing voice communication and which
    do not themselves provide real-time text functionality shall provide
    a standard non-acoustic connection
    point for a real-time text device.
    *[snip]*
    b. If the ACS connects to VoIP via SIP it shall use a RTT format
    that is supported by the
    largest number of products and systems or allow connection of a
    device that supports
    that format.
    i. Note: At this time, the only RTT format that is widely used on
    VoIP via SIP and the only
    one named in emergency standards and guidelines is RFC 4103.
    c. If the ACS connects to VoIP using any other transport standard it
    shall provide real-time
    text using the real-time text interoperability standard chosen for
    and supported by the
    largest number of products on that transport.

So, since we don't use SIP directly, this would not *mandate* RFC 4103 - 
we can effectively define and choose a standard for WebRTC/JSEP. But 
they would mandate that "we" (really service providers providing the 
applications) have such a standard and provide it. And has been pointed 
out, demands to interoperate with SIP/RFC4103 would exist, and also E911 
is likely to want to standardize on RFC4103 (and, for another problem, 
H.263 or H.264). But the E911 folk are still talking about it so far as 
I know. They may have done this to ameliorate Sorenson and their huge 
investment in H.323 equipment, or to accommodate other non-SIP messaging 
systems.

The Emergency Advisory Committee has also published something covering this:
http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-312161A1.doc

>    uses the same browser with multiple web sites.

I'll note that virtually nothing in webrtc, let alone rtcweb, really 
touches on UI - UI is generally (and almost must be) handled by the JS 
application. Assuming the UI is tied to the signaling and media 
components/hardware is the classic SIP hardware UA way to look at it (or 
SIP software application).

We'd need to define a way to inject keystrokes into the stream, and get 
them out (and perhaps process them into a displayable string). In theory 
the W3C could define RTT display elements you could hook an RTT media 
track to; or it could be subsumed into existing audio/video media 
elements (though there's still the input side, and this might be unduly 
restrictive of possible applications layouts and uses).

>    the same module that handles the UI-to-audio-RTP and

Well, in some cases the browser may be busy. This could either be 
handled directly in the Audio/Video element (with downsides), or in a JS 
worker (though modifying the DOM isn't possible from there, so it really 
probably doesn't help you).

It may be best to not try to sidestep the browser being busy, since that 
can cause anything to stall.

-- 
Randell Jesup
[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Nov 2012 09:17:51 +0100

On 2012-11-30 04:51, Randell Jesup wrote:
> Not so simply; MediaStreams in Firefox currently have a strong idea 
> that data has a time for display and a duration. This could be worked 
> around, and might need to for other reasons - but there was no design 
> goal for carrying non-media data in MediaStreams. 
Real-time text is to be seen as media. When using RFC 4103 for 
transport, the samples are usually 300 ms. Usually they should be played 
asap but smoothed out during the sampling period. If needed they can be 
synchronized through time stamps with other media. 3GPP TS 26.114 
Multimedia Telephony is a good example of a spec treating real-time text 
as any other media.

It is of course a good habit to keep already received real-time text 
visible for some time. I hope that that does not conflict with the time 
and duration idea. There is an expired draft telling how that can be done.
http://tools.ietf.org/html/draft-hellstrom-textpreview-08
That topic is also dealt with very briefly in the presentation standard 
ITU-T T.140 http://www.itu.int/rec/T-REC-T.140/en

/Gunnar

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Nov 2012 09:30:48 +0100

On 11/28/2012 10:45 PM, Dale R. Worley wrote:
>> >From: "Richard Shockey"<[email-masked]>
>> >
So we're being asked to incorporate a standard that

* is not used yet
* doesn't have technology push (the regulators need to mandate it)
* doesn't have legal push (the regulators still haven't *decided* to 
impose it)
* is not the obviously right technology choice

because it has active lobbyists?

I, for one, am happy to delay this one and take my chances.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Nov 2012 14:06:23 +0100

It is used and implemented in my understanding.

It has been used in trial circumstances on emergency calls in Sweden.

It is specified as mandatory for networks to support, and interwork in SIP calls over IMS, in support of emergency calls. It is the recognized mechanism in IMS for supporting hearing impaired callers in emergency situations.

Now whether the implementation in webRTC is T.140, or something that is capability of interworking to it is a different story, but I believe you do need to provide at least an equivalent capability at day 1.

Keith

> Of Harald Alvestrand
> Sent: 30 November 2012 08:31
> To: [email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Nov 2012 14:06:58 +0100

> So we're being asked to incorporate a standard that
Wrong, it is used, at least in Europe, and work well.
> * doesn't have technology push (the regulators need to mandate it)
This is just because of lack of making conclusions of observations on 
how users are using IM today. Research reports indicate that all would 
be more happy being provided with real-time text than message-wise IM. 
Users need to adapt to the shortcomings of IM because no big service 
provider has yet provided real-time text together with other media in a 
conveniently available conversational tool.

There is user push among accessibility users and relay service personnel 
who have acces to the technology. It is used and appreciated in text 
relay services, total conversation services, Sign relay services, IP 
text telephony services and captioned telephony services.
> * doesn't have legal push (the regulators still haven't *decided* to 
It is very uncommon for legal requirements to point at specific 
implementation standards.
It is more common to require functionality

-The requirements to provide the real-time text medium,
-the requirement to provide it in calls with aidio and video,
-the quality requirements on real-time text
- and the interoperability requirements
  are all there in the legal requirements.

And a hint that RFC 4103 is a suitable way to arrange the interoperability.

> * is not the obviously right technology choice 
Why not?

There is currently one well working standard, mainly intended for use in 
SIP.

If IM is going to be enhanced to provide a real-time text feature within 
the IM services, the XMPP extension in creation might be a valid 
alternative because it is so well integrated in the IM environment.
But for interworking with SIP, RFC 4103 seems to be the choice. One 
important indication is that it is included  in the NG112 and NG911 
specifications for emergency services.

So, what does rtcweb want to be, IM with real-time media additions and 
SIP interworking, or real-time conversational service?  Or both?

Gunnar

---

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 30 Nov 2012 14:50:40 +0100

> -the quality requirements on real-time text

I think all those can be solved with the data channel (just send 
character by character)

> - and the interoperability requirements

Can't this be done with a GW (just as when interoperating rtcweb - PSTN)?

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 30 Nov 2012 09:24:02 -0500

(This is the author of XEP-0301, the XMPP-based real-time text standard)

On Fri, Nov 30, 2012 at 8:50 AM, Stefan Hakansson LK
<[email-masked]> wrote:
> I think all those can be solved with the data channel (just send character
> by character)

Not always.  There are many use cases (e.g. mobile devices) where
continuously sending character by character will not always show up
continuously character by character on the destination device, for
various reasons (e.g. needing to chunk data, needing to use BOSH,
variable network latency, chunking issues of network congestion, etc)

That's why XEP-0301 includes key press delay encoding capability, so
that infrequent transmission can occur, while still having smooth
playback of text.  Although key press delay encoding is not marked as
required in my spec, people can tell the difference between calm
typing and panicked typing, if key press delays are completely
preserved.   Also with key press delay encoding, people can tolerate
longer latencies during unavoidable conditions (e.g. many, including
myself, can tolerate a 2 second lag or lag spike caused by network
latency, e.g. satellite networks or extremely weak intermittent 1-bar
mobile phone reception areas, etc)

(I posted a link to the mailing list showing an animation, if web-linked
message has not been filtered by the IETF servers.)
It's on my RealJabber website, and is explained by section 6.1 "Text
Presentation".

Sincerely,
Mark Rejhon
Author of XEP-0301 -- XMPP In-Band Real-Time Text

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 30 Nov 2012 10:35:25 -0500

(Adding relevant animations of real-time text, to see if it gets
through IETF spam filters, this time.)

> Author of XEP-0301 -- XMPP In-Band Real-Time Text

An animation of real-time text from an actual implementation:
http://www.realjabber.org/anim/real_time_text_demo.html

This is a playback of my RealJabber demo program, running over an
unmodified Google Talk server -- real-time text transmitted through
somebody else's servers.  So another secondary reason is we don't want
to overload XMPP servers, so we do not transmit character at a time.
We be polite to the XMPP server, and transmit at only one packet per
second.  But the typing still looks exactly original!   (XEP-0301 is a
real-time packetization of typing, like VoIP is a packetization of
voice).

Also observe how well real-time text "integrates" into the existing
instant messaging metaphor -- even including message-edit-before-send
capability, so recipient can see the sender editing the message before
it gets sent ("committed")

Another animation concept of real-time text running in
JavaScript-based messaging systems:
http://www.realjabber.org/anim/facebook_chat_concept.gif

Thanks,
Mark Rejhon
Author of XMPP In-Band Real-Time Text
http://www.xmpp.org/extensions/xep-0301.html

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 30 Nov 2012 11:00:02 -0500

[This message was sent two days ago, but got filtered.  Resending.]

Hello,
I'm the author of XEP-0301 -- the Real-Time Text XMPP Extension
Protocol found at http://www.xmpp.org/extensions/xep-0301.html with
animations/demo software found at http://www.realjabber.org

> Date: Wed, 28 Nov 2012 16:45:36 -0500 (EST)
> From: [email-masked] (Dale R. Worley)
> To: [email-masked]
>
> > In this case, would that mean that when I type something and then
> > want to correct it, backspaces would be transmitted, too?  If so, I
> > doubt it is useful.   The second case, with the user having control
> > over sending of the message, is much better.
>

The XEP-0301 real-time text standard is oriented towards instant
messaging, and it enables visibility of all message edits (including
editing text in the middle of your sentence before sending your
message).  This is necessary in instant messaging programs to allow
backwards compatibility with the user's pre-existing expectation of
backspacing/editing their message before sending the messages.

Examples of animations of how the real-time text integrates into
existing chat systems:

http://www.realjabber.org/anim/real_time_text_demo.html
...(screenshot animation from RealJabber -- comparision with and
without real time, in messaging style metaphor)

http://www.realjabber.org/anim/facebook_chat_concept.gif
...(concept animation of RTT being bolted-on into Facebook Chat,
illustrating seamless add-on)
...(notice the "Fast Text Mode Enabled" notification)

As the XEP-0301 standard is designed to be backwards compatible, as a
client-only modification, and to run over existing XMPP networks with
no server modifications.  Users typically edit and backspace messages
before sending, and that capability is kept even when real-time text
is enabled, to preserve user experience with existing instant message
interfaces.  Also, there is an activation/deactivation mechanism
available, too.

The "I doubt it is useful" phrase (interpretable in multiple ways)
caught my attention...

Backspacing is useful text equivalent to a spoken "oops, let me
repeat" on the telephone, when you made a mistake and need to repeat
what you just said.  On the same subject of telephone -- real-time
text is also useful for placing a telephone call silently -- sometimes
people need to urgently chat in real-time without waiting, but aren't
allowed to use voice with phones (e.g. restaurants, hospitals,
airplane WiFi, military covert chatting, emergency situations,
bedroom, etc).  It is noted that typing on touchscreen is fairly
quiet.  In private trials of my own software within my peer groups,
people preferred real-time text calls over video phone calls, as a
feature.  People still appreciated the freedom to edit instant
messages the way they used to (continued instant messaging UI
familarity) even while the recipient is reading, and implementors can
choose to provide a software feature to turn on/off real-time text
even in mid-message-editing.

Also, being optimized as an RTT enhancement to message-by-message
chats, XEP-0301 also supports RTT group chats including mixed-mode
chats (e.g. RTT only from the leader, teacher or lecturer into a
groupchat, with everyone else message-by-message to prevent
distractions), and remains compatible with RTT and non-RTT-supported
clients, either with all the existing message-line editing features,
including backspacing messages.

Although T.140 RTT isn't derived from instant messaging, the context
of how it can apply to instant messaging, is useful to know, and I
should note that Gunnar has a transcoder between T.140 RTT and my
XEP-0301 (We collaborate on the XEP-0301 spec, he is listed in the
credits) which takes advantage of the backspacing capability.

> > From: Gunnar Hellstrom <[email-masked]>
> >
> > The need for synchronization with audio and video is very relaxed
> > for RTT. I would assume that a second out of synch is easily
> > accepted.
> >
> > The one second end-to-end latency is probably slightly more
> > demanding, even if it also easy compared to audio and video
> > requirements.

Synch with audio/video is not a major issue in my experience for
real-time text.  As long as the playout is smooth (both XEP-0301 and
T.140 have different methods of smooth text output), many can tolerate
a 2 second delay, as it's not as real-time critical as voice or audio.
  Ideally, 300ms or less is far better, of course, and both my
standards and Gunnar's standards use that figure.

> > My suggestion is instead of trying to jam an existing hack to "run
> > a reliable protocol over an unreliable channel" into the
> > implementations, to instead define running a well-known
> > reliable-channel text protocol over a reliable DataChannel (or
> > unreliable, if that makes more sense).
>

On this topic, I should mention that XEP-0301 has a basic redundancy
mechanism too (section 4.6 to 4.6.3), but it is very different from
the way T.140/RFC4103 RTT does it, and it permits recovery in
instant-messaging-releavant situations even a long time later (e.g.
loss of WiFI reception that also leads to disconnection; and the
reconnecting client (even on a separate device, separate software)
receives the re-transmitted contents of a long instant message still
being composed by the sender, without the sender noticing anything's
amiss.  (The sender just notices the recipient disconnect and
reconnect while continuing to type a very long message that's much
longer to write, than the T.140 redundancy windows) (The recipient
sees the sender message-in-progress reappear upon reconnecting)

As a final note, even if T.140 is decided to be integrated into
WebRTC, that does not exclude other real-time text standards in the
future.  I'd like to make sure JavaScript implementations of instant
messaging optimized real-time text standards (including XEP-0301, as
it XML payload format is also usable outside XMPP too) should still be
possible to be added by third party application developers taking
advantage of WebRTC.  Preferred if it's still possible integrate
real-time text into the instant-messaging metaphor.

Mark Rejhon
Author of XEP-0301 -- XMPP based Real-Time Text

---

From: Randell Jesup <[email-masked]>
Date: Fri, 30 Nov 2012 11:13:23 -0500

> variable network latency, chunking issues of network congestion, etc)

That's true, though in many of these cases we're talking about RTT+audio 
and/or video, so per-character typing is not where you'll have your 
problems.

For RTT alone (no audio or video), in a very poor network, you're 
correct.  However, I think Stefan was meaning you can send the data 
character-by-character but did not mean that's *all* you would send; I'm 
assuming this is in a protocol that can include things like 
intra-character delay, multiple characters, etc.

In this situation, DataChannels are a pure transport (combined we hope 
with work to minimize delay by coordinating congestion control with the 
audio/video transport).  The RTT protocol run over it could be simple or 
complex, and could be an existing protocol from elsewhere (or the guts 
thereof), like T.140 or XEP-0301, or something brand new.

> mobile phone reception areas, etc)

Nice demo.  Slightly contrived of course. :-)  I'll note that tolerance 
for true as-you-type RTT varies widely culturally and personally.  Some 
people simply hate it because they don't want to expose intermediate 
"thoughts" they erase while before sending, and don't want the pressure 
of responding *now* after the other person says something.  And a switch 
helps, but then it can lead to awkwardness of "why don't you just 
respond; why are you editing?" Also, I've noticed younger people/teens 
have moved further and further away from direct real-time interaction 
("What do you mean I should *call* him on my phone?!  We only text!") 
partly because the delays provided by text-chat gives a bit of a social 
safety net against nervousness and anxiety.

The HoH community may well have different cultural standards/preferences 
about how to use interactive text communication than the general public 
as well, and emergency services may have different needs.

-- 
Randell Jesup
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Nov 2012 08:24:28 -0800

To be clear, there is US legislation (known as CVAA) that has a compliance deadline of October 7, 2013: 
http://www.gpo.gov/fdsys/pkg/PLAW-111publ260/pdf/PLAW-111publ260.pdf

The expectations for Advanced Communications Services are laid out in the ACS Report and Order. Among other things, the expectation is that ACS will be made accessible and usable by people with disabilities:
http://www.fcc.gov/document/accessibility-rules-advanced-communications-services-0

However issuance of more specific rules is still pending.  Among other things, completion of the Access Board Section 255/508 refresh is still in progress, the most recent draft of which is given below:
http://www.access-board.gov/sec508/refresh/draft-rule.htm

Disclaimer: I am not a lawyer, and do not speak on behalf of any govt agency, or the FCC EAAC. If you need legal advice on CVAA obligations, get advice from a competent telecommunications lawyer.

On Nov 30, 2012, at 0:30, "Harald Alvestrand" <[email-masked]> wrote:
> * doesn't have legal push (the regulators still haven't *decided* to impose it)

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Nov 2012 17:26:57 +0100

There is a key reason why real time text is the preferred media for text rather than instant messaging for emergency calls.

It is because the remote party (the PSAP) wants control of that delay, and wants to keep it as short as possible. PSAP call takers want to gain the maximum amount of relevant information in the minimal possible time. If a user spends time composing a response, the call taker wants to be able to respond as soon as possible if they see the wrong, or inappropriate, response is being given, in order to get the appropriate response given. This is exactly what helps in speech conversation and is needed in the same scenario in real time text.

So 300 ms latency is probably fine. It might chunk a couple of characters, or deal with a quick backspace to get rid of one mistyped character. Anything beyond that will merely delay the call taker providing you with an appropriate emergency response.

Instant messaging and real time text are complementary forms of text communication. One does not replace the other.

Regards

Keith

> Of Randell Jesup
> Sent: 30 November 2012 16:13
> To: [email-masked]
> character

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 30 Nov 2012 11:32:23 -0500

On Fri, Nov 30, 2012 at 11:13 AM, Randell Jesup <[email-masked]> wrote:
> Nice demo.  Slightly contrived of course. :-)  I'll note that tolerance for
> true as-you-type RTT varies widely culturally and personally.  Some people
> simply hate it because they don't want to expose intermediate "thoughts"
> they erase while before sending, and don't want the pressure of responding
> *now* after the other person says something.  And a switch helps, but then
> it can lead to awkwardness of "why don't you just respond; why are you
> editing?" Also, I've noticed younger people/teens have moved further and
> further away from direct real-time interaction ("What do you mean I should
> *call* him on my phone?!  We only text!") partly because the delays provided
> by text-chat gives a bit of a social safety net against nervousness and
> anxiety.
>
> about how to use interactive text communication than the general public as
> well, and emergency services may have different needs.

Agreed.  That's why my XEP-0301 specification supports any text
smoothing method the implementer prefer -- and can be done
independently of the interval transmission rate/limitations.  You can
do it character-at-a-time, delay-buffered (to allow corrections),
captioning, transcription, bursts-at-a-time, words-at-a-time,
fixed-smoothing, etc.  In addition, I've included
activation/deactivation methodologies in XEP-0301.

Mark Rejhon
Author of XEP-0301 In-Band Real-Time Text.

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 30 Nov 2012 11:41:36 -0500

> Instant messaging and real time text are complementary forms of text communication. One does not replace the other.

True.  However, it's also an integration issue.
-> You can handle real-time text separately of message-by-message
(intersperse them).
-> Or you can integrate real-time as part of the instant messaging methodology.

The catch is protocols can be designed to make integration difficult
or easier, so it becomes relevant as an interoperability issue.
WebRTC should, ideally, be designed to permit either type of
integration -- e.g. integrate real-time text into the existing
message-by-message metaphor.

This is where an understanding of the differences of T.140 and
XEP-0301 becomes useful.
T.140 is a continuous linear form of real-time text, similar to
TTY/textphones, with no message breaks.
XEP-0301 integrates real-time text into existing instant messages,
with message boundaries.
There are some linear ability with XEP-0301 if it is also combined
with XEP-0308 Last Message Correction, so this helps T.140 transcoding
to XEP-0301, to allow backspacing into the previous message, to
maintain linear real-time text compatibility with T.140.
(Gunnar Helstrom has also written a transcoder)

(For those who missed it -- animation at
http://www.realjabber.org/anim/real_time_text_demo.html -- useful for
understanding real-time text from an instant messaging metaphor)

Mark Rejhon
Author of XEP-0301 In-Band Real-Time Text

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Nov 2012 11:58:03 -0500

Ok .. first … on the basic issue of the consensus call  for Text
Communications,  IMHO this requirement needs to me met and MUST be
incorporated into RTCWEB sessions at some point in time.  

This is simply unavoidable.   

Two  I certainly support Bernard’s approach here.  Its clear there are
multiple types of requirements for text messaging and we have multiple ways
if implementing them.  Documenting those are the first step. Then choose. 

Bernard also correctly points out the freight train of national regulatory
requirements coming from the US/Canada and additionally the EU as well.  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gunnar Hellström
Sent: Friday, November 30, 2012 8:07 AM
To: [email-masked]
Subject: Re: [rtcweb] Text communication in RTCWEB sessions

* is not used yet

This is just because of lack of making conclusions of observations on how
users are using IM today. Research reports indicate that all would be more
happy being provided with real-time text than message-wise IM. Users need to
adapt to the shortcomings of IM because no big service provider has yet
provided real-time text together with other media in a conveniently
available conversational tool. 

There is user push among accessibility users and relay service personnel who
have acces to the technology. It is used and appreciated in text relay
services, total conversation services, Sign relay services, IP text
telephony services and captioned telephony services. 

* doesn't have legal push (the regulators still haven't *decided* to impose
it) 

Why not?

If IM is going to be enhanced to provide a real-time text feature within the
IM services, the XMPP extension in creation might be a valid alternative
because it is so well integrated in the IM environment.
But for interworking with SIP, RFC 4103 seems to be the choice. One
important indication is that it is included  in the NG112 and NG911
specifications for emergency services.

So, what does rtcweb want to be, IM with real-time media additions and SIP
interworking, or real-time conversational service?  Or both?

Gunnar

---

From: Randell Jesup <[email-masked]>
Date: Fri, 30 Nov 2012 12:04:30 -0500

> Instant messaging and real time text are complementary forms of text communication. One does not replace the other.

Sure, for emergency calls RTT is not surprising.   However, that doesn't 
help us resolve this issue.

We have two 'requirements' for text: Emergency Accessibility, and 
Accessibility to provide "equivalence" in FCC-ish terms.  These may well 
not want to use the same solution.  And even if they do in one country, 
they may not in another.  And the required minimum solution may not be 
what the user prefers to use.  We need to build something that can 
provide realtime communication to websites/web-apps/etc, and enable them 
to provide required and wished-for services to users all over the world, 
not just in the US or Europe (though those cover a large percentage of 
areas that mandate these functions for telephony).

There are also ancillary "requirements" to gateway these conversations 
to existing infrastructures.

(I'll note as an aside that the FCC is going to run into a thorny 
problem of "so, someone has a service with calling and it's based in 
Europe/Russia/Bangkok, and they don't comply with CVAA/E911/etc". 
Especially when it's free and there are no monetary payments they can 
hook into.  I'm not going to try to solve it for them here.)

I think standardizing "foo-over-DataChannels" for accessibility is the 
best solution, and then gateways can convert to "foo-over-SIP/RTP".  
(Note that there may be more than one "foo".) We agreed to add a 
"protocol" label to DataChannel creations, which should help inter-app 
interoperation for this by identifying the DataChannel is for "foo".

This does mean that applications using webrtc that need to comply with 
CVAA/E911/etc (not all will) need to include "foo" in JS.  For E911/etc 
they'll need to include support in their server-side code anyways for a 
bunch of other stuff to local PSAPs, etc. Alternatively we could provide 
support objects (at the W3C level) to help with providing RTT/whatever 
in JS; that would be there and not here.

-- 
Randell Jesup
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Nov 2012 10:48:18 -0800

Thanks for the additional detail, Mark.  It is also perhaps useful to make clear that XEP-0301 is compatible with a number of existing XMPP services (including IM&P and MUC), so that the RealJabber client can be run over GoogleTalk (as an example) today.   

Also, as was noted in the conversation surrounding the recent update to XEP-0301, the document does describe a mechanism for encoding of RTT which could be separated out from XMPP -- such as if someone wanted to use it to encode/decode RTT just for use within their own website, without the need to communicate with XMPP clients. 

Given that XEP-0301 can be incorporated into web sites today (using the Strophe library, for example), even sites that don't support WebRTC, one of the questions we need to answer is exactly what functioning needs to be native in the browser and what scenarios that would support, beyond what is already possible with XEP-0301 today. 

One scenario which seems beyond the XEP-0301 capability is the "911 RTT" scenario.  This is not because of any limitation in XEP-0301 per se, but because XMPP does not currently support emergency services.  For example, the bare JID "[email-masked]" could refer to an actual user within the example.com domain, so placing this bare JID within the "to:" field of an XMPP message stanza would not necessarily result in a conversation with a PSAP via an RFC 4103 gateway. 

The other scenario which seems distinct is a scenario in which RTT is synchronized with audio/video.   However, the discussion on this thread has  pointed only to the need for loose synchronization, which would not necessarily require peer-to-peer transport and also would not seem to require RFC 4103 encoding in RTP, or even native RTTP support in the browser.  

In terms of creating a new standard for RTT transport over the data channel, I am sceptical.  I could see utilizing the RTT encoding suggested in XEP-0301 over a data channel, outside of XMPP stanzas.  That would suffice to provide RTT capabilities on a single site that is not attempting to federate.  

Going beyond that to creating an alternative transport for RFC 4103 does not seem helpful.  If we are requiring a transport gateway to go from RTT over SCTP to RFC 4103 over RTP, then we still have to touch every RTT packet, as well as munging the SDP since an RFC 4103 endpoint will expect an "m=text" line, not a data channel negotiation.  This will introduce fragility as well as latency.  So I'm not clear that it gets us closer to implementation of any of the potential use cases. 

> From: [email-masked]
> Date: Fri, 30 Nov 2012 11:00:02 -0500
> To: [email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 01 Dec 2012 07:58:56 +0100

I said below that there are research indications that IM users would 
like real-time text functionality in IM, but I did not provide any 
references and explanations. Here they are:

----------------------------------------------------------------------------------------------------
Research references showing that mainstream IM users would be more happy 
with using real-time text:

1. RIM usability study show that mainstream users prefer real-time text 
over Instant Messaging.
http://transition.fcc.gov/cgb/dro/EAAC/usability_study_results.pdf

2. Usage of IM research:
http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf

This research says that average message length in IM was just below 30 
characters per message, and average rate was 6 messages per minute in 
the sessions they studied.
That clearly indicates that users artificially shortens their messages 
in order to send something sooner than regular composition of complete 
messages would require.  They squeeze the messaging tool to do a not 
fully satisfactory pseudo-real-time text behavior.

3. Do-it-yourself research:
Ask a small group of people:

a. Have you ever felt a bit of stress to complete your message or even 
shortened off your message when using Instant Messaging so that the 
other party would get a chance to take part of your thoughts soon enough?

b. Have you ever thought when waiting for a message in IM that you would 
like to get a view of what the other party is typing?

c. Have you ever experienced that you or the other party in an Instant 
Messaging exchange has typed a message while the other party is also 
composing a message, causing cross-posting and two threads in the same 
dialogue and a risk for misunderstanding of what response belongs to 
what question?

If you see a smile of recognition or get a yes on at least one of these 
questions, you have identified a market case for introducing a real-time 
text feature in the Instant Messaging environment, or providing a 
real-time text feature in the real-time video and audio calls.
I tried this sequence of questions on two persons last Tuesday, in a 
meeting on accessible emergency services, and I got both recognizing 
smiles and yes responses.

Why not give users what they want?

Gunnar

---------------------------------------------------------------------------------------------

On 2012-11-30 14:06, Gunnar Hellström wrote:
> provider has yet provided real-time text together with other media in 
> a conveniently available conversational tool.
>
> There is user push among accessibility users and relay service 
> personnel who have acces to the technology. It is used and appreciated 
> in text relay services, total conversation services, Sign relay 
> services, IP text telephony services and captioned telephony services.
> There is currently one well working standard, mainly intended for use 
> in SIP.
>
> If IM is going to be enhanced to provide a real-time text feature 
> within the IM services, the XMPP extension in creation might be a 
> valid alternative because it is so well integrated in the IM environment.