§5.2.

Announcements

A publisher MAY send ANNOUNCE messages to any subscriber. An ANNOUNCE indicates to the subscriber that the publisher has tracks available in that namespace. A subscriber MAY send SUBSCRIBE or FETCH for tracks in a namespace without having received an ANNOUNCE for it.

If a publisher is authoritative for a given namespace, or is a relay that has received an authorized ANNOUNCE for that namespace from an upstream publisher, it MUST send an ANNOUNCE to any subscriber that has subscribed to ANNOUNCE for that namespace, or a more generic set including that namespace. A publisher MAY send the ANNOUNCE to any other subscriber.

An endpoint SHOULD NOT, however, send an ANNOUNCE advertising a namespace that exactly matches a namespace for which the peer sent an earlier ANNOUNCE (i.e. an ANNOUNCE ought not to be echoed back to its sender).

The receiver of an ANNOUNCE_OK or ANNOUNCE_ERROR SHOULD report this to the application to inform the search for additional subscribers for a namespace, or abandoning the attempt to publish under this namespace. This might be especially useful in upload or chat applications. A subscriber MUST send exactly one ANNOUNCE_OK or ANNOUNCE_ERROR in response to an ANNOUNCE. The publisher SHOULD close the session with a protocol error if it receives more than one.

An UNANNOUNCE message withdraws a previous ANNOUNCE, although it is not a protocol error for the subscriber to send a SUBSCRIBE or FETCH message for a track in a namespace after receiving an UNANNOUNCE.

A subscriber can send ANNOUNCE_CANCEL to revoke acceptance of an ANNOUNCE, for example due to expiration of authorization credentials. The message enables the publisher to ANNOUNCE again with refreshed authorization, or discard associated state. After receiving an ANNOUNCE_CANCEL, the publisher does not send UNANNOUNCE.

While ANNOUNCE indicates to relays how to connect publishers and subscribers, it is not a full-fledged routing protocol and does not protect against loops and other phenomena. In particular, ANNOUNCE SHOULD NOT be used to find paths through richly connected networks of relays.

A subscriber MAY send a SUBSCRIBE or FETCH for a track to any publisher. If it has accepted an ANNOUNCE with a namespace that exactly matches the namespace for that track, it SHOULD only request it from the senders of those ANNOUNCE messages.

This is one section of the MoQT specification, rendered per-section for quick reference and citation. The authoritative text is draft-ietf-moq-transport-13 at the IETF.