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

Gunnar Hellström <> Tue, 05 May 2020 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA1CD3A07C6 for <>; Tue, 5 May 2020 07:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4yBNFEiPvSkh for <>; Tue, 5 May 2020 07:46:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 899663A07B3 for <>; Tue, 5 May 2020 07:46:43 -0700 (PDT)
Received: from [] ( []) (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: by (Postfix) with ESMTPSA id 9204220093 for <>; Tue, 5 May 2020 16:46:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1588690000; bh=iOpsZKE/rqqo3G9B93dv1Rf7FZhms9zryMu+1bftZr8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=sDaw213YzDc16vgZLi6ImsHm35W5Y1o2MPk97GXi3FcHv6wMt9VowCbS168Uq0fna AmhoKsnZI/TR0fgLhJtjing/CqBq9yZ2ccWz7cWyQXw/ObRYkgYIXLGEhjWZYsaVya lFknLkRB3Z6Yt06+pWnLt+rjCNq3703swW0ou7a4=
References: <> <>
From: Gunnar Hellström <>
Message-ID: <>
Date: Tue, 05 May 2020 16:46:38 +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: <>
Content-Type: multipart/alternative; boundary="------------B8E4C079E963B3B06431A4BA"
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 May 2020 14:46:50 -0000


See proposed text below

Den 2020-04-24 kl. 10:55, skrev Gunnar Hellström:
> Den 2020-04-24 kl. 03:22, skrev Dale R. Worley:
>> Gunnar Hellstrom <> 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.

I propose to add the following last in the introduction:


1.1.  Considered alternative

    The mechanism specified in the present document makes use of the RTP
    mixer model specified in [RFC3550].  From some points of view, use of
    the RTP translator model specified in RFC 3550 would be more
    efficient, because the text packets can pass the translator with only
    minor modification.  However, there is no widely supported sdp
    [RFC4566] specification for the translator model.



> 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