Phones won't stop ringing with Twilio Taskrouter

Question

I've been trying to implement a call centre type system using Taskrouter using this guide as a base: https://www.twilio.com/docs/tutorials/walkthrough/dynamic-call-center/ruby/rails Project location is Australia, if that affects call details.

This system dials multiple numbers (workers), and I have run into an issue where phones will continue to ring even after the call has been accepted or cancelled. ie. If Taskrouter calls Workers A and B, and A picks up first they are connected to the customer, but B will continue to ring. If B then picks up the phone they are greeted by a hangup tone. Ringing can continue for at least minutes until B picks up (I haven't checked if it ever times out). Similar occurs if no one picks up and the call simply times out and is redirected to voicemail. As you can imagine, an endlessly ringing phone is pretty annoying, especially when there's no one on the other end.

I was able to replicate this issue using the above guide without modification (other than the minimum changes to set it up locally). Note that it doesn't dial workers simultaneously, rather it dials the first in line for a few seconds before moving to the next.

My interpretation of what is occurring is that Taskrouter is dialling workers, but not updating them when dialling should end, and simply moving on to the next stage of the workflow. It does update Worker status, so it knows if they've timed out for instance, but that doesn't update the actual call.

I have looked for any solutions to this and havent found much about it except the following: How to make Twilio stop dialing numbers when hangup() is fired? https://www.twilio.com/docs/api/rest/change-call-state

These don't specifically apply to Taskrouter, but suggest that a call that needs to be ended can be updated and completed. I am not too sure if I can implement this however, as it seems to be using the same CallSid for all calls being dialled within a Workflow, makes it hard/impossible to seperate each call, and would end the active call as well. It also just seems wrong that Taskrouter wouldn't be doing this automatically, so I wanted to ask about this before I tinker too much and break things.

Has anyone run into this issue before, or is able/unable to replicate it using the tutorial code? When testing I've noticed the problem much more on landline numbers, which may only be because mobiles have their own timeout/redirects. VOIPs seem to immediately answer calls, so they behave a bit differently.

Any help/suggestions appreciated, thanks!

Answer 1

Current suggestion to work around this is to not issue the dequeue instruction immediately, but rather issue a Call instruction on the REST API when the Worker wishes to accept the Inbound Call.

This will create an Outbound Call to bridge the two calls together and thus won’t have many outbound calls for the same inbound caller at once.

Your implementation will depend on the behavior that you want to achieve:

1. Do you want to simul-dial both Workers?
2. Do you want to send the task to both Workers and whoever clicks to Accept the Task first will have the call routed to them?

If it's #2, this is a scenario where you're saying that the Worker should accept the Reservation (reservation.accepted) before issuing the Call.

If it's #1, you can either issue a Call Instruction or Dequeue Instruction. The key being that you provide a DequeueStatusCallbackUrl or CallStatusCallbackUrl to receive call progress events. Once one of the outbound calls is connected, you will need to complete the other associated call. So you will have to unfortunately track which outbound calls are tied to which Reservation, by using AssignmentCallbacks or EventCallbacks, to make that determination within your app.