search

aws-samples / aws-virtual-participant-framework-for-rtc

Apache License 2.0
48 stars 11 forks source link

amazon-transcribe-lca-virtual-participant-connector-for-zoom-meeting #22

Open vincentwi opened 1 year ago

vincentwi commented 1 year ago

hoping to see the released code for amazon-transcribe-lca-virtual-participant-connector-for-zoom-meeting now that it has been a few months. very curious how to set up a virtual device for TTS synthesis, thank you!

sinasojoodi commented 1 year ago

Right? Time flies 😅. Thank you for your interest in this project.

A couple of questions:

  1. Amazon Transcribe Call Analytics (LCA) works for 2 participants only today [option 1] and is really designed around caller/agent workflows. Other types of call analytics can use parts of LCA architecture and implementation, but would require a very different user experience/frontend. Are you still interested in that caller (customer) and agent workflow?
  2. We could think of scenarios where you can have one caller and multiple agents, e.g. a supervisor being treated like another agent [option 2]. Or even a more complex scenario of having multiple participants but they can only take the role of either caller or agent [options 3]. This is to stay within the bounds of the current LCA UX; but with speaker identity attribution. Which one of options 1, 2, 3 would best serve your workflows?

Option 1 is easy to implement and we have made a demo of it already. Option 2 is more complicated but less so if there is a max number of agents that can join a call (2 or 3). Option 3 is slightly more complicated both in the UI and significantly more complicated if number of participants is nondeterministic and could be >5. Any context you can provide me (reach out to me directly if you need) could help us weigh design options.