Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5764-mux-fixes-03.txt

Marc Petit-Huguenin <> Tue, 26 January 2016 20:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 591491B2D0B; Tue, 26 Jan 2016 12:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pyprHQFPtD5S; Tue, 26 Jan 2016 12:28:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 50A911B2D02; Tue, 26 Jan 2016 12:28:18 -0800 (PST)
Received: from [IPv6:2001:5c0:1400:b::1121] ( [IPv6:2001:5c0:1400:b::1121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "" (verified OK)) by (Postfix) with ESMTPS id 28538200F3; Tue, 26 Jan 2016 21:28:15 +0100 (CET)
To: Magnus Westerlund <>,,
References: <> <>
From: Marc Petit-Huguenin <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 26 Jan 2016 12:28:13 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5764-mux-fixes-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jan 2016 20:28:23 -0000

Hash: SHA256

Sorry for the delay in processing this.  See answers inline.

On 10/20/2015 03:49 AM, Magnus Westerlund wrote:
> Hi,
> I have looked at the updated draft. I think you have resolved my previous comments, thank you. However, I still have some comments.
> 1. Split the introduction chapter. The introduction is much more than an introduction. I think the sub-sections likely belong in a new section after the introduction that discusses the issues and intended changes in depth. However, they are not introduction.


> 2. Section 1.3:
> I still are uncertain if TURN channels needs the whole range 64 to 79. I think the text should be explicit about how many turn channels this support. So according to my math the proposed change is from 64-127 to 64-79, i.e. the available number of channels has been reduced from 16384 to 4096. That still a large number of channels.
> What number of channels are currently used by implementations? I expect that to be single digit, or am I missing some use cases?

We think these questions would be better answered by people implementing RFC 5764, so we left the range as is.  One can imagine an allocation scheme where higher channel numbers are used, without necessarily using many channels.  What you propose would negatively impact these implementations.  Until we hear from implementors, we would prefer to keep it as written.

> 3.  Section 1.4:
> I still don't see how what is written in this section results in any improvement. You authors have assumptions of how this needs to be implemented that isn't written down. Looking on this problem of demultiplexing I would build a table driven solution based on the ranges, where the packet is sent to the relevant protocol based on the table-lookup. If that protocol don't use that value, that will be the end of the road for that packet as invalid, rather than giving it to any other protocol. I get the impression that you want one to send the packet for testing by the protocols one after each other according to the order the protocols are listed. I still don't see that implementations will do that.

Based on the discussion with Paul Kyzivat and you, we decided to remove that section altogether.

With that, we believe that all pending issues are now resolved, which in our opinion makes the draft ready for WGLC.

> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance

- -- 
Marc Petit-Huguenin
Version: GnuPG v2