必要な情報はすべて、不要な情報は一切なし
SMPPの仕組み（ステップ・バイ・ステップ）
ESMEはTCP（理想的にはTLS）接続を確立し、system_idとパスワードを使用してbind_transceiverを送信します。バインド後は、各メッセージをsubmit_sm PDUとして送信します。SMSCはmessage_idを含むsubmit_sm_respで応答します。配信レポートは、同じソケット上のdeliver_sm PDUとして非同期に届き、message_idによって照合されます。30秒ごとのenquire_linkハートビートによりセッションが維持され、アンバインドによってクリーンに終了します。詳細は/answers/what-is-smppおよび/answers/what-is-esmeを参照してください。
バインドの種類とバージョン
ESMEは、送信専用（Transmitter）、受信専用（Receiver）、または単一の接続で両方を行う（Transceiver）としてバインドします。SMPP 3.4におけるTransceiverが現在の標準です。SMPP 5.0ではUnicode対応のヘッダーとセルブロードキャストのサポートが追加されましたが、導入している企業はほとんどありません。インストールベースの大部分は3.4です。BroadNetはSMPP 3.4のバインドを受け入れます。ホスト、ポート、および認証情報は、テストアクセスとともに提供されます。詳細は/answers/smpp-3-4-vs-5-0を参照してください。
REST APIと比較したメリット
一度確立された持続的なバインド（紐付け）は、メッセージあたりのコストが発生しません。そのため、継続的なボリュームにおいては、リクエストごとのHTTPSと比較して、SMPPはCPUの約10分の1、帯域幅の4分の1の負荷で済みます。これは、SMSCに対してp99で100ms未満のレイテンシを実現する唯一の方法です。クリティカルパス上にHTTPのハンドシェイクが存在せず、DLRをリアルタイムでストリーミングします。詳細は/compare/sms-api-vs-smppをご覧ください。
制限事項と注意点
SMPPは、お客様自身で運用する必要があるバイナリプロトコルです。バインド管理、指数バックオフによる再接続、シーケンス番号の追跡、およびmessage_idによるDLRの照合（一部のSMSCでは16進数、その他では10進数で返されます）はすべてお客様の責任となります。エラーハンドリングは簡潔です。送信に失敗すると、デコードが必要な数値のcommand_statusが返されます。これらのコードをアクションに変換するには、/tools/smpp-error-codesルックアップを使用してください。プロダクショングレードのSMPPクライアントは数千行に及ぶコードベースとなります。自社開発するよりも、既存のものを購入することをお勧めします。
RESTではなくSMPPを選択すべきなのはどのような場合ですか？
毎秒数百メッセージを維持する必要がある場合、または持続的なバインド（1バインドあたりの容量はアカウントチームと合意の上、ノードあたり30,000 SMS/秒まで対応可能）が必要な場合、あるいは1ミリ秒を争うレイテンシが重要なOTPを実行する場合、または既にどこでもSMPPに対応している通信事業者やアグリゲーターのエコシステムに統合する場合は、SMPPを選択してください。それ以外の場合は、REST SMS API（BroadNetにアカウントごとの固定レート制限なし）の方が運用がシンプルであり、同一のルートで配信されます。詳細は /developers/smpp と /products/sms-api を参照してください。
SMPPが使用するポートは何ですか？また、2026年でもまだ使用されていますか？
SMPPには単一の予約済みポートはありません。2775は歴史的なプレーンテキストのデフォルトであり、通信事業者は一般的に専用ポートでTLSを公開しています（BroadNetは、お客様のアカウントにTLSポートを提供します）。そして、はい、SMPPは完全に最新です。これは事実上すべてのA2P相互接続契約の最上位に固定されているプロトコルであり、BroadNetは1,000以上の通信事業者接続の背後で1,000以上のアクティブなバインドを実行し、2003年以来、稼働率99.99%で1日3億件以上のメッセージを配信しています。