Inside Smith Phone: an independent custom phone integration connecting live conversation, backend reasoning and permission-aware action.
Implementation notes · October 2, 2026
ILLUSTRATIVE CALL FLOW / 5 STEPS
01 / 05
Voice carries the conversation.
An authorized call exchanges audio through the custom phone bridge and OpenAI Realtime API.
A spoken request is input, not permission.
Conceptual sequence, not a live demo. No calls, audio or API requests. Select any step to explore.
01 / OVERVIEW
A conversation is not an authorization.
Smith Phone connects a custom telephone bridge, OpenAI real-time voice models, a ChatGPT dot, and MCP tools and events. Three separate responsibilities keep a conversation from becoming unrestricted authority.
Conversation
Live audio carries the exchange.
Context
Owner-only, read-only questions inform the response.
Authority
A trusted owner confirms a specific action.
Independent BeyondPOC work. The telephone transport and approval workflow are our integration, separate from talking to a dot inside ChatGPT. Not affiliated with or endorsed by OpenAI.
02 / ARCHITECTURE
Two paths. One explicit boundary.
Live audio handles the exchange. Backend reasoning handles work that needs more context. Neither grants permission to execute a task.
Live voice + backend reasoningCustom bridge · OpenAI Realtime API · ChatGPT dot
Read-only question
Owner-only bridge
Scoped context lookup
Answer to the conversation
Answer only · no execution authority
Task proposal
Untrusted MCP event
Fetch and review proposal
Confirm in trusted owner chat
Separately authorized execution
Full live journey unverified
Two distinct permission paths. An event is a request for review, never an approval.OpenAI Realtime API, ChatGPT Voice and dots
The inspected phone bridge is configured for GPT-Realtime-2.1 through the OpenAI Realtime API. OpenAI describes this model as supporting speech-to-speech interaction and tool use. Model documentation.
ChatGPT Voice and GPT-Live are related but distinct names. OpenAI documents ChatGPT Voice as powered by GPT-Live; its GPT-Live architecture separates the spoken conversation from delegated backend work. That is useful context for readers exploring ChatGPT live voice models, not a claim that Smith Phone uses GPT-Live. ChatGPT Voice · GPT-Live guide.
A ChatGPT dot is an agent that can continue work across conversations. OpenAI says dots are rolling out gradually to eligible accounts. This article describes our custom integration and its observed boundaries; it does not promise access to dots or a generally available dot telephony API. Meet dots.
How MCP tools and events differ
An MCP operation is a scoped request to the backend. An asynchronous event signals that something has happened or that a proposal is available. Receiving an event does not confer authority. The task-proposal path fetches the proposal as untrusted input, presents reviewable details in a trusted owner chat, and requires confirmation before separately authorized execution.
The owner-only question bridge has a different job: answer a read-only question. Keeping it separate from the proposal path prevents a context lookup from silently turning into a write or an outbound call.
One-shot authorization, duration and budget
Call authorization is one-shot and constrained by destination, approved duration and budget. Scoped gates are restored to disabled after the authorized window. When a provider result is uncertain, retrying should not be treated as harmless: another attempt can create another call or another charge.
A stale 130-second timestamp cap was corrected to follow the configured and individually approved maximum, including a five-minute call limit. This was a duration-handling fix. It has not been established as the cause of an earlier provider error.
Diagnostics without recordings or transcripts
The integration does not keep call recordings or transcripts. Bounded, privacy-safe diagnostics help distinguish what was attempted, how a session ended and whether the provider reported an error. They do not supply the exact conversation or prove that every spoken request was understood.
This makes diagnostic discipline essential: record an observed failure separately from a proven cause. The earlier invalid_request_error remains unexplained. A later successful call is useful evidence, but it does not retroactively explain that error.
03 / VERIFICATION
What the evidence supports.
Reported implementation evidence · October 2, 2026. Each result answers a different question.
AUTOMATED / PASSED180
Tests passed
Windows, offline Linux and CI. Automated checks do not establish production readiness.
LIVE CALL / OBSERVEDAudio
Exchanged successfully
The remote party hung up without a provider error. Semantic accuracy and task completion are not established.
EVENT PATH / INCOMPLETEActive
Proposal subscription
The full live event, review, confirmation and execution journey remains unverified.
Known unknown: the earlier invalid_request_error still has no established root cause. A later successful call does not explain it.
Duration handling corrected
The stale timestamp cap now follows the approved maximum. This fix is separate from the unexplained provider error.
Bounded diagnostics deployed
Privacy-safe operational evidence, with no recordings or transcripts for conversation-level inspection.
Next acceptance targets — not yet completed
A useful next verification step is an observed proposal journey: receive the event, fetch the intended proposal, review it, confirm it in trusted owner chat and verify only the separately authorized action. Rejection, expiration, duplicate delivery and uncertain provider outcomes should be checked too. These are suggested acceptance targets, not completed results.
04 / LIMITATIONS
In development, with deliberate limits.
This is a custom integration, not a public calling service or a production-readiness claim.
The read-only bridge is owner-only; retrieved context does not authorize actions.
The proposal subscription is active, but its full live journey remains unverified.
The earlier provider error has no established root cause.
A successful audio exchange does not establish conversational accuracy, long-term reliability or completed downstream work.
Suggested patterns for another system
Separate conversation, context and authority. Treat incoming proposals as untrusted data. Make approval specific enough to review, keep execution gates scoped, and reconcile uncertain outcomes before retrying. Retain only the diagnostic evidence needed to answer operational questions. These are suggested replication patterns; they still need system-specific implementation and verification.