Re: [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

[Sergio Garcia Murillo <[e-mail]>]

On 08/09/2020 14:30, Bernard Aboba wrote:
> Sergio said:
>
> "SFRAME content should be treated just as an opaque payload and when used
> within RTP, there should no additional identification inside the SFRAME
> payload itself (except the ones strictly needed for encrypting/decrypting)."
> [BA] But the SFRAME content (RTCEncodedVideoFrame.data) isn't treated as opaque today, correct?
> I am thinking of the first three octets of data, which cannot be encrypted. Isn't that expected to contain the VP8 Payload Header?

We need to skip the first bytes of the VP8 frame because we a limitation 
on the chrome implementation of the insertable streams and due to the 
fact that we are using the vp8 packetizer and not a codec-agnostic 
packetization but the vp8 rtp one. Ideally, when using a codec agnostic 
packetizer, the whole frame payload should be feed into sframe and the 
result be treated as a black box.


> "What I think it is missing in the charter is define what will happen if
> we find that there is any piece missing in RTP to be able to use SFRAME
> with it. Should we produce them within this group or just write the
> requirements and liaise with the appropriate ietf group so they are
> completed there?"
> [BA] I think we have a decent idea of what kind of RTP info we are talking about.  Basically, this is the information used by the SFU in order to decide whether to forward or drop the packet.  The info is inserted before data within each RTP packet (e.g. VP8 payload descriptor and/or frame forwarding RTP header extension), correct?
> If so, this can be handled by a reference within the SFrame specifications.

My doubt is if we find that there is no suitable reference available, 
what should we do?


> "In no way SFRAME should be required to have knowledge about SSRCS."
> [BA] I think you mean that we don't want SSRCs to be used to identify the keys. As we saw in PERC this creates backwards compatibility issues in SFUs with respect to SSRC modification. But some "knowledge" of SSRCs is required in the system.
> An RTP packetizer needs to fill in the SSRC field in the RTP header, and this info will also be available to the depacketizer. Also, the RTCEncodedVideoFrameMetadata includes both SSRCs and CSRCs (see:https://w3c.github.io/webrtc-insertable-streams/)

Yes, my point is that the SSRCS/rids should not be used as metadata for 
SFRAME encryption/decryption as we have seen it causes issues with SFU 
functionality. Obviously the rtp layer would still need to handle it and 
we may need how to map simulcast/svc behavior with SFRAME operations (as 
it is already captioned on current draft).


> "There are several ways of performing that without imposing any
> limitations on the SFU. Some of which would require extra specification
> work, but I would not like to jump directly into the technical proposals
> while still discussing about the charter."
>
> [BA] I agree that this doesn't seem like a Charter issue. It is more about what information the SFU has available to it (e.g. RTP header, RTP header extensions and possibly a portion of the payload). Based on this information, the SFU needs to be able to decide whether to drop or forward an RTP packet or whether to attempt repair. However, from the SFU's point of view, the repair process operates normally, correct?


I agree.


Best regards

Sergio