<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
CallSid for the call. Also, you can configure Twilio to pass custom SIP headers in the INVITE message. This includes headers such as UUI (User-to-user Information). 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
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
<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.
To specify the geographic region from which Twilio will send SIP-out traffic towards your communication infrastructure, you must include the
region parameter in your SIP URI. For example, if the
region=ie1 parameter is included in your SIP URI, Twilio will send the SIP traffic from the Europe Ireland region:
<?xml version="1.0" encoding="UTF-8"?> <Response> <Dial> <Sip>sip:email@example.com;region=ie1</Sip> </Dial> </Response>
|us1||North America Virginia|
|us2||North America Oregon|
|sg1||Asia Pacific Singapore|
|jp1||Asia Pacific Tokyo|
|br1||South America São Paulo|
|au1||Asia Pacific Sydney|
region parameter is not specified, Twilio will send SIP-out traffic from the North America Virginia region.
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.
<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:
Send username and password attributes for authentication to your SIP infrastructure as attributes on the
|username||Username for SIP authentication|
|password||Password for SIP authentication|
Send custom headers by appending them to the SIP URI -- just as you'd pass headers in a URI over HTTP. For example:
While the SIP URI itself must be under 255 chars, the headers must be under 1024 characters. Any headers starting with the
x- prefix can be sent this way.
Beta You can also send multiple parameters and values as part of the
<?xml version="1.0" encoding="UTF-8"?> <Response> <Dial> <Sip>sip:firstname.lastname@example.org?x-customname=Madhu%2CMathiyalagan%3BTitle%3DManager&x-myotherheader=bar</Sip> </Dial> </Response>
Beta UUI (User-to-User Information) header can be sent without prepending
<?xml version="1.0" encoding="UTF-8"?> <Response> <Dial> <Sip>sip:email@example.com?User-to-User=123456789%3Bencoding%3Dhex&x-myotherheader=bar</Sip> </Dial> </Response>
Set a parameter on your SIP URI to specify what transport protocol you want to use. Currently, this is limited to
TLS. By default, Twilio sends your SIP INVITE over
UDP. Change this by using the transport parameter:
Alternatively, you may customize it to use TLS for SIP signaling. When using TLS, the default port will be 5061 however, a different one may be specified.
<Sip> noun supports the following attributes that modify its behavior:
|Attribute Name||Allowed Values||Default Value|
|url||call screening url||none|
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
<Say> information to the
called party, or provide a chance to decline the phone call using
<Hangup>. If answerOnBridge attribute is used on
the current caller will continue to hear ringing while the TwiML document executes on the other end.
TwiML documents executed in this manner are not allowed to contain 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
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):
|SipCallId||The SIP call ID header of the request made to the remote SIP infrastructure.|
||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:
|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.|
||The name/value of any X-headers returned in the final response to the SIP INVITE request.|
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:
completed for a
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.
As opposed to creating an outbound call via the API, outbound calls created
<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:
statusCallback attribute allows you to specify a URL for Twilio to send
webhook requests to on each event specified in the
attribute. Non-relative URLs must contain a valid hostname (underscores are not permitted).
statusCallbackMethod attribute allows you to specify which HTTP method
Twilio should use when requesting the URL in the
The default is
The parameters Twilio passes to your application in its asynchronous request to
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
When the call progress events are fired, the Status Callback request also passes these additional parameters:
|CallSid||A unique identifier for this call, generated by Twilio. You can use the
|ParentCallSid||A unique identifier for the parent call.|
|CallStatus||A descriptive status for the call. The value is one of
|CallDuration||The duration in seconds of the just-completed call. Only present in the
|RecordingUrl||The URL of the phone call's recorded audio. This parameter is included only if record is set on the
|RecordingSid||The unique ID of the Recording from this call.
|RecordingDuration||The duration of the recorded audio (in seconds).
|Timestamp||The timestamp when the event was fired, given as UTC in RFC 2822 format.|
|CallbackSource||A 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
|SequenceNumber||The order in which the events were fired, starting from
In this example, we want to connect to
firstname.lastname@example.org. To connect the call to Kate, use a
<Dial> verb with a
<Sip> noun nested inside.
In this example, you are still dialing Kate, but you need to pass authentication credentials to reach her.
In this example, pass custom headers along with the SIP address.
A more complex Dial, specifying custom settings as attributes on
<Dial>, including call screening.
In this example, we want to receive a webhook for each call progress event when
dialing a SIP endpoint using