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

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.

Start by reproducing the package restore in the provided net8.0 project, then inspect Samples/nuget.config and the requirements documentation. Compare the declared dependencies of versions 1.2.0.17950 and 1.2.0.18725, and review the reported Calls().AddAsync failure and notification-authentication findings. Done means the missing feed or publishing problem and the 500#1203002 cause are identified, with any required documentation location established.