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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Tue, 27 August 2019 18:57 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 93AFE120869 for <mmusic@ietfa.amsl.com>; Tue, 27 Aug 2019 11:57:13 -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 AuChRFA-GwkQ for <mmusic@ietfa.amsl.com>; Tue, 27 Aug 2019 11:57:11 -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 E64D1120851 for <mmusic@ietf.org>; Tue, 27 Aug 2019 11:57:10 -0700 (PDT)
X-Halon-ID: 6f1f5dcd-c8fc-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 6f1f5dcd-c8fc-11e9-bdc3-005056917a89; Tue, 27 Aug 2019 20:56:54 +0200 (CEST)
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, mmusic@ietf.org
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <a91850b9-6e86-058f-dddd-3f856bcd6710@omnitor.se> <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>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <173fc580-3a30-913b-ebba-5b0cb59702c8@omnitor.se>
Date: Tue, 27 Aug 2019 20:57:07 +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: <255759e0-c2c0-981a-e530-e05f7553c26e@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/74x9Q8bpCypHSZCd7BGAWb8_ZuQ>
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: Tue, 27 Aug 2019 18:57:14 -0000

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?

Regards

Gunnar

>
>     Thanks,
>     Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic