There are multiple ways a publisher can transmit a Track that does not conform to MOQT constraints. Such a Track is considered malformed. Some example conditions that constitute a malformed track when detected by a receiver include:
-
An Object is received in a FETCH response with the same Group as the previous Object, but whose Object ID is not strictly larger than the previous object.
-
An Object is received in an Ascending FETCH response whose Group ID is smaller than the previous Object in the response.
-
An Object is received in a Descending FETCH response whose Group ID is larger than the previous Object in the resopnse.
-
An Object is received whose Object ID is larger than the final Object in the Subgroup. The final Object in a Subgroup is the last Object received on a Subgroup stream before a FIN.
-
A Subgroup is received with two or more different final Objects.
-
An Object is received in a Group whose Object ID is larger than the final Object in the Group. The final Object in a Group is the Object with Status END_OF_GROUP or the last Object sent in a FETCH that requested the entire Group.
-
An Object is received on a Track whose Group and Object ID are larger than the final Object in the Track. The final Object in a Track is the Object with Status END_OF_TRACK or the last Object sent in a FETCH whose response indicated End of Track.
-
The same Object is received more than once with different Payload or other immutable properties.
-
An Object is received with a different Forwarding Preference than previously observed from the same Track.
The above list of conditions is not considered exhaustive.
When a subscriber detects a Malformed Track, it MUST UNSUBSCRIBE any
subscription and FETCH_CANCEL any fetch for that Track from that publisher, and
SHOULD deliver an error to the application. If a relay detects a Malformed
Track, it MUST immediately terminate downstream subscriptions with PUBLISH_DONE
and reset any fetch streams with Status Code MALFORMED_TRACK.
2.5.1. Scope
An MOQT scope is a set of servers (as identified by their connection URIs) for which the tuple of Track Namespace and Track Name are 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.
Because the tuple of Track Namespace and Track Name are 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 tuple 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.