Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix-08.txt - please review

Gunnar Hellström <> Mon, 12 October 2020 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 988A13A0844 for <>; Mon, 12 Oct 2020 12:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, 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 eLp3Nkp40s3U for <>; Mon, 12 Oct 2020 12:48: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 1B22A3A0843 for <>; Mon, 12 Oct 2020 12:48: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 9E24A20097; Mon, 12 Oct 2020 21:48:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1602532134; bh=uxc01MNeSoDNpbut7BnIJKJp/vDt8nCp2/d9UW93nFo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PofrxbHDWChcO1fTzHIfD2egWGK69bEVrB8/Pldy5w9nPB6L6eCv8Dw+3mRrSZPfe 6XEpC9HpCaIZpjDKJP12G2KTCK/F3ZFux5UDNn6Uu4fRRFY4bspDQ6/ANEuDe6QtCG kUr0/u77sxOwJlqXwHDqTWTsvjFu+auk2GnRMDRM=
To: Paul Kyzivat <>,
References: <> <> <> <> <> <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Mon, 12 Oct 2020 21:48:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
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] draft-ietf-avtcore-multi-party-rtt-mix-08.txt - please review
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: Mon, 12 Oct 2020 19:49:02 -0000

See answer below,

Den 2020-10-12 kl. 17:04, skrev Paul Kyzivat:
> On 10/12/20 10:35 AM, Gunnar Hellström wrote:
>> Den 2020-10-10 kl. 20:50, skrev Paul Kyzivat:
>>> * Section 2.1:
>>> Why was "rtt-mix-rtp-mixer" chosen as the name of the attribute? It 
>>> seems cumbersome and redundant. Wouldn't "rtt-mixer" be sufficient?
>> Yes, a better name may be needed.
>> draft-hellstrom-avtcore-multi-party-rtt-solutions has in sections 6.3 
>> and 6.4 a discussion on the sdp attribute. I agree that the name is 
>> long and maybe confusing. The thought is that the first part, 
>> "rtt-mix", indicates the purpose: to indicate support for a type of 
>> mixer for real-time text. The second part, "rtp-mixer", indicates 
>> what type of mixer that is supported. It is the rtp-mixer style as 
>> described in RFC 3550.
>> There is no plan right now, but it would be possible that later work 
>> specifies another mixer type as an alternative. It could be a 
>> multi-stream mixer using the rtp-translator style from RFC 3550. That 
>> work could then register another attribute, e.g. called 
>> "rtt-mix-rtp-translator". That is not sufficiently likely to motivate 
>> the effort to now create an attribute with values, but the reasoning 
>> motivated a name that indicates both the purpose and the solution.
>> That said, looking at your name proposal "rtt-mixer", I find that it 
>> can meet the criteria. "rtt-" indicates that it is about real-time 
>> text, and "mixer" can be taken to mean the "rtp-mixer" style. It was 
>> also used as the name in early versions of this draft.
>> So, the simple conclusion is: Yes, accepted and done.
> When I looked at "rtt-mix-rtp-mixer" my first thought was as you 
> describe - that there would be several attributes pertaining to rtt 
> mixers. But then I found no others in the draft, and none starting 
> with "rtt-mix" already in the iana registry. So simplifying seemed in 
> order.
> But, if you foresee some possibility of others being defined in the 
> future then it might indeed be worth planning for that now. As you see 
> fit, or perhaps it should be further discussed.

I hope that the current draft is what we need for SIP based services. 
And I hope that the SIP environment will be the only one where 
implementations got spread without multi-party support. The presentation 
level standard T.140 requires multi-party support, but the 
implementations did not fulfill that. That is why we now need the 

The next environment where I expect RTT to spread is in WebRTC, where 
the to-be RFC 8865 specifies how to transport RTT in data channels. In 
that spec the normal way to handle multi-party is by multiple data 
channels. The normal design would be to support additions of data 
channels in a session. A bridge would detect if addition of a channel 
for a new participant is unsuccessful and can take that as an indication 
that multi-party is not supported ( or the maximum number of supported 
participants is reached) and take appropriate action.

So, at the moment, I do not see a need for other multi-party rtt attributes.



>     Thanks,
>     Paul
Gunnar Hellström