Issue with Teams Bot: Incoming Call Event Not Reaching Bot (App-Hosted Media Sample)

Question

I am developing a Microsoft Teams bot that should be able to join a call initiated from a Teams user. The goal is that when a user places a call to the bot inside Teams, the bot should join the call and handle the audio stream as described in Microsoft’s documentation for application-hosted media bots.

I am following the official Microsoft documentation: https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/requirements-considerations-application-hosted-media-bots

And I am using the associated Microsoft sample from this GitHub repository: https://github.com/microsoftgraph/microsoft-graph-comms-samples/tree/master/Samples/V1.0Samples/LocalMediaSamples

The code builds successfully, but at runtime the bot does not receive the expected incoming call event when a Teams user tries to call it. Therefore, the bot never joins the call.

There are no compilation errors. The issue only happens during execution.

I have verified the following:

1. The bot is registered correctly in Azure Active Directory.

The bot is added as an app inside Teams (via Developer Portal).

The messaging endpoint is reachable and validated in Azure Bot registration.

The Windows Server VM hosting the bot is reachable externally.

Required ports are open based on Microsoft documentation.

The sample configuration has not been modified except for the App ID and App Secret.

The Teams user placing the call is in the same tenant as the bot’s app registration.

Environment details:

Windows Server 2019 Datacenter (Azure VM)

.NET Framework 4.7.2 (used because sample requires it)

Visual Studio 2022

Public IPv4 assigned

All inbound rules configured as per documentation

Observed behavior:

The sample starts but shows runtime failures related to media initialization.

No incoming call event is received from Teams.

The bot never joins the call.

No error appears in Teams UI besides “not reachable.”

What I need help with:

Confirmation whether the application-hosted media sample is still expected to work with current Teams calling APIs.

Validation whether my configuration is correct based on the documentation.

Guidance on which network ports must be configured in 2024/2025 for media processing.

Clarification whether Windows Server 2019 is still a supported environment for this scenario.

Any known issues that may prevent the incoming call event from reaching the bot.

I will share any runtime logs or correlation IDs that support requests once the case is opened.

Thank you.

Answer 1

Thank you for reaching out.

If your bot builds successfully but does not receive the incoming call event, it usually means the bot is not reachable for signaling or media. Here are the main things to check:

Update SDK – Make sure you are using the latest Microsoft Graph Communications SDK. Older versions can stop working because APIs change.

Public IP and Ports – The VM hosting the bot must have a public IPv4 address and allow inbound traffic. Required ports:

• HTTPS signaling: 443
  • Media: UDP ports for ICE/STUN/TURN (commonly 3478–3481) and RTP streams.
  Firewall and NAT Rules – Confirm that firewall rules and NAT settings allow media traffic. If ports are blocked, the bot will not join the call. Bot Registration – Verify the App ID and secret, and ensure calling permissions are granted in Azure AD. The bot and Teams user must be in the same tenant. Logs and Correlation IDs – Check runtime logs for ICE negotiation or Graph API errors. These often show why the call event is not triggered.

Windows Server 2019 is supported, so the environment is fine. Most issues come from networking or outdated SDK. After fixing these, test with the latest GitHub sample.

Please let us know if you require any further assistance, we’re happy to help.

If you found this information useful, kindly mark this as "Accept Answer".

Answer 2

Thank you. My problem is that the solution builds successfully but then gives one runtime error after another such as "System.IO.FileLoadException

HResult=0x80131040

Message=Could not load file or assembly 'Microsoft.Graph.Core, Version=2.0.13.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Source=Microsoft.Graph.Communications.Common". If I resolve this somehow then I get similar error for microsoft.text.json and then system.memory. Hence I feel that there should be better way to handle it. Is there any documentation on how to setup the project properly and get rid of these errors? Thanks again.

Answer 3

Thanks for reaching out.

You’re hitting classic assembly binding/version skew on .NET Framework: the app compiles against one set of packages but loads different versions at runtime, which triggers errors such as:

System.IO.FileLoadException (0x80131040) Could not load file or assembly 'Microsoft.Graph.Core, Version=2.0.13.0... The located assembly's manifest definition does not match the assembly reference.
This typically cascades to System.Text.Json, System.Memory, System.Buffers, etc.

Below is a proven setup to eliminate these errors for the LocalMediaSamples (application‑hosted media) on Windows Server + .NET Framework.

1. Pin a compatible NuGet package set (no mixing)

Ensure all Graph Communications SDK packages and the Skype media library are version‑aligned. Install/update explicitly from Package Manager Console:
bot2.txt

2. Retarget to .NET Framework 4.8 (recommended)

You can stay on 4.7.2, but 4.8 reduces binding friction and enables modern TLS defaults.

• Project → Properties → Target framework: .NET Framework 4.8
• Install the .NET Framework 4.8 Developer Pack if missing.
  bot1.txt

3. Enable auto binding redirects and add an explicit App.config

• Project → Properties → Application → check Auto‑generate binding redirects.
• Add an App.config with explicit redirects for the assemblies that drift most often.

**Starter App.config (adjust newVersion to your installed versions):
**
4) Clean out stale binaries and caches
dotnet nuget locals all --clear
Reopen the solution → Restore → **Rebuild

**.5) Verify with Fusion Log Viewer (Fuslogvw.exe)

Use Fusion logs to see exactly which version the CLR is trying to load and where it probes:

1. Run Fuslogvw.exe.
2. Enable Log Failures and Bindings; set a custom log path.
3. Reproduce once; open the latest log entry.
4. Confirm your App.config redirects match the requested versions shown in the log.

6) Remove conflicting references

• Standardize on packages.config (or PackageReference)—avoid mixing across projects.
• Ensure all projects reference the same versions of Microsoft.Graph* and System.* packages.
• Make the bot executable the startup project (binding redirects apply to the entry appdomain).

7) Optional: fresh re‑setup (fastest if you’ve iterated a lot)

1. Clone the sample fresh.
2. Retarget to .NET Framework 4.8.
3. Install the package set from step 1.
4. Add the App.config above.
5. Restore → Rebuild → Run; use Fusion logs only if an error remains.

Why this works

  1. The Calling/Media SDKs were compiled against **specific** Graph client versions; mixing newer/older packages breaks assembly identity.
  
     1. `System.Text.Json` on .NET Framework pulls `System.Memory`, `Buffers`, `Unsafe` via netstandard—these must be **version‑compatible** and redirected to **one** resolved version at runtime.  
     Please let us know if you require any further assistance, we’re happy to help.
     
     If you found this information useful, kindly mark this as "Accept Answer".