必要な情報はすべて、不要な情報は一切なし
なぜ3.4がインストールベースを獲得したのか
SMPP 3.4が普及したタイミングは、まさにSMS A2Pが台頭した時期と重なりました。主要なすべてのSMSCベンダーが、深く安定した3.4の実装を行いました。このプロトコルは軽量（送信するコマンドはわずか8種類、約30のPDUタイプ）で、十分に理解されており、経路上のあらゆるNATやファイアウォールを通過できます。27年が経過した今でも、SMPP 3.4仕様は、あらゆるA2P相互接続契約において最優先されるプロトコルであり続けています。
5.0の追加機能
SMPP 5.0では、いくつかの課題が改善されました。ネイティブUTF-8 message_payload、適切なservice_typeレジストリ、セルブロードキャスト用のbroadcast_sm / query_broadcast_sm / cancel_broadcast_sm、オプションの課金用TLV、そしてcongestion_stateによるより厳格な混雑制御が導入されています。また、ESMEに代わってSMSCが操作できるmessage_stateマシンの概念も導入されました。
5.0がほとんど普及していない理由
理由は3つあります。第一に、SMSCベンダーはアップグレードのための費用を受け取っていません。通信事業者はすでに動作する3.4スタックを保有していたからです。第二に、5.0が対象としたセルブロードキャストの活用事例は、SMSCではなく専用のセルブロードキャストセンター（CBC）に送られました。第三に、5.0が解決した事項（Unicode処理、課金用TLV）は、通常、3.4上のTLVを用いたアプリケーションレイヤーで解決されます。その結果、BroadNetにおいて、5.0のバインドは本番環境で1件のみです。一方、3.4の有効なバインドは1,000件以上存在します。
実用的なアドバイス
SMPP 3.4をトランシーバーとしてバインドし、アカウントに提供されるポートでTLSを使用します。受信側のSMSCが対応している場合は、（UDH連結の代わりに）長文メッセージ用にmessage_payload TLVを用いたsubmit_smを使用してください。enquire_linkは30秒ごとにネゴシエーションを行い、クリーンにアンバインドしてください。アグリゲーターが5.0を強制する場合は、その理由を確認してください。商用のA2Pルートにおいて、到達率のメリットはありません。
SMPP 3.4とSMPP 5.0の比較
| SMPP 3.4 | SMPP 5.0 | |
|---|---|---|
| リリース済み | 1999 | 2003 |
| 本番導入実績 | ほぼすべてのA2Pバインド | 稀 — 導入されることは少ない |
| ネイティブUnicodeヘッダー | — | |
| セル / ブロードキャスト対応 | — | |
| 輻輳制御 | Basic | congestion_stateシグナリング |
| 到達率の向上 | ベースライン | 商用A2Pルートではなし |
| 現在の推奨事項 | はい — TLS経由のトランシーバー | 取引先から要求された場合のみ |