CCaaS_AcceptConversation: Operation is not supported in Open state (Microsoft Teams Extensibility)

(0) Share

Report

Posted on by James White

Hi,

Our organisation is currently implementing Dynamics 365 Contact Center but we've come across a very strange bug/issue during development and testing. We have configured voice via Microsoft Teams extensibility to route inbound voice calls but we are facing an issue whereby an agent will accept the incoming call from within our CRM environment with the accept toast notification, but when doing this in the background there is a 400 Bad Request API error occurring on the following endpoint (our sandbox environment URL removed):

/api/data/v9.0/msdyn_ocliveworkitems(ff032f5e-b68f-4b6e-96ce-47b98d7bba99)/Microsoft.Dynamics.CRM.CCaaS_AcceptConversation

The payload data being sent in the request:

{
  "ApiVersion": "1.0",
  "SessionId": "c28b2a9a-bc32-4541-98b7-10c7614361d7"
}

The error response being returned by the original request is:

{
  "error": {
    "code": "0x80048d0b",
    "message": "CoreServices Request returned error response. Exception: The remote server returned an error: (400) Bad Request., Status: ProtocolError, Status Code : BadRequest, Status Description : Bad Request, Response: {\"errorCode\":400801,\"message\":\"API Error : Operation is not supported in Open state\"}",
    "@Microsoft.PowerApps.CDS.ErrorDetails.OperationStatus": "0",
    "@Microsoft.PowerApps.CDS.ErrorDetails.SubErrorCode": "400801",
    "@Microsoft.PowerApps.CDS.ErrorDetails.Plugin.ExceptionFromPluginExecute": "Microsoft.Dynamics.OmnichannelCCaaSApi.Plugins.AcceptConversationAPIPlugin",
    "@Microsoft.PowerApps.CDS.ErrorDetails.Plugin.ExceptionRetriable": "False",
    "@Microsoft.PowerApps.CDS.ErrorDetails.Plugin.ExceptionSource": "PluginExecution",
    "@Microsoft.PowerApps.CDS.ErrorDetails.Plugin.OriginalException": "PluginExecution",
    "@Microsoft.PowerApps.CDS.ErrorDetails.Plugin.PluginTrace": "",
    "@Microsoft.PowerApps.CDS.HelpLink": "http://go.microsoft.com/fwlink/?LinkID=398563&error=Microsoft.Crm.CrmException%3a80048d0b&client=platform",
    "@Microsoft.PowerApps.CDS.TraceText": "\r\n[Microsoft.Dynamics.OmnichannelCCaaSApi.Plugins: Microsoft.Dynamics.OmnichannelCCaaSApi.Plugins.AcceptConversationAPIPlugin]\r\n[7909b123-ef14-f111-8342-6045bdf1fd43: CustomApi 'CCaaS_AcceptConversation' implementation]\r\n\r\n",
    "@Microsoft.PowerApps.CDS.InnerError.Message": "CoreServices Request returned error response. Exception: The remote server returned an error: (400) Bad Request., Status: ProtocolError, Status Code : BadRequest, Status Description : Bad Request, Response: {\"errorCode\":400801,\"message\":\"API Error : Operation is not supported in Open state\"}"
  }
}

The fwlink unfortunately just goes to the general Dynamics 365 support page and searching the specific error code being referenced does not provide any specific information on this error. We have an open ticket with Microsoft about this issue.

The main factor appears to be related to the conversation state and CCaaS_AcceptConversation, given the error: "Operation is not supported in Open state", but we don't know the actual cause of the error. Various attempts at trying to make sense of the error with AI tools suggest a timing issue with the Conversation State being mismatched and a potential race condition, but it could be completely wrong.

The issue appears to be specific to when routing calls via Microsoft Teams Extensibility, if we use an alternative option such as ACS instead, things seem to work fine without issues, so we have narrowed it down to being somehow related to Microsoft Teams in some form, but have no idea configuration wise where we can begin to try and fix this.

We have checked that the appropriate resource groups have been configured in Azure and are correct when deploying the Teams number and testing calls. Clearly it is working as the call is being routed to our CRM environment, but as soon as you accept a call, this 400 error occurs.

Has anyone encountered this issue or might have any further information that could help diagnose or troubleshoot the issue, with more specifics? We are at a loss as to why we are encountering this, with no much information to go on.

Thanks,

James

Categories:

Dynamics 365 Contact Center

Dynamics 365 Customer Service

I have the same question (0)

All responses (11)

Answers (0)

Sort by

James White 14 on at

Like (0)

Report
Copy link

Link copied!
Based on further testing, if the conversation is manually assigned to an agent in the Conversations view before clicking the accept notification for the voice call, this seems to prevent the 400 error. This isn't a solution, but allowed to proceed further, however the voice call never connects by the looks of it.

Capturing logs/console logging, we seem to have the following issues:

1. Invalid cancellation token

Failed to cancel the invite notification Uncaught (in promise) Error: Max retry attempts reached: 3. Last error: {"message":"Invalid cancellation token","msdyn_name":"cancelEvent"}

2. "Store or directline not initialized yet" — repeated UI rendering failures are observed. This warning fires repeatedly throughout the session, meaning the conversation body component kept trying to render before the DirectLine/ACS store was ready.

3. Voice call never connects — polling loop runs indefinitely. Despite the session being up, the system entered an endless ACS polling loop (ACS_SEND_POLLING_REQUEST / ACS_CANCEL_POLLING_CALLBACK / ACS_CREATE_POLLING_CALLBACK cycling every ~1 second). No voice call state transition happened — the call stayed in a "connecting" banner state with no CallConnected event ever arriving.

Example of repeated polling events occurring:

[CONVCTRL] {Event: 'ACS_SEND_POLLING_REQUEST', Description: 'ACS Adapter: Send polling request', TimeStamp: '2026-04-17T07:56:08.435Z', ChatThreadId: '19:acsV2_AJZSYFrcLwiFRk6Qba87Pc3jYJM41Z7HvlH_XmtLa-E1@thread.v2', ACSRequesterUserId: '8:acs:2f78b44b-cc35-4e61-a9e5-cbdcc5fcfd89_0000002e-362b-9ca5-e710-4c3a0d007fad'} [CONVCTRL] {Event: 'ACS_CANCEL_POLLING_CALLBACK', Description: 'ACS Adapter: Canceling polling callback with Id 852', TimeStamp: '2026-04-17T07:56:08.591Z', ChatThreadId: '19:acsV2_AJZSYFrcLwiFRk6Qba87Pc3jYJM41Z7HvlH_XmtLa-E1@thread.v2', ACSRequesterUserId: '8:acs:2f78b44b-cc35-4e61-a9e5-cbdcc5fcfd89_0000002e-362b-9ca5-e710-4c3a0d007fad'} [CONVCTRL] {Event: 'ACS_CREATE_POLLING_CALLBACK', Description: 'ACS Adapter: Created polling callback with Id 855', TimeStamp: '2026-04-17T07:56:08.592Z', ChatThreadId: '19:acsV2_AJZSYFrcLwiFRk6Qba87Pc3jYJM41Z7HvlH_XmtLa-E1@thread.v2', ACSRequesterUserId: '8:acs:2f78b44b-cc35-4e61-a9e5-cbdcc5fcfd89_0000002e-362b-9ca5-e710-4c3a0d007fad'}

Then after 60 seconds, a timeout event is raised.
[CONVCTRL] SCENARIO_FAILED: SCENARIO_INBOUND_ACCEPT2CONNECTED {ScenarioUniqueId: '630b0b4d-cdfb-4b40-9d1e-e32f36466c9a', ScenarioEventType: 2, Duration: 61240, ScenarioStartTime: 1776412510119, ScenarioEndTime: 1776412571359, …} boot.js?ver=b60103b68ece336aa70d:2 [CC] SCENARIO_FAILED: SCENARIO_INBOUND_ACCEPT2CONNECTED {details: 'Taking too long to connect to the call', waitTimeInMs: 60000, closeConnectionScenarioReason: 'takingTooLongToConnectToCall', incomingCallTimestamp: undefined, ccaasAcceptConversation: {…}, …}

While this doesn't provide any answers, it seems from the moment the accept action is done the call is never fully connected and therefore points to something in this area.

The session is never fully established, but there is clearly some form of connection because the accept notification is raised, the joining and leaving of an active conversation is logged in the session. If the voice call is ended by the user, this is detected. If the conversation is forced closed from the contact cenre side, this is stated on the user end saying "Agent has ended the call" and the calls ends, so there is clearly a connection, just that is never fully connects when accepting conversations.

Was this reply helpful? Yes No
James White 14 on at

Like (0)

Report
Copy link

Link copied!
Additionally, plugin trace logging for the identified Plug-in which is coming from the CCaaS solution: Microsoft.Dynamics.OmnichannelCCaaSApi.Plugins.AcceptConversationAPIPlugin shows the CCaaS_AcceptConversation web API call failing, but does not provide further information.
System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: CoreServices Request returned error response. Exception: The remote server returned an error: (400) Bad Request., Status: ProtocolError, Status Code : BadRequest, Status Description : Bad Request, Response: [Redacted-Json] at Microsoft.Xrm.RemotePlugin.Grpc.SandboxFabricGrpcClient.ExecutePluginInternal(IRemotePluginRequest pluginRequest, ExecuteRequest executeRequest, Guid executionId, ISandboxFabricDuplexCommunicationHandler communicationHandler, Boolean returnTraceInfo, Guid organizationId, SandboxFabricCallTracker sandboxFabricCallTracker) +0x5d7 at Microsoft.Xrm.RemotePlugin.Grpc.SandboxFabricGrpcClient.ExecutePlugin(IRemotePluginRequest pluginRequest, IPluginExecutionContext executionContext, IPluginTracingService pluginTracingService, ISandboxFabricDuplexCommunicationHandler communicationHandler, ISet`1 earlySerializedPropertiesList, SandboxFabricCallTracker sandboxFabricCallTracker, ISandboxMemoryStreamProvider memoryStreamProvider) +0x327 at Microsoft.Xrm.RemotePlugin.Grpc.SandboxFabricCodeUnit.ExecutePlugin(ILifetimeScope scope, IExecutionContext context, ISandboxFabricDuplexCommunicationHandler communicationHandler, ISandboxClientSettings sandboxClientSettings, SandboxFabricCallTracker& sandboxFabricCallTracker, ISandboxFabricGrpcClient sandboxFabricGrpcClient, ISandboxMemoryStreamProvider memoryStreamProvider) +0x16 at Microsoft.Xrm.RemotePlugin.Grpc.SandboxFabricCodeUnit.Execute(ILifetimeScope scope, IExecutionContext context, SandboxFabricCallTracker& sandboxFabricCallTracker, ISandboxMemoryStreamProvider memoryStreamProvider) +0xf8 at Castle.Proxies.Invocations.ISandboxFabricCodeUnit_Execute.InvokeMethodOnTarget() +0x13 at Castle.DynamicProxy.AbstractInvocation.Proceed() +0x2d at Microsoft.Xrm.RemotePlugin.Client.Interceptors.SandboxFabricPluginTraceInterceptor.Intercept(IInvocation invocation, IExecutionContext context, SandboxFabricCallTracker sandboxFabricCallTracker) +0x1f

The redacted JSON is the original 400 error posted, which was obtained via network inspection/proxy sniffing.

I feel this error is a symptom of something else, further up the chain. We deployed a very minimal/bare Dynamics 365 environment to rule out any solutions/configuration/customisation conflicts, but we still encountered the same issues in a fresh environment. We have to conclude that something with the Microsoft Teams Extensibility is the problem, given alternative numbers configured via Azure Communication Services work fine.

Was this reply helpful? Yes No
AT-28040446-0 11 on at

Like (0)

Report
Copy link

Link copied!

Hi @James White We are experiencing the exact same issue with Operator Connect. ACS numbers / Direct Routing numbers work fine. We are also seeing calls waiting in queue that offer Direct Callback do not allow DTMF #1 to trigger a callback - again it's as if the call is already in an open state. Are you also having that same issue as well? DTMF works fine due to testing Copilot IVR and using Operator Connect for outbound profile. We also have ticket open and awaiting SIP Logs from telco.

Was this reply helpful? Yes No
James White 14 on at

Like (0)

Report
Copy link

Link copied!

Hi @AT-28040446-0, sorry you are having issues too! We've just recently had a call with some Microsoft contacts and have shared information on what we have debugged and captured from network traces. I have highlighted that someone else had reported issues as well and pointed them to this thread. While it doesn't help, we are somewhat glad someone replied to this thread to at least confirm we perhaps aren't the only one's hitting this, because we've really been struggling to understand why it isn't working for us.

I'm not an expert with voice, we are working with a MS partner, so I don't have experience with setting up voice/DTMF/SIP, but what I can tell you is we tried setting up a separate SIP through our partner as a test rather than our current one. It didn't make a difference to the outcome same errors, so it would seem to rule it out that area. We also looked at capturing SIP logs, but it didn't yield anything to us. The failure seems to be the Web API call from Microsoft.Dynamics.OmnichannelCCaaSApi.Plugins.AcceptConversationAPIPlugin and appears to becoming from Dynamics 365 dataverse side, but we can't make sense of where the issue is. That error code we got has no reference in any documentation we can find.

From our support case, we were informed recently that there may have been an issue with the numbers syncing from Microsoft Teams and Dynamics 365 Contact Center and apparently something was done, but this hadn't changed anything.

We believe it is something specific to our Azure environment, because our MS partner has configured Teams Extensibility on other sandboxes in their test environment, and it works fine. We even tried a very minimal sandbox environment within our tenant to rule out any customisations within CRM itself and that still doesn't work. A bare bones CRM environment with no solutions other than Dynamics 365 Contact Center deployed. The only common factor is the same Azure tenant in all cases.

I will try and share anything that comes to light, we have hopefully got some visibility on the issue directly through some contacts and reaching out, I hope you can make progress with your issue.

Was this reply helpful? Yes No
AT-28040446-0 11 on at

Like (0)

Report
Copy link

Link copied!

We are still in the process of escalating with Microsoft as we have been unable to find the root cause of the issue. From an Azure side we have checked all the app registrations and delegated permissions. From a Team side we have checked licensing, resource account config and Information Barriers (IB) - however Operator Connect numbers aren't in the scope of routing policies and Information Barrier evaluation. From a D365 we have tested a separate ACS number on same Workstream to ensure the route to agent is configured correctly. Routing Diagnostics on the Operator Connect number show the agent is assigned but immediately but pulls back the call and agent assignment fails. All the original error messages you posted are the same.

Other behaviors to note -

1. As previously mentioned, we cannot initiate a direct callback using DTMF 1 when prompted

2. The Teams Meeting hotkeys can be pressed during the call - *1, *5, *6 etc

3. When automatic recording is enabled in D365 we are played the Teams Compliance message

4. Copilot IVR can answer the call and DTMF is fully functional. Once the call hits the D365 queue it is rendered in the wrong state.

We also have this working in another tenant/environment with Operator connect however the telco is different. If we can identify the root cause with the support of Microsoft I will share here with you.

Was this reply helpful? Yes No
James White 14 on at

Like (1)

Report
Copy link

Link copied!

Thanks @AT-28040446-0, this is useful information, thanks for sharing. I hope your case with Microsoft yields results soon for you. We hope the meeting we had with some customer success contacts and engineers will help with ours. We demonstrated the issue and shared the information we had found, errors, HAR information from the debugging web session.

The weird thing is the call seems to be connecting to a point, because it is obviously being routed inbound. Our testing seems to rule out our telecoms provider, because as a test, we configured a completely separate SIP which is known to work, as it was our Microsoft Partner's SIP that we had a baseline of working in their sandbox environment but it was in a different tenant. This didn't seem to change the behaviour we have, the one factor that remains is our specific Azure environment in all cases, but the issue is unclear.

Similar to you, we've also gone through the various troubleshooting, checked resource groups, licences, and all the usual stuff. We've redone the setting up of numbers multiple times, forced syncing etc. Microsoft support did say that they thought they might not have synced properly, but we don't believe there was an issue, as it hasn't resolved anything.

We await further updates from our call that was last week.

Likewise, if I get any new information from Microsoft I will share it.

Was this reply helpful? Yes No
AT-28040446-0 11 on at

Like (0)

Report
Copy link

Link copied!

Hi @James White

Sorry we still don't have a definitive root cause, but we have escalated the issue and it's currently with the Product Group.

We have had the ACS logs analysed and they show AddParticipant failures (403 / SubCode 2203). Typically, this would indicate Information Barrier policy enforcement, but we have ruled that out at a tenant and user level.

What works:

1. Copilot Studio Agent can pick up call + DTMF functional

2. Outbound profiles / phone dialler works

3. D365 Workstream greeting

4. Agent assignment

What doesn't work:

1. D365 Queue Direct Callback activation (DTMF #1)

2. Agent Accept Conversation (Microsoft.Dynamics.CRM.CCaaS_AcceptConversation)

3. Supervisor assign / Assign to Me (Conversation window stuck in "Connecting..")

Was this reply helpful? Yes No
James White 14 on at

Like (0)

Report
Copy link

Link copied!

Hi @AT-28040446-0

Thanks for the update and additional information. We'll investigate Information Barrier Policy enforcement with our Microsoft partner. We did go through various Microsoft Teams policies during our troubleshooting/investigation and didn't find anything. Interesting that you got some logs, when we used a different SIP as a test, our partner ran traces but didn't find anything of value. We haven't done any traces on our actual provider, because we thought we'd ruled out the provider given our partner's SIP had the same issue and we know it works with Teams Extensibility with their sandbox environment. We temporarily configured their SIP in our Azure tenant with a low priority configured on a specific user/number for testing, given we didn't want to route everything through it.

Did these logs come from Azure Communication Services? Were you able to get these, or did Microsoft provide them? One of the challenges we've found is log information has been limited as errors are coming frmo CaaS or cloud services. Plugin trace logs from the offending Dynamics 365 CRM plugin revealed very little, we only got the full stacktrace error from web debugging, outside of any Microsoft logging.

We haven't heard back on our case since the last update when we provided additional information from our call.

There's clearly a common factor here, but it is just difficult to ascertain. There is very limited documentation/information about the error codes that we have managed to find.

Hope you get some further insights soon. As previously mentioned, if we hear anything on our case, I'll provide an update here!

James

Was this reply helpful? Yes No
AT-28040446-0 11 on at

Like (0)

Report
Copy link

Link copied!

Microsoft provided that update and referred to Azure where the analysis was done. However, there is not much information available on that error code.

I assume you have set up ACS Federation as per:

https://learn.microsoft.com/en-sg/answers/questions/5527096/azure-communication-services-add-participants-gett

Set-CsTeamsAcsFederationConfiguration and Set-CsExternalAccessPolicy helped resolve another part of the problem in our environment.

I have tried running my own JS code in DevTools console to execute CCaaS_AcceptConversation using msdyn_ocliveworkitem and SessionId. Hoping to capture more verbose errors but it still only reported the 400801 API Error - Operation is not supported in open state.

If you don't mind letting me know, are you also not able to invoke Direct Callback? I don't think it's a DTMF problem, more a call state problem. When that starts working, I'm pretty sure the root cause will have been fixed.

Thanks.

Was this reply helpful? Yes No
James White 14 on at

Like (0)

Report
Copy link

Link copied!

@AT-28040446-0 That makes sense. A lot of the logs seem to be above our access/visibility, which has been frustrating for this specific issue.

If it helps, our open case ID is 2602040050001547. If you want to reference support Microsoft about another client having the same issues. We are in the United Kingdom. We still don't know if our Azure tenant environment is the issue or not. If you are happy to share your case ID, or if you want to share it via private messaging or alternative methods outside of the community forum, do let me know. If you want to connect up outside of the community forum, I'd be more than happy to do so to help resolve the issue for us both. I'm not an expert with telephony and we are working with a Microsoft partner and our IT team to implement things, but I have Dynamics 365 experience and familiarity with some of the key areas of our project.

I was able to bypass the 400 API error, by manually assigning the open conversation to an agent before accepting from the toast notification, however it doesn't provide much more info/get any further, as the session just hangs at connecting and the constant polling loop occurs in the background before giving up after 60 seconds, then the session is in a weird state and usually needs a hard refresh on the Dynamics 365 interface. The behaviour we see is sometimes when accepting conversations, the conversation panel doesn't even open, because of the 400 or sometimes it does and then just never connects, it seems to rotate between this behaviour, depending on the network conditions.

While the 400 error provided a stack trace error I feel it is more of a symptom of the wider problem, so we didn't want to get too focused on it, but it was the entry point to knowing something wasn't right. I did do some experimenting with API calls in Postman, but I think it is possibly not beneficial given that the underlying problem is beyond the Dataverse API I feel, it is more likely to be higher up, and whatever component/config isn't working then causes the web API calls to fail. I am a web developer myself, so debugging the API areas was my first go to option with HAR/traffic analysis and looking at the requests and payloads.

At the moment we have a very minimal test setup so we aren't doing Direct Callback, we just call the number that's routed via Teams Extensibility, waiting music plays, then the conversation comes into Dynamics 365 in the queue and triggers the accept conversation process, accepting puts the call in a state which is in the limbo of some form of connection but no voice/two way communication established. The holding music continues to play through on the client end after accepting, however, if I force close the session from Dynamics 365 it is announced on the caller end "Agent has ended the call" so clearly there's something established. Leaving and joining the conversation also adds activity down the left side, just no two-way communication is ever established or connected.

Was this reply helpful? Yes No