There are two ways to publish through a relay:
-
Send a PUBLISH message for a specific Track to the relay. The relay MAY respond with PUBLISH_OK in Forward State=0 until there are known subscribers for new tracks.
-
Send an ANNOUNCE message for a Track Namespace to the relay. This enables the relay to send SUBSCRIBE messages to publishers for Tracks in this Namespace in response to received SUBSCRIBE messages.
Relays MUST verify that publishers are authorized to publish the set of tracks whose Track Namespace matches the namespace in an ANNOUNCE, or the Full Track Name in PUBLISH. The authorization and identification of the publisher depends on the way the relay is managed and is application specific.
A Relay can receive announcements for the same Track Namespace or PUBLISH messages for the same Track from multiple publishers and is expected to treat them uniformly.
When a publisher wants to stop new subscriptions for an announced namespace it sends an UNANNOUNCE. A subscriber indicates it will no longer subcribe to tracks in 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 or Full Track Name. Prefix matching is used to determine which publishers receive a SUBSCRIBE or which subscribers receive a PUBLISH. For example, a SUBSCRIBE namespace=(foo,bar), track=x message will be forwarded to the sessions that sent ANNOUNCE namespace=(foo) and ANNOUNCE namespace=(foo, bar) respectively, but not one that sent ANNOUNCE namespace=(foobar). Relays MUST forward SUBSCRIBE messages to all publishers and ANNOUNCE and PUBLISH messages to all subscribers that have a namespace prefix match.
When a relay receives an incoming SUBSCRIBE that triggers an upstream subscription, it SHOULD send a SUBSCRIBE request to each publisher that has announced the subscription's namespace or prefix thereof, unless it already has an active subscription for the Objects requested by the incoming SUBSCRIBE request from all available publishers. If it already has a matching upstream subscription in Forward State=0, it SHOULD send a SUBSCRIBE_UDPATE with Forward=1 to all publishers.
When a relay receives an incoming PUBLISH message, it MUST send a PUBLISH request to each subscriber that has subscribed (via SUBSCRIBE_ANNOUNCES) to the track's namespace or prefix thereof.
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. When it receives an incoming PUBLISH message for a track that has active subscribers, it SHOULD respond with PUBLISH_OK with Forward State=1.
Relays use the Track Alias (Section 9.1) of an incoming Object to identify its track and find the active subscribers. Relays MUST forward Objects to matching subscribers in accordance to each subscription's priority, group order, and delivery timeout.
If an upstream session is closed due to an unknown or invalid control message or Object, the relay MUST NOT continue to propagate that message or Object downstream, because it would enable a single session to close unrelated sessions.
7.3.1. Graceful Publisher Network Switchover
This section describes a behavior that a publisher MAY choose to implement to allow for a better user 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 ANNOUNCE and/or PUBLISH messages. The relay will establish subscriptions 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.
7.3.2. Graceful Publisher Relay Switchover
This section describes a 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 ANNOUNCE and/or PUBLISH messages, but it does not immediately stop publishing objects to the old relay. The new relay will establish subscriptions 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 announcements and subscriptions to the old relay can be withdrawn or terminated.