Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - is recvonly etc support desired?

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 01 September 2019 21:27 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250001200C5 for <rum@ietfa.amsl.com>; Sun, 1 Sep 2019 14:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_MZuKJmlz4o for <rum@ietfa.amsl.com>; Sun, 1 Sep 2019 14:26:55 -0700 (PDT)
Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5ABB1200A4 for <rum@ietf.org>; Sun, 1 Sep 2019 14:26:54 -0700 (PDT)
X-Halon-ID: 2c72834a-ccff-11e9-bdc3-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 2c72834a-ccff-11e9-bdc3-005056917a89; Sun, 01 Sep 2019 23:26:34 +0200 (CEST)
To: rum@ietf.org
References: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> <c4ebbc2e-063b-5bd7-1b03-27e95de78dc2@alum.mit.edu> <5142d3b2-da81-25f0-8859-694cd6126f0b@omnitor.se>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <e7903a95-768a-3574-6dd8-f4dcb646a80d@omnitor.se>
Date: Sun, 01 Sep 2019 23:26:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <5142d3b2-da81-25f0-8859-694cd6126f0b@omnitor.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/H-nbwipGifS4JvYnBBfqg2R_8v4>
Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - is recvonly etc support desired?
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2019 21:27:01 -0000

I would like a comment from RUM if it is desirable to have support for 
the direction attributes : sendrecv, sendonly, recvonly, inactive,  for 
RTT streams?

It might be for control of muting etc in multi-party situations, but of 
course also in other situations.

Regards

Gunnar

Den 2019-08-31 kl. 22:47, skrev Gunnar Hellström:
> Hi John,
>
> Thanks for a good base for discussion.
>
> See inline,
>
> Den 2019-08-30 kl. 17:12, skrev Paul Kyzivat:
>> John,
>>
>> On 8/30/19 7:32 AM, John Martin wrote:
>>> All,
>>>
>>>   $0.02 on RTT:
>>
>> Thanks for joining in! I don't have much knowledge of (and no 
>> experience using) RTT so I will mostly watch from the sidelines as 
>> long as others join in.
>>
>>     Thanks,
>>     Paul
>>
>> (BTW, I don't know how you formatted your message, but in my mail 
>> reader (Thunderbird) none of your lines wrapped, requiring horizontal 
>> scrolling to read them.)
>>
>>> RTT in General
>>>
>>> --------------
>>>
>>> ISTM there are a few options for RTT in RUM, assuming the WebRTC 
>>> media framework is adopted (as seems likely):
>>>
>>> 1.Use existing browser support for SCTP as recommended by the some 
>>> of the WebRTC IETF WG participants. This was discussed as part of 
>>> the IVC WG and would require and SCTP data channel to be negotiated 
>>> and to encapsulate the RTP (4103) which then in turn encapsulate 
>>> T.140 RTT. This solution would require gateways in the VRS provider 
>>> networks, RTP/RTCP userspace (Javascript) layers in the browser and 
>>> a T.140 RTT layer/UI also written in userspace in the browser.
>
> The current work discussed in mmusic  about 
> draft-holmberg-mmusic-t140-usage-data-channel  specifies T.140 
> real-time text transported directly in a "reliable" WebRTC data 
> channel, identified with subprotocol "t140". Would that not be 
> suitable for a WebRTC based RUM? The data payload will be the same as 
> carried in RFC 4103 if used without redundancy. You mention that 
> embedded RTP with RFC 4103 would be used as data also in the data 
> channel. That sounds complicated. What would you gain?
>
> I hope you also follow the discussion in mmusic.
>
>>>
>>> 2.Wait for WebRTC to support lower level data channels. This work is 
>>> being discussed in the WebRTC community, but might be a case of “not 
>>> holding our breath”. A lower level data channel would allow RTP/RTCP 
>>> then T.140 to be negotiated in the SDP without the need for SCTP and 
>>> associated gateway needs.
> Since the RTCWEB WG is closed now in IETF, this sounds as a 7 year 
> uncertain plan.
>>>
>>>
>>> 3.As a stop-gap and simplification, support SIP MESSAGE as already 
>>> provided for by the browsers and many endpoints, including WebRTC 
>>> endpoints.
> SCTP data channels are supported as well, and you can just agree to 
> start using it with a private subprotocol temporarily among RUMs until 
> there is a standard. So why use SIP MESSAGE?
>>>
>>>
>>> We should not forget that RTCP must be implemented along with RTP.
>>>
>>> Conferencing and RTT
>>>
>>> --------------------
>>>
>>> RTT in a conference is not currently defined and does not work using 
>>> currently defined standards (I must admit to being being on mmusic 
>>> so perhaps there are solutions being recommended there). Discussions 
>>> on this have been ongoing for nearly 10 years (we didn’t solve it 
>>> then Gunnar and I think the problems are still the same). For RTT to 
>>> be useful in a conference there needs to be a few problems solved.
>
> If you do it with multiple streams sent to the clients, then there are 
> no problems. Therefore there was hesitation when we discussed to bring 
> up the topic in IETF.
>
> For mixing into one stream, there are problems. You can do it with 
> normal RTP and conferencing specifications but get some limitations. 
> You can select between a presentation planned by the mixer, or use 
> CSRC in RTP to indicate the source of primary data in each packet and 
> let the client plan the presentation. Both work and do not really need 
> any further standardisation, but would benefit from good best practice 
> specifications or even a standard for solving some problems.
>
> Planning and formatting the presentation in the mixer has the 
> limitation that only the local user and one at a time of the remote 
> users text can be presented in real-time. Text from the others need to 
> be buffered until the currently presenting remote participant makes 
> something so that giving turn to next in queue is suitable. Switching 
> turn can be made automatically, based on completed phrase or sentence 
> or message or inactivity or allowed maximum time by the presenting 
> party. Identification about who is sending which text needs to be 
> formatted by the mixer and is likely best in form of an IRC style 
> label when the source is switched. This works for a call where users 
> are reasonably well-behaved in taking turns. There are cases where the 
> presentation in one column with sources in labels is not what the user 
> wants.
>
> Using just one stream, and mark by CSRC who contributed to primary 
> data in each packet works as long as no packet was lost. The receiver 
> can make a better adapted presentation for presentation preferences by 
> the user. And text can be presented in real-time from more than two 
> users at the same time.
>
> But in order to use the redundant RFC 4103 data to recover text in 
> case of packet loss, then also the redundant data needs to be marked 
> with source. And for that, a convention is needed and standardised. A 
> couple of variants are possible with different pros and cons. Losing 
> so many packets that a missing text marker needs to be inserted also 
> has its problems that needs a specified solution.
>
>>>
>>> 1.Multi-stream support: Brian, whilst you’re right that most 
>>> conference systems are point-to-point for signalling they are more 
>>> typically point-to-multi-point for media. The conference bridge 
>>> usually handles the multiplexing of the streams, but they are 
>>> usually now multiple streams. RTT conferencing needs to have the 
>>> same support. We should assume conferencing is supported by way of 
>>> SFU not MCU – that’s how WebRTC handles conferencing and we should 
>>> assume the same for RTT.
> Yes, that is now the main path for 
> draft-holmberg-mmusic-t140-usage-data-channel, and I think that is 
> good. That is also possible without any further standardization for 
> RTP based RTT.
>>>
>>> 2.Participant identification: streams from the conference bridge 
>>> (MCU/SFU) must be tagged with the sender so the UI can signal to the 
>>> user who sent that text (and reconstruct the stream correctly).
> Yes. Use CSRC / CNAME for RTP and  stream ID / label / session 
> information for WebRTC data channel.
>>>
>>> 3.UI adaptions: Modern WebRTC based multi-party conferences have 
>>> adapted UIs to display multiple video streams. UI’s are adapted to 
>>> show the video participants however the user wants them to be 
>>> displayed (single full screen, tiled, voice activated etc). We 
>>> should expect no less from RTT conference enabled endpoints. It 
>>> should be a user decision (if their UI supports it) as to whether 
>>> they see line-by-line or RTT rendering of the text conversation.
> Yes. If you want a one column presentation, a reasonable presentation 
> is to automatically assign one remote party at a time to be presented 
> in real-time and present the others phrase by phrase, and 
> automatically switch who is presented in real-time based on suitable 
> criteria.
>>>
>>> 4.Control of how many simultaneous participants can text and how 
>>> that is presented to the user needs to be explored. Multiple 
>>> insertion points in the UI is one approach (though rapidly breaks 
>>> down as the number of users increases). Line-by-line is another. 
>>> Facilitated GA is another (the Go Ahead concept has been used for a 
>>> long time in text conversations and may be appropriate in large RTT 
>>> conferences to control overload).
>>>
>>> And a final FWIW: I think the utility of RTT in a conference quickly 
>>> breaks down as the number of participants increases. It is 
>>> completely unacceptable to have a single RTT stream presented to the 
>>> user and an unmodified UI. You might as well revert to SIP MESSAGE 
>>> and something like XMPP, and that could also be an option for either 
>>> the short term or for endpoints that do not support multi-stream RTT.
>
> In some conferences it might be desirable with one dominating RTT 
> source: a written interpretation of what is said, and then 
> occasionally another participant gets the floor and types something . 
> It is very valuable if that mode of conferencing is available without 
> hazzle in general multi-party conference systems. The utility does not 
> break down in that situation.
>
> It seems to me that aiming at multi-stream RTT support is to prefer.
>
>
> Regards
>
> Gunnar
>
>>>
>>> John
>>>
>>> Brian said: we agreed we were using 4103 in RUM.
>>>
>>> Good toknow. But is there not a hope to be able to even use browser
>>>
>>> technology for the implementation. The browsers only support RTP for
>>>
>>> audio and video. Can you make RTP-based RTT work in that environment 
>>> and
>>>
>>> encrypted with the security method specified for WebRTC?
>>>
>>> See a bit more below:
>>>
>>> Den 2019-08-29 kl. 21:59, skrev Malloy, Jim:
>>>
>>>> “line at a time” is a user interface issue – RUM is defining a machine 
>>>
>>>> interface.  How it’s presented to the user is out of scope.
>>>
>>>>
>>>
>>> Well, the control and coding must be made so that it is possible to 
>>> make
>>>
>>> a good presentation. Transmission only line-by-line would not suit the
>>>
>>> intention of RTT. It is hard to make a good RTT presentation with a
>>>
>>> client that is only expecting text from one other participant and a
>>>
>>> mixer that has the task to send text from many sources combined in one
>>>
>>> stream. The best result is usable but not nice. And it will be aimed at
>>>
>>> just one way to present RTT. No freedom to plan the presentation
>>>
>>> according to user preferences.
>>>
>>> A receiver may, if there is a desire for such functionality, store
>>>
>>> received text until a received message is complete. I do not think that
>>>
>>> it is to prefer in any situation.
>>>
>>> Regards
>>>
>>> Gunnar
>>>
>>>> --Jim
>>>
>>>>
>>>
>>>> *From:* Rum <rum-bounces@ietf.org> 
>>>> <mailto:rum-bounces@ietf.org&gt>; *On Behalf Of * 
>>> Brian Rosen
>>>
>>>> *Sent:* Thursday, August 29, 2019 1:15 PM
>>>
>>>> *To:* Kyzivat, Paul <pkyzivat@alum.mit.edu> 
>>>> <mailto:pkyzivat@alum.mit.edu&gt>;
>>>
>>>> *Cc:* rum@ietf.org <mailto:rum@ietf.org>
>>>
>>>> *Subject:* [EXT] Re: [Rum] Real-time text in WebRTC is discussed in 
>>>
>>>> mmusic - a topic closely telated to rum
>>>
>>>>
>>>
>>>> “Line at a time” could be an implementation option.  The protocol 
>>>
>>>> mechanism is all streams head to a mixer and the mixer sends a single 
>>>
>>>> stream to each participant.
>>>
>>>>
>>>
>>>> Gunnar, we agreed we were using 4103 in RUM.
>>>
>>>>
>>>
>>>> Brian
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>      On Aug 29, 2019, at 12:05 PM, Paul Kyzivat 
>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
>>>
>>>>  <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>>>
>>>
>>>>      I question how well RTT text is suited to multiparty conferences.
>>>
>>>>
>>>
>>>>      If you have messages on your screen from multiple parties, and
>>>
>>>>      many of them are updating in real-time, are you going to be able
>>>
>>>>      to perceive what is going on?
>>>
>>>>
>>>
>>>>      And while you can have a column per person for two-party and 
>>>> maybe
>>>
>>>>      3-party conversations, that doesn't scale up. With many parties,
>>>
>>>>      some typing may scroll off the screen before it is complete.
>>>
>>>>
>>>
>>>>      Perhaps for conferences it is better to just use line-at-a-time
>>>
>>>>      chat. If necessary, I presume there could be gateways between RTT
>>>
>>>>      and chat. A RUE could have the capability to negotiate down from
>>>
>>>>      RTT to chat.
>>>
>>>>
>>>
>>>>      Thanks,
>>>
>>>>      Paul
>>>
>>>>
>>>
>>>>      On 8/28/19 2:15 AM, Gunnar Hellström wrote:
>>>
>>>>
>>>
>>>>          Den 2019-08-27 kl. 23:15, skrev Brian Rosen:
>>>
>>>>
>>>
>>>>              At least by centralizing the problem at a “mixer”, Alice
>>>
>>>>              and Bob will see the same thing.
>>>
>>>>
>>>
>>>>              You don’t have the problem in Instant Messaging, because
>>>
>>>>              you can’t backspace or delete a sent message.  Of course
>>>
>>>>              if multiple people are typing simultaneously in such
>>>
>>>>              systems, message order will be confusing in that instant.
>>>
>>>>
>>>
>>>>          Right, it is a similar kind of problem that text appears 
>>>> in an
>>>
>>>>          unexpected order. There is also at least one instant 
>>>> messaging
>>>
>>>>          service that allows modification in already sent message. But
>>>
>>>>          I think it has limitations to only accept that in the last
>>>
>>>>          message sent. it is convenient anyway.
>>>
>>>>
>>>
>>>>
>>>
>>>>              Anyway, we need to specify the mixer for RTT so it
>>>
>>>>              receives each of the RTT streams and produces a single
>>>
>>>>              composite stream for each participant.
>>>
>>>>
>>>
>>>>          Yes, right, and there is an effort in that direction in:
>>>
>>>> http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf 
>>>>
>>>
>>>>          It is written for conference-unaware user devices.
>>>
>>>>          The goals are specified as follows:
>>>
>>>>          The procedures are intended to make best efforts to present a
>>>
>>>>          multi-party text conversation on a terminal that has no
>>>
>>>>          awareness of multi-party calls. There are some obvious
>>>
>>>>          drawbacks, and a terminal designed with multi-party awareness
>>>
>>>>          will be able to present multi-party call contents in a more
>>>
>>>>          flexible way. Only two parties at a time will be allowed to
>>>
>>>>          display added text in real-time, while the other parties’
>>>
>>>>          produced text will need to be stored in the multi-party 
>>>> server
>>>
>>>>          for a moment awaiting a suitable occasion to be displayed.
>>>
>>>>          There are also some cases of erasure that will not be
>>>
>>>>          performed on the target text but only indicated in another
>>>
>>>>          way. Even with these drawbacks, the procedure provides an
>>>
>>>>          opportunity to display text from more than two parties in a
>>>
>>>>          smooth and readable way.
>>>
>>>> --------------------------------------------------------------------------------------------------- 
>>>>
>>>
>>>>          I see such mixer procedures as a fall-back for cases without
>>>
>>>>          conference awareness, but want to see support for
>>>
>>>>          conference-aware terminals, where text from more than two
>>>
>>>>          parties can be presented in real-time, and the end user or 
>>>> app
>>>
>>>>          can have influence over the presentation style - e.g. select
>>>
>>>>          between the multiple column view and the
>>>
>>>>          one-column-with-labels view. A mixer for that case would only
>>>
>>>>          need to assure that the receiver has the right kind of
>>>
>>>>          multi-party awareness and send RTT text with source
>>>
>>>>          information attached, and let the receiving terminal sort out
>>>
>>>>          the presentation. This is already possible with CSRC and 
>>>> CNAME
>>>
>>>>          when using RTP, but we lose that possibility natively when
>>>
>>>>          using the WebRTC data channel to transport RTT, and would 
>>>> need
>>>
>>>>          to specify a way to include the source also for that case.
>>>
>>>> ------------------------------------------------------
>>>
>>>>          By the way, what is your current view of how to transport RTT
>>>
>>>>          for RUM, now when you say that you will use WebRTC transports
>>>
>>>>          for media?
>>>
>>>>          Regards
>>>
>>>>          Gunnar
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>                  On Aug 27, 2019, at 4:43 PM, Gunnar Hellström
>>>
>>>> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>>
>>>> <mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>> 
>>>>
>>>
>>>>                  wrote:
>>>
>>>>
>>>
>>>>                  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
>>>
>>>> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>>
>>>> <mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>> 
>>>>
>>>
>>>>                          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
>>>
>>>> gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>>
>>>> <mailto:gunnar.hellstrom@omnitor.se>
>>>
>>>>                          +46 708 204 288
>>>
>>>>
>>>
>>>>                  --
>>>
>>>> -----------------------------------------
>>>
>>>>                  Gunnar Hellström
>>>
>>>>                  Omnitor
>>>
>>>> gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>>
>>>> <mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se> 
>>>>
>>>
>>>>                  +46 708 204 288
>>>
>>>>
>>>
>>>>          --
>>>
>>>> -----------------------------------------
>>>
>>>>          Gunnar Hellström
>>>
>>>>          Omnitor
>>>
>>>>         gunnar.hellstrom@omnitor.se 
>>>> <mailto:gunnar.hellstrom@omnitor.se> 
>>> <mailto:gunnar.hellstrom@omnitor.se>
>>>
>>>>          +46 708 204 288
>>>
>>>>
>>>
>>>>
>>>
>>>>      --
>>>
>>>>      Rum mailing list
>>>
>>>>     Rum@ietf.org <mailto:Rum@ietf.org> <mailto:Rum@ietf.org>
>>>
>>>> https://www.ietf.org/mailman/listinfo/rum
>>>
>>>>
>>>
>>>>
>>>
>>> -- 
>>>
>>> -----------------------------------------
>>>
>>> Gunnar Hellström
>>>
>>> Omnitor
>>>
>>> gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>>
>>> +46 708 204 288
>>>
>>>   * [Rum] Real-time text in WebRTC is discussed in ...
>>> <https://mailarchive.ietf.org/arch/msg/rum/hzX30Lo4DY4J3RGbtgxoC5wpE1s>  Gunnar 
>>>
>>>     Hellström
>>>   * Re: [Rum] Real-time text in WebRTC is discussed...
>>> <https://mailarchive.ietf.org/arch/msg/rum/Lk90w0qStmiAmHoIw_mWFTOE3pY>  Brian 
>>>
>>>     Rosen
>>>   * Re: [Rum] Real-time text in WebRTC is discussed...
>>> <https://mailarchive.ietf.org/arch/msg/rum/opt7uhe3jcCAGEXipXCefVN97PE>  Gunnar 
>>>
>>>     Hellström
>>>   * Re: [Rum] Real-time text in WebRTC is discussed...
>>> <https://mailarchive.ietf.org/arch/msg/rum/uF83bn9GmEkR2FzE4rvH-DiJn1I>  Brian 
>>>
>>>     Rosen
>>>   * Re: [Rum] Real-time text in WebRTC is discussed...
>>> <https://mailarchive.ietf.org/arch/msg/rum/6402q9HzKBNqvkwKajSlo4EYmMU>  Gunnar 
>>>
>>>     Hellström
>>>   * Re: [Rum] Real-time text in WebRTC is discussed...
>>> <https://mailarchive.ietf.org/arch/msg/rum/YG02TyKon1tRtctZ1Bwe0BnI7Cw>  Paul 
>>>
>>>     Kyzivat
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/UDz0JCzyqQ0ut8RJzWF54KjMUXY>  Malloy, 
>>>
>>>     Jim
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/WWekfAbXC81GFmOdUld1YOvV450>  Paul 
>>>
>>>     Kyzivat
>>>   * Re: [Rum] Real-time text in WebRTC is discussed...
>>> <https://mailarchive.ietf.org/arch/msg/rum/8N5sWJvqB-J4XgC5xqMCV2nL0gc>  Brian 
>>>
>>>     Rosen
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/HoD8Ni1r0f8S11H2K4hp6Ss5NB0>  Brian 
>>>
>>>     Rosen
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/eI-dX4HrMUur324GEt-CFmpv4mY>  Paul 
>>>
>>>     Kyzivat
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/AaoKog-HhtBUS_a-BKrB5BpwiF4>  Brian 
>>>
>>>     Rosen
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/1JojOtitB-FlcmCHQd9LMl4PWM4>  Paul 
>>>
>>>     Kyzivat
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/2NDD2kMSGngnh6GyoLD9Th_UYrM>  Brian 
>>>
>>>     Rosen
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/UZDyKrfOw-bjkbqjN8E3MHXrseo>  Malloy, 
>>>
>>>     Jim
>>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is...
>>> <https://mailarchive.ietf.org/arch/msg/rum/avASfCcxCAY18gOFsTGE3P5oTOs>  Gunnar 
>>>
>>>     Hellström
>>>
>>> -- 
>>>
>>> *John Martin*
>>>
>>> Email: John.Martin@Purple.us <mailto:John.Martin@Purple.us>
>>>
>>>
>>
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288