TwiML™ Voice: <Sip>

The SIP INVITE message includes the API version, the AccountSid, and CallSid for the call. Optionally, you can also provide a set of parameters to manage signaling transport and authentication, or configure Twilio to pass custom SIP headers in the INVITE message: this method includes headers such as UUI (User-to-user Information).

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.

If Enhanced Programmable SIP Features is not enabled on your account, 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.

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:

If the 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.

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:

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

For example:

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.

You can also send multiple parameters and values as part of the x- header

UUI (User-to-User Information) header can be sent without prepending x-

The following standard SIP headers can also be sent without prepending x-

• Remote-Party-ID
• P-Preferred-Identity
• P-Called-Party-ID

Set a parameter on your SIP URI to specify what transport protocol you want to use. Currently, this is limited to UDP, TCP and 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 port may be specified.

When a SIP call is answered, Twilio passes the following parameters with its request in addition to the standard TwiML [Voice request parameters][request parameters]:

When you invoke [dial action][dial-action] attribute and <Sip>, Twilio passes the following parameters with its request in addition to the standard [dial action][dial-action] parameters. Use the action callback parameters to modify your application based on the results of the SIP dial attempt:

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

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>. If [answerOnBridge][dial-answer-on-bridge] attribute is used on <Dial>, 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 <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 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.

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:

Rate this page:

12345