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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Mon, 12 October 2020 19:49 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988A13A0844 for <avt@ietfa.amsl.com>; Mon, 12 Oct 2020 12:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLp3Nkp40s3U for <avt@ietfa.amsl.com>; Mon, 12 Oct 2020 12:48:58 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B22A3A0843 for <avt@ietf.org>; Mon, 12 Oct 2020 12:48:56 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-134.cust.a3fiber.se [77.53.37.134]) (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: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 9E24A20097; Mon, 12 Oct 2020 21:48:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; 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 <pkyzivat@alum.mit.edu>, avt@ietf.org
References: <159725784100.26501.7801603611291404620@ietfa.amsl.com> <cea92434-e74b-2fba-dc29-f1b29f5e22d9@ghaccess.se> <7c6ab084-95b6-1c07-fa78-c280a7a0ca6b@ghaccess.se> <7f90dd6d-8a66-bc7c-0865-d1ce566c2306@alum.mit.edu> <62ab2139-6a5b-7116-a54a-abbb6ea95b69@ghaccess.se> <9ea0fc69-8443-2714-b390-19ddf563cf18@alum.mit.edu>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <aa0d1b51-0c1d-ac37-488d-733329e3ab2d@ghaccess.se>
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: <9ea0fc69-8443-2714-b390-19ddf563cf18@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/4twsszSicP3KpqWoonG7KR-OtVA>
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix-08.txt - please review
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=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 
attribute.

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,

Gunnar

>
>     Thanks,
>     Paul
>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se