[AVTCORE] Alternative coding for draft-ietf-avtcore-multi-party-rtt-mix

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Mon, 08 June 2020 21:44 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 216CF3A07CB for <avt@ietfa.amsl.com>; Mon, 8 Jun 2020 14:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VU_GkEEHJG1N for <avt@ietfa.amsl.com>; Mon, 8 Jun 2020 14:44:41 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3823A079C for <avt@ietf.org>; Mon, 8 Jun 2020 14:44:40 -0700 (PDT)
Received: from [] (h79-138-72-251.cust.a3fiber.se []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id D4F1720298 for <avt@ietf.org>; Mon, 8 Jun 2020 23:44:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1591652677; bh=zYWWFKP7Me9w6CUWkbxuNXgUnerXjzB3CRjKxIny5ag=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Sdar6mVy7+h+XnYhewa8+aqZtL5THgdjylo7HmWVPegX/7rzHGAWjAh1W+Pm3zGa/ eVNbE6ZkV5h3y7wC2pkcT2aio4pwDS+Sn9O88yi5/iQyvFBeFJ9j8kyyUWFKojNITS 6vVixUuEU4FhbuxmU4eur9MkGIr5F6Jc0mqABgyw=
To: avt@ietf.org
References: <159126376312.25952.11093292455075419067@ietfa.amsl.com> <8cbdaa6a-bdab-17f7-60ba-b9944ce65eef@ghaccess.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <e55c67e7-3919-060f-dfac-4f4afbcaa655@ghaccess.se>
Date: Mon, 8 Jun 2020 23:44:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <8cbdaa6a-bdab-17f7-60ba-b9944ce65eef@ghaccess.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/VrNDTtLXFnS-9JryCxB5X1h3kN4>
Subject: [AVTCORE] Alternative coding for draft-ietf-avtcore-multi-party-rtt-mix
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: Mon, 08 Jun 2020 21:44:45 -0000

The problem we have with RFC 4103 for multi-party use is that the 
redundancy format text/red cannot switch CSRC rapidly.

I have found an already existing RFC that allows redundancy coding and 
yet change CSRC for every packet. That is RFC 5109 Generic FEC.

It also allows the redundancy to be sent at a suitable time after the 
original, so text loss by bursty packet loss can be kept low.

We have said that the requirement is to enable a mix of five 
simultaneous text sources with an introduced latency less than 500 ms.

That is what can be achieved with the text/t140 format from RFC 4103 
transmitted with up to 10 packets per second, packetized with 
text/ulpfec from RFC 5109. text/ulpfec allows transmission with 
redundancy according to RFC 2198, the same that RFC 4103 uses for 
redundancy, with the difference that text/ulpfec includes parts of the 
RTP header and CSRC in the redundancy data, so that the RTP packets can 
be completely recovered.

RFC 5109 has many options, but can be used for protecting all data with 
two retransmissions, e.g. sent about 600 and 1200 ms after the initial 
transmission. ( or other suitable times to avoid most packet loss burtst 
but not cause too long delays at loss)

There is still a fact that when there is unrecoverable loss of text, it 
is not possible to tell from which source it was lost.  I was drafting a 
proposal to overcome this problem with changes in the format specified 
in the current draft, when I realized that RFC 5109 could be used - but 
not solve just that problem. Still, I think it is a great benefit to be 
able to use already standardized formats.

  Introducing FEC coding is already allowable in RFC 4103.




Den 2020-06-04 kl. 11:49, skrev Gunnar Hellström:
> A new version of the multi-party rtt mix draft is available with 
> adjustments in terminoogy and editorial improvements.
> Regards
> Gunnar
> Den 2020-06-04 kl. 11:42, skrev internet-drafts@ietf.org:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Audio/Video Transport Core 
>> Maintenance WG of the IETF.
>>          Title           : RTP-mixer formatting of multi-party 
>> Real-time text
>>          Author          : Gunnar Hellstrom
>>     Filename        : draft-ietf-avtcore-multi-party-rtt-mix-05.txt
>>     Pages           : 38
>>     Date            : 2020-06-04
>> Abstract:
>>     Real-time text mixers for multi-party sessions need to identify the
>>     source of each transmitted group of text so that the text can be
>>     presented by endpoints in suitable grouping with other text from the
>>     same source.
>>     Regional regulatory requirements specify provision of real-time text
>>     in multi-party calls.  RFC 4103 mixer implementations can use
>>     traditional RTP functions for source identification, but the mixer
>>     source switching performance is limited when using the default
>>     transmission with redundancy.
>>     An enhancement for RFC 4103 real-time text mixing is provided in 
>> this
>>     document, suitable for a centralized conference model that enables
>>     source identification and efficient source switching.  The intended
>>     use is for real-time text mixers and multi-party-aware participant
>>     endpoints.  The mechanism builds on use of the CSRC list in the RTP
>>     packet and an extended packet format "text/rex".
>>     A capability exchange is specified so that it can be verified that a
>>     participant can handle the multi-party coded real-time text stream.
>>     The capability is indicated by the media subtype "text/rex".
>>     The document updates RFC 4102[RFC4102] and RFC 4103[RFC4103]
>>     A brief description about how a mixer can format text for the case
>>     when the endpoint is not multi-party aware is also provided.
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-05
>> https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix-05 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-05 
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
Gunnar Hellström