Code change:
control of packetization and transmission, with addtional support for retransmission as an optional extension. <ins> To provide an overview of interactive use cases, we can consider a conferencing session comprised of: Multiple emitters, publishing on multiple tracks (audio, video tracks and at different qualities) A media switch, sourcing tracks that represent a subset of tracks from across all the emitters.  Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. Multiple receivers, with varied receiving capacity (bandwidth limited), subscribing to subset of the tracks This setup relies on the following functionalities: Media Switches source new tracks but retain the media payload from the original emitters.  This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. Media Switches propagate a subset of tracks as-is from the emitters to the subscribers.  This implies Track IDs to be unchanged between the emitters and the receivers. Subscribers explictly request one or more media tracks in appropriate qualities and dynamically move between the qualtiies during the course of the session. Another topology for the conferencing use-case is to use multiple distribution networks for delivering the media, with media switching functionality running across distribution networks and these media functions as part of the core distribution network as shown below. Such a topology needs to meet all the properties listed in the homogenous topology setup, however having multiple distribution networks, and relying on the distribution networks to carry out the media delivery, brings in further requirements towards a data model that enables tracks to be uniquely identifiable across the distribution networks and not just within a single distribution network. </ins> 3.1.1. In this use case the computation for running a video game (single or

Related discussion:
text: Are there scenarios in which it would be useful to be able to ingest multiple MediaStreamTracks (either audio or video)? I ask because the RUSH draft doesn't support ingestion of multiple tracks and I've been told that this is a problem by some customers. Section 2.4 A media switch, sourcing tracks that represent a subset of tracks from across all the emitters. Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. [BA] The use of the term "media switch" suggests to me that it is forwarding tracks, rather than sourcing (e.g. transcoding) them. Can you clarify? subscribing to subset of the tracks [BA] I think there may be an implicit assumption here, which is that the receiver only indicates the track it wishes to subscribe to, rather than indicating the quality it wishes to receive. Above setup brings in following properties on the data model for the transport protocol [BA] The paragraphs that follow appear to describe different ways that the system could be implemented, rather than "properties on the data model". Do you mean to say that the design should be able to handle any of the approaches described? Media Switches to source new tracks but retain media payload from the original emitters. This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. [BA] Is the term "source new tracks" implied by changing the Track IDs? If the payload is retained, this seems like forwarding to me, rather than "sourcing new tracks". Media Switches to propogate subset of tracks as-is from the emitters to the subscribers. This implies Track IDs to be unchanged between the emitters and the receivers. [BA] What does "as-is" mean here? Are you referring only the lack of a change in the "Track ID"? If the switch drops some frames in order to reduce quality (and bandwidth consumption) is it still "as-is"? Subscribers to explictily request multiple appropriate qualities and dynamically move between the qualtiies during the course of the session [BA] Is it a goal to be able to support such a "receiver driven" approach, as well as the other two approaches, which are sender driven?