Some messages include a Parameters field that encode optional message elements. They contain a type, length, and value.
Senders MUST NOT repeat the same parameter type in a message. Receivers SHOULD check that there are no duplicate parameters and close the session as a 'Protocol Violation' if found.
Receivers ignore unrecognized parameters.
The format of Parameters is as follows:
Parameter {
Parameter Type (i),
Parameter Length (i),
Parameter Value (..),
}
Parameter Type is an integer that indicates the semantic meaning of the parameter. Setup message parameters use a namespace that is constant across all MoQ Transport versions. All other messages use a version-specific namespace. For example, the integer '1' can refer to different parameters for Setup messages and for all other message types.
SETUP message parameter types are defined in Section 7.2.2. Version- specific parameter types are defined in Section 7.1.1.
The Parameter Length field of the String Parameter encodes the length of the Parameter Value field in bytes.
Each parameter description will indicate the data type in the Parameter Value field. If a receiver understands a parameter type, and the parameter length implied by that type does not match the Parameter Length field, the receiver MUST terminate the session with error code 'Parameter Length Mismatch'.
7.1.1. Version Specific Parameters
Each version-specific parameter definition indicates the message types in which it can appear. If it appears in some other type of message, it MUST be ignored. Note that since Setup parameters use a separate namespace, it is impossible for these parameters to appear in Setup messages.
7.1.1.2. DELIVERY TIMEOUT Parameter
The DELIVERY TIMEOUT parameter (Parameter Type 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message. It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received. The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference. There is no explicit signal that an Object was not sent because the delivery timeout was exceeded.
If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription. The publisher SHOULD always specify the value received from an upstream subscription when there is one, and nothing otherwise. If an earlier Object arrives later than subsequent Objects, relays can consider the receipt time as that of the next later Object, with the assumption that the Object's data was reordered.
If neither the subscriber or publisher specify DELIVERY TIMEOUT, all Objects in the track matching the subscription filter are delivered as indicated by their Group Order and Priority. If a subscriber exceeds the publisher's resource limits by failing to consume objects at a sufficient rate, the publisher MAY terminate the subscription with error 'Too Far Behind'.
If an object in a subgroup exceeds the delivery timeout, the publisher MUST reset the underlying transport stream (see Section 8.4.2).
When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay that intends to serve multiple subscriptions for the same track.
Publishers SHOULD consider whether the entire Object is likely to be delivered before sending any data for that Object, taking into account priorities, congestion control, and any other relevant information.
7.1.1.3. MAX CACHE DURATION Parameter
MAX_CACHE_DURATION (Parameter Type 0x04): An integer expressing a number of milliseconds. If present, the relay MUST NOT start forwarding any individual Object received through this subscription after the specified number of milliseconds has elapsed since the beginning of the Object was received. This means Objects earlier in a multi-object stream will expire earlier than Objects later in the stream. Once Objects have expired, their state becomes unknown, and a relay that handles a subscription that includes those Objects re-requests them.