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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 28 August 2019 14:49 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44E120043 for <mmusic@ietfa.amsl.com>; Wed, 28 Aug 2019 07:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 eSdKpt4sm7hA for <mmusic@ietfa.amsl.com>; Wed, 28 Aug 2019 07:49:37 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 3F42C12001E for <mmusic@ietf.org>; Wed, 28 Aug 2019 07:49:36 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7SEnWul006418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 10:49:33 -0400
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, mmusic@ietf.org
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@ericsson.com> <6fcf46a6-544d-027c-97c7-5c0e08caa555@omnitor.se> <HE1PR07MB3161A9A0C696B9636BBD380C93A70@HE1PR07MB3161.eurprd07.prod.outlook.com> <6484f305-0c38-4178-ee12-05a7dc38364f@omnitor.se> <HE1PR07MB31617F7C6E81EF041716749793A60@HE1PR07MB3161.eurprd07.prod.outlook.com> <ee4e6d3a-e984-15c7-dcaa-571be0e726b8@omnitor.se> <HE1PR07MB3161CC8F09E178F2E982E5AC93A60@HE1PR07MB3161.eurprd07.prod.outlook.com> <a5057f34-f222-e290-df88-da6e96d56294@omnitor.se> <A48CA18B-567B-46B9-9501-4FF65D4C8CAE@ericsson.com> <6c6d13ad-8699-73b9-f8aa-8ef16c5b3451@omnitor.se> <FB8E32BC-89C2-41CE-BBE1-81C4E7A56E77@ericsson.com> <f59f9335-329d-7b26-dec3-0898051040ce@omnitor.se> <VI1PR07MB31675A98F9B08A07D984369293A10@VI1PR07MB3167.eurprd07.prod.outlook.com> <084e8ee3-56fe-b764-fbbe-8afbee72e8e3@omnitor.se> <255759e0-c2c0-981a-e530-e05f7553c26e@alum.mit.edu> <173fc580-3a30-913b-ebba-5b0cb59702c8@omnitor.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <49da444c-c74f-b7b4-49be-72b2e4c3fbb9@alum.mit.edu>
Date: Wed, 28 Aug 2019 10:49:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <173fc580-3a30-913b-ebba-5b0cb59702c8@omnitor.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Vyweu_-vUiU6OXVNnZT3CK96Vzc>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2019 14:49:39 -0000

On 8/27/19 2:57 PM, Gunnar Hellström wrote:
> Hi Paul,
> 
> Please see inline,
> 
> Den 2019-08-27 kl. 20:39, skrev Paul Kyzivat:
>> On 8/26/19 3:59 PM, Gunnar Hellström wrote:
>>
>>> 4. A multi-party server S, combining a number of sources into one 
>>> call to a participant A, with real-time text from each other 
>>> participant (B,C,...) communicated in just one T140 data channel 
>>> between S and A. There is a need to indicate source for each 
>>> T140block sent to A. We currently have no way specified for that. An 
>>> extension of T.140 could do it.
>>
>> Is there a reason to ever do this?
>>
>> In audio and video the "mixing" actually does something irreversible. 
>> And it takes real work to do it, and doing so reduces the bandwith 
>> considerably over what is required to transmit the individual streams.
>>
>> For RTT none of that is true. There is very little impact in bandwidth 
>> or processing in transmitting them all as separate channels.
>>
>> So why not just say "don't do that"?
> 
> Yes, interesting and realistic thought. It would likely be the best 
> choice for many practical cases.
> 
> I am not sure however how it will work with a huge conference with 
> hundreds of participants, and some of them occasionally asking for the 
> floor and send a bit of RTT text. A server using one data channel per 
> participant would either be required to establish an enormous amount of 
> T140 data channels being prepared to send what has been received, or 
> take the effort to establish a new T140 data channel to all users at the 
> moment a user gets the floor, and then possibly close it again.
> 
> What do you think about that case?

Initially each user would only have one channel. Then he gets another 
one added each time there is a new speaker who hasn't spoken before. I 
don't know if there would be formal floor control, or if everyone would 
always be allowed to talk. Formal floor control would provide an early 
hint to establish the new channels, possibly preventing delays. But 
adding a channel isn't an expensive operation and delaying messages 
until it is done shouldn't be a problem.

But is this a realistic issue? Do RTT conferences with hundreds of 
speakers happen in practice?

	Thanks,
	Paul