eDiscovery - How it works

General

eDiscovery receives info from 2 components:

  1. API - Chat and Files

  2. Proxy - Meeting info and activity of Audio, Video ,Desktop sharing and participants. This info is stored in Activity Auditing and is copied by the MNTS to the eDiscovery.

Audio Video means the activity that was done without the content. Chat and files include the content.

If A/V content is needed- you must deploy recording management

To get all type of content - both proxy and API are required

 

A meeting session is considered and Audio / Video activity

 

CasbAdapter ApplicationSettings.config

  • InitializeMessagingBL - true

  • EnableFetchingMessages - true

  • DataProcessingEnabled - true

  • EnableFetchingMemberships - true

  • GraphPaymentModel - A

  • PollingUsersMessages - false

  • pollingChatMessagesEnable - true

  • pollingChannelsMessagesEnable - false

  • EnableFetchingSharePointSites - true

 

eDiscovery data fields

Conversation Type- Message , File , Audio, Video , info (for auditing), Screen Sharing, unknown. Also Channel, Meeting for backwards computability

Conversation scope: Meeting, Channel, Chat, Group chat, Call, Space, Direct, Space Meeting.

Note: In Webex - Meeting refers to Schedule Meeting. Meeting started from a space refers to Space Meeting.

Session Type- All, Teams, Exchange, Skype for Business, OneDrive or SharePoint, OneDrive, SharePoint, Webex Teams, Webex Meeting, zoom, Slack, RingCentral, Audio Code. P2P, conference for backwards computability

 

Contestation host scope- Whether the room/ Teams in hosted internal or external

 

Content type:

Content type is an internal value of eDiscovery messages as a field in the eDiscovery table.

In eDiscovery messages table, the field content type can have the following values:

Html , Plain, Text, Rtf , File, Meeting, Video, Audio , Screen Sharing.

For records indicating an audio / video call that has started- the relevant values are set and are used when filtering eDiscovery media records.

 

Messages Thread:

For each message there is Parent message ID.
When it is empty (NULL) - it is a root message and actually starts a new thread, and the thread ID is this message ID.
When it has value - it is a reply message to the thread started with the parent (root) message.

Meeting and group chat

Participants list includes link to Auditing. For a managed user the link is to the auditing records with the “From” value that match and for non managed users the link is to auditing records with the “To” value that match.

Managed participants are determined by Auditing record, if a user appears in “From” value and the activity type is Audio than the user is managed.

Sample of Meeting record

Video and Share screen

Video and screen sharing are being copied from Auditing to eDiscovery when allowed.

Participants list contains all the user in the meeting while screen sharing or video events occurred.

Sample of Screen Sharing record

External Meetings

SphereShield eDiscovery can also capture communications from meetings that are hosted externally even if the domains are not federated.

 

Identifying and handling meeting and recurring meetings

Each meeting contains multiple calls.

A meeting is identified by meeting-ID

A call is identified by call-ID

 

Each session has meeting id and call id, so each call has a separate session in the eDiscovery DB

 

Recurring meetings are in fact the same meeting with multiple calls done every week.

 

Cases inspection

The whole flow is a part of messaging BL including getting data from DB and updating it.

The BL calls each application e.g. Webex to call its API and to fil the MESSAGING_QUEUE table.

After the application inserts to MESSAGING_QUEUE, the BL continues its processing including sending the email at the end

Need to configure this in Adapter config file -

CasesInspectionEnabled = true

 

What is captured for eDiscovery needs by SphereShield proxy and API