I built an app that sends SMS messages with a URL to a list of users. When sending to Google Fi phones.
the message is "Your Weekly Report is now available! Log in to check it out: [URL]".
This message sends successfully with the URL in it to phones on AT&T, Verizon, and other carriers, but not to Google Fi.
This message sends successfully to Fi if I remove the link from the message, so I know the code is good.
I have reached out to Fi and they were not at all helpful.
Any Ideas?
remove the link. Carriers are strict when sending links via SMS, more so when using standard long codes and Application to Person (A2P) traffic (vs. two people exchange SMS directly with one another).
You can try sending from a Toll Free number, to see if you have any better luck but those still experience filtering. The true solution is a carrier short code, but that involves an extensive carrier vetting process of your business and have additional costs involved.
How Does Carrier Filtering Work?
Related
So to help debug we even take it out of our code and put it on twilio portal that lets us test the API. When I send to most of our group everyone gets the text message, but when we send to someone with tmobile, the message says it's delivered on twilio logs, but the person never gets it.
If we test and send him an 'Hello world' message, he gets it, but when we test with out SMS
'XXXXXX wants to make plans with you on the HotSauce App. :tada::hot_pepper:
Get the app now to join in on the action. https://rts2t.app.goo.gl/FGYB'
The message doesn't get delivered. Maybe there's a whitelist for Tmobile we can get on?
FYI, we have a USA number and this is a USA person and we are on the paid version, not trial.
I've encountered the same issue working on another app, and unfortunately I do not think there's a conclusive single answer. Carriers intentionally keep their spam filtering techniques secret so that they cannot be gamed. From Twilio's support page on the topic:
There is no standard practice for carrier filtering across all carriers. For some, filtering can range from a simple static list of prohibited terms to advanced machine learning systems that work in real time. Regardless of the system, carriers keep their filtering systems closely guarded secrets. In turn, Twilio cannot say definitively how these systems work or why a particular message was filtered.
Note that not all carriers report errors to Twilio, so some messages may appear to go through even though they were not delivered. You may or may not see error 30007 in the Twilio console when a message is blocked.
I don't believe any type of universal white-list exists, and once a number has been black-listed by a carrier there is no easy process to have it white-listed. However, short-code numbers are generally less prone to getting spam filtered (though they are more expensive).
While there isn't any one thing you can do to guarantee delivery, there are several things you can try:
Make the language of the text message more conversational as opposed to promotional
Don't obscure the url with a link shortener
Don't over-use a single number by implementing something like Twilio co-pilot
Include clear opt-out instructions
I've been using Twilio to send SMS and things work great. The only issue is that Twilio charges for both outbound and inbound messages. As such, we've been looking for other solutions.
We thought we found it with Plivo as their pricing was more favorable for SMS.
However, with Plivo, very quickly our outbound messages are being marked as spam or something and they're not being delivered.
We are sending the exact same message every day to about 5k users at a given time in the day. The message has a url in it, but it is something our users signed up for.
Two questions:
1. Why does everything work on Twilio and not on Plivo?
2. Is there a code change I can make to ensure our outbound messages sent with Plivo are not marked as spam by carriers and then stopped?
You need to contact Plivo about this. I experience this problem too. Their carrier mark our number as spammer since we are sending almost the same messages (verification). They called their carrier and our number was white-listed.
Plivo Sales engineer here. This is indeed an issue with the carrier marking your messages as spam. We can definitely help you overcome this. Could you please drop an email to ramya(at)plivo.com and we can sort this out?
You need to contact with Plivo support , there may be problem for number prefix for country like if you are using twilio you have to add +(with country prefix) but not in Plivo. It will be better to contact with Plivo support.
Thank You
I dont know how Pilvo work but usually with SMSC there is Message Queue associated sometimes with each SMPP Client and also with Mobile Station. You can't always send messages until your certain number of request are still pending. there is a specific error code that SMSC sent to its client about message queue overflow.
BADABING BADABOM! After having a look in the Plivo administration I noticed a new option under other-settings "Automatic Encoding Of Unicode Characters". As Norway uses inernational characters this is definately a setting for me, and after enabling it all SMS are delivered as expected. So remember to enable this setting.
MAKE SURE TO ENABLE THIS:
Path: Plivo admin / Messages / Settings / Other settings
Feature: Automatic Encoding Of Unicode Characters -> Enable
I am sending SMS using Twilio API. During testing i found that it sometimes delivered message to the phone number but does not sends all the time. This is the case of DND activated numbers(Do Not Call List).
I knew this is because of Sender routing done by Twilio. When Twilio sends SMS using a number(only numeric sender-FROM), i received the message, but when it sends message using some alphanumeric sender(like DM-044138), it does not delivers the message.
Now my question is do we have any access to change this ? Can we set something that could guarantee the delivery even for the DND numbers ?
Any help would be highly appreciated.
Your problem is you are sending it to India.
Please review the following.
This feature is only available when sending messages to supported countries
As you can see from the list below India is not a supported country.
https://www.twilio.com/help/faq/sms/what-countries-does-twilio-support-alphanumeric-sender-id
My web app sends an SMS text message to users in the US when they enter their phone number, using the Nexmo API. When the SMS contains a link, it does not get delivered to users if their carrier is Verizon or T-Mobile. For other carriers, such as Sprint and AT&T, it does get delivered. It does not generate error messages in any case with Nexmo and I still get charged for the text even if it gets blocked by the carrier.
I contacted Nexmo and they replied:
I would say it is very likely that the link in this sms caused a spam
filter to block this message, especially if other plain content
messages have been delivered to this number successfully. So the issue
with US LVNs is that they are intended for pure P2P traffic and this
is why sending a link might be suspicious and seen as a message
originated from an application. Unfortunately there is nothing we can
do about this as it is set by the US carriers.
These are not definitely not spam or marketing messages. How can I send a link in an SMS message and not get blocked?
I had the same issue recently. All major carriers have some basic checks in place which blocks the SMS from getting delivered if you use short links (e.g.http://abc.gl/1432). The SMS will get delivered as long as you have a .com in the URL (e.g. http://abc.gl.com/1432)
Well, I observed that some carriers mark it as spam if have "Some Message. Click Here http://example/somelink" format.
Removing "Click here" part worked for me.
i.e. "Some Message. http://example/somelink"
Got the same issue. I have been using twilio to a t-mobile phone in the US.
SMS Hello Alan, your code is: 146945 for website.com is not working but
SMS Hello Alan, your code is: 146945 is working fine.
I am trying out different things with Twilio, but open for other solutions with Nexmo, Tropo or Plivo.
Here's a situation, I am sending an SMS texts from a server to bunch of clients. I can get a status back: like queued, sending, sent, or failed. Here's what Twilio says about SMS sent status:
"Sent" indicates that your message was successfully sent into the SMS
network for delivery. However Twilio does not receive confirmation from
the destination carrier that the message was received, and this is not
a guarantee that the message has reached the intended device.
(https://www.twilio.com/help/faq/sms/what-do-the-sms-statuses-mean)
So, my question is: does Plivo, Tropo or Nexmo (or any other service that I missed) do anything like that? I mean, knowing that an SMS was received either by client directly, or client's carrier would be really important.
PS. I'm not even sure if it is possible
Any help or suggestions would be appreciated.
It's certainly possible with Nexmo - as the other answer and comment state, it's not possible with Twilio & Tropo. Plivo's docs look like their delivery receipts are similar to Nexmo's.
Nexmo sends a delivery receipt if it's supported by the carrier. In the US it's not, but internationally it is supported often. In those cases Nexmo will give your app a callback with a delivery receipt. You can also use the message ID to query for the message status.
This screencast shows checking the DLR from the dashboard, which is really just a UI on top of the API.
Kevin makes the point that this could be difficult if the message is bounced through multiple providers - one of Nexmo's focuses is getting as direct a connection as possible.
[Disclaimer: I do occasional developer evangelism for Nexmo.]
I'm a Tropo customer, and I've asked the same question, and so far, the answer's similar to what Kevin Burke gave for Twilio. It's hard to do, so there's no confirmation at this time. They do give some debugging information in the logs which is helpful with that first-hop negotiation, at least, even if it's hard to retrieve/parse easily. They are working on it, and have been very active adding new features.