Good question. However, I'm rooting for them "We founded MessageBird in 2011 after experiencing firsthand how poor the quality of service of most communication providers was at the time".
It's 2017 and the incumbent (Twilio) can't explain why I get delays in inbound SMSs.
They blame it all the time on carriers, but if they can work directly with carriers to improve QOS while having Twilio-like ease of use they might have a winner.
There are other providers that promise better QOS than Twilio, but they're very enterprisey (meaning long sales cycle, no ease of testing, etc).
The problem is that to get an SMSC that is respected by all of the operators requires a negotiation with an aggregator who has done contracts with all of the operators. The 2nd order problem is that you don't know the quality of the relationship an aggregator has with operators until you're a customer. All carriers have a prioritization in their SMSC's and, necessarily, no aggregator is in position 1 on all carriers.
The result is fairly untraceable failures.
Source: former telecom PM.
We have secured direct relationships with 220 carriers globally essentially skipping the aggregators. That way in terms of support in almost all cases we can at least explain what happened with the message end to end.
To be clear, you are operating a SMSC and have signed SMSC interop agreements as a CLEC operator with 220 carriers globally?
Yes, we run our own SMSC but in terms of functionality like routing and quality control we go way beyond what a normal carrier would be able to. CLEC is a US specific term and not needed to sign direct agreements with carriers. We operate our own SS7 stack, global titles and mobile network codes. This way we can interconnect with carriers as a carrier. Deploying an on-premise SMSC or E1's would be an old-school way of doing this. Most carriers use either Sigtran or connectivity through their SCCP provider.
I'd love clarity on this (specifically because it's hard for me to believe you've done smsc integration 220 times already).
See my comment above - on of their VCs has posted some stuff
Good question - but all these gateways have tendency to drop messages, report weird errors, messages are sometimes delayed by hours, their MMS support if quirky, etc.
I.e., if you ever worked with Twilio you will learn about "30008 Unknown error" - Twilio support tries but because "Carrier Network" problems these problems cannot be fixed.
In short, reliable delivery of SMS messages internationally is still not solved.
> In short, reliable delivery of SMS messages internationally is still not solved.
So how does MessageBird solve this...?
see my comment above.
So that error doesn't exist in MessageBird? I don't get it. Is it not dependent on carriers as well? I'm asking how they technically do things differently that would absolve them from encountering that issue.
When you connect directly to a carrier you get so called PTT codes back (industry standard). Not all carriers do this the same way but we standardize this and return them like shown at the link below. When your provider uses a lot of in-between providers its harder to return errors correctly. https://developers.messagebird.com/docs/smserrorcodes
Do they use any tools to monitor sms reception on real SIM cards?
That said, I've looked at MessageBird a bunch of times but I still don't get it. What makes them different from all the other SMS gateways out there? It's the same product everywhere: you invoke some REST API, an SMS is sent to a number and you get billed.