2.3 KiB
provider-stream-policy Specification
Purpose
TBD - created by archiving change phase3c-provider-stream-policy. Update Purpose after archive.
Requirements
Requirement: Provider work carries the effective stream policy
Authenticated ProviderSessionWork SHALL carry the immutable policy version and its effective resolution, frame rate, codec, target bitrate, and audio-enabled decision.
Scenario: Gateway receives an effective policy
- WHEN the Server issues provider work for an admitted session
- THEN the work identifies the policy version and includes the effective bounded stream-policy values
Requirement: Stream-policy bindings share one strict contract
Generated Go, Rust, and Swift bindings MUST reject missing, unknown, out-of-range, or unsupported stream-policy wire values according to the canonical schema.
Scenario: Invalid policy is rejected consistently
- WHEN provider work contains an unknown codec or a value outside the canonical bounds
- THEN every generated binding rejects the work before it can reach provider setup
Requirement: Decode capabilities use registered ordered profiles
CapabilityProfile.client_decode SHALL be a non-empty ordered unique set containing only registered h264-opus and hevc-opus profile identifiers. It MUST NOT encode multiple capabilities in an opaque private token.
Scenario: Independent peer advertises one registered profile
- WHEN an independent peer advertises one registered decode profile
- THEN canonical validation accepts that profile without requiring a combined private token
Requirement: Consumers share one ordered registered-profile intersection
Generated Protocol behavior SHALL select common registered profiles in the first peer's preference order. Provider consumers SHALL separately reject the resulting intersection when it cannot honor the immutable stream policy.
Scenario: Policy-compatible profile overlaps
- WHEN the gateway advertises HEVC then H.264 and the client advertises only H.264
- THEN the shared intersection selects
h264-opus
Scenario: No policy-compatible profile overlaps
- WHEN peers have no registered common profile
- THEN the shared intersection rejects admission without inventing a private combined token