3 ms·

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

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).

josh2600 9y ago
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.
- techlad84 9y ago
  See my comment above - on of their VCs has posted some stuff
- robertvis 9y ago
  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.
  - josh2600 9y ago
    To be clear, you are operating a SMSC and have signed SMSC interop agreements as a CLEC operator with 220 carriers globally?
    - josh2600 9y ago
      I'd love clarity on this (specifically because it's hard for me to believe you've done smsc integration 220 times already).
    - robertvis 9y ago
      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.

josh2600 9y ago

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.

techlad84 9y ago
See my comment above - on of their VCs has posted some stuff
robertvis 9y ago
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.
- josh2600 9y ago
  To be clear, you are operating a SMSC and have signed SMSC interop agreements as a CLEC operator with 220 carriers globally?
  - josh2600 9y ago
    I'd love clarity on this (specifically because it's hard for me to believe you've done smsc integration 220 times already).
  - robertvis 9y ago
    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.