Re: [AVTCORE] Update to RFC5285 allowing both one and two bytes header extensions in the same RTP packet

Magnus Westerlund <> Fri, 11 September 2015 11:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D37F51A00E9 for <>; Fri, 11 Sep 2015 04:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AGPh8QpaLpGH for <>; Fri, 11 Sep 2015 04:27:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA1471A6FCE for <>; Fri, 11 Sep 2015 04:27:31 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-c0-55f2baa10ebf
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E7.18.17026.1AAB2F55; Fri, 11 Sep 2015 13:27:30 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 11 Sep 2015 13:27:29 +0200
To: Roni Even <>, <>
References: <04a801d0ec69$aec10170$0c430450$> <> <04b001d0ec7f$4c4338e0$e4c9aaa0$>
From: Magnus Westerlund <>
Message-ID: <>
Date: Fri, 11 Sep 2015 13:27:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <04b001d0ec7f$4c4338e0$e4c9aaa0$>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvje6iXZ9CDaZf47B42bOS3eJvO7MD k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbHtyEbGgq1KFTOv/WdsYFwh3cXIySEhYCLx cM0yRghbTOLCvfVsXYxcHEICRxklrkx8zgzhLGeUWPv5J3sXIweHsECxxLItviANIgJmEuvO v2KBqGlllDj0bw3YJDYBC4mbPxrZQGxeAW2J3XOuMYPYLAKqEl8m/GUCsUUFYiR6fm2AqhGU ODnzCQuIzQnUu/jtSrBdzAL2Eg+2loGEmQXkJZq3zgYbIwQ0sqGpg3UCo8AsJN2zEDpmIelY wMi8ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwJA9u+a27g3H1a8dDjAIcjEo8vAtMP4UK sSaWFVfmHmKU5mBREudtYXoQKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRKHr5ga8uB1b9 m+d4zOHht7a4I3d9Pj61cP4/w3vn029bDs6uLt3HWvKDd2Xi2hn3Pwozz7LnlS15rGGTfmG9 rvPG5BV5T2z2RQW+qeqd4mTQt2JKepf/+vhn+a+nLZvy22vjc/Yu+ez+BUnPr3R+9TJ8r1Nw dHty0rIa275zX754NnDM7nlkqcRSnJFoqMVcVJwIAKB6ClIqAgAA
Archived-At: <>
Subject: Re: [AVTCORE] Update to RFC5285 allowing both one and two bytes header extensions in the same RTP packet
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: Fri, 11 Sep 2015 11:27:34 -0000


Please see inline.

Den 2015-09-11 kl. 12:47, skrev Roni Even:
> Hi Magnus,
> Inline
> Roni
> -----Original Message-----
> From: Magnus Westerlund []
> Sent: Friday, September 11, 2015 11:36 AM
> To: Roni Even;
> Subject: Re: [AVTCORE] Update to RFC5285 allowing both one and two bytes
> header extensions in the same RTP packet
> Den 2015-09-11 kl. 10:13, skrev Roni Even:
>> Hi,
>> At IETF94 there was a consensus to allow mixing of one byte and two
>> bytes header extensions in the same RTP packet.  I volunteered to do
>> the update to RFC5285.
>> The issue I have s how to pack both one and two bytes in the same RTP
>> packet.
> No, I don't agree with that classification of the issue. What was discussed
> was that RFC 5285 does not allow to use both one and two byte headers in the
> same RTP stream.
> RE: OK , so I had a wring understanding. But I am not sure it is simpler
> except using the current extension headers in the RTP packets. But if this
> is what was the agreement I will propose text accordingly.
> To my understanding the suggestion for fixing this issue was to allow an RTP
> sender to switch between RTP packets between using one or two bytes headers
> depending on need.
> RE: that will be a limitation if at a certain point of time you may need to
> send at the same time a one byte and two bytes header extension even though
> initially it was not required.

My understanding is that header extensions in general is not one or two 
byte specific. Header extensions that are longer than 15 bytes are 
required to use two-byte from the fact that one-byte can't indicate the 
necessary length. The other reason that can force use of two byte 
extensions is if the total number of negotiated extensions are more than 
15, then the ID values would force use of two byte.

However, among a set of header extension that are not forced by either 
of the above restrictions, payload length or ID > 15, these extensions 
is able to use either one or two byte extension headers. Which is used 
depends on the mix of other. So, if all header extensions that are to be 
added to a particular packet are such that one can use one-byte, then 
use one byte for all. If the next packet then contain one or more header 
extension requiring two-byte, then one uses two byte for all of the 
header extensions present in this packet.

> I think that has much less impact on deployed scenarios than the more
> extensive change below.
> Further I think Mo was suggesting that the signalling was tweaked such that
> any header extension that requires two byte headers only should request ID
> values of 16 and larger to indicate that need. That still leaves some
> uncertainty for header extensions that have changing context and may go back
> and forth between needing one or two byte headers.
> RE: I am not sure I understand, are you saying that currently you can use
> only ID value of 16 and higher for two bytes header extensions, or is the
> proposal, this can allow mixing in the same packet but may have backward
> interoperability issues.  I am ot sue we need this limitation since the
> extension header will distinguish between one byte and two bytes RTP packets
> I think my proposal will address backward interoperability since a new
> extension header will be used for the mixing case, but any solution whether
> it is only in the same RTP stream or packet will need to be negotiated.

Currently there are clarifications. But, I think Mo's proposal was to 
recommend/force header extensions that know they need to use two-byte 
header to indicate that in setup signalling by using ID values > 15. 
That way one can detect some implementations that fails to support 


Magnus Westerlund
(As individual)


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: