Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-12.txt

Gunnar Hellström <> Sat, 20 June 2020 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47D2C3A1104 for <>; Sat, 20 Jun 2020 02:38:03 -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 tsMjBAtekUJ7 for <>; Sat, 20 Jun 2020 02:37: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 9C7F93A0A07 for <>; Sat, 20 Jun 2020 02:37:57 -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 7AD6020159; Sat, 20 Jun 2020 11:37:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1592645875; bh=W8d2GmkjXfhEiGd/hsT2dGxC6WiCo9oejug23yrG5Ag=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SmKzE88ja/NCFM6w6LgSaTsZtAEG7KAvu79Sy+xfynab27U+jK9jWBXVBfqrL6dIM pviAJqiwQQQv8k2nCxmJpT7UG7wrf+L+HoVXJgRoktbulciBm+vPeJZwY9xhm/+7/+ PT5cgrlLOLd922fD3rFyf8MjcQ8ACfTO8VSQflu4=
To: Magnus Westerlund <>, "" <>
References: <> <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Sat, 20 Jun 2020 11:37:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6A79281ABED8CD502A845830"
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-12.txt
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: Sat, 20 Jun 2020 09:38:03 -0000


Thanks for an inspiring draft.

I have two issues:

1.) In section 3.4.2 it is said:

"RTP Considerations for Endpoints Sending Multiple Media Streams" 
[RFC8108 <>].

I first got the impression that this would refer to a section in RFC 
8108, but there is none with that title.

And it is also not the title of RFC 8108. I suggest that you update the 
string to what it was intended to refer to.

2.) I see a contradiction between two statements:


I.) In 3.4 you say:    "Using multiple RTP streams is a well-supported 
feature of RTP."

II.) In 5.2, 4.b you mention a disadvantage with using multiple streams 
for the same media type in one RTP session:

"b. There is some potential for concern with legacy implementations that 
don't support the RTP specification fully when it comes to handling 
multiple SSRC per endpoint."


Can you in some way tell for which cases there is concern and for which 
it is a well-supported feature.

My interest is for the multi-party-rtt drafts, where we have so far 
avoided the solution with multiple media streams of one media type in a 
single RTP session saying that there may be lack of support for it in 
current RTP stacks. Our current choice to instead have a mixer combine 
all streams into one stream has some disadvantages and does not seem to 
be your recommendation.



Den 2020-06-16 kl. 10:40, skrev Magnus Westerlund:
> WG,
> This version intendeds to address the issues raised during IESG review.
> Cheers
> Magnus
> On Tue, 2020-06-16 at 01:37 -0700, wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Audio/Video Transport Core Maintenance WG of
>> the IETF.
>>          Title           : Guidelines for using the Multiplexing Features of
>> RTP to Support Multiple Media Streams
>>          Authors         : Magnus Westerlund
>>                            Bo Burman
>>                            Colin Perkins
>>                            Harald Tveit Alvestrand
>>                            Roni Even
>> 	Filename        : draft-ietf-avtcore-multiplex-guidelines-12.txt
>> 	Pages           : 43
>> 	Date            : 2020-06-16
>> Abstract:
>>     The Real-time Transport Protocol (RTP) is a flexible protocol that
>>     can be used in a wide range of applications, networks, and system
>>     topologies.  That flexibility makes for wide applicability, but can
>>     complicate the application design process.  One particular design
>>     question that has received much attention is how to support multiple
>>     media streams in RTP.  This memo discusses the available options and
>>     design trade-offs, and provides guidelines on how to use the
>>     multiplexing features of RTP to support multiple media streams.
>> The IETF datatracker status page for this draft is:
>> There are also htmlized versions available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> I-D-Announce mailing list
>> Internet-Draft directories:
>> or

Gunnar Hellström