Crate o_sfu_model 

shared application model for the Odoo Discuss SFU contract

this crate defines the Odoo Discuss call concepts that multiple o-sfu crates must interpret identically they are more specific than RFC vocabulary but less specific than any one runtime subsystem

the model crate depends only on serialization support sockets, async work, media transports, router topology, metrics registries, server configuration and JSON envelope parsing stay in the runtime, core, router, telemetry and protocol crates

Compatibility

several types preserve the old SFU and Odoo browser contract they should remain small data types with explicit serde shapes and local normalization helpers runtime callers should normalize compatibility input at ingress before storing it in room state, diagnostics indexes or subscription maps

Structs

AvailableFeatures

room capabilities advertised to a newly connected browser client

DownloadStates

receiver intent for which streams to download from one peer

PeerSnapshot

full peer entry sent when a client needs the current room membership view

RecordingOptions

recording modes requested by a user

RecordingState

current room recording state as shown to call participants

RecordingStateUpdate

recording state update emitted to clients and observers

UserInfo

presence and call UI state associated with one room participant

UserPermissions

user-level permissions supplied by the Odoo authentication path

Enums

StopCode

business reason attached to a recording stop update

StreamType

stream category exposed to Odoo clients

UserId

user identity as accepted by the Odoo-facing call contract

VideoLayoutIntent

receiver-side layout role for a video stream

WebSocketCloseCode

websocket close code vocabulary shared by server and browser protocol code

Type Aliases

JsonPayload

opaque compatibility payload carried through legacy broadcast paths