Phone and live sessions

Phone Agents is a setup and architecture preview, not a verified telephony deployment workflow. The page can help an operator understand prerequisites and the relationship between browser realtime testing, provider configuration, and session concepts, but it does not prove number provisioning, inbound or outbound calls, transfers, callbacks, recording, or durable live-session history. Use the route to assess readiness and identify missing dependencies without treating its controls as live phone operations.

Session lifecycle

A live voice interaction has several potential stages: configuration, connection attempt, media exchange, model response, audio playback, completion, and later inspection. A complete state machine for those stages is not currently documented. Browser tests and phone-oriented sessions also lack a verified shared durable event store.

Browser testing is the first stated live interaction path. A browser test can show whether microphone permission, audio output, provider configuration, and the current realtime path work together for one attempt. It cannot establish production uptime, automatic reconnection, interruption handling, transcript persistence, or a fixed retention period.

Treat session entries as observations from the current environment. If a session appears, inspect its available metadata without assuming that every event was captured. If no session appears, do not conclude that generation or playback necessarily failed because logging and persistence contracts remain under review.

A phone-oriented lifecycle would require additional verified stages such as telephony provider setup, number association, call events, transfer rules, recording controls, and callbacks. Those stages must not be added to the documentation until their implementation is inspected.

A live-session concept begins with configuration and a connection attempt, but its durable lifecycle is not yet specified. The phone route describes telephony setup and architecture rather than a completed calling service. Browser realtime agents are identified as the first live interaction path in the current metadata. No inspected contract verifies phone-number acquisition, carrier configuration, inbound calls, outbound calls, transfers, or callback delivery.

The phone route describes telephony setup and architecture rather than a completed calling service; confirm that the intended provider is configured before interpreting phone-readiness messaging. Live-session event names, ordering, persistence, and replay behavior require additional review; document whether the intended flow requires a number, callbacks, recording, transfers, or event persistence; each remains unverified. Do not publish instructions for provisioning numbers or receiving calls because those operations were not established by the supplied sources.

Phone readiness

The /voice/phone route describes telephony setup and architecture. It should be used to review missing dependencies rather than to provision a working phone service. No inspected contract verifies phone-number acquisition, inbound calling, outbound calling, transfer behavior, callback delivery, recording, or carrier credentials.

A readiness assessment should identify the intended provider, whether it is configured, the required media path, whether the use involves recording, and which session events must be retained. A provider card or selected option does not prove that the corresponding telephony account is active.

Stop at readiness review when the environment lacks a verified deployment path. Do not invent account-creation steps, phone-number controls, callback URLs, or provider dashboards.

Telephony readiness depends on capabilities that the supplied repository bundle does not verify as operational. Live-session event names, ordering, persistence, and replay behavior require additional review. Recording would introduce consent and data-handling obligations that are not resolved by the presence of a phone surface. Provider readiness remains separate from provider catalog visibility or a selected routing mode.

Phone-number acquisition, carrier configuration, inbound calls, outbound calls, transfers, or callback delivery is not verified by an inspected contract; use the browser agent path to test microphone, speaker, and turn behavior before considering telephony dependencies. Provider readiness remains separate from provider catalog visibility or a selected routing mode; review consent and privacy requirements before collecting or retaining any audio. A visible session or test event should not be described as a guaranteed durable phone-session record.

Live interaction

Use the browser agent test to evaluate the interaction path that is most directly represented by the current product. Begin with a short, non-sensitive exchange. Confirm microphone permission, speaker output, connection establishment, input capture, model response, and audio playback as separate checkpoints.

A failure in one checkpoint should not be misdiagnosed as failure of the agent configuration. Denied microphone permission can block input even when the provider is configured. Missing audio output can hide a successful response. Provider setup can fail after a browser connection opens. These distinctions matter when deciding whether to adjust the device, browser, configuration, or provider.

Realtime behavior such as barge-in, interruption, turn detection, reconnect, resume, and concurrent sessions was not verified. Do not promise that those behaviors work uniformly across browsers or providers. If the test exposes connection or session events, use them only as current diagnostics.

The browser path also does not prove phone readiness. Telephony introduces separate provider, network, consent, event, and operational dependencies.

Browser realtime testing is the first stated live path and should be assessed separately from phone service. A session entry may represent a test or attempt without proving a durable production conversation record. Document whether the intended flow requires a number, callbacks, recording, transfers, or event persistence; each remains unverified. Review consent and privacy requirements before collecting or retaining any audio.

Recording would introduce consent and data-handling obligations that are not resolved by the presence of a phone surface; document whether the intended flow requires a number, callbacks, recording, transfers, or event persistence; each remains unverified. The phone route describes telephony setup and architecture rather than a completed calling service; stop at readiness assessment when the environment lacks a verified phone deployment path.

Events

A useful event review separates observation from contract. The interface may show a timestamp, label, session reference, or error detail for one browser attempt. Record those values exactly as displayed. Do not convert them into a permanent event taxonomy or assume that an equivalent phone event exists. Browser audio, model response, playback, and telephony signaling are different layers, and the inspected files do not define a shared delivery guarantee.

For a failed browser test, note the last visible checkpoint: permission granted, connection opened, input detected, response produced, or audio played. This narrows the fault without requiring invented event names. If the use case depends on recording, transfer, callbacks, or a durable transcript, stop at readiness assessment until the corresponding implementation and consent controls are verified.

No inspected telephony contract establishes a canonical event schema for voice sessions. Avoid publishing invented names for call started, media received, transcript updated, transfer requested, recording started, or call ended. The existence of a session viewer or realtime surface is not sufficient evidence for those contracts.

When the interface shows an event, record its actual label, timestamp, and safe identifiers for diagnosis. Keep the event tied to the inspected interface and do not assume it will be persisted, replayed, or delivered in the same order later. A browser event should not be described as a telephony callback.

Event data can contain personal or sensitive information. Do not copy full transcripts, audio, phone details, or provider credentials into routine troubleshooting notes. The approved Privacy route provides the current legal destination, but no fixed Voice-session retention policy is verified.

Future documentation for session events should identify event names, ordering, retry behavior, delivery guarantees, persistence, and privacy handling. Until those details exist, this section remains a boundary guide.

Session event names, ordering, persistence, and replay require a dedicated runtime audit. Stop at readiness assessment when the environment lacks a verified phone deployment path. Confirm that the intended provider is configured before interpreting phone-readiness messaging.

A session entry may represent a test or attempt without proving a durable production conversation record; review consent and privacy requirements before collecting or retaining any audio. Phone-number acquisition, carrier configuration, inbound calls, outbound calls, transfers, or callback delivery is not verified by an inspected contract; confirm that the intended provider is configured before interpreting phone-readiness messaging.

Errors

Phone and live-session problems should be classified by the stage that failed:

• Permission error: the browser cannot access the microphone or audio output.
• Provider setup error: the selected hosted provider is not configured.
• Connection error: the browser realtime path cannot establish or maintain the interaction.
• Media error: input capture or playback fails after connection.
• Session-record error: the interaction occurred but the expected record or event is missing.
• Telephony unavailable: the requested phone operation has no verified implementation path.

Correct the specific dependency before retrying. Reloading will not configure a provider, grant operating-system permission, or create telephony capability. If a browser test works but the phone route remains setup-oriented, treat that as the expected product boundary rather than a hidden failure.

For internal investigation, include the browser, permission state, selected provider, routing mode, safe session identifiers, and the exact visible error. Do not include credentials, full audio, or personal call data.

Phone-oriented failures are currently best described as missing setup, unavailable provider capability, or unverified runtime behavior. Use the browser agent path to test microphone, speaker, and turn behavior before considering telephony dependencies.

Limitations

Phone and live sessions remain preview functionality with substantial unverified behavior. The documentation must not claim active numbers, calls, transfers, callbacks, recordings, guaranteed WebRTC, durable events, or production retention.

Recording creates an additional consent and safety boundary. The phone page does not authorize recording. Recording notices, storage, deletion, and provider handling remain unverified. Review consent before any workflow that could capture a person’s voice.

Use the route to understand architecture intent, verify browser readiness, and document missing telephony dependencies. Move beyond setup only when source-backed implementation evidence establishes the provider, number, event, recording, and operational contracts required by the intended deployment.

The route should be read as architecture and setup preview rather than a calling product contract.