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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 29 August 2019 15:11 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 4CC77120100 for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 08:11:27 -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 CUNI483wbICd for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 08:11:25 -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 95E3C12007A for <mmusic@ietf.org>; Thu, 29 Aug 2019 08:11:25 -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 x7TFBMVR023804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Thu, 29 Aug 2019 11:11:23 -0400
To: mmusic@ietf.org
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@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> <49da444c-c74f-b7b4-49be-72b2e4c3fbb9@alum.mit.edu> <3102c9de-0d99-0a9c-c3d3-1baf2a3d1b5d@omnitor.se> <HE1PR07MB316107D614D83B75EB44421293A30@HE1PR07MB3161.eurprd07.prod.outlook.com> <HE1PR07MB31613E4B56430C7829A4586193A30@HE1PR07MB3161.eurprd07.prod.outlook.com> <HE1PR07MB316197DD9F693CB226C4F60C93A30@HE1PR07MB3161.eurprd07.prod.outlook.com> <25c89003-7f18-b440-a058-b3e6d8d42fdd@alum.mit.edu> <HE1PR07MB3161F193995F03EF01483A7793A30@HE1PR07MB3161.eurprd07.prod.outlook.com> <dcd0f0e5-9f30-3a5b-9409-5f4e256c4d53@omnitor.se> <HE1PR07MB31615C58CD1DA39C8A5C261A93A30@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <61fde23d-b49c-3de7-980a-31fd5aab82a4@alum.mit.edu>
Date: Thu, 29 Aug 2019 11:11:22 -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: <HE1PR07MB31615C58CD1DA39C8A5C261A93A30@HE1PR07MB3161.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/7iCG1ylfqn-f2Q1M3MvQ1tqIBIg>
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: Thu, 29 Aug 2019 15:11:28 -0000

On 8/28/19 4:22 PM, Christer Holmberg wrote:

> My suggestion for the next step would be that you send an e-mail to AVT, and describe the issue, and ask:
> 
> 1) Is using a single data channel for multiple remote users an issue to begin with (basically Paul's question), or can we assume that there will always be a separate data channel for each remote participant
> 2) If it is an issue, and a single data channel could be used for multiple remote participants, what would be the best way to solve it

+1