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

NOTE
The SMS コネクタのプロトコルと設定 Adobe Campaign Classicは、 ページ.
このドキュメントでは、プロトコル、フィールド名とフィールド値の詳細については、すべて SMPP 3.4 仕様を参照しています。

概要 overview

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

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

  • 電話から手動で送信する:人と人との間で直接通信する通常の方法。

  • インターネットから送信する:Adobe Campaign がメッセージを送信する方法。インターネットをモバイルネットワークに接続する SMS サービスプロバイダーが必要です。Adobe Campaign は、SMPP プロトコルを使用して SMS をサービスプロバイダーに送信します。

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

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

IMPORTANT
新しいプロバイダーへの接続の設定には、技術的なスキル、TCP に関する知識、バイナリ、16 進表現、およびテキストエンコーディングが必要になる場合があります。プロバイダーとの積極的な協力も求められます。

SMS の種類 sms-types

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

  • SMS MT(モバイル終了):Adobe Campaign が SMPP プロバイダーを通じて携帯電話に向けて発信する SMS。

  • SMS MO(モバイル発信):携帯電話から SMPP プロバイダー経由で Adobe Campaign に送信される SMS。

  • SMS SR(ステータスレポート)、DR または DLR(配信受信):SMS が正常に受信されたことを示す、SMPP プロバイダーを通じて Adobe Campaign に携帯電話から送信される返信確認メッセージ。Adobe Campaign は、メッセージが配信できなかったことを示す SR を受け取る場合もあります。多くの場合、エラーの説明が記載されています。

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

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

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

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

  • テキスト。140 バイトに制限されます。つまり、エンコーディングに応じて 70~160 文字の範囲です。詳細と制限については、SMS テキストエンコーディングを参照してください。

  • 受信者アドレス。ADC または MSISDN とも呼ばれます。SMS を受信する携帯電話の番号です。

  • 送信者のアドレス。oADC または sender id とも呼ばれます。日々の使用で使用される電話番号、プロバイダーや名前を通じて送信されるショートコードを指定できます。名前はオプションの機能です。この場合、SMS に返信できません。

  • メッセージが Flash メッセージであるかどうかを示すフラグ。Flash メッセージは、メモリに保存されないポップアップです。

  • SR が予想されるかどうかを示すフラグ。

  • 有効日。この日を過ぎると、ネットワーク機器は再試行できません。

  • data_coding フィールド。テキストのエンコーディングを示します。

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 つのモードで動作します。

  • トランスミッター + レシーバー(または TX+RX):メッセージの送受信には、2 つの異なる TCP 接続が使用されます。
  • トランシーバ (TRX):メッセージの送受信には、単一の TCP 接続が使用されます。
NOTE
TRX は、接続数を減らし、障害が発生した場合の接続回復を簡素化するので、Adobe Campaign Standardにとって推奨されます。

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 の種類のみを変更します。具体的には、次のようになります。

モード
許可されている SMS の種類
トランスミッター
MT
レシーバー
MO + SR
トランシーバ
MT + MO + SR

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

  • system_id:認証に使用するログイン。外部アカウントに設定されます。

  • パスワード:認証に使用するパスワード。外部アカウントに設定されます。

  • system_type:一部のプロバイダーでは、特定の値に設定する必要があります。外部アカウントで設定され、すべてのバージョンで利用可能です。多くの場合、様々な種類の契約、チャネル、国などを区別します。

  • addr_ton および addr_npi:一部のプロバイダーで必須です。外部アカウントの Bind TON 設定と Bind NPI 設定で指定します。

  • address_range:一部のプロバイダーで必須です。これはほとんどの場合、この接続で使用できるショートコードのリストです。外部アカウントに設定されます。

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 の主なフィールド:

  • service_type:一部のプロバイダーで必要です。配信のプロパティで設定します。

  • source_addr_ton および source_addr_npi:伝送される送信元アドレスの種類を示します。これらのフィールドの意味は標準化されていますが、一部のプロバイダーでは使い方が異なるので、プロバイダーに正しい値を確認する必要があります。外部アカウントに設定されます。

  • source_addr:MT のソースアドレス/oADC。携帯電話に表示されます。外部アカウントと配信で設定すると、配信内の値が外部アカウントの値よりも優先されます。

  • dest_addr_ton および dest_addr_npi:送信される宛先アドレスの種類(ローカルや国際形式など)を示します。これらのフィールドの意味は標準化されていますが、一部のプロバイダーでは使い方が異なるので、プロバイダーに正しい値を確認する必要があります。外部アカウントに設定されます。

  • destination_addr:受信者アドレス、電話番号、または MSISDN。

  • esm_class:UDH がテキストフィールドで使用されているかどうかを示すために使用します。message_payload モードが使用されない場合、分割 SMS のコネクタによって自動的に有効になります。

  • priority_flag:他のメッセージと比較した場合のこのメッセージの優先順位。これは、配信自体の優先度に結び付けられます。

  • validity_period:タイムスタンプ。このタイムスタンプを超えると、再試行はおこなわれません。配信自体に設定されます。

  • registered_delivery:SR が要求されているかどうかを示します。Adobe Campaign は、自動返信を除き、常にこのフラグを設定します。マルチパートメッセージの場合、フラグは最初のパーツに対してのみ設定されます。すべてのバージョンで同じ動作がおこなわれます。

  • data_coding:テキストフィールドで使用されるエンコーディングを示します。詳しくは、SMS テキストエンコーディングの節を参照してください。

  • short_message:メッセージのテキスト。UDH を使用する場合は、UHD ヘッダーも含まれます。

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

  • dest_addr_subunit:Flash、携帯電話、または SIM カードといった SMS のターゲットを指定するために使用します。配信のプロパティで設定します。

  • message_payload:外部アカウントで有効にすると、長いメッセージは 1 つの PDU で送信され、テキストは short_message フィールドではなくこのフィールドで送信されます。

SUBMIT_SM_RESP submit-sm-resp

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

IMPORTANT
多くのプロバイダーは、MT ID を 16 進数で送信します。外部アカウントで、MT 確認応答の ID 形式 ​設定で正しく設定されていることを確認してください。

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

DELIVER_SM delivery-sm

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

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

  • source_addr:MO/SR のソースアドレス。通常は電話番号です。

  • destination_addr:MO または SR を受け取ったショートコード。

  • esm_class:PDU が MO か SR かを識別するために使用します。

  • short_message:メッセージのテキスト。SR の場合、SMPP プロトコル仕様の付録 B に記載されているデータが含まれます。詳しくは、SR エラー管理を参照してください。

Adobe Campaignは、 receipted_message_id オプションフィールド(設定の調整を含む)。

DELIVER_SM_RESP deliver-sm-resp

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

Adobe Campaign Standardのみが DELIVER_SM_RESP すべての処理手順が正常に完了したら、次の手順を実行します。 これにより、処理エラーのリスクがまだある間は、SR や MO が認識されなくなります。

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

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

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

マルチパート SMS(長文 SMS) multipart

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

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

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

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

  • UDH:長いメッセージを送信するデフォルトおよび推奨される方法です。このモードでは、コネクタは UDH 情報を含む複数の SUBMIT_SM PDU にメッセージを分割します。このプロトコルは、携帯電話が使用するプロトコルです。Adobe Campaign はメッセージの生成を最大限制御でき、送信されたパーツの数と分割方法を正確に計算できます。

  • message_payload:長いメッセージを単一の SUBMIT_SM PDU で送る方法です。プロバイダーはこれを分割する必要があります。つまり、Adobe Campaign が送信されたパーツの数を正確に把握することは不可能です。一部のプロバイダーはこのモードを必要としますが、UDH をサポートしていない場合にのみ使用することをお勧めします。

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

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

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

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

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

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

レコメンデーションは、 SMPP プロトコルの仕様 (167 ページ)ですが、実際のエラーコードとその意味は一覧に表示されません。

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

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

  • メッセージが SMSC に送信された直後に発生する SUBMIT_SM_RESP 内の同期応答。
  • 携帯電話がメッセージを受信したとき、またはメッセージがタイムアウトしたときに、受信メッセージがずっと後に発生する場合。この場合、SR にエラーが見つかります。

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

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

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

Adobe Campaign Standard Extended generic 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 正規表現を使用して、成功か失敗かを判断します。

  • success 正規表現と一致する場合は、成功と見なされます。

  • error 正規表現と一致する場合は、メッセージはエラーとして認定されます。

  • この 2 つの正規表現に一致するものがない場合、SR は無視されます。それは、Adobe Campaign で処理されない中間通知の可能性があります。

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

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

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

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

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

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

  • どの文字がどのエンコーディングに属するのかを把握しておくようにします。GSM7 は、読み分け符号(アクセント記号)を完全にはサポートしていません。 フランス語の場合、é と è が GSM7 に含まれますが、ê、â、ï は含まれません。スペイン語も同じです。

  • セディラが付いた C(ç)は、GSM7 アルファベットでは大文字のみで表示されますが、一部の携帯電話では小文字または「スマート」文字で表示されます。一般的なレコメンデーションは、この文字の使用を避けてセディラを削除するか、UCS-2 に切り替えることです。

  • SMSC プロバイダーから明示的に要求されない限り、SMS では ASCII を使用しないでください。このエンコーディングは、8 ビット文字で GSM7 よりも有効範囲が少ないため、領域を浪費します。このエンコーディングは、北米で使用される CDMA ネットワークで必要な場合があります。

  • Latin-1 は必ずしもサポートされているわけではありません。Latin-1 を使用する前に、SMSC プロバイダーとの互換性を確認してください。

  • 各国語シフトテーブルは、Adobe Campaign コネクタではサポートされていません。代わりに、UCS-2 または他の data_coding を使用する必要があります。

  • UCS-2 と UTF-16 は、多くの場合、携帯電話で混在します。これは、UCS-2 に存在しない絵文字やその他の文字を使用する場合に問題となります。

  • ほとんどの携帯電話では、すべての UCS-2 文字のフォントグリフはありません。スマートフォンは珍しい文字を容易に表示できる傾向にありますが、通常、フューチャーフォンは、購入した国の母語で役立つ文字に対するサポートが制限されています。絵文字やアスキーアートを使用したい場合は、送信前に複数の携帯電話でテストしてください。Adobe Campaign プレビューは、見つからないグリフをシミュレートせず、web ブラウザーで使用できる記号を表示します。

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

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

エンコード
通常の data_coding
メッセージサイズ(文字)
マルチパート SMS のパーツサイズ
使用可能な文字
GSM7
0
160
152
GSM7 基本文字セット + 拡張文字(拡張文字は 2 文字)
Latin-1
3
140
134
ISO-8859-1
UCS-2
UTF-16
8
70
67
Unicode(携帯電話によって異なります)

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 プロセスの数は、デプロイメントによって決まります。通常、MTA は 2 つ、スレッドは 1 つです。 スレッドの数は、 smppConnectorThreads 設定を使用して config-instance.xml ファイル内で変更できます。 通常、コンテナごとに 1 つの MTA プロセス、MTA プロセスごとに 1 つのスレッドがあります。

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

  • 合計接続数=同時接続数 スレッド数 MTA の数

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

分離された 送受信機 mode。上の接続数は、 送受信機 ペアとは、合計で 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 つの機能において役立ちます。

  • ソース番号が指定されていない場合、プレビューにショートコードが表示されます。携帯電話での実際の動作を反映します。

  • 自動応答機能のブロックリスト設定では、特定のショートコードに対してのみ、強制隔離に送信されます。

ソース TON/NPI、ターゲット TON/NPI ton-npi

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

これらは、SUBMIT_SM PDUsource_addr_tonsource_addr_npidest_addr_tondest_addr_npi フィールドにそのまま送信されます。

サービスタイプ service-type

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

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

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

送信ウィンドウ sending-window

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

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

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

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

  • SUBMIT_SMSUBMIT_SM_RESP の間の最大待ち時間を測定します。

  • この値に秒数を掛けて、MT の最大スループットを求めます。これにより、最適な送信ウィンドウの値が得られます。

例:最大 MT スループットに 300 個の SMS が設定されていて、SUBMIT_SMSUBMIT_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_SMSUBMIT_SM_RESP との間のタイムアウト。RESP を時間どおりに受信しない場合、メッセージは失敗と見なされ、MTA のグローバル再試行ポリシーが適用されます。

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

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

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 行だけ宣言することで、この設定を使用すると、特定のエンコーディングを常に使用するように強制できます。

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

data_coding
エンコード
0
GSM
9
UCS-2

つまり、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 に設定する場合:

  • プロバイダーは、ID が「1234」の SR(DELIVER_SM)を送信します。

  • ID「1234」はデータベースで見つかりませんでした。

  • コネクタは、その ID に対して​ 無効な ID エラーを 1 にカウントするので、「メッセージ ID が無効です」エラーコード(通常の動作)と共に DELIVER_SM_RESP を送信します。

  • プロバイダーは、ID が「1234」の同じ SR を再試行します。

  • ID「1234」はやはりデータベースで見つかりませんでした。

  • コネクタは、その ID に対して​ 無効な ID エラーを 2 とカウントするので、正しく処理されなかった場合でも DELIVER_SM_RESP「OK」を送信します。

  • この機能は、無効な SR ブロックが正当でない場合に、プロバイダー側の SR バッファをフラッシュするために使用されます。この場合、メッセージを処理できません。

このフィールドを 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 値(例:REJECTEDUNDELIV)はエラーと見なされます。

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

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

  • 変更しない:ID は、ASCII エンコードされたテキストとして、そのままデータベースに保存されます。前処理やフィルタリングはおこなわれません。

  • 10 進数:ID は、ASCII 形式の 10 進数である必要があります。この設定を使用すると、先頭と末尾の空白文字と先頭の 0 が削除されます。

  • 16 進数:ID は ASCII 形式の 16 進数です。先頭に 0x および末尾に h を付けません。その後、ID を 10 進数に変換してから、データベースに保存します。

  • 16 進文字列:ID は、ASCII エンコードされたテキストで、16 進数でエンコードされたバイト数の文字列である必要があります。例えば、PDU には 0x34 0x31 0x34 0x32 0x34 0x33 があり、これは ASCII「414243」に変換されます。次に、この文字列が 16 進数のバイト文字列としてデコードされ、「ABC」が返されます。ID「ABC」をデータベースに格納します。

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
IMPORTANT
テキスト(ASCII/UTF-8)値を持つオプションのフィールドのみ取得できます。特に、現在の正規表現システムでは、バイナリフィールドを確実に取り込むことはできません。

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

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

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

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

サービス ID タグ

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

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

NOTE
21.1 リリース以降では、複数のオプションパラメーターを追加できるようになりました。 詳しくは、この節を参照してください。

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

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

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

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

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

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

IMPORTANT
「完全な電話番号を送信」設定は、自動返信強制隔離メカニズムの動作に影響します。「完全な電話番号を送信」がオフの場合、強制隔離に入力した電話番号には、国際電話番号の形式と互換性を持たせるために、プラス記号(「+」)が付きます。

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

自動返信オプションパラメータ (TLV) automatic-reply-tlv

21.1 リリース以降では、自動返信 MT にオプションのパラメーターを追加できます。 これらは、オプションの TLV パラメーターとしてに追加されます。 SUBMIT_SM PDU 返信の ( SMPP 仕様(131 ページ)を参照してください。

オプションのパラメーターについて詳しくは、 セクション.

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

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

送信者フィールド from-field

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

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

配信パラメーター delivery-parameters

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

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

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

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

送信モード transmission-mode

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

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

  • 指定なし」の場合、PDU にオプションのフィールドは送信されません。

  • Flash」の場合、値を 1 に設定します。携帯電話上でポップアップ表示され、メモリには保存されない Flash メッセージを送信します。

  • 通常」の場合、値を 0 に設定します。通常のメッセージを送信します。

  • 携帯電話に保存」の場合、値を 2 に設定します。SMS を内部メモリに保存するよう電話に指示します。

  • ターミナルに保存」の場合、値を 3 に設定します。SIM カードに SMS を格納するよう電話に指示します。

有効期間 validity-period

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

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

21.1 リリース以降では、この配信用に送信される各 MT に複数のオプションパラメーターを追加できます。 これらのオプションパラメーターは、 SUBMIT_SM PDU 返信の ( SMPP 仕様(131 ページ)を参照してください。

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

  • パラメーター:パラメーターの説明。 プロバイダーには送信されません。
  • タグ ID:オプションのパラメーターのタグ。 0x1234 形式を使用した、有効な 16 進数である必要があります。 無効な値を指定すると、配信準備エラーが発生します。
  • :オプションのフィールドの値。 プロバイダーに送信される際に UTF-8 としてエンコードされます。 エンコーディング形式は変更できません。バイナリ値を送信したり、UTF-16 や GSM7 などの別のエンコーディングを使用したりできません。

任意のオプションパラメーターが同じ タグ 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 を提供し、その後、1 つ以上の SR に同じ ID を提供します。

プロバイダーから提供された ID は、 sProviderId の列 nmsBroadLogExec 表。 SR は常に、MT が正常に送信され、確認された後に届きますが、順序が狂った場合もあります。これは、Adobe Campaignでは優れた SR として知られています。 処理スレッドは、完全な情報が到達するまで、これらの SR を一時的に RAM に保存します。

MT が確認されたとき (SUBMIT_SM_RESP), sProviderId は、データベース内で即座に更新されます。

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

各 SR に適用されるプロセスを次に示します。

  • SR の ID は、正規表現を使用して抽出されます。
  • この ID はで検索されます。 nmsBroadLogExec:sProviderId.
  • ステータス+エラーコードは、regex を使用して SR から抽出されます。
  • broadlog メッセージメカニズムは、エラーを検証し、broadlog メッセージ ID を見つけるために使用されます。
  • broadlog は上記のすべての情報で更新されます。
  • SR が確認されました。

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

本番運用開始前 checklist

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

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

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

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

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

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

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

SMS のテスト test

  • SMS に様々な文字を送信する
    GSM 以外の文字や ASCII 以外の文字で SMS を送信する必要がある場合は、できるだけ多様な文字でメッセージを送信してみてください。カスタム文字マッピングテーブルを設定する場合は、考えられるすべての data_coding 値に対して 1 つ以上の SMS を送信します。

  • SR が正しく処理されていることを確認する
    SMS が配信ログに受信済みとマークされます。配信ログは正常に作成され、次のようになります。
    SR yourProvider stat=DELIVRD err=000|#MESSAGE
    配信プロバイダー名を変更したことを確認してください。実稼働環境では、配信ログに SR Generic を含めないでください。

  • MO が処理されていることを確認する:MO を処理する必要がある場合(自動応答、MO のデータベースへの格納など)、いくつかテストを試してみてください。すべての自動返信キーワードに対して SMS を送信し、返信速度が適切である(数秒以内)ことを確認します。Adobe Campaign が DELIVER_SM_RESP(command_status=0)に正常に応答したことをログで確認します。

PDU の確認 check-pdus

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

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

BIND bind

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

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

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

SUBMIT_SM / DELIVER_SM submit-sm-deliver-sm

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

SUBMIT_SM PDU を使用:

  • data_coding が正しいことを確認し、デフォルトでは 0 になっていることを確認します。
  • short_message が正しくエンコードされていることを確認します。複数のエンコーディングをサポートする 16 進数コンバーターを使用してデコードしてみてください。

SUBMIT_SM_RESP PDU を使用:

  • 成功したことを確認します(command_status = 0)。
  • 本文で、適切にフォーマットされた ID の後に「0」バイトが続くことを確認します。

DELIVER_SM PDU を使用:

  • 16 進数 short_message フィールドをデコードします。
  • SR 内の ID の Extraction 正規表現に定義された正規表現が 1 つの取得グループを返し、メッセージ内の ID 全体を取り込むことを正規表現チェックツールで確認します。
  • 抽出した ID が SUBMIT_SM_RESP の ID と一致することを確認します。
  • SR 内のステータスの Extraction 正規表現に定義されている正規表現が、stat フィールドの内容を返すことを確認します。
  • SR 内のエラーの Extraction 正規表現に定義されている正規表現が err フィールドの内容を返すことを確認します。

DELIVER_SM_RESP PDU を使用:

  • DELIVER_SM PDU を受信した後、通常 1 秒未満で迅速に送信されたことを確認します。
  • 成功したことを確認します(command_status = 0)。

問題がないかプロバイダーに問い合わせる provider

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

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

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

recommendation-more-help
3ef63344-7f3d-48f9-85ed-02bf569c4fff