A vCon (Virtualized Conversation) is an IETF-standardized JSON container for conversation data — call recordings, transcripts, chat logs, participant identities, AI analysis, and attachments — all in one portable, signable file. Think of it as “vCard for conversations”: just as vCard made contact data portable across platforms, vCon does the same for the conversations themselves.

The standard is being developed by the IETF’s Virtualized Conversations (vcon) working group. The core draft (draft-ietf-vcon-vcon-core) is on the Standards Track, and 2026 is shaping up to be the year of formal adoption.

For operators, vCon matters in three places: AI pipelines (feeding conversations to LLMs in a consistent format), compliance (tamper-evident records, structured redaction, consent tracking), and portability (no more vendor lock-in on recordings and transcripts). If you run a multi-tenant VoIP platform today, your conversation data is scattered across recording stores, transcription vendors, CRMs, and ticketing systems. vCon is the container format that lets you unify it — and prove its integrity later.

Your platform generates conversations. Where do they actually live?

Ask any operator running a hosted PBX or contact-center platform a simple question: “Show me everything that happened on this customer call — the recording, the transcript, who was on it, the sentiment analysis, and proof it hasn’t been altered.”

In most deployments, the honest answer involves four or five systems. The recording sits in an S3 bucket named by the recording service. The transcript lives with whichever speech-to-text vendor was cheapest that quarter. Party information is buried in CDRs. The AI summary — if there is one — is a row in a SaaS tool that may not exist next year. And proof of integrity? Usually nothing beyond “we trust our storage.”

That fragmentation was tolerable when conversation data was write-once, read-rarely. It stops being tolerable the moment you need to:

  • Feed conversations into AI/LLM workflows at scale
  • Respond to a legal hold, subpoena, or dispute with verifiable records
  • Honor a GDPR/CCPA deletion or redaction request across every copy
  • Migrate platforms without abandoning years of recordings and transcripts

This is the problem the vCon standard was designed to solve.

What is a vCon?

A vCon (Virtualized Conversation) is a standardized JSON document that packages everything about a single conversation into one self-contained, portable object. The format is defined by the IETF vcon working group — the same standards body behind SIP, SDP, and most of the protocols your platform already runs on.

The analogy the working group itself uses: vCon is to conversations what vCard is to contacts. A vCard doesn’t care whether the contact came from Outlook, iOS, or a CRM — it’s a neutral container any system can read. A vCon does the same for a phone call, a video meeting, an SMS thread, or a chat session.

One conversation, one file, containing the who, what, when, how, and — increasingly important — the proof.

Anatomy of a vCon: the five building blocks

A vCon is deliberately simple at the top level. Per the core specification, the container holds:

1. Metadata

The envelope: a globally unique uuid, created_at / updated_at timestamps, the spec vcon version, and an optional subject. This is what makes a conversation referenceable across systems — the vCon UUID becomes the single key that ties your recording store, CRM, and analytics together.

2. Parties

An array of everyone in the conversation, with structured identifiers: tel for phone numbers, sip for SIP URIs, mailto for email, plus names and roles. If you’ve ever tried to reconstruct “who was actually on this call” from raw CDR legs across a transfer and a conference bridge, you’ll appreciate having this normalized in one place.

3. Dialog

The conversation itself. Each dialog entry captures a segment of the exchange — an audio recording, a video file, or text messages — with start times, durations, and which parties participated. Media can be embedded inline (base64) or referenced externally by URL. Externally referenced files must carry a content_hash (SHA-512), so a vCon can point at a 200 MB recording in object storage while still guaranteeing that what you fetch later is what was recorded.

4. Analysis

Everything derived from the conversation after the fact: transcripts, translations, sentiment scores, summaries, intent classification. Each analysis entry records what it analyzed and what produced it — so when your transcription vendor changes or you re-run analysis with a better model, the lineage stays intact.

5. Attachments

Documents that traveled with the conversation: the presentation shared on the call, the contract discussed, the ticket that triggered the callback.

{
  "vcon": "0.3.0",
  "uuid": "0192607e-2b0c-8333-b7ac-5d75d78092d6",
  "created_at": "2026-08-11T14:23:00Z",
  "subject": "Support call - port order status",
  "parties": [
    { "tel": "+15551234567", "name": "Alice Customer" },
    { "tel": "+15559876543", "name": "Bob Agent", "role": "agent" }
  ],
  "dialog": [
    {
      "type": "recording",
      "start": "2026-08-11T14:23:04Z",
      "duration": 542,
      "parties": [0, 1],
      "url": "https://storage.example.com/rec/0192607e.wav",
      "content_hash": "sha512-Lp8e6y5..."
    }
  ],
  "analysis": [
    {
      "type": "transcript",
      "dialog": 0,
      "vendor": "example-stt",
      "body": { "text": "Hi, I'm calling about my port order..." }
    }
  ],
  "attachments": []
}

A simplified vCon. One JSON object now answers the “show me everything about this call” question.

The three forms: unsigned, signed, encrypted

This is where vCon goes beyond being “just a JSON schema” and starts earning its place in a compliance conversation. The spec defines three progressive forms:

  • Unsigned — plain JSON, used while a conversation is in progress or being assembled. This is the working form inside your pipeline.
  • Signed — the vCon wrapped in a JWS (JSON Web Signature). Once signed, any modification is detectable. This is what turns a recording from “a file we have” into evidence — suitable for disputes, chargebacks, legal holds, and regulatory audits.
  • Encrypted — the signed vCon wrapped in JWE (JSON Web Encryption), protecting confidentiality at rest and in transit between domains.

If you’ve handled a dispute where a customer claimed “I never agreed to that,” you already know why cryptographically verifiable conversation records are worth the operational effort.

Redaction and amendment: compliance built into the format

Two mechanisms in the spec map directly onto problems every operator eventually faces:

Redaction. A privacy-preserving version of a vCon can be generated with PII removed — and it carries a redacted reference to the less-redacted original. That gives you a clean answer to GDPR/CCPA workflows: hand the redacted vCon to analytics vendors and AI pipelines, keep the original under stricter access control, and maintain a verifiable chain between the two instead of an untracked pile of edited copies.

Amendment. Signed documents can’t be modified — so how do you add a transcript to a call that was signed at hang-up? The amended mechanism creates a new vCon version that references the prior one. Nothing is ever silently altered; the history is an append-only chain. Related IETF work explores anchoring that lifecycle in SCITT transparency ledgers for even stronger audit trails.

Why this matters now: the AI angle

Be honest about what’s driving urgency here: AI is eating conversation data. Every operator is being asked to bolt LLM-powered summaries, QA scoring, and agent-assist onto their platform. And every one of those integrations is currently a bespoke pipeline: pull the recording from here, the transcript from there, the caller identity from a third place, glue it together, and hope the formats don’t change.

vCon collapses that glue work. When your platform emits a vCon per conversation:

  • Every AI vendor gets the same input format. Swapping transcription or summarization providers stops being an integration project.
  • Analysis results come back into the same container, with lineage — you know which model produced which summary from which recording.
  • Consent and redaction travel with the data. Before a conversation reaches a third-party model, the vCon itself tells you what’s permitted and what’s been stripped. That’s a materially better position than discovering, mid-audit, that raw customer recordings were shipped to an AI vendor with no record of consent.

There’s a reason industry commentary is calling 2026 the pivotal year for vCon standardization: the standard matured at exactly the moment the industry needed a safe, uniform way to move conversations into AI systems.

What this looks like for a platform operator

You don’t need to wait for final RFC status to benefit. A practical adoption path:

  1. Start at the recording boundary. Wherever recordings land today (platform recording service, SBC-based recorder, SIPREC), add a step that wraps each completed call in an unsigned vCon: parties from the CDR, a dialog entry pointing at the recording with its SHA-512 hash.
  2. Attach analysis as you already generate it. If you’re transcribing or summarizing calls today, write those results into the vCon’s analysis array instead of (or alongside) a separate database.
  3. Sign what matters. You don’t have to sign everything on day one. Start with conversations that carry legal weight — sales confirmations, consent capture, collections, healthcare scheduling.
  4. Use the open-source ecosystem. The vCon community maintains open-source tooling — most notably the conserver, a lightweight server for creating, storing, and processing vCons through configurable pipelines — plus Python libraries for building and validating containers. You’re not starting from a blank page.
  5. Make it a differentiator. If you’re a reseller or MSP, “your conversation data is stored in an open IETF format, cryptographically verifiable, and portable if you ever leave us” is a genuinely rare pitch in this industry. Lock-in through data hostage-taking is the norm; vCon lets you sell the opposite.

Common misconceptions

“It’s just another recording format.” No — vCon doesn’t replace WAV or Opus. It’s the container of record that binds media, identity, analysis, and integrity proofs together. Your codecs don’t change.

“It’s only for contact centers.” Contact centers are the anchor use case, but the format is mode-agnostic: SMS threads, video meetings, chat sessions, even emergency-services communications are in scope per the working group charter.

“It’s not finished, so it’s not usable.” The core draft is on the IETF Standards Track and iterating in the open, with working code and real deployments feeding back into the spec — the same way SIP matured. Early adopters are shaping the standard rather than waiting for it.

The bottom line

Conversation data is becoming the most valuable — and most regulated — asset a VoIP platform produces. Today it’s scattered, unverifiable, and locked into vendor silos. vCon is the industry’s answer: one open container per conversation, with identity, media, analysis, integrity, and privacy controls built in.

The operators who adopt it early won’t just have cleaner pipelines. They’ll have provable records when disputes arrive, ready-made AI integration when customers demand it, and a portability story their competitors can’t match.

Planning your conversation-data or AI strategy and not sure where vCon fits? Our engineers help platform operators design recording, compliance, and analytics pipelines every day. Book a free 30-minute assessment — no obligation, just a straight answer on whether this makes sense for your stack.

Sources