SIP calls interact with TwiML in virtually the same way as inbound phone calls and Client. When Twilio receives an incoming INVITE to your Twilio SIP domain and authenticates it, it passes a 180 Ringing SIP response code to your SIP endpoint. Twilio then looks up the URLs associated with your SIP domain and makes an HTTP request to the VoiceUrl.
When requesting your TwiML, Twilio will pass several parameters to your application from the original SIP call:
|To||The URI of the INVITE|
|From||“From” header passed in the INVITE|
|SipDomain||The Twilio SIP Domain to which the INVITE was sent|
|SipUsername||The username given when authenticating the request, if Credential List is the authentication method.|
|SipCallId||The Call-Id of the incoming INVITE|
|SipSourceIp||The IP Address the incoming INVITE came from.|
|SipHeader_<name>||X- headers in the incoming INVITE are passed as SipHeader_<name> params, where <name> is the header key. You can receive multiple of these.|
Upon receiving a response with valid TwiML, Twilio begins executing the instructions contained within the TwiML. If the instructions are <Say>, <Play>, <Record>, <Dial>, or <Gather>, Twilio sends a 200 OK SIP response code to your endpoint and establishes the call.
If your application passes back a <Redirect> verb, the redirect document is requested and Twilio continues in the 180 Ringing state.
If your application sends back a <Reject reason=”busy”>, Twilio returns a 486 Busy SIP response code and the call setup is denied. If your application sends back a <Reject reason=”rejected”>, Twilio returns a 603 Rejected SIP response code and the call setup is denied.
In order to better integrate with remote SIP applications, Twilio's SIP connections can read headers in the initial INVITE and pass them to your application. Twilio will read any headers beginning with the X- prefix and pass them in the TwiML HTTP callback in the format SipHeader_X-headername=headervalue. This allows your application to make programmatic decisions about what to do with a call.