Subscriber Interactions

Subscribers request Tracks by sending a SUBSCRIBE (see Section 10.7) or FETCH (see Section 10.12) control message for each Track of interest. Relays MUST ensure subscribers are authorized to access the content associated with the Track. The authorization information can be part of request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification.

The relay MUST have an Established upstream subscription before sending SUBSCRIBE_OK in response to a downstream SUBSCRIBE. If a relay does not have sufficient information to send a FETCH_OK immediately in response to a FETCH, it MUST withhold sending FETCH_OK until it does. Relays MUST follow the constraints on LARGEST_OBJECT defined in Section 10.2.16.

Publishers maintain a list of Established downstream subscriptions for each Track. Relays use the Track Alias (Section 11.1) of an incoming Object to identify its Track and find the current subscribers. Each new Object belonging to the Track is forwarded to each subscriber, as allowed by the subscription's filter (see Section 10.7), and delivered according to the priority (see Section 7) and delivery timeout (see Section 8).

A relay MUST NOT reorder or drop objects received on a multi-object stream when forwarding to subscribers.

Relays MAY aggregate authorized subscriptions for a given Track when multiple subscribers request the same Track. Subscription aggregation allows relays to make only a single upstream subscription for the Track. The published content received from the upstream subscription request is cached and shared among the pending subscribers. Because MOQT restricts widening a subscription, relays that aggregate upstream subscriptions can subscribe using the Largest Object Location filter to avoid churn as downstream subscribers with disparate filters subscribe and unsubscribe from a Track. Aggregating subscriptions can also help relays conserve resources especially with disparate filters or SUBSCRIBE_TRACKS in a namespace with a large number of Tracks (see Section 6.3.1).

A subscriber remains subscribed to a Track at a Relay until it unsubscribes, the upstream publisher terminates the subscription, or the subscription expires (see Section 10.8). A subscription with a filter can reach a state where all possible Objects matching the filter have been delivered to the subscriber. Since tracking this can be prohibitively expensive, Relays are not required or expected to do so.