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

Gunnar Hellström <> Fri, 06 March 2020 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0E7C3A07C3 for <>; Fri, 6 Mar 2020 11:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.126
X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, 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 0NsYEDta6gqr for <>; Fri, 6 Mar 2020 11:07:51 -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 39B8F3A07C0 for <>; Fri, 6 Mar 2020 11:07:50 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=lEePcFL/LWDB5pYxhWRMgidd6lgmDunKsgSRoWg/jXZ8Y4QOt+r+oOtSaSiyqNhucMJ9q1EQfTCQuFLZV6ZHCHR09V4g+NvzvXhD4pMG68w+aGxY2WJp3LPKfClkJlCpjJ1RqitYCxILcao+cniiAamFlf5XBiOZj3dGFnLZ+FNpkXWnyevBLY32PwOU8QlLR0j6d2W9QJoh9P2SulZv7fBB4grkQqnlNpXvz31yIMA9h6swknSxut6lmQ2p7BcJ9x21pMXfqXXMEIRm5qcAs7bQf9pv0as4MOhVIlOjNUNfA1vge+8hM2f/fnCA+gYx7SbA/cT71fsWy1lGPGJkJg==
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=DdYq6PTF2pRkITp+J9m3hKPtKp182ZHZwNwzJVW5Je0=; b=R+fQ7YmVV0FQLmIrZQ6uPE0XZqC1RlCnrJErI3rZxuQN0g5fZgm6mIec5vAPORfq4678cSvCh1agDx6WMQMJZO0pDQTb/+S7L3o6PXoCzFTqz0+unZhsbBowEMA49oGN8ii42LwRAGB7tR9k3HSamm2DXwK8CU76MP7uO6xMsuEIqWwzu9GCK3/pJmCwBNO5D0Fll+ItdAyWOJIYDmvhDFSP8c20w75HMQ0z5SwkoQmdSv/yGE1smNPw8DjczipnG4DZ2nemltWlkfEq/ZsY7o4pEXhy7NAE7E3BlWsuZ4ikf4b1milXOoeTSFBv4xgTDD9/PWors/ABqmkAhQmIWQ==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=DdYq6PTF2pRkITp+J9m3hKPtKp182ZHZwNwzJVW5Je0=; b=LXWmZTVpItFuA1RRWMWJYBhKw97VCmtVEs6yaeoXtwmIvd2hIRQfFAv24TtY7giOx8JS7hZQcT4lVEzuHuoMbX2FKPuGMvAUDDCX4X55uhTNkL5YoET960MGy4T1J8IMzdxHCm9gy+dcG9ehL8mpnHTlBP+1eidhHaWx8BnVjMY=
Authentication-Results: spf=none (sender IP is );
Received: from AM0P193MB0721.EURP193.PROD.OUTLOOK.COM ( by AM0P193MB0257.EURP193.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 6 Mar 2020 19:07:47 +0000
Received: from AM0P193MB0721.EURP193.PROD.OUTLOOK.COM ([fe80::d850:e7bb:c87c:3a3e]) by AM0P193MB0721.EURP193.PROD.OUTLOOK.COM ([fe80::d850:e7bb:c87c:3a3e%7]) with mapi id 15.20.2793.013; Fri, 6 Mar 2020 19:07:47 +0000
To: Paul Kyzivat <>,
References: <> <>
From: Gunnar Hellström <>
Message-ID: <>
Date: Fri, 06 Mar 2020 20:07:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: sv
X-ClientProxiedBy: FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) To AM0P193MB0721.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:163::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [] ( by FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) 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 19:07:46 +0000
X-Originating-IP: []
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 022c3235-32ce-4a8e-6fad-08d7c201a81a
X-MS-TrafficTypeDiagnostic: AM0P193MB0257:
X-Microsoft-Antispam-PRVS: <AM0P193MB02573BB22E73A41CF10D60B4FBE30@AM0P193MB0257.EURP193.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0334223192
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(366004)(396003)(39830400003)(189003)(199004)(6486002)(8936002)(36756003)(6666004)(86362001)(31686004)(31696002)(81156014)(966005)(8676002)(508600001)(81166006)(66946007)(66556008)(53546011)(16526019)(66574012)(26005)(16576012)(316002)(66476007)(2616005)(5660300002)(956004)(2906002)(52116002)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0P193MB0257; H:AM0P193MB0721.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
Received-SPF: None ( does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: gmwxeunZipy76ooU8VGLpUpJhhqGrxSTrasuBbAxBAlO2pD3OApTsRXXcEutQomaYGVgbbqkIoHb3o68e2ntJFPVOyLze+1ircsZFdfbXHjr39glGeyJ8tySOAuMgQrBamW6A2AHG15QVOt0S361igSms51l3nx/XE0tqr9uce3YnvNCVBIBqKl06tpBBDsPUGVcZ9iTRCw1kz1lB46hMAE0F+51xI1uhRL4kp8OIy/JVB55ZSQMFiBj6pKjSz9D9takC7kpvHpK7XUG+ngwj4W74eaHJWM7/hazj19imHGpGlXC4ED9AI/JamO3x0vdBgnIlSMYkKsnj9uuL3Jkq+r1SrYhqMAsjbURqytMg4WmfP16F6aU/A3MnCfg2i3CvyaYljvZ3OsTNtTUWEUmkZLkJkpYQcRzIYBUxDr1Ub+hBKkp5Az7WEKEr5gSUsYcWBk3x/5Ezd7rIPpYQYVunrLRJeR7SozR8QGYnr/f/zNc0IgZZcn9NUb13fHUqrWRyalbIOcxwSG3sAgP3wbSbQ==
X-MS-Exchange-AntiSpam-MessageData: +52WIGGAII2MB4ZuG2px7Ie1jvl/yFxT1FpHpE0nktaSjxXpCxjoQt2+4XeXVzRxSUJTmdxEVjtuiSH7FYqzGm9mZorkh6c05IaYiM3MNstJifRuBAsOpWwxDVhFNf7TDvrpJKrKYNAY+xj5v4oDlQ==
X-MS-Exchange-CrossTenant-Network-Message-Id: 022c3235-32ce-4a8e-6fad-08d7c201a81a
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2020 19:07:46.8927 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: nD5KcnYzBcfG+/2ummqmjZNR/NIKVkJ1slyC472DWVPVaDeEYqWGbnJzaLDcdylOOupSbKWjbcO/5ANAh4+H7HBIo74q7T4KcmKkx+YhH0w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P193MB0257
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 19:07:55 -0000


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 

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 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 

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.



>     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


+ + + + + + + + + + + + + +

Gunnar Hellström
+46 708 204 288