Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum

[Gunnar Hellström <[e-mail]>]

Den 2019-08-27 kl. 21:48, skrev Brian Rosen:
> The problem of conference 4103 RTT is high on my list of work I need to get done.  So, I’m motivated to help out.
Thanks, great.
> The basic problem is that we’re going to get very inconsistent UI doing it that way, because of how systems will handle backspace of one party that extends beyond responses from other parties:
(well, for me the currently most basic problem is to have a reliable way 
to append received text to the already presented text of the right 
participant. And that is getting worse in WebRTC than it was in RFC 
4103. But we will sort it out.)
>
> Alice: I waited for you
> Bob: I didn’t see you
> Alice: sorry
>
> And then Alice types 12 backspaces.
>
> What should happen?

You are right that there are a number of ways to handle the RTT UI. And 
just as inconsistencies are common with a message oriented UI, where 
messages show up in a confusing order because two users completed 
messages in an unexpected time order, it is possible that RTT text gets 
displayed in a strange order after erasure and retyping. It is better 
for RTT than for message oriented presentation, and user get used to it 
in both cases.  With the labelled style in one column you have in the 
example, I would recommend that first 5 backspaces erase "sorry", next 
backspace erases the line separator, and pulls down "I waited for you" 
to be shown last, as an uncompleted text. Then the next 6 backspaces 
erase so that only "I waited f" is displayed. When Alice adds text and 
end with a new line, the corrected sentence is allowed to flow up when 
new text is added from any participant.  That causes a bit strange 
order, but it is just as manageable as when text in messaging 
applications appear in an unexpected order so that one message seems to 
be a respone on something totally else than what was intended.

A sophisticated UI may mark text that is moved and modified.

We want to keep sentences or at least phrases from each participant 
together in a readable unit. Already that causes a design decision on 
where to place the completed chunk of text once the user has completed 
it. The start of the chunk may be older than completed text from other 
participants which would motivate to move it up a bit in the 
presentation. But the end of it is at that moment the latest text to 
present. I think it is best to let the finished text be presented last 
on the display, but let others' newer text push everything up and be 
displayed last.


T.140 has information on how to handle erasure:

-------------------From T.140---------------------------

8.2 Erase last character
Purpose: Erase the last character sent from the display at the receiving 
end.
Code: BS: 0008.
Procedure: On the receiving end: Move the insertion point to the last 
character and erase it.
Combined characters are erased as a unit, with one BS erasing the whole 
character even if it is
combined from more than one component.
Control sequences (like CR LF) are erased in one operation.
NOTE – The same action shall be taken on the local display.

------------------------------------------------------------

   /Gunnar

>
> Brian
>
>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellström <[e-mail]> wrote:
>>
>> Hi,
>>
>> A topic is currently discussed in mmusic that is closely related to rum. it is WebRTC transport of real-time text.
>>
>> The draft is draft-holmberg-mmusic-t140-usage-data-channel .
>>
>> A good point to start reading could be:
>>
>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel
>>
>> Please check if the current state of the discussion suits rum!
>>
>> The only issue that seems to be remaining is how to transport RTT data to and from a conference server that combines all traffic per media in a meeting in one data stream. That is not very elegantly specified for RFC 4103 transport of RTT in RTP either, so we might want to do a rapid action together to solve the multi-party RTT MCU case in a general and consistent way.
>>
>> Regards
>>
>> Gunnar
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> [e-mail]
>> [phone]
>>
>>
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]