Media Over QUIC C. Jennings Internet-Draft S. Nandakumar Intended status: Standards Track Cisco Expires: 7 January 2027 6 July 2026 MOCHA Meetings: Real-Time Conferencing over MoQ Transport draft-jennings-moq-mocha-meetings-00 Abstract This document specifies how multi-party audio and video meetings are conducted using MOCHA (MoQ Open Communication & Hosting Architecture). It defines namespace conventions, media track design, catalog distribution, and participant flows for real-time conferencing over MoQ Transport (MOQT). This specification supports both simulcast and scalable video codec configurations, enabling meetings ranging from small group calls to large-scale conferences. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jennings-moq-mocha-meetings/. Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Jennings & Nandakumar Expires 7 January 2027 [Page 1] Internet-Draft mocha-meetings July 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Meeting Namespace . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Identifier Derivation . . . . . . . . . . . . . . . . . . 4 3.2. Media Namespace . . . . . . . . . . . . . . . . . . . . . 4 3.3. Media Track Names . . . . . . . . . . . . . . . . . . . . 4 3.4. Catalog Namespace . . . . . . . . . . . . . . . . . . . . 5 3.5. Catalog Track Names . . . . . . . . . . . . . . . . . . . 5 4. Media Track Design . . . . . . . . . . . . . . . . . . . . . 5 4.1. Audio Tracks . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Audio Object Mapping . . . . . . . . . . . . . . . . 6 4.2. Video Tracks . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Video Object Mapping . . . . . . . . . . . . . . . . 6 4.2.2. Quality Variants . . . . . . . . . . . . . . . . . . 7 4.3. Active Speaker Detection via Top-N Track Filters . . . . 7 5. Catalog Format . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Catalog Object Structure . . . . . . . . . . . . . . . . 8 5.2. Catalog Updates . . . . . . . . . . . . . . . . . . . . . 9 6. Basic Meeting Flow . . . . . . . . . . . . . . . . . . . . . 9 6.1. Meeting Creation . . . . . . . . . . . . . . . . . . . . 9 6.2. Joining a Meeting . . . . . . . . . . . . . . . . . . . . 9 6.3. Active Speaker Switching . . . . . . . . . . . . . . . . 11 6.4. Screen Sharing . . . . . . . . . . . . . . . . . . . . . 12 6.5. Late Join . . . . . . . . . . . . . . . . . . . . . . . . 12 6.6. Leaving a Meeting . . . . . . . . . . . . . . . . . . . . 14 7. Relay Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Fan-Out . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Self-Suppression . . . . . . . . . . . . . . . . . . . . 15 7.4. Track Filtering . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 Jennings & Nandakumar Expires 7 January 2027 [Page 2] Internet-Draft mocha-meetings July 2026 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Real-time meetings are a core use case for MOCHA. This document specifies how participants join, publish, and subscribe to audio and video media in a meeting using MOQT's publish/subscribe primitives. Each participant's device publishes its media on per-device tracks within a meeting namespace. A catalog track provides metadata about available media renditions, enabling subscribers to discover and select appropriate streams. Active speaker detection and relay-based fan-out allow meetings to scale efficiently. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terminology and architecture defined in [MOCHA-ARCH], including Provider, Organization, Team, Channel, and Device. The MOQT transport primitives (Track, Group, Object, Namespace, Relay) are defined in [MoQTransport]. HClientID and HDevID are defined in [MOCHA-IDENTITY]. The following additional terms are used: MeetingID: A unique identifier for a meeting instance within a channel. A new MeetingID is assigned each time a meeting is started in a channel. RenditionID: An identifier for a specific media encoding variant (e.g., resolution, bitrate, codec profile). Catalog: An MSF [MSF] catalog track describing the available media renditions published by a device. Active Speaker: The participant currently producing the most significant audio activity, as determined by the audio_level object property and Top-N Track Filter selection. Jennings & Nandakumar Expires 7 January 2027 [Page 3] Internet-Draft mocha-meetings July 2026 3. Meeting Namespace 3.1. Identifier Derivation The HClientID and HDevID used in namespace tuples and track names are derived per [MOCHA-IDENTITY], Section "Identifier Derivation". 3.2. Media Namespace The media namespace groups all real-time audio and video tracks for a single meeting instance. All devices participating in the same meeting publish and subscribe to tracks under this common namespace, allowing the relay to perform fan-out, caching, and track filtering scoped to that meeting. Media tracks for a meeting use the following namespace tuple: ("mocha_v1", , , "media", , , , ) For example, a meeting in the "standup" channel of team "engineering" at organization "acme": ("mocha_v1", "example.com", "acme", "media", "engineering", "standup", "meeting-2024-05-15-1600", ) 3.3. Media Track Names Each device publishes media on tracks within the meeting namespace. Track names encode the media type, rendition, and device identity: Audio tracks: audio-- Video tracks: video-- HClientID and HDevID are derived per Section 3.1. For example, if Alice's device has HDevID "alice-laptop-1" and publishes two video renditions: Jennings & Nandakumar Expires 7 January 2027 [Page 4] Internet-Draft mocha-meetings July 2026 Namespace: ("mocha_v1", "example.com", "acme", "media", "engineering", "standup", "meeting-2024-05-15-1600", ) Track: audio-opus48k- Track: video-720p- Track: video-360p- The RenditionID values used in track names (e.g., "opus48k", "720p", "360p") correspond to rendition entries in the device's catalog (see Section 5). Subscribers consult the catalog to discover which renditions are available before subscribing to specific media tracks. 3.4. Catalog Namespace The catalog namespace carries metadata tracks that describe each device's available media renditions. By separating the catalog from media, subscribers can discover participants and their capabilities without subscribing to any media streams. Each device publishes exactly one catalog track in this namespace, enabling other participants to learn what audio/video tracks are available for subscription. Catalog tracks use a separate namespace tuple: ("mocha_v1", , , "catalog", , , , ) HClientID and HDevID are derived per Section 3.1. 3.5. Catalog Track Names Each device publishes a catalog describing its available renditions: catalog- For example: Namespace: ("mocha_v1", "example.com", "acme", "catalog", "engineering", "standup", "meeting-2024-05-15-1600", ) Track: catalog- 4. Media Track Design Jennings & Nandakumar Expires 7 January 2027 [Page 5] Internet-Draft mocha-meetings July 2026 4.1. Audio Tracks Each participant publishes a single audio track per rendition. The audio codec and encoding parameters are specified by the RenditionID and described in the device's catalog (see Section 5). 4.1.1. Audio Object Mapping Each audio frame maps to a single MOQT Object: * Group ID increments per frame (no inter-frame dependencies) * Object ID is 0 within each group * Objects MAY be sent via QUIC Datagrams for lowest latency 4.2. Video Tracks Video publishers provide one or more rendition tracks (simulcast). Each rendition represents a different resolution or quality level. 4.2.1. Video Object Mapping Track: video-720p-alice-laptop-1 | +-- Group 1 (GOP / keyframe boundary) | +-- Object 0: I-frame | +-- Object 1: P-frame | +-- Object 2: P-frame | ... | +-- Group 2 (next GOP) | +-- Object 0: I-frame | ... * Each encoded video frame is packaged as a LOC container and placed in a single MOQT Object * Group ID increments at each keyframe boundary (GOP). The first Group ID is the lower 32 bits of the current wall clock time in milliseconds * Object IDs are sequential within each group * Objects are sent via QUIC Streams for reliable delivery Jennings & Nandakumar Expires 7 January 2027 [Page 6] Internet-Draft mocha-meetings July 2026 4.2.2. Quality Variants Publishers advertise available quality variants via the catalog. Typical variants include: +=============+============+============+===============+ | RenditionID | Resolution | Frame Rate | Bitrate Range | +=============+============+============+===============+ | 1080p | 1920x1080 | 30 fps | 2-4 Mbps | +-------------+------------+------------+---------------+ | 720p | 1280x720 | 30 fps | 1-2 Mbps | +-------------+------------+------------+---------------+ | 360p | 640x360 | 30 fps | 300-600 Kbps | +-------------+------------+------------+---------------+ | 180p | 320x180 | 15 fps | 100-200 Kbps | +-------------+------------+------------+---------------+ Table 1 4.3. Active Speaker Detection via Top-N Track Filters Active speaker detection leverages MOQT's Top-N Track Filter mechanism on SUBSCRIBE_TRACKS. Rather than requiring a separate speaking indicator track, each audio track includes an audio_level object property (0-127) representing the current voice activity level. Subscribers issue a SUBSCRIBE_TRACKS with a TRACK_FILTER parameter selecting the top-N audio tracks by audio_level. The relay monitors audio_level properties across all audio tracks in the namespace and automatically promotes tracks that enter the top-N (sending PUBLISH messages for them) and demotes tracks that fall out (ceasing delivery). A configurable timeout (TrackFilterTimeout, default 1 second) provides damping to avoid rapid switching during brief interjections. This approach eliminates the need for dedicated speaking indicator tracks, as the relay performs active speaker selection natively using the audio_level property on the media tracks themselves. 5. Catalog Format The meeting catalog uses the MOQT Streaming Format (MSF) catalog structure. Each device publishes an MSF catalog track describing its available media renditions. The catalog track MUST have a track name of "catalog" within the catalog namespace. Jennings & Nandakumar Expires 7 January 2027 [Page 7] Internet-Draft mocha-meetings July 2026 5.1. Catalog Object Structure Each catalog object is a JSON document following the MSF catalog schema. The catalog describes the tracks being published by the device, their codecs, qualities, and relationships: { "version": 1, "generatedAt": 1715788800000, "tracks": [ { "name": "audio-opus48k-alice-laptop-1", "namespace": ["mocha_v1", "example.com", "acme", "media", "engineering", "standup", "meeting-2024-05-15-1600"], "packaging": "loc", "role": "audio", "codec": "opus", "samplerate": 48000, "channelConfig": "mono", "label": "Alice Smith" }, { "name": "video-720p-alice-laptop-1", "packaging": "loc", "role": "video", "codec": "avc1.64001f", "width": 1280, "height": 720, "framerate": 30, "bitrate": 2000000, "altGroup": 1, "label": "Alice Smith" }, { "name": "video-360p-alice-laptop-1", "packaging": "loc", "role": "video", "codec": "avc1.64001f", "width": 640, "height": 360, "framerate": 30, "bitrate": 500000, "altGroup": 1, "label": "Alice Smith" } ] } Jennings & Nandakumar Expires 7 January 2027 [Page 8] Internet-Draft mocha-meetings July 2026 Tracks that share an altGroup value represent alternate renditions of the same content (simulcast). Subscribers select one track from each alternate group based on available bandwidth and layout requirements. 5.2. Catalog Updates When a device changes its published renditions (e.g., starts screen sharing or changes video quality), it publishes a new catalog object in the next group. Delta updates MAY be used for incremental changes. Subscribers to the catalog track receive the updated rendition list and adjust their media subscriptions accordingly. 6. Basic Meeting Flow 6.1. Meeting Creation A meeting is created when the first participant initiates a call in a channel. The MeetingID is generated and associated with the channel. Meeting creation is signaled via a system message on the channel's chat track as defined in [MOCHA-CHAT], allowing all channel participants to discover and join the meeting. 6.2. Joining a Meeting When a participant joins an existing meeting, the following sequence occurs. In this example, the catalog namespace is ("mocha_v1", "example.com", "acme", "catalog", "engineering", "standup", "meeting- 2024-05-15-1600") and the media namespace is ("mocha_v1", "example.com", "acme", "media", "engineering", "standup", "meeting- 2024-05-15-1600"). Jennings & Nandakumar Expires 7 January 2027 [Page 9] Internet-Draft mocha-meetings July 2026 Alice Relay Bob (existing) | | | | 1. SUBSCRIBE_NAMESPACE | | | catalog namespace | | |-------------------------->| | | | | | 2. NAMESPACE | | | (catalog-bob-desktop) | | |<--------------------------| | | | | | 3. SUBSCRIBE | | | catalog-bob-desktop | | |-------------------------->| | | | | | 4. Catalog object | | | (Bob's renditions) | | |<--------------------------| | | | | | 5. SUBSCRIBE_TRACKS | | | media namespace | | | (Top-N audio_level) | | |-------------------------->| | | | | | 6. PUBLISH (from relay) | | | audio-opus48k-bob-desktop | | video-720p-bob-desktop| | |<--------------------------| | | | | | 7. PUBLISH media | | | audio-opus48k-alice-laptop-1 | | video-720p-alice-laptop-1 | | catalog-alice-laptop-1| | |-------------------------->| | | | | | 8. Media objects flow | | |<------------------------->|<---------------------->| | | | The join sequence in detail: 1. Alice sends SUBSCRIBE_NAMESPACE for the catalog namespace to discover existing participants. 2. The relay responds with NAMESPACE messages for each catalog track currently published in the meeting (e.g., catalog-bob-desktop). 3. Alice sends SUBSCRIBE for each discovered catalog track to learn available renditions. Jennings & Nandakumar Expires 7 January 2027 [Page 10] Internet-Draft mocha-meetings July 2026 4. Alice receives MSF catalog objects describing each participant's media tracks and renditions. 5. Alice sends SUBSCRIBE_TRACKS for the media namespace with a Top-N Track Filter on audio_level. This requests the relay to establish subscriptions for the top-N active audio/video tracks. 6. The relay responds by sending PUBLISH messages for the matching tracks (e.g., Bob's audio and video), then begins delivering media objects. 7. Alice publishes her own media tracks and catalog, making her media available to other participants. 8. Bidirectional media flows through the relay. 6.3. Active Speaker Switching Active speaker detection uses the audio_level object property on audio tracks. The relay monitors these values and selects the top-N tracks for delivery based on the SUBSCRIBE_TRACKS filter: Alice Relay Bob's View | | | audio_level: 95 | +-----------+ |---------------->| Top-N select | Alice(AS) | | | by audio_level | Carol | | Bob level: 20 | | Dave | | | +-----------+ | | | audio_level: 110| |---------------->| Alice exceeds +-----------+ | | threshold for |*Alice* | | | >1 sec | Bob | | | | Carol | | | +-----------+ Subscribers use SUBSCRIBE_TRACKS with a Top-N Track Filter to request the top-N media streams ranked by audio_level: Jennings & Nandakumar Expires 7 January 2027 [Page 11] Internet-Draft mocha-meetings July 2026 SUBSCRIBE_TRACKS { Prefix: ("mocha_v1", "example.com", "acme", "media", "engineering", "standup", "meeting-2024-05-15-1600") Parameters: TRACK_FILTER: { Property: audio_level MaxTracksSelected: 4 } } The relay selects the top-N audio tracks and delivers only those to the subscriber. When the active speaker changes, the relay sends PUBLISH for the newly promoted track and ceases delivery of the demoted track. 6.4. Screen Sharing A participant initiates screen sharing by publishing additional video rendition tracks and updating their catalog: Alice (sharing) Relay Others | | | | Update catalog: | | | + video-screen-1080p-alice-laptop-1 | |--------------------------->| | | | | | Publish screen video | | |--------------------------->| Notify catalog | | | subscribers | | |----------------->| | | | | | SUBSCRIBE | | | video-screen-* | | |<-----------------| | | | | Screen frames | Fan-out | |--------------------------->|----------------->| | | | 6.5. Late Join When a participant joins a meeting already in progress, it needs to synchronize to the current media state. The SUBSCRIBE_OK response includes the current live edge (the latest Group ID being published), which the subscriber uses to determine where to begin playback. For video tracks, the subscriber chooses between two strategies based on how far into the current group the publisher has progressed: Jennings & Nandakumar Expires 7 January 2027 [Page 12] Internet-Draft mocha-meetings July 2026 1. FETCH from current group: If the publisher is not too far into the current group (i.e., few objects have been published since the last keyframe), the subscriber issues a FETCH request starting from the beginning of the current group (Object 0). The relay delivers the keyframe and subsequent frames from its cache, allowing the subscriber to catch up quickly and join the live stream mid-GOP. 2. DYNAMIC_GROUPS: If the publisher is deep into the current group (many frames since the last keyframe), fetching from the beginning would require downloading a large backlog. Instead, the subscriber sends a DYNAMIC_GROUPS to the publisher, which triggers the publisher to end the current group and start a new one with a fresh keyframe. The subscriber then receives the new keyframe immediately as live media. The live edge information from SUBSCRIBE_OK (the current Group ID and Object ID) allows the subscriber to determine how far into the current group the publisher is and choose the appropriate strategy. Case 1: FETCH (publisher early in current group) Subscriber Relay Publisher | | | | SUBSCRIBE video track | | |-------------------------->| | | | | | SUBSCRIBE_OK | | | (live edge: G=5, O=2) | | |<--------------------------| | | | | | Decision: O=2, only 2 | | | frames in, FETCH is fast | | | | | | FETCH (G=5, O=0) | | |-------------------------->| | | | | | Object G=5/O=0 (I-frame)| | |<--------------------------| | | Object G=5/O=1 (P-frame)| | |<--------------------------| | | Object G=5/O=2 (P-frame)| (live continues) | |<--------------------------|<---------------------| | | | | (now in sync, receives | | | live objects G=5/O=3...) | | |<--------------------------|<---------------------| | | | Jennings & Nandakumar Expires 7 January 2027 [Page 13] Internet-Draft mocha-meetings July 2026 Case 2: DYNAMIC_GROUPS (publisher deep in current group) Subscriber Relay Publisher | | | | SUBSCRIBE video track | | |-------------------------->| | | | | | SUBSCRIBE_OK | | | (live edge: G=5, O=47) | | |<--------------------------| | | | | | Decision: O=47, too far | | | to fetch from O=0 | | | | | | DYNAMIC_GROUPS | | |-------------------------->|--------------------->| | | | | | Publisher ends G=5 | | | Starts G=6 with | | | fresh keyframe | | |<---------------------| | | | | Object G=6/O=0 (I-frame)| | |<--------------------------| | | Object G=6/O=1 (P-frame)| | |<--------------------------|<---------------------| | | | | (in sync from fresh | | | keyframe, minimal delay)| | |<--------------------------|<---------------------| | | | 6.6. Leaving a Meeting When a participant leaves a meeting: 1. The device stops publishing media objects on its tracks. 2. The device publishes a final catalog object with an empty rendition list or a "departed" status. 3. The relay detects track inactivity and stops forwarding. 4. Other participants observe the catalog update and unsubscribe from the departed device's media tracks. 7. Relay Behavior Jennings & Nandakumar Expires 7 January 2027 [Page 14] Internet-Draft mocha-meetings July 2026 7.1. Fan-Out When multiple participants subscribe to the same media track, the relay performs fan-out delivery from a single upstream subscription. This prevents duplicate traffic to the original publisher. 7.2. Caching Relays cache recent video keyframes (the most recent complete group) to enable fast joins. When a new subscriber arrives, the relay delivers the cached keyframe immediately, providing instant video without waiting for the next keyframe from the publisher. 7.3. Self-Suppression Relays MUST NOT deliver a participant's own media back to them. The relay supresses self-delivery based on FullTrackName and Track alias. 7.4. Track Filtering Relays support track filtering based on properties like speaking level, enabling active speaker selection without requiring subscribers to receive all tracks and filter locally. 8. Security Considerations TODO 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [LOC] Zanaty, M., Nandakumar, S., and P. Thatcher, "Low Overhead Media Container", Work in Progress, Internet-Draft, draft- ietf-moq-loc-02, 15 March 2026, . [MOCHA] "*** BROKEN REFERENCE ***". [MOCHA-ARCH] "*** BROKEN REFERENCE ***". Jennings & Nandakumar Expires 7 January 2027 [Page 15] Internet-Draft mocha-meetings July 2026 [MOCHA-CHAT] "*** BROKEN REFERENCE ***". [MOCHA-IDENTITY] "*** BROKEN REFERENCE ***". [MoQTransport] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet- Draft, draft-ietf-moq-transport-18, 12 May 2026, . [MSF] Law, W. and S. Nandakumar, "MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-msf-01, 2 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SecureObjects] Jennings, C. F., Nandakumar, S., and R. Barnes, "End-to- End Secure Objects for Media over QUIC Transport", Work in Progress, Internet-Draft, draft-jennings-moq-secure- objects-04, 8 February 2026, . 10.2. Informative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, . Jennings & Nandakumar Expires 7 January 2027 [Page 16] Internet-Draft mocha-meetings July 2026 Acknowledgments TODO Authors' Addresses Cullen Jennings Cisco Email: fluffy@iii.ca Suhas Nandakumar Cisco Email: snandaku@cisco.com Jennings & Nandakumar Expires 7 January 2027 [Page 17]