SMS コネクタのプロトコルと設定 sms-connector-protocol

概要 overview

SMS は、書式設定のない短いテキストメッセージの送信に限定されますが、そのシンプルさがこのコミュニケーションチャネルの利点でもあります。

SMS を送信する主な方法は 2 つあります。

このドキュメントでは、Adobe Campaignと SMPP プロバイダーの間の接続を設定する手順について説明します。

SMPP プロバイダーは公式仕様から外れる場合がありますが、Adobe Campaign の SMS コネクタは、ほとんどのプロバイダーと互換性を持つように動作を適応させるための多くのオプションを提供します。

SMS の種類 sms-types

SMS プロバイダー経由で大量の SMS を送信する場合、次の 3 種類の SMS が発生します。

確認応答（RESP PDU、SMPP プロトコルの一部）と SR を区別する必要があります。SR は、ネットワークのエンドツーエンドを通じて送信される SMS の一種で、確認応答は、1 回の転送が成功したことを確認するだけのものです。

確認応答と SR は両方ともトリガーエラーを起こす可能性があります。そのため、この 2 つを区別するとトラブルシューティングに役立ちます。

SMS で送信される情報 information-sms

SMS は、テキストよりも多くの情報を伝送します。SMS によって提供される情報のリストを以下に示します。

SMPP プロトコル smpp-protocol

Adobe Campaign Standardは、SMPP プロトコルバージョン 3.4 をサポートしています。これは、SMS をプロバイダー（SMSC）に送信し、SMS や受信を受信できる広範なプロトコルです。 詳しくは、SMPP ドキュメントを参照してください。

SMS サービスプロバイダー側のネットワーク機器は、SMSC と呼ばれることが多いです。

SMPP 接続 smpp-connections

Adobe Campaign は、TCP を介して SMS サービスプロバイダーのネットワーク機器に接続します。SMPP プロトコルは、Adobe Campaign からプロバイダーへの永続的な TCP 接続を設定します。TCP 接続は、常に Adobe Campaign が開始します。メッセージを受信する場合も同様です。SMPP は、モードに応じて 1 つまたは 2 つの TCP 接続を開きます。すべての接続は、常に Adobe Campaign によって開始されます。

SMPP プロトコルは次の 2 つのモードで動作します。

SMPP PDU smpp-pdu

SMPP 送信ユニット（「パケット」）は PDU と呼ばれます。PDU には、コマンド、ステータス、シーケンス番号、データが含まれます。

各 PDU は、SMPP RESP PDU（同期応答）によって確認される必要があります。リクエストはパイプラインで記述できます。送信者は、RESP を待たずに多数のコマンドを送信できます。いつでもパイプライン化できる要求の数はウィンドウと呼ばれます。RESP PDU は、対応するイニシエーター PDU の順序とは関係なく、どの順序でも到着する可能性があります。

分離された​ トランスミッター + レシーバー ​モードでは、使用する接続は、送信されるメッセージの種類に応じて異なります。トランスミッター接続は MT に、レシーバー接続は MO と SR に使用されます。各種のメッセージに対する要求と応答は、同じ TCP 接続を介して送信されます。

例えば、MT を送信する際には、トランスミッター接続が使用され、MT を確認する RESP もトランスミッターチャネルを介して送信されます。MO（または SR）を受け取ると、レシーバー接続は MO を受け取り、MO を確認する RESP を送信するために使用されます。

Adobe Campaign Standardでは、MT と SR の紐付けは MTA にネイティブなので、専用の SMS プロセスはありません。

成功した SUBMIT_SM_RESP PDU は「送信済み」メッセージのステータスを送信ログにトリガーし、成功した DELIVER_SM (SR) PDU は「受信済み」メッセージのステータスをトリガーします。

セキュリティ面 security-aspects

プロトコル自体は暗号化されません。ほとんどのプロバイダーは、許可リスト上に IP のバリアントを実装しているので、Adobe Campaign サーバーの IP アドレスをプロバイダーに宣言する必要があります。

Adobe Campaign は、バインド段階でのログインとパスワードの受け渡しをサポートしています。また、SMPP over TLS もサポートします。適切なセキュリティを確保するためには、証明書が必要であることに注意してください。SMPP コネクタは証明書チェックのバイパスを許可しますが、証明書を持たない TLS はセキュリティレベルの大幅な低下につながるので、テストにのみ使用する必要があります。

コネクタは、システム openssl ライブラリが提供するデフォルトの証明書を使用します。通常は Debian の /etc/ssl/certs ディレクトリで提供されます。このディレクトリは、デフォルトで「ca-certificates」パッケージによって提供されていますが、カスタマイズ可能です。

各種 PDU の情報 information-pdu

各種の PDU には、異なる情報を伝達する個別のフィールドがあります。これらの PDU の詳細は、SMPP 3.4 仕様に記載されています。

以下の各節では、PDU と同期応答（*_RESP PDU）の両方について説明します。すべての PDU は対応する RESP によって認識される必要があります。これは仕様の必須部分です。

PDU にはオプションのフィールドを指定できます。ここでは、最も一般的なフィールドについて説明します。詳しくは、SMPP 3.4 仕様を参照してください。

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER bind-transmitter

この PDU は、SMSC への接続を開始するために使用されます。トランスミッター、レシーバー、および​ トランシーバ ​モードは、この接続を介して転送できる SMS の種類のみを変更します。具体的には、次のようになります。

BIND_* PDU の主なフィールド：

BIND_*_RESP に特定のフィールドがない場合は、接続が成功したかどうかを確認します。

UNBIND unbind

この PDU は、切断前にシステムから送信する必要があります。接続を閉じる前に、一致する UNBIND_RESP PDU を待機する必要があります。

適合 SMSC は接続を閉じてはいけません。TCP 接続は Adobe Campaign コネクタによって制御されます。

SUBMIT_SM submit-sm

この PDU は、MT を SMSC に送信します。応答 PDU は、MT の ID を提供します。

SUBMIT_SM PDU の主なフィールド：

Adobe Campaign では、次のオプションフィールドがサポートされています。

SUBMIT_SM_RESP submit-sm-resp

この PDU には、MT の ID が含まれます。これは、着信 SR と一致させるのに役立ちます。

一部のプロバイダーは、SR を送信した後に SUBMIT_SM_RESP を送信します。この動作を考慮するには、Adobe Campaign は 30 秒待ってから、不明な ID を持つ SR に​ 無効なメッセージ ID を返します。

DELIVER_SM delivery-sm

この PDU は、SMSC から Adobe Campaign に送信されます。MO または SR が含まれます。

ほとんどのフィールドは、対応する SUBMIT_SM と同じ意味を持ちます。役立つフィールドのリストを次に示します。

Adobe Campaignは、設定を調整して、receipted_message_id のオプションフィールドのメッセージ ID を読み取ることができます。

DELIVER_SM_RESP deliver-sm-resp

この PDU は、SR と MO を確認するために Adobe Campaign から送信されます。

Adobe Campaign Standardは、すべての処理手順が正常に完了した場合にのみ DELIVER_SM_RESP ールを送信します。 これにより、処理エラーのリスクがある間は SR または MO が確認されなくなります。

ENQUIRE_LINK enquire-links

この PDU は、接続が有効であるかどうかを確認する目的でのみ使用します。頻度は、プロバイダーのニーズに応じて設定する必要があります。

デフォルトの 60 秒は、外部アカウントで設定されているほとんどの設定と一致する必要があります。

ENQUIRE_LINK_RESP enquire-links-resp

この PDU は、接続が動作していることを確認します。

マルチパート SMS（長文 SMS） multipart

マルチパート SMS（ロング SMS）は、複数のパーツで送信される SMS です。モバイルネットワークプロトコルの技術的な制限により、SMS は 140 バイト以下にする必要があり、超える場合は分割する必要があります。SMS に収まる文字数について詳しくは、SMS テキストエンコーディングの節を参照してください。

長いメッセージの各部分は、個々の SMS です。これらのパーツは、ネットワーク上を単独で移動し、受信側携帯電話によって組み立てられます。再試行と接続性の問題を処理するために、Adobe Campaign はこれらのパーツを逆順に送信し、メッセージの最初の部分（最後の送信）でのみ SR を要求します。携帯電話は最初の部分を受け取ったときにのみメッセージを表示するので、他の部分の再試行は携帯電話で重複を生成しません。

配信ごとの SMS の最大数は、配信テンプレート ​の​ メッセージごとの SMS の最大数 ​設定を使用して、メッセージごとに設定できます。この制限を超えると、メッセージが長すぎることが原因で SMS の送信に失敗します。

長い SMS を送信する方法は 2 つあります。

プロトコルとフォーマットについて詳しくは、SUBMIT_SM PDU の esm_class、short_message、message_payload の各フィールドの説明を参照してください。

スループットのキャッピングとウィンドウイング throughput-capping

ほとんどのプロバイダーでは、各 SMPP 接続にスループットの制限が必要です。これは、外部アカウント内に多数の SMS を設定することで達成できます。スループットのスロットルは接続ごとに発生します。有効なスループットの合計は、接続ごとの制限値に接続の合計数を乗じた値です。これについては、同時接続の節で詳しく説明します。

最大スループットに達するには、最大送信ウィンドウを微調整する必要があります。送信ウィンドウは、SUBMIT_SM_RESP を待たずに送信できる SUBMIT_SM PDU の数です。詳しくは、送信ウィンドウの設定の節を参照してください。

SR およびエラー管理（「付録 B」） sr-error-management

SMPP プロトコルは、RESP PDU に標準の同期エラーを定義しますが、SR のエラーコードは定義しません。各プロバイダーは、独自のエラーコードと意味を使用します。

SMPP プロトコル仕様の付録 B の節（167 ページ）で推奨されていますが、実際のエラーコードやその意味は記載されていません。

エラー管理に対応するために、Adobe Campaign の broadLog メッセージシステムを活用して、エラーとその重大度（ハード、ソフトなど）を適切にプロビジョニングできます。

上述したように、2 種類のエラーがあります。

SR を受け取ると、short_message フィールドにステータスとエラーが表示されます（付録 B 準拠の実装例）。PDU の short_message フィールドは、MT にテキストが含まれるので、テキストフィールド ​と呼ばれることがよくあります。SR の場合は、テクニカル情報に加えて​ テキスト ​という名前のサブフィールドが含まれます。これらの 2 つのフィールドは異なり、short_message には実際に​ テキスト ​フィールドと他の情報が含まれます。

SR テキストフィールドの形式 sr-text-field-format

この仕様では、SR テキストフィールドに対して次の形式を使用することをお勧めします。これはサブフィールドのリストで、フィールド名と値を区切るコロンで区切られます。フィールド名では、大文字と小文字が区別されません。

付録 B のレコメンデーションと一致する SR テキストフィールドの例：

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

id フィールドは、SUBMIT_SM_RESP PDU で受け取った ID で、MT の認識です。

sub および dlvrd は、配信されるパーツと配信されるメッセージの量を数えると考えられますが、broadLog システムはより的確で統合された情報を提供するので、Adobe Campaign はこの値を使用しません。

submit date および done date フィールドは、MT が送信されときと、SR が携帯電話から送信されたときのタイムスタンプを示します。タイムゾーンに関する問題や、日付が正しく設定されていない携帯電話のタイムスタンプは、正しくないことが予想されます。

stat フィールドは、メッセージの状態を示すので重要です。重要なステータスは DELIVRD、UNDELIV、REJECTD のみです。DELIVRD ステータスは成功を示し、残りの 2 つはエラーを示します。その他の値も可能ですが、通常は中間通知です（例えば、MT が携帯電話会社に到達したが、携帯電話に到達しなかった場合など）。これらの中間通知は、Adobe Campaign では無視されます。

err フィールドには、プロバイダー固有のエラーコードが含まれます。プロバイダーは、この値を解釈できるように、考えられるエラーコードの表とその意味を提供する必要があります。

最後に、テキストフィールドには通常、MT のテキストの先頭が含まれます。これは Adobe Campaign では無視され、一部のプロバイダーは PII の漏洩やネットワーク帯域幅の消費を防ぐために送信しません。このフィールドを読み込むと、テスト MT に一致する SR をより容易に見つけられるため、トラブルシューティングの際に使用できます。

Adobe Campaign Standardの拡張された汎用 SMPP における SR 処理の例 sr-processing

次の例では、付録 B のレコメンデーションに従った実装、外部アカウントのデフォルト値、成功した SMS MT を示します。

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

まず、id extraction 正規表現を適用して ID を抽出し、対応する MT に合わせて紐付けます。

次に、status extraction 正規表現と error code extraction 正規表現を適用してこれらのフィールドを抽出し、文字列に追加します。

broadLog メッセージは次の情報を使用して構築され、元の変更されていない文字列が参照用に追加されます。

SR ExampleProvider DELIVRD 000|MESSAGE=id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

次に、メッセージは正規化され、MESSAGE 部分を削除して同じ stat および err コードを持つ複数のメッセージが一致するようにします。

SR ExampleProvider DELIVRD 000|#MESSAGE#

メッセージが broadLog メッセージテーブルにまだプロビジョニングされていない場合は、メッセージ全体を firstText とし、正規化されたメッセージを使用して新しいエントリが作成されます。次に、コネクタは success と error 正規表現を使用して、成功か失敗かを判断します。

デフォルトでは、すべてのエラーはソフトエラーとしてプロビジョニングされます。つまり、ハードエラーは手動でプロビジョニングする必要があります。

SMS テキストエンコーディング sms-text-encoding

エンコードの問題が発生した場合は、必ず SMSC プロバイダーに連絡する ​必要があります。SMSC プロバイダーのみが、サポートするエンコーディングと、技術的なプラットフォームの制限によって適用される可能性のある特別なルールに関する正確な知識を持っています。

SMS メッセージは、特殊な 7 ビットエンコーディングを使用します。通常、GSM7 エンコーディングと呼ばれます。

SMPP プロトコルでは、トラブルシューティングを容易にするために、GSM7 のテキストが 1 文字あたり 8 ビットに拡張されます。SMSC は、携帯電話に送信される前に、1 文字あたり 7 ビットにパックします。つまり、SMS の short_message フィールドの長さは SMPP フレームで最大 160 バイトになりますが、モバイルネットワークで送信される場合は 140 バイトに制限されます。

エンコードの問題が発生した場合は、次の点を確認してください。

data_coding フィールドは、使用されるエンコーディングを示します。主な問題は、値 0 が仕様のデフォルトの SMSC エンコーディングを意味し、通常は GSM7 を参照する点です。エンコーディングが data_coding = 0（Adobe Campaign のみがサポート）に関連付けられている SMSC パートナーに問い合わせてください。他の data_coding 値は仕様に従う傾向にありますが、念のため SMSC プロバイダーに確認することをお勧めします。

メッセージの最大サイズは、エンコーディングによって異なります。次の表に、すべての関連情報をまとめます。

SMPP 外部アカウントパラメーター SMPP-parameters-external

SMPP プロトコルの実装は、それぞれ多くのバリエーションを持ちます。互換性と適応性を向上させるために、SMPP コネクタの動作を変更する多くの設定を使用できます。この節では、コネクタに対するすべてのパラメーターとその影響について説明します。

一般的なパラメーターとルーティング general-parameters-routing

このアカウントの MTA インスタンスの制限

SMPP プロバイダーへの接続を許可する MTA インスタンスの数に制限を設定できます。このオプションを有効にすると、最大で使用できる MTA の数を指定できます。

このオプションを使用すると、接続数をより細かく制御できます。同時接続を参照してください。

実行中の MTA の数より大きい値を設定すると、すべての MTA は通常どおりに実行されます。このオプションは制限にすぎず、追加の MTA を生成できません。

接続数（プロバイダー要件など）を正確に制御する必要がある場合は、現在のデプロイメントで適切な数の MTA が実行されていても、常にこのオプションを設定することをお勧めします。その後 MTA を追加した場合でも、接続制限は考慮されます。

接続設定 connection-settings

SMPP 接続モード smpp-connection-mode

接続を トランシーバ モードまたは分離 トランスミッター+レシーバー モードに設定します。 分離 送信者+受信者 モードに切り替えると、「SMPP 接続モード」セクションの設定が送信者に適用され、「受信者接続設定」セクションの設定が受信者接続に適用されます。これは、「受信者に異なるパラメーターを使用」チェックボックスをオンにした場合のみです。

SMSC 実装名 smsc-implementation-name

SMSC 実装の名前を設定します。プロバイダーの名前に設定する必要があります。このフィールドに追加する内容については、管理者または配信品質チームにお問い合わせください。このフィールドの役割は、SR エラー管理の節で説明しています。

サーバー server

接続先のサーバーの DNS 名または IP アドレス。

ポート port

接続先の TCP ポート。

アカウント account

接続のログイン。BIND PDU の system_id フィールドに渡されます。

パスワード password

SMPP 接続のパスワード。BIND PDU のパスワードフィールドに渡されます。

システムタイプ system-type

BIND PDU の system_id フィールドに渡された値。一部のプロバイダーは、ここで特定の値を必要とします。

同時接続 simultaneous-connections

Adobe Campaign Standardでは、SMS スレッドごとの接続数と MTA プロセスごとの接続数を定義します。
MTA プロセスの数はデプロイメントによって決まります。通常、2 つの MTA と 1 つのスレッドがあります。 スレッドの数は、smppConnectorThreads 設定を使用して config-instance.xml ファイルで変更できます。 通常、コンテナごとに 1 つの MTA プロセスと、MTA プロセスごとに 1 つのスレッドがあります。

Adobe Campaign Standardの合計接続数の数式：

同時接続は外部アカウントで設定し、スレッドの数は config-instance.xml ファイル（smppConnectorThreads）で設定し、MTA の数は外部アカウントで制限できます。

分離 送信者/受信者 モードでは、上記の接続数は 送信者/受信者 ペアの数を表し、接続数の合計が 2 倍になることを意味します。

TLS over SMPP を有効にする enable-TLS

TLS を使用してプロバイダーに接続します。接続が暗号化されます。TLS 接続は OpenSSL ライブラリによって管理され、この接続で OpenSSL に適用されるものはすべて実行されます。

ログファイルの詳細 SMPP トレースを有効にする enable-verbose-log-file

この設定は、すべての SMPP トラフィックをログファイルにダンプします。多くの場合、初期設定時にパラメーターを調整する必要があります。コネクタのトラブルシューティングをおこなう場合は、この機能を有効にし、プロバイダーが確認するトラフィックと比較する必要があります。

受信者接続設定 receiver-connection

このセクションは、分離された​ 送信者 + 受信者 ​モードでのみ表示されます。

受信者に別のパラメーターを使用 receiver-parameters

このチェックボックスをオフにすると、トランスミッターとレシーバーに同じ設定が適用されます。

このチェックボックスをオンにすると、接続設定 ​セクションの設定がトランスミッターに適用され、レシーバー接続 ​設定がレシーバーに適用されます。

レシーバーサーバー、ポート、アカウント、パスワード、システムタイプ

これらの設定は、トランスミッター+レシーバー モードの場合にレシーバーに適用されます。 トランスミッター部分と同様に機能します。詳しくは、上記を参照してください。

SMPP チャネル設定 smpp-channel-settings

文字の表記変換を許可 allow-character-transliteration

文字の置き換えとは、見つからない文字に相当する文字を探す処理です。例えば、フランス語の「ê」（曲折アクセント記号付きの e）文字は GSM エンコーディングでは見つかりませんが、可読性を損なうことなく「e」に置き換えることができます。

このチェックボックスをオフにすると、文字列をそのままエンコードできない場合、テキストエンコードは失敗します。

このチェックボックスをオンにすると、テキストエンコーディングは、失敗する代わりに、おおよそのバージョンに変換を試みます。ターゲットエンコーディングで相当する文字がない場合、テキストエンコーディングは失敗します。

エンコーディング処理の一般的な説明については、エンコーディングの具体的なマッピングの定義設定を参照してください。

受信 MO をデータベースに格納 incoming-mo-storing

このオプションを有効にすると、着信 MO はデータベースの inSMS テーブルに格納されます。このテーブルは、任意のワークフローのクエリアクティビティを使用して照会できます。

SR 処理中に KPI のリアルタイム更新を有効にする real-time-kpi

このオプションを有効にすると、KPI はエラー SR を受け取ったときに、メイン配信ページでリアルタイムに更新されます。

欠点として、生成されるデータベースの競合が原因で、パフォーマンスが低下する場合があります。このオプションを無効にすると、統計は syncfromexec ワークフローによって更新され、20 分ごとに実行されます。

ソース番号 source-number

メッセージの既定の送信元アドレスを定義します。この設定は、ソース番号が配信内で空のままの場合にのみ適用されます。

デフォルトでは、ソース番号フィールドは渡されないので、プロバイダーはショートコードの代わりにソース番号フィールドを使用します。

これにより、送信者アドレス／oADC 上書き機能が有効になります。

ショートコード short-code

アカウントのメインのショートコードを示します。このアカウントで複数のショートコードが使用されている場合、またはショートコードが不明な場合は、このフィールドを空欄にしてください。

ショートコードを指定すると、次の 2 つの機能において役立ちます。

Source TON/NPI、宛先 TON/NPI ton-npi

TON（数値のタイプ）と NPI（数値計画インジケータ）は、SMPP 3.4 仕様の 5.2.5 節（117 ページ）で説明されています。これらの値は、プロバイダーのニーズに合わせて設定する必要があります。

これらは、SUBMIT_SM PDU の source_addr_ton、source_addr_npi、dest_addr_ton、dest_addr_npi フィールドにそのまま送信されます。

サービスタイプ service-type

このフィールドは、SUBMIT_SM PDU の service_type フィールドにそのまま送信されます。プロバイダーのニーズに合わせて設定します。

スループットとタイムアウト throughput-timeouts

これらの設定は、SMPP チャネルのすべてのタイミングを制御します。一部のプロバイダーでは、メッセージレート、ウィンドウ、再試行タイミングを非常に正確に制御する必要があります。これらの設定は、プロバイダーの処理能力と契約で示される条件に一致する値に設定する必要があります。

送信ウィンドウ sending-window

送信ウィンドウは、SUBMIT_SM_RESP との一致を待たずに送信できる SUBMIT_SM PDU の数です。

最大ウィンドウ数が 4 の送信例：

このウィンドウは、ネットワークリンクの待ち時間が長い場合のスループットを向上させるのに役立ちます。ウィンドウの値は、少なくとも SMS の数にリンクの待ち時間（秒）を掛けた数である必要があります。これにより、コネクタは、次のメッセージを送信するまで SUBMIT_SM_RESP を待たなくなります。
ウィンドウが大きすぎる場合は、接続に問題が発生した場合に、より多くの重複メッセージを送信する可能性があります。また、ほとんどのプロバイダーは送信ウィンドウに対して非常に厳しい制限を適用しており、この制限を超えるメッセージを拒否します。

最適な送信ウィンドウ式の計算方法：

例：最大 MT スループットに 300 個の SMS が設定されていて、SUBMIT_SM と SUBMIT_SM_RESP の間の平均待ち時間が 100 ミリ秒の場合、最適な値は 300×0.1 = 30 となります。

MT の最大スループット max-mt-throughput

1 秒あたりの最大 MT 数および 1 回の接続あたりの最大数。この設定は厳密に適用されるので、MTA はこの制限を超える速さでメッセージをプッシュすることはありません。この機能は、プロバイダーが精密なスロットルを必要とする場合に役立ちます。

総スループット制限を知るには、この数値に上の式で説明した接続の総数を掛けます。

0 は制限なしを意味し、MTA はできるだけ早く MT を送信します。

最終的なアーキテクチャで適切にベンチマークされない限り、この数を超える正確なスループットを保証することはできないので、通常、この設定は 1000 未満に保つことをお勧めします。 スループットが 1000 を超える場合は、プロバイダーにお問い合わせください。 ただし、接続数を増やして 1000 MT を超える方が良い場合もあります。

再接続までの時間 time-reconnection

TCP 接続が失われた場合、コネクタは、この秒数の間待機してから接続を試みます。

MT の有効期間 expiration-period

SUBMIT_SM と SUBMIT_SM_RESP との間のタイムアウト。RESP を時間どおりに受信しない場合、メッセージは失敗と見なされ、MTA のグローバル再試行ポリシーが適用されます。

バインドのタイムアウト bind-timeout

TCP 接続試行と BIND_*_RESP 応答の間のタイムアウト。タイムアウトした場合、接続は Adobe Campaign コネクタによって閉じられ、再試行する前に、再接続までの時間待機します。

enquire_link 期間 enquire-link-period

enquire_link は、接続を有効に保つために送信される特別な種類の PDU です。この期間は秒単位です。キャンペーンコネクタは、帯域幅を節約するために接続がアイドル状態の場合にのみ enquire_link を送信します。この期間の 2 回後に RESP を受信しなかった場合、接続が切断されたと見なされ、再接続プロセスがトリガーされます。

SMSC 固有の設定 SMSC-specifics

これらの設定は、Adobe Campaign コネクタを SMPP 実装の特殊性のほとんどに適応させるための詳細設定です。

エンコーディングの特定のマッピングの定義 encoding-specific-mapping

テキストエンコーディングについて詳しくは、SMS テキストエンコーディングの節を参照してください。

この設定を使用すると、仕様とは異なるカスタムエンコーディングマッピングを定義できます。エンコーディングのリストと data_coding 値を宣言できます。

MTA は、リスト内の最初のエンコードを使用してエンコードを試みます。失敗した場合は、リスト上で次のエンコーディングを使用しようとします。メッセージのエンコードにエンコーディングを使用できない場合は、エラーが発生します。エンコーディングが見つかると、MTA はエンコードされたテキストと SUBMIT_SM PDU フィールドを作成し、テーブルで指定された値を使用して data_coding フィールドを設定します。

テーブル内の項目の順序は重要です。エンコーディングは上から下へ試行します。最も費用のかからないエンコーディング、または最も推奨されるエンコーディングをリストの上部に配置し、続けて高価なエンコーディングを配置する必要があります。

UCS-2 は、Adobe Campaign でサポートされるすべての文字をエンコードでき、UCS-2 SMS の最大長は非常に短い（70 文字のみ）ため、UCS-2 は失敗しません。

また、マッピングテーブルで 1 行だけ宣言することで、この設定を使用すると、特定のエンコーディングを常に使用するように強制できます。

チェックボックスがオフの場合に使用されるデフォルトのマッピングは、次の表と同じです。

つまり、MTA は GSM でメッセージのエンコードを試みます。成功した場合は、data_coding を 0 に設定して送信します。

メッセージを GSM でエンコードできない場合、UCS-2 でエンコードされ、data_coding が 8 に設定されます。

message_payload を有効にする enable-message-payload

このオプションをオフにすると、長い SMS は MTA によって分割され、UDH と共に複数の SUBMIT_SM PDU に送信されます。メッセージは、UDH データに従って携帯電話によって再構成されます。

このオプションをオンにすると、長い SMS が 1 つの SUBMIT_SM PDU に送信され、message_payload オプションフィールドにテキストが入力されます。詳しくは、SMPP 仕様を参照してください。

この機能が有効になっている場合、Adobe Campaign は SMS パーツを個別にカウントできません。すべてのメッセージは、1 つのパーツで送信済みとしてカウントされます。

完全な電話番号を送信 send-full-phone-number

このチェックボックスをオフにすると、電話番号の数字のみがプロバイダーに送信されます（SUBMIT_SM フィールドの destination_addr フィールド）。これは、国際番号インジケータ（通常は + プレフィックス）が SMPP の TON フィールドと NPI フィールドに置き換えられるので、デフォルトの動作です。

このチェックボックスをオンにすると、電話番号はそのまま送信され、前処理、潜在的なスペース、+ プレフィックスまたはシャープ／ハッシュ／スター記号は含まれません。

この機能は、自動返信ブロックリスト機能の動作にも影響します。チェックボックスがオフの場合、強制隔離テーブルに挿入される電話番号に + プレフィックスが追加され、SMPP プロトコル自体によって電話番号から + プレフィックスが削除されるのを補正します。

TLS 証明書チェックのスキップ skip-tls

TLS が有効な場合は、すべての証明書の確認をスキップします。

このオプションをオンにすると、接続はセキュリティで保護されなくなるため、実稼働環境では有効化しないでください。

このオプションは、デバッグやテストの際に役立ちます。

TON／NPI のバインド bind-ton-npi

SMPP 3.4 仕様の 5.2.5 節（117 ページ）で説明されている TON（番号のタイプ）と NPI（採番計画インジケータ）。これらの値は、プロバイダーのニーズに応じて設定する必要があります。

BIND PDU の addr_ton フィールドと addr_npi フィールドには、そのまま送信されます。

アドレス範囲 address-range

BIND PDU の address_range フィールドにそのまま送信されます。この値は、プロバイダーのニーズに応じて設定する必要があります。

無効な ID 確認数 invalid-id

1 つの SR に対して送信できる​ 無効なメッセージ ID DELIVER_SM_RESPの数を制限します。

これは、トラブルシューティングの目的で、ワークアラウンドとして使用し、通常の状態では 0 に設定する必要があります。

例えば、2 に設定する場合：

このフィールドを 0 に設定すると、「メッセージ ID が無効です」が常に返されるメカニズムが無効になります。これは通常の動作です。

このフィールドを 1 に設定すると、ID が無効であってもコネクタは常に「OK」を返します。これは、プロバイダー側の問題からの回復など、トラブルシューティングをおこなう場合に最小限の時間で、監視下でのみ 1 に設定する必要があります。

SR に含まれている ID の抽出用正規表現 regex-extraction

SR 形式は、SMPP プロトコル仕様に厳密には適用されません。これは、仕様書の付録 B（167 ページ）で説明されているレコメンデーションにすぎません。一部の SMPP 実装者は、このフィールドの形式を変更するので、Adobe Campaign は正しいフィールドを抽出する方法が必要です。

デフォルトでは、id: の後に最大 10 文字の英数字を取り込みます。

正規表現には、括弧内に一部を含むキャプチャグループが 1 つだけ必要です。ID 部分は括弧で囲む必要があります。正規表現の形式は PCRE です。

この設定を調整する場合は、誤ったトリガーを避けるために、できる限り多くのコンテキストを含めてください。標準に id: のような特定のプレフィックスがある場合は、正規表現に含めます。また、単語の途中でテキストが取り込まれないように、できる限り単語区切り文字（\b）を使用します。

正規表現に十分なコンテキストを含めないと、セキュリティ上の軽微な欠陥が生じる可能性があります。メッセージの実際の内容は、SR に含めることができます。UUID など、コンテキストのない特定の ID 形式のみが一致する場合、実際のテキストコンテンツ（ID の代わりにテキストフィールドに埋め込まれた UUID など）が解析される可能性があります。

成功／エラーステータスを判別するために適用された正規表現 regex-applied

不明な stat/err フィールドの組み合わせのメッセージが検出されると、これらの正規表現が stat フィールドに適用され、SR が成功したかエラーになったかが判別されます。これらのどの範囲とも一致しない stat 値を持つ SR は無視されます。

デフォルトでは、DELIV で始まる stat 値（例：付録 B 内の DELIVRD）は、正常に配信されたと見なされ、エラーに一致するすべての stat 値（例：REJECTED、UNDELIV）はエラーと見なされます。

MT 受信確認の ID 形式 id-format-mt

これは、SUBMIT_SM_RESP PDU の message_id フィールドに返される ID の形式を示します。

SR の ID 形式 id-format-sr

これは、SR 内の ID の Extraction 正規表現によって取り込まれる ID の形式を示します。値は同じ意味を持ち、上記の MT の形式と同じ動作をします。

オプションフィールドの SR ID またはエラーコード

このオプションを選択すると、上記の正規表現で処理されるテキストにオプションフィールドのコンテンツが追加されます。テキストは 0xTAG:VALUE の形式です。0xTAG は大文字のタグの 4 桁の 16 進値です（0x002E など）。

例えば、receipted_message_id フィールドに ID を取り込むとします。この場合、このチェックボックスを有効にすると、次のテキストがステータスに追加されます。

0x001E:05e3299e-8d37-49d0-97c6-8e4fe60c7739

この例では、0x001E がオプションのフィールドのタグで、UUID がフィールドの値です。

この値を取り込むために、SR フィールドの ID の抽出正規表現に次の正規表現を設定できます。

\b0x001E:([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\b

テキストフィールドの SR ID またはエラーコード

このオプションを選択すると、テキスト ​フィールドは、SR のステータステキストの処理中に保持されます。

これは、プロバイダーが ID やステータスなど、重要なデータをこのフィールドに配置する場合に役立ちます。通常、このフィールドは ASCII 以外のエンコードのテキストが含まれて正規表現の処理に支障が生じる場合があるので、安全に破棄できます。

SR フィールド内の ID の Extraction 正規表現が十分に具体的でない場合、このオプションを有効にすると、セキュリティ上の軽微な欠陥が生じる可能性があります。テキスト ​フィールドの内容は ID として解析され、攻撃者が偽造 ID の挿入に使用する場合があります。これにより、部分的なサービス拒否状況が発生する可能性があります。

サービス ID タグ

カスタム TLV を追加できます。このフィールドは、タグの部分を設定します。この値は、配信の詳細パラメーターにある​ サービスまたはプログラム ID の値の配信ごとにカスタマイズできます。

この設定では、メッセージごとに 1 つの TLV オプションのみを追加できます。

MO に送信された自動返信 automatic-reply

この機能を使用すると、MO にすばやくテキストを返信し、ショートコードごとのブロックリスト送信処理を実行できます。

キーワード ​列と​ ショートコード ​列は、自動応答をトリガーする条件を定義します。両方のフィールドが一致する場合、MO が送信され、追加のアクションがトリガーされます。ワイルドカードを指定するには、フィールドを空のままにする必要があります。キーワードは、MO テキストの最初の英数字の単語に対して一致します。句読点や先頭のスペースは無視します。つまり、キーワード ​フィールドにスペースを含めることはできません。また、1 つの単語である必要があります。

キーワード ​設定はプレフィックスです。例えば、「AD」を指定した場合、「AD」、「ADAPT」および「ADOBE」と一致します。共通のプレフィックスを持つ複数のキーワードがある場合は、キーワードは上から下に順に処理されるので、順序に注意する必要があります。

返信 ​列は返信するテキストです。このフィールドでは個人設定を使用できません。このフィールドを空のままにすると、メッセージは返信されませんが、追加のアクションはトリガーされます。

追加のアクション ​列は、キーワード ​と​ ショートコード ​の両方が一致した場合に、追加のアクションを提供します。空のショートコードはすべてのショートコードと一致します。強制隔離に送信したり、強制隔離から削除できます。値なしはテキストに返信します。追加のアクション ​を指定し、返信 ​フィールドを空のままにした場合、アクションは実行されますが、返信は送信されません。強制隔離は、指定したショートコードに対してのみ適用されます。フィールドが空の場合は、すべてのショートコードに適用されます。

テーブル内のすべてのエントリは、1 つのルールが一致するまで、指定された順序で処理されます。複数のルールが 1 つの MO に一致する場合、最上位のルールのみが適用されます。

自動応答オプションパラメーター（TLV） automatic-reply-tlv

21.1 リリースの時点では、自動応答 MT にオプションのパラメーターを追加できます。 これらは、SMPP の仕様の 5.3 節（131 ページ）で説明されているように、応答の SUBMIT_SM PDU にオプションの TLV パラメーターとして追加されます。

オプションパラメーターについて詳しくは、この 節を参照してください。

SMS 配信テンプレートパラメーター sms-delivery-template-parameters

一部のパラメーターは、配信テンプレートごとに設定できます。

送信者フィールド from-field

このフィールドはオプションです。送信者アドレス（oADC）を上書きできます。このフィールドの内容は、SUBMIT_SM PDU の source_addr フィールドに配置されます。

SMPP 仕様では、このフィールドの文字数が 21 文字に制限されていますが、プロバイダーによっては、これより長い値を使用できる場合があります。また、長さ、コンテンツ、許容文字など、一部の国では非常に厳密な制限が適用される場合があります。

配信パラメーター delivery-parameters

メッセージあたりの SMS の最大数 maximum-sms

この設定は、メッセージペイロード ​設定が無効な場合にのみ機能します。詳しくは、この ページを参照してください。 メッセージにこの値より多くの SMS が必要な場合は、エラーがトリガーされます。

SMS プロトコルでは SMS は 255 のパーツに制限されていますが、携帯電話では 10 のパーツを超える長いメッセージを組み合わせるのに問題が生じる場合があります。この制限はモデルによって異なります。1 通のメッセージにつきパーツは 5 を超えないことをお勧めします。

Adobe Campaign でのパーソナライズされたメッセージの動作によって、メッセージのサイズが異なる場合があります。長いメッセージが大量に存在すると、送信コストが増加する可能性があります。

送信モード transmission-mode

このフィールドは、送信する SMS の種類を次のように示します。通常または Flash メッセージ、携帯電話または SIM カードに保存。

この設定は、SUBMIT_SM PDU の dest_addr_subunit オプションフィールドに送信されます。

有効期間 validity-period

有効期間は、SUBMIT_SM PDU の validity_period フィールドに送信されます。日付は、常に UTC 絶対時刻形式で書式設定されます（日付フィールドは「00+」で終わります）。

SMPP オプションパラメーター（TLV） smpp-optional-parameters

21.1 リリースの時点では、この配信で送信されるすべての MT に対して、複数のオプションパラメーターを追加できます。 これらのオプションパラメーターは、SMPP の仕様の 5.3 節（131 ページ）で説明されているように、返信の SUBMIT_SM PDU に追加されます。

テーブルの各行は、オプションのパラメーターを表しています。

任意のオプションパラメーターの タグ ID が、外部アカウントで定義された サービスタグ ID と同じ場合、この表で定義されている値が優先されます。

SMPP コネクタ ACS-SMPP-connector

矢印はデータフローを表します。

ここで最も重要な注意点は、複数の SMPP コネクタスレッドがあることです。 これらのスレッドはすべて同一で、同じ設定を共有します。 そのため、接続数は常にスレッド数で乗算されます。

設定ファイルの変更が必要なため、スレッドの数を顧客が変更することはできません。

SMPP コネクタの動作の説明 behavior-smpp-connector

MT、SR、broadLog エントリの照合 matching-mt-sr

Adobe Campaignでは、メッセージは broadlog エントリです。 Adobe Campaign Standardでは、外部コネクタは、動作中の broadlog テーブル nmsBroadLogExec について知っておくだけで済みます。 ワークフローは、broadlog エントリを特定のターゲティングディメンション（nmsBroadLogXXX）にコピーし直す役割を担います。

残念ながら、SMPP では、メッセージと共に ID を送信することはできません。プロバイダーは各 MT に MT ID を付与した後、同じ ID を持つ 1 つ以上の SR を提供します。

プロバイダーから提供された ID は、テーブルの sProviderId 列に格納 nmsBroadLogExec れます。 SR は、MT が正常に送信され、確認された後に必ず到着しますが、Adobe Campaignでは未処理の SR と呼ばれる順不同で到着する場合もあります。 処理スレッドは、完全な情報が到達するまで、これらの SR を一時的に RAM に保存します。

MT が確認されると（SUBMIT_SM_RESP）、sProviderId はデータベースで直ちに更新されます。

各 SR は、SMPP 処理スレッドによって個別に処理されます。 このプロセスは擬似同期です。外部から同期していると見なされますが、イベント駆動型の実装を使用して内部で実装されます。 SR は、broadLog が正常に更新された場合、エラーが発生した場合にのみ確認され、SR は拒否されます。

各 SR に適用されるプロセスは次のとおりです。

上記の手順を確認するには、すべての手順が正しく適用されていることを手動で確認する 詳細 SMPP トレースを有効にする 必要があります。 これは、Adobe Campaignが新しい SMPP プロバイダーに接続されるたびに必要になります。

本番運用開始前 checklist

このチェックリストは、公開前に確認する必要がある事項をリストアップしています。設定が不完全な場合、多くの問題が発生する可能性があります。

外部アカウントの競合の確認 external-account-conflict

古い SMS 外部アカウントがないことを確認します。テストアカウントを無効のままにしておくと、実稼働システムで再有効化し、競合が発生する可能性があります。

このアカウントに接続しているインスタンスが他にないことを確認してください。 特に、ステージング環境がアカウントに接続していないことを確認してください。 一部のプロバイダーはこれをサポートしていますが、Adobe Campaign側とプロバイダーのプラットフォームの両方で非常に具体的な設定が必要です。

同じAdobe Campaign インスタンス上に、同じプロバイダーに接続する複数のアカウントが必要な場合は、プロバイダーに問い合わせて、これらのアカウント間の接続が実際に区別されていることを確認してください。 複数のアカウントに同じログインを割り当てる場合は、追加の設定が必要です。

チェック時の詳細 SMPP トレースの有効化 enable-verbose

チェック中は必ず詳細 SMPP トレースを有効にしてください。
ログを自分で確認できない場合は、サポートを依頼してください。

SMS のテスト test

PDU の確認 check-pdus

メッセージが正常に表示された場合でも、PDU が正しくフォーマットされているかどうかを確認することが重要です。

この手順は、以前に Adobe Campaign に接続されていないプロバイダーに接続する場合に必要です。

BIND bind

BIND_* PDUs が正しく送信されていることを確認します。最も重要な点は、プロバイダーが常に成功した BIND_*_RESP PDUs を返すことです（command_status = 0）。

BIND_* PDU の数が多すぎないか確認します。数が多すぎる場合は、接続が不安定であることを示している可能性があります。詳しくは、不安定な接続の問題の節を参照してください。

ENQUIRE_LINK enquire-link-pdus

接続がアイドル状態のときに ENQUIRE_LINK PDU が定期的に交換されていることを確認します。

SUBMIT_SM / DELIVER_SM submit-sm-deliver-sm

メッセージを送信し、ログで対応する SUBMIT_SM、SUBMIT_SM_RESP、DELIVER_SM、DELIVER_SM_RESP PDU を検索します。

SUBMIT_SM PDU を使用：

SUBMIT_SM_RESP PDU を使用：

DELIVER_SM PDU を使用：

DELIVER_SM_RESP PDU を使用：

すべて問題ないかどうかをプロバイダーに問い合わせます provider

SMS が正常に終了した場合でも、プロバイダーに問い合わせて、すべて問題ないかどうかを確認してください。

詳細 SMPP トレースの無効化 disable-verbose

すべてのチェックが完了したら、最後に​ 詳細な SMPP トレースを無効 ​にして、多くのログを生成しないようにします。実稼働システムでも、トラブルシューティング用にこれらを再度有効化できます。