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 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.
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>
Send username and password attributes for authentication to your SIP infrastructure as attributes on the <Sip> noun.
| Attribute Name | Values |
|---|---|
| username | Username for SIP authentication |
| password | Password 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>
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.
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>
The <Sip> noun supports the following attributes that modify its behavior:
| Attribute Name | Allowed Values | Default Value |
|---|---|---|
| url | call screening url | none |
| method | GET, POST |
POST |
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.
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.
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 Name | Values |
|---|---|
| SipCallId | The SIP call ID header of the request made to the remote SIP infrastructure. |
| SipHeader |
The name/value of any X-headers returned in the 200 response to the SIP INVITE request. |
Use the action callback parameters to modify your application based on the results of the SIP dial attempt:
| Attribute Name | Values |
|---|---|
| DialSipCallId | The SIP call ID header of the request made to the remote SIP infrastructure. |
| DialSipResponseCode | The 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. |
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>
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>
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>
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>