IETF Logo Mail Archive

Re: [AVTCORE] Improved RTP-mixer performance for RFC 2198 and RFC 4103 redundancy coding

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 06 March 2020 18:04 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 5423A3A0C87 for <avt@ietfa.amsl.com>; Fri, 6 Mar 2020 10:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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=alum.mit.edu
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 iJsBCPodEnvI for <avt@ietfa.amsl.com>; Fri, 6 Mar 2020 10:04:33 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2042.outbound.protection.outlook.com [40.107.244.42]) (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 C0BFF3A0C8C for <avt@ietf.org>; Fri, 6 Mar 2020 10:04:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BAJqmAUDHGCOPpsxfk92+vFyCiy8phPjupVDsKpln3L4c2tjsR/z5IxhEEbhJTX4RqGzLoc3IgCymCnJ/tUwisoTAsFl3jlNyHEx8pOXEBYk40zLIuxc3MIFadnMZPefJ1oGrO7iTr+cKg58dYU8/bGxOco+69riVvgsnOFWHuVBu5sBW7+CU+67QJ6BSM7dCp40hEU5G5sLdOVyheOM9yVsSP/LddeqjN5exfAWGbIx0yPfJ0bQu4LfWkc2fVzHkajqcYzwysn4fqqtHQC/Kb7PB363PSNbpS+Wqb5HMS6aVBrme9a0IwdJZaNfTAjdwi0nl5HiY3oc6ovfGj0tRw==
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=iZF7OZcPFuQ8aiv7DJDIQr0RYQ7rYwRLe0PeptMZBt8=; b=E2Pdgb/vTBpRl8rBMLK3dMWHIJ35+duwSt1TB85nJLLpBpfv18GDaBZoWciErSKWpgkh0IrUA0kJIjCLzT+aew02vYgVpbskpdRGb/j/FkcY0jlV+EghmGQKJQqzra9HF9t+uTfJdomjQ0dukay/QQfEeyhZBGJ4muiSzxS9nBnZOO2FoIPVlEh3OAHpey9WI6704eYhNm1og6ot2ST3zo/uhS0iCgQgIxpHhE0fbEriaJ/6DNgRlZ4nokik4lVsFE5ST2tF1eKfqfwZ3rqGyTT/Cq3z1c7OI1DaWSSaGALD+9OOjqF3WEIPyQY/SiXFu6HsQCffzfCQ1jG8Glr+0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=iZF7OZcPFuQ8aiv7DJDIQr0RYQ7rYwRLe0PeptMZBt8=; b=dQkG6hL471mGAoK1UHZEnab+J88+pq/BEAeVqePkrP/WRdLh/473Rjx31LK16HXi1T2IONskmFyUiptyllL7StiVSMUU84BcVk/WzgAhO42fGp4oMFEQaulqCQDpGiSZWVYvqT5ErWr/jkVEN4yUfVBNDnldBdi9OKNSHk0vkt4=
Received: from BL0PR02CA0080.namprd02.prod.outlook.com (2603:10b6:208:51::21) by CY4PR12MB1656.namprd12.prod.outlook.com (2603:10b6:910:d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.18; Fri, 6 Mar 2020 18:04:32 +0000
Received: from BL2NAM02FT053.eop-nam02.prod.protection.outlook.com (2603:10b6:208:51:cafe::74) by BL0PR02CA0080.outlook.office365.com (2603:10b6:208:51::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11 via Frontend Transport; Fri, 6 Mar 2020 18:04:32 +0000
Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT053.mail.protection.outlook.com (10.152.76.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11 via Frontend Transport; Fri, 6 Mar 2020 18:04:32 +0000
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 026I4UX3003049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <avt@ietf.org>; Fri, 6 Mar 2020 13:04:31 -0500
To: avt@ietf.org
References: <ce102d26-5e07-c720-9a0f-e3ea3d908a90@omnitor.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <fec0ff39-76a7-a518-d3a2-be94c98dacfc@alum.mit.edu>
Date: Fri, 06 Mar 2020 13:04:30 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <ce102d26-5e07-c720-9a0f-e3ea3d908a90@omnitor.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(136003)(199004)(189003)(70206006)(6916009)(478600001)(2906002)(53546011)(956004)(75432002)(8936002)(26826003)(70586007)(7596002)(966005)(2616005)(246002)(336012)(31686004)(31696002)(8676002)(786003)(186003)(86362001)(66574012)(5660300002)(316002)(36906005)(356004)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR12MB1656; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d97e54fd-9aa2-45dc-b280-08d7c1f8d252
X-MS-TrafficTypeDiagnostic: CY4PR12MB1656:
X-Microsoft-Antispam-PRVS: <CY4PR12MB16560C40F834318C969ED0CFF9E30@CY4PR12MB1656.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0334223192
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: D0Rgjjo7xi4jOg/d9hrcjcesZRp/GedBRWJsV2jQiFYUTKvOMg4SaIX9YSNT/MOBroTES5+iMx/s5FyZIDNvLYyDRuhYz5+TwHlVEz3Zoaq8F2SzL6nUsdf5ymk3iP45AREUmOwULZv0NpcMt1W6g0kUdg5UIuzaozkbm/CFwGpmRV20JjxHywlklBMKwhWp0rVMN2iGehj3DCJVV3T2bHrIR/25cKwOB6kFyHkrVqTN87nAMmfQZmfPuqduSG8A5DhsPU275yDaB7EP1gJwvm+z9G0fmJpJdOsvv+x0YBjpKLIGL0rR4f48Ajlm9F354AKOskKdqw7qniwCWB8XDWOaY03tJnyWtGE/b9tjIMtYs2Xr0NM1LDDgRorQbEQ4wapkiGcslc8JuM0ZNRQVOsXX7tVjdlYxoNbd296jbIivZaqm/Lxa2QVANKAaCchzGItmwNcQvg2LZprqxZno7LbSEerCxXJ2VKgwEjshaXNACj/B4WAZh+QqQuFa6RLXviqEc6KEm2BTHZhHOhAr4g==
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2020 18:04:32.0319 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d97e54fd-9aa2-45dc-b280-08d7c1f8d252
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1656
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/B93iP-G9URdgmQ0Qvpsq40tW2qI>
Subject: Re: [AVTCORE] Improved RTP-mixer performance for RFC 2198 and RFC 4103 redundancy coding
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, 06 Mar 2020 18:04:43 -0000

Gunnar,

I'm not deeply knowledgeable regarding RTP, but I think I understand 
what you are proposing. It seems like it should work in typical cases 
for RTT. But I think it doesn't work properly for other media (notably 
voice) and might not work for some unusual cases of RTT.

The issue is that you are repurposing CSRC. In the case of audio mixing, 
multiple sources are literally mixed to form a single stream of audio, 
and the CSRCs are used to show which ones have been mixed. In that 
situation your scheme doesn't seem to work.

Similarly, ISTM that it is at least *possible* to build a RTT mixer that 
does something similar, mixing multiple sources into a single text 
stream. If this was done then again your scheme for coding redundancy 
wouldn't work right.

I don't think this is a problem as long as the scheme is properly 
circumscribed to the situations where is is applicable.

	Thanks,
	Paul

On 3/6/20 8:12 AM, Gunnar Hellström wrote:
> Hi,
> 
> I have submitted a proposal for improved performance for multi-party 
> mixers dealing with RFC 4103 real-time text.
> 
> https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-source/ 
> 
> 
> It just came to my mind that the same solution can be used for any media 
> transport using the RFC 2198 redundancy coding.
> 
> The problems with the redundancy packetization is that there is no place 
> for source for each redundant part in the reduncancy header. Therefore 
> the traditional assumption is that all payload parts of a packet has the 
> same source. That makes source switching in a mixer inefficient.
> 
> The solution is to let the members of the CSRC list in the RTP packet 
> exactly correspond to the sources of the different parts of the payload 
> ( primary, 1st redundant etc).
> 
> I want to progress the draft for the RFC 4103 use, but am interested to 
> support any discussion on the more general use of the solution.
> 
> Regards
> Gunnar
>

v2.23.0 | Report a Bug | By Email