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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Thu, 23 April 2020 08:37 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 3BA5A3A1711 for <avt@ietfa.amsl.com>; Thu, 23 Apr 2020 01:37:07 -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 AThzNaJcYOrd for <avt@ietfa.amsl.com>; Thu, 23 Apr 2020 01:37:03 -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 B23323A1712 for <avtcore@ietf.org>; Thu, 23 Apr 2020 01:37:02 -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 D60B8202BA; Thu, 23 Apr 2020 10:36:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587631019; bh=DCnM1kPIlrgL0UibNqlrVi2+jh+C4Nx6tv82wIWr9M4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=C/YgE9r/JVEo4r7oAVyegkhR+F1qY8qeKd6lkT/gBkzbxfkC3GIt7xo65/n+wal/+ 7MSoUJB17S4thnExRzpneVWqxv5g1gVV1rmzE0gd1ziz7SWTaGQLhJmPloiywKrzXf BIe9cI7HIPzQW9iiErS8gmseXkfGV4X523Errk9E=
To: "Dale R. Worley" <worley@ariadne.com>
Cc: avtcore@ietf.org
References: <87h7xbuebo.fsf@hobgoblin.ariadne.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <8cec232d-1341-9d33-447a-49263c550a92@ghaccess.se>
Date: Thu, 23 Apr 2020 10:36:51 +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: <87h7xbuebo.fsf@hobgoblin.ariadne.com>
Content-Type: multipart/alternative; boundary="------------31E464FC11F3D0320E7BA0A9"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/W_7zS4kDuEmigOYZ9yCeAaFlLtg>
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: Thu, 23 Apr 2020 08:37:08 -0000

Hi Dale,

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.

More below

Den 2020-04-23 kl. 04:27, skrev Dale R. Worley:
> I assume that there's a good reason why the case of redundant
> transmission of multi-party text isn't done by suitably interleaving the
> redundant packets of the serveral text sources (which can be separated
> by their SSRC values).  I can't remember if this is a violation of the
> RTP rules, or perhaps it's just inefficient.  But a quick read of the
> draft didn't mention why this approach doesn't work, and it seems like
> it would be a useful note to the reader.
Draft-hellstrom-avtcore-multi-party-rtt-source is intended to contain 
the solution for the type of bridge used in NG9-1-1 and 3GPP IMS, which 
seems to be based on the RFC4535 SIP centralised conference framework.
Backgrounds and discussions of possible methods with a wider scope are 
collected in

draft-hellstrom-avtcore-multi-party-rtt-solutions
<https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-solutions/?include_text=1>

where section 4.2.1 is similar to what you propose with separate ssrc:s 
per source. Each discussed method also has pros and cons briefly 
documented. Having separate SSRC per source is what RTP calls using a 
RTP translator.

Yes, I would have liked to use that method. But we have an urgency in 
implementing the selected method in NG9-1-1 systems and in 3GPP IMS. And 
it is said that many current RTP implementations do not support multiple 
SSRCs in the same RTP session and even that RFC 3264 says that one 
m-section in sdp can only support one SSRC. However, RFC 4588 (FEC) 
section 8.8 shows an SSRC-multiplexing sdp example where the original 
media stream has one SSRC and the redundancy another within the same 
m-section. But that is of course no evidence that current RTP 
implementations support it.

RFC 8108 clarifies in section 3.3 that one of its applications is for 
combining multiple media sources of the same kind in the same RTP 
session. But it has the total goal of multiplexing also multiple media 
in the same RTP session. The corresponding sdp specification (with a 
much wider scope than we need) is 
draft-ietf-mmusic-sdp-bundle-negotiation and it is not supported by many 
current RTP implementations ( but maybe soon is because of its use in 
WebRTC).

Methods that could be considered but are not yet documented in 
draft-hellstrom-avtcore-multi-party-rtt-solutions 
<https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-solutions/?include_text=1> 
are (excuse me if some look far fetched):

RFC 4588 FEC, using SSRC multiplexing if that works or session 
multiplexing if needed. In this case plain T.140 RTP would be sent from 
the mixer in one stream, with the ssrc of the mixer and csrc of the 
source, and in the redundancy stream the packets would be repeated 
(twice) with another ssrc in a small redundancy header.

RFC 8122 Comedia to improve reliability, but then I have not studied how 
to arrange for multi-party use.

draft-ietf-mmusic-t140-usage-data-channel using one WebRTC data channel 
per source.

RFC 8108 section 3.3 and draft-ietf-mmusic-sdp-bundle-negotiation

Avoiding solutions because of imagined limitations in current 
implementations may be a bad design criterium, so do you suggest that we 
rapidly look further into any of these or other options?

Thanks

Gunnar


>
> Dale

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