Amobit Call: engineering a live AI voice conversation through Telegram
From a button in a private operator panel to a real two-way conversation with the AI assistant Lola.
We developed Amobit Call as a controlled voice application for Amobit. An operator starts a personal Telegram call; after the other person answers, the application joins a Live AI session and moves audio in both directions. The implementation includes call states, audio conversion, bounded queues, diagnostics and protected access to the resulting call history. Real calls established that this is more than a screen prototype, while audible pauses remain a quality issue under investigation.
OPERATOR → choose a contact and start one call
→ TELEGRAM → place and answer the personal call
→ LIVE SESSION → connect after answer
→ AUDIO BRIDGE → resample PCM in both directions
→ LIFECYCLE → stop, timeout, hang up and cleanup
→ DIAGNOSTICS → call states and technical audio metricsThe business task
The goal was to let a business representative start a natural spoken AI conversation through a channel the recipient already uses. A text bot or a generated voice message would not meet that goal: the person must be able to answer, speak, hear the assistant and continue a live exchange. The system therefore needed a real call path, not only a conversation UI.
This is a supervised outreach tool. A human chooses a recipient and starts the call from a protected panel. The current implementation permits one call at a time and does not run an automatic dialling campaign. That scope made the first working voice loop observable and gave the operator control over whom the system calls.
What we built
A Python/FastAPI application coordinates a Telegram user account, the call manager and a separate OpenAI Live connection. Telethon maintains the account session; PyTgCalls/NTgCalls handles Telegram call media. A browser panel provides settings, recipient selection, start and stop actions, current state and call history. The account and API access are kept outside the public page.
The call manager owns the lifecycle. It admits one active call, waits for an answer, starts Live only after that answer, and closes both sides on a stop, hang-up, timeout or error. The system records technical outcome and audio counters so a healthy process is not confused with a successful conversation.
A call from button to conversation
The operator finds an eligible Telegram recipient and confirms the destination in the panel. The server creates a call record and asks Telegram to dial. While ringing, it does not stream speech to the AI service. Once the recipient answers, the call enters a connecting state and the Live session is started. After the Live connection signals readiness, microphone frames are sent to the model and generated speech is sent back to the Telegram call.
The visible path uses preparing, ringing, connecting, active and ending states, finishing as ended or error. A ring timeout, a separate Live readiness timeout and an upper bound on active conversation time prevent an abandoned call from keeping resources indefinitely. A manual stop and remote hang-up follow the same cleanup path.
Audio is the engineering core
Telegram and the Live session do not use the same audio rate. Telegram media arrives as mono PCM at 48 kHz, while the Live side uses 24 kHz. A streaming resampler converts audio in both directions without treating each small packet as an isolated recording. Separate input and output loops let microphone capture continue while generated speech is played.
The Telegram output must be paced in 10 ms frames. During testing, native media behaviour revealed that a larger 20 ms write was effectively read as only one frame, cutting half the audio. We corrected the frame size and pacing, then added bounded queues, underrun counters and an adaptive playback reserve. These changes addressed concrete sound failures; they are not a claim of zero latency or flawless speech.
Keeping delays visible
Live speech depends on the network, model generation and local playback. A queue that is too short can run dry and create audible gaps; a queue that grows unchecked can make the assistant answer late. The implementation limits incoming backlog, starts output after a small reserve and can raise that reserve after an underrun. It reduces accumulated delay only at quiet audio boundaries.
The application stores technical samples such as queued audio, dropped bytes, underruns and gaps between output chunks. Those measurements help distinguish capture, Live and playback problems. They cannot replace listening to a real call: earlier calls still produced pauses and quality concerns even after frame pacing and buffer changes.
Instructions and private data
Lola's spoken behaviour and her internal consultant context are separate instructions in the application. The operator may supply a topic for one call; it is appended only to that session. The voice agent does not gain external business actions merely because it can answer a question. This keeps conversation policy distinct from media transport and the panel.
The system stores call states and technical metrics in SQLite. Secret settings and optional text fragments from Live's built-in transcription are encrypted; an authorised endpoint serves transcripts with a no-store response. Audio itself is not recorded. Model transcription can diverge from what the recipient heard during interruptions, so a transcript is a review aid rather than a perfect recording.
What real tests proved
A personal Telegram account was connected and restored from its protected session. A recipient accepted a real call. After the initial Live billing issue was resolved, test calls carried incoming and outgoing PCM, and completed conversations produced usage and call metrics. The operator could initiate a call through the panel and the AI voice path could speak back through Telegram.
The work also exposed the distinction between functional delivery and voice acceptance. A native frame-size defect caused sped-up, distorted speech and was corrected. Later diagnostics showed that input backlog improved, but output underruns and audible pauses still appeared in some calls. The current evidence supports a working two-way call system; it does not establish stable naturalness across recipients, devices and networks.
Current scope and next validation
The case is about the Telegram path. The repository also contains a separate SIP route, but its most recent documented registration was rejected; that route is not presented here as a verified telephone service. WhatsApp is a separate prototype effort and is not part of the delivered Telegram result. Incoming calls and mass outbound campaigns are outside this implementation.
The next meaningful acceptance step is a consented real call with simultaneous technical observation and a listening review. It should test pauses, interruptions, hang-up and the recipient's experience on the actual device and network. We have not attached a conversion rate, time saving or measured business return to the project, because those outcomes were not established by the engineering tests.
The result
Amobit Call moved from a proposed voice assistant to an operating call path: a human can start a Telegram call, the recipient can answer, and a Live AI session can exchange speech through an audio bridge. The panel, lifecycle controls, diagnostics and protected history make the system testable and maintainable rather than a one-off voice demo.
Its practical value is an inspectable foundation for assisted voice conversations. The remaining audio-quality work is visible in metrics and listening notes instead of being hidden behind a generic ‘AI phone agent’ promise. That boundary is essential before extending the same idea to other channels or a larger calling operation.
Implemented call path
- Operator confirms one recipient
- Telegram call is placed and answered
- Live session starts after answer
- PCM is converted and streamed both ways
- Hang-up closes media and records technical outcome