Build a Webinar Solution for Business Recordings with Symbl.ai

High-Level Architecture

What to Consider Before Integration Starts

Cloud Services

Recorded files:

• Available on public cloud storage to allow Symbl Async requests access for conversation analysis.
• Recorded files length – Symbl conversation Analysis supports files up to 4 hours

Database:

• Store Webinar recording’s metadata: meeting name, number of participants, participants names (If possible) , meeting date/time and more.
• Async request concurrency management – Symbl allows to have up to 50 active  requests per account of active Async APIs (scheduled, in_process) requests

Note: If in your concurrency requirements are greater than 50 consider Symbl option for a private tenant package. 

• Conversation analysis results

Serverless functions:

• Serverless functions should have access to relevant tables in database and/or storage endpoints and will serve the key for adding/managing/updating conversation analysis status to/from Symbl.
• HTTPS endpoint for the serverless function that serves as Async API WebHook endpoint.

Symbl

• Registered user account
• Valid token to use Symbl APIs
• Here are Symbl’s APIs to review and that will be used for this MVP integration:
  • Generate Token – Will be used to generate a valid token to use Symbl’s API. Token is valid for 24 hours.
  • Async POST Video URL API – This API is used for:
    • Digest and analyze the Webinar recordings.
    • In this API you will add most of the metadata like meeting name speaker diarization using the number of participants etc.
    • Once you run this API you will get conversationId and jobId. conversaitonId will be used for later Conversations API analysis and jobId will be used to see what is the jobId analysis status.
    • In this API you will send a WebHook endpoint to a specific serverless function to get the jobId status in order to know when the job is completed.
  • Create Pre-built UI using Experience API – This API result will provide a link of the Pre-Build UI of the Webinar and will include the transcripts, insights  and more. For MVP the link will be wrapped with iFrame.
  • Summarization API (Labs non-production feature) – This is a pre-alpha feature and can be used to show the meeting summary before along with the Pre-Built UI option.
• Get job status (Optional) – This is a good practice to check the jobId in case the process time goes beyond 40% of recording duration length.

Integration Steps – Initial infrastructure

Step 1: Database design

Here are a few things to consider to store when you design your database tables and fields:

1. Conversation-metadata“ table (Prior to Symbl conversation analysis):
   1. Unique identifier
   2. File name
   3. Datetime created
   4. File duration length
   5. Recording url
   6. Language code
   7. Time Zone
   8. Custom Vocabulary – In case there are specific words that are not common in the conversation spoken language having them will help in getting better results from Speech To Text
   9. Company/Business name –  In case you have different segments.
   10. Number of participants
   11. Recorded in separate channel (Optional for future separate channel option) – Recording can be recorded in mono channel or each participant is recorded in separate channel
   12. Participants names (Optional for future)
   13. Participants emails (Optional for future)
   14. Any other metadata you think should be included.
2. Symbl-Async-Request table – Holds the request unique identifiers and status associated with the request metadata that are created per Async API request:
   1. conversationId
   2. jobId
   3. jobId status
   4. Datatime created
   5. The unique identifier from Conversation-metadata table
3. Conversation-Intelligence-<names> tables –
   1. For MVP have a table for Conversation-Intelligence-PreBuiltUI with the following fields:
      1. conversationId
      2. Link – Taken from Experience API response (Symbl Pre Built UI usage)
   2. In case you would like to manage/aggregate different calls intelligence data and/or remove the analyzed data from your Symbl account, store the analyzed data in different tables per conversation API and the unique conversationId per conversation request.
4. Business-UX table for Symbl Pre Built UI usage to determine which design to provide to each Company/Business(Optional):
   1. Company/Business name
   2. Logo url
   3. Favicon url
   4. Additional UX configurations

Step #2.1: Create serverless function for adding/reusing new/existing recording

When a new recording and/or new metadata are created:

1. If recording file was not added: Add the new recording file to your storage
2. Add the conversation metadata to Conversation-metadata table
3. Add a new record to Symbl-Async-Request table:
   1. jobId status – pending
   2. Datetime – Current time
   3. jobId and conversationId with no value
   4. Unique identifier value from Conversation-metadata table
4. Trigger serverless function for managing requests in next step

Step #2.2: Create serverless function for managing requests

This serverless function can be triggered in two ways:

#1 – Serverless function trigger from step #2.1:

1. Query Symbl-Async-Request for how many active (scheduled, in_progress) are there:
   1. If active requests is less than max concurrent (Max is 50 requests):
      1. Query the oldest “pending” request record with no conversationId, jobId in Symbl-Async-Request
      2. Send the selected record to Symbl’s Async POST Video URL API request with:
         1. The serverless function webhook endpoint in body request
         2. Relevant fields that will be taken from metadata like name, url (Recording url), customVocabulary, etc. in body request
         3. Speaker separation method:
            1. In case each speaker was recorded in separate channel use the fields enableSeparateRecognitionPerChannel with the value true and channelMetadata with the relevant data in body request
            2. In case the recording was done only in one channel use the fields enableSpeakerDiarization with the value true and diarizationSpeakerCount with the number of participants in the conversation as part of query params
      3. Update the selected request in Symbl-Async-Request table with conversationId and jobId values returned from Async API response