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

"Roni Even" <> Fri, 11 September 2015 10:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 495C81B4296 for <>; Fri, 11 Sep 2015 03:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uanxi4HbVkvp for <>; Fri, 11 Sep 2015 03:47:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AB2E1B3D09 for <>; Fri, 11 Sep 2015 03:47:55 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so59544783wic.0 for <>; Fri, 11 Sep 2015 03:47:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=pJXRYkCipuqFVSlqBVA5V8WC7DKRiybQNwvtdNqG8k4=; b=BtZX9FQd7g+6zRW+rr2CN+KDBqnWpN4aex/UR2v0bYz5P6GnQZO6Ay2xiW44tGwBeB wf7DaMNjIzF+g2IKaK3YZK/kJOljamYulKF4WrSjetwczGwaMJlkrcCMaw2emLh6vic3 0ghhqO20YFyuMeqUNUPPVWoZMyJJsgzzAza/3rBsZHiTN7anM74eYJlYNh/+zH5Sqc9G hdxrQqQ2LxzbTA8Meef7RQoeIFFpk8Kl7v3NMoa8H+bqqw8U94kcKpZOsK0rGHJx1W30 V+u68aQLBTR+frQOt72PSgozeyoAS6T27jGH/Q8e58EU/SstCFD1M115AteMRgDBqtr7 ii0w==
X-Received: by with SMTP id n7mr77047607wjf.112.1441968473811; Fri, 11 Sep 2015 03:47:53 -0700 (PDT)
Received: from RoniPC ( []) by with ESMTPSA id ub7sm1670119wib.17.2015. (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Sep 2015 03:47:53 -0700 (PDT)
From: "Roni Even" <>
To: "'Magnus Westerlund'" <>, <>
References: <04a801d0ec69$aec10170$0c430450$> <>
In-Reply-To: <>
Date: Fri, 11 Sep 2015 13:47:46 +0300
Message-ID: <04b001d0ec7f$4c4338e0$e4c9aaa0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIRWn3/ymKxYe3VDbMo/U5aoeH03gGExYP3naofNvA=
Content-Language: he
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 10:47:57 -0000

Hi Magnus,

-----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. 

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. 


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: