I have a situation where I need to connect 2 persons together using Twilio Elastic SIP Trunking.
So, I have two mobile phone numbers, I need to call first person and when he answer an incoming call, I need to call second person and when he answer an incoming call, connect them together.
Those 2 persons could be in different countries. So, is it possible to use Twilio's Elastic SIP Trunking to accomplish this purpose?
Twilio developer evangelist here.
I believe this is a follow on from your previous question. I recommend you read my answer there.
If you have two people with separate phones, then you are not looking to use Elastic SIP Trunking. That feature is for when you have a PBX and SIP phones and you are looking to connect them to the PSTN.
Related
I saw that Twilio's Lookup API can tell you whether a phone number is landline, mobile, or voip, as well as what the carrier is. Is there any functionality or possibility of telling whether a number is disconnected or not, similar to what RealPhoneValidation does?
For example, I looked up a disconnected phone number in RealPhoneValidation and this was the output, versus the Twilio Lookup API only provided the line type and carrier.
Problem
By default, Twilio Lookup API does not provide information on phone number’s connection status with provider.
Solution
Twilio Lookup API allows for “addons”, one of which being the “payfone” addon that uses another service (payfone) to determine phone connection status.
References
Twilio Lookup API: https://www.twilio.com/docs/lookup/api
Twilio addons: https://www.twilio.com/docs/add-ons
Twilio Payfone addon: https://www.twilio.com/docs/add-ons/quickstart#using-the-payfone-lookups-add-on
I have the next situation:
A call is made to a PSTN/DID number of my phone company and that I can use with proprietary SIP cell phone app or SIP client application like Zoiper / Linphone configuring with SIP, user and password.
I cannot configure this service to forward a call to 3rd party service SIP URI. I've already asked it to my PSTN provider and they say that it is impossible.
The question is:
How can I make Twilio (or maybe another service) register as SIP client with user and password (like extension/endpoint ) to receive a call from PSTN and forward it to other SIP URI or phone number?
I know that asterisk / some cloud pbx can do it like it was previously free account at pbxes.com.
Have you considered porting your number to a carrier that will allow you to forward inbound calls to a specific SIP URI you configure or register for calls to that URI, given your current carriers constraints?
For example, Twilio has some documentation here on porting a number.
International Porting
Porting a number To Twilio
I understand, based on your country, this may not be an option.
Twilio does not have a way to register as a SIP client with another provider. It does offer the ability of using a Twilio hosted number (and thus the comment on porting) to register a SIP client against or forward a PSTN call to a SIP User Agent.
I know there are some twilio experts here and would really appreciate it if someone could answer a question for us and if so, please let me know if you do freelance work.
Our website offer clients to purchase numbers, which are twilio numbers, and we forward the calls and SMS to their original number, while doing demographics, call recordings and marketing. The number on which call was received is important to us. We want to use Thinq LCR to reduce cost. But Thinq wants us to port the twilio number to them. If we port the twilio number to Thinq, will the existing twilio services break? and on which routing profile will we forward the numbers after porting, if twilio number has been ported to thinq, there's no twilio number to forward anymore. And will we need to change all the code to work with the new Thinq API as twilio is out of the game now?
Thank you!!!
Chip :)
From what I understand of your problem, you should port your existing Twilio DIDs to ThinQ and switch to provisioning new DIDs from ThinQ directly, going forward.
Once the DIDs are visible in the dashboard (i.thinq.com), you would configure them all to route to a Twilio SIP domain that you will need to create. See https://www.thinq.com/thinq-voice-origination-with-twilios-bring-your-own-number-byon-service/ for instructions on how to do this.
With this setup, people trying to reach your clients would dial the DIDs controlled by ThinQ. ThinQ would send the SIP calls over to the Twilio SIP domain which would then interact with your server's callbacks to handle the call.
Your callback would use the appropriate Twilio API (REST or TwiML) to dial the client's actual phone number via SIP so that it goes over your ThinQ VoIP account for lower costs (e.g dial to sip:#wap.thinq.com?thinQid=&thinQtoken= )
Twilio is cool and has great prices for calls and toll-free. I have used it with Zoho CRM, but I would like to use it without being tied to a CRM.
Is there some service or place where you can just download or use ready-made web or windows clients? I want to use Twilio similar to how I would use Skype - and have it automatically / easily connect to my Twilio account. My Google searches have not returned any results.
The closest (already built client) I can think of is a SIP client, something like Zoiper.
Take a look at my answer in the link (it only describes the setup for voice but you could add messaging too):
How do I forward a Twilio number to a VoIP phone?
Basic question here...for making calls in/out of Twilio, between PSTN numbers and SIP endpoints (e.g. PBX), it seems you could accomplish this using 1 of 2 methods:
Twilio SIP (using TwiML for translating between PSTN call and SIP call)
Elastic SIP Trunking
I'm wondering what the main differences in these methods are. It seems that with Twilio SIP you have use of TwiML-based applications, and with SIP Trunking you do not...is that the only difference?
ELASTIC SIP Trunking by Twilio is VoIP Carrier option with Global reach such that Load balancing / geographical redundancy and every other interconnect pain point is handled by Twilio and you can just focus on your application and not worry about interconnect partners and call termination in different countries.
I believe, after having built the partnerships to do the call terminations for applications that were making calls using TwiML, they decided to open the infrastructure to applications that dont necessarily have to be written over TwiML.