So I'm trying to figure out how companies are able to provide free phone numbers to their users like Skype and Google Voice? I tried doing some research on who maintains a list of available phone numbers like ICANN and found NANPA (North American Numbering Plan Administration). It doesn't look like you can purchase a block of phone numbers from them.
So if I wanted to purchase bulk telephone numbers and provide a service where I could give my users a free number, do I just call AT&T and purchase from them?
Any help or direction would be greatly appreciated.
I'm trying to figure out how I can provide a phone number to my users so I can deliver text messages to them (outside of a cell phone number). Like how users are assigned a phone number from eFax and anyone can send them a fax.
My assumption is that eFax purchased a block of phone numbers from a provider which then assigns to users to receive fax messages. If you own the number, the routing should be fairly simple.
So maybe the direction is to provision the number in real-time as users sign up and pay that fee (whatever it may be).
I'll check out your link to bandwidth.
Check out http://www.bandwidth.com or http://www.voip-info.org/wiki/view/Bandwidth.com.
Bandwidth.com has an API for real-time provisioning. I'm not sure about the cost though.
Essentially, you don't even have to purchase them. You just need to be a (registered) telephone company. That's a bigger burden than you probably expected, but I expect Skype and Google did this. For smaller companies, it may be wise to outsource this, but you'd want to find a partner that isn't competing with you. AT&T wouldn't sound like the best partner if you're going to sell VOIP to consumers.
Related
I looked at Twilio's Masked Phone Numbers tutorial. It mentions that we can create "disposable" phone numbers.
My question is: How/ when to dispose those purchased numbers on-demand?
You can imagine our app to be like Uber, where riders and drivers need to communicate anonymously just for the duration of the ride.
When the ride starts, we purchase a number using the Twilio API. But, when the ride finishes, should I
(1) release the phone number and purchase a new phone number for every new ride? This will be easy to implement.
OR
(2) keep the purchased number and reuse it to avoid the charge for buying a new phone number for every ride (the $1/month charge for a new phone number)? But, the overhead is to keep track of the purchased phone numbers.
Any help is appreciated. Thanks!
Twilio developer evangelist here.
I recommend that you keep a pool of numbers that you can use to avoid incurring a charge every time you need a new number, but build your system to be able to purchase a new number if the pool is exhausted. Once you start buying numbers, when the ride is finished you can inspect how many numbers you have and compare to your pool size, releasing the number if you are over your default pool size. Alternatively, you could mark numbers as permanent and temporary and always release temporary numbers.
This is a bit of a wide question, there's many answers, so it's not ideal for Stack Overflow. If you want to chat more about this, let me know in the comments and I will share my email address.
The Scenario:
I have a exclusive mobile chat app. Users can communicate with preselected and know groups of people that don't use the app via an SMS bridge. For that purpose currently each user get's her/his own virtual phone number. SMS for an specific user are sent and received via this virtual number. The SMS are distribute to each member of the group she/he communicates with.
The Problem:
A single receiver can be member of more then one group. In this case, when a receiver (R) responds to an SMS message from the user (U), it is not unambiguously clear wich group the response belongs to. Because the only available information is the sender (R) number and receiver (U) number (virtual) we can not be certain wich of the groups that R belongs to the message came from.
Solution Idea:
The only way I can see to get around this problem is to have U use a different phone number to communicate with each group. Assigning each user many phone phone numbers for that case isn't scalable at all because of the costs. But I also would at least initially like to avoid the complexities of managing a vast number pool that automatically assign numbers to individual communications.
Question:
Is there any way at all to add additional digits to the senders virtual number when sending an SMS? So that when he/she replies to that number, the context is transmitted back to the server
Twilio developer evangelist here.
I'm afraid there isn't anything within SMS that does what you need. You were right when you supposed that U should have a different phone number to communicate with each group.
It's not all bad though, because you can set up which users are in a particular group, you can reuse that number for a completely different group. Here's a good article on scaling number pools for group messaging that might help.
I'm working on an app-idea that enable users to sell goods and services through the app. For this to work I need to be able to pay users, much like uber drivers are paid for their rides or how snapcash transfers money from one user to another.
Does Apple have any framework to do this in iOS apps?
Does it have to be country specific maybe? So that every user register their bank account and my company takes money from one users credit card and makes a bank transfer to the receiving user.
Any input or pointers to where to find more info on this is much appreciated.
No, Apple does not have a framework to do this, unless you use Apple Pay (in which case it's not a P2P payment).
Your solution will have to be country specific and more. I.E. bank specific. You'll have to have deals in place with each bank you want your system to work with.
I believe you would like to have a checkout option on the mobile. If this is the case, there are lot of options available. It depends on country and what exactly you are trying to achieve.
Please more information to assist you.
I've been working with Twilio to program SMS functionality on my app, and it seems that Twilio works best with US numbers and not so well with international numbers. I've done some research and have learned about an August 16th fiasco that resulted inthe SMS functionality being shut off by Twilio. Also through testing I have learned that some international carriers are not supported by Twilio. So some of my friends abroad aren't receiving my Twilio SMS messages.
Can anyone provide further insight into this issue? Is international SMS well supported by Twilio? If not, how many carriers and which ones ARE supported? Finally is there a better SMS service provider that can guarantee full support for all if not the more prevalent carriers internationally?
Thanks for the support everyone and any clarification on this issue.
Good questions all - this information can be kind of hard to find on our website right now. If I'm picking up what you're putting down correctly, you're curious what kind of availability Twilio SMS has internationally and what the deliverability is like.
The matrix on what kind of Twilio service is available where can get a little complicated (which we have here a little buried in our FAQ: http://www.twilio.com/help/faq/phone-numbers/which-countries-does-twilio-have-phone-numbers-in-and-what-are-their-capabilities), but for SMS it breaks down like this:
Twilio phone numbers that can send and receive SMS are available in the US, Canada and the UK.
US and Canadian numbers can send and receive to 190 countries to over 1,000 carriers. To see what the pricing for each country and carrier per message, check out this page: https://www.twilio.com/sms/pricing
UK numbers can currently send and receive SMS reliably within the UK. As the numbers themselves are geographic, some international carriers do not allow messages to be sent or received to them. This might be a possible root cause for some of the deliverability issues you experienced.
All other phone numbers we make available in other countries only have support for Twilio Voice - these numbers cannot send or receive SMS at all.
I'm not aware of any SMS related incident on 16 August, though we did have intermittent service interruption the week before on 9 August lasting a little under 90 minutes. For future reference, we communicate all our service issues on an independently hosted status board here: http://status.twilio.com/ Any issue, root cause and resolution are posted there for your review.
Finally, if you have a specific question about a number, deliverability to a particular carrier or handset, or would just like to share a cool hack, I definitely encourage you to engage one-on-one with our support crew at help#twilio.com or come meet one of my fellow developer evangelists when you're out at a programming event. We'd love to see what you're working on and if there is anything we can do to help.
Thanks Kev!
Rob - devangel at Twilio
I have a slightly different issue, but my discussion of the problem addresses some of the questions here. In essence, if you want to SMS internationally without upgrading, your limitation is that you can only text to numbers that have been manually verified through this website. You have to log in, use a US phone number, and then "Verify" your international numbers. By upgrading your account you no longer have to manually verify each number.
Twilio is very strong in USA, however, you may try to use several SMS suppliers for delivery of your messages internationally. Also, if you would like to test a delivery of your messages to a certain country where you do not have a testing mobile phone number, you can send it on telqtest.com testing numbers.
On WhitePages.com they have a mechanism in place that facilitates payment by entering your telephone number. After you enter your number, you get an SMS that instructs you to enter "GO" in order to complete the transaction. Following that reply with the purchase you've made, you get another message suggesting that for a certain monthly fee you can use the service in an unlimited fashion. I had not seen anything with quite those dynamics before and I'm curious of what service(s) one would use to construct a payment system like this for a Ruby on Rails app?
I am particularly interested in a platform that allows this kind of payment from as many countries as possible as I currently use Twilio for SMS messaging on another app.
Without knowing the full details of what WhitePages.com offer it sounds like they're using Premium SMS as a method of collecting payment from a mobile.
After you've entered your telephone number, they'll send you a text with the originator set to a premium shortcode (rather than from a long number). The reply you send back to the premium shortcode is deemed your acceptance to be charged more than your standard network SMS rate. The amount of the charge can vary but should be made obvious to subscribers before they are charged. This Mobile-Originated reply text (MO) is what causes the charge to be taken from your mobile telephone number bill.
Premium subscription services can then subsequently generate further charges whilst the user is still subscribed by sending messages from the premium shortcode. The act of receiving these messages causes a charge to be applied to your mobile telephone bill. These are deemed Mobile-Terminated texts (MT).
Premium SMS is not a simple solution for collecting payment for a number of reasons.
You often only receive a small percentage of what the user is being charged on their bill as the mobile networks keep a cut for offering the service.
As this relies on premium shortcodes you may have to accept you'll have different numbers for each country you want to operate in as you'll have to organise premium shortcodes in each country.
There's different regulations regarding Premium services that you need to be aware of in each country. For example, users need to be able to unsubscribe / opt-out of premium services once subscribed so premium services often have to comply with receiving 'STOP' and 'STOP ALL' messages from users.
As far as I know, Twilio doesn't support premium shortcodes at this time. There are other SMS Gateways which do support premium SMS but you won't get a single solution to fit any country you wish to operate in. Interacting with this kind of system is usually no more complex than sending and receiving normal SMS so the task of creating this with a Ruby on Rails app should be no more complex.
Normal SMS is pretty much globally universal. Premium SMS is an additional country specific feature.