## vCon "Bof"   {#vcon-bof}

*   Not an offical WG, as the charter not approved yet. However,we
    expect an approval in 30 days with our current charter. We just
    can't make decisions.

## JDR Requirements   {#jdr-requirements}

*   Overview of contact center technologies
*   Compliance issues
*   Quality Management
*   Speech Analytics
    *   What was spoken
    *   Angry customers, etc.

### Two flows:   {#two-flows}

*   Real time or post call recording transfer, including call meta data
    and call events - needs to be shared with consumer
*   Desktop recording - not connected but also required and do a post
    call/upload overnight to supporting applications

### Meta Data Fields:   {#meta-data-fields}

*   Interaction types
*   Interaction ID
*   File Type
*   Media meta data: bitrate, channels
*   Start time
*   Duration
*   Direction of call
*   Partipant details
*   PII and PCI Redaction
*   Skill
*   Campaign
*   Transferred Indicator
*   Conference Indicattor
*   Count transfers, conferences, holds
*   Hangup parth
*   Disposition
*   Dialing list

## Emergency Call vCON Use Case - Brian Rosen   {#emergency-call-vcon-use-case---brian-rosen}

### Emergency Calls are Citizen to Authority   {#emergency-calls-are-citizen-to-authority}

*   regulated carriers 3 digit dial code (911)

IETF ecrit defined standards for emergency calls, routing of call based
on location.

Participants in an emergency call

*   caller
*   call taker
*   dispatcher
*   responders
*   all calls logged for legal purposes and QA by logging service
*   Privacy restrictions otherwise in force are waived

3 most important things about emergency calls:location

Location is used to get to the right PSAP and responder

Start of the call

*   qs for calls at PSAPS
*   You can get a busy, really want to avoid
*   True skill based routing is rare
*   Media is negotiated: audio, video, text

Conversations

*   two way call always starts
*   Call is transferred to a dispatcher
*   Transfer is attended
*   Transfer to responder is rare, but same as attended
*   Data transfers usig standardized data is used to communicate
    incident data from call taker to dispatcher to responder

Logging

*   all is logged, we use SIP REC, playback with RTSP
*   All calls have a globally unique incident identifier

JDR: What is the unique ID requirement and what is the lifecycle?  
BR: We do it after the fact, but it depends on the actual use case.   
JDR: Wouldn't you want to keep this?  
BR: Depends when you make the vCon

Persons

*   We track people with an incident, including non-victims and
    bystanders

Operations on Conversation Data

*   Limited use of automated transcriptions, but changing
*   Logging is primarily for legal proceedings.

JDR: Name the examples of where this goes between vendors  
BR: First, vendor lock-in. Secondly, in nextgen 911 vcons are sent
during the incident.   
JDR: Also interesting in the failure network configuring use cases.

## Rohan Mahy, vCon for MIMI IM   {#rohan-mahy-vcon-for-mimi-im}

### Three Use Cases   {#three-use-cases}

*   Export conversation history from my old client to new device
*   Group chat with substantive discussion, then add some users. Allow
    an admin to "catch them up" by sharing message history from some
    relevant point in the past
*   Back up my messages

New elements  
From the MIMI content draft

*   Under the parties list, imUri
*   Dialog : array of individual dialog
    *   messageID: from mimi
    *   parties: who is active in the MLS room at this moment
    *   originator: party ID
    *   In reply to:
    *   replaces

Content format for MIMI does not have these fields, so have to do that.

RM: If they wanted to take this

## Dan   {#dan}

### Learnings   {#learnings}

A few things we added:

*   created\_at
*   updated\_at

GAP analysis, of use cases and requirements IDs  
Object signatures, how many variations of the same thing are we signing

Give vCon a try

## Conclusions   {#conclusions}

JDR: Lots of metadata. We should have a baseline format, with super
common stuff  
Cody: We are using vCons ourselves, looking at the extensions  
Cullen: We need an abstraction layer to define a core functional layer  
Brian: Maybe we actually want two layers, one well known, then one that
varies per application.