SMPPとHTTPによる接続
バインド、ウィンドウ、配信レポートを壊さずにテストルートを本番へ移行します。バインド、スループット、キープアライブ、エンコーディング、コールバック、障害対応を扱います。
本番のメッセージング接続は、単なるエンドポイントではなく運用上の約束事です。SMPPでは、セッション上にバインドの状態、スループットのウィンドウ、キープアライブの通信、配信レポートが加わります。HTTPでは、リクエストごとの認証とコールバックが加わります。本ガイドでは、その両方をテストから本番までの手順にまとめます。
このページの内容
まず管理すべきはバインドの状態
バインドは、方向が宣言されたセッションです。トランスミッターは送信を行い、レシーバーは着信メッセージと配信レポートを受け取り、トランシーバーはその両方を行います。プロバイダーは必要なバインド種別の認証情報を発行し、クライアントはバインドを状態として扱う必要があります。状態は、接続処理中、バインド済み、スロットリング中、再接続中、切断済みのいずれかです。バインドが常に確立していると想定するクライアントは、最初の切断でメッセージを失います。
バインドの状態を明示的に追跡します。すべてのバインド要求と応答について、インターフェースバージョン、システムID、エラーコードをログに記録します。切断時はバックオフをかけて再接続し、送信中だったsubmitは、メッセージセンターが受け付けたかどうかがわかるまで再送しません。それを確実に判別できるのは、submit_sm_respのメッセージIDだけです。
バインドと最初の送信
- アプリケーション（ESME）
- bind_transceiver セッションを開く
- SMSC
- submit_sm_resp 配信受付済み
- 配信確認
テキストによる説明
クライアントはバインド要求を送り、バインド応答を受け取ります。submit_smでメッセージを送信し、メッセージID付きのsubmit_sm_respを受け取ります。その後、メッセージセンターが配信レポートを含むdeliver_sm PDUを送り、クライアントはdeliver_sm_respで応答します。unbindでセッションを閉じます。
ウィンドウ、ハートビート、エンコーディング
ウィンドウとは、メッセージセンターが1つのバインドで受け付ける未応答リクエストの数です。送信中の件数をウィンドウ未満に保ち、バーストの前にウィンドウを空けておきます。スロットリングされたsubmitは、速度を落とすべきだという合図です。同じ速度で再試行するとキューが埋まり、1件の遅いメッセージが滞留に変わります。バインド数は、月間平均ではなくピーク時のレートから決めます。
キープアライブのやり取りにより、両端はセッションが生きていることを確認します。enquire_linkを定期的に送信し、応答しなくなったセッションは閉じます。エンコーディングは、内容が許す場合はGSM-7、それ以外はUCS-2で送信します。GSM-7の文字セットにない文字が1文字でもあると、メッセージ全体がUCS-2になり、セグメント数が変わることがあります。変数の値を含め、実際のテンプレートでテストしてください。
配信レポート
配信レポートは、deliver_sm PDUとして非同期に届きます。元のメッセージID、配信済み、期限切れ、未配信、不明などの状態、そして多くの場合ネットワークコードを含みます。メッセージIDで照合し、状態をメッセージのレコードに保存します。到着順で照合しないでください。また、配信レポートがないことを送信失敗と見なさないでください。
配信レポートの形式はさまざまです。新しいメッセージセンターはmessage_stateのTLV（tag-length-value）フィールドを使い、古いメッセージセンターはショートメッセージのフィールドにキーと値のテキストを入れます。両方を解析してください。アプリケーションに必要な状態を正規化し、元のコードも保持しておくと、サポート案件をネットワークが返した内容までさかのぼって追跡できます。
障害のパターンと最初の対応
| 症状 | 考えられる原因 | 最初の確認事項 |
|---|---|---|
| バインドが拒否される | 認証情報、バインド種別、またはインターフェースバージョンの誤り | バインド応答のコードとインターフェースバージョンを確認する |
| タイムアウトが増加 | ウィンドウ超過、または遅いルート | 再試行の前に、送信中の件数と応答コードを確認する |
| バインドは開いているが応答がない | セッションが切れているか、クライアントがキープアライブを停止した | enquire_linkを送信し、その後バックオフをかけて再接続する |
| 配信レポートが届かない | 配信レポートがハンドラーに届いていない | 再送の前に、セッションログとメッセージIDを確認する |
| 文字化け | GSM-7の内容をUCS-2として送信した、またはその逆 | データコーディングとセグメント数を確認する |
| コールバックのタイムアウト | エンドポイントが遅い、または到達できない | すぐに応答し、非同期で処理し、署名を検証する |
対応の順序が重要です。まず観察し、それから変数を1つだけ変更します。
テストルートから本番へ
-
テストルートにバインドする
テスト用の認証情報と、本番で使うバインド種別を使用します。バインド応答とインターフェースバージョンを確認します。
-
実際のテンプレートを送信する
リンク、変数、最長のメッセージを含め、公開する内容でテストします。エンコーディングとセグメント数を記録します。
-
配信レポートを確認する
すべての配信レポートをメッセージIDで照合します。アプリケーションが受け取る状態とエラーコードを確認します。
-
障害時の動作をテストする
無効な番号、容量がいっぱいの端末、利用制限されたサービスに送信します。配信レポートの状態とアプリケーションの処理を確認します。
-
ウィンドウのサイズを決める
ピークレートのテストを実行し、送信中の件数がウィンドウ未満に収まることを確認します。収まらない場合はバインドを追加します。
-
モニタリングを有効にする
バインドの状態、送信の遅延、配信レポートの遅延、配信レポートの状態の内訳についてアラートを設定します。各アラートに対応する担当者を決めます。
-
本番トラフィックを切り替える
まず一部のトラフィックを移し、配信レポートをテスト時と比較してから増やします。テストルートはフォールバックとして使える状態に保ちます。
HTTPの認証とコールバック
HTTP連携では、オンボーディング時に発行されたキーで各リクエストを認証します。キーは有効期限前にローテーションし、切り替え期間中は古いキーも有効にしておきます。送信するとメッセージID付きの受付応答が返り、配信レポートと着信メッセージはコールバックURLに届きます。
コールバックのエンドポイントは、署名を検証し、すばやく応答し、応答の後でイベントを処理する必要があります。エンドポイントが遅いと再試行が発生し、ハンドラーが冪等でなければ再試行が重複を生みます。証明書やDNSの変更時もエンドポイントに到達できる状態を保ち、コールバックの失敗率が上昇したらアラートを出します。セッションについてはSMPPの解説を、方式の選択については転送方式の比較をご覧ください。
よくある質問
どのSMPPバージョンを使うべきですか？
バインドはいくつ必要ですか？
コールバックは処理の前に応答すべきですか？
配信レポートが届かない場合は？
障害はどうテストしますか？
関連
- グローバルA2P送信者IDプレイブック
市場ごとの送信者IDの仕組み：英数字、番号、ショートコードの各経路、登録で求められる事項、国別の例。
- A2P SMS
A2P（Application-to-Person）SMSは、確認コードや取引通知など、アプリケーションが登録済みの送信者を通じて端末に送るトラフィックです。
- DLR
配信レシート（DLR）は、送信したSMSについて、配信済み、期限切れ、拒否、不明など、モバイルネットワークのステータスを報告します。
提供内容に近い領域
当社サービスのご利用方法に関わるため、ここで解説しています。