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

Hi everyone,

I have built a Microsoft Teams Calling Bot using Application-Hosted Media based on the official C# EchoBot sample:

https://github.com/microsoftgraph/microsoft-graph-comms-samples/tree/master/Samples/PublicSamples/EchoBot

Currently, our signaling logic is fully serverless and runs efficiently on Azure Functions. However, the actual media processing (using the C# Calling SDK which relies on native Windows media binaries) is deployed on VMSS with Windows Server, just like the repository's default deployment guide suggests.

Running these Windows VMs continuously is becoming extremely expensive, and we are looking for a cheaper, modern, or "on-demand" alternative to handle the media pipeline.

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

1. Windows Containers (ACI / AKS): Has anyone successfully run this C# EchoBot/Media SDK inside Windows Containers (such as Azure Container Instances or AKS)? If so, how do you handle the public IP and port-binding requirements for the media sockets (since the platform needs direct public connectivity for UDP/TCP traffic)?

2. On-Demand Provisioning: Are there any known architectures or best practices for spinning up the media processor only when a call starts (e.g., triggering an ACI instance via the Azure Function signaling bot) and tearing it down afterwards to keep costs near zero when idle?

3. Alternative Approaches: If you have solved this high-infrastructure cost problem for a real-time raw audio bot in production, what architecture did you end up using?

Any documentation, GitHub references, or architectural advice would be highly appreciated!

Thanks!