Subscribers request Tracks by sending a SUBSCRIBE (see Section 9.8) or FETCH (see Section 9.14) 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.
Publishers maintain a list of Established downstream subscriptions for
each Track. Relays use the Track Alias (Section 10.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 9.8), and delivered according
to the priority (see Section 7) and delivery timeout (see
Section 9.3.3).
A relay MUST NOT reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application specific information.
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 filter to avoid churn as downstream subscribers with disparate filters subscribe and unsubscribe from a Track.
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 9.9). 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.
8.4.1. Graceful Subscriber Relay Switchover
This section describes a behavior that a Subscriber MAY implement to improve user experience when a relay sends a GOAWAY or the Subscriber switches between networks, such as WiFi to Cellular, and QUIC Connection Migration is not possible.
When a subscriber receives the GOAWAY message, it starts the process
of connecting to a new relay and sending the SUBSCRIBE requests for
all Established subscriptions to the new relay. The new relay will send a
response to the subscribes and if they are successful, the subscriptions
to the old relay can be cancelled (see Section 3.3.1).