If the subscriber is aware of a namespace of interest, it can send SUBSCRIBE_NAMESPACE or SUBSCRIBE_TRACKS to publishers/relays it has established a session with.
SUBSCRIBE_NAMESPACE requests namespace discovery: the publisher sends relevant NAMESPACE and NAMESPACE_DONE messages for namespaces matching the prefix, including echoing back Track Namespaces under the prefix that have been published to it.
SUBSCRIBE_TRACKS requests track subscriptions: the publisher sends PUBLISH messages for tracks within matching namespaces, excluding tracks published by the subscriber.
Either message with zero Track Namespace fields indicates the sender is interested in all namespaces or all tracks from the receiver, respectively.
The subscriber sends SUBSCRIBE_NAMESPACE or SUBSCRIBE_TRACKS on a new bidirectional stream and the publisher MUST send a single REQUEST_OK or REQUEST_ERROR as the first message on the bidirectional stream in response.
If a Subscription cannot be created because there are no available bidirectional streams, the Publisher sends a PUBLISH_BLOCKED message on the SUBSCRIBE_TRACKS response stream to indicate the Full Track Name of the Subscription that could not be established. The Publisher MUST NOT send a PUBLISH for a Track after PUBLISH_BLOCKED has been sent. The subscriber can instead issue a SUBSCRIBE to establish a subscription to that track.
The receiver of a REQUEST_OK or REQUEST_ERROR ought to forward the result to the application, so the application can decide which other publishers to contact, if any.
A SUBSCRIBE_NAMESPACE or SUBSCRIBE_TRACKS can be cancelled by closing the stream with either a FIN or RESET_STREAM. Cancelling SUBSCRIBE_TRACKS does not prohibit original publishers from sending further PUBLISH messages, but relays MUST NOT send any further PUBLISH messages to a client without knowing the client is interested in and authorized to receive the content.