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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Thu, 14 May 2020 14:39 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 86A753A0AC5 for <avt@ietfa.amsl.com>; Thu, 14 May 2020 07:39:30 -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 9x-ZObDUaTkx for <avt@ietfa.amsl.com>; Thu, 14 May 2020 07:39:27 -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 7E3243A0AC8 for <avt@ietf.org>; Thu, 14 May 2020 07:39:14 -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) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id B6D6B20218 for <avt@ietf.org>; Thu, 14 May 2020 16:39:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589467152; bh=sfUei9O9oXnI5V7sqR1ECOCvG73cl6m0gN1n7GOX7/I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=oMDf8HmJpVqpnFBjBwOoK3Nswhn1Nd0hl8RheSAV9+38CAgf0JVs/ekvvfi6KgoOR kIXwI5avnvNzVBc6aYxjiMrv/g6talGZOliEGeFfUGyapqy7gLgcGiQ3Y7N8VIlHXh ctVlsS7RcWYVJyg08z1EipvjCvo7PXqtF4HxppsE=
To: avt@ietf.org
References: <158946609026.18079.16754240649572667779@ietfa.amsl.com>
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <7cbf3994-6bfb-1c75-3b12-fa8ff4beba6a@ghaccess.se>
Date: Thu, 14 May 2020 16:39:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <158946609026.18079.16754240649572667779@ietfa.amsl.com>
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/oE7LYhEpvEOh_eQqPm3mfW3mI8c>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-01.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: Thu, 14 May 2020 14:39:32 -0000

A new version of the multi-party-rtt-mix  draft is available.

This is a brief summary of what has been done, related to the earlier 
announced issues:

New text is started by --


1. Consider rapidly if there is any more reliable transport that is 
feasible to move to.
(e.g. Comedia RFC 4145 and RFC 4572, or the recently approved WebRTC 
t140 data channel draft-ietf-mmusic-t140-data-channel-usage, or use of 
SAVPF with NAK and retransmission RFC 4588)

The answer on issue 1 influences many of the following issues, currently 
written with the assumption that we continue with RTP transport.

---I consider now only two solutions realistic to continue with. That is 
the currently specified RTP-mixer based version and the WebRTC version. 
The draft continues with the RTP-mixer version and includes brief info 
on gatewaying to WebRTC.


2. Add sdp examples

---Done for non-encrypted use. OSRTP use should be added.


3. Add SRTP hints and OSRTP preference (RFC 8643).
--Very briefly mentioned in the SDP section. Need extension.

4. Add a brief motivation for the solution and why not rtp-translator is 
used. (or review rapidly the decision to go with the RTP-mixer model, 
three commenters have wondered why we do not use the rtp-translator model.)
--Done in the introduction.

5 We have indications  that the format with the strict use of the CSRC 
list to indicate sources also of the redundant parts might not be called 
text/red. A new format (e.g. text/rex) may then need to be registered, 
and sdp negotiation made between text/red and text/rex for 
interoperability reasons. Shall we accept that and move on with text/rex 
and the CSRC list that gives switching performance for 5 participants 
within 500 milliseconds delay (as compared to 3 participants within 600 
milliseconds for the text/red format.

--Done. A format "text/rex" specified that can carry text from 16 
participants in each packet.
   The format is as text/red repeated up to 16 times in the packet.
    The earlier proposed attribute a=rtt-mix is not needed anymore and 
is deleted.

6. If we agree to change format to text/rex, then also consider to move 
to the format proposed by James Hamlin, with primary text from up to 16 
participants in each packet. Provides good switching performance 
increase to 16 simultaneous sources.
--Done

7. Describe limitations in the multi-party-unaware case that 
unrecoverable packet loss can hit the label at source switch and 
therefore give the impression that text is coming from another source 
than it is.
--Done. Maybe the main text of the multi-party unaware mixing should 
move to an appendix to be better isolated from the main direction.

8. Make explicit wording about what is to be regarded as update to RFC 
4103. It is important from regulatory points of view in Europe and USA 
that the result can be seen as an update of RFC 4103.
--Done

9. Include brief gateway considerations to WebRTC t140 data channel.
--Briefly done, more needed.

Regards

Gunnar

Den 2020-05-14 kl. 16:21, 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-01.txt
> 	Pages           : 31
> 	Date            : 2020-05-14
>
> 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-01
> https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-01
>
>
> 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