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

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Wed, 31 July 2013 15:12 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0D321F9B53; Wed, 31 Jul 2013 08:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crxvJhCYbkC6; Wed, 31 Jul 2013 08:12:03 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 14F3021F9B5B; Wed, 31 Jul 2013 08:12:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2567; q=dns/txt; s=iport; t=1375283523; x=1376493123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vGBY5Jhpd5WRoEd+yQYLrG/ATVpelP2Al+Fq9xjb2BM=; b=jG9gYusNqdzf/NyougxhmhLaLJfSduNk+p7afyeRbcvBS4+uFmzVVnjT vsf4kxVOeljSHBDuW8I4npvqyxkDvyO5iqLQXZ2GqrBd+FWRxl2yJxqPV 13NPYt5983I8kl4oHzMRK7puBqv+/lmTlASIcquVrUeGhUZVSbXvHEdYB 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFAJgo+VGtJXG8/2dsb2JhbABRCoMGNVC+HYEYFnSCJAEBAQR3AgwEAgEIEQMBAgsZCzIdCAIEDgUIAYgHDLhxjkWBETEHBoMScwOIcpAWkCSBW4E5gio
X-IronPort-AV: E=Sophos;i="4.89,788,1367971200"; d="scan'208";a="241789237"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 15:12:02 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6VFC2tU001532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 15:12:02 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 10:12:02 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Adam Fineberg <fineberg@vline.me>
Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Thread-Index: AQHOiJCjF97CHVLHtESLPGspt4xmi5l0Hkhg
Date: Wed, 31 Jul 2013 15:12:01 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D4C75F3@xmb-rcd-x14.cisco.com>
References: <CE0F0BEB.9F95D%stewe@stewe.org>, <51EEA709.2020009@vline.me> <BLU169-W20CACC8554C875802188A3936F0@phx.gbl> <51F00A02.3060204@vline.me>
In-Reply-To: <51F00A02.3060204@vline.me>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.165.109]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 15:12:11 -0000

Hi Adam,

Why do you include PictureID? I can understand how the "Y" bit for base layer sync can be useful to include. But how does including PictureID help identify temporal layers?

Regards,
Mo

________________________________________
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

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.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message -------- 
Subject:
New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date:
Tue, 09 Jul 2013 10:02:05 -0700
From:
internet-drafts at ietf.org
To:
Adam Fineberg <fineberg at vline.com>



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
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


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

-- 
Regards,
Adam