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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Tue, 21 April 2020 09:18 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 A51253A09E3 for <avt@ietfa.amsl.com>; Tue, 21 Apr 2020 02:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 eWYwnmCzKAas for <avt@ietfa.amsl.com>; Tue, 21 Apr 2020 02:18:20 -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 818573A09EF for <avtcore@ietf.org>; Tue, 21 Apr 2020 02:18:18 -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 6B62B2003C for <avtcore@ietf.org>; Tue, 21 Apr 2020 11:18:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587460696; bh=6/9xApAVDulCM3sqGvbnaisEQLVodhH0mJnmALDd9Ew=; h=To:From:Subject:Date:From; b=shheT+NQPw1yi1ok3B0l8zZGR9ugHFULooJrP5IqWQmyEpopxZR7uww1bCJlCziCG ScxC+4PA9eKcX+WHTvM2lWlQqRw7oDFzfBnUph/Rux4NcASpwwzPaUAXXEmii0sElP 9QBZGo7M+L/3cYCcbkvsEB3Wz51A7aFLNTMRAqIw=
To: "avtcore@ietf.org" <avtcore@ietf.org>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <e2d44956-2cd7-b43a-e847-fbeed5b0ef62@ghaccess.se>
Date: Tue, 21 Apr 2020 11:18:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------59E7894BB72C1166AEC84AF8"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/0ivHf_hH2sL35QlWFG8P2NI0TZ0>
Subject: [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: Tue, 21 Apr 2020 09:18:26 -0000

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