I have an application that uses Twilio Programmable Voice.
The app is basically a call center. There are several instances deployed, each one has its own Twilio phone number and a pool of available human operators who can answer incoming calls. When GSM call is received from the customer to instance's Twilio phone number, Twilio invokes a WebHook on our side, and then we simply find an available person from the pool and return a TwiML like this:
<?xml version="1.0" encoding="utf-8"?>
<Response>
<Say>Hello. Connecting you to the available operator.</Say>
<Dial callerId="{callCenterNumber}">{operatorNumber}</Dial>
</Response>
Now the customer is connected to available person from the application instance's pool. So far, so good.
Now I want to handle the case when no available operators were found in the pool of the application instance that was originally called. In that case, I want the original app instance to connect to another instance's Twilio phone number and to be treated as a customer of that instance, so that the original human customer will be connected to an operator from another instance's pool. To achieve this, instance A simply returns <Dial callerId="{callCenterNumber}">{anotherCallCenterNumber}</Dial> (dialing anotherCallCenterNumber instead of operatorNumber in the example above).
So, instead of this connection: Customer => Call Center A => Operator from A's pool, I have Customer => Call Center A => Call Center B => Operator from B's pool connection.
It also works fine and I can chain even more call center instances until available operator is found somewhere.
The problem is, I want to use SIP protocol for instance-to-instance communication instead of GSM phone numbers, because I need to pass some extra data (language, etc) along the way, so that the next instance knows how to handle the call and find the right operator to answer it. SIP headers looks like a suitable solution for passing this data. Everything else will stay the same.
So, I configured a SIP endpoint for each application instance and set up Request WebHook URLs in a similar manner to regular Phone Number WebHook URLs. Now, to dial another call center instance via SIP, I return the following TwiML:
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Say>Hello. No available operators were found. Connecting you to Call Center B.</Say>
<Dial>
<Sip>sip:callcenter#instanceB.sip.us1.twilio.com?x-customHeader=customData</Sip>
</Dial>
</Response>
At this point, I expect that Twilio will invoke instanceB SIP Domain's WebHook, so I can handle the call and route it the same way as I used in regular Phone Number WebHooks.
Instead of that, the call is dropped immediately, and in the Twilio Debugger I see following warning:
32009 - The user you tried to dial is not registered with the corresponding SIP Domain
After some research, I realized that callcenter endpoint must be registered in instanceB.sip.us1.twilio.com SIP domain. But, it seems like the only way to do that is using a softphone client app like X-Lite or Jitsi. I installed X-Lite locally and added a callcenter account. Now when Call Center A receives a call and instructs Twilio to dial Call Center B (sip:callcenter#instanceB.sip.us1.twilio.com), my local softphone starts ringing, and if I answer it, I will be connected to a customer calling Call Center A. This is not what I want at all!
Also, I found that if I call any address from the softphone, even unregistered one like sip:unknown#instanceB.sip.us1.twilio.com, then strangely enough Twilio will invoke instanceB SIP Domain's WebHook without any complains. But that's also not what I need. I need Twilio => Twilio connection over SIP in the same way as it worked when using Phone Numbers.
So, to sum up:
Is the described scenario with Twilio-to-Twilio over SIP communication possible at all, same way as Twilio-to-Twilio over Phone Numbers?
Why Twilio returns an error The user you tried to dial is not registered with the corresponding SIP Domain when it receives a TwiML instructing it to dial unregistered SIP endpoint, but at the same time it doesn't return that error when I'm dialing the same unregistered endpoint from the softphone client?
Unfortunately you cannot do this via SIP. Twilio doesn't host SIP endpoints for you.
Related
I'm trying to combo the concepts found here (make a voice call with proxy) and here (click to call) but I'm running into a bit of a mental hurdle in that it seems to initialize a proxy call, you need to call a number. From the docs:
If your Twilio Phone Numbers are voice capable, you're now ready for a proxied voice conversation. Following the names from the previous steps, get Alice to make a call to her Proxy Identifier number. Twilio's Proxy service will then make a call from Bob's Proxy Number to his real number and connect the two calls.
What I'd like to do is have Alice click a button on her desktop, have the Proxy Identifier Number call her, then let Twilio's proxy make the call from Bob's proxy number to his real number and the two of them could chat.
Is there a way to trigger the call from the Proxy Identifier number to Alice?
You can use the Twilio REST API Calls Resource to initially trigger the call to connect the parties, using each participants proxy number as the respective CallerID. When they call or SMS each other back, the proxy session will be active.
Making Calls
TwiML™ Voice: - Twilio
I have a somewhat peculiar situation for which I can't find documentation: I have an application that will use the Twilio API to initiate a voice call from phone number X (my number) to another one. The problem is that number X could already be in the middle of another call, one that was not initiated with Twilio (so my application wouldn't know about it). Would Twilio detect this, and send an error, or try to initiate the call anyway? If the former, what would the error be? I have found the error code for "callee busy", but nothing similar to "caller busy".
Alternatively, is there an API call I could make before initiating the call to make sure number X is available and not in another call?
Twilio numbers can have multiple calls associated with them, so there would be no error id the Phone X was on an existing call (since phone numbers can be routed however you choose). You can set the outbound CallerID to be another Twilio number or a verified callerID (but if they call that verified callerID back, it wont go back to Twilio but the carrier/business owning that number).
Once the dialed party answers after making the outbound API call, you tell Twilio how to route the other piece (who to connect the answering party to) via the URL parameter hosting the Twilio Markup Language (TwiML).
There is an API call and example for, Read multiple Call resources and filter by call status and phone number (Code Example), you could query before making your outbound call (assuming you always map inbound calls to the same endpoint) or routing your inbound call (which probably makes more sense if you want to re-route to another destination who can answer the call).
The status of this call. Can be: queued, ringing, in-progress, canceled, completed, failed, busy or no-answer.
I would like to forward call from mobile phone numbers to a single Twilio number (using regular carrier forwarding functionnality).
I would like to know if there is any way to get the original callee id from the incoming call on the Twilio number (i.e. the mobile number of the original recipient of the forwarded call).
Said differently, I would like to be able, when I receive the call on Twilio, to make the difference between calls forwarded from the number A and calls forwarded from number B.
If this is not possible like this, is there any other option ?
My recommendation would be to not forward the calls to Twilio and call the Twilio number directly. The ability to capture the original called number is carrier dependent and not reliable.
ForwardedFrom - https://www.twilio.com/docs/voice/twiml#request-parameters
You could also forward the call to Twilio via SIP (rather then over the Public Switched Telephone Network), and possibly pass an X-Header with the original Caller ID, but that is most likely not possible with your existing carrier.
Situation
I use Twilio iOS SDK for my iOS Voip application.
I'm trying to call from my Voip application to any numbers I stacked in some points though.
I already confirmed that Http request is sent to my app request url which I set on the url both when I make outgoing call from my Voip application and when get incoming call to my Voip application.
In short, below is the flow which I think it true when I call from my Voip application
type the number and call (iOS Voip Application ) -> the request url is called and returns TwiML to call number I typed(my server side) -> call to the number(Twilio Service) -> get call(phone)
Question
What is the best practice to call from Voip to any numbers?
can I set different request url for incoming and outgoing call separately in one application on the Twilio console, or we have a way to judge if it's incoming or outgoing call by parameter?
What kind of TwiML I should return when I want to make an outgoing call from my Voip Application to the phone?
My server side script returns <Response><Dial><Number>090xxxxxxxxx</Number></Dial></Response> when the request url which I set was called to call from my Voip application, but it failed unfortunately and recorded not as outgoing call but as incoming call on Twilio call logs. I know I should return <Response><Dial><Client>name</Client></Dial></Response> when it comes to get an incoming call I think it's not appropriate for outgoing one though.
Kind Regards.
Edit
Below is the request I got for incoming call from any phone numbers to my Twilio number and the TwiML I return to call my Twilio number in Voip application. It's working well.
[request]
<QueryDict: {u'FromZip': [u''], u'From': [u'+8190xxxxxxxx'], u'FromCity': [u''], u'ApiVersion': [u'2010-04-01'], u'ApplicationSid': [u'AP192f34d8a08f17592163af2c6cxxxxxx'], u'To': [u'+8150xxxxxxxx'], u'ForwardedFrom': [u'050xxxxxxxx'], u'CallStatus': [u'ringing'], u'CalledState': [u''], u'FromState': [u''], u'Direction': [u'inbound'], u'ToCity': [u''], u'ToZip': [u''], u'CallerCity': [u''], u'FromCountry': [u'JP'], u'CalledCity': [u''], u'CalledCountry': [u'JP'], u'Caller': [u'+8190xxxxxxxx'], u'CallerZip': [u''], u'AccountSid': [u'AC41ebdf749095141bfdb182fbd8fxxxxx'], u'CalledVia': [u'050xxxxxxxx'], u'Called': [u'+8150xxxxxxxx'], u'CallerCountry': [u'JP'], u'CalledZip': [u''], u'CallSid': [u'CA7afa3aae965d9207b7e8b065e9dxxxxx'], u'CallerState': [u''], u'ToCountry': [u'JP'], u'ToState': [u'']}>
[TwiML]
<?xml version="1.0" encoding="UTF-8"?><Response><Dial><Client>name</Client></Dial></Response>
While the incoming call does work well, below is the debugged outgoing call request from my Voip application to any phone numbers via my server and the TwiML I returned. It has failed to call and I confirmed the Twilio call log shows no 'To' number while 'From' number is my client name which I used for capability.allow_client_incoming(my client name).
[request]
[TwiML]
<?xml version="1.0" encoding="UTF-8"?><Response><Dial><Number>090xxxxxxxx</Number></Dial></Response>
Twilio developer evangelist here.
If I were you, I would go through the Twilio Client quick start for iOS which will show you various ways you can build this.
To answer your questions.
You can't set different request URLs for inbound and outbound using the same number with Twilio Client, but you can tell whether it is inbound or outbound by checking the direction parameter.
You should use <Dial> and <Number> when going outbound VOIP to numbers. I don't know why that would fail. Could you possibly share more information on the error?
I have a OpenVBX/Twilio setup where I use its dial applet to call particular people in my company. However, when viewing an incoming call on my phone, I have no way to know if the caller is calling via OpenVBX or not.
Is there a way to customize OpenVBX/Twilio so that when viewing the caller's Caller ID on my phone, I can see the Caller ID information and some indicator that the call came through Twilio?
Thanks.
Not sure if this is configurable in OpenVBX itself, or if you'd have to change some of the Dial applet code, but you could just use the CallerID (number) of a Twilio number, instead of using the CallerId of the incoming call.