Subject: [rtcweb] Real-time text

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 17 Dec 2013 11:15:58 +0100

I am picking up an old thread about how to do real-time text (RTT) in 
the WebRTC environment.
On 2012-12-03 20:26, Adam Roach wrote:
> We can do RTT right now with data channels. I can hack together a 
> ridiculously simple example on top of Firefox Nightly build if you 
> want to see it.
Yes, I want to accept that offer, thanks.

It would also be good to have a common specification on how to do it.

Here is a set of requirements:

 1. Text shall be delivered in order.
 2. The presentation protocol elements shall be conveyed to the receiver.
 3. Transmission problems shall not cause long blocking of transmission
    for retries, but rather mark the loss and transmit next text sample.
 4. If there are transmission problems, retries shall continue up to a
    defined maximum time (e.g. 3 seconds). If unsuccessful, the
    transmitter should be notified, and the receiver shall be notified
    at least at next successful transmission to the receiver.
 5. Duplications shall not appear.
 6. Gaps appearing because of bad transmission shall be marked in the
    received text. When T.140 is used, that is done by the UTF-8
    character "replacement character".
 7. The source of the transmission shall be conveyed so that it can be
    displayed together with received text.
 8. The transmission contents are short time-sampled strings of UTF-8
    coded characters consisting of text and presentation control codes.
    (e.g. according to ITU-T T.140)
 9. The method shall not cause overhead of more than 10 kbit/s (rather
    much less) when transmitting every 300 ms.
10. Transmission shall be performed in time samples of 300 - 700 ms
    each. 300 ms is preferred if overhead is acceptable.
11. It shall be possible to use the transmission for multiparty calls,
    where text from different sources shall be displayed separate, e.g.
    as in a multiparty text chat but with real-time display. This can be
    achieved in three ways:

a.Each transmission has information about the source in a structured way.

b.Each source sets up its own data channel. The source is identified 
when the channel is set up.

c.Source information is embedded in the text.

I have tried to map these requirements to the rtcweb data channel with 
the following conclusions:

*RTCDataChannel use for real-time text transmission*

The WebRTC data channel offers suitable types of reliable or 
partially-reliable channels where retransmissions can be maximised to a 
time or a number.

The RTCDataChannel type most suited for these requirements seem to be 
the ordered type with a MaxReTransmit Time=3000, and Protocol= T140 ( 
T140 needs to be registered with IANA, before that is completed, the 
experimental versions need to set Label = T140. )

But it is not clear if it provides information about transmission 
failures to the transmitter or the receiver.

If no error info about loss is provided, then a sequence number needs to 
be provided with each transmission and an identification of gaps on 
reception.

The connections can become closed in case of transmission problems. It 
should then be opened again. In such a procedure, it cannot be known if 
text was lost or transmitted in the shift between the current and 
previous channel instance. Therefore it seems that text samples should 
have sequence numbers, and the receiving application need to check 
arrived text samples for duplication and loss. In case of duplication, 
the duplicate shall be discarded. In case of loss, the UTF-8 replacement 
character shall be inserted in the received string.

The transmitter samples the text source for text and transmits every 300 
ms, when there is text to transmit.
The receiver checks received text for duplication and gaps and displays 
text according to T.140 presentation.

Do you agree in these conclusions?

/Gunnar

---

From: <[email-masked]>
Date: Tue, 17 Dec 2013 14:39:13 +0100

If you want to connect an existing T.140 system, you need to build a gateway. Even if the browsers supported RfC 4103, you would still need a gateway in most cases, as few SIP/H.248 RTP endpoints support DTLS / SRTP and bundling.
You can easily define your own protocol between that data channel / T.140 gateway and the browser. Both sides are under your control. You can use an unreliable data channel and define a packet format that includes sequence and ack numbers so you can detect missing or re-ordered packets.  This will require a minor effort in Javascript, but gives you a lot of freedom. If you are not tied to T.140 (eg if you communicate between browsers), you could even transmit handwriting in real-time. I wish we had the same flexibility for video..

Wolfgang Beck

Von: rtcweb [mailto:[email-masked]] Im Auftrag von Gunnar Hellstrom
Gesendet: Dienstag, 17. Dezember 2013 11:16
An: Adam Roach; [email-masked]
Betreff: [rtcweb] Real-time text

I am picking up an old thread about how to do real-time text (RTT) in the WebRTC environment.
On 2012-12-03 20:26, Adam Roach wrote:
We can do RTT right now with data channels. I can hack together a ridiculously simple example on top of Firefox Nightly build if you want to see it.
Yes, I want to accept that offer, thanks.

 1.  Text shall be delivered in order.
 2.  The presentation protocol elements shall be conveyed to the receiver.
 3.  Transmission problems shall not cause long blocking of transmission for retries, but rather mark the loss and transmit next text sample.
 4.  If there are transmission problems, retries shall continue up to a defined maximum time (e.g. 3 seconds). If unsuccessful, the transmitter should be notified, and the receiver shall be notified at least at next successful transmission to the receiver.
 5.  Duplications shall not appear.
 6.  Gaps appearing because of bad transmission shall be marked in the received text. When T.140 is used, that is done by the UTF-8 character "replacement character".
 7.  The source of the transmission shall be conveyed so that it can be displayed together with received text.
 8.  The transmission contents are short time-sampled strings of UTF-8 coded characters consisting of text and presentation control codes. (e.g. according to ITU-T T.140)
 9.  The method shall not cause overhead of more than 10 kbit/s (rather much less) when transmitting every 300 ms.
 10. Transmission shall be performed in time samples of 300 - 700 ms each. 300 ms is preferred if overhead is acceptable.
 11. It shall be possible to use the transmission for multiparty calls, where text from different sources shall be displayed separate, e.g. as in a multiparty text chat but with real-time display. This can be achieved in three ways:
a.       Each transmission has information about the source in a structured way.
b.       Each source sets up its own data channel. The source is identified when the channel is set up.
c.        Source information is embedded in the text.
I have tried to map these requirements to the rtcweb data channel with the following conclusions:
RTCDataChannel use for real-time text transmission
The WebRTC data channel offers suitable types of reliable or partially-reliable channels where retransmissions can be maximised to a time or a number.
The RTCDataChannel type most suited for these requirements seem to be the ordered type with a MaxReTransmit Time=3000, and Protocol= T140 ( T140 needs to be registered with IANA, before that is completed, the experimental versions need to set Label = T140. )
But it is not clear if it provides information about transmission failures to the transmitter or the receiver.
If no error info about loss is provided, then a sequence number needs to be provided with each transmission and an identification of gaps on reception.
The connections can become closed in case of transmission problems. It should then be opened again. In such a procedure, it cannot be known if text was lost or transmitted in the shift between the current and previous channel instance. Therefore it seems that text samples should have sequence numbers, and the receiving application need to check arrived text samples for duplication and loss. In case of duplication, the duplicate shall be discarded. In case of loss, the UTF-8 replacement character shall be inserted in the received string.

The transmitter samples the text source for text and transmits every 300 ms, when there is text to transmit.
The receiver checks received text for duplication and gaps and displays text according to T.140 presentation.

/Gunnar

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Dec 2013 08:58:12 -0600

Unfortunately, I have other obligations that would keep me from doing 
something as rigorous as you describe below at the moment.

However, I'll point out that something like this -- which doesn't even 
go peer-to-peer -- already satisfies all of your requirements except for 
#3 and #6: https://etherpad.mozilla.org/TexVGQxmQJ

I think you can envision how porting a system like this to use 
unreliable datachannels rather than reliable websockets would make it 
trivially possible to address those two requirements, right?

/a

On 12/17/13 04:15, Gunnar Hellstrom wrote:
>  3. Transmission problems shall not cause long blocking of
>     transmission for retries, but rather mark the loss and transmit
>     next text sample.
>     coded characters consisting of text and presentation control
>     codes. (e.g. according to ITU-T T.140)
>     where text from different sources shall be displayed separate,
>     e.g. as in a multiparty text chat but with real-time display. This
>     can be achieved in three ways:
>
> partially-reliable channels where retransmissions can be maximised to 
> a time or a number.
>
> If no error info about loss is provided, then a sequence number needs 
> to be provided with each transmission and an identification of gaps on 
> reception.
>
> should then be opened again. In such a procedure, it cannot be known 
> if text was lost or transmitted in the shift between the current and 
> the duplicate shall be discarded. In case of loss, the UTF-8 
> replacement character shall be inserted in the received string.
>
> The receiver checks received text for duplication and gaps and 
> displays text according to T.140 presentation.
>
>
>