IETF Logo Mail Archive

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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Fri, 24 April 2020 08:55 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 124FF3A1056 for <avt@ietfa.amsl.com>; Fri, 24 Apr 2020 01:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 uYNBci-ahIIL for <avt@ietfa.amsl.com>; Fri, 24 Apr 2020 01:55:14 -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 3175D3A1046 for <avtcore@ietf.org>; Fri, 24 Apr 2020 01:55:09 -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 EFF3520097; Fri, 24 Apr 2020 10:55:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587718507; bh=AJZp6yIc1ErbL0hWgZbpu+PhdA8YL1NHHSYzDM9Q5ig=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mv+XLDBzSFMZonclszaFPJ6APYHseF+G0NcI2yRLX1HUkntzKiYTXY7m9NI3b8e8N CtUrbL0hsD7fHbGSWTcOpOFJKyNs4Pbah242HkiuxGq1zcLjL7LvgQzBoj9VxROgWM lNm7Tyc+TQGWCAQrNSd95GJ5jb2YuwMCLMmvL+ZM=
To: "Dale R. Worley" <worley@ariadne.com>
Cc: avtcore@ietf.org
References: <87y2qlu17b.fsf@hobgoblin.ariadne.com>
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <23b9e138-b346-8fcb-4627-dee75aba79c4@ghaccess.se>
Date: Fri, 24 Apr 2020 10:55:04 +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: <87y2qlu17b.fsf@hobgoblin.ariadne.com>
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/9DEbhndFIlC6-dPQmsmACG6df-w>
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: Fri, 24 Apr 2020 08:55:18 -0000

Den 2020-04-24 kl. 03:22, skrev Dale R. Worley:
> Gunnar Hellstrom <gunnar.hellstrom@ghaccess.se> writes:
>> Thanks, a good question. It is the right time to consider which source
>> multiplexing and reliability method to select, now when we need to
>> introduce a new negotiation.
> My idea wasn't that I had any better idea, but rather that there were
> some obvious ideas, and clearly, people who had studied the matter found
> that the obvious ideas were not the best.  What I really meant was that
> it would be useful to give brief documentation why the obvious ideas
> aren't best.

Your question provided a good opportunity to review solution alternatives.

Since the effort to specify multi-party real-time text aims at additions 
to current implementations of bridges and endpoints I think one 
requirement should be to keep the solution as close to the current 
solutions for the other media handles by these bridges and endpoints.

NG9-1-1, NG 112 and 3GPP CONF services specify use of the RFC 4535 SIP 
conference framework. Adding new participants in that framework usually 
does not cause any new sdp interaction with the other participants, as 
long as no new media is added. Just a notification is sent. I assume 
that it can be good to keep that way of action also for adding 
participants with real-time text. Using the RTP mixer model adding just 
members in the CSRC lists is then the most simple model. So, this is yet 
another reason for why to keep to the RTP-mixer solution for the first 
specification in the draft-hellstrom-avtcore-multi-party-rtt-source 
draft. It might be followed by other selected cases in the 
draft-hellstrom-avtcore-multi-party-rtt-solutions draft, where WebRTC 
and use of sdp-bundle can be spcified, which are out of scope for the 
first case.


Even if different solutions are discussed in the 
draft-hellstrom-avtcore-multi-party-rtt-solutions draft, I accept your 
point and will include a brief motivation also in the 
draft-hellstrom-avtcore-multi-party-rtt-source draft.

Comments are very welcome about the reasoning.

Thanks

Gunnar

>
> Dale

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

v2.23.0 | Report a Bug | By Email