An MOQT scope is a set of servers (as identified by their connection URIs) for which a Full Track Name is guaranteed to be unique and identify a specific track. It is up to the application using MOQT to define how broad or narrow the scope is. An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs.
A single MOQT transport session is tied to the scope that is negotiated in the
beginning of the session. Unless the application has additional information,
two tracks are assumed to belong to the same scope if and only if the
authority and path-abempty components (Section 6.1) of their
connection URIs are equal. These values are communicated through the SETUP
message in case of raw QUIC, and through HTTP request header fields in case of
WebTransport.
The query component of the connection URI is not part of the scope; two
connection URIs that differ only in their query components identify the same
scope.
Because each Full Track Name is unique within an MOQT scope, they can be used as a cache key for the track. If, at a given moment in time, two tracks within the same scope contain different data, they MUST have different names and/or namespaces. MOQT provides subscribers with the ability to alter the specific manner in which tracks are delivered via Parameters, but the actual content of the tracks does not depend on those parameters; this is in contrast to protocols like HTTP, where request headers can alter the server response.
A publisher that loses state (e.g. crashes) and intends to resume publishing on the same Track risks colliding with previously published Objects and violating the above requirements. A publisher can handle this in application specific ways, for example:
-
Select a unique Track Name or Track Namespace whenever it resumes publishing. For example, it can base one of the Namespace Fields on the current time, or select a sufficiently large random value.
-
Resume publishing under a previous Track Name and Namespace and set the initial Group ID to a unique value guaranteed to be larger than all previously used groups. This can be done by choosing a Group ID based on the current time.
-
Use TRACK_STATUS or similar mechanism to query the previous state to determine the largest published Group ID.