A callback, phone menu and voice assistant use different parts of a calling platform.
What can a voice API control?
A voice API can expose configuration, call control and reporting, with the supported operations defined by the provider.
Configuration covers trunks, caller identities, destinations and number routing. Call control covers behavior inside a conversation, such as prompts or keypad input. Reporting returns the call’s status, duration and other recorded outcomes.
Providers express call control differently. Twilio’s TwiML, for example, describes actions through instructions returned to Twilio. Moving an application therefore means mapping its behavior and callback expectations, not only replacing a hostname.
A method that reads a call is not an operation that starts one.
How do an API and SIP work together?
An application API can configure or control a service while SIP establishes the telephone session underneath it.
SIP, the call-signaling protocol, creates, modifies and terminates sessions. It negotiates how participants connect. RTP carries real-time media such as audio.
The paths can fail independently. A call can ring while a media setting or network path prevents one participant from hearing the other. Test audio in both directions as well as ringing and hangup.
A PBX, the business phone system that routes calls, can keep its call handling while using a provider’s SIP trunks. A conversational runtime can use a similar connection while supplying speech and business tools itself.
What can I read about a call?
A call record identifies the attempt and reports its observed state. The fields available depend on the operation and the stage of the call.
- Connection: whether the call was admitted, rang and received an answer.
- Media: whether the participants could hear and interact with each other.
- Business outcome: whether the intended appointment, callback or support task completed.
An answered telephone call may reach a person, voicemail or another automated system. The call record alone cannot prove that a customer completed a task.
Events help your application react to changes. Handle duplicates and late delivery, then reconcile missing or uncertain updates against the provider’s recorded state.
How do I build this with Bird?
You configure outbound calling with a SIP trunk, a verified caller ID and an enabled destination country.
Configuration changes require voice_management at write level.
On the trunk, outbound_enabled must be true. Its domain is the address your SIP client connects to. API-key authentication lists your key in allowed_api_key_ids; the key needs voice at write level. Updating that list replaces all entries, so retain keys that other clients still use.
Your caller ID needs status: verified, which confirms that your workspace completed its verification call. Its phone_number contains the international number, including the leading +.
The destination country needs both enabled: true and status: available. Enabling a country does not make an unsupported destination callable.
The browser phone also needs session_credentials_enabled: true and MD5 in the trunk’s digest_algorithms.
After a call, you inspect status, rejection_reason and sip_response_code. The leg list and leg read operations return those fields. These operations report attempts. Your SIP application initiates them.
For a phone menu, you configure prompts and keypad branches in the connected application. A voice AI runtime supplies speech, reasoning and business tools for a conversation.
In short
Voice APIs expose different operations.
Configuration, call control and call records are different interfaces. A read operation does not imply a way to place a call.
Signaling and audio have separate paths.
SIP establishes and changes the session. Media carries what the participants hear, so successful signaling alone does not prove audio works.
An answered call does not prove task completion.
An answered call can reach voicemail or another system. The application that owns the task confirms whether it completed.