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 on a Subgroup stream whose Object ID is not strictly larger than the previous Object received on the same Subgroup.
-
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.
-
A Subgroup or FETCH response is terminated with a FIN in the middle of an Object
-
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 from the
Track and SHOULD deliver an error to the application. If a relay detects a
Malformed Track, it MUST immediately terminate downstream subscriptions with
SUBSCRIBE_DONE 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 Name and Track Namespace 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 Subscribe 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.