Changes in the Programmable Voice TwiML functionality will be documented here for your reference.
Additional changes to Voice TwiML processors have been made.
completed
, the status callback request is now asynchronous and will no longer wait for responses from webhooks before getting emitted. Previously any webhook requests in-flight at the time the call ended would need to receive a response before the
completed
event would fire which could lead to race conditions, especially on inbound calls. The completed event will now be emitted as soon as the call ends.
Additional changes to Voice TwiML processors have been made.
<Dial><Client>
,
POST to /Calls
, and
POST to /Participants
has been increased to 256 characters
<Enqueue>
waitUrl
webhook will now be
ringing
; previously the sent status was
in-progress
<Say>
verb
will have the same behavior as the
<Pause>
verb
, and the call status sent to any following TwiML documents will be
ringing
and not
in-progress
; the overall call status will be determined by the subsequent TwiML verb
<Play>
media fetch requests
Additional changes to Voice TwiML processors have been made.
<Gather>
. This change brings this behavior into alignment with the behavior for
<Enqueue>
waitUrl
.
Additional changes to Voice TwiML processors have been made.
From
numbers
will no longer contain
only
digits: For example, an incoming caller ID could be
anonymous
,
unknown
, etc.
<Play>
media fetches now use the same redirect behavior as status callbacks and other webhooks. This means that query parameters received at the initial URL will now be persisted to the redirected URL.
We are beginning to roll out updates to our Voice TwiML processor. Some changes that may impact your call flows are:
<Hangup>
or
<Reject>
will now be marked as no-answer or busy as determined by the verb
<Play>
responses, but will not be collected for
<Play>
verbs nested inside
<Gather>
<Pause>
verb; previously no RTP was sent from Twilio while the
<Pause>
verb executes
<Record>
verb; previously no RTP was sent from Twilio while the
<Record>
verb executes
To or From
parameters
Answering machine detection (AMD) can now be enabled when creating child calls using <Dial><Number>
and <Dial><Sip>
, or when creating a new conference participant via POST to the /Participants API.
AMD will run in the background while the call connects and will return the results of our detection to inform your application when a human or machine answered, or when the voicemail message beep has been detected.
We are changing the behavior of <Dial>
. This could represent a breaking change for some call flows. The changes are:
<Dial>
action url is specified, Twilio will make a request to the provided action callback when the parent call is transferred to a new TwiML via call modification
<Dial>
action url is specified, the parent call will continue to the next verb in the current TwiML document when the parent call is modified to use new TwiML. Note: in most cases the verb after the
<Dial>
will not be executed since the call has been modified, but if the next verb is
<Redirect>
Twilio will make a request to the provided URL.
This change brings Enhanced Programmable SIP Feature enabled accounts behavior in alignment with the behavior of TwiML for non-enabled accounts.
The following functional improvements to <Dial>
TwiML verb are available:
<Dial>
now allows simultaneous or sequential dialing to up to ten
<Number>
,
<Client>
or
<Sip>
endpoints in a single
<Dial>
command
<Dial>
now supports Global Low Latency (GLL) when using
<Dial hangupOnStar=”true”>
.
A new action callback parameter DialBridged
is added with value returned as true
only if the call was bridged with the parent. This is to distinguish the cases where the child call was hung up during screening vs bridged with the parent.
<Sip>
noun now supports the
ringTone
parameter.
To
and
From
phone numbers of the dialed leg. Previously, the geographic data for the
To
and
From
numbers of the parent leg was used in the status callbacks for the dialed leg as well.
Early audio will always be generated for the following scenarios
url
attribute is present
sendDigits
attribute is present
<Dial>
verb will never be allowed in the TwiML returned by the screening url.
<Hangup>
or <Reject>
in screening url, DialCallStatus
will be set to completed
, previously it was set to no-answer
.
<Dial answerOnBridge="true">
, parent call status will be
ringing
until the screening url is complete. Previously it was set to
in-progress
immediately.
ringing
until answered and
in-progress
when screening. Previously it was set to
queued
until answered.
<Dial answerOnBridge="true">
, the parent call will report a status of
no-answer
until and unless it is bridged to the child call.
DialCallStatus
will be set to
completed
. Previously
DialCallStatus
was set to
no-answer
.