View a markdown version of this page

Connect Customer のオーディオ品質問題のトラブルシューティング - Amazon Connect Customer
開始する前に: 情報を収集しますステップ 1: 症状を特定するステップ 2: スコープを決定するステップ 3: 呼び出しパスを使用して問題をローカライズするステップ 4: 診断データを収集する (エージェント側、パス 1、2、3)ステップ 5: エージェント側の問題を解決するステップ 6: エンドユーザー/テレフォニーの問題を解決する (パス 4/5/6)ステップ 7: AWS サポートに連絡する前に

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Connect Customer のオーディオ品質問題のトラブルシューティング

対象者

このガイドでは、ネットワーク、テレフォニー、ワークステーションの問題の調査経験があり、Connect Customer の問い合わせレコードのデータにアクセスできることを前提としています。

音声品質の問題は、音声、エコー、遅延、一方向音声、ハミング、デッドエアなど、通話パスの任意の場所で発生する可能性があります。このページは、それらを診断するための出発点です。これにより、問題が発生するパス内の場所を絞り込み、それを解決する専用のトピックに移動します。

通話の切断

このページでは、オーディオ品質について説明します。通話が悪く聞こえるのではなく切断または切断されている場合は、「」を参照してください問い合わせレコードの DisconnectDetails を使用した通話切断に関するトラブルシューティング。

開始する前に: 情報を収集します

開始する前に、影響を受ける呼び出しについて以下を収集します。これは、調査し、必要に応じて AWS Support でケースを開くために必要です。

  • 症状の説明 - 音声がどのように聞こえるか (途切れ、ロボット、エコー、一方向、ハミング、デッドエア、遅延）、および音声が影響を受けるか。これはステップ 1 で使用します。

  • インスタンス Amazon リソースネーム (ARN) — 「」を参照してくださいConnect Customer インスタンス ID または ARN を検索する。

  • 影響を受ける各通話の ContactId (3～5 個の例を示し、24 時間未満は提供しないでください）。

  • タイムゾーンを含む出現時刻 (可能な場合は協定世界時 (UTC) で記録）。

  • 各例の通話録音。

録音を直接取得できない場合は、エージェントまたは顧客に確認して確認します。

  • エージェントまたはエンドユーザーなど、オーディオが劣化しているユーザー。

  • 報告された劣化が実際に記録で聞こえるかどうか。

前提条件

トラブルシューティングの前に、エージェントワークステーションが最小ハードウェア要件を満たし、エージェントがサポートされているブラウザを使用するという基本事項を確認してください。

ステップ 1: 症状を特定する

症状を使用して、最も可能性の高い原因にジャンプします。症状が表示されていない場合、または不明な場合は、ステップ 2 に進みます。

症状 可能性が最も高いエリア 行き先
Windows 11 の再起動後の最初の呼び出しでオーディオ (「デッドエア」) がない ワークステーション (ネットワークインターフェイスカード/サービス) Windows 11 を使用する場合のシステム再起動後の最初の呼び出し時の CCP オーディオの問題
再起動後ではなく、双方向の音声がない (どちらの当事者も相手の音声を聞くことができない) 問い合わせコントロールパネル (CCP) のセットアップ、マイクアクセス、またはポート コンタクトコントロールパネル (CCP) の問題、Amazon Connect CCP の呼び出し中に停止したオーディオのトラブルシューティングを行うにはどうすればよいですか? (AWS re:Post)
一方の当事者が他方の相手の音声を聞くことができない (一方向音声) 排他的なマイク/スピーカー制御、またはネットワークアドレス変換 (NAT) 顧客からの一方向のオーディオ, 通話の音質と切断の問題に関するネットワークのトラブルシューティング
エージェントのオーディオの永続的なハミング ヘッドセット/ブラウザのサンプルレートの不一致 エージェントの音声デバイスのハミングサウンド: ヘッドセットとブラウザのサンプルレートを確認します。
不在着信/「マイクにアクセスできません」/「初期化に失敗しました」/ウェブリアルタイム通信 (WebRTC) タイムアウト CCP のセットアップ、アクセス許可、またはポート コンタクトコントロールパネル (CCP) の問題
Echo (エージェントは自分の声を聞きます) マイク/スピーカーのフィードバック 通話の音質と切断の問題に関するエージェントワークステーションのトラブルシューティング
途切れ/壊れた、遅延した、または歪んだ/回転したオーディオ ネットワークまたはワークステーション ステップ 2 に進む

ステップ 2: スコープを決定する

影響を受けるエージェントの数は、最初に見る場所が変わります。

  • 単一のエージェント — そのエージェントのワークステーション (ステップ 5、ワークステーションパス) とヘッドセットに焦点を当てます。

  • 同じ場所または階層内の複数のエージェント — ローカルネットワークの問題 (ルーター、インターネットサービスプロバイダー (ISP)、またはローカルエリアネットワーク (LAN))、またはそれらのマシンにプッシュされたソフトウェアまたは OS 更新を疑います。

  • 複数の場所 (リモートおよびオフィス内) にまたがるエージェント — 組織レベルのネットワーク変更またはブラウザ/OS の自動更新を疑います。

問い合わせレコードDeviceInfoの AgentHierarchyGroupsと を使用して、影響を受ける母集団を特定します。影響分析の詳細については、「」を参照してください問い合わせレコードに含まれる QualityMetrics を使用して音質に関するトラブルシューティングを行う。

ヒント

影響を受けるすべてのエージェントの特定の日に問題が発生した場合は、その日にプッシュされたネットワークインフラストラクチャの変更、ブラウザの自動更新、または OS パッチを確認します。

ステップ 3: 呼び出しパスを使用して問題をローカライズする

エージェントが問い合わせコントロールパネル (CCP) を使用する場合、 呼び出しはこのパスを通過します。

(1) ヘッドセット → (2) エージェントデバイス/CCP → (3) エージェントネットワーク → (4) カスタマーの接続 → (5) テレフォニーネットワーク → (6) エンドカスタマーデバイス

Connect Customer は、ポイント (4) で各通話を記録するため、録音は Connect Customer に到着したとおりに音声をキャプチャします。録音は分割線です。録音で劣化が聞こえる場合、Connect Customer (パス 1～3) に到達する前にオーディオが既に劣化していました。録音がクリーンに聞こえるが、参加者が不正な音声を報告した場合、リスナーへのパスのポイント 4 の後に低下が発生しました。

次の表を使用して、観察した内容と結論、次に進むべき点をペアにします。

オーディオが劣化するユーザー 記録に分解がある 記録に分解が含まれていない
エージェント (顧客が聞いたエージェントの音声) Connect Customer — ヘッドセット、デバイス、またはエージェントネットワーク (1、2、3) に到達する前にオーディオが劣化しました。ステップ 4 に進みます。 Audio reached Connect Customer cleanly but customer heard degradation — telephony network or end-customer side (5 and 6)。ステップ 6 に進みます。
エンドユーザー (エージェントが聞いた顧客の声) テレフォニーネットワークまたはエンドカスタマーデバイス (5 と 6) のインバウンド側で Connect Customer に到達する前にオーディオが劣化しました。ステップ 6 に進みます。 Audio reached Connect Customer cleanly but agent heard degradation—agent network, device, orヘッドセット (1, 2, and 3)。ステップ 4 に進みます。
マルチパーティー通話と電話会議

会議通話またはマルチパーティー通話の場合は、通話全体ではなく、レッグごと (ContactId ごと) にこの録音ローカリゼーションロジックを適用します。

録音は利用できません

記録から影響を受けるパスを特定できない場合、または記録が利用できない場合は、ステップ 4 に進んでメトリクスをプルします。これにより、問題を個別にローカライズできます。

ステップ 4: 診断データを収集する (エージェント側、パス 1、2、3)

これらを順番に実行します。各 は完全な手順にリンクします。

  1. エンドポイントテストユーティリティ — 影響を受けるエージェントのマシンから、WebRTC サポート、メディアデバイスアクセス、リージョンごとのレイテンシー (300 ミリ秒未満のターゲット）、および必要なポートを検証します。JSON 結果をダウンロードします。「エンドポイントテストユーティリティを使用してお客様に接続する接続を検証する」を参照してください。

  2. 問い合わせレコードの QualityMetrics — DescribeContact を呼び出して以下を確認します。

  3. CCP ログ — 利用可能な場合は、それらをダウンロードして CCP ログパーサーで開きます。影響を受ける呼び出し中に、ERROR レベルのエントリと WebRTC メトリクスを確認します。PacketLoss、 JitterBufferMillis (> 30 ミリ秒は異常）、 RoundTripTime (> 300 ミリ秒は異常）。「Connect Customer Contact Control Panel (CCP) ログをダウンロードして確認する」を参照してください。

  4. Amazon CloudWatch — 問題発生時に が 20% ToInstancePacketLossRateを超えたかどうかを確認します。このメトリクスの確認の詳細については、Amazon Connect オーディオ品質問題のトラブルシューティング (AWS re:Post)」を参照してください。オーディオ品質は、パケット損失率が 20% を大幅に下回ると低下する可能性があります。このしきい値は、即時のネットワークチームの関与を必要とする重大な問題を示します。

次に、見つかったものに分岐します。

  • 異常なメトリクスが見つかった → をネットワークの問題として扱います (ステップ 5、ネットワークパス）。

  • 異常なメトリクスなし → ワークステーションの問題として扱います (ステップ 5、ワークステーションパス）。

ステップ 5: エージェント側の問題を解決する

ネットワーク (パス 3)

エージェントネットワークへの異常な PacketLoss、JitterBuffer、RoundTripTime、または高ToInstancePacketLossRateポイント。以下を確認してください。

  • 仮想プライベートネットワーク (VPN) — VPN (直接接続) なしで問題が再現されますか? VPN が必要な場合は、リアルタイムトラフィックに対して分割トンネリングが有効になっていますか?

  • Wi-Fi と有線 — 有線接続で再現されますか?

  • Firewall/proxy/NAT — UDP 3478 (メディア）、TCP 443、およびウェブソケットトラフィックは許可されていますか? 可能な場合は、キープアライブで静的 NAT を使用します。

  • 帯域幅の競合 — 大規模なファイル転送や帯域幅の多いアプリケーションが同時に実行されていますか?

  • リージョンまでの距離 — エージェントはインスタンスの AWS リージョンから遠いですか? (高い と相関します)RoundTripTime。

完全な手順: 通話の音質と切断の問題に関するネットワークのトラブルシューティング。メトリクス解釈の詳細については、「」を参照してください問い合わせレコードに含まれる QualityMetrics を使用して音質に関するトラブルシューティングを行う。

ワークステーション (パス 1/2)

ヘッドセット、デバイス、またはソフトウェアを指す異常なネットワークメトリクスはありません。以下を確認してください。

完全な手順: 通話の音質と切断の問題に関するエージェントワークステーションのトラブルシューティングおよび Amazon Connect コンタクトセンターのエージェントワークステーションの通話品質の向上 (規範ガイダンス）。 Amazon Connect

ステップ 6: エンドユーザー/テレフォニーの問題を解決する (パス 4/5/6)

デグレードがエンドカスタマー/テレフォニー側にある場合、エージェントワークステーションで修正することはできません。ケースを開く前にソースを分離してみてください。

  • 呼び出し元の環境を変更します。エンドユーザーに別のデバイス、ネットワーク、またはキャリアを試してもらいます。

  • 一般的な要因を確認します。問題は特定のキャリア、直通ダイヤル (DID) 番号、または地理的リージョンと相関していますか? 特定の国または番号タイプと相関する場合は、Amazon Connect ウェブサイトの Amazon Connect Telecoms Coverage ガイドで、その国のカバレッジと既知のテレフォニー制限を確認してください。

  • 通話転送を確認します。 は、Connect Customer への別のシステム転送通話ですか? その場合、問題は転送せずに Connect Customer への直接ダイヤルで発生しますか?

  • 複数の数値をテストする — 複数の送信先番号と送信元番号を試して、問題が特定の数値に従っているかどうかを確認します。

これらの変更間で問題が解決しない場合は、 AWS サポートでケースを開きます。

ステップ 7: AWS サポートに連絡する前に

トラブルシューティング後も問題が解決しない場合は、24 時間以内に 3～5 例のケースを開き、以下を含めます。

  • インスタンス ARN と症状の説明 (音声、音声なし、エコーなど）。

  • ContactIds、タイムスタンプ (UTC)、および問い合わせレコードスナップショット。

  • ケースにアタッチされた通話録音。

  • エンドユーザーの問題の場合: エンドユーザーの電話番号 (最後の 4 桁はマスクされている場合があります) と Connect Customer の電話番号。

  • テスト結果: テストされたブラウザ、テストされたネットワーク、代替マシンテスト、エンドポイントテストユーティリティ JSON エクスポート、および Ping と MTR の実行後の観測値。

  • エージェント環境の詳細: VPN/firewall/VDI 設定、ヘッドセットタイプ、オーディオ機能強化モード。

  • CCP タイプ (デフォルトとカスタム) と、影響を受ける呼び出し用にダウンロードされた CCP ログ。

  • 問題の頻度と開始日時 (UTC)。

影響を受けた呼び出しの直後に CCP ログをダウンロードする

CCP ログは、現在のブラウザセッション内でのみ保持されます。エージェントが CCP タブを閉じたり更新したりすると、ブラウザはログを破棄し、影響を受けた呼び出しの直後にダウンロードします。