Subject: [rtcweb] Consensus call on Text Communication

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Nov 2012 10:01:58 +0100

WG,

This is the start of an one week+ call for consensus that will end on
Sunday the 9th of December. The question for consensus is: Shall a use
case be added regarding Text communication within the context of
PeerConnection, i.e. not using the generic capabilites of WebRTC, but
rather provide a specific media type and its transport.

Please indicate your support or objections for this!

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Nov 2012 01:06:49 -0800

I do not think that a use case on text communications would solve the problem by itself.  The reality is that realtime text can be used in a number of different ways, which will generate different implementation requirements.  Rather than trying to boil this down into a single use case, it makes more sense to me to have a document that explains the uses that are envisaged and the resulting implementation requirements.  If we had such a document, the use case document could refer to it.  

> Date: Fri, 30 Nov 2012 10:01:58 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: [rtcweb] Consensus call on Text Communication
> 
> WG,
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 30 Nov 2012 09:31:27 +0000

I'd like to know how WebVTT and WebRTC interact, if at all, before knowing how to answer this.

Matthew Kaufman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Friday, November 30, 2012 9:02 AM
> To: [email-masked]
> This is the start of an one week+ call for consensus that will end on Sunday
> the 9th of December. The question for consensus is: Shall a use case be
> added regarding Text communication within the context of PeerConnection,
> i.e. not using the generic capabilites of WebRTC, but rather provide a specific
> media type and its transport.
>

---

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

What do you mean by interact?

What I do know is that a hearing impaired user may use RTT to support a voice call, or support a RTT call with voice. It is not one or the other.

Indeed if you look at the interworking between IMS and the PSTN, you will see that in the PSTN side the mechanism is capable of real time switching between the two.

It is real time communication, rather than deferred (as in fax or IM or email).

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Matthew Kaufman
> Sent: 30 November 2012 09:31
> To: Magnus Westerlund; [email-masked]
> Subject: Re: [rtcweb] Consensus call on Text Communication
> 
> Sunday

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Nov 2012 17:34:46 +0100

> Please indicate your support or objections for this!
I object to adding such an use case.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 30 Nov 2012 09:51:37 -0800

> I object to adding such an use case.

+1

---

From: Martin Thomson <[email-masked]>
Date: Fri, 30 Nov 2012 10:49:20 -0800

On 30 November 2012 01:06, Bernard Aboba <[email-masked]> wrote:
> I do not think that a use case on text communications would solve the
> problem by itself.  The reality is that realtime text can be used in a
> number of different ways, which will generate different implementation
> requirements.  Rather than trying to boil this down into a single use case,
> it makes more sense to me to have a document that explains the uses that are
> envisaged and the resulting implementation requirements.  If we had such a
> document, the use case document could refer to it.

+1

At this point I have choice but to object.  As pointed out in several
different ways, submitting use cases in piecemeal to the list is
insufficient.  A document describing how RTT fits into the larger
context might let me make a more informed choice about the right
technical solution.

---

From: Adam Roach <[email-masked]>
Date: Fri, 30 Nov 2012 13:00:54 -0600

> context might let me make a more informed choice about the right

I also agree with Bernard. While a coherent use case document would be 
helpful, I think the requirements would be far, far more important.

I have a very strong suspicion that any reasonable set of requirements 
on user-perceived behavior can be satisfied using existing web browser 
technologies without imposing any additional work on the WebRTC 
specifications. Putting pen to paper to detail actual user experience 
requirements would show if and where my suspicions are wrong.

/a

---

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

+1

A document would be a good start, looking at the constraints, available 
technologies and possible solutions.  We've pointed out here that the 
problem and solution space is ... interesting, with lots of issues and 
needs to predict future needs.  And lots of constraints.

-- 
Randell Jesup
[email-masked]

---

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

> requirements would show if and where my suspicions are wrong.
A document describing the requirements quite thoroughly both from users' 
view and technically, and describing some available implementations is 
ETSI EG 202 320 Duplex Universal Speech and Text
http://www.etsi.org/deliver/etsi_eg/202300_202399/202320/01.02.01_60/eg_202320v010201p.pdf

---

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

Also RFC 5194 describes the requirements quite well.

There is also a short requirements chapter in draft XEP-0301, maybe much 
less describing the usage but more as a starting point for adding 
real-time text to the XMPP environment.
See http://xmpp.org/extensions/xep-0301.html

It is much better if the feature can be seen as being of mainstream 
interest as well as of accessibility interest rather than something 
introduced because of regulated accessibility requirements. But if that 
is not achievable right now, we need to fall back to pointing at 
accessiblity regulation to get it specified and implemented.

I think we have repeated the basic requirements many times already, but 
here they are again:

1. The important things are that real-time text usage together with 
rtcweb/webrtc gets specified consistently enough to achieve wide-spread 
interoperable implementation together with audio and video in the same 
session.
2. Interworking with SIP calls with all three media and real-time text 
using RFC 4103 shall be possible.
3. Presentation of characters shall be possible within two seconds after 
keypress or other entry (but one second is preferred).
4. An entry and transmission rate up to 30 characters per second shall 
be supported( to allow also speech to text applications )
5. Text needs to be able to be expressed in any character set 
internationally ( implying UTF-8 transmission).
6. Text needs to have not more than 0.2% errors in environments where 
video and audio are regarded usable.
7. It is valuable if places for possible text loss because of 
transmission errors can be shown in the received text.
8. Editing shall be possible, at least erasing text and appending text 
and new lines.
9. Addressing, calling and connection of all three media together shall 
be possible in one simple user operation.
10. Multiparty, call transfer, call hold shall be possible and act on 
all the established media.
11. Adding or deleting any of the three media shall be possible during a 
session.

Usage will be any human text conversation spanning from occasional 
adding of small items of text during a voice or video call, to a call 
where the majority of conversational interaction is done by real-time text.

Gunnar

On 2012-11-30 21:17, Gunnar Hellström wrote:
>> I also agree with Bernard. While a coherent use case document would 
>> be helpful, I think the requirements would be far, far more important.
>>
>> I have a very strong suspicion that any reasonable set of 
>> requirements on user-perceived behavior can be satisfied using 
>> existing web browser technologies without imposing any additional 
>> work on the WebRTC specifications. Putting pen to paper to detail 
>> actual user experience requirements would show if and where my 
>> suspicions are wrong.
> A document describing the requirements quite thoroughly both from 
> users' view and technically, and describing some available 
> implementations is ETSI EG 202 320 Duplex Universal Speech and Text

---

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

It has been said a number of times that the rtcweb data channel would be 
suitable for real-time text.

I have also seen doubts about that expressed.

One alerting doubt was that it did not seem to have well established 
implementations. And the protocol spec is very thick. It might take a 
long time before it is implemented with reliable function and good 
interoperability. Right?

I would like to know more about the data channel.

How much overhead is it per transmission?

Is it possible to specify capability negotiation of features using the 
data channel?
  Does that require additions to the specs.

There are indications that the data channel can be used in reliable and 
unreliable mode. Does the reliable mode have the risk for stalled 
communication that is common for reliable protocols? How is the mode 
controlled?

In what way would it be better to use the data channel than RTP with 
redundancy?

Gunnar

---

From: Randell Jesup <[email-masked]>
Date: Fri, 30 Nov 2012 17:21:07 -0500

On 11/30/2012 4:17 PM, Gunnar Hellström wrote:
> There is also a short requirements chapter in draft XEP-0301, maybe 
> much less describing the usage but more as a starting point for adding 
> introduced because of regulated accessibility requirements. But if 
> that is not achievable right now, we need to fall back to pointing at 

I think the protocols likely to be mandated for accessibility and 
emergency use are not what would likely be preferred by applications for 
general use (which likely would be much higher featured, and selected 
and controlled by the apps.

>
> I think we have repeated the basic requirements many times already, 
> but here they are again:
>
> rtcweb/webrtc gets specified consistently enough to achieve 
> wide-spread interoperable implementation together with audio and video 
> in the same session.

This is the strongest point, IMHO.  Though most uses (excluding 
emergency uses) will be homogenous apps, not heterogeneous - Unlike SIP 
UAs and hard endpoints, many users will use the app for the service to 
contact someone on that service, not depend on federation to connect 
their in-the-home-hardware to someone elses different hardware UA.  
There will be exceptions to this where big services set up peering with 
others, or different apps from the same provider get used.

Still, this is important to do - though depending on where and how it 
might not be directly part of rtcweb.

> 3. Presentation of characters shall be possible within two seconds 
> after keypress or other entry (but one second is preferred).
> 9. Addressing, calling and connection of all three media together 
> shall be possible in one simple user operation.
> 11. Adding or deleting any of the three media shall be possible during 
> a session.

The last several items are in the domain (largely or entirely) of the 
application and service provider providing it, unless we want to bake 
the display and text-entry directly into media elements.  The 
application has to capture keystrokes somewhere, do any local editing, 
send them to the other side (via whatever - datachannel or "text" 
mediastream).  I do NOT think we'll be baking those directly into the 
browser; it ties the hands of the apps too much.  So likely (to support 
this) there will be JS libraries anyways - so that could also abstract 
from the app the actual channel used (DataChannel vs. MediaStreams) and 
also the actual protocol as well.

If we bake it into the core, it is less likely to have bugs (and they'll 
get fixed faster, probably), but likely it will become a 
least-common-denominator that is painful for apps to rise above.  If 
this is in a JS library, it can handle basic accessibility and emergency 
use, but people can add support for more than just the minimum fairly 
easily (fork it, etc).

What I don't want is something where the UI interaction or display is 
locked down into the browser (type into the video element, fixed-style 
subtitle displays where there's no opportunity for UI improvements and 
alternate layouts/interactions).

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Fri, 30 Nov 2012 17:36:54 -0500

On 11/30/2012 4:58 PM, Gunnar Hellström wrote:
> It has been said a number of times that the rtcweb data channel would 
> be suitable for real-time text.
>

The protocol spec is tiny (draft-jesup-rtcweb-data-protocol).  If you're 
thinking SCTP, yes it's large - so are UDP and TCP, and it does a lot 
more.  It's used a lot in telephony; very little on the open web.

> How much overhead is it per transmission?

Not a lot.  The rtcweb DataChannel protocol adds nothing to a datagram.  
SCTP is slightly larger than TCP IIRC, not a lot.  Ask Michael Tuexen or 
Randall Stewart; maintainers of SCTP and authors on the spec who are 
working with us.

> Is it possible to specify capability negotiation of features using the 

yes

>  Does that require additions to the specs.

No, you can specify them at channel open time (see the draft), or 
(proposed) in negotiation (draft-mmusic-sdp-something).

> There are indications that the data channel can be used in reliable 
> and unreliable mode. Does the reliable mode have the risk for stalled 

Reliable can stall (like any reliable protocol).  You can specify 
partially-reliable which is probably what you really want: limited time 
or number of retransmissions (settable by the app).  You can also 
specify only in-order delivery.  You can even have out-of-order delivery 
with reliable (which removes almost all head-of-line blocking; you'll 
need some internal framing to properly deal with out-of-order delivery 
of course as with any such).

> In what way would it be better to use the data channel than RTP with 

Redundancy is a hammer; SCTP allows smarter options with retransmission 
only where needed.  Reliable out-of-order delivery might be perfect for 
this use (as I  believe it will eventually get the data through if the 
channel is in any way usable).

You can have multiple channels used for different purposes, with 
different reliability settings.

-- 
Randell Jesup
[email-masked]