I am looked through the documentation for over 30 sms vendors, not one supports replies through alphanumeric sender ids. I am wondering if this is technically possible at all? Or know of any vendors that provide this service? Thanks.
(I did this 20 years ago, but SMS didn't change that much over the years).
The chief problem here is that alphanumeric senders are typically used in mass communications scenario's, not 1 to 1 communication. Technically there's no reason for such a restriction. The SMS sender field has a format, either digits or alphanumeric characters, and that field is not specially restricted for replies.
Vendor suggestions are off-topic BTW.
Related
RFC 822, 3696 and others specify email address formats and how those should be validated by applications. Unfortunately in practice virtually nobody adheres to them, with most developers tending to invent a regex on the fly or copy-n-paste one from dubious sources to validate their user's email addresses. This in practice leads to many web services requiring email addresses, often as the primary identity of their users, yet only accepting a very limited subset of addresses that the RFCs actually allow.
So, can anything be said about the current state of what is generally considered a "web safe" email address? Is there some common subset that has crystalized over time that's accepted by most services? What's the standard for the HTML 5 email input type, which will hopefully eventually emerge as the default quick front-end validity check for emails?
Please note that I'm not asking what should be done to validate email addresses. Ideally validation should consist of light front-end validation which allows every possible address and possibly some false-positives, followed by a callback validation with the actual email server on the backend. I'm asking instead whether there is any sort of consensus on what the current implementations in the wild regard as valid. If I were to create a regex to validate email addresses (which I'm not, but humor me), what should that be to roughly match what everyone else does? If I were to create a new email address for myself on my own server, what safe subset should I stick to in order to be able to use that address at most web sites?
You pretty much answered your own question in your first paragraph.
TL;DR there is no consensus.
I am trying to send an SMS to Mexico via Twilio. The Mexican country code is 52 and the area code I am sending to is 667.
I have tried the following
+521667xxxxxxx - which I believe to be correct based on http://en.wikipedia.org/wiki/Telephone_numbers_in_Mexico#Dialing_a_cell_phone_in_Mexico_from_abroad
+011521667xxxxxxx
+001521667xxxxxxx
+52667xxxxxxx
I get the following error from twilio - "is not a mobile number"
This question is old, but people might still wonder about this, so here it goes:
+521667xxxxxxx used to be correct up until August 3rd, 2019. The correct format is +52667xxxxxxx since then. Even now you may have varying degrees of success using the former format since telecom companies are still allowing it, but you should use the new one to avoid problems in the future.
You can confirm this information here: https://www.mexperience.com/mexico-simplifies-telephone-dialing-rules/ (one of the few sources in English I could find)
With respect to the specific number you were trying, it really might not be a mobile number.
According to the twilio docs it would be +53667xxxxxxx. You may also have to enable international messaging
Twilio International Numbers
Enabled International Dialing Permissions
I am investigating SCTP and whether its useful for sending BULK SMS BUSSINESS in any way.So far my efforts have gone vain.I am not from telecom background.
So have faced some challeges to get acquainted.Perhaps any point of advice to use SCTP or ANY other part of SS7 leading to enhacement of the process of sending BULK SMS is highly appreciated.Many thanks for reading this
SCTP in itself will get you nowhere - you need one of the user adaption layers (e.g. M3UA, SUA) - and then the rest of the stack (e.g. in case of M3UA: SCCP, TCAP, MAP). This however will only be useful if you are an mobile operator and have a mobile operator license from your countries telco regulator - as no other operator will have much to do with you without this.
Closest you might get is SMPP interface from a Mobile operator - but these are usually not easily provided. So you are left with working with some other provider which already has arrangements in place with the operators in your country. Though it is theoretically possible that one of them might require you to use SCTP - it will not be to carry SS7 (i.e. MAP).
Quick question that I can't find an answer to...
How do you find what the number of the phone running Windows Phone 7 is?
For example, in the UK the number would start with 447*. I need this information to send to our server so it can send the user a text message when something has happened.
As far as I know, phone number is not available via the API.
Do you mean the phone's actual number or the country code? +44 is the UK international code. If you mean the phone number, I don't think this is possible. In Mango, you can get the Mobile Operator. Mobile operators tend to have their own first few digits, so you could store a table of those and check it against the operator returned. It may not be wholly accurate, but might be useful if you can get a list of numbers of prefix major operators.
It is not available with the API, nor any private methods.
This is also not in the Mango release as far as I am aware.
Its not available directly; but if you definitely need the phone number and you are providing a useful service that the user is interested in, then just ask the user to provide their phone number.
You can validate if the user has entered the number along with country code by looking at the location and determining the country code from a lookup table/ web service.
With the age of text messages and things like that, what's a good way to store phone numbers in a database?
In the USA, text messages are handled by phone numbers but in other countries I hear they use email addresses so I guess there needs to be a way to differentiate between countries that use cell phone numbers as their address.
Addition:
For example, people in the USA might use 432-342-3333 or 1-432-342-3333 while in the UK they might use +44 800 400000 or they might even leave out the 44. The 44 and the 1 makes a difference when automatically sending out SMS. However, checking the phone number for each country can get tedious. In this case, would you split the country code or would you merge it into a single column and deal it with it there?
I would primarily use a text field, or a series of text fields, even if you are using a numerical phone number for the following reasons.
Phone numbers have a great range of values, including extension numbers which may result in numerical columns losing precision.
Losing precision in a phone number is rather bad.
There is no logical reason to want to perform math ( addition/multiplication ) on a phone number.
Additionally, you may want to specify how you are using this data. If you are planning an automated messaging service, you're going to need a series of relaying agents to broadcast via, so you may as well add an identifier that pertains to the relay the information pertains to. Then all you have to worry about is that the relaying agent can understand the content in the text fields.
Generally as text, you don't need all the fancy formatting, unless you need it to parse numbers from different countries that you can't distinguish otherwise. You can always add the formatting later on.
Not as a number!!! Leading zeros may be problematic.
I don't know if you have read these two questions, but they might help you a little.
Phone Number Columns in a Database
Is there a standard for storing normalized phone numbers in a database?
Perhaps it would be wise to store the type of number (landline, cell, fax) and/or the messages that can be received on it (voice, text, email). Note that in the US, it is also possible to send text messages to a phone via email, but I believe that is dependent on the carrier.