Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard Aboba <> Thu, 18 July 2013 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9671A21F9A05 for <>; Wed, 17 Jul 2013 20:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IGCL-Cd28uNr for <>; Wed, 17 Jul 2013 20:27:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BFA1E21F92C2 for <>; Wed, 17 Jul 2013 20:27:00 -0700 (PDT)
Received: from BLU169-W123 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 20:26:58 -0700
X-TMN: [6DYaeqNBSyq1ZK6x/N6CromwRGRfgS8a]
X-Originating-Email: []
Message-ID: <BLU169-W1238F58A9A258620DA2FE0F93620@phx.gbl>
Content-Type: multipart/alternative; boundary="_4899aed9-d0eb-4689-81a9-9545eb48347c_"
From: Bernard Aboba <>
To: Adam Fineberg <>, "" <>
Date: Wed, 17 Jul 2013 20:26:58 -0700
Importance: Normal
In-Reply-To: <>
References: <>
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jul 2013 03:26:58.0869 (UTC) FILETIME=[A92F8650:01CE8366]
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jul 2013 03:27:05 -0000

Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why 
 a VP8-specific RTP extension? 
Date: Wed, 17 Jul 2013 17:09:46 -0700
Subject: [rtcweb] Fwd: New Version Notification for	draft-fineberg-avtext-temporal-layer-ext-00.txt


    I'm working on
      WebRTC services and have found that while developing services that
      forward VP8 video streams if we want to take advantage of the VP8
      temporal scaling we must get the temporal layer information from
      the RTP header which requires us to decrypt the SRTP packets. This
      is undesirable both because the middle-box needs to have access to
      the keys as well as the because of the added overhead of the
      decrypt/encrypt cycle. This draft proposes an RTP header extension
      that will allow us to use the VP8 temporal layer information
      included in the header extension and therefore do forwarding
      without SRTP decryption. Comments welcome.
    Adam Fineberg
    fineberg at


      -------- Original Message --------
            New Version Notification for
            Tue, 09 Jul 2013 10:02:05 -0700

            Adam Fineberg <fineberg at


      A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6

   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.


rtcweb mailing list