SMS トラブルシューティング troubleshooting-sms

その問題は 1 つまたは複数のアカウントで発生した

この場合、各アカウントに別々にその他のトラブルシューティング手順を適用できます。ネットワークトラフィックとログ数を減らすために、アカウントの診断時に他のアカウントを無効にすることをお勧めします。

1 つのアカウントのみアクティブの場合は、問題は発生しなかった

アカウント間で競合が発生しています。前述したように、Adobe Campaign はアカウントを個別に扱いますが、プロバイダーはアカウントを単一のアカウントとして扱うことができます。

• すべてのアカウント間で異なるログイン／パスワードの組み合わせを使用しています。プロバイダーに連絡して、プロバイダー側の競合の可能性を診断する必要があります。

• 一部の外部アカウントは、同じログイン／パスワードの組み合わせを共有します。プロバイダーは、BIND PDU がどの外部アカウントから来たのかを知る手段がないので、複数のアカウントからの接続をすべて単一のものとして扱います。2 つのアカウントに対してランダムに MO と SR をルーティングし、問題を引き起こしている可能性があります。プロバイダーが同じログイン／パスワードの組み合わせで複数のショートコードをサポートしている場合は、BIND PDU のどこにショートコードを置くのかについて問い合わせる必要があります。MO を正しくルーティングできるのは BIND PDU だけなので、この情報は BIND PDU の中に入れる必要があり、SUBMIT_SM の中に入れる必要はありません。BIND PDU で使用できるフィールドは、前述の各種 PDU の情報の節を参照してください。通常は address_range にショートコードを追加しますが、プロバイダーの特別なサポートが必要です。複数のショートコードを個別にルーティングする方法については、担当者にお問い合わせください。Adobe Campaign は、同じ外部アカウントでの複数のショートコードの処理をサポートしています。

コネクタが最近変更されたかどうか、およびどのユーザーによって変更されたかを調べます（外部アカウントをグループとして確認します）。

select saccount, (sserver ||':'||sport) as serverPort, iextaccountid, CASE WHEN N0.iactive=1 THEN 'Yes' ELSE 'No' END as "(x) Enabled",

(select X1.sname from xtkoperator X1 where N0.icreatedbyid = X1.ioperatorid) as "Created By",

(select X1.sname from xtkoperator X1 where N0.imodifiedbyid = X1.ioperatorid) as "Last Modified By",

N0.slabel as "External Account", N0.tslastmodified as "LastModifiedDate"

from nmsextaccount N0 LEFT JOIN xtkoperator X0 ON (N0.icreatedbyid=X0.ioperatorid) order by 8 DESC LIMIT 50;

システムがアップグレードされたかどうか、およびシステムがアップグレードされたタイミングを調べます（/postupgrade ディレクトリ内）。

SMS に影響を与えるパッケージが最近アップグレードされた可能性があるかどうかを調べます（/var/log/dpkg.log）。

ミッドソーシング環境で問題が発生した場合は、配信とブロードログが適切に作成され、ミッドソーシングサーバーで更新されていることを確認してください。そうでない場合は、SMS の問題ではありません。

ミッドサーバー上で動作し、SMS が正しく送信され、マーケティングインスタンスが正しく更新されない場合は、中間同期の問題が発生している可能性があります。

BIND PDU がゼロ以外の command_status コードを返す場合は、プロバイダーに詳細を問い合わせてください。

プロバイダーへの TCP 接続を確立できるように、ネットワークが正しく設定されていることを確認してください。

プロバイダーに、Adobe Campaign インスタンスの許可リストに IP が正しく追加されたかどうかを確認するように依頼します。

外部アカウント ​の設定を確認します。フィールドの値をプロバイダーに問い合わせます。

接続が成功したものの不安定な場合は、不安定な接続の問題の節を確認してください。

接続の問題を診断するのが困難な場合、ネットワークキャプチャによって情報を取得できる場合があります。問題が発生するときにネットワークのキャプチャを同時に実行すると、効率的に分析できます。また、問題が発生した正確な時刻もメモしておく必要があります。

接続状態が 1 時間未満の場合。Adobe Campaign Classic トランスミッター接続は、Adobe Campaign Classic MTA の動作方法が原因で例外です。

プロバイダーが UNBIND PDU を送信する場合。

enquire_link が、Adobe Campaign 側またはプロバイダー側でタイムアウトする場合。この場合、ENQUIRE_LINK_RESP にはゼロ以外のエラーコードが表示されます。

BIND PDU が多数ある場合。接続数によっては、1 日の間に数回を超えるべきではありません。1 時間に 1 つ以上の BIND PDU は、警告を発する必要があります。

不安定な接続が根本的な原因であることはほとんどありません。多くの場合、別の問題により接続解除がトリガーされた結果です。根本原因の特定を優先する必要があります。

詳細 SMPP トレースを有効にします。接続が再開されたときに何が起きているのかを確認するために必要になります。

プロバイダーが BIND PDU を送信した場合は、問題が発生している可能性があります。UNBING が送信された理由をプロバイダーに問い合わせてください。

ネットワークのキャプチャをおこなうことが、接続が閉じられた状態を確認する唯一の方法である場合があります。

プロバイダーが TCP FIN または TCP RST packet を送信して接続を閉じた場合は、プロバイダーに詳細を問い合わせてください。

エラーコードを使用して DELIVER_SM_RESP などのクリーンエラーを送信した後にプロバイダーが接続を閉じた場合は、コネクタを修正する必要があります。そうしないと、他の種類のメッセージが送信されず、MTA スロットルがトリガーされます。これは、接続を閉じると MT と SR の両方に影響を与えるトランシーバモードで特に重要です。

接続が安定していることを確認します。SMPP 接続は、Adobe Campaign Classic 上のトランスミッタ―を除き、少なくとも 1 時間は接続状態が維持される必要があります。不安定な接続に関する問題の節を参照してください。

MTA を再起動することで、しばらくの間送信 MT が再び作動する場合、接続が不安定なためにスロットルが発生する可能性があります。不安定な接続に関する問題の節を参照してください。

広範ログが存在し、ステータスと日付が正しいことを確認します。そうでない場合は、配信または配信の準備に関する問題である可能性があります。

MTA が実際にメッセージを処理していることを確認します。そうでない場合は、SMS の問題ではない可能性があります。

SMS コネクタがプロバイダーの機器に実際にバインドされていることを確認します。すべてのシステムが正しく通信されていることを確認するために、プロバイダーにフィードバックを求めます。バインド処理について詳しくは、BIND_TRANSMITTER および BIND_TRANSCEIVER PDU を参照してください。適切なトラブルシューティングをおこなうために、SMPP トレースを有効にする必要がある場合があります。

SMPP トレースを有効にして、SUBMIT_SM PDU に正しい情報が含まれていることを確認します。

プロバイダーが「OK」値（コード 0）で SUBMIT_SM_RESP PDU に応答していることを確認します。PDU が適切な遅延で到着することを確認します。1 秒を超える場合はプロバイダーに問い合わせる必要があります。通常は、100 ミリ秒未満で到達します。

これらの手順がすべて正常に動作する場合は、問題がプロバイダー側にある可能性が高いです。プロバイダー側のプラットフォームのトラブルシューティングをおこなう必要があります。

動作してもスループットが異なる場合は、送信ウィンドウを調整し、MT スループットを下げてみてください。MT スループットを調整するには、プロバイダーに依頼する必要があります。Adobe Campaign は非常に速くメッセージを送信できるので、プロバイダーの機器でパフォーマンスの問題が発生する可能性があります。

重複が正確に 60 秒間隔で送信されている場合は、おそらくプロバイダー側の問題で、SUBMIT_SM_RESP を十分な速度で送信していません。

BIND/UNBIND が多い場合は、接続が不安定です。重複メッセージの問題を解決しようとする前に、不安定な接続の問題の節を参照してください。

SR のトラブルシューティングを行うには、SMPP トレースを有効にする必要があります。

DELIVER_SM PDU がプロバイダーから送信されたものであり、正しい形式であることを確認します。

Adobe Campaign が DELIVER_SM_RESP PDU に正常に応答したことを適切なタイミングで確認します。Adobe Campaign Classic では、SR が providerMsgId テーブルに挿入され、SMS プロセスによる遅延処理がおこなわれていることが保証されます。

外部アカウント ​の ID 抽出とエラー処理に関連する正規表現を確認します。場合によっては、DELIVER_SM PDU の内容に対してこれらを検証する必要があります。

broadLogMsg テーブルで、エラーが適切にプロビジョニングされていることを確認します。

テスト中に SMPP トレースを有効にします。TLS を有効にしない場合は、MO のトラブルシューティング時にネットワークキャプチャを実行し、PDU に正しい情報が含まれ、正しくフォーマットされていることを確認する必要があります。

ネットワークトラフィックをキャプチャしたり、SMPP トレースを分析する場合、応答が設定されている場合は、MO とその応答 MT との会話全体をキャプチャするようにしてください。

MO（DELIVER_SM PDU）がトレースに表示されない場合は、プロバイダー側に問題があります。プロバイダーのプラットフォームでトラブルシューティングをおこなう必要があります。

DELIVER_SM PDU が表示された場合は、Adobe Campaign が DELIVER_SM_RESP PDU に成功したことを確認してください（コード 0）。この RESP は、すべての処理ロジックが Adobe Campaign によって適用されていることを保証します（自動応答および許可／ブロックリスト）。そうでない場合は、SMS プロセスログでエラーメッセージを検索します。

自動返信が有効な場合は、SUBMIT_SM がプロバイダーに送信されたことを確認します。送信されない場合は、必ず SMS プロセスログにエラーメッセージが表示されます。

応答を含む SUBMIT_SM MT PDU がトレースに見つかったものの、SMS が携帯電話に届かない場合は、プロバイダーに問い合わせてトラブルシューティングのサポートを依頼する必要があります。

電話番号の形式が、強制隔離テーブルと配信ログで完全に同じであることを確認します。それ以外の場合で、国際電話番号形式のプラスプレフィックスに問題がある場合は、この節を参照してください。

ショートコードを確認します。受信者のショートコードが外部アカウントで定義されているものと同じ場合、または空の場合（空の場合は任意のショートコード）に、除外が発生する可能性があります。Adobe Campaign インスタンス全体にショートコードを 1 つだけ使用する場合、すべての​ ショートコード ​フィールドを空にすると、処理が容易になります。

問題が発生した場合に、詳細 SMPP メッセージを有効 ​にします。ほとんどの SMS 問題は、これなしでは解決できません。

問題が SMS トラフィックに関連している場合は、まずプロバイダーに問い合わせてください。プロバイダーのプラットフォームは、SMS トラフィックの問題をリアルタイムで効率的に診断するのに最適です。

問題についての簡潔で事実に即した説明を含めます。

期待される結果の説明を含めます。

プロバイダーからのフィードバックを含めます。

関連するログやネットワークキャプチャを含めます。キャプチャを取得する場合は、キャプチャ中に問題を再現してください。

ログ、トレース、またはキャプチャを含める場合、問題が発生したときのファイル内の正確な場所を特定します。

メッセージ、PDU、ログを参照する場合は、見つけやすいようにタイムスタンプを明確に記述してください。

テスト環境で問題を再現してみてください。設定が不明な場合は、テスト環境で試して、SMPP トレースの結果を確認してください。通常、実稼働環境の問題を直接報告するよりも、テスト環境で問題を再現して報告する方が効果的です。

プラットフォームでおこなった変更や微調整を含めます。また、プロバイダー側でおこなった可能性のある変更も含めます。

接続に問題がありますが、詳細メッセージには BIND_RESP PDU が表示されません。

エラーメッセージのない不明な接続の切断。低レベルのプロトコルエラーを検出した場合のコネクタの通常の動作です。

プロバイダーは、バインド解除／切断プロセスに関してエラーを出しています。

オプションの TLV フィールドでのエンコードの問題。

トラフィックが異なる接続間で混在している疑いがあります。

TLS が有効：定義上、TLS トラフィックは暗号化されるため、キャプチャできません。

パフォーマンスの問題：ログにパフォーマンスの問題を追跡するために必要なすべての情報が含まれます。

タイミングの問題（retry timing、enquire_link 期間、スループットの上限など）

SR 解析と処理：詳細ログは、より多くのコンテキストを提供し、より適切な表示を提供します。

MO 処理（自動応答、強制隔離）

実際の SMPP トラフィックが関係しないエラー：配信の準備、Message Center API の問題、ワークフローの問題など

モバイルで受信済み:
メッセージがユーザーのデバイスに正常に配信されました。モバイル終了（MT）配信とステータスレポート（SR）の両方で確認が提供されます。

送信済み:
メッセージはモバイル終了（MT）ステップを通じて正常に処理されましたが、モバイルデバイスへの配信を確認するステータスレポート（SR）がまだ受信されていません。

プロバイダーに送信:
メッセージは SUBMIT_SM command を使用してプロバイダーに送信されましたが、プロバイダーから SUBMIT_SM_RESP の確認は受信されませんでした。

保留中：メッセージはまだアグリゲータに送信されていません。

プロバイダーで受信済み: メッセージがアグリゲータに送信され、アグリゲータで受信が確認されました。

送信済み：即時エラーなく、メッセージがユーザーのモバイルネットワークに正常にプッシュされたことをアグリゲータが確認しました。

モバイルで受信済み：ユーザーのモバイルデバイスが受信を確認し、アグリゲータによって検証されています。

失敗：メッセージがアグリゲータに送信され、アグリゲータは定義された期間（例：数時間）にわたってユーザーのモバイルデバイスへの配信を試みました。 ネットワークの問題、ユーザーデバイスが使用できないなどの理由で、配信が最終的に失敗しました。