Unclear on sequence of control message responses

[TimEvens]

Many control messages have a specific expected response that in some cases MUST happen before sending another control message involving the pending state of another, such as one relating to a namespace. It's unclear in the draft which messages require this and which do not.

For example the assumed behavior is shown below where the announce and announce_ok are exchanged before any other control message that would relate to that namespace.

sequenceDiagram
    participant P as Publisher
    participant R as "Relay/Server"

    P->>R: ANNOUNCE namespace=ABC
    R-->>P: ANNOUNCE_OK namespace=ABC    
    Note right of P: Ready for subscriptions to tracks

    R->>P: SUBSCRIBE (namespace=ABC, name=HDVideo)
    P-->>R: SUBSCRIBE_OK (ok for HDVideo)
    R->>P: SUBSCRIBE (namespace=ABC, name=SDVideo)
    R->>P: SUBSCRIBE (namespace=ABC, name=LRVideo)
    R->>P: SUBSCRIBE (namespace=ABC, name=AudioOpus)
    P-->>R: SUBSCRIBE_OK (ok for SDvideo)
    P-->>R: SUBSCRIBE_OK (ok for LRVideo)
    P-->>R: SUBSCRIBE_OK (ok for AudioOpus)

Below is the possible interpretability problem flow that could cause problems if not clearly articulated in MOQT. The below shows that the implementations assumes that the namespace is not available/exist unless it's been OK'd first. Any subscribes that arrive while pending OK result in error.

sequenceDiagram
    participant P as Publisher
    participant R as "Relay/Server"

    P->>R: ANNOUNCE namespace=ABC

    R->>P: SUBSCRIBE (namespace=ABC, name=HDVideo)
    P-->>R: SUBSCRIBE_ERROR (NOT EXIST)
    R->>P: SUBSCRIBE (namespace=ABC, name=SDVideo)
    P-->>R: SUBSCRIBE_ERROR (NOT EXIST)
    R->>P: SUBSCRIBE (namespace=ABC, name=LRVideo)
    P-->>R: SUBSCRIBE_ERROR (NOT EXIST)
    R->>P: SUBSCRIBE (namespace=ABC, name=AudioOpus)
    P-->>R: SUBSCRIBE_ERROR (NOT EXIST)
    R-->>P: ANNOUNCE_OK namespace=ABC    

    Note right of P: Sadly now we are ready to accept subscriptions

What I would like to see is that we should accept subscriptions while waiting for the announce OK. The fact that the subsription was sent by the relay indicates that an OK will follow at some point. Maybe the implementation will hold off on actually sending data for those subscribes till it gets the announce OK, but at least it will accept those subscribes so that the relay doesn't have to subscribe in trial and error fashion.

I use the ANNOUNCE flow as an example above, but the problem in MOQT not clearly defining the flows of requests and responses allowed prior to other requests exposes interpretability challenges.

For example, SUBSCRIBE_DONE is not clearly defined as informational, but it appears that it is. SUBSCRIBE_DONE is a way for the publisher to indicate it's done sending on a track (namespace + name = fullname = track alias), but there is no mention that an UNSUBSCRIBE should be issued in response to that. The lack of sending the unsubscribe means that the relay will still have state that the subscription is still active with the publisher regardless of the publisher sending SUBSCRIBE_DONE.

If or when the publisher decides to send again on the track the subscription is still valid and should resume as it was before. But that's a BIG IF as some implementers may treat sending a SUBSCRIBE_DONE as if it equaled UNSUBSCRIBE... hence requiring the relay/server to subscribe again after the SUBSCRIBE_DONE. This is not good for interoperability.

An example of how this could become a real-world problem is when a user disables their camera for a little while, which results in the publisher sending a SUBSCRIBE _DONE, but then shortly later the user enables the camera...

[fluffy]

I think I would describe this as we have a race condition between ANNOUCE_OK and SUBSCRIBE for something in that namespace. I think the spec should be clear that once an ANNOUCE is sent, the publisher MUST be ready to respond to a SUBSCRIBE even if that arrives before the ANNOUCE_OK. Would that resolve what you are getting at here ?

[vasilvv]

At least when initially proposed, ANNOUNCE was meant to be declarative message for the peer to indicate what namespaces it has, with implication that the subscriber could just subscribe to the announced tracks if it were aware of them existing. From that perspective

the implementations assumes that the namespace is not available/exist unless it's been OK'd first

is not correct behavior. We should probably be clearer about that in the text.

[ianswett]

Closing this as a duplicate of #402 which should resolve this as well.