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

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Aug 2013 16:12:35 -0700

Jonathan said: 
 
"Unfortunately, RTP doesn’t really let you do this.  The problem is that by just dropping packets without rewriting RTP sequence numbers or RTCP sender reports, this is going to look like enormous packet loss to RTP (which, in a sense, it is).  A middlebox like this – which is acting as a media-modifying RTP translator, in RTP terminology – needs to rewrite RTP headers and RTCP sender reports in order to keep the stream and its metadata consistent and valid. Is there something I’m missing here?" [BA] Your statement assumes that all the layers are sent on the same SSRC. (which is how I believe VP8 does it).    If the layers are sent on individual SSRCs (as can be done with H.264/SVC), then rewriting of sequence numbers or RTCP sender reports can be avoided.   There are some caveats though.  Typically there is still a need to indicate that layers are being dropped; if this is handled in RTP, then an SEI message needs to be inserted, so there will still be some encrypt/decrypt operations.                                                                                                                                                                                                                                                           From: Adam Fineberg [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 6:37 PM
To: [email-masked]
Subject: [avtext] 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 middlebox needs to have acesss 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 [email-masked]

-------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txtDate: Tue, 09 Jul 2013 10:02:05 -0700From: [email-masked]: Adam Fineberg <[email-masked]> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txthas been successfully submitted by Adam Fineberg and posted to theIETF repository. Filename:       draft-fineberg-avtext-temporal-layer-extRevision:       00Title:          A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer InformationCreation date:  2013-07-08Group:          Individual SubmissionNumber of pages: 6URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txtStatus:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-extHtmlized:        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.                                                                                     The IETF Secretariat  
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Aug 2013 09:43:13 +0200

On 2013-08-23 01:12, Bernard Aboba wrote:
>  Jonathan said:
>  
> 
> "Unfortunately, RTP doesn’t really let you do this.  The problem is that
> by just dropping packets without rewriting RTP sequence numbers or RTCP
> sender reports, this is going to look like enormous packet loss to RTP
> (which, in a sense, it is).  A middlebox like this – which is acting as
> a media-modifying RTP translator, in RTP terminology – needs to rewrite
> RTP headers and RTCP sender reports in order to keep the stream and its
> metadata consistent and valid.
> 
>  
> 
> Is there something I’m missing here?"
> 
>  
> 
> [BA] Your statement assumes that all the layers are sent on the same
> SSRC. (which is how I believe VP8 does it).    If the layers are sent on
> individual SSRCs (as can be done with H.264/SVC), then rewriting of
> sequence numbers or RTCP sender reports can be avoided.   There are
> some caveats though.  Typically there is still a need to indicate that
> layers are being dropped; if this is handled in RTP, then an SEI message
> needs to be inserted, so there will still be some encrypt/decrypt
> operations. 
> 

Using SVC MST with multiple SSRCs and having the layer on and off
happening at a middlebox without RTP re-writing will still be strange to
the receiver. Turning off one stream is fine, it is turning it on again
that looks strange to the receiver unless these on and off events are
known to the receiver. Thus also in this case I  think rewriting the RTP
headers and ensure RTCP is matching what is actually needed.

Having receiver initiated leaving and joining of layers mitigates this
as it is that entity that performs the actions.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------