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

Gunnar Hellström <> Sun, 12 July 2020 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF2913A0839 for <>; Sun, 12 Jul 2020 14:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XZ4eFrB9PtFS for <>; Sun, 12 Jul 2020 14:03:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 216423A0832 for <>; Sun, 12 Jul 2020 14:03:56 -0700 (PDT)
Received: from [] ( []) (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: by (Postfix) with ESMTPSA id AD38F2039E for <>; Sun, 12 Jul 2020 23:03:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1594587834; bh=T1OGbPunQDDe0Q7j8xIoIyqeXhyBj9WbUuWGSXoxk28=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aiZQxAbIW4cdxIckkIAUkcp/QNt+m3zPHerRmvGk4243kM6SnqEWpNHUz2DJ0N0yt MxXGaTpMKXo3RLlrbVu1QD6sI49A1SsIPLLz5k+SdvDbEd8GIkpog35xa1nLTDibIv hz/RNgjANiiUwdyZGlnfErglizQA5NOwZYV1nvbg=
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Sun, 12 Jul 2020 23:03:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-07.txt
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: Sun, 12 Jul 2020 21:04:02 -0000

A new version of the multi-party real-time text draft is available.

I have added one multi-party method using the existing "text/red" packet 
format from RFC 4103 and transmission interval shortened to 100 ms when 
there is text from more than one participant to send. It is negotiated 
by an sdp media attribute.

This was because I realized that it may be more important to have a 
method that is rapid to implement as an upgrade on existing 
implementations than to have best performance and technical elegance.

I have had 2 and 3 and 5 simultaneously typing participants in the 
requirement statements, but now I realize that 5 simultaneously typing 
participants must be an extremely rare case that is not needed as a 
requirement for good performance, at least not for emergency service 
calls, relay service calls and small or well managed meetings.

Looking forward to discussions e.g. if all three currently specified 
methods shall be kept in the draft or some be dropped.



Den 2020-07-12 kl. 16:34, skrev
> 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-07.txt
> 	Pages           : 53
> 	Date            : 2020-07-12
> 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.
>     Enhancements for RFC 4103 real-time text mixing is provided in this
>     document, suitable for a centralized conference model that enables
>     source identification and source switching.  The intended use is for
>     real-time text mixers and multi-party-aware participant endpoints.
>     Two mechanisms are provided.  The mechanisms builds on use of the
>     CSRC list in the RTP packet for source identification.  One method
>     makes use of the same "text/red" format as for two-party sessions,
>     while the other makes use of an extended packet format "text/rex" for
>     more efficient transmission.
>     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 for one method is by use of a media attribute a=rtt-
>     mix-rtp-mixer.  The other method 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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> Audio/Video Transport Core Maintenance

Gunnar Hellström