



Independent Submission                                         J. Tansey
Internet-Draft                                               Independent
Intended status: Informational                                 J. Tansey
Expires: 16 April 2026                                             Cisco
                                                         13 October 2025


    Adaptive Layered Voice Container (ALVC) for Constrained Networks
                     draft-joetansey-alvc-codec-02

Abstract

   This document specifies the Adaptive Layered Voice Container (ALVC),
   a codec-agnostic framing and metadata container that enables
   progressive voice delivery in constrained and lossy networks.  ALVC
   defines a Base layer that is intelligible on its own at sub-kilobit
   rates, and optional Enhancement layers that improve quality when
   additional capacity is available.  The container supports store-and-
   forward operation, progressive enhancement, unequal error protection
   signaling, and receiver behavior for seamless splice-and-improve
   playback.  ALVC does not define a new speech coding algorithm; it
   multiplexes existing voice coders within a layered container.

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 16 April 2026.

Copyright Notice

   Copyright (c) 2025 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.



Tansey & Tansey           Expires 16 April 2026                 [Page 1]

Internet-Draft               ALVC Container                 October 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Container Overview  . . . . . . . . . . . . . . . . . . . . .   2
   4.  ALVC Frame Format . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Receiver Behavior . . . . . . . . . . . . . . . . . . . . . .   3
   6.  Sender Behavior . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   10. Changes since -01 . . . . . . . . . . . . . . . . . . . . . .   4
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   4
     11.2.  Informative References . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Low-power and highly constrained links (for example LPWANs) cannot
   sustain traditional conversational streaming.  ALVC provides a simple
   container for layered audio so that a small Base layer is delivered
   first for intelligibility, with optional Enhancements sent later.
   The container is transport-agnostic and can be mapped to different
   networks; a companion document describes a SCHC mapping for LPWAN
   [ALVC-SCHC].

2.  Requirements Language

   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.

3.  Container Overview

   ALVC multiplexes one Base stream and zero or more Enhancement streams
   across time-aligned windows (for example 20 ms or 40 ms).  Each
   window is a self-contained set of frames that can be played as soon
   as the Base frame is available.  Enhancements, when present, refine
   the audio for the same window.



Tansey & Tansey           Expires 16 April 2026                 [Page 2]

Internet-Draft               ALVC Container                 October 2025


   ALVC is codec-agnostic: the Base frame is typically produced by a
   very low bitrate coder (for example Codec2), while Enhancements may
   be produced by a higher-fidelity coder (for example LPCNet or Opus)
   configured to refine the same speech segment.  The precise codec
   choices are outside the scope of this document.

4.  ALVC Frame Format

   Each ALVC frame carries structured metadata followed by codec
   payload.  Fields:

   ts  Unsigned timestamp of the start of the covered window, in
      milliseconds since an agreed origin.

   win_dur_ms  Window duration in milliseconds.

   layer_id  0 for Base; positive integers for Enhancements, where
      higher numbers indicate higher quality.

   codec_id  Identifier indicating which codec produced the payload (for
      example a registry or vendor space).

   frag_seq, frag_total  Optional per-frame fragmentation indices when a
      frame is split over multiple transport units.

   flags  Bit flags including: end_of_clip, parity_present,
      auth_present.

   payload_len  Length of codec payload in bytes.

   payload  Opaque codec bytes for this layer and window.

   The Base layer for a window MUST be decodable on its own.
   Enhancement layers for a window MUST refine, but MUST NOT be required
   for basic intelligibility.  Receivers MUST render the best available
   layer for each window as data arrives.

5.  Receiver Behavior

   Receivers maintain per-window state.  On arrival of a Base frame for
   window N, the window becomes immediately playable.  If one or more
   Enhancements for window N later arrive, the receiver SHOULD splice-in
   the improved audio without glitch, using a crossfade or codec-
   specific switch.  Missing or invalid Enhancements MUST NOT block Base
   playback.  Implementations SHOULD expose progress to the application
   layer, such as "Base-only", "Enhanced L1", "Enhanced L2".





Tansey & Tansey           Expires 16 April 2026                 [Page 3]

Internet-Draft               ALVC Container                 October 2025


6.  Sender Behavior

   Senders SHOULD prioritize timely delivery of upcoming Base windows to
   sustain continuous intelligible playback, then transmit earliest-
   missing Enhancements for already-playable windows.  Senders MAY
   include parity or forward error correction and indicate this with the
   parity_present flag.  Transport-specific scheduling (for example SCHC
   fragmentation or channel hopping) is out of scope here but is
   discussed in the SCHC mapping document [ALVC-SCHC].

7.  Examples

   *Example timing:* A clip is encoded into 20 ms windows.  The Base
   stream averages about 0.5 kb/s.  Enhancement L1 averages 1.0 kb/s.
   During constrained periods, only Base is delivered; when capacity
   improves, the sender backfills L1 for the earliest windows missing
   enhancement.

8.  Security Considerations

   ALVC frames SHOULD be protected end-to-end using an authenticated
   encryption scheme.  Integrity failures in Enhancement frames MUST NOT
   affect Base playback; such frames are discarded.  Metadata should be
   minimized consistent with receiver needs.

9.  IANA Considerations

   This document does not create any new IANA registries.  If a public
   registry of ALVC codec identifiers is later desired, it can be
   defined in a follow-up document.

10.  Changes since -01

   Added BCP 14 requirements-language, clarified container scope and
   receiver behavior, added explicit field list and examples, aligned
   text with SCHC mapping companion, ASCII cleanup.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.



Tansey & Tansey           Expires 16 April 2026                 [Page 4]

Internet-Draft               ALVC Container                 October 2025


11.2.  Informative References

   [ALVC-SCHC]
              Tansey, J., "Carrying ALVC over LPWAN using SCHC
              Fragmentation and Priorities", 2025,
              <https://datatracker.ietf.org/doc/draft-joetansey-alvc-
              schc-lpwan/>.

Authors' Addresses

   Joe Tansey
   Independent
   Email: joe.tansey@gmail.com


   Joe Tansey
   Cisco
   Email: joetanse@cisco.com

































Tansey & Tansey           Expires 16 April 2026                 [Page 5]
