Voice Overview | SignalWire

SignalWire cXML is a set of actions defined in an XML document you can use to tell SignalWire what to do when you receive an incoming call or instructions for outbound calls.

When a call is made to one of your SignalWire phone numbers, SignalWire looks up the SignalWire cXML document from the URL you configured and reads the instructions you provided to determine what to do.

SignalWire cXML allows you to dynamically control what happens, responding with specific instructions based on the caller, time of day, incoming call, and much more.

Not making a call? Check out Messaging XML for more details.

Request for XML

SignalWire makes an HTTP request to your configured endpoint just like a regular web form submission (POST) or page load (GET). The request includes contextual information about the call, allowing you to respond dynamically and fluidly to the call to meet the needs of your application.

You can configure the endpoint URL and HTTP Method in your phone number settings panel on your SignalWire Dashboard, or via the REST API.

Request parameters

SignalWire sends the following parameters, as either URL query parameters or POST parameters, to your endpoint when it receives a call:

AccountSid

string

The unique ID of the Account this call is associated with.

ApiVersion

string

The version of the SignalWire API. Incoming calls use the API version placed on the number called. Outgoing calls use the version of the REST API request.

CallSid

string

A unique identifier for the call.

CallStatus

string

The status of the call. Can be one of the following values: ringing, in-progress, queued, failed, busy, no-answer, or completed.

Direction

string

An identifier to describe the direction of the call: outbound-dial: calls launched through the <Dial> verb, outbound-api: calls launched through the REST API, inbound: for inbound calls.

From

string

The phone number that sent this call, in E.164 format.

ParentCallSid

string

A unique identifier for the call that created this call.

To

string

The phone number of the call recipient, in E.164 format.

CallStatus values

The following are the possible CallStatus parameter values. These are also used in <Dial>’s DialCallStatus:

Value
`ringing`	The call is ringing.
`in-progress`	The call was answered and is in progress.
`queued`	The call is ready and in line to initiate.
`failed`	The call could not be completed. Usually occurs when phone number does not exist.
`busy`	The caller encountered a busy signal.
`no-answer`	The call ended without an answer.
`completed`	The call was answered and ended normally.
`canceled`	The REST API canceled the call while it was ringing or queued.

Responding to SignalWire

An example of a SignalWire cXML document that reads a message to the caller before playing an audio file:

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Say>Hello, World!</Say>
    <Play>https://your-application.com/audio.mp3</Play>
</Response>

When a message comes into one of your SignalWire phone numbers, SignalWire makes an HTTP request to the URL endpoint you configured for that number. Your response to that request instructs SignalWire on what to do next.

Responses to the HTTP request are in SignalWire cXML. SignalWire starts at the top of your Compatibility XML document and executes your XML commands in order, from top to bottom.

SignalWire cXML verbs and their attributes are case-sensitive, so using <play>instead of <Play> will result in an error.

Status callbacks

Status callbacks are advisory

Status callbacks are asynchronous, best-effort HTTP notifications: delivery can be delayed or fail silently — if your server is unreachable, the callback simply never arrives. Don’t gate time-critical or business-critical actions solely on receiving one. Confirm state via the REST API before acting, or use a transport with visible failure modes — see Status callback reliability.

SignalWire can send your application callbacks at various lifecycle stages of your call. Status callbacks do not allow you to change the application execution directly, so callbacks do not have to respond with SignalWire cXML, but they allow your application to get updates as a call is happening.

You should respond to any callbacks with a 200 OK or 204 No Content, otherwise you will see failures in your application log on SignalWire.

The StatusCallback request contains the Standard Request Parameters plus the following optional parameters. It also carries call-quality metrics such as packet counts, jitter, and round-trip time. The Voice status callback reference lists every parameter.

AudioInMos

number

The estimated Mean Opinion Score (MOS) for inbound audio quality, based on the share of incoming audio packets that arrived without loss or delay. It ranges from about 1 to 4.5, the score for a call with no lost or late packets. Sent with up to two decimal places, such as 4.37.

CallbackSource

string

The source of the status callback.

CallDuration

integer

The duration, in seconds, of the finished call, from when the call started ringing to when it ended, rounded up to the next whole second. Because it includes ringing time, it’s longer than the time the call was connected and usually longer than a recording of the call. Only present on the completed event.

HangupBy

string

The From or To value of the party that ended the call, as indicated by HangupDirection. Present once the call has ended.

HangupDirection

string

Which side ended the call. Present once the call has ended. inbound means the remote party hung up, so HangupBy is From on an inbound call and To on an outbound call. outbound means the call was ended from the SignalWire side, so HangupBy is To on an inbound call and From on an outbound call.

SipCallId

string

The SIP Call-ID of the call.

Timestamp

string

The timestamp, in RFC 2822 format, of when the event occurred.

Instructions

Instructions (verbs and nouns) tell SignalWire what actions to take during a call. They are executed sequentially, so one instruction must complete fully before the next one is executed. Some instructions have optional attributes that can override the flow of execution, allowing you to dynamically change what happens based on events within the call.

All instructions are case-sensitive, so calling <ThisAction> is different from calling <thisaction>.