Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Wed, 22 April 2020 20:01 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 753483A07B5 for <avt@ietfa.amsl.com>; Wed, 22 Apr 2020 13:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 aiOBdVaZDePz for <avt@ietfa.amsl.com>; Wed, 22 Apr 2020 13:01:34 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224333A07AD for <avtcore@ietf.org>; Wed, 22 Apr 2020 13:01:33 -0700 (PDT)
Received: from [192.168.2.136] (h77-53-230-67.cust.a3fiber.se [77.53.230.67]) (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 0F30520093; Wed, 22 Apr 2020 22:01:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587585691; bh=hIDk0SAc+R54G+6I+wQGYcOWou1S3O8VJwpfMmqONx0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aRIIT2lgB/CplFg66YZHPYrU56+zg1MAK6vhduib+wBUrVgj6NnXT55BrUmdjfGW7 vnhHYUbJzKNwmgleg8VOM8GlwjEujtV+LJoU5dYFmamkJmVjC1ydJtL88uZUH4OXsx Sxf7BDNnOt3Ft6t8mW2MeA7lalJMigko3PXiM3YM=
To: Brian Rosen <br@brianrosen.net>
Cc: "avtcore@ietf.org" <avtcore@ietf.org>
References: <e2d44956-2cd7-b43a-e847-fbeed5b0ef62@ghaccess.se> <197C0C31-FDCB-46A8-9642-5F4D98F63F75@brianrosen.net>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <45d55958-fb0f-6298-807b-ce375b60d60f@ghaccess.se>
Date: Wed, 22 Apr 2020 22:01:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <197C0C31-FDCB-46A8-9642-5F4D98F63F75@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------71432BD9D44A40CFE5F76DBF"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/cr5CGHkV7O9bvJBTG7Vgm3ZX3v8>
Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type
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: Wed, 22 Apr 2020 20:01:39 -0000

Thanks Brian,

Den 2020-04-21 kl. 20:56, skrev Brian Rosen:
> I’m okay with the new payload type.  All of this would be new code, so 
> dealing with the new payload type wouldn’t be confusing or difficult.
Right. And a lot from RFC 4103 is still valid with the new payload type, 
so that it can be an update to RFC 4103.
> I’m not aware of any implementations of t140 without redundancy, but 
> I’m also not bothered by including rtt-mix.
Right. No one using plain T.140 without redundancy currently.
>
> I’m also okay with James Hamlin’s proposal.  I like the effect enough 
> that I’m not going to worry about bad implementations.
I aim at including this new payload type in next version. I also intend 
to look at what sdp would look like if we include negotiation between 
RTP and SRTP.
> Again, supporting this is new code, so if your implementation of T140 
> and SDP in general is lacking, this would be a good time to fix that.

>
> Brian
>
Thanks,

Gunnar

>
>> On Apr 21, 2020, at 5:18 AM, Gunnar Hellström 
>> <gunnar.hellstrom@ghaccess.se <mailto:gunnar.hellstrom@ghaccess.se>> 
>> wrote:
>>
>> Hi,
>>
>> I have got an off-list comment that the proposed use of the CSRC-list 
>> members to indicate source of the primary and the different 
>> redundancy generations of the T140blocks would require registration 
>> of a new payload type instead of saying that it is a refined use of 
>> text/red updated from RFC 4103.
>>
>> ( this is about 
>> https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt-source-03.txt 
>> )
>>
>> The purpose is to speed up the switch of source of text from the 
>> mixer so that every packet can have primary text from another source 
>> than the previous packet. Without the update, the mixer would need to 
>> send two packets with just redundant text before sending new text 
>> from another source.
>>
>> I am not yet totally convinced that we need to introduce a new 
>> payload type, but find it possible.
>>
>> Let us call it "text/rex" for "redundancy extended".
>>
>> It would cause a quite straightforward sdp negotiation of parties 
>> supporting both the traditional text/red format from RFC 4103, and 
>> the updated text/rex.
>>
>> Offer example :
>>
>>        m=text 11000 RTP/AVP 101 100 98
>>        a=rtpmap:98 t140/1000
>>        a=rtpmap:100 red/1000
>>        a=rtpmap:101 rex/1000
>>        a=fmtp:100 98/98/98
>>        a=fmtp:101 98/98/98
>>        a=rtt-mix
>>
>>   Answer example  from a multi-party capable device
>>        m=text 11000 RTP/AVP 101 98
>>        a=rtpmap:98 t140/1000
>>        a=rtpmap:101 rex/1000
>>        a=fmtp:101 98/98/98
>>        a=rtt-mix
>>
>> Answer example from a multi-party unaware device:
>>
>>        m=text 11000 RTP/AVP 100 98
>>        a=rtpmap:98 t140/1000
>>        a=rtpmap:100 red/1000
>>        a=fmtp:100 98/98/98
>>
>>   
>>
>> It may look strange that the attribute a=rtt-mix is still there as an 
>> indication of multi-party capability when that already is implied in 
>> the "rex" payload type. But it is for the very rare case that the 
>> network conditions would allow use of bare t140 payload type without 
>> redundancy. Then there is a need to indicate multi-party awareness by 
>> a=rtt-mix .
>>
>> If we accept this move, we could also open for discussion if the 
>> format proposed by James Hamlin earlier in this list, where the 
>> maximum number of 16 members in the CSRC list allows transport of 
>> text from up to 16 sources in the same packet. That would make the 
>> mixing of real-time text as efficient and rapid as that of audio and 
>> video. A question is though if current implementations are well 
>> behaving and do not collapse by getting the combined sdp.
>>
>> If we do not accept this move and instead base the multi-party mixing 
>> on the current text/red format with short transmission intervals, we 
>> can claim that simultaneous typing is quite rare and that the 
>> introduced delay of the first few characters of about 200 ms from a 
>> second source when one is already sending is acceptable, knowing that 
>> most text conversations are at speeds of under 12 characters per 
>> second and that the transmissions from each source anyway comes in 
>> 300 ms intervals.  Some jerkiness and delay will be noticable when 
>> there is more than two simultaneous senders.
>>
>> Regards
>>
>> Gunnar
>>
>> -- 
>> Gunnar Hellström
>> GHAccess
>> gunnar.hellstrom@ghaccess.se
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org <mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt
>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se