draft-ietf-vcon-cc-extension — vCon Contact Center Extension — library

draft-ietf-vcon-cc-extension (Petrie, Rosenberg) is the working group’s Contact Center extension to the core vCon schema — a small, compatible extension that registers the “CC” extension token and adds a handful of contact-center-specific parameters to the Party and Dialog objects. Daniel Petrie (SIPez LLC) and Jonathan Rosenberg (Five9) are the co-authors. Currently draft-ietf-vcon-cc-extension-01 (published 16 October 2025), expired 19 April 2026 and pending a refresh that the working group has signaled is coming. Standards Track. I co-chair the vCon working group with Brian Rosen.

The conceptual framing for vCons lives on the vCon topic page; the core schema lives in the core spec page. This page covers what’s specific to the Contact Center extension itself.

What the extension specifies

The extension adds two parameters to the Party Object:

role — what the participant played in the conversation. Suggested values are “agent”, “customer”, “supervisor”, “sme” (subject-matter expert), and “thirdparty”, though other values are permitted. In conferencing contexts the values shift to host, cohost, speaker, panelist, and so on.
contact_list — a string label or foreign key referencing the contact list that the party was on, for outbound campaign scenarios.

And four parameters to the Dialog Object:

campaign — string label or foreign key for the campaign this dialog is part of.
interaction_type — string label for the type of interaction (the draft has a TODO marker indicating enumerated values are still being worked out).
interaction_id — label or foreign key for the interaction. The draft itself flags an open question about how this differs from the RFC 7989 SIP Session-ID that the core already carries in session_id.
skill — required skill for the agent or automaton servicing this dialog segment, with values that are contact-center specific.

The extension is compatible — it doesn’t alter or remove core semantics, and consumers that don’t recognize it can safely ignore the new parameters. The “CC” token therefore appears in the extensions array but not in the critical array.

Use-case framing

About half the document is dedicated to contact-center use cases, and that’s where the extension does most of its informational work. Three application categories anchor the discussion:

Recording — long-term storage, playback, and search of call recordings, often driven by compliance requirements.
Quality Management (QM) — the application category that the “this call may be monitored for quality and training purposes” greeting refers to. QM applications combine call recordings with desktop screen recordings and let supervisors score agents against a rubric. Stitching matters here — a single customer call handled by two agents typically produces two stitched recordings, one per agent, because what’s being scored is the agent’s experience, not the customer’s.
Speech analytics — sentiment analysis, cross-talk detection, frequency-of-call-reason dashboards, often feeding back into QM by selecting which calls are worth scoring.

The PII/PCI redaction discussion is also useful. The extension flags that a vCon should be able to indicate that a section of recording is absent for PCI reasons (the agent hit “pause recording” while the customer read a credit card number), rather than just leaving the absence unexplained — without that signal, downstream analytics see broken transcripts and unexplained gaps.

The omni-channel discussion captures what makes vCon appropriate as a unifying container — a single customer interaction that combines voice, SMS, web chat, and a “see-what-I-see” video segment can be expressed as a single vCon with multiple Dialog Objects of varying types, rather than as fragments scattered across channel-specific systems.

Status

Currently draft-ietf-vcon-cc-extension-01, published 16 October 2025, expired 19 April 2026. The working group state remains WG Document and the working group has signaled that a refresh revision is coming — the cc-extension has been a steady WG work item alongside the core. The draft carries some open items — interaction_type enumerated values, the relationship of interaction_id to the core’s session_id, and a TODO for the example vCons section — that the next revision is expected to address.