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

Magnus Westerlund <> Fri, 11 September 2015 08:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2F6A41B4298 for <>; Fri, 11 Sep 2015 01:36:12 -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 KUDLp4BX5Yco for <>; Fri, 11 Sep 2015 01:36:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A2331B4253 for <>; Fri, 11 Sep 2015 01:36:10 -0700 (PDT)
X-AuditID: c1b4fb3a-f79136d0000071e2-1d-55f29278164d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DB.BF.29154.87292F55; Fri, 11 Sep 2015 10:36:08 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 11 Sep 2015 10:36:07 +0200
To: Roni Even <>, <>
References: <04a801d0ec69$aec10170$0c430450$>
From: Magnus Westerlund <>
Message-ID: <>
Date: Fri, 11 Sep 2015 10:36:06 +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: <04a801d0ec69$aec10170$0c430450$>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+JvjW7FpE+hBpcmSFm87FnJbvG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyji/uYm94K54xaE54Q2MN4W6GDk5JARMJOY+ f8cMYYtJXLi3ng3EFhI4yijxpc2yi5ELyF7OKPGvbT9jFyMHh7BAscSyLb4gNSICZhLrzr9i gag3l3j6oJkRxGYTsJC4+aMRbA6vgLbEnEfnwWwWAVWJfxMbmEBsUYEYiZ5fG6BqBCVOznwC NocTqHfnvS+sIKuYBewlHmwtAwkzC8hLNG+dzQyxSluioamDdQKjwCwk3bMQOmYh6VjAyLyK UbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzAYD275bbWD8eBzx0OMAhyMSjy8C0w/hQqxJpYV V+YeYpTmYFES521mehAqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVEn+mrgqfRNL06zSEjr vYtX1fwd75xvzOfy7N1udpu/ez0aphcx7j+VoGUT+YshPeXm3TnHcmom8AQsMZY75Dj7+JUE q0MHuWV2bn0UosWww8l5Xc/27a2ye6/MKvU7vvjJ4htr9v+0OnmtIqorZbqV9+f1YQv3Cngq L5/CY/Vcq/q+/R2xdVFKLMUZiYZazEXFiQD8blDrJwIAAA==
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 08:36:12 -0000

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.

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.

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.


Magnus Westerlund
(As individual)

> Currently the extension header (as specified by the profile) is 0xBEDE
> for one byte only headed extension and 0x100 followed by 4 bits called
> appbits for the two bytes header extension
> “The appbits field is 4 bits that are application-dependent and may be
>     defined to be any value or meaning, and are outside the scope of this
>     specification.  For the purposes of signaling, this field is treated
>     as a special extension value assigned to the local identifier 256.
>     If no extension has been specified through configuration or signaling
>     for this local identifier value 256, the appbits field SHOULD be set
>     to all 0s by the sender and MUST be ignored by the receiver.”
> My proposal is to keep this two options and add a new extension header
> 0x200 followed by the 4 bits appbits (using the same semantics) and
> mandate having first one byte header extensions terminated by a one byte
> header extension with ID 15 which in this case will not terminate the
> header extensions but signal the start of the two bytes header extension
> part.
> Does this looks reasonable
> Thanks
> Roni Even
> As individual
> _______________________________________________
> Audio/Video Transport Core Maintenance


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: