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

Paul Kyzivat <> Fri, 06 March 2020 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7FBE3A0A7A for <>; Fri, 6 Mar 2020 12:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.127
X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001, URG_BIZ=0.573, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 876CVIqo8yMr for <>; Fri, 6 Mar 2020 12:57:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BECE63A0A7F for <>; Fri, 6 Mar 2020 12:57:51 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=T2GAkps7u0YCylejlhPZAosuPzELECvNQP3+kNQNTBg7biBu4jE75q9KwGbr8GdRpf1yaVEIfWQMpudxUvFQzmRW1Ig6TVneLwSIkkyWn9NTlpwHCC6IdE+ONttpX8ygy4w89BljHUULAXdmCWPnt0S3a2I47inu+tcTLEyWQPSspmygT3p0Dl1J+l4gj9TggoTppKQxUq518646z1QryoIS0Cr0yejlnJjuTj0MSEhDwTrKvFrRuS7JokjUWvS6fXIKF2Q8oyB8ldYJS29QyZR7tSmZRsfHyTJsprOVCYUovHuJJWB6qQXqh7C3W5/VXOnC7Krmx6kc8Nv/EmyuMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=0YhGh7c8TalFa60tiDTMZFYDcREnaRylecqOlckS8xM=; b=V8R3jgI4HvEXop7lwHlmJpQAiKxfiWUnVZT7k1RZG1JJUvAdGgg5KGX96yioBlsamz9ERiCNQ5lsM06xzohGyb1bR0OQYdenN8wrqwO/Xlpw39kfjgVgNGA11Knd9jgtcHJZKq75C6vUmgd+uk3bA1hSjQTrbRTkBTdNXrhx/yxwe31KvWd76LipyGbCS9nzVpLc16qspatk71sdtXQ7fTSxyElIZo0SAD8dpACkvKMAZ7HpHZtHNvszVpAEzxx3wQ8DHd5FLrH1eZTYjocI8eDEpc5E8BwJQqkyClBE5AGn3zxlsnxN4FlZohXFtV9BwIa4QYLpQek7Uj15sWNrxg==
ARC-Authentication-Results: i=1; 1; spf=pass (sender ip is; dmarc=bestguesspass action=none; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=0YhGh7c8TalFa60tiDTMZFYDcREnaRylecqOlckS8xM=; b=HWAd6DG7Mc/RmT0mqO0PNDCqTamCbYViJ4trJZE+Mg6EZ6u9/Zt4DisFI0UwWhpxOL/lu6Q27lURy8TxxBKA7kG43ns5KT6OZneJ5/g6jo0EGh6x0kPYnJVu2mtuvBEcoxFfdLhm02Vu8apcO8FMA16hNoQybVlXsn+XnBgT4so=
Received: from (2603:10b6:208:23b::14) by (2603:10b6:5:223::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.16; Fri, 6 Mar 2020 20:57:50 +0000
Received: from (2603:10b6:208:23b:cafe::d4) by (2603:10b6:208:23b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15 via Frontend Transport; Fri, 6 Mar 2020 20:57:50 +0000
Authentication-Results: spf=pass (sender IP is;; dkim=none (message not signed) header.d=none;; dmarc=bestguesspass action=none;
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Received: from ( by ( 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 20:57:49 +0000
Received: from Kokiri.localdomain ( []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 026Kvkun020619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Mar 2020 15:57:47 -0500
To: Gunnar Hellström <>,
References: <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Fri, 06 Mar 2020 15:57:46 -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: <>
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:; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(396003)(189003)(199004)(7596002)(786003)(316002)(36906005)(31686004)(26005)(186003)(53546011)(31696002)(86362001)(966005)(478600001)(70586007)(2906002)(70206006)(26826003)(75432002)(336012)(8936002)(246002)(5660300002)(66574012)(356004)(956004)(8676002)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR12MB4282;; FPR:; SPF:Pass; LANG:en;; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 0a0a9435-2209-48c3-94af-08d7c2110782
X-MS-TrafficTypeDiagnostic: DM6PR12MB4282:
X-Microsoft-Antispam-PRVS: <>
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: Dm7s4SCOc1Q5t1mjO3SOuhezEL/rT8fzyQ14i44KgUqPQ4JyPVvS8Lg3VQarj1YK8UUG234kh8CTro5kPPOvlT4T+5/8/BpDF7TnfZ0CsM1UmrKWX+f5kJhVBwSzQ5YNGl8lfGE3HiwpuUdHX/6qQvPsMNhvrhbZ+z8uHQXYWbIjxHGkxZ6myxVxxK+E2J77zTVpPmJ7QF0Jx0GGt1Dq1aeU0G3Fh9t9LyFBPKN2Qch2nazI3qkcy7GKIYHGH6mCjL0puj399thCzGlMmkXbJo/qkWukOLBzz/Ly+YsHSwgV5PNMBN58FVXmyrUyT3CFdDP34mPhLuioTKVRRbPmzPInQi89cPUwrd/Jn6P3IeS+XTf5/m2lm0/Jouu1pBpDPjtdOIB+gjXz652FrL2WFWD/fwZaO+SPLZW/YYdlhcOaGHLsizAFeKDcwbWQd2GrQUu8KSh7jfFo5iWpgzoeffknfGh8gI4UPJnn1nFkLYR53F4I0U8IMyaywthHsxnHraADHneivSyK5zSuKY0CHA==
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2020 20:57:49.1584 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a0a9435-2209-48c3-94af-08d7c2110782
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[]; Helo=[]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4282
Archived-At: <>
Subject: Re: [AVTCORE] Improved RTP-mixer performance for RFC 2198 and RFC 4103 redundancy coding
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Mar 2020 20:57:54 -0000

On 3/6/20 2:07 PM, Gunnar Hellström wrote:
> Paul,
> Den 2020-03-06 kl. 19:04, skrev Paul Kyzivat:
>> 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.
> Right. So I should not bother about the use of the method for other 
> media than real-time text.
>> 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.
> Yes, in the other draft with a wider description about the problem and 
> possible solutions,  ( draft-hellstrom-mmusic-multi-party-rtt ) , there 
> are three different solutions discussed based on traditional RTP-mixing, 
> with two of them having the source identified in the stream, but the one 
> I recommend and made the specific draft for ( 
> draft-hellstrom-avtcore-multi-party-rtt-source ) having the specific use 
> of the CSRC list to indicate the source of each primary and redundancy 
> element.
> In order to know that the parties agree on using that specific use of 
> the CSRC list, I propose a negotiation by a new SDP media attribute 
> "a=rtt-mix" . Only if both parties include that attribute in the 
> real-time text media description they may assume that the CSRC list is 
> used the way the draft specifies.

I agree that this seems to do the job. I'm interested to hear if others 
who are experts in RTP are happy with this mechanism.


>>  I don't think this is a problem as long as the scheme is properly 
>> circumscribed to the situations where is is applicable.
> And that is what I believe I have done in 
> draft-hellstrom-avtcore-multi-party-rtt-source.
> Thanks for the discussion. We need to progress this draft. It is 
> urgently needed as a response to discussions in a group in Canada called 
> TIF-89, but also as response to liaisons between ETSI HF and 3GPP SA4.
> Regards
> Gunnar
>>     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.
>>> 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
>> _______________________________________________
>> Audio/Video Transport Core Maintenance