Asterisk/ARI/Python Developer for IVR Autodialer
Budget / Salary$250–750
TypeFreelance project
LocationRemote
Posted2 hours ago
Senior Asterisk / ARI / Python Developer Needed — Finish Existing Real-Time IVR Autodialer — 48-Hour Priority
I have an existing Python/Asterisk outbound autodialer running on a Debian 12 VPS that needs to be finished and stabilized.
This application is already built. I am NOT looking for somebody to rebuild it from scratch.
I need an experienced developer who can inspect the existing codebase, understand how the components work together, preserve the functionality that already works, and finish the remaining live IVR integration.
IMPORTANT — 48-HOUR DEADLINE / AVAILABILITY
I need someone who can start immediately and dedicate substantial focused time to this project over the next 48 hours.
I am willing to pay a premium for the right developer and for priority availability.
Please do not bid if you are juggling numerous other projects, can only work a couple of hours per day, cannot begin immediately, or cannot realistically dedicate the time necessary to complete and test this within approximately two days.
CURRENT SYSTEM
The existing system includes:
Debian 12 VPS
Asterisk 22.10.1
Python application
ARI call/channel control
AMI/MixMonitor components
PJSIP outbound calling
VMGate cellular/SIP gateway
Existing web dashboard
Existing CSV/database workflow
Existing IVR state machine
Existing multi-step input/response workflow
Existing retry and branching logic
Existing batch-processing logic
Existing call/session state tracking
Deepgram/live STT integration code
DTMF handling
RTP keepalive/media handling
Logging and result/status handling
Important existing components include ivr_flow.py, dialer.py, live_ivr.py, ari_client.py, and rtp_keepalive.py.
WHAT IS ALREADY WORKING
Outbound calling through the current VMGate/PJSIP setup is working.
The live call/media path has been established. Audio capture and MixMonitor functionality have already been tested.
A previous DTMF delivery problem has also been resolved. Controlled live testing has confirmed that complete multi-digit DTMF sequences are being received correctly by the destination IVR and that navigation through multiple IVR stages works.
In other words, basic calling and DTMF transmission are already working.
EXISTING APPLICATION LOGIC
The application already contains a substantial IVR state machine. It includes multiple IVR states, input sequences, prompt/response handling, retries, branching, attempt tracking, success/failure states, call/session context, and the surrounding CSV/database workflow.
These are existing application requirements and existing code—not functionality that I am asking the new developer to invent from scratch.
The developer must be comfortable reviewing, maintaining and integrating an existing multi-stage IVR automation workflow.
PRIMARY REMAINING TASK
The main remaining work is to properly connect and stabilize the existing IVR state machine with the working live call/audio/STT/DTMF system.
The application needs to react to the live IVR in real time:
Live call → IVR audio → real-time prompt/event detection → existing state machine → appropriate DTMF action → next state → final result/status
The system should not primarily depend on large fixed delays or post-call transcription when the existing live audio/STT system can determine what is happening during the call.
REAL-TIME STT / EVENT HANDLING
Deepgram/live STT code and integration hooks already exist.
The developer needs to inspect how live audio currently reaches the transcription/state-machine components and finish the integration so that relevant IVR responses can trigger state transitions promptly and reliably.
Partial/interim transcription and other available real-time signals should be utilized appropriately where supported by the existing architecture.
RELIABILITY / FAIL-CLOSED LOGIC
The workflow must not blindly advance when an expected IVR state has not been positively identified.
Unexpected prompts, incorrect branches, STT uncertainty, timeouts, media problems and other abnormal conditions should produce predictable state handling and useful logging.
SPEED / CALL DURATION
Reliability is the first priority, but unnecessary waiting also needs to be eliminated.
Once the system reliably knows that the IVR is ready for the next action, it should proceed instead of waiting through unnecessarily long fixed timers.
CONCURRENCY
The application is designed for multiple simultaneous outbound calls.
Each call must maintain independent state/session information without state, transcription, DTMF or results from one call interfering with another.
EXISTING DASHBOARD / CSV / DATABASE
The existing dashboard, CSV workflow, database and results/logging system should be preserved.
I am hiring someone to finish the existing application, not unnecessarily replace components that already work.
TESTING
I expect actual testing and debugging—not simply code changes followed by “it should work.”
Development and workflow testing can use the existing mock/test environment. Any testing against external systems must use authorized test information supplied specifically for that purpose.
The project is complete when the agreed existing workflow is integrated and demonstrated successfully, not merely when the individual components work independently.
BEFORE YOU ACCEPT THIS PROJECT
This is extremely important.
I will provide serious candidates with the relevant source files and a more detailed private technical handoff before the project is awarded/accepted.
You must review those materials first.
I want you to understand the existing workflow, branching/retry requirements, architecture and remaining integration work before committing to the project.
If there is any existing functionality you are unwilling to maintain or integrate, tell me before accepting.
I do not want somebody accepting the project and later saying that they did not understand an existing requirement.
REQUIRED EXPERIENCE
You should have strong practical experience with Asterisk, ARI, AMI, PJSIP/SIP, RTP/media troubleshooting, RFC2833/4733 DTMF, Python, asynchronous/event-driven applications, IVR state machines, real-time speech-to-text, and Linux/Debian.
Experience debugging existing telephony applications is especially important.
Deepgram or comparable streaming STT experience is highly desirable.
DELIVERABLE
Finish and stabilize the integration between the existing application/state machine and the live call, audio, STT and DTMF path while preserving the existing dashboard, CSV/database workflow, state handling, logging and concurrency architecture.
Do not propose rebuilding the entire application unless you identify a specific technical reason that an existing component cannot reasonably be used.
WHEN BIDDING
Start your proposal with:
“I READ THE EXISTING-SYSTEM REQUIREMENTS.”
Then tell me:
Your direct Asterisk ARI/AMI + Python experience
Your experience with real-time IVR/STT systems
Whether you can start immediately
Whether you can make this project your primary focus for the next 48 hours
Whether you are willing to review the existing source code/handoff before accepting
Your realistic completion estimate after reviewing the code
Generic proposals will be ignored.
Budget: Flexible. I am willing to pay more for an experienced developer who can give this project immediate priority.
Target completion: Approximately 48 hours after starting.
I have an existing Python/Asterisk outbound autodialer running on a Debian 12 VPS that needs to be finished and stabilized.
This application is already built. I am NOT looking for somebody to rebuild it from scratch.
I need an experienced developer who can inspect the existing codebase, understand how the components work together, preserve the functionality that already works, and finish the remaining live IVR integration.
IMPORTANT — 48-HOUR DEADLINE / AVAILABILITY
I need someone who can start immediately and dedicate substantial focused time to this project over the next 48 hours.
I am willing to pay a premium for the right developer and for priority availability.
Please do not bid if you are juggling numerous other projects, can only work a couple of hours per day, cannot begin immediately, or cannot realistically dedicate the time necessary to complete and test this within approximately two days.
CURRENT SYSTEM
The existing system includes:
Debian 12 VPS
Asterisk 22.10.1
Python application
ARI call/channel control
AMI/MixMonitor components
PJSIP outbound calling
VMGate cellular/SIP gateway
Existing web dashboard
Existing CSV/database workflow
Existing IVR state machine
Existing multi-step input/response workflow
Existing retry and branching logic
Existing batch-processing logic
Existing call/session state tracking
Deepgram/live STT integration code
DTMF handling
RTP keepalive/media handling
Logging and result/status handling
Important existing components include ivr_flow.py, dialer.py, live_ivr.py, ari_client.py, and rtp_keepalive.py.
WHAT IS ALREADY WORKING
Outbound calling through the current VMGate/PJSIP setup is working.
The live call/media path has been established. Audio capture and MixMonitor functionality have already been tested.
A previous DTMF delivery problem has also been resolved. Controlled live testing has confirmed that complete multi-digit DTMF sequences are being received correctly by the destination IVR and that navigation through multiple IVR stages works.
In other words, basic calling and DTMF transmission are already working.
EXISTING APPLICATION LOGIC
The application already contains a substantial IVR state machine. It includes multiple IVR states, input sequences, prompt/response handling, retries, branching, attempt tracking, success/failure states, call/session context, and the surrounding CSV/database workflow.
These are existing application requirements and existing code—not functionality that I am asking the new developer to invent from scratch.
The developer must be comfortable reviewing, maintaining and integrating an existing multi-stage IVR automation workflow.
PRIMARY REMAINING TASK
The main remaining work is to properly connect and stabilize the existing IVR state machine with the working live call/audio/STT/DTMF system.
The application needs to react to the live IVR in real time:
Live call → IVR audio → real-time prompt/event detection → existing state machine → appropriate DTMF action → next state → final result/status
The system should not primarily depend on large fixed delays or post-call transcription when the existing live audio/STT system can determine what is happening during the call.
REAL-TIME STT / EVENT HANDLING
Deepgram/live STT code and integration hooks already exist.
The developer needs to inspect how live audio currently reaches the transcription/state-machine components and finish the integration so that relevant IVR responses can trigger state transitions promptly and reliably.
Partial/interim transcription and other available real-time signals should be utilized appropriately where supported by the existing architecture.
RELIABILITY / FAIL-CLOSED LOGIC
The workflow must not blindly advance when an expected IVR state has not been positively identified.
Unexpected prompts, incorrect branches, STT uncertainty, timeouts, media problems and other abnormal conditions should produce predictable state handling and useful logging.
SPEED / CALL DURATION
Reliability is the first priority, but unnecessary waiting also needs to be eliminated.
Once the system reliably knows that the IVR is ready for the next action, it should proceed instead of waiting through unnecessarily long fixed timers.
CONCURRENCY
The application is designed for multiple simultaneous outbound calls.
Each call must maintain independent state/session information without state, transcription, DTMF or results from one call interfering with another.
EXISTING DASHBOARD / CSV / DATABASE
The existing dashboard, CSV workflow, database and results/logging system should be preserved.
I am hiring someone to finish the existing application, not unnecessarily replace components that already work.
TESTING
I expect actual testing and debugging—not simply code changes followed by “it should work.”
Development and workflow testing can use the existing mock/test environment. Any testing against external systems must use authorized test information supplied specifically for that purpose.
The project is complete when the agreed existing workflow is integrated and demonstrated successfully, not merely when the individual components work independently.
BEFORE YOU ACCEPT THIS PROJECT
This is extremely important.
I will provide serious candidates with the relevant source files and a more detailed private technical handoff before the project is awarded/accepted.
You must review those materials first.
I want you to understand the existing workflow, branching/retry requirements, architecture and remaining integration work before committing to the project.
If there is any existing functionality you are unwilling to maintain or integrate, tell me before accepting.
I do not want somebody accepting the project and later saying that they did not understand an existing requirement.
REQUIRED EXPERIENCE
You should have strong practical experience with Asterisk, ARI, AMI, PJSIP/SIP, RTP/media troubleshooting, RFC2833/4733 DTMF, Python, asynchronous/event-driven applications, IVR state machines, real-time speech-to-text, and Linux/Debian.
Experience debugging existing telephony applications is especially important.
Deepgram or comparable streaming STT experience is highly desirable.
DELIVERABLE
Finish and stabilize the integration between the existing application/state machine and the live call, audio, STT and DTMF path while preserving the existing dashboard, CSV/database workflow, state handling, logging and concurrency architecture.
Do not propose rebuilding the entire application unless you identify a specific technical reason that an existing component cannot reasonably be used.
WHEN BIDDING
Start your proposal with:
“I READ THE EXISTING-SYSTEM REQUIREMENTS.”
Then tell me:
Your direct Asterisk ARI/AMI + Python experience
Your experience with real-time IVR/STT systems
Whether you can start immediately
Whether you can make this project your primary focus for the next 48 hours
Whether you are willing to review the existing source code/handoff before accepting
Your realistic completion estimate after reviewing the code
Generic proposals will be ignored.
Budget: Flexible. I am willing to pay more for an experienced developer who can give this project immediate priority.
Target completion: Approximately 48 hours after starting.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.