Skip to content

Slowness Issue with Communication.CallAutomation in 1.1.0-beta.1 -> 1.1.0 #40858

Open
@mnlIteratorIt

Description

@mnlIteratorIt

Library name and version

Azure.Communication.CallAutomation 1.1.0

Describe the bug

Hello,

While using CallAutomation during its preview phase, I employed it for a Proof of Concept (POC) with the primary objective of communication through CallMedia and DtmfTones. It worked quite well for the most part.

The only issue I encountered was related to response time. The device I'm communicating with expects a quick response after sending its message (we are talking 1+- secounds). If the response is delayed, the device assumes something has gone wrong, making it critical for me to respond promptly.

For this reason, I couldn't use CallMedia.StartRecognizingAsync because it's too slow to proceed to RecognizeCompleted, even though I configured the following:

  • Minimum InterToneTimeout to 1 second in CallMediaRecognizeDtmfOptions.
  • StopTone to the last tone in the message, which I know in advance.
  • MaxTonesToCollect to the length I know the message will be.

On the other hand, when using CallMedia.StartContinuousDtmfRecognitionAsync, I could respond after the last tone and send back a reply each time as desired :D

However, now that CallAutomation has transitioned from preview to production, I can only occasionally respond quickly enough. I've tried stripping away all other logic that could potentially delay my response time. Still, I'm experiencing the same inconsistent result even though I'm reacting to a fixed tone.

It's possible that in my POC, I was lucky and pushing the limits, but it seems that something in the background has changed, causing CallMedia.StartContinuousDtmfRecognitionAsync to become slower.

Is that something you are aware of, and is it something that can be fixed?

Expected behavior

Expected to send faster like when it was in preview.

Actual behavior

Sends the tone, but not as fast as it used to do.

Reproduction Steps

  1. Start API with inbound and webhook-callback endpoints.
  2. Call
  3. StartContinuousDtmfRecognitionAsync
  4. StopContinuousDtmfRecognitionAsync at any given point
  5. SendDtmfTonesAsync

Environment

  • Azure Communication Service

  • Danish phone number (+45)

  • Event Grid System Topic (Microsoft.Communication.IncomingCall)

  • Event Subscription (webhook)

  • REST API with .NET 6

Metadata

Metadata

Assignees

No one assigned

    Labels

    ClientThis issue points to a problem in the data-plane of the library.CommunicationService AttentionWorkflow: This issue is responsible by Azure service team.customer-reportedIssues that are reported by GitHub users external to the Azure organization.needs-team-attentionWorkflow: This issue needs attention from Azure service team or SDK teamquestionThe issue doesn't require a change to the product in order to be resolved. Most issues start as that

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions