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.
Related
By default, Twilio trial accounts can only send SMS to numbers that are listed as Verified Caller IDs in the Twilio console. These numbers have to be added manually, and require a verification message before they can receive SMS. This is an excellent feature for development, as it prevents accidentally sending SMS to wrong numbers.
My problem, is that I am developing for a client whose account is already out of trial status. I don't want the software in development to be able to send text messages to any number, because there is a risk of sending dev messages to the client's actual customers. However, we need to be able to send to some numbers for testing. Is there any way to turn the trial behavior back on? That is, can we somehow configure Twilio to only allow sending SMS to verfied numbers, even if it is not a trial account?
If this isn't possible, I think I can query the Outgoing Caller IDs resource from my program to verify the recipient number against the list before sending. However, this puts the responsibility back on my development team, and the possibility for mistakes remains. I'd like to be able to block the behavior at the Twilio level.
This behavior is only applied for trial accounts, however I'll pass this feedback on internally.
You'll need to replicate this behavior yourself for your applications using an upgraded account.
As you mentioned, you can query the Outgoing Caller IDs to get the phone numbers you have already verified with Twilio and use that as an accept list.
However, for your use case, you can store and fetch the accept list using whatever way is most convenient for you, like in code, file, database, etc.
Depending on your needs, you could embed this logic directly into your app, or use a single shared library, or create a web API that all other apps have to use to send texts.
Good luck! We can't wait to see what you build!
Update after getting internal feedback.
You can create a new trial account, even with the same Twilio profile, which would give you promotional credits and the same verified Caller ID limits again.
The promotional credit should last you a long time for test scenarios.
We have recently implemented group chat functionality for an existing application using Twilio Programmable Chat.
Context: The application allows users to connect with each other and join groups. We are using Twilio to add a real-time chat room within each group so that group members can communicate. So when a user joins a group, he/she accesses the Twilio chat channel, as well as various other group resources.
When a user joins a group (as defined by our app), it seems that they are not considered a member of the group's channel unless they are active in the chatroom (i.e., when app is not in foreground, user is not listed as channel member). We are trying to do find some way to introduce persistent notifications for the group in the Twilio channel (i.e., "John Smith has joined the group" or "Jane Smith has left the group"). In another SO discussion, philnash had mentioned using the Twilio REST API to send system-authored messages with this information, and then manage these messages on the UI side to format them as group "updates". That makes sense!
My questions are:
Do I need to handle sending system-authored messages on our backend? If so, I'll need to add a field to my Groups model to include the Twilio channel SID for the group.
Is it possible to mute notifications for these system-authored messages (which will be formatted as "channel updates")? I.e., is it possible to not send push notifications to users whenever the message being sent is authored by system?
I hope my questions are clear enough. Thanks so much for any answers or guidance anyone can provide for the above!!
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.
I have developed an iPhone application for a café. In the application you can order takeaway food and therefore I need a way to be sure that there are no orders in a "fake" name (e.g. a person who makes an order with a strangers name, e-mail and so on)
Therefore I have to make the user confirm the order before it's sent to the café. I am not sure what the best way to do this is.
I have been thinking of setting up an SMS gateway and when an order is placed, an SMS is sent to the the entered phone number and the user will have to send a confirmation SMS back. I am not a fan of this approach, as the confirmation is not happening in the application itself.
Then I got the idea that this might be possible with push notifications. I am not exactly sure how it would work (if you have any ideas on this, please let me hear) but since Apple writes the following in their documentation I do not really dare to rely on this for confirmation.
Important: Because delivery is not guaranteed, you should not depend on
the remote-notifications facility for
delivering critical data to an
application via the payload. And never
include sensitive data in the payload.
You should use it only to notify the
user that new data is available.
Another approach which would be very easy to implement would be to programtically retrieve the user's phone number from the SIM card but I have read that Apple rejects applications which does this.
I would like to ask if you have any ideas how I can do this confirmation? It could be one of the above approaches or a completely new. Would it be possible to do something with the unique ID that the every iPhone has?
Could you do the SMS confirmation, but only once? Keep a link of UDID and phone number pairs, and once a confirmation has been made for a pair then don't request it again? That way, regular customers will get minimal hassle.
Don't forget that the UDID for a phone number, or the phone number for a UDID, may change, if the person gets a new device or a new SIM card: make sure your code supports that.
Another approach is to validate credit card information up front as part of account setup. Then offer the option to pay now or cash n carry. This eliminate 99% of the no shows.
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.