How to control the callAutomationClient.Createcall method retries

Question

How to control the callAutomationClient.Createcall method retries

Soundhar M 55

I utilise CallAutomationClient when using the PSTN Outbound call method in Azure Communication Service.The CreateCall function places three more calls to a client who declines the call if they do. How can I take control of this? I don't want to keep calling customers who have been denied.

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

Christos Panagiotidis 3,301 Reputation points

2026-07-30T07:06:19.1233333+00:00

CreateCall represents one outbound call action; the Call Automation SDK does not document a client option that controls an automatic redial count after rejection. A decline should appear in CallDisconnected with code 487 and subcode 10024. Record every CreateCall invocation, operation context, ServerCallId, callback event, and timestamp. If your logs contain multiple CreateCall invocations, the retries are in your application, queue processing, or duplicated webhook handling. Make the command idempotent, persist a call-attempt ID before dialing, and never call again when the terminal event reports a decline. Also ensure callback delivery cannot trigger the original command a second time. If your application issued exactly one CreateCall request but the PSTN destination received several separate call attempts, retain the call identifiers and Communication Services diagnostic logs and open Microsoft Support. That behavior cannot be changed through a documented CreateCall retry property and needs service-side or carrier tracing.

Christos Panagiotidis 3,301 Reputation points

2026-07-30T07:06:19.1233333+00:00

CreateCall represents one outbound call action; the Call Automation SDK does not document a client option that controls an automatic redial count after rejection. A decline should appear in CallDisconnected with code 487 and subcode 10024. Record every CreateCall invocation, operation context, ServerCallId, callback event, and timestamp. If your logs contain multiple CreateCall invocations, the retries are in your application, queue processing, or duplicated webhook handling. Make the command idempotent, persist a call-attempt ID before dialing, and never call again when the terminal event reports a decline. Also ensure callback delivery cannot trigger the original command a second time. If your application issued exactly one CreateCall request but the PSTN destination received several separate call attempts, retain the call identifiers and Communication Services diagnostic logs and open Microsoft Support. That behavior cannot be changed through a documented CreateCall retry property and needs service-side or carrier tracing.