Re: [rtcweb] Real-time text

[<[e-mail]>]

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:[e-mail]] Im Auftrag von Gunnar Hellstrom
Gesendet: Dienstag, 17. Dezember 2013 11:16
An: Adam Roach; [e-mail]
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.

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