Since SMPP is used mainly by wireless operators, the answer to your question will depend a lot on what market/region/country you are dealing with.
I have experience with Latin American wireless companies, and can tell you that although more and more companies are hiding their SMPP servers behing HTTP webservices (that provide them more flexibility) the SMPP protocol is still a requirement to connect to a lot of Wireless companies, so it's definitely not dead.
And if you look inside those Wireless companies, the smpp protocol is very much alive in their internal networks and in the inter-connections with other carriers.
It's true that the SMPP spec hasn't changed in a long time, but that's not a bad thing actually. The protocol has matured, and there seems to be no interest from the carriers in expanding it to include new functionality, specially because they have found the flexibility they need in custom HTTP APIs
And regarding library implementations of SMPP, Kannel is in active development, although I wouldn't recommend it's use. Unfortunately most of the successful long-term implementations that I have seen of SMPP clients have been home grown implementations
SMPP 是一种用于简单消息发送的良好协议。 我希望它不会因为任何基于 HTTP 的协议而消亡。 我同意 HTTP 协议将提供灵活性，但是，这可能意味着基于 XML 或其他文本协议的某些变体的胖负载，这将极大地影响性能/功耗。
只要 SMPP 遵循规范，它就应该很好用。
SMPP is a good protocol for simple message sending. I hope it doesn't die in favour of any HTTP-based protocols. I agree that the HTTP protocols would provide flexibility, however, it would likely mean a fat payload based on some variant of XML or some other text protocol, which would affect greatly performance/power-usage.
As long as SMPP is guided by the specs, it should be great to use.
I work for a company that runs SMPP hub. We do handle business logic that handles binary SMS. The percentage is low, but they exist. Smartphones (iPhone, for example) can create binary SMS for long messages. We are seeing some use-cases.
Comment on SMPP spec
It is has been quite a few years that the SMPP spec has been updated. I have not seen any major carrier in the US to support SMPP 5.0 spec. Almost everywhere, it's SMPP v3.4. For me, the reasons are:
SMPP v3.4 meets most requirement. Companies have found their ways around the limitations.
The growth trend for SMS is flattening. It may not make sense to spend resources on this area. Even though SMPP v5.0 did not get much traction, no alternative is being developed.
Smart phone apps can use data plan to send SMS (not over SMPP) and bypass carriers' SMS communication channel. iPhone's iMessage is the biggest trend changer here.
Despite the declining growth trend, SMS over SMPP, being a core communication protocol, will probably continue live in the carrier space for few more decade. That's strictly my personal observation.
Comment on usages of SMPP
SMPP requires specific knowledge about the protocol, and it takes time and patience to acquire that knowledge. It probably influenced the rise of other alternatives.
I have seen that developers are leaning more and more towards HTTP based communication. The implementation is custom. I have seen:
HTTP communication using GET parameters. If synchronous acknowledgement is required, the call becomes a blocking, else a callback is used to report acknowledgement.
HTTP with using POST parameters. XML is being used to describe the SMS.
发布评论
评论（6）
由于 SMPP 主要由无线运营商使用，因此您问题的答案很大程度上取决于您所面对的市场/地区/国家。
我有拉丁美洲无线公司的经验，可以告诉您，尽管越来越多的公司将他们的 SMPP 服务器隐藏在 HTTP Web 服务后面（这为他们提供了更大的灵活性），但 SMPP 协议仍然是连接到许多无线公司的要求，所以它绝对没有死。
如果您仔细观察这些无线公司的内部，就会发现 smpp 协议在其内部网络以及与其他运营商的互连中非常活跃。
确实，SMPP 规范已经很长时间没有改变了，但这实际上并不是一件坏事。 该协议已经成熟，运营商似乎没有兴趣扩展它以包含新功能，特别是因为他们已经在自定义 HTTP API 中找到了所需的灵活性，
并且关于 SMPP 的库实现，Kannel 正在积极开发中，尽管我不建议使用它。 不幸的是，我所看到的 SMPP 客户端的大多数成功的长期实施都是本土实施
Since SMPP is used mainly by wireless operators, the answer to your question will depend a lot on what market/region/country you are dealing with.
I have experience with Latin American wireless companies, and can tell you that although more and more companies are hiding their SMPP servers behing HTTP webservices (that provide them more flexibility) the SMPP protocol is still a requirement to connect to a lot of Wireless companies, so it's definitely not dead.
And if you look inside those Wireless companies, the smpp protocol is very much alive in their internal networks and in the inter-connections with other carriers.
It's true that the SMPP spec hasn't changed in a long time, but that's not a bad thing actually. The protocol has matured, and there seems to be no interest from the carriers in expanding it to include new functionality, specially because they have found the flexibility they need in custom HTTP APIs
And regarding library implementations of SMPP, Kannel is in active development, although I wouldn't recommend it's use. Unfortunately most of the successful long-term implementations that I have seen of SMPP clients have been home grown implementations
SMPP 是一种用于简单消息发送的良好协议。 我希望它不会因为任何基于 HTTP 的协议而消亡。 我同意 HTTP 协议将提供灵活性，但是，这可能意味着基于 XML 或其他文本协议的某些变体的胖负载，这将极大地影响性能/功耗。
只要 SMPP 遵循规范，它就应该很好用。
SMPP is a good protocol for simple message sending. I hope it doesn't die in favour of any HTTP-based protocols. I agree that the HTTP protocols would provide flexibility, however, it would likely mean a fat payload based on some variant of XML or some other text protocol, which would affect greatly performance/power-usage.
As long as SMPP is guided by the specs, it should be great to use.
不幸的是，我们仍在使用它。
We are still using it, unfortunately.
我们仍然使用它，但我们正在为新项目使用 HTTP 协议替换它！
We also still use it but we are repacing it with HTTP protocol for new projects!
Ricardo Reyes的回答几乎完全涵盖了（https://stackoverflow.com/a/545651/467545）这个问题。 只是添加我自己在这件事上的经验。
对二进制消息发表评论
我在一家运行 SMPP 集线器的公司工作。 我们确实处理处理二进制短信的业务逻辑。 虽然比例很低，但它们确实存在。 智能手机（例如 iPhone）可以为长消息创建二进制 SMS。 我们看到了一些用例。
SMPP 规范评论
SMPP 规范已经更新很多年了。 我还没有看到美国有任何主要运营商支持 SMPP 5.0 规范。 几乎所有地方都是 SMPP v3.4。 对我来说，原因是：
限制。
尽管增长趋势有所下降，但 SMPP 上的 SMS 作为核心通信协议，可能仍将在运营商领域继续存在几十年。 这完全是我个人的观察。
对 SMPP 用法的评论
SMPP 需要有关协议的特定知识，并且需要时间和耐心来获取这些知识。 它可能影响了其他替代品的兴起。
我发现开发人员越来越倾向于基于 HTTP 的通信。 实施是定制的。 我见过：
一些很少使用的替代方案是：
Ricardo Reyes' answer covered (https://stackoverflow.com/a/545651/467545) this question almost completely. Just adding my own experience in this matter.
Comment on binary messages
I work for a company that runs SMPP hub. We do handle business logic that handles binary SMS. The percentage is low, but they exist. Smartphones (iPhone, for example) can create binary SMS for long messages. We are seeing some use-cases.
Comment on SMPP spec
It is has been quite a few years that the SMPP spec has been updated. I have not seen any major carrier in the US to support SMPP 5.0 spec. Almost everywhere, it's SMPP v3.4. For me, the reasons are:
limitations.
Despite the declining growth trend, SMS over SMPP, being a core communication protocol, will probably continue live in the carrier space for few more decade. That's strictly my personal observation.
Comment on usages of SMPP
SMPP requires specific knowledge about the protocol, and it takes time and patience to acquire that knowledge. It probably influenced the rise of other alternatives.
I have seen that developers are leaning more and more towards HTTP based communication. The implementation is custom. I have seen:
Some rarely used alternatives are:
尽管许多 SMS 聚合器都有 HTTP API。 我认为当你想要进行大量发送时，SMPP 非常有用，因为它是一个连接协议。
Although many SMS agregattors have HTTP APIs. I think SMPP is very useful when you want to do massive sendings, because it is a connected protocol.