[限定提供（LA）]{class="badge informative"}
SMS チャネルの特性 sms-channel
SMS の種類 sms-types
SMS プロバイダー経由で SMS を送信する場合、次の 3 種類の SMS が発生します。
- SMS MT（Mobile Terminated：モバイル着信）：Adobe Campaign が SMPP プロバイダーを通じて携帯電話に向けて発信する SMS です。
- SMS MO（Mobile Originated：モバイル発信）：携帯電話から 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 で送信される情報 sms-info
SMS は、テキストよりも多くの情報を伝送します。SMS によって提供される情報のリストを以下に示します。
- テキスト。140 バイトに制限されます。つまり、エンコーディングに応じて 70～160 文字の範囲です。詳細と制限については、SMS テキストエンコーディングを参照してください。
- 受信者のアドレス。ADC または MSISDN（「電話番号」の技術名）とも呼ばれます。SMS を受信する携帯電話の番号です。
- 送信者のアドレス。oADC または送信者 ID とも呼ばれます。電話番号（日常的に使用）、ショートコード（プロバイダーを通じて送信される場合）または名前（オプション機能。これを使用した場合は SMS に返信できません）を指定できます。
- メッセージが Flash メッセージであるかどうかを示すフラグ（Flash メッセージは、メモリに保存されないポップアップです）
- SR が予想されるかどうかを示すフラグ。
- 有効日。この日を過ぎると、ネットワーク機器は再試行できません（常に存在または遵守されるわけではありません）。
- data_coding フィールド。テキストのエンコーディングを示します。
SMS テキストエンコーディング sms-text-encoding
最初のルールは、エンコーディングの問題が発生した場合は、常に SMPP プロバイダーに問い合わせること です。SMPP プロバイダーの技術プラットフォームには限りがあるため、SMPP プロバイダーがサポートするエンコーディングおよび適用される可能性がある特別なルールを正確に把握しているのは、SMSC プロバイダーのみです。自身が送信した内容と返信された内容をプロバイダーに確認してもらってしてください。これが、成功し、安定した相互接続への唯一の道です。
SMS メッセージは、特殊な 7 ビットエンコーディングを使用します。通常、GSM7 エンコーディングと呼ばれます。Wikipedia には、これに関する優れた記事（英語版の GSM 03.38）があります。
SMPP プロトコルでは、トラブルシューティングを容易にするために、GSM7 のテキストが 1 文字あたり 8 ビットに拡張されます。SMSC は、携帯電話に送信される前に、1 文字あたり 7 ビットにパックします。つまり、SMS の short_message フィールドの長さは SMPP フレームで最大 160 バイトになりますが、モバイルネットワークで送信される場合は 140 バイトに制限されます（最上位ビットは単に破棄されます）。
エンコードの問題が発生した場合は、次の点を確認してください。
- まず、どの文字がどのエンコードに属するのかを把握しておくようにします。GSM7 は、一部の読み分け符号（アクセント）をサポートしていないことで有名です。フランス語の場合、é と è が GSM7 に含まれますが、ê、â、ï は含まれません。スペイン語も同じです。
- セディラが付いた C（ç）は、GSM7 アルファベットでは大文字のみで表示されますが、一部の携帯電話では小文字または「スマート」文字で表示されます。一般的に、この文字の使用を避けてセディラを削除するか（フランス語ではそれでも十分読みやすい）、UCS-2 に切り替えることが推奨されます。
- SMS では ASCII を使用しないでください（SMSC プロバイダーから明示的に要求されない限り）。このエンコードは、8 ビット文字で GSM7 よりも有効範囲が少ないため、領域を浪費します。このエンコードは、（北米で使用される）CDMA ネットワークで必要な場合があります。
- Latin-1 は必ずしもサポートされているわけではありません。Latin-1 を使用する前に、SMSC プロバイダーとの互換性を確認してください。
- 各国語シフトテーブルは、Adobe Campaign コネクタではサポートされていません。代わりに、UCS-2 または他の data_coding を使用する必要があります。
- UCS-2 と UTF-16 は、多くの場合、携帯電話で混在します。これは、UCS-2 に存在しない絵文字やその他のまれに使用される文字を送信する人物にとっては問題となります。
- 以前の携帯電話にのみ、すべての UCS-2 文字のフォントグリフはありません。最新のスマートフォンは珍しい文字を容易に表示できる傾向にありますが、以前のスマートフォンは多くの絵文字が欠けていることが多く、非常に以前のフィーチャーフォンは、通常、購入した国の母語で役立つ文字に対するサポートが制限されています。絵文字や何らかのアスキーアートを使用したい場合は、送信前に複数の携帯電話でテストしてください。Campaign プレビューは、見つからないグリフをシミュレートせず、プレビューを表示する web ブラウザーで使用できるすべての記号を表示します。
data_coding フィールドは、使用されるエンコーディングを示します。主な問題は、値 0 が仕様では デフォルトの SMSC エンコーディング を意味し、通常は GSM7 を意味しますが、常にそうであるとは限らないことです。エンコーディングが data_coding = 0 に関連付けられている SMPP パートナーにお問い合わせください。他の data_coding 値は仕様に従う傾向にありますが、念のため SMPP プロバイダーに確認することをお勧めします。
メッセージの最大サイズは、エンコーディングによって異なります。次の表に、すべての関連情報をまとめます。
マルチパート SMS（長文 SMS） multipart-sms
マルチパート SMS（通常、長文 SMS と呼ばれる）は、複数のパーツで送信される SMS です。モバイルネットワークプロトコルの技術的な制限により、SMS は 140 バイト以下にする必要があります（SMS に収まる文字数について詳しくは、以下の SMS テキストエンコーディングの節を参照）。そのため、長いメッセージは分割する必要があります。
長いメッセージの各部分は、個々の SMS です。これらのパーツは、ネットワーク上を単独で移動し、受信側携帯電話によって組み立てられます。再試行と接続の問題を適切に処理するために、Campaign はパーツを逆順に送信し、メッセージの最初の部分（最後に送信された部分）でのみ SR を要求します。携帯電話は最初の部分を受け取ったときにのみメッセージを表示するので、他の部分の再試行は携帯電話で重複を生成しません。
配信ごとの SMS の最大数は、配信テンプレートのメッセージごとの SMS の最大数設定を使用して、メッセージごとに設定できます。この制限を超えると、メッセージが長すぎることが原因で SMS の送信に失敗します。
長い SMS を送信する方法は 2 つあります。
- UDH
- message_payload
UDH は、長いメッセージを送信するデフォルトおよび推奨される方法です。このモードでは、コネクタは UDH 情報を含む複数の SUBMIT_SM PDU にメッセージを分割します。このプロトコルは、携帯電話が使用するプロトコルです。つまり、Campaign はメッセージの生成を最大限制御でき、送信されたパーツの数と分割方法を正確に計算できます。
message_payload は、長いメッセージを単一の SUBMIT_SM PDU で送る方法です。プロバイダーはこれを分割する必要があります。つまり、Campaign が送信されたパーツの数を正確に把握することは不可能です。一部のプロバイダーはこのモードを必要としますが、UDH をサポートしていない場合にのみ使用します。
プロトコルとフォーマットについて詳しくは、SUBMIT_SM PDU の esm_class、short_message、message_payload の各フィールドの説明を参照してください。