SUBSCRIBE_DONE

A publisher sends a SUBSCRIBE_DONE message to indicate it is done publishing Objects for that subscription. The Status Code indicates why the subscription ended, and whether it was an error. Because SUBSCRIBE_DONE is sent on the control stream, it is likely to arrive at the receiver before late-arriving objects, and often even late-opening streams. However, the receiver uses it as an indication that it should receive any late-opening streams in a relatively short time.

Note that some objects in the subscribed track might never be delivered, because a stream was reset, or never opened in the first place, due to the delivery timeout.

A sender MUST NOT send SUBSCRIBE_DONE until it has closed all streams it will ever open, and has no further datagrams to send, for a subscription. After sending SUBSCRIBE_DONE, the sender can immediately destroy subscription state, although stream state can persist until delivery completes. The sender might persist subscription state to enforce the delivery timeout by resetting streams on which it has already sent FIN, only deleting it when all such streams have received ACK of the FIN.

A sender MUST NOT destroy subscription state until it sends SUBSCRIBE_DONE, though it can choose to stop sending objects (and thus send SUBSCRIBE_DONE) for any reason.

A subscriber that receives SUBSCRIBE_DONE SHOULD set a timer of at least its delivery timeout in case some objects are still inbound due to prioritization or packet loss. The subscriber MAY dispense with a timer if it sent UNSUBSCRIBE or is otherwise no longer interested in objects from the track. Once the timer has expired, the receiver destroys subscription state once all open streams for the subscription have closed. A subscriber MAY discard subscription state earlier, at the cost of potentially not delivering some late objects to the application. The subscriber SHOULD send STOP_SENDING on all streams related to the subscription when it deletes subscription state.

The format of SUBSCRIBE_DONE is as follows:

SUBSCRIBE_DONE Message {
  Type (i) = 0xB,
  Length (i),
  Request ID (i),
  Status Code (i),
  Stream Count (i),
  Error Reason (Reason Phrase)
}

• Request ID: The Request ID of the subscription that is being terminated. See Section 8.7.

• Status Code: An integer status code indicating why the subscription ended.

• Stream Count: An integer indicating the number of data streams the publisher opened for this subscription. This helps the subscriber know if it has received all of the data published in this subscription by comparing the number of streams received. The subscriber can immediately remove all subscription state once the same number of streams have been processed. If the track had Forwarding Preference = Datagram, the publisher MUST set Stream Count to 0. If the publisher is unable to set Stream Count to the exact number of streams opened for the subscription, it MUST set Stream Count to 2^62 - 1. Subscribers SHOULD use a timeout or other mechanism to remove subscription state in case the publisher set an incorrect value, reset a stream before the SUBGROUP_HEADER, or set the maximum value. If a subscriber receives more streams for a subscription than specified in Stream Count, it MAY close the session with a Protocol Violation.

• Error Reason: Provides the reason for subscription error. See Section 1.3.3.

The application SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below:

• Internal Error - An implementation specific or generic error occurred.

• Unauthorized - The subscriber is no longer authorized to subscribe to the given track.

• Track Ended - The track is no longer being published.

• Subscription Ended - The publisher reached the end of an associated Subscribe filter.

• Going Away - The subscriber or publisher issued a GOAWAY message.

• Expired - The publisher reached the timeout specified in SUBSCRIBE_OK.

• Too Far Behind - The publisher's queue of objects to be sent to the given subscriber exceeds its implementation defined limit.