I'm trying to figure out how to set up an SMS service where users can communicate with people on phones that are not participating in my service. "TextFree" on iPhone does something like what I want to do. They let you sign up, then you can send messages for "free" to other friends that aren't part of the service.
It looks like when you sign up for TextFree, they assign you an email address [user#textfree.us]. People outside the service without MMS capabilities can't send an SMS to this user. The user must first send an SMS to them, starting a conversation. I think this is what they're doing:
Textfree signs up for an account with a bulk SMS provider, and is assigned a single phone #, like "123".
Joe signs up for TextFree, gets assigned email: joe#textfree.us.
Mary wants to send Joe an sms, but can't because she doesn't know what # to direct the sms to.
Joe sends an sms to Mary using textfree. This really just makes an http request to some textfree server. The server gets the request, and the destination # (Mary's phone).
The server sends the sms out using their bulk sms api provider.
Mary receives the sms, and sees the originator phone # as "123".
Mary replies to the sms, using this phone #, "123".
Their sms provider receives the message, and forwards it to textfree's http server.
Textfree now has to resolve that the sms received by Mary's phone # is destined for Joe (not sure how this can be done), so it can be delivered to Joe's account.
I think that all makes sense and seems feasible, I'm just not sure about that last step, how they could figure out which conversation sms' belong to. If all outside users are directing their sms to phone #123, how could I figure out which internal user the message is destined for? Is there some way to embed a unique identifier in an SMS, so that when the external user replies to the SMS, some unique ID can be embedded in there to provide that type of context to read on the reply side of things?
Long question, thanks for any thoughts!
As for the last part of your question (unique ID in SMS):
I know of no mechanism that could help you here. When replying to a short message phones only set the sender address as destination and the user is free to type the text. The headers in a short message PDU are solely for the basic transport parameters (encoding, sender-ID, ...). There is a way to define so called user data headers, but for this to be of any use for you, you'd have to be in control of most of the devices that are involved in the message delivery, including the handsets... So basically the only way I see to correlate messages with each other reliably is the use of some ID within the message text.
An alternate approach would be to rent a bunch of numbers and assign these permanently (I assume some subscription model here) to your users. This way you could use these as identification numbers within your service and forward the messages to their real phone numbers (or even a completely different media like email / instant messenger).
Related
I already have a SIM card with a company that allows tethering and A2P.
I want to be able to send an SMS with a unique sender ID (company name) using that sim card.
Is this possible and if so, what should I purchase and how do I set it up?
It is NOT possible to alter the senderid when sending SMS using a SIM card + modem. The senderid will simply be the number belonging to that SIM.
If you want to have a custom (alpha) senderid, your only option is using a professional A2P SMS gateway. But even then it is not always possible, as not all countries allow alpha senderids. They might get overwritten to a short/longcode, or the operators require senderid whitelisting (basically, you need to request "access" to an alpha senderid, by sending your personal/company details and SMS content details to the operators. This is done to battle SPAM messages)
Yes this is possible.
Most of the time you don't need any SIM card as you'll be using some sort of API, most of the time a HTTPS/JSON or HTTPS/XML API. If you intend to use a SIM to send SMSes, having a dedicated sender ID will be most probably impossible: using a SIM will make your request arrive through the "regular" signaling link just as "any subscriber" that sends an SMS from his mobile, while using an API will make you use the SMPP links to the SMS-C where specific configuration can be done on per client basis. If I misunderstood something, please sent a comment.
Anyway, you have to have an agreement with your SMS API provider or telco to use a dedicated ID
We're building a live chat-like software and we're trying to connect it through Twilio to send SMS messages to our clients' staff members. We've built a backend base in our control panel that would allow staff members to reply to the users through our system (it would send them an SMS back through Twilio).
Our system is built so that a user can send text messages based on a specific interest, which would create a new lead (for that interest type) entry in our system (as well as notify the staff with SMS). We'd like to be able to show a threaded SMS conversation back and forth between the users and the staff members for each of those separate leads/threads.
It's not a simple one-to-one conversation between the user and a staff member because the same user phone number can have multiple threads for each lead type. Is there a way to somehow tag messages so we can detect which thread they belong to?
Twilio developer evangelist here.
The limitation here is the SMS platform. You can see, if you open up your own phone's SMS application, that SMS messages are delivered in chronological order only. You can only reply to the last message sent, not a different message in the history. There is no message threading in SMS.
You have two options:
You insist that your users include a specific ID within messages in a thread so that you can parse the message and extract the ID to tie the threads together. Or, as Digant Shah suggested, use an ID and then assume every message is for that ID until a new ID is used.
You conduct separate conversations between the same users using different Twilio numbers. This way you can tie the thread together using the number that was used.
I've had this conversation in this question before, and the follow up might help too.
Let me know if that helps at all.
With Rocket.chat and Twilio - the incoming chat 'user' is just a mobile number. This is not very user friendly if multiple conversations are ongoing. Responding to and tracking conversations by name and not phone number is much better if possible.
I have a database that could be used to match the incoming SMS phone numbers to a human name for most of my expected incoming SMS IM's. Trying to figure out the best way to do a lookup and add that to the Twilio # identity so that the 'chat' makes more sense to the in-house user who would be using it.
Appreciate any ideas anyone might have that would save me from re-inventing the wheel w/ Twilio and Rocket.Chat.
Related to RocketChat: How to send SMS Messages to Livechat channel from mobile
Twilio developer evangelist here.
I have not used RocketChat for this before, I just took a look through the code to see what I could find.
Turns out, RocketChat has a field for phone number on the user model and when an incoming message is received it looks up a user from their phone number. If the user is found, the message is sent from the user, otherwise a new user is created.
So, what you need to do is merge your database of usernames and phone numbers with the RocketChat User model.
Hope that helps!
I am currently using Twilio to send balance notifications for customers who have opted into SMS notifications, but have run into an issue in positively identifying accounts in the message logs. A number of customers have multiple accounts due to the nature of my industry, but naturally use the same phone number across all accounts. Is there any way to pass a parameter containing their internal account ID in the HTTP POST request without including it in the message body? I've searched extensively through Twilio's API docs and cannot find this addressed anywhere.
Twilio developer evangelist here.
As far as I know there is currently no way to store metadata, like your account ID, within an SMS sent via Twilio.
One idea could be that you purchase a number of Twilio numbers and tie together a user's phone number, a Twilio phone number and the specific account. That way, if you always send balance notifications for a specific account from a specific number then you can identify that message in the logs as belonging to that user phone number for that account.
Alternatively, I'd have thought it would be useful for users, if they have more than one account, to see to which account you are referring in a balance notification. Would it be possible to include the account id (or some other identifier that the user would recognise) and then parse that out of the message when reconciling messages and accounts?
Not exactly the question but if you are using twilio webhooks for status callbacks you can pass query string params through the status_callback parameter when making the call to send the SMS message and get it sent to your endpoint
I have built an app that sends out an SMS using the twilio number(the one assigned to me) when a message is sent I receive the SID number which is inserted into the db, along with some other general information, however I do not know how to connect the received SMS SID to the sent SMS SID that tells the system that user has responded....how does someone connect the outgoing message to what is received?
UPDATE:
Hello Devin, Thanks for the response! however, this does not help me much as I might send lets say one of three different people multiple messages in an hour.
my app is a notification app...basically it is a form that a user fills out with some basic info. one of these fileds they choose is a drop down of three different people(who the message will go to) they send the message. my app then inserts the form data explained above along with the SMSID that is returned by you guys into a DB.
the user(one of the three people descibed above) that was sent the notification above responds to the message, meaning that Twilio hits my "Request URL" and I save all the information that is returned by the user...however, and where the problem actually lies is that the SMSID for that reply is not the same as the SMSID of the sent notification...therefore I have no way to connect the SMS that was sent to the user with their response. I have looked at the cookies option and that is not what I am needing...actually your documentation actually acknowledges this issue but does not offer a solution as seen here under "Application Initiated Conversations"
https://www.twilio.com/blog/2014/07/the-definitive-guide-to-sms-conversation-tracking.html
So if you know of a way around this, I would love to hear it for sure :)
Twilio evangelist here.
The SMS protocol has no concept of a "conversation". Each message sent is unique and has no knowledge of messages sent before or after it. Twilios SMS Sid is simply a unique identifier for an individual message.
The typical way to solve this is to use the To/From phone number pair as the unique identifier of an SMS conversation. When you send your first outbound message, store the To/From phone number in your database. When the user replies Twilio will tell you what number they sent the message to and from and you can use that information to look up the original outbound message in your database.
If a "user" can be involved in several different conversations at once you either need to use a unique phone number for each seperate conversation (allowing you to use the technique above), or you need to have the user include some type of conversation ID in their reply (which you can use as the unique identifier).
You can buy a pool of numbers and as each conversation "ends", recycle the number for a new conversation.
Hope that helps.