Re: [rtcweb] Real-time text

[Adam Roach <[e-mail]>]

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:
> 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
>