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

[Bernard Aboba <[e-mail]>]

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?

"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.

"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/)

"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?