search

microsoftgraph / microsoft-graph-comms-samples

Microsoft Graph Communications Samples
MIT License
211 stars 236 forks source link

Statefullness of the bot #708

Closed vigbav36 closed 8 months ago

vigbav36 commented 8 months ago

Going thru the code, I am wondering if there is no work around for the bot being stateful

If that is the case, then are there any suggestions on how we can configure this statefulness when we have multiple VMs in an AWS ecosystem (Apart from Kubernetes). Currently i have a Network load balancer and application load balancer on top of a single EC2 machine that does the job. But if i were to move to multiple machines, statefulness will be a point to consider.

InDieTasten commented 8 months ago

Calls are no request response type protocol. App-hosted media bots are actively connected to the meeting and are receiving / sending media in real-time. Do you expect to be able to receive bits and pieces of that communication on different machines? Do you expect to be able to send bits and pieces of that communication from multiple machines?

You will need to expose each machine with it's own media port on your public facing IP, so that when your bot handles a call, each instance of your bot can be addressed uniquely from the Teams platform. You can still load balance the initial incoming call notification. That is HTTP. You can route that to your machine pool via round robin. The machine that is selected answers the call with a) a media platform object that has a public address port combination and b) an http endpoint for receiving subsequent notifications for that call.

a) is usually done with different ports on a public IP b) is usually done with a reverse proxy that routes traffic based on a path segment

InDieTasten commented 8 months ago

Also, EC2 is not officially supported. Running bots outside of Azure VMs can lead to issues. But that's beside the main question I guess.

vigbav36 commented 8 months ago

Ahhh I was also thinking along the same line thanks. But curious abt the last comment tho, is it specified anywhere where running outside azure VM cud lead to problems or is this for windows servers in general.

InDieTasten commented 8 months ago

An application-hosted media bot requires the Microsoft.Graph.Communications.Calls.Media .NET library to access the audio and video media streams, and the bot must be deployed on a Windows Server machine or Windows Server guest Operating System (OS) in Azure.

Source

While developing and debugging locally (outside Azure), I haven't seen issues with running the bot. However, I do believe you will not be receiving support, when you are running outside of Azure. Other than that, I'm not sure what might happen, if there are ToS regarding that, or technical steps in place to enforce that kind of requirement, like IP banning. Maybe somebody from MSFT could also shine a light on that.

vigbav36 commented 8 months ago

Hmmm I see , thanks for the info

ssulzer commented 8 months ago

@vigbav36 @InDieTasten The bot media SDK does not have a hard, technical dependency on Azure; however, we do not officially support running the media SDK outside of Azure, and it is not a scenario we test. Furthermore, the Teams meeting the media bot is connected to is most definitely hosted within Azure and real-time media is transmitted over a lossy RTP/UDP stream. So, we recommend the bot’s media endpoint be in Azure, and ideally co-located within the same Azure data center region as the meeting itself, to minimize round trip time and packet loss. Depending on the join call flow, the platform can inform the bot what Azure region the meeting is hosted in ("mediaHostedRegion"): bot apps can use that to co-locate their bot endpoint. Once the bot receives the real-time meeting audio/video media, it can do whatever it wants with it, including transmitting it outside of Azure using less real-time lossless transports. Thanks.