]> The JSON format for vCon - Conversation Data Container SIPez LLC
dan.ietf@sipez.com
Applications and Real-Time Virtualized Conversations conversation vcon CDR call detail record call meta data call recording email thread text conversation video recording video conference conference recording vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Virtualized Conversations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction This document specifies the vCon (Conversational Data Exchange) standard, which defines a unified format for representing and exchanging conversational data across different communication platforms and modalities. The goal of vCon is to provide a standardized, platform-agnostic structure for capturing and sharing conversational information, allowing for seamless integration between systems, enterprises, and trust boundaries.
Purpose of vCon The vCon standard enables the abstraction of conversation data, making it easier to integrate communication platforms with external services, including post-conversation analysis tools, customer support systems, and business intelligence platforms. By defining a consistent data format, vCon ensures interoperability across various platforms, regardless of the communication mode - whether text, audio, video, or other formats. The vCon format captures the essential components of a conversation, including metadata, media content, related documents, and post-conversation analysis. This abstraction simplifies data exchange, apply AI-driven analysis, as well as model training and testing.
Extending the vCon Schema In addition to the core vCon schema, this document provides a framework for extending the vCon format to support specialized use cases. The vCon schema can be customized to address the needs of specific industries or applications, such as:
  • Contact Centers: Adding specific metadata related to customer service interactions, case management, and priority tracking.
  • Messaging Platforms: Supporting the integration of different message formats, including SMS, email, and chat, group concepts, along with platform-specific information.
  • ECRIT (Emergency Communication) Centers: Extending the schema to capture critical data such as location, urgency, and incident details for emergency communications.
The ability to add extensions ensure that vCon remains flexible and adaptable, enabling its use in a wide range of domains while maintaining a consistent format for data exchange.
Benefits of vCon The vCon standard offers several key benefits:
  • Interoperability: A consistent data format for conversational data facilitates integration across diverse platforms and systems.
  • AI-Driven Analysis: By capturing data in a structured format, vCon enables the application of AI analysis such as sentiment analysis, categorization, transcription, and decision-making.
  • Data Automation: The vCon format simplifies the automation of processes involving conversational data, improving efficiency and reducing the risk of errors.
  • Enterprise Integration: The ability to integrate conversation data with third-party tools and services enhances the value of conversations by providing deeper insights and driving business decisions.
Scope of the Document This document defines the core structure and schema for vCon as a JSON format. Detailed specifications for the various parameters and the extension framework will be provided in subsequent sections. The primary focus is on creating a flexible, extensible standard for the exchange of conversational data that can be easily adopted across industries, use cases, and communication technologies.
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 when, and only when, they appear in all capitals, as shown here.
Terminology
  • analysis - analysis, transformations, summary, sentiment, or translation typically of the dialog data
  • conversation - an exchange of communication using text, audio or video medium between at least one human and one or more bots or humans
  • de-identification - removal of all information that could identify a party in a conversation. This includes PII as well as audio and video recordings. Voice recordings might be re-vocalized with a different speaker.
  • dialog - the captured conversation in its original form (e.g. text, audio or video)
  • encrypted form - encrypted JWE document with the JWS signed vCon form contained in the ciphertext
  • file - a data block either included or referenced in a vCon
  • object - JSON object containing key and value pairs
  • parameter - JSON key and value pair
  • party - an observer or participant to the conversation, either passive or active
  • payload - the contents or bytes that make up a file
  • PII - Personal Identifiable Information
  • PII masked - may include voice recordings, but PII is removed from transcripts and recordings (audio and video).
  • vCon - container for conversational information
  • vCon instance - a vCon populated with data for a specific conversation
  • vCon instance version - a single version of an instance of a conversation, which may be modified to redact or amend additional information forming a subsequent vCon instance version
  • vCon syntax version - the version for the data syntax used for form a vCon
  • signed form - JWS signed document with the unsigned vCon form contained in the payload
JSON Notation For the ease of documentation, the convention for notation used in this document is copied from sections 1.1-1.5 of .
  • Date - A string that MUST have the form of an date string as defined for the Date type in section 1.4 of .
  • "String" - a JSON string type
  • "UnsignedInt" - a positive JSON integer as defined in section 1.3 of .
  • "UnsignedFloat" - a positive JSON floating point number containing a decimal point as defined in section 6 of .
  • "Mediatype" - A "String" value that MUST be of the following form as defined in section 5.1 of : type "/" subtype
  • "ContentHash" - The string token value is generated using the same approach used in section 6 of . The relevant text is copied here for convenience and to remove the normative dependency. The hash string token values are formed from combining a string that defines the crypto algorithm used to generate the digest along with the Base64Url Encoded value of the SHA-512 hash, as defined in section 6.3 and 6.4 , of the body of the content at the given url. The hash algorithm is identified by "sha512". SHA-512 is part of the SHA-2 set of cryptographic hash functions defined by the US National Institute of Standards and Technology (NIST). Implementations MAY support additional recommended hash algorithms in ; that is, the hash algorithm has "Yes" in the "Recommended" column of the IANA registry. Hash algorithm identifiers MUST use only lowercase letters, and they MUST NOT contain hyphen characters. The character following the algorithm string MUST be a hyphen character, "-", or ASCII 45. The subsequent characters are the Base64Url encoded (see Section 2 ) digest of a canonicalized and concatenated string or binary data based on the JSON pointer referenced elements of "rcd" claim or the URI referenced content contained in the claim.
  • "SessionId" - An object with the String parameters: "local" and "remote". The String values of these parameters are UUIDs as defined in section 5 of as "local-uuid" and "remote-uuid". This is designed to also work with the H.323 correlated which refers to them as "Sender-UUID" and "Recipient-UUID". { "local": String, "remote": String }
  • "A[]" and array of values of type A.
All parameters are assumed to be mandatory unless other wise noted. Objects or arrays with no or null values MAY be excluded from the vCon.
Inline Files Objects that contain a file or data inline (i.e. within the vCon) MUST have the parameters: body and encoding. JSON does not support binary data values. For this reason inline files MUST be Base64url (see Section 2 ) encoded to be included as a valid JSON string value if they are not already valid JSON strings.
body The body parameter contains the payload of the file to be included inline. Depending upon the data in the file, it may require encoding to be used as a valid JSON string value.
  • body: "String"
encoding The encoding parameter describes the type of encoding that was performed on the string value of the body parameter. If the body parameter is provided and is not an empty string, the encoding parameter MUST be provided. In the interest of being tolerant for interoperability, if the encoding value is not provided, applications can attempt to derive the encoding token value based upon the mediatype parameter or filename extension if either is provided.
  • encoding: "String"
This MUST be one of the following strings:
  • "base64url": The payload of the file has been Base64Url encoded and provided as the string value of the body parameter.
  • "json": The value of the body string is a JSON object.
  • "none": The payload of the file is a valid JSON string and can be included without modification as the string value to the body parameter.
Externally Referenced Files Files and data stored externally from the vCon MUST be "signed" to ensure that they have not been modified. Objects that refer to a file which is externally stored from the vCon MUST have the parameters: url, content_hash. These parameters are defined in the following subsections. The values and format of the hashes are defined in type: ContentHash. The use of hash for ensuring that the externally referenced data or file has not been modified, is defined in this document. Other methods of ensuring integrity may be added in the future.
url The url value contains the URL where the externally referenced file is stored. HTTPS MUST be used for retrieval to protect the privacy of the contents of the file.
  • url: "String"
content_hash The integrity of externally referenced files are protected using a hash of the external content. The algorithm and hash value are contained in the content_hash parameter. The value of the content_hash can be a single token or an array of tokens if multiple hash algorithms are desired to be provided. The SHA-512 algorithm MUST be supported. Other algorithms MAY be included. The algorithm used for signing the externally referenced file is defined in section 6.3 and 6.4 of .
  • content_hash: "ContentHash" | "ContentHash[]"
Extending vCon vCon provides a means to extend the schema defined in this document. A vCon extension can define new parameters at any level of the schema. It can also redefine the semantics of or deprecate existing parameters. To do so, a new extension definition MUST do the following: * Define a new token value and register it with IANA (see examples)) * Define the new parameter(s), their meaning, value types and register them with IANA * Define the new semantics and values for change parameters * List deprecated parameters, what should be used in its stead and migration approaches * Use snake case naming convention for parameter names (as opposed to camel case) Extensions to the vCon schema can be classified into two categories:
  • Compatible: These extensions introduce additional data or fields without altering the meaning or structure of existing elements. Implementations that do not recognize these extensions can safely ignore them while maintaining valid processing of the vCon.
  • Incompatible: These extensions modify existing semantics or schema definitions in ways that render a vCon incompatible with implementations that do not support the extension. Interpreting such a vCon correctly requires explicit awareness of the extension.
Wherever feasible, extensions SHOULD be designed as Compatible to preserve compatibility with existing implementations. The question of Compatible vs Incompatible is a little subjective. A transcriber for vCon can be fairly tolerant of changes adding new parameters or objects to a vCon. On the other hand, a redactor must be aware of the implications of all parameters in the vCon to be sure to redact all of the objective information. In these cases a transcriber will likely only need to look at the critical extensions. However the redactor perhaps should reject vCons with any extension that it does not support. However, when disruptive extensions are necessary, the names of all such extensions MUST be listed in the critical parameter of the vCon. This allows implementations to determine whether they are capable of processing the vCon safely and accurately. Implementations that encounter a vCon containing a disruptive extension listed in the critical parameter, but do not support that extension, MUST NOT process the vCon except to reject it or notify the user.
vCon JSON Object The JSON form of a vCon is contained in a JSON object in one of three forms:
  • unsigned
  • signed
  • encrypted
The unsigned form of the vCon has a single top level object. This top level vCon object is also contained as described in the signed and encrypted forms of the vCon. The selection of the JSON format enables interchange between application and lower layers of the network stack, critical for enablement of analysis of conversations. The signed form of vCon is defined in using to provide integrity and proof of the conversation data. The encrypted form of vCon is defined in to provide complete privacy of the conversational data. Partial privacy or data minimization can be provide for a vCon using the construct.
Unsigned Form of vCon Object The unsigned form of the top level vCon object is necessary as in many cases, a vCon will be partially constructed and in process as conversation data is collected. This may change while the conversation is in progress or on-going. The vCon may start with only meta data and party information, then progress to contain dialog information. It may then get analysis added or it could be passed to another security domain for analysis. A vCon may be constructed across several security domains. When a vCon is to be exported from one security domain to another, it SHOULD be signed or encyrpted by the domain that constructed it. The subsequent domain may have need to redact or amend data to the vCon. Alternatively the originating domain may want to redact the vCon before providing it to an other domain. The second or subsequent domain, MAY modify the prior vCon instance version and when complete or exporting to another security domain, it SHOULD sign or encrypt the new vCon instance version. The new vCon instance version SHOULD refer to the prior vCon instance version via the redacted () or amended () parameters.
vCon JSON Object Keys and Values The keys and values for the top level vCon JSON object are defined in the following subsections.
vcon The "vcon" parameter is DEPRECATED as of the publication of this document as an RFC. The "vcon" parameter was used to differentiate schema changes to the vCon core container when incompatibilities were created in Internet-Draft versions. The extension mechanism replaces the need for schema versioning. The vcon parameter was used to contain the syntactic version of the JSON format used in the vCon. (see Non-Upward Compatible Changes to the vCon Container)
  • vcon: "String"
For syntax defined in this document, the string MUST have the value: "0.4.0"
uuid The for the vCon is used to refer to it when privacy or security may not allow for inclusion or URL reference to a vCon. The UUID MUST be globally unique.
  • uuid: "String"
The value of the string SHOULD be generated using the version 8 UUID defined in which is generated identically to a version 7 UUID with the exception that:
  • rand_b/custom_c is generated from the high 62 bits of the SHA-1 hash of the FQHN string
  • the variant and version fields are set as described for version 8 UUID
The DNS name string used in generating the uuid value SHOULD be the same FQHN, or a subdomain to allow for more distributed generation of UUIDs, as would used in the signing certificate as they are the same domains of uniqueness.
extensions The vCon schema can be extended through the definition of new extensions. The extensions parameter SHOULD contain the list of names of all vCon extensions for any parameters used that are not defined in this core vCon schema document.
  • extensions: "String[]"
critical Implementations that include extensions which are incompatible with the core vCon schema MUST list the names of those extensions in the critical parameter. A vCon that includes a critical parameter indicates that correct interpretation of the vCon requires explicit support for the listed extensions. An implementation that does not recognize or support the extensions listed in the critical parameter MUST NOT attempt to process or operate on the vCon, except to reject it or report unsupported content.
  • critical: "String[]"
created_at The created_at parameter provides the creation time of this vcon, which MUST be present, and should not changed once the vcon object is created.
  • created_at: "Date"
updated_at The updated_at parameter provides the last modified time of this vcon, which MAY be present. For unsigned forms, the updated_at of the vcon object SHOULD be updated as it is modified. For signed forms of the vCon object, the updated_at contains the time when this vcon was last signed. Future updates MUST first set the updated_at to the new signing time as the vcon object is signed again.
  • updated_at: "Date"
subject The subject or the topic of the conversation is provided in the subject parameter. This parameter is optional as not all conversations have a defined subject. Email threads and prescheduled calls and video conferences typically have a subject which can be captured here. The subject may also be derived from analysis of the dialog.
  • subject: "String" (optional)
The string value of the subject parameter is a free formed JSON string with no constrained syntax.
redacted A redacted vCon SHOULD provide a reference to the unredacted or prior, less redacted, vCon instance version of itself. The purpose of the Redacted Object is to provide the reference to the unredacted or less redacted version of the vCon from which this vCon was derived. For privacy reasons, it may be necessary to redact a vCon to construct another vCon without the PII. This allows the non-PII portion of the vCon to still be analyzed or used in a broader scope. The Redacted Object SHOULD contain the uuid parameter and MAY include the url, content_hash parameters (see Externally Referenced Files). If a reference to the unredacted vCon is provided in the url parameter, the access to that URL MUST be restricted to only those who should be allowed to see the identity or PII for the redacted vCon. The method(s) for redaction of text, audio and video can be done with existing post processing of media. The method of redaction is out of scope of this document. The assurance of the accuracy of the redaction is made by the entity that creates the redaction which SHOULD sign the redacted version of the vCon. All data and parameters in the prior, less redacted, vCon instance version are either:
  • Removed entirely in the redacted version
  • Copied and partially redacted
  • Copied as is
Data which is to be completely removed from the redacted version, that is contained in a JSON array in the unredacted vCon, SHOULD create an empty placeholder such that object array indices do not change for the rest of the elements of the array.
  • redacted: "Redacted" (optional, mutually exclusive with amended and group parameters)
Redacted Object A Redacted Object contains the following parameters:
  • uuid: "String"
The value contains the uuid string value of the unredacted/prior vCon instance version. The absence of a value for uuid indicates that the less redacted version of this vCon is not available or does not exist.
  • type: "String"
The value of the redacted type parameter is used to indicate the type of redaction that was performed on this vCon relative to the less redacted version referenced by the redacted uuid parameter. This should indicate the type of information that was redacted. The the location of the referenced vCon MAY be provided as defined in Externally Referenced Files by including url and content_hash. content_hash MUST be included if url is provided.
  • url: "String"
  • content_hash: "ContentHash" | "ContentHash[]"
The following diagram illustrates an example partial JSON object tree for a redacted vCon. The top level object is a JWS signed vCon which contains a vCon in the unsigned form in the payload parameter. The second level object is the redacted vcon which refers to the encrypted unredacted vCon in it's redacted parameter. Note that the redacted vCon references the JWE encrypted vCon by UUID and may reference it by URL or direct inclusion. The JWE encrypted unredacted vCon contains the signed version of the unredacted vCon in the ciphertext parameter. The signed unredacted vCon contains the unredacted vCon in the unsigned form in it's payload parameter.
redacted vCon object tree | JWE uuid-|-- uuid in unprotected Encrypted signed | | unredacted vCon: | cyphertext-|--- JWS signed --------------- / unredacted vCon / in cyphertext /-------------------/ parameter / / ------------- Signed -> |JWS uuid-|-- unredacted vCon uuid in header unredacted vcon: | | | payload-|-- unsigned unredacted vCon ------------- \ in payload \ ---------- -->| vCon | Unsigned unredacted vCon: | | ---------- ]]>
amended A signed or encrypted vCon cannot be modified without invalidating it. In these cases, to allow for adding of additional information a new vCon instance version MUST be created. The prior vCon instance version is referenced by the Amended Object. The vCon with amended data contains all of the data that is in the referenced vCon with the exception of data that is amended. That is to say that the newer version of the vCon is a deep copy of the prior version with the amended and additional data added to it. The prior vCon instance version SHOULD be referenced via the uuid of the prior vCon instance version, and MAY include the url and content_hash parameters (see Externally Referenced Files).
  • amended: "Amended" (optional, mutually exclusive with redacted and group parameters)
Amended Object The Amended Object contains the following parameters:
  • uuid: "String" (optional if inline or external reference provided)
The value contains the uuid string value of the unredacted/original vCon instance version. The location of the referenced vCon MAY be provided, as defined in Externally Referenced Files by including url and content_hash. content_hash MUST be provided if url is provided.
  • url: "String"
  • content_hash: "ContentHash" | "ContentHash[]"
The following figure illustrates an example partial JSON object tree for an amended vCon. The top level object is the JWS signed amended vCon which contains the unsigned form of the vCon in it's payload parameter. The second level object is the amended vCon with additional conversational data (e.g. analysis data). It refers to its original parent (or prior vCon instance version) of the vCon in its amended parameter. Note: the amended parameter may refer to the prior version of the vCon via URL. The amended vCon in this figure refers to the JWS signed version of the vCon, which in turn contains the original vCon in unsigned form in its payload parameter.
amended vCon object tree | JWS uuid-|-- original vCon uuid in header signed | | original vCon: | payload-|--- payload parameter ------------ / contains unsigned / original vCon ------------- / Original vCon: |vCon |<-- | | | parties | | dialog | ------------- ]]>
parties Objects Array The name, identity or contact information of all of the parties involved with the conversation are included in the parties object array. Whether the parties were observers, passive or active participants in the conversation, they each are included as a Party Object in the parties array.
  • parties: "Party[]"
The value of the parties parameter is an array of Party Objects.
dialog Objects Array The actual conversation which occurred over text, audio or video that was captured, is contained in the dialog Objects Array.
  • dialog: "Dialog[]" (optional)
The value of the dialog parameter is an array of Dialog Objects. It should be noted that the Dialog Objects may not be sorted in chronological order. They are in the order that they were added. It is the applications responsibility to sort dialog and transcriptions if they are needed in chronological order.
analysis Objects Array Analysis, which is performed on the conversational data, is stored in the analysis Objects array.
  • analysis: "Analysis[]" (optional)
The value of the analysis parameter is an array of Analysis Objects.
attachments Objects Array Ancillary documents, discussed, presented, referenced or related to the conversation may be stored in the attachments array. It should be noted that the Attachment Objects may not be sorted in chronological order. They are in the order that they were added.
  • attachments: "Attachment[]" (optional)
The value of the attachments parameter is an array of Attachment Objects.
Party Object A Party Object contains information about a specific party or particiant in the conversation. The information that is available about the party varies with the context, the communcaiton mode and platform. There are times when no information is available for a party either intially or over the entire life of the vCon. In such situations, it is possible to have a Party Object with no parmaters in it. A Party Object SHOULD be created for each participant. This may result in more than one empty Party Object. They are distinct by the order or index in the Party Object array.
tel If the tel URL for the party is known, it can be included in the tel parameter.
  • tel: "String" (optional)
The value of the tel parameter SHOULD be a valid URL. The URL scheme prefix (i.e. "tel:") is optional.
sip The URL for the party can be provided in the sip parameter.
  • sip: "String" (optional) The value of the sip parameter is the addr-spec as defined in section 25.1 of .
stir If the STIR was provided to identify the party, the PASSporT can be included in the stir parameter for the party.
  • stir: "String" (optional)
The string value of the stir parameter contains the in the JWS Compact Serialization form.
mailto If the mailto URL is known for the party, it can be included in the mailto parameter.
  • mailto: "String" (optional)
The value of the mailto parameter is a string of the format of a valid URL. The URL scheme prefix (i.e. "mailto:") is optional.
name If the party's name is known, it can be included in the name parameter.
  • name: "String" (optional)
The string value of the name parameter is a free form JSON string in which part or all of the party's name can be included. It may be necessary, for privacy reasons, to not identify any information about the party. This MAY be indicated by creating a Party Object with only the name parameter and setting its value to "anonymous". A Party Object SHOULD be create for each anonymous party in the conversation. This is necessary to capture the number of parties and distiction between which party contribued what data or dialog in the conversation. Hence it is possible to have multiple anonymous Party Objects in the vCon. They are distinct by the order or index in the Party Object array.
did If a Decentralized Identifier is known for the party, it can be included in the did parameter.
  • did: "String" (optional)
The value of the did parameter MUST be a valid DID URI that enables verifiable, decentralized digital identity for the party. DIDs are designed to be decoupled from centralized registries and identity providers, allowing the controller of the DID to prove control without requiring permission from other parties. The DID can refer to any subject (person, organization, thing, etc.) as determined by the controller of the DID.
validation Proof of authorization of the communication channel through STIR, login or possession of a device, is often not sufficient proof of the identity of the person at the other end of the communications channel. It is common in call centers to validate the identity of the person on the communication channel through verification of some sort of personal identification information. The methods used, often varies with the situation and is business practices specific. The purpose of the validation parameter, is to allow the validator to save a label or token which identifies the method of identity validation used to identify the person at the other end of the communication channel. For confidentially reasons, it SHOULD NOT contain the data used to validate the name. However it MAY name the data used to validate the name (e.g. "SSN", "DOB", "user ID and password"). It is up to the domain creating the vCon to define the set of tokens or values to be used for the validation parameter.
  • validation: "String" (SHOULD be provided if name parameter is provided)
The value of the validation string MAY be "none" or enterprise or domain defined token or string values.
gmlpos If the geolocation of the party is known, it can be added in the gmlpos parameter. The gmlpos parameter contains the latitude and longitude of the location of the party at the time of the conversation start.
  • gmlpos: "String" (optional)
The gmlpos parameter value contains a string of the same format as the gml:pos element defined in section 3.2 of the PIDF.
civicaddress The the civicaddress parameter value contains a Civicaddress Object which is optional and contains civic address information about the location for the party.
  • civicaddress: "Civicaddress" (optional)
The Civicaddress Object MAY contain any or all of the following parameters: country, a1, a2, a3, a4, a5, a6, prd, pod, sts, hno, hns, lmk, loc, flr, nam, pc as defined in section 2.2.1 of . The values of all of these parameters are of type String. Note that the parameter names MUST be in lower case when contained in the Civicaddress Object even though they are in upper case in .
  • country: "String" (optional)
  • a1: "String" (optional)
  • a2: "String" (optional)
  • a3: "String" (optional)
  • a4: "String" (optional)
  • a5: "String" (optional)
  • a6: "String" (optional)
  • prd: "String" (optional)
  • pod: "String" (optional)
  • sts: "String" (optional)
  • hno: "String" (optional)
  • hns: "String" (optional)
  • lmk: "String" (optional)
  • loc: "String" (optional)
  • flr: "String" (optional)
  • nam: "String" (optional)
  • pc: "String" (optional)
uuid The uuid is a unique identifier for the participant. In a contact center, this is particularly important for the call agent participant, and must be static across interactions to allow correlation with the actual agent configuration provisioned into the systems.
  • uuid: "String" (optional)
Dialog Object The Dialog object references or contains text, audio or video captured from the conversation. Currently four types of dialog objects are defined in this document:
  • Text based media communications
  • Audio or Video recorded media communications
  • Metadata for failed or incompleted communications
  • Metadata for providing relationships between other Dialog Objects in transfer scenarios
Media-based Dialog Objects (type text and recording) SHOULD contain only media that is transcribable. Media that is transcribable can be converted into a textual representation of sequential communication between parties. While images such as sunsets, cows, photographs of documents, or application forms may be describable, they are not transcribable in a concise manner and SHOULD NOT be included as Dialog Objects. They SHOULD be included as Attachment Objects. Text and audio may be subject to interpretation, but they are transcribable to a precise dialog representation. Although transcriptions may not always be accurate, there exists a single correct transcription for any given content. Media that is not transcribable SHOULD be included in the vCon as Attachment Objects rather than Dialog Objects. For example, a fax or photograph of a text-based letter is transcribable and MAY be included as a Dialog Object. Most other faxes and photographs SHOULD be included as Attachment Objects and SHOULD NOT be included as Dialog Objects. Similarly, a musical recording, even if it is in MP3 audio format, SHOULD be included as an Attachment and SHOULD NOT be included as a Dialog Object. It may not always be known at the time of vCon construction whether an image or recording is transcribable. When uncertain, the default SHOULD be to include images as Attachment Objects and audio or video recordings as Dialog Objects. This distinction is important for interoperability. If it is ambiguous as to what belongs in a Dialog Object versus an Attachment Object, interoperability cannot be achieved, as vCon constructors will not be able to consistently determine where content should be placed and users of vCons will not know where content can be found within the vCon. There are situations when no information is available for a dialog either intially or over the entire life of the vCon and yet it is known that the dialog occurred. For example this may occur in some call transfer cases where there is nothing known about the consultative call. In such situations, it is possible to have a Dialog Object with no parmaters in it. There may even be more than one empty Dialog Object. They are distinct by the order or index in the Dialog Object array.
type
  • type: "String"
The sting MUST have the value of either "recording", "text", "transfer" or "incomplete". A dialog of type "recording" has Dialog Content that either contains a body or refers to via url, which is a recording of the video and/or audio of a segment of the conversation. A dialog of type "text" had has Dialog Content that either contains a body or refers to via url, which contains the text from one of the parties for a segment of the conversation. A dialog of type "transfer" does not capture actual conversation exchange, but rather captures operations, parties and relations between dialog segments. A dialog of type "incomplete" or "transfer" MUST NOT have Dialog Content. In the "incomplete" case the call or conversation failed to be setup to the point of exchanging any conversation. Incomplete Dialog Objects MUST have a disposition parameter which indicates why the call or conversations failed. In the "transfer" case, the conversation is recorded in other Dialog Objects. The Dialog Transfer parameters, are used to show the roles and relationships between the parties and other Dialog Objects as the transfer process occurred.
start The start parameter contains the date and time for the beginning of the captured piece of dialog. For text it is the time that the party started typing or if not available, then it is the time the text was sent. For audio and video recordings, it is the time which corresponds to the beginning of the recording. It should be noted that Dialog Objects may not be ordered by the value of the start parameter. Dialog Objects in the dialog array are in order that they were added to the vCon and cannot be reordered with out correcting the dialog indices which occur in other Objects in the vCon.
  • start: "Date"
duration The duration parameter contains the duration in seconds of the referenced or included piece of dialog. For text, if known, it is the time duration from when the party started typing to when they completed typing and the text was sent. For recordings, it is the duration of the recording.
  • duration: "UnsignedInt" | "UnsignedFloat" (optional)
The value MUST be the dialog duration in seconds.
parties The party(s) which generated the text or recording for this piece of dialog are indicated in the parties parameter.
  • parties: "UnsignedInt" | "UnsignedInt[]" | ("UnsignedInt" | "UnsignedInt[]")[]
Single channel recordings should have a parties value of the form: "UnisignedInt" or "UnsignedInt[]" where the integer value or array of integer values are the indices to the Party Object(s) in the parties array that contributed to the mix for the single channel recording. The index for the Party Object SHOULD be included even if the indicated party was silent the entire piece of dialog. Multi-channel recordings MUST have a parties value that is an array of the same size as the number of channels in the recording. The values in that array are either an integer or an array of integers which are the indices to the parties that contributed to the mix for the associated channel of the recording. The index for Party Objects SHOULD be included even if the party was silent the entire conversation. It is implied that the first party in the dialog Object parties list, is the originator of the dialog. However, in some situations, it is difficult to impose the constraint that the first channel of a recording is the originator. If ensuring that the first channel and party listed is the originator is not possible, the optional originator parameter indicates the originator party. In other cases, there may be a separate recording file for each party in a conversation, where only one party is recorded per file. In this situation, it is necessary to indicate the originator as the dialog Object parties parameter may contain only one party and may not be the originator. It should be noted that the recordings may be shorter than the collective conference when there is a separate recording per speaker/party. For example the recording(s) of the individual speaker may be trimmed to only the parts where they are actually speaking. In the email context, messages have the headers From, To, Cc and Bcc that all correspond to parties to the text Dialog Object. The From header should be the first party index in the parties parameter for the text Dialog Object. They are the implied originator. The parties listed in the To, Cc and Bcc headers (if present) should all be added in that order to the parties parameter in the text Dialog Object. The sender SHOULD be allowed to set a policy, through out of band means, as to whether they would like their application or server to include the Bcc parties in the vCon. A text Dialog Object should only contain a single message. Each may have a different set of parties.
originator The originator party for this dialog. For email and text, this is the sender of the text. For audio and video, this is the caller or host of the call or conference. The originator parameter is only provided if the first party of the dialog Object parties list is NOT the originator.
  • originator: "UnsignedInt" (optional)
The originator value is the index into the parties Objects Array, to the party that originated the dialog.
mediatype The media type for the piece of dialog included or referenced is provided in the mediatype parameter. The mediatype parameter MUST be provided for inline dialog files and MUST be provided if the Content-Type header in the response for the externally referenced URL is not provided.
  • mediatype: "Mediatype" (optional for externally referenced files, if absent, this is provided in the Content-Type header)
The media types SHOULD be one of the following strings:
  • "text/plain"
  • "audio/x-wav"
  • "audio/x-mp3"
  • "audio/x-mp4"
  • "audio/ogg"
  • "video/x-mp4"
  • "video/ogg"
  • "multipart/mixed" Note: multi-part will also likely include the boundary parameter
filename It is sometimes useful to preserve the name of the file which originally contained this piece of dialog. This can be done in the filename parameter.
  • filename: "String" (optional)
Dialog Content The Dialog Object SHOULD contain the body and encoding parameters or the url and content_hash parameters for all dialog types other than "incomplete" and "transfer", these parameters MUST NOT be present for "incomplete" or "transfer" dialog types (see Inline Files and Externally Referenced Files). The exception to this is that the body or url MAY be absent if it is redacted. For inline included dialog:
  • body: "String" (optional in an a redacted vCon)
  • encoding: "String"
Alternatively, for externally referenced dialog:
  • url: "String" (optional in an a redacted vCon)
  • content_hash: "ContentHash" | "ContentHash[]"
disposition If the dialog type is "incomplete", it must have a disposition parameter. The value of the disposition parameter provides the reason that the "call control" failed. The term: "call control" is used in a loose sense, as there in not always a call involved, to differentiate from a call disposition that an agent may assign to a call to indicate the reason, issue addressed or outcome of a conversation. This latter definition of call disposition is not dialog, but analysis of the conversation and is not included in the dialog portion.
  • disposition: "String" (required for incomplete type Dialog Objects, SHOULD NOT be present for other dialog types)
The value of the disposition parameter MUST be one of the following string:
  • "no-answer" - a call or connection was attempted, but no one answered or accepted the connection
  • "congestion" - a call or connection was attempted, but was unable to be completed due to system load
  • "failed" - a call or connection was attempted, but failed
  • "busy" - a call or connection was attempted, but the party was busy with another conversation
  • "hung-up" - a call or connection was made, but the party hung-up before any conversation occurred
  • "voicemail-no-message" - a call or connection was made, the voicemail system answered, but no message was left Note: if a message was left with the voicemail system this is no longer an "incomplete" type dialog, it is a "recording" type and the conversation SHOULD be included in the Dialog Content.
session_id The MAY be included for the dialog. If the same applies to all the parties in a dialog, than a single instance of the SessionId Object is provided as the value of session_id. If some parties have a different or no associated for this Dialog Object, then the array structure of the session_id objects MUST correlate to the array structure of the Dialog Object's parties index array. Parties which do not have a associated with this dialog, MUST have an empty object ({}) for the SessionId Object. That an empty Object and not an Object with two "nil UUIDs" as defined in section 7 of . It is also possible that the SessionId Object will not have values for both the local and remote parameters in some conferencing situations (See ). In the case that one end of the [SESSION-ID} does not have a UUID, the "nil UUID" String value SHOULD be used as defined in section 7 of .
  • session_id: "SessionId" | "SessionId[]" | ("SessionId" | "SessionId[]")[] (optional)
party_history Objects Array Participants in a dialog may not all join and leave at the same time. To support the capturing of the information when parties join, drop, go on hold or mute and unmute, the party_history array may be added to the Dialog Object.
  • party_history: "Party_History[]" (optional)
Party_History Object The Party_History Object contains the following parameters:
  • party: "UnsignedInt" The index of the party for this event.
  • time: "Date" The time at which this event occurred.
  • event: "String" The string token for the event which MUST be one of the following:
    • "join" - when the party joins the dialog
    • "drop" - when the party drops out of the dialog
    • "hold" - when the party is put on hold
    • "unhold" - when the part is taken off hold
    • "mute" - when the party is muted
    • "unmute" - when the part is taken off mute
    • "keydown" - when a DTMF or application key/button was pressed
    • "keyup" - when a DTMF or application key/button was released
  • button: "String" - (required for keydown and keyup events)
The button parameter value is the String value of the DTMF digit, character or string label for the button that was pressed or released.
Dialog Transfer A dialog of type "transfer" documents the rolls of three parties and the relationship between 2 or three dialog segments. In a transfer operation, the roles of the three parties to a transfer are defined in as:
  • Transferee
  • Transferor
  • Transfer Target
There are two or three calls in which the parties are connected:
  • original call
  • consultative call (optional as this call may not get created)
  • target call
To capture the above roles and dialog segments, the following parameters are defined and SHOULD be present in the "transfer" type dialog and MUST NOT be present in other dialog types.
  • transferee: "UnsignedInt"
The value of the transferee parameter is the index into the parties Object array to the party that played the role of the Transferee.
  • transferor: "UnsignedInt"
The value of the transferor parameter is the index into the parties Object array to the party that played the role of the Transferor.
  • transfer_target: "UnsignedInt" | "UnsignedInt[]"
The value of the transfer_target parameter is the index into the parties Object array to the party that played the role of the Transfer Target. The consultation, target_dialog and transfer parameters all refer to the Dialog Objects that correspond to the 2 to 3 calls that are part of a transfer. These calls may end up spread across multiple Dialog Objects due to the nature of how the calls are recorded. For example each party may be recorded in a separate file which will result in a dialog for each. Alternatively a call may go on hold where recording is stopped and back off again resulting where recording is started again in a separate recording file, resulting in multiple Dialog Objects. For this reason, the values for the consultation, target_dialog and transfer parameters MAY have a single UnsignedInt or an array of UnsignedInt. There are scenarios where we know that a transfer has occurred, but we have no Dialog Object information for one or two of the consultation, target or transfer calls. In this case an empty Dialog Object is created and its index is used for the consultation, target_dialog or transfer parameter. A unique Dialog Object SHOULD be referenced for each role in the transfer. However a Dialog Object may be referenced in more than one transfer dialogs when multiple transfers occur.
  • original: "UnsignedInt" | "UnsignedInt[]"
The value of the original parameter is the index/indices into the dialog Object array to the "recording" or "text" type Dialog Object for the original dialog between the Transferee and the Transferor.
  • consultation: "UnsignedInt" | "UnsignedInt[]" (optional)
The value of the consultation parameter is the index/indices into the Dialog Object array to the "recording", "text" or "incomplete" type Dialog Object for the consultative dialog between the Transferor and the Transfer Target. It is also possible for there to be more than one consultation. This may occur for a number of reasons. Call attempts may fail. The caller may decide the consultation with a party is not the desired transfer target.
  • target_dialog: "UnsignedInt" | "UnsignedInt[]"
The value of the target_dialog parameter is the index/indices into the Dialog Object array to the "recording", "text" or "incomplete" type dialog for the target dialog between the Transferee and the Transfer Target. A "transfer" type dialog MUST NOT contain the parties, originator, mediatype, filename or Dialog Content parameters. The "transfer" type dialog only captures the roles, operations and events of the parties and the dialog setup. It does not capture the purpose or reason for the transfer as that is analysis to be captures in the analysis section of the Vcon after the conversation has occurred.
application The application parameter is used to capture the application, communication channel or context over which the conversation was held. The conversation mode can be identified by looking at the dialog type. However that does not different between different communication platform service providers or hosting service. For example, the application parameter can be used to identify the web conference hosting service.
  • application "String" (optional)
message_id Some messaging systems assign a unique message identifier to each message. The message_id parameter may be used to label the message for either cross referencing back to the messaging system or to prevent the addition of duplicate messages to the vCon. For example SMTP messages have a message-id in the SMTP header. In the SMTP case a message may exist in multiple mailboxes or tags. When exporting these SMTP messages, the message_id parameter may be used to avoid adding the same message, to the vCon containing the email thread, more than once.
  • message_id: "string" (optional)
Attachment Object Ancillary documents to the conversation are included or referenced in the Attachment Object. There is no constraint on the types files which can be included or referenced. As most modes of communication, that allow the exchange of files, do not constrain the file type, any file type may be included here.
purpose The purpose parameter may be used to provide a text base description of the purpose or point of the attachement. There is no restriced set of values for this description.
  • purpose: "String" (optional)
start The start parameter contains the date and time that the Attachment Object was sent/exchanged. It should be noted that Attachment Objects may not be ordered by the value of the start parameter. Attachment Objects in the attachments array are in order that they were added to the vCon and cannot be reordered with out correcting the attachment indices which may occur in other Objects in the vCon.
  • start: "Date"
party In most conversations, ancillary documents originate from one of the parties to the conversation. This is not necessarily the author, but the person who distributed the document. This party is identified by the party parameter in the Attachment Object.
  • party: "UnsignedInt"
The value of the party parameter is the index into the Party Object array to the party that contributed the attachment.
dialog Attachments are added as data related to the dialog. The dialog parameter is used to identify the dialog that the attachment is part of. The dialog is identified by the index to the dialog Object in the dialog objects array.
  • dialog: "UnsignedInt"
mediatype The media type for the included or referenced attachment file is provided in the mediatype parameter.
  • mediatype: "Mediatype" (optional for externally referenced files, if absent, this is provided in the Content-Type header)
The mediatype string contains the media type or type of the attached file.
filename It is sometimes useful to preserve the name of the file which originally contained this attachment file. This can be done in the filename parameter.
  • filename: "String" (optional)
The file name string contains an optional name for the attachment file referenced in this Attachment Object.
Attachment Content The Attachment Object SHOULD contain the body and encoding parameters or the url and content_hash parameters (see Inline Files and Externally Referenced Files). The exception to this is that the body or url MAY be absent if it is redacted. For inline included attachments:
  • body: "String"
  • encoding: "String"
Alternatively, for externally referenced attachments:
  • url: "String"
  • content_hash: "ContentHash" | "ContentHash[]"
Analysis Object Analysis is a broad and in some cases developing field. This document does not attempt to suggest a SHOULD support list of types. Nor are formats for analysis data defined in this document. That is for research and specification outside the scope of this document. For this reason the Analysis Object provides multiple ways to define the media type of the analysis file. If a well known media type is defined, it SHOULD be used. For analysis data or files types for which a media type is not defined, the vendor and schema parameters SHOULD be used.
type The type parameter is used to label the semantic type of analysis data.
  • type: "String"
TODO: this list is not sufficient. Do we enforce a specific set of tokens. Seems like analysis has a pretty huge set of possibilities. The string value SHOULD be one of the following:
  • "report"
  • "sentiment"
  • "summary"
  • "transcript"
  • "translation"
  • "tts"
dialog Analysis typically pertains to one or more of the Dialog Objects in the dialog array. The dialog parameter is used to indicate which Dialog Objects this analysis was based upon.
  • dialog: "UnsignedInt" | "UnsignedInt[]" (optional only if the analysis was not derived from any of the dialog)
The value of the dialog parameter is the index to the dialog or array of indices to the Dialog Object array to which this analysis object corresponds.
mediatype The media type for the included or referenced analysis file is provided in the mediatype parameter.
  • mediatype: "Mediatype" (optional for externally referenced files, if absent, this is provided in the Content-Type header)
The mediatype string contains the media type or type of the analysis file.
filename It is sometimes useful to preserve the name of the file which originally contained this analysis data. This can be done in the filename parameter.
  • filename: "String" (optional)
The file name string contains an optional name for the analysis data file referenced in this Analysis Object.
vendor There may not be a IANA registered media type for the file format containing the analysis data. Even if a media type is defined, it is often useful to keep a record of the vendor that produced the software that produced the analysis. Different implementations perform differently and knowing the implementation can be useful in interpreting the analysis. For this reason, the vendor or product name is provided in the vendor parameter.
  • vendor: "String"
The vendor string value contains the vendor or product name of the software which generated this analysis.
product As the vendor may have more than one product, the product parameter may be used to differentiate it from other products which may have different schemas of analysis data.
  • product: "string" (optional)
schema The same vendor or software product may produce different formats or data for the same analysis. The schema parameter allows the data format, schema or configuration used to generate the analysis to be saved with the included or referenced analysis data.
  • schema: "String" (optional)
The schema string contains a token or label for the data format or schema for the analysis data. As the vendor name may not be specific enough to identify the format of the analysis, the schema value is provide to differentiate from potentially multiple data formats for analysis provided by the same vendor or software.
Analysis Content The Analysis Object SHOULD contain the body and encoding parameters or the url and content_hash parameters (see Inline Files and Externally Referenced Files). The exception to this is that the body or url MAY be absent if it is redacted. For inline included analysis:
  • body: "String"
  • encoding: "String"
Alternatively, for externally referenced analysis:
  • url: "String"
  • content_hash: "ContentHash" | "ContentHash[]"
Security Considerations The security concerns for vCons can put into two categories: making the conversation immutable through integrity verification and protecting the confidentiality of privacy of the parties to the conversation and/or their PII. These requirements along with need to evolve a vCon (e.g. adding analysis, translations and transcriptions) conflict in some ways. To enable this, multiple versions of a vCon may be created. Versions of a vCon may add information (e.g. analysis added to a prior vCon referenced by the amended ()) and versions that remove information (e.g. redactions of privacy information removed from the vCon referenced in the redacted ()). Redactions may be at different levels for example:
  • PII masked to remove PII data in the text, audio, video or transcripts
  • De-identified to remove segments or whole recordings that might be used for voice printing or facial recognition
Different parts and versions of a vCon may be created in different security domains over a period of time. In addition, some conversation data may be referenced externally through an HTTPS URL as opposed to completely contained within the vCon. Typically a conversation of one mode, will be hosted or observed in a single domain. This will likely fall into one of the following hosting situations:
  • Enterprise Hosted Communications
  • Software as a Service (SaaS) Hosted Communications
  • Service Provider Hosted Communications
The distinction among these has gotten clouded over recent years. The import consideration is that each is a different security domain. Information about a conversation captured in an enterprise communications system (e.g. meta data and Dialog Object(s) recorded in an IP PBX) is a different security domain from a SaaS transcription service (i.e. an Analysis Object). Before a vCon leaves a security domain, it SHOULD be signed to prevent it from being altered. If the new security domain needs to alter it, a new vCon is created with the removed or added data and the prior version is referenced (i.e. via the redacted () or amended ()). See the redacted vCon object tree figure-1 and amended vCon object tree figure-2. If information is redacted for privacy reasons, the vCon referenced in the redacted (), if inline, SHOULD be encrypted to protect the privacy information in the unredacted version of the vCon. The secure storage and access of externally referenced conversation data is considered out of scope from this document. Secure mechanisms for HTTPS access and storage of files are well defined. Identity and credentials for accessing externally stored data will be exchanged out of band from the vCon. The one requirement for externally referenced data from the perspective of this document, is proof of integrity of that data. Using the above described approach for redaction and amending of data, we can reduce the security operations on a vCon to signing and encryption. Two approaches to signing are needed as we have data, in JSON format, that is contained within the vCon and may have data (typically media and file formats, often binary) not contained, inline in the vCon, that is externally referenced. Externally referenced data will be "signed" using hash which along with the URL of the externally referenced data is included in the vCon. was chosen due to the relatively low cost to generate and verify the signature for what could be very large externally referenced media files. As the hash for each externally referenced file is contained in the vCon which will be signed, the chain of authentication is provided via the signature on the vCon itself. This document specifies the JSON format for vCons. So it seemed the logical solution for signing vCons, is JOSE JSON Serialization and likewise for encrypting vCons is JOSE JSON Serialization. The solutions are well documents, implementations are readily available and tested. Methods of redaction exist for text, audio and video using post processing of the media. The method of redaction used is out of the scope of this document. A redacted vCon SHOULD reference it's non-redacted version. The non-redacted version of the vCon referenced from the redacted vCon MUST be encrypted such that only those with permission to view the non-redacted content can decrypt it. Any time a vCon is shared outside its original security domain, it SHOULD be signed and optionally encrypted. Files externally referenced by a vCon SHOULD always be signed with the verification information included in the vCon that references the external file as defined in Externally Referenced Files and Signing Externally Referenced Files. Externally referenced files SHOULD only be transported over and SHOULD be access controlled to those who are permitted to read the contents of that non-redacted vCon. vCons transported over non-secure channels such as email MUST be in the encrypted form.
Signing Externally Referenced Files In some deployments, it is not practical to include all of the file contents of a vCon inline. In support of that, a file may be externally referenced. When external files are referenced, the signature on the vCon does not secure the file contents from modification. For this reason any externally referenced files SHOULD also have a signature. vCons use the hash method for integrity checking of externally referenced file content and include its url and content_hash in the vCon which are included in the integrity signature for the whole vCon. After retrieving externally referenced files, before using its content, the payload of the HTTPS request should be verified using the signature parameter value for the hash for the url body using the procedure defined in section 6.3 and 6.4 of .
Signed Form of vCon Object A signed vCon uses and takes the General JWS JSON Serialization Syntax form as defined in section 7.2.1 of . The vCon General JWS JSON Serialization MUST include x5c or x5u in the unprotected header.
  • payload: "String"
The value of the payload is the Base64Url Encoded string containing either: the unsigned form of the JSON vCon; or the gzipped unsigned form of the JSON vCon. The general construction of the payload string value is described in section 7.2.1 of
  • signatures "Signature[]"
The value of signatures is an array of Signature Objects
Signature Object The Signature Object MUST contain a header, protected and signature parameter as defined in section 7.2.1 of .
  • header: "Header"
The value of header is defined in Header Object
  • protected: "String"
  • signature" "String"
Header Object The Header Object and its contents are defined in section 4 of . The Header Object for a signed vCon MUST include the alg and either the x5c or x5u arrays. The x5c or x5u requirement makes the management and use of vCons easier, allowing the certificate chain to be found as the vCon is moved.
  • alg: "String"
The string value of alg is defined in section 4.1.1 of . For a signed vCon this value SHOULD be "RS256" to maximize interoperability.
  • x5c: "String[]" (MUST provide x5c or x5u)
The array of string values for x5c are defined in section 4.1.6 of .
  • x5u: "String" (MUST provide x5c or x5u)
The string value of x5u MUST contain an URL as defined in section 4.1.5 of .
  • uuid: "String" (SHOULD be provided)
The string value of the UUID for the vCon contained in the payload parameter. This is added for convenience to not require verification of the signed vCon to get it's UUID. When the vCon is verified, the value of this uuid parameter SHOULD be verified against the UUID in the signed vCon.
Long Term Archiving of Signed vCons In some use cases, it may be necessary to store or archive signed vCons for compliances or records purposes for as long as 10 years or more. In most cases the keys and certificates used to sign the vCon and construct the or signed form of the vCon, will have an expiration on the order of a few years at best. Below is an apporach on how integrety may be maintained on the archived vCon. There may be other approaches to this as well. For our example illustrated below, we have a vCon which was signed (labeled as JWS1). The certificate used to sign JWS1 has an expiration date. Before the expiration of the JWS1 signing certificate, the content of JWS1 (the vCon) is verified and then JWS1 is signed as the payload to construct JWS2. Before the expiration of the JWS2 certificate, the contents of JWS2 (JWS1) is verified and then JSW2 is signed as the payload to construct JWS3. The process is continued for the life of the vCon archiving. When it is desired to access the data in the archived vCon, first the outer JSW (JWS3 in diagram) is verified (payload of JWS2), then the vCon (payload in JWS1) is assumed to have valid integrety.
Encrypted Form of vCon Object A vCon MUST be signed first using JWS as defined in Signed Form of vCon Object, then encrypted using JWE as opposed to just encrypted with integrity protection. The rationale is that meta data and dialog will typically be collected in one security domain, then may be stored or exported to another. The signing is likely for the lifetime of the vCon, where the encryption may be shorter term or domain specific. vCons may be stored in unencrypted form, but the signed form MUST be maintained to ensure its integrity. A encrypted vCon uses and takes the General JWE JSON Serialization Syntax form as defined in section 7.2.1 of .
  • unprotected: "Unprotected"
  • recipients: "Recipient[]"
  • iv: "String"
The string value of iv is the Initialization Vector as constructed as defined in section 7.2.1 of .
  • ciphertext: "String"
The string value of ciphertext is constructed as defined in section 7.2.1 of using the signed form of the vCon as the plaintext input for encryption.
  • tag: "String"
The string value of tag is the the Authentication Tag as defined in section 7.2.1 of .
Unprotected Object
  • cty: "String"
The string value of cty SHOULD be either "application/vcon" or "application/vcon+gzip"
  • enc: "String"
The string value of enc SHOULD be "A256CBC-HS512"
  • uuid: "String" (SHOULD be provided)
The string value of the UUID for the vCon contained in the ciphertext parameter. This is provided for identification of the encrypted vCon without the need of the key to decrypt the vCon. The value of this uuid parameter SHOULD be verified when the vCon is decrypted.
Recipient Object
  • header: "Header"
  • encrypted_key: "String"
The string value of encrypted_key is defined in section 7.2.1 of .
Header Object
  • alg: "String"
The string value of alg SHOULD be "RSA-OAEP".
Differentiation of unsigned, signed and encrypted forms of vCon vCons in the unsigned, signed and encrypted form are all valid JSON. It is necessary to distinguish which form a vCon is in order to properly handle it. For example a signed vCon needs to be verified. The following is the recommended approaches to identifying which form a particular vCon is in:
  • unsigned The presence of one or more of the following parameters indicates that the vCon is in the unsigned form:
    • parties
    • dialog
    • analysis
    • attachments
  • signed (JWS) The presence of both of the following parameters indicates that the vCon is in the signed (JWS) form:
    • payload
    • signatures
  • encrypted (JWE) The presence of both of the following parameters indicates that the vCon is in the encrypted (JWE) form:
    • ciphertext
    • recipients
IANA Considerations This section includes the information required for IANA to register the application/vcon media type per .
JSON Format vCon Mediatype The JSON format for vCon is mandatory to implement.
  • Type name: application
  • Subtype name: vcon
  • Required parameters: N/A
  • Optional parameters: N/A; unrecognized parameters should be ignored.
  • Encoding considerations: 8bit
  • Additional information: format
  • Security considerations: See Security Considerations section of this document.
  • Interoperability considerations: The vCon schema is defined in RFC XXXX. The schema may be extended through extensions as defined there.
  • Published specification: [VCON], this document: RFC XXXX
  • Applications that use this media type:
  • Fragment identifier considerations: N/A
  • Additional Information:
    • Deprecated alias names for this type: N/A
    • Magic number(s): N/A
    • File extension(s): "vcon"
    • Macintosh file type code(s): N/A
    • Windows Clipboard Name: VCON
  • Author: See the Author's Addresses section of this document.
  • Change controller: IETF
gzip Format vCon Mediatype A gzip format vCon is a JSON format vCon that has been compressed using the gzip compression algorithm. The gzip format is used to reduce the size of potentially very large vCons containing audio or video media in dialog objects. Applications SHOULD support the receiving of gzip format vCons, but do not need to use the gzip format when sending.
  • Type name: application
  • Subtype name: vcon+gzip
  • Required parameters: N/A
  • Optional parameters: N/A; unrecognized parameters should be ignored.
  • Encoding considerations: binary
  • Additional information: compression of format
  • Security considerations: See Security Considerations section of this document.
  • Interoperability considerations: The vCon schema is defined in RFC XXXX. The schema may be extended through extensions as defined there.
  • Published specification: [VCON], this document: RFC XXXX
  • Applications that use this media type:
  • Fragment identifier considerations: N/A
  • Additional Information:
    • Deprecated alias names for this type: N/A
    • Magic number(s): N/A
    • File extension(s): "vcon"
    • Macintosh file type code(s): N/A
    • Windows Clipboard Name: VCON
  • Author: See the Author's Addresses section of this document.
  • Change controller: IETF
vCon JSON Registry This document defines a number of new IANA registries for the JSON vCon schema. Each Object (i.e. dict, map, dictionary) has its own registry of parameter names. All of those registries have the same registry template which is defined in the following subsection. When registering new entries, the following template should be used.
Object Registry Template Parameter Name: The string name of a parameter to be used within the Object. The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Parameter Description: Brief description of the parameter Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
vCon Object Parameter Names Registry The following defines the initial values for the vCon Object Parameter Names Registry. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
vcon Schema version number IESG RFC XXXX
uuid vCon instance UUID IESG RFC XXXX
extensions list of extensions used IESG RFC XXXX
critical list of incompatible extensions used IESG RFC XXXX
created_at creation date IESG RFC XXXX
updated_at modification date IESG RFC XXXX
subject conversation subject IESG RFC XXXX
redacted Redacted Object IESG RFC XXXX
amended Amended Object IESG RFC XXXX
group reserved for future extension IESG RFC XXXX
parties Party Objects array IESG RFC XXXX
dialog Dialog Objects array IESG RFC XXXX
analysis Analysis Objects array IESG RFC XXXX
attachments Attachment Objects array IESG RFC XXXX
Party Object Parameter Names Registry The following defines the initial values for the Party Object Parameter Names Registry. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
tel tel URL IESG RFC XXXX
sip SIP URL IESG RFC XXXX
stir STIR token IESG RFC XXXX
mailto mailto URL IESG RFC XXXX
name participant name IESG RFC XXXX
validation validation method IESG RFC XXXX
gmlpos participant geolocation IESG RFC XXXX
civicaddress civic address IESG RFC XXXX
uuid participant UUID IESG RFC XXXX
Dialog Object Parameter Names Registry The following defines the initial values for the Dialog Object Parameter Names Registry. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
type dialog type name IESG RFC XXXX
start dialog start time IESG RFC XXXX
duration dialog duration period IESG RFC XXXX
parties dialog parties list IESG RFC XXXX
originator dialog originator party IESG RFC XXXX
mediatype dialog content media type IESG RFC XXXX
filename dialog content filename IESG RFC XXXX
body dialog inline content IESG RFC XXXX
encoding dialog inline content encoding IESG RFC XXXX
url dialog referenced content URL IESG RFC XXXX
content_hash dialog content hash IESG RFC XXXX
disposition dialog disposition IESG RFC XXXX
session_id RFC7989 session ID IESG RFC XXXX
party_history dialog party events history IESG RFC XXXX
transferee transferee party index IESG RFC XXXX
transferor transferor party index IESG RFC XXXX
transfer_target transfer target party index IESG RFC XXXX
original original transfer dialog index IESG RFC XXXX
consultation consultation`transfer dialog index IESG RFC XXXX
target_dialog target_dialog transfer dialog index IESG RFC XXXX
application dialog source application IESG RFC XXXX
message_id dialog message id IESG RFC XXXX
Dialog Type Name Registry This document defines a new registry for the token name values that are permitted as values to the dialog type parameter.
Dialog Type Name Registration Template Dialog Type Name: The string token name of a Dialog Object Type The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Dialog Type Description: Brief description of the Dialog Object type Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
Dialog Type Name Registration Initial Values The following table defines the initial values for the Dialog Object Types Registry.
Dialog Type Name Dialog Type Description Change Controller Specification Document(s)
text text dialog IESG RFC XXXX
recording recording dialog IESG RFC XXXX
transfer transfer dialog IESG RFC XXXX
incomplete incomplete dialog IESG RFC XXXX
party_history Object Parameter Names Registry This initial values for the party_history Object Parameter Names Registry are listed in the following table. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
party event party index IESG RFC XXXX
time time event occurred IESG RFC XXXX
event event type IESG RFC XXXX
party_event Event Name Registry This document defines a new registry for the token name values that are permitted as values to the party_event Object event parameter.
party_event Event Name Registration Template party_event Event Name: The string token name of a party_event Object event type. The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. party_event Event Description: Brief description of the party_event Object Event Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
party_event Type Name Registration Initial Values The following table defines the initial values for the Dialog Object Types Registry.
party_event Event Name party_event Event Description Change Controller Specification Document(s)
join party join event IESG RFC XXXX
drop party drop event IESG RFC XXXX
hold party on hold event IESG RFC XXXX
unhold party off hold event IESG RFC XXXX
mute party on mute event IESG RFC XXXX
unmute party off mute event IESG RFC XXXX
keydown DTMF/app key/button press event IESG RFC XXXX
keyup DTMF/app key/button release event IESG RFC XXXX
Attachment Object Parameter Names Registry The following defines the initial values for the Attachment Object Parameter Names Registry. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
purpose atachment object purpose description IESG RFC XXXX
start attachment start time IESG RFC XXXX
party sending party index IESG RFC XXXX
dialog associated dialog index IESG RFC XXXX
mediatype attachment body media type IESG RFC XXXX
filename attachment content filename IESG RFC XXXX
body attachment inline content IESG RFC XXXX
encoding attachment inline content encoding IESG RFC XXXX
url attachment referenced content URL IESG RFC XXXX
content_hash attachment content hash IESG RFC XXXX
Analysis Object Parameter Names Registry The following defines the initial values for the Analysis Object Parameter Names Registry. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
type analysis type IESG RFC XXXX
dialog associated dialog index IESG RFC XXXX
mediatype analysis body media type IESG RFC XXXX
filename analysis content filename IESG RFC XXXX
vendor vendor producing content IESG RFC XXXX
product vendor product producing content IESG RFC XXXX
schema product schema of content IESG RFC XXXX
body analysis inline content IESG RFC XXXX
encoding analysis inline content encoding IESG RFC XXXX
url analysis referenced content URL IESG RFC XXXX
content_hash analysis content hash IESG RFC XXXX
Redacted Object Parameter Names Registry The following defines the initial values for the Redacted Object Parameter Names Registry. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
uuid less redacted vCon UUID IESG RFC XXXX
type redaction type or reason IESG RFC XXXX
url referenced less redacted vCon URL IESG RFC XXXX
content_hash less redacted vCon hash IESG RFC XXXX
Amended Object Parameter Names Registry The following defines the initial values for the Amended Object Parameter Names Registry. Use the template in Object Registry Template when registering additional entries to this table.
Parameter Name Parameter Description Change Controller Specification Document(s)
uuid prior vCon version UUID IESG RFC XXXX
url referenced prior version vCon URL IESG RFC XXXX
content_hash prior version vCon hash IESG RFC XXXX
vCon Extensions Names Registry This document defines and new registry for the token name values that are permitted as values to the [extensions]s(#extensions) parameter. However it does not define any values for this registry. Values for this registry are to be defined in subsequent documents which define extensions to the vCon schema.
Extensions Registration Template Extension Name: The string token name of an extension to the vCon JSON schema. The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Extension Description: Brief description of the the vCon extension Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
JSON Web Signature and Encryption Header Parameters This document registers the following new parameter in the JSON Web Signature and Encryption Header Parameters registry.
  • Header Parameter Name: "uuid"
  • Header Parameter Description: UUID of the signed object
  • Header Parameter Usage Location(s): JWS
  • Change Controller: IESG
  • Specification Document(s): Header Object of RFC XXXX
JSON Web Signature and Encryption Unprotected Parameters TODO: cannot find this registry This document registers the following new parameter in the JSON Web Signature and Encryption Unprotected Parameters registry.
  • Header Parameter Name: "uuid"
  • Header Parameter Description: UUID of the encrypted object
  • Header Parameter Usage Location(s): JWE
  • Change Controller: IESG
  • Specification Document(s): Header Object of RFC XXXX
Non-Upward Compatible Changes to the vCon Container
Version 0.3.0 to 0.4.0
  • The "appended" Object was renamed to "amended"
  • The "must_support" parameter was renamed to "critical" to be consistent with other IETF JSON schema extension mechanisms.
  • The "session_id" Dialog Object parameter was changes from a String to a SessionId Object.
Version 0.0.2 to 0.3.0
  • "transfer-target" parameter was renamed to "transfer_target" to be consistent with other compound names that use the underscore ("_").
  • "target-dialog" parameter was renamed to "target_dialog" to be consistent with other compound names that use the underscore ("_").
Version 0.0.1 to 0.0.2
  • "mimetype" parameters were renamed to "mediatype"
  • "alg" and "signature" were combined into "content_hash"
References Normative References Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Decentralized Identifiers (DIDs) v1.0 W3C A Presence-based GEOPRIV Location Object Format This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK] GZIP file format specification version 4.3 This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. COSE Algorithms n.d. End-to-End Session Identifier for H.323 Systems H.460.27 The JSON Meta Application Protocol (JMAP) This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. JSON Web Signature (JWS) JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE) JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. JSON Web Key (JWK) A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. The 'mailto' URI Scheme This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK] Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] PASSporT: Personal Assertion Token This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. [STANDARDS-TRACK] End-to-End Session Identification in IP-Based Multimedia Communication Networks This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP). This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document. This document obsoletes RFC 7329. Simple Mail Transfer Protocol This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] The tel URI for Telephone Numbers This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK] New UUID Formats This document presents new Universally Unique Identifier (UUID) formats for use in modern applications and databases. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format ISO/IEC 14496-12:2022 JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) Federal Information Processing Standard, FIPS SIP: Session Initiation Protocol This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] Session Initiation Protocol (SIP) Call Control - Transfer This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. PASSporT Extension for Rich Call Data Somos Inc. Neustar Inc. This document extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network and is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases. jCard: The JSON Format for vCard This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications. vCon: an Open Standard for Conversation Data STROLID Inc. SIPez LLC Conversational X TADHack and TADSummit n.d. Recommendation Q.825: Specification of TMN applications at the Q3 interface: Call detail recording ITU n.d. Python open source vCon command line interface, library and workflow server n.d.
Example vCons This appendix contains example vCons in the unsigned, signed and encrypted form. The JSON has been indented for readability. The vCons have been formatted such that long text lines have been wrapped with a left hand white space indent for readability purposes. Links for unformatted versions of the vCons are provided for each of the examples. The example vCons in this document were generated using the command line interface.
Two Party Call vCon With Inline Recording This example vCon is for a simple 2 party PSTN call. It has a single Dialog Object which contains a single channel wav format recording with the two parties audio mixed into the single channel. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_call_int_rec.vcon
Email Thread Multipart vCon The following is an unsigned form of an vCon for a 2 message email thread between 2 parties. The email messages are multipart MIME message bodies. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_email_acct_prob_thread.vcon
Alice:
Please find the image attached.

Regards,
Bob

\r\n--- ---=_Part_388313_805631480.1663969465697--\r\n\r\n------= _Part_388314_1108189513.1663969465698\r\nContent-Type: im age/png\r\nContent-Transfer-Encoding: base64\r\nContent-D isposition: attachment; filename=\"=?UTF-8?b?c2NyZWVuc2hv dC5wbmc=?=\"\r\nContent-ID: \r\n\r\niVBORw0KGgoAAAANSUhEUgAAACYAAA AeCAIAAADPdvs5AAAAA3NCSVQICAjb4U/gAAAAGXRFWHRT\r\nb2Z0d2F yZQBnbm9tZS1zY3JlZW5zaG907wO/PgAAALpJREFUSInl1t0NgzAMBOC7 qPvP1gW6Qjdo\r\nj4f0J4qAJI6NROvniE8+mwCvtzv6imTnyf1K/UclH UFWjIvaIL3CHCABSPKKtJckWfY6zw+sj5dq\r\nISdVIzmj2klzTZG2Rm e7NKgOwY6qPrMcUs+2PqchL14P+oyz+fHx77K5Sv8xyxAyZ0uBaxn/Spc U\r\n8NxcosAut1Y3NtjVX7UjZlmpgWTSFyvVQPKB16tSqW53bFnKtyyZ vYT3rSsAWADWAlOjseYFfwAA\r\nAABJRU5ErkJggg==\r\n\r\n----- -=_Part_388314_1108189513.1663969465698--\r\n", "message_id": "<1126698042.388315.1663969465698@mail.yahoo. com>" }, { "type": "text", "start": "2022-09-23T21:44:59.000+00:00", "duration": 0, "parties": [ 1, 0 ], "mediatype": "multipart/alternative; \n\tboundary=\"----=_P art_390234_811845464.1663969499935\"", "encoding": "none", "body": "------=_Part_390234_811845464.1663969499935\r\nCon tent-Type: text/plain; charset=UTF-8\r\nContent-Transfer- Encoding: 7bit\r\n\r\n Hi Bob:Got it. Thanks.\r\n\r\n On Friday, September 23, 2022, 9:44:40 PM UTC, Bob wrote: \r\n \r\n Alice:Please find the image a ttached.\r\n\r\nRegards,Bob\r\n \r\n------=_Part_390234_ 811845464.1663969499935\r\nContent-Type: text/html; chars et=UTF-8\r\nContent-Transfer-Encoding: 7bit\r\n\r\n
\r\n
Hi B ob:
Go t it. Thanks.


\r\n \r\n
\r\n
\r\n \r\n
\r\n On Friday, September 23, 2022, 9:44:40 PM UTC, Bo b <b@example.com> wrote:\r\n
\ r\n

\r\n
\r\n
Alice:
Please find the image attached.
< /div>

Regards,
Bob< /div>

\r\n
\r\n
\r\n------=_Par t_390234_811845464.1663969499935--\r\n", "message_id": "<2031327240.390235.1663969499936@mail.yahoo. com>" } ], "analysis": [], "attachments": [], "created_at": "2025-03-02T00:39:02.990+00:00", "redacted": {}, "subject": "Account problem", "uuid": "0195544a-cc55-8d85-b9a2-279e0d16bc46" } ]]>
Email Thread Text vCon The following is an unsigned form of an vCon for a 3 message email thread between 2 parties. The email messages are plain text message bodies. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_email_prob_followup_text_thread.vcon " }, { "type": "text", "start": "2022-09-23T23:34:32.000+00:00", "duration": 0, "parties": [ 1, 0 ], "mediatype": "text/plain; charset=UTF-8", "encoding": "none", "body": "Hi Alice:\nAll is fine. Thanks.\n\n On Friday, September 23, 2022, 23:24:59 PM UTC, Alice wrote: \n \n Hi Bob:\n I just wanted to follow up to see that your account is ok now.\n \n Regards,\n Alic e\n", "message_id": "<1126698042.388315.1663969465698@mail.yahoo. com>" }, { "type": "text", "start": "2022-09-23T23:38:12.000+00:00", "duration": 0, "parties": [ 0, 1 ], "mediatype": "text/plain", "encoding": "none", "body": "Awesome!\n\n On Friday, September 23, 2022, 23: 34: PM UTC, Bob wrote: \n\n Hi Alice:\n All is fine. Thanks.\n \n On Friday, September 23 , 2022, 23:24:59 PM UTC, Alice wrote: \n \n Hi Bob:\n I just wanted to follow up to see t hat your account is ok now.\n \n Regards,\n Alic e\n", "message_id": "<2031327240.390235.1663969499936@mail.yahoo. com>" } ], "analysis": [], "attachments": [], "created_at": "2025-03-02T00:39:04.591+00:00", "redacted": {}, "subject": "Account issue followup", "uuid": "0195544a-d292-8cda-b9a2-279e0d16bc46" } ]]>
Two Party Call vCon With Externally Referenced Recording This example vCon is for a simple 2 party PSTN call. It has a single Dialog Object which reference a single channel wav format recording with the two parties audio mixed into the single channel. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_call_ext_rec.vcon
Two Party Call vCon with Analysis TODO: fix diarization in transcript The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_call_ext_rec_analysis.vcon
Signed vCon This example vCon is the signed form of the Two Party Call vCon With Externally Referenced Recording example. The private key used to sign this can be found at: The certificate chain is included in the x5c parameter of the header Object. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_call_ext_rec_signed.vcon
Encrypted vCon This example vCon is the encrypted form of the Signed vCon example. The private key to decrypt it can be found at: The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_call_ext_rec_encrypted.vcon
Redacted vCon This is an example redaction of the vCon in the example Two Party Call vCon With Externally Referenced Recording. Most notable is the Redacted object which references the lesser redacted version of this vCon. In addition the url parameter has been redacted from the Dialog Object, but the rest of the Dialog Object was left in the redaction. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_call_ext_rec_redacted.vcon
Amended Signed vCon This is an example vCon with an Amended Object referencing the vCon that it amends or adds additional content. In this case it is referencing the signed vCon example above. An example text Dialog Object (index 1) is the amendment. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/examples/ab_call_ext_rec_amended.vcon
vCon JSON Schema This JSON schema is provided as informational. The text in secions 1-6 of this document define the normative definition of the vCon schema. If the JSON schema provided below differs from that in the text of the above sections, the text should be taken as the definitive definition and the JSON Schema below should be consider incorrect. The JSON Schema definition below has been formatted with line breaks to print nicely on the page. The unformatted version of the JSON schema can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/vcon_json_schema.json
Acknowledgments
  • Thank you to Thomas McCarthy-Howe for inventing the concept of a vCon and the many discussions that we had while this concept was developed into reality.
  • Thank you to Jonathan Rosenberg and Andrew Siciliano for their input to the vCon container requirements in the form of I-D: draft-rosenberg-vcon-cc-usecases.
  • Thank you to Rohan Mahy for his help in exploring the CDDL schema and CBOR format for vCon and testing out the extension framework with MIME.
  • The examples in this document were generated using the command line interface (CLI) from the py-vcon python open source project.
  • Thank you to Steve Lasker for formatting and spelling edits.
  • Thank you to Mike Jones for input and help media types, version and helping to form the extension framework.
  • Thank you to Jonathan Lennox for numerous inputs including separate single channel recordings per party and the extension framework.
  • Thank you to Marc Petit-Huguenin for sorting out session_id.
  • Thank you to Rob Sliwa for heling to review and test the JSON Schema.
  • Thank you to Mike Jones, Richard Barnes and Mike Ounsworth for their help with providing an approach to maintaining integrety for long term storage of signed vCons.