Calls.Media 1.2.0.18725 is unrestorable from nuget.org (NU1101 x3), leaving 1.2.0.17950 as the newest installable version — which terminates every meeting join with 500#1203002

[DSYJ94]

There are two problems here and they compound: the newest Microsoft.Graph.Communications.Calls.Media cannot be installed from nuget.org at all, and the newest version that can be installed fails every application-hosted media join with 500#1203002.

The first is fully reproducible from a clean machine with no account, subscription or tenant involved. I have led with it for that reason.

1. Microsoft.Graph.Communications.Calls.Media 1.2.0.18725 cannot be restored from nuget.org

Three of its declared dependencies do not exist on nuget.org.

Repro — any machine, no Azure resources needed:

<!-- sdktest.csproj -->
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Graph.Communications.Calls.Media" Version="1.2.0.18725" />
  </ItemGroup>
</Project>

$ dotnet restore
error NU1101: Unable to find package Bond.Core.NET. No packages exist with this id in source(s): nuget.org
error NU1101: Unable to find package Microsoft.Identity.ServerAuthorization. No packages exist with this id in source(s): nuget.org
error NU1101: Unable to find package Microsoft.Skype.Bots.Media.Library. No packages exist with this id in source(s): nuget.org

Those three ids are absent, not merely unlisted — they 404 both from the flat-container index and from a direct exact-version .nupkg URL:

https://api.nuget.org/v3-flatcontainer/bond.core.net/index.json                         -> 404
https://api.nuget.org/v3-flatcontainer/bond.core.net/3.0.69/bond.core.net.3.0.69.nupkg  -> 404
https://api.nuget.org/v3-flatcontainer/microsoft.identity.serverauthorization/index.json -> 404
https://api.nuget.org/v3-flatcontainer/microsoft.skype.bots.media.library/index.json     -> 404

They are new in 18725; 17950 does not declare any of them.

	1.2.0.17950 (2026-07-02)	1.2.0.18725 (2026-09-03)
Bond.Core.NET	—	3.0.69 (missing)
Microsoft.Identity.ServerAuthorization	—	4.15.0 (missing)
Microsoft.Skype.Bots.Media.Library	—	1.31.0.243 (missing)
System.Formats.Asn1	—	8.0.1 (present)
Microsoft.Skype.Bots.Media	1.31.0.225-preview	1.31.0.225-preview

This repo's own Samples/nuget.config does <clear /> and then adds nuget.org alone, so there is no documented additional feed that would supply them.

Questions: are these three intended to be published to nuget.org, or is 18725 meant to be consumed from a feed that isn't documented? If the latter, could that feed be named in the samples nuget.config or the README?

2. 1.2.0.17950 terminates every meeting join with 500#1203002

This is what makes (1) blocking rather than cosmetic.

An application-hosted media bot calls Calls().AddAsync(new JoinMeetingParameters(...)) to join a scheduled meeting. The call is created and reaches Establishing with a real Graph id, then terminates roughly 300 ms later. No participant ever appears in the meeting.

t+0.000  AddAsync called
t+0.566  AddAsync returned   resourceNull=False  state=Establishing
t+0.879  call terminated     state=Terminated
         resultInfo: { "code": 500, "subcode": 1203002,
                       "message": "Server Internal Error. DiagCode: 500#1203002.@" }

The notification sequence for the call is changeType: Updated (state: 1) immediately followed by changeType: Deleted (state: 8). Reproduced on every attempt.

Environment

Microsoft.Graph.Communications.Calls.Media	1.2.0.17950 (newest installable)
Microsoft.Skype.Bots.Media	1.31.0.225-preview
Reported by media platform	skypeMediaBotsVersion 1.31.0.0225, mediaStackVersion 2025.8.1.3
Runtime / OS	.NET 8, Windows Server
Hosting	Azure IaaS VM, 4 vCPU
Media config	AudioFormat.Pcm16K, audio Sendrecv, video Inactive

Ruled out — each measured, not assumed

• TLS chain. Full three-certificate chain (leaf → intermediate → root) served on both 443 and the media port; openssl s_client returns Verify return code: 0 (ok) on both. The incomplete-Let's-Encrypt-chain cause cited in similar threads does not apply here.
• Media reachability. TCP connects succeed from outside the network on both 443 and the media port.
• Instance-level public IP. The public IP is bound directly to the NIC with loadBalancerBackendAddressPools: null — no load balancer or NAT in front. Public DNS resolves to exactly that address, and that is the address the media platform advertises.
• Compute. 4 vCPU, above the documented minimum.
• Hosting type. IaaS VM, explicitly permitted by the requirements doc.
• Application permissions. Calls.JoinGroupCall.All, Calls.AccessMedia.All, Calls.InitiateGroupCall.All, Calls.Initiate.All, OnlineMeetings.Read.All all present in a freshly issued token, with admin consent.
• Inbound notification auth. Worth flagging separately — see below. It was genuinely broken on our side, is now fixed and verified, and 1203002 persists unchanged afterwards.

A related finding that may be worth documenting

Before reaching 1203002 we had a different failure with the same outward symptom: the call was created and then deleted seconds later, with IDX10503 signature-validation failures on the inbound notifications.

The cause was validating inbound notification tokens against the Entra key set (login.microsoftonline.com/common/discovery/v2.0/keys). Teams calling notifications are not signed by Entra — a real notification carried a kid that is present in the Teams calling platform's key set and absent from Entra's. Because a bot that rejects notifications cannot acknowledge its own call, Graph tore the call down, and the only visible symptom was a downstream roster poll 404-ing against a call that no longer existed.

Validating against the union of both key sets fixed it. This may be worth an explicit note in the docs or samples, because the failure mode gives no hint at the real cause.

What connects the two

The requirements doc states the library must be "either the newest available version of the NuGet package, or a version that isn't more than three months old", and that older versions "are deprecated and don't work after a few months".

We are on the newest version that can actually be installed. It is 75 days old — inside the stated window — but the newest published version is 12 days old and unrestorable. So if 1203002 is version-related we cannot act on it, and if it is not, we would still like to be on a supported version.

I can supply call ids, call chain ids and exact UTC timestamps privately to anyone who can trace them server-side — happy to do that through whatever channel you prefer.

[lojoh]

I have the same issue with installing version 18725.

I do however get a bot with 1.2.0.17950 to Establish a meeting with this combination if that can help you.

<PackageReference Include="Microsoft.Graph.Communications.Calls.Media" Version="1.2.0.17950" />
<PackageReference Include="Microsoft.Skype.Bots.Media" Version="1.33.0.258-preview" />

I am not NET8, I am experimenting with the move to NET10 at the moment.

[bhupenderlost]

If anyone finds a solution or workaround for this issue, please let me know. I’m looking for a way to incorporate the fix into my code.

[Jeanbjoseph]

Reproducing 500#1203002 on a fully-configured application-hosted media bot — and confirming it is not version-specific across the publicly installable range

We hit the exact problem described in this issue and did a fairly exhaustive elimination pass. Sharing it in case it helps triage, and to ask about the private-feed dependencies.

Environment

• Bot: .NET 8 (net8.0-windows, x64), ASP.NET Core, application-hosted media (ILocalMediaSession, audio recv-only for live transcription).
• Host: Azure VM (Windows Server 2022, Standard_D4as_v7, 4 vCPU), instance-level static public IP, DNS A record, valid Let's Encrypt TLS cert in LocalMachine\My.
• Signaling: Kestrel HTTPS on 0.0.0.0:443 (same cert); notification URL reachable publicly (verified). Media ports 8445-8449 open in both the NSG and the Windows firewall.
• MediaPlatformInstanceSettings: CertificateThumbprint set, InstancePublicIPAddress = the VM public IP (not IPAddress.Any), InstancePublicPort = 8445, ServiceFqdn = the cert CN.
• Media platform initializes successfully (NativeMedia.dll + native deps present, VC++ 2015-2022 x64 installed, 2-core check passes). Bot binds 443 and logs Application started.
• Join: guest identity (anonymous named "…"), meeting organized by an account in the bot's own tenant (single-tenant app), joined via short meeting link (meetingId + passcode) with Calls.JoinGroupCallAsGuest.All + Calls.AccessMedia.All + a -Global application access policy.

Symptom (100% reproducible)

• Calls().AddAsync(...) returns, call goes to Establishing.
• ~300 ms later the call is removed with resultInfo: code=500, subcode=1203002, message="Server Internal Error. DiagCode: 500#1203002.@"
• Bot never appears in the meeting/lobby; 0 audio frames received.

Version elimination (the key point)
The issue title pins this on Calls.Media 1.2.0.17950. We can confirm it is not specific to that build within the publicly installable set:

• Microsoft.Graph.Communications.Calls.Media 1.2.0.17950 → 500#1203002 on every join.
• Microsoft.Graph.Communications.Calls.Media 1.2.0.15690 (Oct 2025), with its paired Microsoft.Skype.Bots.Media 1.31.0.225-preview → identical 500#1203002.
• We could not test 1.2.0.18725 because it is unrestorable from nuget.org: its dependencies Microsoft.Skype.Bots.Media.Library, Bond.Core.NET, and Microsoft.Identity.ServerAuthorization return 404 from the flat-container index and direct .nupkg URLs (NU1101 ×3).

Because two independent public versions fail identically on a correctly provisioned host, this looks like either a service-side gate or a defect fixed only in 1.2.0.18725.

Questions / requests

1. Are the three dependencies of Calls.Media 1.2.0.18725 (Skype.Bots.Media.Library, Bond.Core.NET, Microsoft.Identity.ServerAuthorization) intended to be public? If so, could they be published to nuget.org? If not, what is the supported feed to restore 1.2.0.18725?
2. Is 500#1203002 on app-hosted media a known service-side issue with the currently installable SDK range, and is 1.2.0.18725 the fix?
3. Is there a supported/interim SDK version that successfully joins with application-hosted media today from nuget.org?

Happy to provide full trace logs, the IGraphLogger output, and the call/scenario IDs on request.

[ssulzer]

Please use Skype media SDK version 1.33.0.258-preview with Graph Comms SDK version 1.2.0.17950.