Re: [AVTCORE] Opsdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-14

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 21 May 2021 14:46 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789E13A12FB; Fri, 21 May 2021 07:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.com
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 XyHDKgMP3I37; Fri, 21 May 2021 07:46:12 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70057.outbound.protection.outlook.com [40.107.7.57]) (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 476F93A12F9; Fri, 21 May 2021 07:46:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bw3z6Do77O9Eky0YQ208p9w+Esb9tgEC8O+fIl5k7+xJSY2oyqbYaAdQTnBRucwTUpXtndQugXiU1llQWAIDRy7k15Nh/wdYI5Cse3TYW5UgixILb5DXEgld46tqiyArfT6Es4Si26EJU+ruAZQ28aKgxPhCr7TSR+7SZLNDN8RdbwfdTWYucYLd8pnhAjDYcD8TJZsiqrraDN9kge12UdMhwUsgpSytRB6OdmthZIRwU2b8qFR3e7br4SXsuFR024WEx/xS6r7IH9MNAJbqSN/6WN5MdD+aE+ptXa0ZRXz5AHjPC9JMuWD4nQgYYR23ltmyxyBSVrxh347I4qLTMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TJ1O+pLoW701es+xerWRnCkoW4o+2RXDLoRtP05NcfU=; b=U6ZkOSFM+78JKiU/B9SOiRMZx0PJVtdVmXJFosiaaO96WUZB+9LGVRVokoxhSjkpbF9iAPXTyr1faqOrfC8yMwIEuFSZY3StGMJcyaB36g1+BhuTnLI5IRoO+U/1BCWdmZ1HuIPwNqw3/o+mrWmtfdUcjwlAOfLY35oo7KDoqlDlXVAyiijya+esC+RYzKQmG6ny7FRgwUk8Q/0j0q+XslmufXhqTYhWRVuCPJOMZaOPV7RkVouCpCDoI5t1OvAbohrQ9YUJ8tLwcDjfdCsEJtSezcd66rUT031gK2G5YFA6tvSuVd+tz5kWZ633duOpTojBYbGaxK1qmEvYCCkgLg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TJ1O+pLoW701es+xerWRnCkoW4o+2RXDLoRtP05NcfU=; b=TfTCcvs/4qj0ebDSjwwywteYaFgWIfvXylsknEWMdPnV3w54dyolIjQaUibTU6pfT/xiajPg/JJFYGKdI1eyFJCqywg6hKUtizLElPKWB/+7eO4cwmEqwYglcWXrXfDbI4M6UOefDXn6z7SjWFDYbrZU40258N+4XcKHDQPSIb4=
Authentication-Results: ghaccess.se; dkim=none (message not signed) header.d=none;ghaccess.se; dmarc=none action=none header.from=jacobs-university.de;
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1331.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.23; Fri, 21 May 2021 14:46:09 +0000
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4150.023; Fri, 21 May 2021 14:46:09 +0000
Date: Fri, 21 May 2021 16:46:08 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Gunnar =?utf-8?Q?Hellstr=C3=B6m?= <gunnar.hellstrom@ghaccess.se>
Cc: ops-dir@ietf.org, last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org
Message-ID: <20210521144608.xp2klodaoz23oots@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Gunnar =?utf-8?Q?Hellstr=C3=B6m?= <gunnar.hellstrom@ghaccess.se>, ops-dir@ietf.org, last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org
References: <161951914802.5120.8507635650494768525@ietfa.amsl.com> <7a7ed2b4-bb23-48ea-d55d-c5804a2363af@ghaccess.se> <b76936fc-95ed-4722-c1d9-f4c6fdb20977@ghaccess.se>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b76936fc-95ed-4722-c1d9-f4c6fdb20977@ghaccess.se>
X-Originating-IP: [212.201.44.244]
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com (2603:10a6:20b:28f::35) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (212.201.44.244) by AM0PR02CA0228.eurprd02.prod.outlook.com (2603:10a6:20b:28f::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.24 via Frontend Transport; Fri, 21 May 2021 14:46:08 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3d69805d-92d1-4e29-43c3-08d91c672ba5
X-MS-TrafficTypeDiagnostic: AM9P190MB1331:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM9P190MB1331EC145BA7026D863DC1DBDE299@AM9P190MB1331.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: lp/gltCLf4kcA5npWCc0DJw187ifF0GOJ68lTcez1RfnZOgjPpCvz/i63mkmV7w4HHLcgW4H7JmmPxmdEhjIcP6POigjJbXscR6gWq3hTt7F5jRpQBRmjeZwTcN57heIx3YR9D8mKCdWwRNV9Jr5U4g3UZnsYVOPd/Bau/aiPWArLXwLfF4aAhVFIhLIA8Mp+Ha24+wub0fSgAzGePuo8MPmzTl4RRQN+7O1bip95BRyZDKPe1rkhlY9eaEr0UGkjKyh8qFaifzWKuZSJ7zoA5X6dJAvdvCjoQ42qqZjDzyKCAs7gzCqFYCIMVN4lbRhDfJGZ34mOuuigz7Zt30tRiuu1TGuqiisB+V1qmCbFQve3DCqB/5MjMneEjfqN9B9x/4tYaWQd1C0YwB1h09jD9pMUdVFt/XI07ZRxM/U+oL6Ojswqb8W5r5M4F4uEHvC93OkBdm192ffLlw9PZiDIPxZ69OZ0FgyH+OlfV6qFEmwPHR8hpiGtCeGwx0qRNANQIqyriaHgNnLNPCsDx23wL8g0j7sOmtBHvnUicK2o9rFOn9jjRxMUolBgFCqHxNBGBUiBvPXMH9ZUH0uEdhh7NXAgxDvCn2oUnNR/bhvg5XAWY4vENMq+py86VyIH7Ykxalrog0Pa2NdVU9HDMKW5pGzvQjRDhvZf9aHd5pPvxdAX28N+WvU3/6FcExNS2fsjwsf/SeuWJre3tHYmLfXrHUAS1Xa3mXj8bSGsLNuAXC/FmXdoZX2+Xa5Qb4eJBUB95zq43NFVaLOdsaktrNVtg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(39850400004)(396003)(376002)(366004)(52116002)(2906002)(16526019)(4326008)(5660300002)(66556008)(478600001)(6496006)(66946007)(1076003)(66476007)(8676002)(83380400001)(956004)(186003)(38100700002)(38350700002)(26005)(6916009)(8936002)(6486002)(786003)(966005)(316002)(3450700001)(66574015)(86362001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?504sSnlGmq53+kDare7zRd0MC8QNUDFVkusk7gwreUTqWLUL6n2jHm0sWq?= =?iso-8859-1?Q?pbyIdzIdFW8JjR8W2o64f09eoTbGa3lQ3KQHr5Xdd7u3UqLE9/Ds5MI5r6?= =?iso-8859-1?Q?QTD73Iv1G/J9JfxLswWDmL5qiITniMZhbEGOgzlvZX7MBu1rmXkShjROcW?= =?iso-8859-1?Q?ATi8gzJZibARWYD/IpvfQ9zvfbeEwCt7Dl+z5hcitq5A0HYB5s1jy3ian+?= =?iso-8859-1?Q?UgirxQbTaUNY6wu+DtC31YQ6oFbkqinEd+NFZVTPcwMzyeJFTsznPK7gns?= =?iso-8859-1?Q?JloxD6szyaL5cMv3J9JfKBfACSqLfaq5vdB7SH+eQ/7hPrCBoHgOvrl7wt?= =?iso-8859-1?Q?8GeoeS6UOXthVXCc9O2ARlB4KdiiIW5DhZmTq002PcL7yK2N0O+TO+t3Wz?= =?iso-8859-1?Q?QuZWw1zg7PlmfL3pWfKGOOtmYigFE9QByjqvDFzHj01r9J0PwZmSC4dkJq?= =?iso-8859-1?Q?PVfGhQlcfyXTm0PtUxUfqrVuDxFC5rglrAZQGqlr3zCUY+Hn0ucSl5lUPo?= =?iso-8859-1?Q?aVR8oUx6PT4H5mCWLO/o+OOdIQDf1muxpPoFu6Jn2e6LylrI0ZAm4msnXq?= =?iso-8859-1?Q?IzudspB/eJV65QfMjsL3JCNSq5Q8HqbSMUAhmfkiNzM/EMa8do6BEjx0uw?= =?iso-8859-1?Q?XLM8DzEXwR9rzElLg1/pak7iBvhy0nB7dkAuDtkPFuSydOOyjGLQNxBoF0?= =?iso-8859-1?Q?qgNb3+1Tiy5JwyOF3YoZdlKarzR0rsL33le/OdH6Y5zVKaqU52YAEDh7WZ?= =?iso-8859-1?Q?ZcNArOL6MdCWa3SvNj2gR/4aZrXgpNGIZmORffsB1juNusC4BrzLWgKWhk?= =?iso-8859-1?Q?ssVMZI+IdY/vX43jSX5Av+E1oSOlZVhnxR4aBOHXEl4SgI8S6I9gOMaIJ9?= =?iso-8859-1?Q?I0vWwcgq023mCOSPb1r9EaURnAZc7ZR60NhxSRvTtMY3HxK4WHYIPJfw8P?= =?iso-8859-1?Q?nzWc/67tqxuOIW7Yj8NdFwH3biXB+i2zuuVBZHjtDwVrouN6egEr4BApZN?= =?iso-8859-1?Q?0Vsh29zsmLF+ZPnJx7XR2x3WId3GU7x7YMKZlDg7xVj7OXMRzYa3PlRKZF?= =?iso-8859-1?Q?hjBqaCILLIoAD7oVjgrb3buGpqCalrZT3K15gxIat5Yq9Tg2VLMM9vEnGZ?= =?iso-8859-1?Q?U4tNsTOOZ3A9xcX9FcWbYxp/mSl+0rEJdtCgowdZJzZi7wlvKiM5UMj/2u?= =?iso-8859-1?Q?JjaEHF12ZRvc69H1SIak+KM4BIRzYGBgIAPY/bEwj3nEIgTylW3R/Dt7Yr?= =?iso-8859-1?Q?oLg91UJPqfV4kvE5E4exh/V7ehwwNQyv/gZBTx+6p7eu/6T4mB3CAqd/JV?= =?iso-8859-1?Q?FeDeEsH4BbX3ezmzKTV7mwnEire64tr4wTOWXnLr3TDLhWTn3UBo7BV3Ri?= =?iso-8859-1?Q?8LsKPWeaA1?=
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d69805d-92d1-4e29-43c3-08d91c672ba5
X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2021 14:46:09.0549 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pey+Da3ZvU3Soo59JbM0BtWBrgB0U+O9wVOFntqOhV4Mo03tur+ZkDhbzRy1tnLh0e57zJS4H2PISsGeUHPV+WjSsPiXs1HOl217a69Rrbc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1331
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/qGF0b2IZjJR4fZ3ayJHuh_6JrBk>
Subject: Re: [AVTCORE] Opsdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 14:46:18 -0000

Gunnar,

this looks all good to me. Thanks for considering my comments.

/js

On Wed, Apr 28, 2021 at 01:44:20PM +0200, Gunnar Hellström wrote:
> Jürgen,
> 
> I have submitted a new version, acting on your comments.
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-15.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-15
> 
> 
> Here is a summary of what I did:
> 
> Actions on review comments from Jurgen Schonwalder:
> 
>    A bit more about congestion situations and that they are expected to
>    be very rare.
> 
>    Explanation of differences in security between the conference-aware
>    and the conference-unaware case added in security section.
> 
>    Presentation examples with source labels made less confusing, and
>    explained.
> 
>    Reference to T.140 inserted at first mentioning of T.140.
> 
>    Reference to RFC 8825 inserted to explain WebRTC
> 
>    Nit in wording in terminology section adjusted.
> 
> I hope this satisfies your comments.
> 
> Thanks,
> Gunnar
> 
> 
> Den 2021-04-27 kl. 23:58, skrev Gunnar Hellström:
> > Thank you for your review.
> > 
> > I will provide initial reactions here, and follow up with more exact
> > proposals for changes.
> > 
> > Den 2021-04-27 kl. 12:25, skrev Jürgen Schönwälder via Datatracker:
> > > Reviewer: Jürgen Schönwälder
> > > Review result: Has Nits
> > > 
> > > I am by no means an expert in this area so please take this into
> > > account while reading my comments...
> > > 
> > > Content comments:
> > > 
> > > * The document assumes "human" communication, i.e., where text
> > >    originates at a speed of a human and politeness is used to resolve
> > >    concurrency conflicts. This seems to be a fair assumption for the
> > >    considered use cases but what happens if this assumption is not met?
> > >    Can systems or RTP mixers detect and handle such situations
> > >    gracefully or is the idea that any resulting "jerkiness" must be
> > >    accepted if senders misbehave?
> > 
> > [GH] The receivers are expected to declare their reception speed
> > capability in characters per second (over a 10 second period). A high
> > capability will allow smooth flow of text from many participants
> > simultaneously. The congestion section 9 tells what can be done if the
> > load gets too high. The mixer can then discard text, and if it has any
> > means to detect who is the main contributer, it can avid to discard text
> > from that participant. (e.g. by the sdp "content" attribute.
> > 
> > This is of course not nice. But it is equally not nice to try to hear
> > any specific voice in a mixed audio channel with many participants. And
> > same with video in cases when the video has real information.
> > 
> > So we are in good company with the other media in the problem that there
> > are no really good solutions to an information overload situation.
> > 
> > In most cases the typing participants will send a sentence or two and
> > then stop and read or listen to the others. In such situations the
> > overload will be sorted out after a short while even without the
> > participants being very polite.
> > 
> > Do you want me to elaborate more about this in the congestion chapter 9?
> > 
> > > 
> > > * The solution does not provide end-to-end security since the mixer
> > >    must be trusted to have access to the texts in order do the mixing.
> > >    This is mentioned in the security considerations and in section 2
> > >    where alternatives are considered. The reason to not select a
> > >    solution providing end-to-end security is give in section 1.2. Is
> > >    there work planned to address this issue, i.e., to complement this
> > >    solution with a solution providing end-to-end security?
> > 
> > [GH] There is another individual draft
> > "draft-hellstrom-avtcore-multi-party-rtt-solutions", intended to
> > document design choices behind the reviewed draft. It discusses the
> > end-to-end security topic among other things but does not solve it. If
> > there are requests for it, that work could be continued to provide
> > specific solutions. But I would like to hear the request first.
> > 
> > Maybe it is more urgent to specify how RFC 8865 "real-time text in
> > WebRTC" can be used in a multi-party setting with end-to-end security.
> > 
> > I would prefer to let the discussion of the topic in the reviewed draft
> > be sufficient fo now.
> > 
> > > 
> > > * Perhaps the recommendation in section 4.2.6 that the mixing method
> > >    for multi-party unaware endpoints is not RECOMMENDED to be used
> > >    should be repeated in the security considerations? It seems there
> > >    are serious limitations, in particular also related to the creation
> > >    of a presentation that can make it impossible to detect masquerade
> > >    attacks. Yes, masquerading is mentioned but from an outside security
> > >    point of view it feels like there was a strong security solution
> > >    that was discarded due to lack of implementation support, there is a
> > >    somewhat OK solution (but not able to provide end-to-end security),
> > >    and there is a pretty ugly solution to accommodate endpoints with no
> > >    support for the other solution. If this is a fair summary, perhaps
> > >    explaining this clearly in the security considerations would be a
> > >    good thing.
> > [GH] Yes, good point. I will compose a proposal.
> > > 
> > > * I am confused about Figures 5 and 6 since the mixed identities of
> > >    the sources are once shown in square brackets and once in
> > >    parenthesis. Are labels like [Alice] or [Bob] not inserted by the
> > >    mixer? If so, why would the format on the endpoint be different? Is
> > >    the idea that endpoints try to parse the mixed text in order to
> > >    render it differently? Or was the idea to show that different mixers
> > >    can use different styles to generate labels, i.e., I should not
> > >    really compare Figure 5 and 6?
> > 
> > [GH] The figures should be possible to compare. And, yes, I have caused
> > confusion by letting the mixer create labels with brackets in figure 5
> > but with parentheses in figure 6. In figure 6 the brackets are inserted
> > by the receiving terminal in a way that has become quite common in RTT
> > implementations, but the parentheses come from the mixer. Alice is the
> > local user. Her text is merged locally and therefore get the label
> > assigned locally.
> > 
> > I will change so that the type of label framing is consistent and insert
> > some words about the labels and their framing.
> > 
> > > 
> > > Editorial comments:
> > > 
> > > * I suggest to cite [T140] when you first refer to it in the
> > >    Introduction:
> > > 
> > >    OLD
> > > 
> > >     A requirement related to multi-party sessions from the presentation
> > >     level standard T.140 for real-time text is: "The display of text
> > > from
> > > 
> > >    NEW
> > > 
> > >     A requirement related to multi-party sessions from the presentation
> > >     level standard T.140 [T140] for real-time text is: "The display
> > > of text from
> > [GH] In the previous review, I got a recommendation to delete many such
> > standard names before the reference, but you are right that it would
> > probably be good with using it once.
> > > * as defined -> are defined and missing full stop
> > > 
> > >    OLD
> > > 
> > >     The terms SDES, CNAME, NAME, SSRC, CSRC, CSRC list, CC, RTCP, RTP-
> > >     mixer, RTP-translator as defined in [RFC3550]
> > > 
> > >    NEW
> > > 
> > >     The terms SDES, CNAME, NAME, SSRC, CSRC, CSRC list, CC, RTCP, RTP-
> > >     mixer, RTP-translator are defined in [RFC3550].
> > [GH] Yes, will do.
> > > 
> > > * Add reference(s) to WebRTC in the terminology section?
> > [GH] Yes, will do.
> > 
> > Thanks,
> > 
> > Gunnar
> > 
> > > 
> > > 
> > > _______________________________________________
> > > Audio/Video Transport Core Maintenance
> > > avt@ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> > 
> -- 
> Gunnar Hellström
> GHAccess
> gunnar.hellstrom@ghaccess.se
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>