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

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)

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):

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

<PackageReference Include="Microsoft.Graph.Communications.Calls.Media" Version="1.2.0.17950" />
<PackageReference Include="Microsoft.Identity.Client" Version="4.83.1" />
<PackageReference Include="Microsoft.IdentityModel.Protocols.OpenIdConnect" Version="8.16.0" />
<PackageReference Include="Microsoft.Skype.Bots.Media" Version="1.31.0.225-preview" />

• 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.

Start with the RecordingBot/EchoBot architecture and the Calls().AddAsync() join path; compare the MediaPlatformInstanceSettings values and call OnUpdated ResultInfo logging with the linked local-testing guide. Reproduce the Establishing → Terminated transition using the listed package versions; done means identifying a documented cause or workaround for the 500/1203002 result.