Bot fails to join Teams meeting with error 500#1203002 (media negotiation failure) on GCP despite correct configuration

[imrankhn03]

Teams Application-Hosted Media Bot: 500#1203002 on GCP NAT — Call Terminates at "Establishing"

We're experiencing a persistent Server Internal Error. DiagCode: 500#1203002 when attempting to join Teams meetings with an application-hosted media bot. The call progresses to "Establishing" state but immediately terminates with a media negotiation error.

Environment Details

Platform:

• Hosting: Google Cloud Platform (GCP) VM
• OS: Windows Server
• .NET Version: .NET 8.0
• VM Configuration:
  • Internal IP: 10.x.x.x (private)
  • External IP: NAT'd public IP
  • Custom DNS FQDN pointing to public IP

SDK Versions:

<PackageReference Include="Microsoft.Graph.Communications.Calls" Version="1.2.0.*" />
<PackageReference Include="Microsoft.Graph.Communications.Calls.Media" Version="1.2.0.*" />
<PackageReference Include="Microsoft.Graph.Communications.Common" Version="1.2.0.*" />
<PackageReference Include="Microsoft.Graph.Communications.Core" Version="1.2.0.*" />
<PackageReference Include="Microsoft.Skype.Bots.Media" Version="1.31.0.225-preview" />
<PackageReference Include="Microsoft.IO.RecyclableMemoryStream" Version="3.*" />

Configuration Verified

We've systematically verified all standard requirements:

Certificate:

• ✅ CA-signed certificate
• ✅ Has private key
• ✅ Complete certificate chain
• ✅ Not expired
• ✅ Bound to port 8445 via netsh
• ✅ Certificate uses RSACng provider

Network:

• ✅ TCP port 8445 listening and accessible
• ✅ UDP ports 41000–41999 configured in firewall
• ✅ GCP firewall rules allow inbound TCP 8445 and UDP 41000–41999
• ✅ nmap confirms UDP port 41000 is open|filtered (not blocked)
• ✅ Windows Firewall configured correctly

MediaPlatformSettings:

new MediaPlatformSettings
{
    ApplicationId = appId,
    MediaPlatformInstanceSettings = new MediaPlatformInstanceSettings
    {
        CertificateThumbprint = "<your-cert-thumbprint>",
        InstanceInternalPort = 8445,
        InstancePublicIPAddress = IPAddress.Parse("<your-public-ip>"),
        InstancePublicPort = 8445,
        ServiceFqdn = "<your-fqdn>",
        MediaPortRange = new PortRange(41000, 41999)
    }
}

Audio Settings:

new AudioSocketSettings
{
    StreamDirections = StreamDirection.Sendrecv,
    SupportedAudioFormat = AudioFormat.Pcm16K,
    ReceiveUnmixedMeetingAudio = true
}

Call Flow

1. Bot receives join request via /api/call/join endpoint
2. Fetches call details from Graph API successfully
3. Extracts meeting token successfully
4. Calls CommunicationsClient.Calls().AddAsync() with TokenMeetingInfo
5. Receives "Establishing" notification
6. Immediately receives "Terminated" with error 500#1203002

Logs

Establishing notification:

{
    "@odata.type": "#microsoft.graph.commsNotification",
    "changeType": "updated",
    "resource": "/app/calls/<call-id>",
    "resourceData": {
        "@odata.type": "#microsoft.graph.call",
        "state": "establishing"
    }
}

Termination (within seconds):

{
    "@odata.type": "#microsoft.graph.commsNotification",
    "changeType": "deleted",
    "resource": "/app/calls/<call-id>",
    "resourceData": {
        "@odata.type": "#microsoft.graph.call",
        "state": "terminated",
        "resultInfo": {
            "@odata.type": "#microsoft.graph.resultInfo",
            "code": 500,
            "subcode": 1203002,
            "message": "Server Internal Error. DiagCode: 500#1203002.@"
        }
    }
}

Key Question: GCP NAT Compatibility

The VM has a private IP with NAT to a public IP. Microsoft's documentation states:

"Each VM instance hosting an application-hosted media bot in Azure must be directly accessible from the internet using an instance-level public IP address (ILPIP)"

Question: Is GCP's NAT architecture fundamentally incompatible with the Real-time Media Platform? Our working server uses the same Azure app registration but may be on a different hosting platform.

What We've Tried

1. ✅ Dynamic certificate discovery by subject name
2. ✅ Verified certificate chain completeness
3. ✅ Updated SSL binding to match certificate
4. ✅ Changed StreamDirection from Recvonly to Sendrecv
5. ✅ Set ReceiveUnmixedMeetingAudio = true
6. ✅ Passed MediaPlatformInstanceId to CreateMediaSession
7. ✅ Verified UDP connectivity with nmap
8. ✅ Confirmed firewall rules allow all required ports

Similar Issues

We've reviewed these related issues but none provided a solution:

• Bot sometimes does not join meeting: Server Internal Error. DiagCode: 500#7117 #750 — Intermittent failures (ours is 100% consistent)
• Server Internal Error. DiagCode: 500#1203002.@ while trying to join a teams call with audio #772 — Same error code but different root cause
• Microsoft Q&A 5584569 — Suggests certificate chain issues (verified not our case)

Questions

1. Is GCP NAT fundamentally incompatible with application-hosted media bots?
2. Are there additional diagnostic logs we can enable to see why media negotiation fails?
3. What specific network requirements does the Real-time Media Platform have beyond basic UDP connectivity?

Additional Context

• CommunicationsClient creation takes ~14 seconds (seems slow but completes successfully)
• No errors in local logs — failure happens entirely on Microsoft's side
• Issue is 100% reproducible (not intermittent)

[owennewo]

can you describe your setup a bit more. are you an a gcp managed instance group/vm or gke? (i've seen it working on vm). why are you using GCP NAT gateway? my understanding is that it is for outbound traffic, the setup i've seen working is where each vm in mig has a unique (non shared) external ip/dns so is seperately routable (i don't know if sharing public ip is possible, i don't work for msft).

Are you super confident that the media port that the teams binds too is accessible and locally using certificate (terminating tls).
echo | openssl s_client -connect mycustomdomain.com:8445 -servername mycustomdomain.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

My understanding is that teams will give you an "establishing" notification over signalling interface and then try that media port, if the media port fails e.g. cert is untrusted, doesn't match domain, unroutable then you'll see the dreaded 500#1203002.@ error. if you give the callid of a failed call and the time it failed they can sometimes look in their logs to give you more info as to what you are doing wrong.

have you had local success, e.g have you seen it working from your local laptop using ngrok/pinggy? One non obvious thing for me initially was the media port requirements, i.e it needs to be IP all the way to the server (no sneaky man in the middle https), you need a custom domain, etc.

i believe there are 3 sets of ports:

1. signalling port (often 9441) - this is https and is used for graph callbacks. tls can be terminated anywhere
2. media tcp (often 8445) - this is tcp and uses a proprietary protocall - you need to configure it with certs, etc
3. media udp (negotiated with stun/turn) - i think there are some outbound requirements for this

i wonder if you are having problems with 3. as if 2. is wrong i typically see an error during startup (teams failed to connect error), but it sounds like you are not seeing any startup errors.

[ssulzer]

@imrankhn03 Can you please share a recent call-id.

[keshavjeet]

Was this resolved?
I am facing the same issue on Azure.

[Lohith-UncovAI]

same error

[ssulzer]

A couple things to check:

1. Ensure your firewall allows egress TCP to the Teams IP address space (52.112.0.0/14 and 52.122.0.0/15) and does not restrict the peer/destination port.
2. Ensure that the Windows VM hosting your media bot trusts the various root and intermediate/subordinate certificate authorities (CAs) listed at https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-certificate-authority-details?tabs=certificate-authority-chains
   such as the DigiCert SHA2 Secure Server CA.
   Normally, a Windows machine can auto-update itself and fetch new CA certs it encounters when validating a peer's certificate. However, if the machine's firewall prevents outbound access to certain certificate resources, then a manual update of the machine's set of installed intermediate/root CA certs may be necessary.
   https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-certificate-authority-details?tabs=root-and-subordinate-cas-list#certificate-downloads-and-revocation-lists

[keshavjeet]

I implemented the sample code as it is and it worked. (2VCPU was required).