A vCon (Virtualized Conversation) is an IETF working-group standard for packaging a conversation – call, chat, video meeting, or SMS exchange – into a single portable, signable, encryptable JSON object. The virtual conversation meaning is that conversation data becomes an independent, vendor-neutral artifact with four major sections: parties (who participated), dialog (the actual messages and media references), analysis (transcript, summary, sentiment, extracted metadata), and attachments (files exchanged).

Think of it as analogous to vCard, but for conversations instead of contact details. The point is that your conversation data shouldn't be locked inside one vendor's recording silo. The format is still being finalized as an IETF Internet Draft, but it's already mature enough to design for. ECG is involved in the working group and has shipped vCon in production, so we know which extensions are stable and which are still evolving. 

SIPREC is the protocol that captures the audio and metadata off the call path in real time and sends it to a recording server. vCon is the file format that the recording server (or anybody downstream) emits. They're complementary, not competitive.

Where SIPREC says "here's a copy of the call audio and some metadata right now," vCon says "here's the whole conversation – audio reference, participants, transcript, analysis, attachments – packaged so anybody downstream can consume it without vendor-specific integration."

A typical pipeline has SIPREC flowing into a recording engine, and the recording engine emits vCons to your AI pipeline, CRM, archive, and compliance system. SIPREC is settled as an RFC; vCon is moving toward standardization. 

Nobody knows for sure, but the trajectory looks good.

The IETF working group is active, and the contact center extension was specifically driven by real contact-center vendor input. The case is similar to SMS interop in the late 1990s. Once carriers could exchange SMS between networks, the format exploded. vCon is positioned the same way for conversation data.

Whether it gets to RFC status in 2026 or 2027 or later, the direction is clear: if you build for vCon-shaped data, you're set whether the spec evolves or not.

 Yes – that's exactly the use case we've built ingestion for. Most major recording vendors are now aware of vCon, and several are working on native emission. In the meantime, we build adapters that take their proprietary export format and produce conformant vCons. Once vCons are flowing from all your recording sources, your downstream pipeline (AI, archive, CRM, compliance) only has to understand one format. That's where integration savings show up. 

vCon is an IETF standard developed in an open working group, not a vendor format. The whole motivation for vCon is the opposite of vendor lock-in – it's the open container that lets you move conversation data between systems regardless of which vendor produced it.

That said, individual vCon implementations can be done with proprietary extensions that nobody else parses. We've already seen this play out with SIPREC, where the standard is open, but interop between vendors is a constant battle due to metadata extensions.

At ECG, we design vCon implementations to stay close to the spec and to use standard extensions where they exist, so your vCons stay portable.

The vCon consent extension (lawful-basis extension) captures the lawful basis under which the conversation was recorded, the exact timestamps of consent capture, and (when required) the recorded consent announcement itself. Combined with the vCon parties section, this provides the metadata to answer "show me every conversation involving this customer and the consent state for each one" – which is what GDPR and CCPA require for data subject access and deletion requests.

vCon by itself doesn't make you compliant, as you also need retention policies, access controls, and a deletion workflow. However, it's the format that makes the compliance program technically feasible. 

STIR PASSporTs identify the origination of a call – who placed it with what authority. The vCon specification explicitly references STIR PASSporT as part of the participant identity information you can preserve in the parties section. When a call arrives with a verified A-attestation PASSporT, that identity assertion can be preserved in the vCon instead of getting lost when the recording is exported to a separate system.

For organizations that care about the chain of custody between caller identity and conversation content – fraud detection, compliance forensics – this is meaningful. 

SCITT (Supply Chain Integrity, Transparency, and Trust) is an IETF effort to standardize transparency ledgers – append-only, cryptographically verifiable logs of transformations applied to data artifacts. The vCon lifecycle extension uses SCITT-style ledgers so that every transformation of a vCon leaves a verifiable receipt signed by the system that performed it.

For regulated workloads – financial services, healthcare, anything where a regulator can ask "what happened to this data and when?" – this creates chain-of-custody evidence. ECG can help you decide which side of that line your project sits on and build the ledger integration when it's required. 

The vCon analysis section is designed to carry AI-generated content like transcripts, summaries, sentiment analysis, action items, and any other extracted structured data. Each analysis entry references the dialog section it covers, names the producer, and is timestamped. When the regulator asks which conversations were used to train which model, the vCon analysis section combined with the lifecycle extension and SCITT receipts gives you the answer. Without this, AI compliance becomes nearly impossible at scale.

That depends on your starting point. If you're already running SIPREC into a modern recording vendor, adding vCon emission is mostly an integration and schema-mapping project – measured in weeks, not months.

If you're retrofitting a legacy proprietary recording stack, it's a bigger project. At ECG, we model the integration cost against your call volume and downstream consumer set before architecture decisions get locked in.