Twilio developer evangelist here.
The problem here is that when you update the first call to redirect to the hold music that disconnects the other call and ends it.
This is likely because your TwiML ends after the <Dial>
that connected the two calls in the first place. You can keep a call going by either adding more TwiML after the or using the action attribute.
If instead, your Twilio Client leg of the call had the following TwiML:
<Response>
<Dial action="/holding">NUMBER_TO_DIAL</Dial>
</Response>
And the endpoint /holding
looked like:
<Response>
<Say>You have a caller on hold.</Say>
<Redirect>/holding</Redirect>
</Response>
Then your call won't end. It will instead endlessly say "You have a caller on hold". You could implement this however you like though.
Now, instead of shipping the caller on the other end off to "http://demo.twilio.com/docs/voice.xml" you should place them in a queue to wait to be retrieved. So, you'd need another endpoint at say /place-on-hold
which you would update the call to when the hold button is pressed. That would need the TwiML:
<Response>
<Enqueue waitUrl="SOME_HOLD_MUSIC">ADMIN_ID</Enqueue>
</Response>
If you use the ID of the admin who put the user on call then if you have multiple users of the Twilio Client dialler then they will each have their own holding queue.
Finally, you need to Reconnect the callers. For this you need to redirect your admin out of their holding pattern using the REST API again and onto some TwiML that will dial their hold queue which will reconnect the callers. The TwiML would look like:
<Response>
<Dial action="/holding">
<Queue>ADMIN_ID</Queue>
</Dial>
</Response>
This will dequeue the caller on hold and reconnect. Note we also include the action attribute so that the user can be placed on hold again.
Let me know if this helps at all.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…