TwiMLTM Voice: <SIP>

The <Dial> verb's <Sip> noun lets you set up VoIP sessions by using SIP -- Session Initiation Protocol. With this feature, you can send a call to any SIP endpoint. Set up your TwiML to use the <Sip> noun within the <Dial> verb whenever any of your Twilio phone numbers are called. If you are unfamiliar with SIP, or want more information on how Twilio works with your SIP endpoint, please see the SIP overview.

The SIP session

The SIP INVITE message includes the API version, the AccountSid and CallSid for the call. Also, configure Twilio to pass custom SIP headers in the INVITE message. Optionally, provide a set of parameters to manage signaling transport and authentication.

Once the SIP session completes, Twilio requests the <Dial> action URL, passing along the SIP CallID header, the response code of the invite attempt, any X-headers passed back on the final SIP response, as well as the standard Twilio <Dial> parameters.

Currently, only one <Sip> noun may be specified per <Dial>, and the INVITE message may be sent to only one SIP endpoint. Also, you cannot add any other nouns (eg <Number>, <Client>) in the same <Dial> as the SIP. If you want to use another noun, set up a callback on the <Dial> to use alternate methods.

Use the Sip noun

All of the existing <Dial> parameters work with the <Sip> noun (record, timeout, hangupOnStar, etc). For SIP calls, the callerId attribute does not need to be a validated phone number. Enter any alphanumeric string. Optionally include the following chars: +-_., but no whitespace.

Within the <Sip> noun, you must specify a URI for Twilio to connect to. The URI should be a valid SIP URI under 255 characters. For example:

<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Dial>
    <Sip>
        sip:jack@example.com
    </Sip>
</Dial>
</Response>

Authentication

Send username and password attributes for authentication to your SIP infrastructure as attributes on the <Sip> noun.

Attribute NameValues
usernameUsername for SIP authentication
passwordPassword for SIP authentication

For example:

<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Dial>
    <Sip username="admin" password="1234">sip:kate@example.com</Sip>
</Dial>
</Response>

Custom headers

Send custom headers by appending them to the SIP URI -- just as you'd pass headers in a URI over HTTP. For example:

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Dial>
        <Sip>
            sip:jack@example.com?mycustomheader=foo&myotherheader=bar
        </Sip>
    </Dial>
</Response>

While the SIP URI itself must be under 255 chars, the headers must be under 1024 characters.

Transport

Set a parameter on your SIP URI to specify what transport protocol you want to use. Currently, this is limited to TCP and UDP. By default, Twilio sends your SIP INVITE over UDP. Change this by using the transport parameter:

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Dial>
        <Sip>
            sip:jack@example.com;transport=tcp
        </Sip>
    </Dial>
</Response>

Attributes

The <Sip> noun supports the following attributes that modify its behavior:

Attribute NameAllowed ValuesDefault Value
urlcall screening urlnone
methodGET, POSTPOST
statusCallbackEventinitiated, ringing, answered, completednone
statusCallbackany urlnone
statusCallbackMethodGET, POSTPOST

url

The url attribute allows you to specify a url for a TwiML document that runs on the called party's end, after they answer, but before the two parties are connected. You can use this TwiML to privately <Play> or <Say> information to the called party, or provide a chance to decline the phone call using <Gather> and <Hangup>. The current caller continues to hear ringing while the TwiML document executes on the other end. TwiML documents executed in this manner cannot contain the <Dial> verb.

method

The method attribute allows you to specify which HTTP method Twilio should use when requesting the URL specified in the url attribute. The default is POST.

Call Screening HTTP parameters

When a call is answered, Twilio passes the following parameters with its request to your screening URL (in addition to the standard TwiML Voice request parameters):

Attribute NameValues
SipCallIdThe SIP call ID header of the request made to the remote SIP infrastructure.
SipHeaderThe name/value of any X-headers returned in the 200 response to the SIP INVITE request.

Dial Action HTTP parameters

Use the action callback parameters to modify your application based on the results of the SIP dial attempt:

Attribute NameValues
DialSipCallIdThe SIP call ID header of the request made to the remote SIP infrastructure.
DialSipResponseCodeThe SIP response code as a result of the INVITE attempt.
DialSipHeader_The name/value of any X-headers returned in the final response to the SIP INVITE request.

statusCallbackEvent

When dialing out to a number using <Dial>, an outbound call is initiated. The call transitions from the initiated state to the ringing state when the phone starts ringing. It transitions to the answered state when the call is picked up, and finally to the completed state when the call is over. With statusCallbackEvent, you can subscribe to receive webhooks for the different call progress events: initiated, ringing, answered, or completed for a given call.

The statusCallbackEvent attribute allows you to specify which events Twilio should webhook on. To specify multiple events separate them with a space: initiated ringing answered completed. If a statusCallback is provided and no status callback events are specified the completed event will be sent by default.

The initiated, ringing, and answered events have a cost of $0.0001 per event, which results in $10 for every 100,000 events. The completed event is not charged.

As opposed to creating an outbound call via the API, outbound calls created using <Dial> are initiated right away and never queued. The following shows a timeline of possible call events that can be returned and the different call statuses that a <Dial> leg may experience:

Outbound Dial call events diagram

EventDescriptionCost
initiatedThe initiated event is fired when Twilio starts dialing the call.$0.0001 per event
ringingThe ringing event is fired when the call starts ringing.$0.0001 per event
answeredThe answered event is fired when the call is answered.$0.0001 per event
completedThe completed event is fired when the call is completed regardless of the termination status: busy, canceled, completed, failed, or no-answer. If no statusCallbackEvent is specified, completed will be fired by default.No cost

statusCallback

The statusCallback attribute allows you to specify a URL for Twilio to send webhook requests to on each event specified in the statusCallbackEvent attribute.

statusCallbackMethod

The statusCallbackMethod attribute allows you to specify which HTTP method Twilio should use when requesting the URL in the statusCallback attribute. The default is POST.

Status Callback HTTP Parameters

The parameters Twilio passes to your application in its asynchronous request to the StatusCallback URL include all parameters passed in a synchronous request to retrieve TwiML when Twilio receives a call to one of your Twilio numbers. The full list of parameters and descriptions of each are in the TwiML Voice Request documentation.

When the call progress events are fired, the Status Callback request also passes these additional parameters:

ParameterDescription
CallSidA unique identifier for this call, generated by Twilio. You can use the CallSid to modify the child call by POSTing to Calls/{CallSid} with a new TwiML URL.
CallStatusA descriptive status for the call. The value is one of queued, initiated, ringing, in-progress, busy, failed, or no-answer. See the CallStatus section for more details.
CallDurationThe duration in seconds of the just-completed call. Only present in the completed event.
RecordingUrlThe URL of the phone call's recorded audio. This parameter is included only if Record=true is set on the REST API request and does not include recordings from <Dial> or <Record>. RecordingUrl is only present in the completed event.
RecordingSidThe unique ID of the Recording from this call. RecordingSid is only present in the completed event.
RecordingDurationThe duration of the recorded audio (in seconds). RecordingDuration is only present in the completed event.
TimestampThe timestamp when the event was fired, given as UTC in RFC 2822 format.
CallbackSourceA string that describes the source of the webhook. This is provided to help disambiguate why the webhook was made. On Status Callbacks, this value is always call-progress-events.
SequenceNumberThe order in which the events were fired, starting from 0. Although events are fired in order, they are made as separate HTTP requests and there is no guarantee they will arrive in the same order.

Examples

Example 1: Dialing to a SIP endpoint

In this example, we want to connect to kate@example.com. To connect the call to Kate, use a <Dial> verb with a <Sip> noun nested inside.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Dial>
    <Sip>kate@example.com</Sip>
</Dial>
</Response>

Example 2: Dial a SIP endpoint, protected by authentication

In this example, you are still dialing Kate, but you need to pass authentication credentials to reach her.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Dial>
    <Sip username="admin" password="1234">kate@example.com</Sip>
</Dial>
</Response>

Example 3: Passing headers

In this example, pass custom headers along with the SIP address.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Dial>
        <Sip>sip:kate@example.com?mycustomheader=foo&myotherheader=bar</Sip>
    </Dial>
</Response>

Example 4: Dial with several attributes

A more complex Dial, specifying custom settings as attributes on <Dial>, including call screening and setting the protocol to TCP.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Dial
        record="true"
        timeout="10"
        hangupOnStar="true"
        callerId="bob"
        method="POST"
        action="/handle_post_dial">

        <Sip
            method="POST"
            url="/handle_screening_on_answer">
                    sip:kate@example.com?customheader=foo
        </Sip>
    </Dial>
</Response>

Example 5: Call Progress Events

In this example, we want to receive a webhook for each call progress event when dialing a SIP endpoint using <Dial>.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
        <Dial>
                <Sip
                statusCallbackEvent='initiated ringing answered completed'
                statusCallback='https://myapp.com/calls/events'
                statusCallbackMethod='POST'>
                        sip:kate@example.com
                </Sip>
        </Dial>
</Response>