Asterisk/ARI/Python Developer for IVR Autodialer

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 tro