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

Gunnar Hellström <> Thu, 11 June 2020 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C6B03A0A40 for <>; Thu, 11 Jun 2020 14:36:39 -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 h6WfDLO1CTo9 for <>; Thu, 11 Jun 2020 14:36: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 66DF93A0A4A for <>; Thu, 11 Jun 2020 14:36:23 -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 400B52015F for <>; Thu, 11 Jun 2020 23:36:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1591911381; bh=hDQCA02mkioYOpTWaOtYO7ZUXv4TWU5fz1J+aZm43vE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rUkIhK5qRsc/NegRrlaByg8XuqKCIzUFncMlmPnddC7Ih0wGFmcV9MH8G8iwOVNYF wulM8DYsdqLnbUvtgbmD6gKecrW/LtKAEhQLfimyZ0eSGwCz1sZOKFNo7gZJNdBIJd JokiZf192T4KEDH4h3GR/XQ7zYkiqU6lMToqmqHU=
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Thu, 11 Jun 2020 23:36:20 +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: <>
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-06.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: Thu, 11 Jun 2020 21:36:40 -0000

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

The sections about media subtype registration and mapping of media 
subtype parameters to sdp are improved.

I have mentioned a question on alternative codings and I would like to 
have a discussion on these alternatives.
1) replace the PT in the data headers with a sequence number per source 
for improved handling of loss.
2)Use RFC 5109 general FEC format with RFC 2198 to get a format 
completely based on existing RFCs.

Assuming that we stay with the current format, I have no more issues, 
and would appreciate comments to progress the draft.


Den 2020-06-11 kl. 23:18, 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-06.txt
> 	Pages           : 40
> 	Date            : 2020-06-11
> 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:
> 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