Open source toolkit for voice services; with special focus to the needs of medium- and low-income countries, scalable services, and interacting with vulnerable populations
We implement the progress callback to make progress on a call after is has been answered. Otherwise we guess that a call didn't answer for example (pending for 2 minutes), and we're not notified by a call has ended. If someone hangs up, we don't know about it, which might be the what leads to #900 (sometimes).
While working on the Twilio simulator, I noticed that Twilio had two different callbacks: a progress callback and a status callback, to report states such as no-answer, busy, failed, ...
Looking at the Twilio integration in the broker, all those states seem to be handled and implemented. What's missing is telling Twilio the StatusCallback params (in addition to URL) and adding the http endpoint (in the broker) that would merely pass the state to the twilio pbx to handle.
This could improve the throughput of calls to Twilio, that will tell you sooner (1 minute for no-answer, possibly even sooner for busy) that a call didn't answer instead of relying on a 2 minute timeout. Same for hangs up while a survey is running, we could be notified as soon as the call ends (instead of a 10 minutes timeout waiting for input).
We implement the progress callback to make progress on a call after is has been answered. Otherwise we guess that a call didn't answer for example (pending for 2 minutes), and we're not notified by a call has ended. If someone hangs up, we don't know about it, which might be the what leads to #900 (sometimes).
While working on the Twilio simulator, I noticed that Twilio had two different callbacks: a progress callback and a status callback, to report states such as
no-answer,busy,failed, ...Looking at the Twilio integration in the broker, all those states seem to be handled and implemented. What's missing is telling Twilio the
StatusCallbackparams (in addition toURL) and adding the http endpoint (in the broker) that would merely pass the state to the twilio pbx to handle.This could improve the throughput of calls to Twilio, that will tell you sooner (1 minute for
no-answer, possibly even sooner forbusy) that a call didn't answer instead of relying on a 2 minute timeout. Same for hangs up while a survey is running, we could be notified as soon as the call ends (instead of a 10 minutes timeout waiting for input).References: