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

Brian Rosen <br@brianrosen.net> Tue, 21 April 2020 18:56 UTC

Return-Path: <br@brianrosen.net>
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 324293A052C for <avt@ietfa.amsl.com>; Tue, 21 Apr 2020 11:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 bNPf_uv0oR8G for <avt@ietfa.amsl.com>; Tue, 21 Apr 2020 11:56:19 -0700 (PDT)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EEC3A0524 for <avtcore@ietf.org>; Tue, 21 Apr 2020 11:56:18 -0700 (PDT)
Received: by mail-qv1-xf32.google.com with SMTP id y19so7113500qvv.4 for <avtcore@ietf.org>; Tue, 21 Apr 2020 11:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/lNTLANoneOk09ctHvrep7GVtm82hGrpAnF06EmOHv0=; b=a37rf0VJF1wMOMShCfAybjydOfX1RWGHo7o4bWUpbOUPuKH/UfcTT4KgJmZxx0i2+u OJxsDEzsSvHS4psk9eAmoj9J1xko7cgTA4Af/Fnk2TTXWJeSZ9+tCvyGMo4IrDmStAKR KH8eK4YTdK/B7rH4MCAq1H53SpuRRSAFl9382ILhToe/KhzFzIQr/eh+1Sba/sDZWqur 78qzlRu0VCzdn6b2mQx88aUzBVeXalHfZ176bn1GxC89s/wKgVVZvyALaw+FC/xVRCCl McG2oK6jOAYJfyB7W9EZkBazoyNRmfaRk3+0thnnrAzQb5yEhXr+c15DO8vjh/3mgxAi qMFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/lNTLANoneOk09ctHvrep7GVtm82hGrpAnF06EmOHv0=; b=IjALB7EyDabbmQai2K/pTI40AUO1ZD5U8WVEPRSJ/W53NXdFchkfymeLnjbLTOzc44 sEio6da9pRYLkJNdMKjDNMSqXceyZknTVv7udZpSlDzqmwJH2pxxl7VyoCSfEFsBzkIR BuJANaMh6kA9BXwbZtJT4jOIquTyZetxpyQoNq1bsBisgKyBQEWIfMpsgomlzcX1+rbu WWGuOS4YQ77PDxP1skiBwO7SN+iQT5c/KhF1CqxgJe+yz35z7ew0CscO1v3BZI3q8Bbn daJW3aGkXWqJ8HYjqrwauE3v/Kebx0KF3lUUgHgbwIvV9fYAaOfA24fqqz2kOSLT4Gwi JF0Q==
X-Gm-Message-State: AGi0PuaqI8x055AoX3/Eox+VEQcCafdlRL5flqqtqVe1Rmeh9RDc+yuG oW92lfNoSNvsclLM/OM23uPRsGRc97s=
X-Google-Smtp-Source: APiQypIwxOdwdx0Fd9dmgsKS/X+n4xYha8xlt1oHWpVU3wlOAuxg2hcTjpPKfW0vuzito+8EIikX2g==
X-Received: by 2002:a05:6214:530:: with SMTP id x16mr9077440qvw.55.1587495376157; Tue, 21 Apr 2020 11:56:16 -0700 (PDT)
Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id c11sm2258678qkj.78.2020.04.21.11.56.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 11:56:15 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <197C0C31-FDCB-46A8-9642-5F4D98F63F75@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3AC490FF-0B73-428E-9870-C627F032532C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 21 Apr 2020 14:56:14 -0400
In-Reply-To: <e2d44956-2cd7-b43a-e847-fbeed5b0ef62@ghaccess.se>
Cc: "avtcore@ietf.org" <avtcore@ietf.org>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@ghaccess.se>
References: <e2d44956-2cd7-b43a-e847-fbeed5b0ef62@ghaccess.se>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/1ypKIh19DCYL9R5EwnImyALy6Ws>
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: Tue, 21 Apr 2020 18:56:24 -0000

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. 
I’m not aware of any implementations of t140 without redundancy, but I’m also not bothered by including rtt-mix.

I’m also okay with James Hamlin’s proposal.  I like the effect enough that I’m not going to worry about bad implementations.  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


> On Apr 21, 2020, at 5:18 AM, Gunnar Hellström <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 <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 <mailto:gunnar.hellstrom@ghaccess.se>_______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt