Migrating Teams Calling Bot (EchoBot) from VMSS to Windows Containers / AKS?

[jamil-z]

🏷️ Discussion Type

Question

Body

Hi GitHub Community,

I am seeking architectural advice from anyone who has modernized or scaled a Microsoft Teams Calling Bot.

I built our solution based on the official C# Microsoft Graph Calling sample (specifically the EchoBot project):
https://github.com/microsoftgraph/microsoft-graph-comms-samples/tree/master/Samples/PublicSamples/EchoBot

Currently, our signaling is handled serverless on Azure Functions, which works beautifully. However, the actual media processing (which relies on the native Windows C# Calling SDK binaries) is running on VMSS (Virtual Machine Scale Sets) with full Windows Server VMs.

Running these Windows VMs continuously is extremely expensive, and we want to migrate this media pipeline to a modern, cost-efficient, or "on-demand" containerized infrastructure.

Since raw audio processing strictly requires the native Windows-based Media binaries, I would like to ask:

1. Windows Containers (AKS): Has anyone successfully containerized this specific EchoBot / Skype Media SDK inside Windows Containers on AKS? If so, how did you handle the public IP and dynamic port-binding routing requirements for the media sockets?
2. On-Demand Processing: Are there any known patterns to dynamically spin up/tear down the media processor (e.g., launching an instance only when a call starts and killing it after) to avoid keeping idle Windows infrastructure running?
3. Alternative Solutions: If you have optimized costs for a production real-time raw audio bot, what architecture or hosting strategy did you use?

Any dynamic port-binding configs, dockerfiles, or architectural tips would be highly appreciated.

Thanks!

Guidelines

• I have read and understood this category's guidelines before making this post.