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

Gunnar Hellström <> Wed, 12 August 2020 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1628D3A07DD for <>; Wed, 12 Aug 2020 11:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, 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 f-SY-jmmykZK for <>; Wed, 12 Aug 2020 11:52:34 -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 0557E3A07D4 for <>; Wed, 12 Aug 2020 11:52:33 -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 669D22021C for <>; Wed, 12 Aug 2020 20:52:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1597258351; bh=JCYOlBEifJuoqzBFEOirpKAdPZLokplqKK1wDXKMyyk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Nx76d87egwj9cTKpHkkS6gpyRKhPl9v/VTPAWhkfXp0OPTBTKZaCyNvoK0wEerllv C1d0f8/JO+wkWqlx1LeG3ilToV2ZlqhBZv28kdyzylUo7s09IG5PEo8wmefDwYyEyp /fsBdS9k9N5v02q1NZinqFzAYl9wTRZx/QuQ8xp0=
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Wed, 12 Aug 2020 20:52:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.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-08.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: Wed, 12 Aug 2020 18:52:37 -0000

A new version of the "RTP-mixer formatting of multi-party Real-time 
text" is available.

This version moves forward with only two methods for multi-party mixing 
of RTP transported real-time text.

The major one is RFC 4103 with transmission interval of 100 ms when 
there is text from more than one source to transmit, and source 
indicated in the CSRC list.

The second one is the fallback for the situation that the endpoint does 
not have multi-party capability.



Den 2020-08-12 kl. 20:44, 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-08.txt
> 	Pages           : 36
> 	Date            : 2020-08-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 characteristics 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.
>     The specified mechanism build on the standard use of the CSRC list in
>     the RTP packet for source identification.  The method makes use of
>     the same "text/red" format as for two-party sessions.
>     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 use of a media attribute "rtt-mix-rtp-
>     mixer".
>     The document updates RFC 4103[RFC4103]
>     A specifications of 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