This guide was prepared with AI assistance using the linked documentation. Code examples are illustrative; verify them against your environment and current API documentation before use.
Define when the call leaves the agent
Before connecting a phone number, decide which calls should reach a person. The triggers might include a caller asking for a human, a denied tool action, an unclear request, or a service failure. Decide what happens if no person is available too.
A transfer is only successful when the person receives the call or an agreed fallback has taken over. A spoken ‘I’m transferring you’ is not evidence that the transfer completed.
Separate call media from backend control
OpenAI's SIP guide describes routing incoming calls through a SIP provider and handling an incoming-call webhook. After accepting a Realtime API call, a backend can connect to the session to observe events and issue commands while SIP carries audio.
GPT-Live and the Realtime API have different session endpoints and event flows. Follow the selected API's guide from start to finish; don't mix an acceptance or sideband example from one with the other.
Verify and deduplicate events
Authenticate the webhook using the provider's documented verification mechanism before using its payload. Webhooks can be retried, and events may be observed on more than one connection. Choose one owner for each side effect and use stable identifiers to prevent duplicate work.
This example is local pseudocode for illustrating the decision. A production deduplication record needs durable, atomic storage with expiry and a recovery strategy.
// Illustrative only: use an atomic durable store in production.
async function handleVerifiedEvent(eventId: string) {
if (await eventAlreadyHandled(eventId)) return;
await processEvent(eventId);
await markHandled(eventId);
}Build a useful handoff summary
Send the receiving person only the information they need for the next step: the caller's request, confirmed details, relevant history the caller is authorized to share, and any unresolved question. Mark uncertain fields rather than presenting them as facts.
Avoid putting full recordings, secrets, or unnecessary personal information in ordinary application logs. Apply your own retention and access rules to transcripts and summaries.
Test the difficult paths
For each case, check both the audible message and the resulting application state. Test on a non-production number before allowing a live call to create a real booking or change a record.
- The caller asks for a human while the agent is speaking.
- A transfer fails or the destination is unavailable.
- The incoming webhook arrives twice.
- A tool times out after an action may already have completed.
- The caller hangs up before the handoff finishes.
Monitor the handoff
Record the state transitions your team needs to support: request received, decision made, transfer requested, result, and fallback. Define who receives an alert when the path fails. Keep the distinction between an agent's intention and a confirmed external result visible in the record.
Plan a handoff from the operator's view
For an appointment request, the receiving person needs to know what the caller wants and which details have been confirmed. A useful summary might identify the requested service and a date the caller explicitly confirmed. If the agent heard a possible phone number but couldn't verify it, label the field as unconfirmed and let the operator ask again.
Agree on the transfer destination and fallback with the team that will receive calls. When a destination is busy or closed, the workflow could offer another approved route, such as a callback request. Don't promise a callback has been scheduled unless the backing system confirms it and the caller receives the right information.
A summary is a disclosure of call information to the receiving party. Apply your application's authorization and data-handling rules, and include only what the person needs to continue the task.
Make side effects safe under retries
The short pseudocode above illustrates the need to remember a handled event, but the check and write shown are not atomic. Two workers can both pass the check before either writes the marker. In a production design, use a durable operation that atomically claims an event, then record completion and failure with enough information for recovery.
A timeout after requesting a transfer is ambiguous: the transfer might have succeeded even though the caller never received the acknowledgement. Check the call or provider state before retrying an action that can affect a real person. Give one component ownership of the side effect even if multiple listeners receive the same event.
Test with a non-production number and a synthetic caller. Include duplicate webhooks, an unavailable operator, a hangup during transfer, and a timeout after the request was sent. Capture both the call outcome and the stored state, then confirm they agree.
Review the situation where the caller asks the agent to stop sharing details just before a transfer. Your application needs a policy for what the receiving operator can see and a way to apply it before sending the summary. Exercise this with a synthetic call and verify the operator's actual view. If the transfer destination doesn't answer, record the fallback that occurred instead of leaving the call marked as successfully handed off.
Sources and further reading
Documentation reviewed November 9, 2026. Verify current model support, limits and pricing before implementation.