Subject: Re: [Perc] [avtext] draft-ietf-avtext-framemarking and FEC

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 9 Mar 2017 19:06:07 +0000

Hi Bernard,

Adding PERC for your question on HBH vs E2E FEC/RTX. I expected HBH but don't think this has been discussed. Adding Emil and Boris as they plan to submit/present a PERC draft related to this (RTX).

Frame marking was intended for Source RTP Streams not Redundancy RTP Streams [RFC 7656]. I will update the draft to reflect this. If E2E encrypted redundancy streams need some type of marking, I would recommend a separate marking mechanism rather than overloading or extending the current video frame marking draft.

Thanks,
Mo

From: avtext <[email-masked]<mailto:[email-masked]>> on behalf of Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 1, 2017 at 3:10 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [avtext] draft-ietf-avtext-framemarking and FEC

So far, discussion on framemarking has focused on conveying information about video frames useful to an SFU.

In video forwarding scenarios, forward error correction can be used to protect one or more layers.

Today, typically robustness (FEC or RTX) is dealt with hop-by-hop, not end-to-end.  For example, FEC is consumed and re-generated by the SFU which receives video frames and repairs via the received FEC if it can.The SFU decides which video frames to forward (such as by using info in the frame marking header), and will regenerate an FEC stream corresponding to the forwarded stream.

My question is whether hop-by-hop robustness is expected to continue with PERC so that the payloads of FEC packets would be available to the SFU, or whether FEC payload would also be encrypted so that FEC would be end-to-end.

If FEC becomes end-to-end, do those packets also need to be marked?