Publishing through the relay starts with publisher sending ANNOUNCE
control message with a Track Namespace (Section 2.4).
The ANNOUNCE enables the relay to know which publisher to forward a
SUBSCRIBE to.
Relays MUST verify that publishers are authorized to publish the content associated with the set of tracks whose Track Namespace matches the announced namespace. Where the authorization and identification of the publisher occurs depends on the way the relay is managed and is application specific.
A Relay can receive announcements from multiple publishers for the same Track Namespace and it SHOULD respond with the same response to each of the publishers, as though it was responding to an ANNOUNCE from a single publisher for a given track namespace.
When a publisher wants to stop new subscriptions for an announced namespace it sends an UNANNOUNCE. A subscriber indicates it will no longer route subscriptions for a namespace it previously responded ANNOUNCE_OK to by sending an ANNOUNCE_CANCEL.
A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace. This MUST use an exact match on track namespace unless otherwise negotiated by the application. For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar.
When a relay receives an incoming SUBSCRIBE request that triggers an upstream subscription, it SHOULD send a SUBSCRIBE request to each publisher that has announced the subscription's namespace, unless it already has an active subscription for the Objects requested by the incoming SUBSCRIBE request from all available publishers.
When a relay receives an incoming ANNOUNCE for a given namespace, for each active upstream subscription that matches that namespace, it SHOULD send a SUBSCRIBE to the publisher that sent the ANNOUNCE.
OBJECT message headers carry a short hop-by-hop Track Alias that maps to
the Full Track Name (see Section 7.15). Relays use the
Track Alias of an incoming OBJECT message to identify its track and find
the active subscribers for that track. Relays MUST forward OBJECT messages to
matching subscribers in accordance to each subscription's priority, group order,
and delivery timeout.
6.2.1. Graceful Publisher Network Switchover
This section describes behavior that a publisher MAY choose to implement to allow for a better users experience when switching between networks, such as WiFi to Cellular or vice versa.
If the original publisher detects it is likely to need to switch networks, for example because the WiFi signal is getting weaker, and it does not have QUIC connection migration available, it establishes a new session over the new interface and sends an ANNOUCE. The relay will forward matching subscribes and the publisher publishes objects on both sessions. Once the subscriptions have migrated over to session on the new network, the publisher can stop publishing objects on the old network. The relay will drop duplicate objects received on both subscriptions. Ideally, the subscriptions downstream from the relay do no observe this change, and keep receiving the objects on the same subscription.
6.2.2. Graceful Publisher Relay Switchover
This section describes behavior that a publisher MAY choose to implement to allow for a better user experience when a relay sends them a GOAWAY.
When a publisher receives a GOAWAY, it starts the process of connecting to a new relay and sends announces, but it does not immediately stop publishing objects to the old relay. The new relay will send subscribes and the publisher can start sending new objects to the new relay instead of the old relay. Once objects are going to the new relay, the announcement and subscription to the old relay can be stopped.