[rtcweb] Real-time text

[Gunnar Hellstrom <[e-mail]>]

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