GraphAPI #microsoft.graph.commsNotification not being presented

Question

We have a BOT which answers calls. Previously we got an Established Event:

{

"@odata.type": "#microsoft.graph.commsNotifications",

"value": [

{

  "@odata.type": "#microsoft.graph.commsNotification",

  "changeType": "updated",

  "resourceUrl": "/communications/calls/57D<PII: Moderator removed>E78896",

  "resourceData": {

    "@odata.type": "#microsoft.graph.call",

    "@odata.id": "/communications/calls/57<PII: Moderator removed>E78896",

    "@odata.etag": "W/\"5445\"",

    "state": "established"

  }

}
```  ]

}

But now we are not.  Note:  This is NOT that the establishing/established events are received out of order.  We are not getting the established event at all.

[https://learn.microsoft.com/en-us/graph/api/call-answer?view=graph-rest-1.0&tabs=http](https://learn.microsoft.com/en-us/graph/api/call-answer?view=graph-rest-1.0&tabs=http)

Answer 1

Please understand that our forum is a public platform, and we will modify your question to cover the personal information in the description. Kindly ensure that you hide these personal or organization information next time you post error or some information to protect personal data.

Dear @Jon KENDALL,

Welcome to Microsoft Q&A Forum!

Thank you for reaching out and providing the detailed information about the issue you're experiencing with your bot. I appreciate the examples of the previously received notifications and the confirmation that neither the "establishing" nor "established" state updates are arriving anymore (and that this is not simply a matter of out-of-order delivery).

From what you've described, your bot successfully answers incoming calls via the /communications/calls/{id}/answer endpoint, but the expected real-time commsNotification updates for the call state transitions are no longer being delivered to your callback URI. This is a change from previous behavior where these notifications were reliably received.

Therefore, here are some observations from documentation:

The official Microsoft Graph documentation for the call: answer operation still clearly states that the following notifications should be sent:

• A notification with state: "establishing" shortly after the answer request succeeds.
• A subsequent notification with state: "established" once the call media is fully connected.

Example payloads match exactly what you shared previously:

• Establishing:

{
  "@odata.type": "#microsoft.graph.commsNotifications",
  "value": [
    {
      "@odata.type": "#microsoft.graph.commsNotification",
      "changeType": "updated",
      "resourceUrl": "/communications/calls/{callId}",
      "resourceData": {
        "@odata.type": "#microsoft.graph.call",
        "state": "establishing"
      }
    }
  ]
}

• Established: Similar, but with "state": "established".

Important note in the docs: "Call establishing/established notifications may arrive out of order." However, this does not explain a complete absence of both.

So, here are possible causes and suggested steps for you to try:

While there are no publicly documented deprecations or widespread outages specifically removing these notifications (as of the latest checks), similar intermittent or missing notification behaviors have appeared in community reports (e.g., on GitHub microsoft-graph-comms-samples issues and Microsoft Q&A threads). Common contributing factors include:

1.Callback URI Reachability / Delivery issues:

• Ensure your endpoint always returns HTTP 200 OK quickly (within ~5-10 seconds) and handles POST requests correctly.
• Test by manually POSTing sample notification payloads (like the ones above) to your callback URI using tools like Postman or curl.
• If using ngrok, Azure App Service, or similar, verify no recent changes in networking, firewalls, or SSL certificates are blocking incoming traffic from Microsoft.

2.Polling as a reliable workaround:

• As a temporary measure, after a successful 202 Accepted response from the answer endpoint, periodically GET the call resource: GET https://graph.microsoft.com/v1.0/communications/calls/{callId}
• Monitor the state property until it reaches "established" (and log etag changes to detect progress even without notifications).
• This approach ensures your bot may proceed with media handling or other logic.

3.Configuration and Permissions check:

• Confirm your app still has the necessary permissions (Calls.JoinGroupCall.All, Calls.AccessMedia.All, etc.) with valid admin consent.
• If using application-hosted media vs. service-hosted, test switching configs in the answer body to see if it affects notification delivery.

For reference, here are the most relevant links:

• call: answer API documentation - Details expected notifications
• call resource type - All possible states
• Microsoft Graph communications samples on GitHub - Test with minimal samples like HueBot or VoiceRecorderAndPlaybackBot to isolate if it's code vs. service-side

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". 

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.