Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-04.txt

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Mon, 01 June 2020 20:57 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
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 B40003A0DD3 for <avt@ietfa.amsl.com>; Mon, 1 Jun 2020 13:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBp68d6VnKEG for <avt@ietfa.amsl.com>; Mon, 1 Jun 2020 13:57:48 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BCD3A0DD1 for <avt@ietf.org>; Mon, 1 Jun 2020 13:57:48 -0700 (PDT)
Received: from [192.168.2.136] (h79-138-72-251.cust.a3fiber.se [79.138.72.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 5066220298 for <avt@ietf.org>; Mon, 1 Jun 2020 22:57:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1591045065; bh=rmLhdZJg6mqOiIw65pP/kMQfwNZCN+7l/BlDZ0yDdsI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DbGGgmPYtW+YHthH0NnMkQ/laarjRLOk/24PFzv+BF4DEqFIKMwL3+ezNu1vrxnwW awPQQ00MvNqJRfxGzyPJRIvNTaLqkc8fImcamIflTqIcgVsAA90dygRwSEpgnhl12I qWRxF6EwTzYFr6fbvI1fA+QXqW1y0Jws99XaRMgI=
To: avt@ietf.org
References: <159102621628.32235.8052992310988575727@ietfa.amsl.com> <5ad925ca-9df7-bd94-6335-2a077a6d671f@ghaccess.se>
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <e6717090-3eff-21f0-8b8f-75f6b1f5eb5b@ghaccess.se>
Date: Mon, 01 Jun 2020 22:57:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <5ad925ca-9df7-bd94-6335-2a077a6d671f@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/jDfg6zIxF07OfqxDc9LDo6c-92I>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-04.txt
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, 01 Jun 2020 20:57:53 -0000

I want to propose one more change in the "text/rex" packet format, that 
is not included in the latest draft -04.

The format in the draft is not specified to be based on RFC 2198 as is 
the case with RFC 4103. We always have t140 as the data format in the 
primary and redundant data fields. So there is no need to have that 
configurable by the fmtp sdp attribute. It can be specified in the 
text/rex format.

The 7 bits PT field in the data header that is now specified to contain 
the PT number of the t140 format can instead be used as a sequence 
number per source. That would make it possible to cover a functional 
limitation in the current specification: If there is more loss of 
packets than can be covered by the redundancy, it is not possible to 
deduct which sources were struck by the loss.  The loss indication 
cannot be made specific to any stream from a source, but can only be 
made general.

By introducing the sequence number per source, it gets possible to check 
which source was struck. The receiver needs to have a status with memory 
for the latest received sequence number per source. At each packet 
reception, the received source sequence numbers SHOULD be checked for 
gaps, and if a gap is detected, it can be found which sources were 
struck, and marks for loss can be inserted in the correct streams.

It is a win-win situation. The SDP gets less complex, the loss can be 
decided per source and the packet format gets less complex.

Can there be any situations when this does not work?  Or any other 
reasons for why not accept this proposed change?

Regards

Gunnar

Den 2020-06-01 kl. 17:53, skrev Gunnar Hellström:
> A new version of the multi-party mixing draft for RTT is available.
>
> The changes are mainly in cleaning up logic and language and make the 
> structure of the document more clear.
>
> Regards
>
> Gunnar
>
> Den 2020-06-01 kl. 17:43, 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-04.txt
>>     Pages           : 38
>>     Date            : 2020-06-01
>>
>> 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 the
>>     present specification, 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-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix-04 
>>
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-04 
>>
>>
>>
>> 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
GHAccess
gunnar.hellstrom@ghaccess.se