Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Gunnar Hellström <> Sun, 25 August 2019 08:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 822D4120127 for <>; Sun, 25 Aug 2019 01:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NME3dId8QUa9 for <>; Sun, 25 Aug 2019 01:56:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7758B120077 for <>; Sun, 25 Aug 2019 01:56:08 -0700 (PDT)
X-Halon-ID: 2b053d7c-c716-11e9-903a-005056917f90
Received: from [] (unknown []) by (Halon) with ESMTPSA id 2b053d7c-c716-11e9-903a-005056917f90; Sun, 25 Aug 2019 10:56:04 +0200 (CEST)
To: Christer Holmberg <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Sun, 25 Aug 2019 10:56:04 +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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Aug 2019 08:56:13 -0000

Hi Christer,

Quite good, see one comment inline,


Den 2019-08-25 kl. 10:25, skrev Christer Holmberg:
> Hi Gunnar,
> Please see inline.
> --------------------------------------------------------------------------------------------------------------------------------------------
> 18. Add a new section 4.5
> 4.5 Multi-party considerations
>>>> Implementations should be prepared to accept establishment and use of multiple T140 data channels in order to support multi-party sessions
>>>> with real-time text. A number of scenarios are available for how multi-party sessions can be supported in the WebRTC environment.
>>>> Implementations may select any suitable scenario.
>>> I don't think we need the two last sentences.
>>> Also, in some cases all communication will go via a central server, so there will only be one T.140 data channel towards each participant.
>> No, T.140 has no source indicator of its own, it relies on the transport to indicate the source for each T140block.
> Good point.
>> In RTP, this can be done by an RTP mixer making one stream from multiple sources including CSRC for the sources
>> of the primary text and for the redundant generations of text in each packet. On the T140 data channel side, I do
>> not know any corresponding way to indicate different sources in the same data channel.
>> The solutions I see are:
>>         1) create one T140 channel per source/destination pair. or
>>         2) Introduce a source indicator in the data format for the T140 data channel, either one per STCP message
>>         requiring all T140blocks in the message being from one source only, or inline between series of T140blocks
>>         from different sources.
>> This is because the real-time text from multiple sources simultaneously need to be presented with some separation,
>> so that the text gets readable at least sentence-wise from each source. The T.140 Appendix 1 shows two ways to do
>> this, one column-oriented, and one sentence-oriented with a label per start of sentence. You can read more about
>> the topic in
>>> So, maybe something like:
>>> "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly
>>> with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels."
>> While that is true, it does not tell us how to solve the case with a conference server.
>>>> Presentation should be made so that the source of the real-time text is perceivable and the relative time relations in the conversation approximately presented.
>>>> The "label" attribute may be used to convey a presentable source.
>>> I am not sure I understand the "relative time relations" part.
>> In order to enable the reader to follow the flow of a multi-party text conversation, it is a good habit to present older text placed higher in
>> the text area and newer text placed lower. (This is valid for both when you present text in one column per source and if you combine all
>> sources in one (IRC-style) column).
>> It is also a good habit to present text from the same source readable together, e.g. sentence by sentence, (and not break the text just
>> because a text item from another source was received during the time the sentence was created).
>> These two requirements are in conflict. A true time-related presentation would fragment simultaneous text from different sources into unreadability,
>> and presenting all text from each source in one chunk each would give no clue about the flow of the discussion.
>> Therefore this expression " the relative time relations in the conversation approximately presented".
> Gotcha.
>>> Regarding the source, perhaps extending my suggested text above with something like:
>> "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly
>> with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels. The label
>> attribute can be used to provide information that helps an implementation to distinguish between the T.140 data channels."
>> Yes, this is a good statement for the case without the server, or can be modified for a server that maintains a channel per source.
>> But which solution do you prefer if we allow a mixing server?
>> 1) require also servers to support one T140 data channel per source
>> 2) introduce a data format for the T140 data channel containing a unique source identifier
>> 3) introduce a source identifier in-line in the T.140 data stream. (T.140 is extendable)
> Short term, as far as the draft is concerned, I think we should go for alternative 1. Alternatives 2 and 3 would probably take some time, so
> if done I think it should be done as a separate task (and, again, probably in a separate WG).
> So, what about the following text:
> "If an implementation needs to support multi-party scenarios, implementations (both clients and servers) need
> to support multiple simultaneous T.140 data channels, one for each source. At the time of writing this document, this
> is true even in scenarios where each participants communicate via a centralized conference server. The reason is
> that, unlike RTP media, WebRTC data channels and the T.140 protocol do not support the indication of the source of T.140 data.
"participants" s.b. "participant"
> NOTE: Future extensions to T.140, or to the T140block, might allow indicating the source of T.140 data, in which case
> it might be possible to use a single T.140 data channel to transport data from multiple sources."
Should also "the T140 data channel data format" be among the options for 
where to place the source information?



> Regards,
> Christer
> _______________________________________________
> mmusic mailing list

Gunnar Hellström
+46 708 204 288