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

Gunnar Hellström <> Sun, 25 August 2019 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F3A71200F5 for <>; Sat, 24 Aug 2019 23:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 M_paxzbyhe0Y for <>; Sat, 24 Aug 2019 23:49:00 -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 5A64312007C for <>; Sat, 24 Aug 2019 23:49:00 -0700 (PDT)
X-Halon-ID: 68102ce2-c704-11e9-903a-005056917f90
Received: from [] (unknown []) by (Halon) with ESMTPSA id 68102ce2-c704-11e9-903a-005056917f90; Sun, 25 Aug 2019 08:48:55 +0200 (CEST)
To: Christer Holmberg <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Sun, 25 Aug 2019 08:48:56 +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: multipart/alternative; boundary="------------C9EEC629C97823C8C60523F2"
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 06:49:04 -0000

Hi Christer,

Below are comments on the multi-party considerations

Den 2019-08-24 kl. 12:04, skrev Christer Holmberg:
> --------------------------------------------------------------------------------------------------------------------------------------------
> 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. 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 draft-hellstrom-text-conference-04.txt 

> 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".

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


> ----------------------------------------------------------------------------------------------------------------------------------
> -
> -
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> +46 708 204 288