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

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

On 07/09/2020 18:42, Magnus Westerlund via Datatracker wrote:

> However, I would
> prefer if some thought was spent on at least having a model for what
> information may be needed to be able to handle the media streams. Considering
> RFC 7656 (https://datatracker.ietf.org/doc/rfc7656/) and the work that was
> needed for us to up-level how RTP worked and even discuss this so that we
> understood each other. I think SFRAME needs to discuss how it is going to
> handle identification of the data encapsulated by SFRAMEs for media. A single
> media source can be encoded in multiple formats. Each format may produce one or
> more sub-streams of encoding for scalability or robustness and this needs to
> conveyed.


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

Any further identification or metadata required must be performed at RTP 
level:

This working group will, however, define how SFrame interacts with RTP (e.g., with
regard to packetization, depacketization, and recovery algorithms) to ensure
that it can be used in environments such as WebRTC.

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?

> So looking at the above challenges in the context of SFRAME over RTP. So a
> possibility here is to say that the SSRC represents either just a media source.

In no way SFRAME should be required to have knowledge about SSRCS.

> The RTP payload format provides only fragmentation of the SFRAME across
> multiple RTP packets and the RTP timestamp can be used to indicate its
> belonging in the timeline of the encoding. That puts a lot of the
> identification on the SFRAME layer, but its minimizes the signalling
> interactions related to RTP. However it creates limitation about what the SFU
> can do, especially when it comes to repair. Switching can be done based on
> Frame-marker extension header. However, layer related loss detection becomes
> impossible without additional information, or use of multiple SSRCs.

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.

Best regards

Sergio