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

Gunnar Hellström <> Wed, 20 May 2020 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E40A73A045B for <>; Wed, 20 May 2020 14:47:41 -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 tTUIZOWbfxYA for <>; Wed, 20 May 2020 14:47:38 -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 B9CA33A0440 for <>; Wed, 20 May 2020 14:47:36 -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 C1ABC20685 for <>; Wed, 20 May 2020 23:47:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1590011254; bh=rvppfYDLiwwfo322Av0F7nW1aLfM/naqQ34a1VHxqhk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=neLUDQ/8Ysw0LomJozEQkl/GAlbn7MmRMyFgAhEaI0HR5k8FbigDg0AHi2XFika3P drEHFy4YD2B1NvvWp81jAXKvCV6FAykKjaPIf4z0m7dKG1iZ6JqD7tPMQh7afHrRvn ivZlWWqsJSK0EkhmNBUMNu9SB1co9ne/klXG4UKw=
To: "" <>
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Wed, 20 May 2020 23:47:31 +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: <>
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-02.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, 20 May 2020 21:47:42 -0000

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

It has the following modifications:

1. The section for security in session and media is extended and made 
easier to find.

2. The packet format description is much more detailed

3. The gateway considerations to/from WebRTC is extended and made easier 
to find.

On the issues list were also:

a) move the mixing for multi-party unaware endpoints to an appendix. I 
am not convinced that that is good, so this issue is dropped.

b) Should there be a limit on how many simultaneous text sources are 
allowed. And if so, what to do. This issue needs discussion before 
action. Maybe not needed. Or the number can be fixed at what one packet 
can carry - 16.



Den 2020-05-20 kl. 23:36, 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-02.txt
> 	Pages           : 34
> 	Date            : 2020-05-20
> 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:
> 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