Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport

Gunnar Hellström <> Thu, 14 May 2020 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8FEF3A0AB3 for <>; Thu, 14 May 2020 08:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X51sVy8fwiMX for <>; Thu, 14 May 2020 08:01:59 -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 EBBA93A0AF5 for <>; Thu, 14 May 2020 08:01:58 -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)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id C715D202B4 for <>; Thu, 14 May 2020 17:01:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1589468516; bh=1hWO8Z/Wx/s4YIIrhV2+zI5ZUNfzyXQBab3FFCkKj6E=; h=Subject:From:To:References:Date:In-Reply-To:From; b=KLvYBHRzjFIyI/kyt6wy6vuaqS67yXtaB4bv/VOusOIpq1jRmwf1DrpPHVX5EBlSI BKFmLawKdSsS6Hy/wEn+saDg20u2IQTkEAzw3Yoeqv5iXqYxDT0BqWO41C/ndoBsLo PQRIqbIFGJf4lYlzVURax7MHCovCCAp3w07hO5LE=
From: Gunnar Hellström <>
References: <> <> <>
Message-ID: <>
Date: Thu, 14 May 2020 17:01:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport
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: Thu, 14 May 2020 15:02:03 -0000

I have concluded that only two of the discussed transports are realistic.

Comments below

Den 2020-05-11 kl. 12:22, skrev Gunnar Hellström:
> In a recent e-mail, I listed 9 issues to act on in 
> draft-ietf-avtcore-multi-party-rtt-mix-00
> I want to deal with them one by one or in small groups. Here is number 1:
> 1. Consider rapidly if there is any more reliable transport that is 
> feasible to move to.
>> (e.g. Comedia RFC 4145 and RFC 4572, or the recently approved WebRTC 
>> t140 data channel draft-ietf-mmusic-t140-data-channel-usage, or use 
>> of SAVPF with NAK and retransmission RFC 4588) 
> It may look strange with this issue after many months as an individual 
> draft. But I want to touch it anyway before we move on in one fixed 
> direction.
> T.140 and its RTP transport (RFC 2793 - later RFC 4103) were created 
> 1998 - 2000 as the third real-time medium for human conversations 
> beside voice and video. The idea was to give equal opportunities to 
> persons wanting to communicate by text as the ones who use voice or 
> video. That means real-time transmission while text is created and 
> accepting some rare dropouts just as we do with voice and video. 
> However, users are nowadays used to text messaging where it is 
> customary to accept a delay and get the text complete in most cases, 
> rather than to have loss. That user experience might be expected from 
> real-time text as well. I do not have any strong user indications that 
> this is the case, it is just my own thinking.
> The reason to bring this up now, is that we seem to need to introduce 
> the multi-party mixed format at least as a new text media subtype, 
> text/rex instead of text/red. Then we are anyway introducing signaling 
> complexity of similar kind that another transport will do.
> Are any of the initially mentioned more reliable transports realistic 
> and easily implemented in the target implementation environments: NG 
> emergency services, 3GPP IMS MTSI, IETF RUM, and plain SIP multimedia? 
> Or are there any other not mentioned?
> When considering this, we should have in mind that the proposed 
> transport should be with security so that we do not need to introduce 
> more options to negotiate between.
> And we shall also keep in mind that NAT traversal needs to be 
> supported as well as multi-party-signaling through the SIP central 
> conferencing model RFC 4353.
> Another complexity is that current regulation requires RFC 4103 and it 
> would be best that the finaly specified multi-party solution can be 
> perceived as an extension to RFC 4103.
> What can be said about the options?
>  1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for transport, so 
> it is secured. Should use RFC 6544 ICE for TCP for NAT traversal. 
> Requires specification of how to arrange the streams and code the 
> sources in the multi-party environment. I do not know how well these 
> RFCs are supported in the target environments. Seems to increase 
> complexity.
--Increases complexity - not selected
> 2. draft-ietf-mmusic-t140-usage-data-channel. Has security, NAT 
> traversal and possibility to code multi-party source. Has good 
> opportunity for being supported in endpoint devices, because all of 
> them are expected to support WebRTC. Maybe less supported in 
> traditional SIP bridges.
--A realistic solution. The base is already approved and is for a 
popular environment. Multi-party is briefly mentioned but should 
probably be a bit further specified. Should however not be the only 
solution. The RTP based solution is also needed.
> 3. SAVPF with NACK and RFC 4588 retransmission. I assume this can be 
> combined with OSRTP RFC 8643 for security negotiation. When the 
> immediate or early feedback option can be used, this method can likely 
> be used without redundancy to achieve a reliability enhancement. That 
> will not work well over networks with high latency. Further study 
> needed if redundancy or FEC is needed as complement for high latency 
> networks. Easy to achieve up to 5 simultaneously sending users.
--Increases complexity - not selected
> 4. (Not mentioned in the introduction above) Use RFC 4103 plus one of 
> the RTP based methods for multi-party source indication but just 
> increase redundancy to one original and three (instead of two) 
> redundant generations. Can easily be done if reliability increase is 
> really a concern. Has low overhead. Easily applicable to OSRTP 
> security, SIP conferencing model and ICE NAT traversal.
--Easily done by local recommendations if 3 generations redundancy 
(including the original) would not be felt sufficient somewhere.
> 5. Accept reliability that is quite good as it is with RTP with one 
> original and two redundant generations in the RFC 2198 - style ( with 
> one of the additional methods discussed for increasing switching 
> performance)
--Realistic and regarded sufficient. By move to a mixer method allowing 
300 ms transmission interval, the protection against burtsy packet loss 
is quite good. Continue on this track.

The conclusion is reflected in version -01 of the draft, just published.



> Comments please so we can take a rapid decision and move on with one 
> solution.
> Regards
> Gunnar
Gunnar Hellström