Code change:
6.7. <ins> A publisher issues a "SUBSCRIBE_FIN" message to all subscribers indicating it is done publishing objects on the subscribed track. The format of "SUBSCRIBE_FIN" is as follows: Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track. Final Object: The largest Object Sequence sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.8. A publisher issues a "SUBSCRIBE_RST" message to all subscribers indicating there wan an error publishing to the given track and subscription is terminated. The format of "SUBSCRIBE_RST" is as follows: Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). Error Code: Identifies an integer error code for subscription failure. Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track. Final Object: The largest Object Sequence sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.9. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is

Related discussion:
text: Cease the announcement This is an explicit signal from the publisher that it is no longer interested in sending media for the announced tracks. This is sent to the relay to trigger subscription cancellation downstream and clean up local relay state. Terminate the Subscription On subscribe end signal, each receiving entity will forward downstream and clean up local state. If it is the consumer, it stop media pipeline and so on. Unsubscribe For subscribers to explicitly indicate that they are no longer interested in a given track , they will send I am happy to write up a small PR as proposal if we think the general direction is fine.
What is the difference between Cancel the subscription and Unsubscribe?
Unsubscribe is an explicit action from the subscriber and Cancel is the signal from the publisher. May be we should call it ` instead ? I see cancel can be misleading
Got it. Terminate is better than Cancel.
We already have for the publisher to immediately terminate a subscription with a code/reason, so we could reuse that. However, the problem is when the termination occurs. The end of a broadcast would look like: There's a race, as the can arrive before the last objects due to retransmits or congestion control, severing the subscription early. Ideally we wait for all outstanding objects to get delivered and then terminate the subscription. In QUIC terminology, we need a in addition to our existing . The difficult part is determining which objects are still outstanding.
Do we want to distinguish a normal end of subscription (due to EOF), and an unexpected end (due to, e.g., a downstream server crashing)? We do that normally in QUIC (fin vs reset), so it might make sense to do that here.
Image the case where we have A sending to R sending to B. B subscribes to R. A sends ANNOUNCE to R. R subscribes to A. At this point media is flowing from A to R to B. A temporary looses WIFI connectivity and reconnects over 5G with new IP. A sends an ANNOUNCE to R, R subscribes to the new A and perhaps tries to send an error to original ANNOUNCE and end subscribe but A will not get that as that QUIC connection is gone.