Call reaches Establishing then immediately Terminated with 500/1203002 "Server Internal Error" — app-hosted media join, no other diagnostic detail (relates to #772, #839) · Issue #870 · microsoftgraph/microsoft-graph-comms-samples

ftacorn · 2026-08-23T01:42:40.000Z

# Title Call reaches Establishing then immediately Terminated with 500/1203002 "Server Internal Error" — app-hosted media join, no other diagnostic detail (relates to #772, #839) # Body **Describe the issue** Building a minimal app-hosted-media calling bot (throwaway feasibility spike, not derived from any sample repo directly, but following the architecture of `RecordingBot`/`EchoBot`) to prove whether app-only Teams meeting join + media works on our tenant. Auth, app registration, and the join request itself all work correctly — the call is accepted and transitions to `Establishing` — but it then fails to `Terminated` within a couple of seconds every single time, before ever reaching `Established`, with no other error surfaced anywhere (no exception thrown locally, no webhook/notification content beyond the state change itself). This looks identical to #772 and #839 — same code (500), same subcode (1203002), same "immediately after Establishing" timing. Neither of those threads got a maintainer response, so opening a fresh one with a from-scratch tenant/environment to add a third data point, since #839 already ruled out ngrok/tunneling as the cause (real Azure VM + public IP + real cert, same result) and I can independently confirm the same on a different tenant. **Setup** - Local dev machine (Windows 11), signaling via an ngrok HTTP tunnel (static/reserved hostname, paid tier), media via a separate ngrok TCP tunnel. - Per the official local-dev guide (learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/debugging-local-testing-calling-meeting-bots), `MediaPlatformInstanceSettings.ServiceFqdn` is set to a **dedicated hostname we control** (CNAME'd to the ngrok TCP tunnel's hostname), separate from the HTTPS signaling hostname. `InstancePublicIPAddress` is `IPAddress.Any` (`0.0.0.0`), matching the SDK sample pattern, not a resolved literal IP. - Certificate is a real CA-signed cert (win-acme / Let's Encrypt via DNS-01), subject/SAN matching `ServiceFqdn` exactly, installed in `LocalMachine\My`, thumbprint passed as `CertificateThumbprint`. - Azure AD app registration has `Calls.AccessMedia.All`, `Calls.InitiateGroupCall.All`, `Calls.JoinGroupCall.All` (all application permissions, admin-consented), plus a companion **Azure Bot Service** resource with the Teams channel added and Calling explicitly enabled (required separately from the Graph AD app registration — error 7503 without it). - Joining a real scheduled Teams meeting via `Calls().AddAsync()` with `AudioSocketSettings` (`StreamDirection.Recvonly`, `AudioFormat.Pcm16K`), no video/VBSS sockets. **Code snippet (relevant excerpt)** ```csharp clientBuilder.SetMediaPlatformSettings(new MediaPlatformSettings { ApplicationId = clientId, MediaPlatformInstanceSettings = new MediaPlatformInstanceSettings { CertificateThumbprint = certificateThumbprint, InstancePublicIPAddress = IPAddress.Any, InstancePublicPort = mediaPublicPort, // ngrok TCP tunnel's public port InstanceInternalPort = mediaInternalPort, // local port media platform binds ServiceFqdn = mediaServiceFqdn, // dedicated hostname, CNAME'd to the ngrok TCP host }, }); ``` Call-state handler logs `ResultInfo` on every transition (added specifically to chase this issue down, since the bare `state` field alone gives no reason): ```csharp call.OnUpdated += async (sender, args) => { var state = args.NewResource.State; Console.WriteLine($"[spike] call state -> {state}"); var resultInfo = args.NewResource.ResultInfo; if (resultInfo is not null) { Console.WriteLine($"[spike] result info -- code: {resultInfo.Code}, subcode: {resultInfo.Subcode}, message: {resultInfo.Message}"); } ... }; ``` **Expected behavior** Call transitions `Establishing` → `Established`, media session starts receiving audio frames. **Actual behavior** ``` [spike] call state -> Establishing [spike] call state -> Terminated [spike] result info -- code: 500, subcode: 1203002, message: Server Internal Error [spike] call terminated. Total audio frames received: 0 ``` `ResultInfo` is the only diagnostic surfaced — no exception on our side, nothing else in the `/api/calling` notification payload beyond the state change and this result info. **Package versions** ```xml ``` - Target framework: net8.0 - OS: Windows 11 (dev machine), ngrok for tunneling **What we've already ruled out** - Not a networking/tunneling issue — TLS handshake to the media endpoint completes fine, and #839 reproduces the identical error on a real Azure VM with a public IP and zero tunneling involved. - Not the `ServiceFqdn`/`InstancePublicIPAddress` config — corrected both to match the SDK's own documented sample (dedicated CNAME'd hostname distinct from signaling, `0.0.0.0` for the public IP field) per the local-dev guide linked above; identical failure before and after. - Not a missing native-DLL/build issue — confirmed the media platform initializes (TLS handshake succeeds, call is accepted into `Establishing`) before failing. - Not a permissions/licensing issue — no 401/403, no 7503/7504, the call is genuinely accepted and only fails once media negotiation starts. **Additional context** Two existing issues on this exact code/subcode (#772, #1203002-tagged #839) are open/closed with no maintainer resolution. Happy to provide a fresh Fiddler/Wireshark capture, full server log, or try any diagnostic the team wants — this is currently a hard blocker on evaluating app-hosted media bots for our use case.