]> Ozyegin University

zafer.gurel@ozu.edu.tr

Networked Media

ali.begen@networked.media

Applications and Real-Time MOQ Internet-Draft This document defines a solution for switching tracks in media. More particularly, the solution provides a seamless switching that ensures there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other.

Introduction This document outlines a solution for switching tracks in media delivery over Media Over QUIC Transport (MOQT) . Switching tracks is necessary for a variety of reasons, such as changing the quality, the language of the media, or the type of the media (e.g., switching from a video to an audio track). The solution described in this document ensures that there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other.

Terms and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Client:

The party initiating a MoQ transport session.

Server:

The party accepting an incoming transport session.

Endpoint:

A Client or Server.

Producer:

An endpoint sending media over the network.

Consumer:

An endpoint receiving media over the network.

Transport session:

A raw QUIC connection or a WebTransport session.

Congestion:

Packet loss and queuing caused by degraded or overloaded networks.

Group:

A temporal sequence of objects. A group represents a join point in a track.

Object:

An object is an addressable unit whose payload is a sequence of bytes.

Track:

An encoded bitstream. Tracks contain a sequential series of one or more groups and are the subscribable entity with MOQT.

Notational Conventions This document uses the conventions detailed in () when describing the binary encoding. As a quick reference, the following list provides a non-normative summary of the parts of RFC9000 field syntax that are used in this specification.

x (L):

Indicates that x is L bits long

x (i):

Indicates that x holds an integer value using the variable-length encoding as described in ()

x (..):

Indicates that x can be any length including zero bits long. Values in this format always end on a byte boundary.

x (L) ...:

Indicates that x is repeated zero or more times and that each instance has a length of L

This document extends the RFC9000 syntax and with the additional field types:

x (b):

Indicates that x consists of a variable length integer encoding as described in (), followed by that many bytes of binary data

To reduce unnecessary use of bandwidth, variable length integers SHOULD be encoded using the least number of bytes possible to represent the required value.

Switching Tracks In MOQT communications, the publisher announces the availability of multiple encodings of a media content in different tracks, which are alternatives of each other and indicated so in the catalog . The subscriber subscribes to one of the tracks from an altGroup in the catalog. During the session, the subscriber may switch from a currently consumed track to any other alternate track from the catalog due to, for example, changes in available bandwidth. To do this, the subscriber can subscribe to a new track and unsubscribe from the old track. Such an action is done by sending a SUBSCRIBE message to the relay. An example of the different tracks indicated in the catalog is shown below.

An example of the different tracks.

The Problem and Solution Approaches Relays do not have access/visibility to the catalog. Therefore, they are unaware when two tracks are alternates. An example of the existing SUBSCRIBE message format is shown below.

MOQT SUBSCRIBE message.

Existing SUBSCRIBE message that the subscriber transmits to the relay only contains information of the current track and does not indicate that the client is switching to a new track for the same media content. Therefore, when receiving a SUBSCRIBE message from the subscriber for switching to the new track, the relay may download and transmit both the new track and the old track of the same media content, which can create a bitrate spike and in turn can aggravate an already congested link. Additionally, the player/client application on the subscriber will have to process (e.g., parse and decode) the same media content in overlapping times, which is a waste of computational power.

Solution 1 (altTrackGroup) A new parameter altTrackGroup can be added to every SUBSCRIBE message. altTrackGroup is the identifier for a group of alternative tracks within the scope of a track namespace. The value of the altTrackGroup identifier may be the same as the altGroup identifier used in the catalog or a different one. An example of a SUBSCRIBE message that includes the identifier altTrackGroup is shown below.

MOQT SUBSCRIBE message with altTrackGroup.

Solution 2 (Switch Track Alias) The SUBSCRIBE message can contain an identifier Switch Track Alias such that the Switch Track Alias = Track Alias of the active subscription. This way, this ID in the SUBSCRIBE message can indicate to the relay that this switching request is for an alternative track of the same media content of the current track and assists the relay in seamless switching. An example of a SUBSCRIBE message that includes the identifier Switch Track Alias is shown below.

MOQT SUBSCRIBE message with Switch Track Alias.

Security Considerations TODO: Expand this section.

IANA Considerations TODO: Expand this section.

References Normative References Discord Meta Cisco Google Google This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Cisco Akamai Cisco This specification defines a Common Catalog specification for streaming formats implementing the MOQ Transport Protocol [MoQTransport]. Media over QUIC Transport (MOQT) defines a publish/ subscribe based unified media delivery protocol for delivering media for streaming and interactive applications over QUIC. The catalog describes the content made available by a publisher, including information necessary for subscribers to select, subscribe and initialize tracks. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.