Amazon Connect
管理者ガイド

Amazon Connect のトラブルシューティングとベストプラクティス

このガイドを使用して、Amazon Connect を使用するためのベストプラクティスを見極めます。また、正常に動作していない場合の情報をトラブルシューティングするためにも使用します。

Contact Control Panel を使用するベストプラクティス

このガイドには、CCP ソフトフォンに関する情報 (例: ベストプラクティスおよびトラブルシューティング) を含みます。ソフトフォン接続要件を満たせない、またはソフトフォンの問題が発生するワークステーションの場合、CCP にも外部デバイスにリダイレクトする機能が搭載されています。

エージェントのワークステーションの要件

コンタクトセンターのエージェントワークステーションは、大きく異なります。Amazon Connect CCP は、高レベルのジッタや高レイテンシーの環境に対応するよう構築されていますが、エージェントが使用するワークステーションのアーキテクチャ、コールを受ける場所や環境は、エクスペリエンスの質に影響を及ぼす可能性があります。

ワークステーションが電力不足の場合は、エージェントが発信者にサービスを提供するために必要なツールやリソースにアクセスしづらくなる可能性があります。また、負荷がかかっても、ユースケースに対して適切なマルチタスクを実行できるようにするには、ワークステーションのスコープ設定時のリソース要件に注意してください。エージェントと顧客のオーディオ体験で最良の結果を得るために、USB ヘッドセットの使用をお勧めします。または、エージェントの既存テレフォニーを使用して E.164 形式でコールを外部番号にリダイレクトすることもできます。

以下の値は、CCP のみを使用するワークステーションの最小システム要件です。リソースの競合を避けるために、オペレーティングシステムおよびワークステーション上で実行中のものについては、追加のメモリ、帯域幅、および CPU のスコープを設定する必要があります。

  • ブラウザ — Google Chrome または Mozilla Firefox の最新の 3 つのバージョン

  • ネットワーク — 接続されたワークステーションあたり 100 Kbps の帯域幅

  • メモリ — 2 GB RAM

  • プロセッサ (CPU) — 2 GHz

ワークステーションのモニタリング

ワークステーションレベルで CCP の機能に影響を及ぼす要因は多数あります。さまざまなレベルのログ情報へのアクセスは、修復に対する手順を決定する上で不可欠です。リソースの競合が発生しているワークステーションにロギングやモニタリングをさらに追加すると、使用可能なリソースは削減され、テスト結果が無効になる可能性があります。ワークステーションは、このガイドの エージェントのワークステーションの要件 セクションに示す最小要件を満たすことをお勧めしたことで、追加リソースはログ記録、モニタリング、マルウェアスキャン、オペレーティングシステム機能などの他の実行中のプロセスでそのまま使用することができます。

相関のために追加の履歴ログとデータソースを収集します。イベントの時刻と問題が報告された時刻との間に相関がある場合は、次の情報を使用して原因を特定できる場合があります。

  • エージェントワークステーション、または同じネットワークセグメント上の同一ワークステーションから Amazon Connect リージョン内にあるエンドポイントへの往復時間 (RTT) およびパケット損失。セキュリティポリシーが原因でリージョンエンドポイントが使用できない場合は、パブリック WAN エンドポイント (www.Amazon.com など) で問題ありません。理想的には、インスタンスエイリアスアドレス (https://yourInstanceName.awsapps.com) とエンドポイントのシグナリングアドレスを使用します。

  • 実行中のプロセス、および各プロセスのリソースの現在の使用状況を示すワークステーションの定期的なモニタリング。

  • これらの領域におけるワークステーションのパフォーマンス/使用率:

    • プロセッサ (CPU)

    • ディスク/ドライブ

    • RAM/メモリ

    • ネットワークスループットおよびパフォーマンス

  • 前述のすべての VDI デスクトップ環境をモニタリングします (エージェントワークステーションと VDI 環境間の RTT/パケットモニタリングを含む)。

ネットワークポートとプロトコル

CCP ソフトフォンには、AWS リソースへの 3 つの接続が必要です。CCP の完全な機能の実現に向けて、双方向通信を可能にするために Amazon Connect インスタンスを作成したリージョン向けに適切なプロトコルを使用して、これらのリソースへのアドレスとポートを開く必要があります。CCP では、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon CloudFront、Amazon Connect の IP 範囲へのアクセスが必要です。詳細については、Amazon EC2 (EC2)、CloudFront (CLOUDFRONT)、または Amazon Connect (AMAZON_CONNECT) の https://ip-ranges.amazonaws.com/ip-ranges.json ファイルを参照してください。新しいリソースが追加されると、このファイル内のアドレス範囲が更新されます。つまり、エージェントが CCP を正常に使用できるように、含まれる範囲をモニタリングし、環境を更新する必要があります。このファイルに追加されてから 30 日後、新しい IP 範囲の使用が Amazon Connect で開始されます。

サービス

Port

プロトコル

コメント

Amazon Connect

3478

UDP イン/アウト

リージョン内のメディアエンドポイント、およびソフトフォンクライアントのコールの音声に使用されます。

Amazon Connect

443

TCP イン/アウト

Amazon EC2

443

TCP イン/アウト

CCP シグナリングエンドポイント

CloudFront

443

TCP イン/アウト

インスタンスに関連付けられたウェブコンテンツのホスティングに使用されます。エンドポイントは、エンドユーザークライアントの場所によって決まります。

また、Amazon EC2 エンドポイントの場合、AWS ipranges.json ファイルに記載されているすべての IP アドレス範囲ではなく、すべての Amazon EC2 エンドポイントが許可されるように、次の URL およびポートへのアクセスを許可することができます。

rtc.connect-telecom.{region}.amazonaws.com:443

{region} を Amazon Connect インスタンスを作成したリージョン (例: us-east-1) に置き換えます。特定のプロキシアプリケーションでは、このアドレスの使用時にウェブソケットの処理によって機能に影響を及ぼす可能性があります。実稼働環境にデプロイする前にテストを実行して検証する必要があります。

CloudFront では、すべての CloudFront エンドポイントのトラフィックが許可されるように、次の URL をポート 443 で使用することができます。AWS ipranges.json ファイルに記載されているすべての範囲を含めずに、この操作を行います: https://myInstanceName.awsapps.commyInstanceName をトラフィックを許可するインスタンスの名前に置き換えます。特定のプロキシアプリケーションでは、このアドレスの使用時にウェブソケットの処理によって機能に影響を及ぼす可能性があるため本稼働環境にデプロイする前にテストを実行して検証する必要があります。

ポートおよびプロトコルに関する考慮事項

Amazon Connect のネットワーク設定変更を実装するときは、次の点を考慮してください。

  • Amazon Connect インスタンスを作成したリージョンのすべてのアドレスと範囲のトラフィックを許可する必要があります。

  • CCP と Amazon Connect の間でプロキシまたはファイアウォールを使用している場合は、エージェントのシフト全体の期間をカバーするように SSL 証明書キャッシュのタイムアウトを延長します。これを行うことで、スケジュールされた作業時間内の証明書の更新に伴う接続の問題を回避できます。たとえば、エージェントが 8 時間作業予定の場合 (休憩を含む)、間隔は、8 時間に休憩や昼食の時間を加えた時間に延長します。

  • ポートを開く際、Amazon EC2 と Amazon Connect では、インスタンスと同じリージョンにあるエンドポイントのみ必要です。ただし、CloudFront では、エージェントの所在地に最も近いリージョンのエンドポイントが必要です。複数のリージョンにエージェントが存在する場合は、エージェントが Amazon Connect CCP を使用している各リージョンのエンドポイントのトラフィックを許可する必要があります。たとえば、インスタンスが米国東部で、エージェントの現住所は別の国である場合は、エージェントの現住所があるリージョンの IP アドレス範囲を使用して、AWS CloudFormation のポートを開く必要があります。

  • 範囲が AWS ipranges.json ファイルで更新されてから 30 日以内にトラフィックが許可される範囲を更新します。更新しない場合、トラフィックは新しい範囲にルーティングされるが、CCP を使用してエージェントに接続できない場合にソフトフォンで CCP を使用すると、断続的な接続の問題が発生する可能性があります。

  • Amazon Connect ストリーム API でカスタム CCP を使用している場合は、Amazon Connect との通信にポートを開く必要がないメディアレス CCP を作成できますが、Amazon EC2 および CloudFront との通信するにはポートを開いておく必要があります。

リージョンの選択に関する考慮事項

Amazon Connect リージョンの選択は、データガバナンスの要件、ユースケース、各リージョンで利用可能なサービス、およびエージェント、発信者、外部転送エンドポイントの地理に関するレイテンシーによって決まります。

  • エージェントの場所/ネットワーク — CCP 接続はパブリック WAN を経由するため、ワークステーションのレイテンシーが最小で、ホップが最小限に抑えられており、特にリソースと Amazon Connect インスタンスがホストされている AWS リージョンが重要です。たとえば、エッジルーターに到達するために数回のホップを行う必要のあるハブおよびスポークネットワークでは、レイテンシーが発生し、通信品質が低下する可能性があります。

    インスタンスとエージェントを設定するときは、インスタンスを作成するリージョンに地理的に最も近いリージョンにインスタンスを作成してください。会社のポリシーやその他の規制に準拠するために特定のリージョンにインスタンスを設定する必要がある場合は、エージェントコンピュータと Amazon Connect インスタンス間のネットワークホップが最小限になる設定を選択します。

  • 発信者の場所 — コールは Amazon Connect リージョンエンドポイントに固定されているため、PSTN のレイテンシーの影響を受けます。発信者と転送エンドポイントが、Amazon Connect インスタンスが最低限のレイテンシーでホストされている AWS リージョンに可能な限り近く配置されてることが理想的です。

    最適なパフォーマンスを実現し、お客様がコンタクトセンターにコールする際のレイテンシーを抑えるために、お客様がコールした場所から地理的に最も近い Amazon Connect インスタンスを作成します。複数の Amazon Connect インスタンスを作成し、お客様がコールした場所から最も近い番号で問い合わせ情報を指定できる場合があります。

  • Amazon Connect からの外部転送 — では、通話中は Amazon Connect リージョンのエンドポイントに固定された状態になります。転送されたコールの受取人によって切断されるまで、使用料は引き続き分単位で発生します。エージェントが離れたり、転送が完了しても、コールは記録されません。転送されたコールの CTR データやそのコール記録は、コール終了後に生成されます。PSTN のレイテンシーが増えないように、可能な限り、コールは Amazon Connect に戻して転送しないでください (循環転送と呼ばれる)。

Amazon Connect をリモートに使用したエージェント

リモートエージェントで、組織のメインネットワークに接続されていない場所から Amazon Connect を使用しており、接続が不安定で、パケットが損失したり、レイテンシーが長い場合、ローカルネットワークに関する問題が発生する可能性があります。この問題は、VPN でリソースにアクセスする必要がある場合、複雑になります。エージェントが AWS リソースと Amazon Connect インスタンスがホストされている AWS リージョンの近くに配置されており、パブリック WAN に安定して接続されていることが理想的です。

オーディオの再ルーティング

既存のデバイスにオーディオをルーティングするときは、Amazon Connect リージョンでのデバイスの位置を考慮してください。これにより、レイテンシーが増える可能性を考慮することができます。音声を再ルーティングすると、エージェントを対象としたコールがある度に、設定されたデバイスに発信されます。エージェントがデバイスに応答すると、そのエージェントは発信者に接続されます。エージェントがデバイスに応答しない場合、エージェントまたは責任者が状態を使用可能に戻すまで、エージェントは不在着信状態に移行されます。

AWS Direct Connect の使用

AWS Direct Connect は、エッジルーターと AWS リソース間のレイテンシーやコール品質の問題を解決するのに役立ちます。また、パブリック WAN を経由するのではなく、AWS トラフィックを専用ファイバにリダイレクトするようにエッジルーターを設定することもできます。これにより、ISP に依存してリクエストを AWS リソースに動的にルーティングするのではなく、永続的で一貫性のある接続が可能になります。ハブアンドスポークネットワークアーキテクチャのようなエッジルーターへのプライベート LAN/WAN トラバーサルに関する問題は解決されない点に注意してください。

VDI 環境での Amazon Connect の使用

仮想デスクトップインフラストラクチャ (VDI) 環境では、ソリューションが複雑になるため、POC の作業とパフォーマンステストを別々にして最適化する必要があります。他の WebRTC ベースのブラウザアプリケーションと同様に、Amazon Connect Contact Control Panel (CCP) は、シッククライアント、シンクライアント、ゼロクライアントの VDI 環境で動作し、VDI サポートチームによって適切に設定/サポート/最適化が行われます。以下は、VDI ベースの顧客に役立つ考慮事項とベストプラクティスをまとめたものです。

  • エージェントの場所 — エージェントが CCP を使用する場所と VDI ホストの場所との間のラウンドトリップ時間をできるだけ短くし、ホップ数を可能な限り少なくすることが理想的です。

  • VDI ソリューションのホストの場所 — VDI ホストの場所が、エージェントと同じネットワークセグメントにあり、内部リソースとエッジルーターの両方のホップ数が可能な限り少ないことが理想的です。また、WebRTC と Amazon EC2 範囲の両方のエンドポイントにできるだけ小さいラウンドトリップ時間を設定することもできます。

  • ネットワーク — トラフィックがエンドポイント間を通過するホップによって、障害やレイテンシーが発生する可能性は高くなります。VDI 環境では、基本的なルートが最適化されていない場合や、パイプが十分に高速または広い場合でも、コール品質の問題が発生しやすくなります。AWS Direct Connect ではエッジルーターから AWS のコール品質は向上しますが、内部ルーティングの問題が解消されることはありません。コールオーディオの問題を回避するには、プライベート LAN/WAN をアップグレードまたは最適化するか、外部デバイスにリダイレクトする必要があります。ほとんどのシナリオでは、これが必要な場合、問題が発生しているアプリケーションは CCP だけではありません。

  • 専用リソース — アクティビティから利用可能なエージェントリソースへの影響を回避するには、ネットワークレベルおよびデスクトップレベルで行うことが推奨されています (例: バックアップ、大規模なファイル転送)。リソース競合を防止するひとつの方法として、異なるリソースを使用する可能性のある他のビジネスユニットとリソースを共有するのではなく、環境を同じように使用する Amazon Connect ユーザーにデスクトップアクセスを制限します。

  • リモート接続を搭載したソフトフォンの使用 — VDI 環境ではオーディオ品質に影響を及ぼす可能性があります。エージェントがリモートエンドポイントに接続してその環境で動作する場合は、オーディオを外部 E.164 エンドポイントにルーティングするか、ローカルデバイスでメディアに接続してからリモート接続でシグナリングすることをお勧めします。カスタム CCP を Amazon Connect Streams API で構築するには、コールシグナリング用のメディアを持たない CCP を作成します。このように、メディアは標準の CCP を使用してローカルデスクトップ上で処理され、シグナリングおよびコール制御はメディアなしで CCP とのリモート接続で処理されます。streams API の詳細については、GitHub リポジトリ (https://github.com/aws/amazon-connect-streams) を参照してください。

CCP 接続

エージェントがログインすると、CCP は AWS ipranges.json ファイルに一覧表示されている Amazon EC2 シグナリングエンドポイント、メディアの場合は Amazon Connect、イメージなどのウェブアーティファクトの場合は CloudFront への接続を試みます。エージェントがログアウトするか、ブラウザが閉じられると、エンドポイントはエージェントの次回ログイン時に再選択されます。Amazon EC2 または Amazon Connect への接続に失敗すると、エラーが CCP に表示されます。CloudFront への接続に失敗すると、ボタンやアイコンなどのウェブ要素だけでなく、ページも読み込めなくなります。

発信通話:

  • 通話が発信されると、イベントシグナルは Amazon EC2 エンドポイントに送信され、Amazon Connect と通信してコールを発信します。ダイヤルが正常に終了したら、エージェントは接続され、エージェントの Amazon Connect エンドポイントへのコールが固定されます。また、コールが切断されるまで、外部転送やカンファレンスでアンカーが使用されます。固定することで、PSTN のレイテンシーを短縮できます。

受信通話:

  • 通話を受信すると、そのコールは Amazon Connect エンドポイントに固定されます。また、コールが切断されるまで、外部転送やカンファレンスでこのアンカーが使用されます。

  • エージェントが利用可能になると、新しい Amazon EC2 接続経由でブラウザにプッシュされ、エージェントに提供されます。

  • エージェントがコールを受け入れ、外部デバイスが応答されたか、CCP で通話を受信できると判断されると、エージェントへのコールメディアに対して Amazon Connect への接続が確立されます。

転送されたコール:

  • コールが転送されると、指定された転送先に通話を発信するシグナルを送信する転送イベントが Amazon EC2 に送信され、Amazon Connect と通信して通話を発信します。

  • コールが接続されると、エージェントはブリッジされ、コールはエージェントの既存の Amazon Connect エンドポイントに固定されます。また、コールが切断されるまで、外部転送やカンファレンスでこのアンカーが使用されます。

  • コールがブリッジされた後にエージェントがハングアップすると、そのコールに対するエージェントの接続は終了しますが、遠方が切断されるまで、Amazon Connect アンカーポイントの Amazon Connect コールはハングします。コールが切断されると、CTR とその録音が生成され、コールに使用できるようになります。

不在着信:

  • コールがエージェントで待機している場合は、エージェントが使用可能になりコールがそのエージェントに正常にルーティングされるまで、お客様キューフローのロジックが使用されます。

  • エージェントがコールを受け付けない場合、エージェントは不在着信状態になり、エージェントまたはコールセンターマネージャーがステータスを再び使用可能に変更するまでコールを受けることはできません。エージェントの受信を待っている間、発信元には呼び出し音は鳴らず、お客様キューフローのロジックで定義されたエージェントに接続されるまで発信し続けます。

パニックログアウト:

  • CCP が実行されているブラウザウィンドウが閉じている場合、コールは接続されたままですが、ブラウザを開いてログインし直した場合、メディア接続を再度確立することはできません。コールを転送または終了することはできますが、エージェントと発信元の間に音声パスは確立されません。

CCP に関する問題のトラブルシューティング

CCP の問題をトラブルシューティングするには、ネットワークオペレーション、システム管理者、および VDI ソリューションチームから、根本的な原因とドライブ解決策を特定するための適切なレベルの情報を収集するサポートが必要です。関与する適切なリソースを判断しやすいように、同様の現象が発生しているユーザーに問題を共有することが重要です。次のガイダンスは、Amazon Connect のお客様がオペレーションサポートチームと CCP の問題を解決するのに役立ちます。

一般的な CCP の問題

Amazon Connect CCP を使用する際に発生する一般的な問題を以下に示します。

  • CCP で初期化/接続できない — 最も一般的な原因は、ポート/IP ホワイトリストのエントリがないため、ブラウザのマイクアクセスを許可していないか、外部デバイスに応答していないことです。このガイドの ネットワークポートとプロトコル セクションで説明しているすべての IP がホワイトリストに登録されていることと、プロンプトが表示された際、ブラウザへのマイクアクセスを許可していることを確認してください。

  • 定期的な接続エラー — 最も一般的な原因として、ネットワークの競合が生じているか、ipranges.json の更新があり、新しいエントリがホワイトリストに登録されていない可能性があります。詳細については、このガイドの「ネットワークポートとプロトコル」セクションを参照してください。

  • 不在着信、状態変更の遅延、CCP 不応答 — ほとんどの場合、これは断続的で、エージェントのワークステーションかネットワーク、またはその両方のリソース競合と直接相関しています。この問題は、プライベート WAN/LAN、パブリック WAN レベル、またはローカルワークステーションリソースの競合で、AWS リソースへの接続が弱い、不安定、または制限によって状況が悪くなる可能性があります。

CCP 使用時のコール品質に関する一般的な問題を以下に示します。通話品質は、潜在的な原因が広範囲に含まれているため、最適な方法で対応するために、直面している問題のタイプを最初に識別することをお勧めします。

  • レイテンシー/クロストーク — 音声接続では、一方が発声し、もう一方に伝わるまでの遅延として作成されます。多くの会話を必要とするユースケースでは、レイテンシーが長くなると、相互に発声している状況が生じることがあります。このシナリオでは、PSTN レイテンシー、エージェントレイテンシー、またはその両方を削減するための要因を特定し、対策を講じるために、PSTN とエージェントのレイテンシーを算出する必要があります。詳細については、このドキュメントの「PSTN とエージェント接続のレイテンシー」セクションを参照してください。

  • 片通話 — エージェント側で発信者の音声が聞こえないか、発信者側でエージェントの音声が聞こえない状態です。通常、エージェントのワークステーションのハードウェア、ネットワーク、リソースレベル、またはこれらの 3 つのすべてにおける問題を示しています。また、ブラウザのマイクのアクセス許可やヘッドセットの問題に関連している可能性もあります。詳細については、このガイドの「ワークステーションのモニタリング」セクションを参照してください。

  • ボリュームの増減 — コールの開始時または断続的に発生する可能性があり、トラブルシューティングを行うためにもこの 2 つを区別することが重要です。通常、これは、サードパーティーの転送に関する問題からこれを継承する Amazon Connect との間の通話転送に関連します。

  • 音声の途切れ、切り取られ、エコー、残響、またはその他のシグナルノイズ — ロボット音やその他のひずみとして発生し、エージェント、発信者、または両者が内容を理解するのが困難になる場合があります。通常、エージェントのワークステーションのハードウェア、ネットワーク、リソースレベル、またはこれらの 3 つのすべてにおける問題を示しています。詳細については、このガイドの「ワークステーションのモニタリング」セクションを参照してください。

  • 振動 — 高いジッタとレイテンシーに対抗するためにオーディオの速度を調整するメディアコーデックの影響をオーディオに及ぼす場合があります。通常、エージェントのワークステーションのハードウェア、ネットワーク、リソースレベル、またはこれらの 3 つのすべてにおける問題を示しています。詳細については、このガイドの「ワークステーションのモニタリング」セクションを参照してください。

  • 切断 — コール中に発生する可能性があります。通話が切断された場合にパターンを識別する際に注意することが重要です。たとえば、特定の外部番号へのコール転送の切断された場合は、通常、サードパーティーの転送の問題から継承した Amazon Connect との間コールの転送に関連しています。また、循環転送に関連している可能性もあります。つまり、Amazon Connect からコールを転送し、同じコールでコールを戻している可能性があります。

便利なトラブルシューティングのツールと情報

Amazon Connect に関する問題のトラブルシューティングには、次のツールと情報が役立ちます。

  • インスタンス ARN — Amazon Connect AWS サポートでインスタンスのアクティビティを確認できるように、お問い合わせの際はインスタンス ARN を記載してください。インスタンスの ARN は、[概要] ページ (Amazon Connect コンソールからインスタンスのエイリアスを選択) で確認できます。

  • 通話の録音 — 報告された動作を表し、特定するだけでなく、エージェント側からの音声の問題を排除します。Amazon Connect の録音は、操作のインスタンス側で行われてから、その音声がエージェントの接続を横断します。これにより、オーディオの問題がエージェント側で解消したか、エージェントが受信したオーディオに存在するかどうかを判断できます。問い合わせに関連付けられた通話記録は、問い合わせの検索レポートで確認できます。

  • CTR の問い合わせ ID — AWS サポートにお問い合わせされる際は記載してください。

  • エージェントのデスクトップパフォーマンス/プロセスログ — ローカルリソース/ネットワークの競合を排除するのに役立ちます。

  • Contact Control Panel のログ — エージェントのアクションとタイミングを追跡します。CCP のログをダウンロードするには、CCP の設定の歯車を選択し、[Download logs (ログのダウンロード)] を選択します。ログは、ブラウザのデフォルトのダウンロードディレクトリに保存されます。

  • ネットワーク使用率のログ記録/モニタリング — 主に、エージェントと同じネットワークセグメント上のレイテンシーおよび削除されたパケットを確認します。

  • プライベート WAN/LAN ネットワーク図 — AWS へのエッジルーターへの接続パスを概説しながら、ネットワークトラバーサルについて説明します。

  • ファイアウォールホワイトリストアクセス — IP/ポート範囲が ネットワークポートとプロトコル に示されているとおりにホワイトリストに登録されていることを確認します。

  • オーディオのキャプチャおよび分析ツール — エージェントのワークステーションからのレイテンシーを算出します。

  • AWS リージョンのレイテンシーテストツールAmazon Connect Call Control Panel 接続ツールなど。

Streams API を使用して役立つ情報を収集します。

大規模な問題を追跡してトラブルシューティングするために、全体的な通話品質に関するデータを収集することをお勧めします。通話品質が良くない場合、エージェントは、次の図に示すように、配置キーチャートを使用して、現在の時刻と対応する配置コードを書き留めることができます。または、Streams API を使用して独自のレポートを組み込み、カスタム CCP に機能を発行して、対応するコール情報とともにこれらの配置をデータベース (例: Amazon DynamoDB) に書き込むことができます。Amazon Connect Streams API の詳細については、GitHub リポジトリ (https://github.com/aws/amazon-connect-streams) を参照してください。

エージェントの問題レポートの配置の例

次の配置キーの例は、現象やシナリオ、および重要度ごとに一覧表示されています。

症状

  • S — ソフトフォンエラー

  • M — 不在着信

  • L — レイテンシーによって生じる品質の低下

  • P — 開始時は問題ないが、時間の経過とともに悪化している

  • D — 通話の切断

  • W — 片通話 (例: エージェント側でお客様の音声は聞こえるが、お客様側でエージェントの音声が聞こえていない状態)

  • V — ボリュームが小さすぎる、または大きすぎる

  • C — 断続的に途切れる

シナリオ

  • O — 発信通話

  • I — 受信通話

  • T — 三者間通話

重要度

  • 1 — 影響 (小)、CCP を効率的に使用できる

  • 2 — 影響 (中)、通信は困難だが通話可能

  • 3 — 影響 (大)。CCP コールを使用することはできません

例:

  • 5:45PM agentName LT2 (三者間通話でレイテンシー、影響: 中)。

  • 6:05PM agentName DO3 (三者間通話で切断、影響: 大)。

  • 6:34 PM agentName MI3 (不在着信、影響: 大)。

データの分析

次のガイドラインは、環境内の問題の特定に必要なデータの分析に役立ちます。

  • CTR/問い合わせ検索レポートを使用して、通話品質の問題が発生した問い合わせの問い合わせ ID を特定します。CTR には、関連する通話記録へのリンクや、現象の確認、AWS サポート担当者に提供するための追加の詳細がそれぞれ含まれています。

  • CTR のエージェント名とタイムスタンプを使用して、発生している問題の種類や、エージェント、現象、シナリオ、および時間の経過に伴う重要度による影響を認識します。これにより、同じ時間に問題が発生しているか、特定のイベントが関連しているか、特定のエージェントまたはエージェントのアクションに特化しているかどうかを確認できます。また、サポートを必要とする場合は、関連する通話記録と関連する問い合わせ ID を簡単に識別してアクセスすることができます。

  • ローカルネットワークログ、CPU/ディスク/メモリ使用率、プロセスモニターログなどのデータソースを、クライアントワークステーションのオペレーティングシステムから相関させます。これにより、時間の経過とともにエージェントがイベントを相関させ、ローカルリソースの競合を原因または寄稿者として排除することができます。

  • 報告された現象およびシナリオによるデータ (時間または分) を分析して、問題のヒートマップをタイプ別および重要度別にエージェントごとに作成します。これは、バックアップや大規模なファイル転送などのスケジュールされたアクティビティに関連するクラスタ化された影響があるため、環境のトラブルシューティングに特に役立ちます。

  • ローカルリソース競合の証拠がない場合や注目すべき相関を導出できない場合は、収集した問い合わせ ID を使用してサポートケースを開くことができます。問題が断続的に発生する場合は、エージェントのワークステーション、ネットワーク接続、またはその両方に関する問題に関連している可能性があります。

検証テスト

音声品質の問題には、関連する多数の原因があります。管理されたテストを実行して、問題を報告している環境やワークステーションと同じ環境やワークステーションをモニタリングし、同じユースケースを再現できることが重要です。音声品質の問題を調査するために、データの測定と収集に関する一般的なテストの推奨事項を検討してください。

PSTN とエージェント接続のレイテンシー

クロストークの問題を解決するには、さまざまな修復作業が必要なため、エージェントおよび未処理の PSTN レイテンシーの対応を区別して測定する必要があります。

  • [overall_latency] は、発信者とエージェントとの間で発生する合計レイテンシーを指します。このレイテンシーは、[overall_latency] = [agent_latency] + [pstn_latency] と計算できます。

  • [pstn_latency] は、Amazon Connect エンドポイントと発信者の間のレイテンシーを指します。このレイテンシーは、[pstn_latency] = [overall_latency] - [agent_connection_latency] と計算できます。このレイテンシーを改善するには、Amazon Connect リージョンの別の場所を使用するか、地理的に離れたエンドポイントの場所への外部転送と循環転送を回避します。

  • [agent_latency] は、Amazon Connect エンドポイントとエージェントの間のレイテンシーを指します。このレイテンシーは、[agent_latency] = [overall_latency] - [recording_latency] と計算できます。オンプレミスのエージェントでこのレイテンシーを改善するには、AWS Direct Connect を使用することで、VPN 接続を使用しない、プライベート WAN/LAN パフォーマンス/耐久性を強化する、エージェントに近い場所の Amazon Connect リージョンを使用するといった対策を行います。ユースケースによっては、別のリージョンを選択しても [pstn_latency] が増えることもあります。

  • [redirect_latency] は、オーディオを外部デバイスにリダイレクトするためのレイテンシーです。このレイテンシーを算出するには、[overall_latency] をリダイレクトした場合としない場合とで 1 回ずつ測定し、その間の差分を計測します。

  • [forward_latency] は、Amazon Connect との間で転送呼び出しを行う際のレイテンシーです。このレイテンシーを算出するには、[overall_latency] を転送した場合としない場合とで 1 回ずつ測定し、その間の差分を計測します。

レイテンシーの測定

  • ユースケースを再生成します。テスト結果に変更が生じるため、偏差を測定して考慮する必要があります。

  • 本稼働の管理と環境を可能な限り一致させます。フロー、電話番号、エンドポイントの場所は同じものを使用します。

  • 発信者、エージェント、および外部転送先の地理的な位置を書き留めます (該当する場合)。複数の国にサービスを提供する場合は、国別にテストし、エージェントが本稼働環境で使用するようにテスト範囲を設定する必要があります。

  • テストでは、モバイルと固定回線の使用に注意してください。モバイルネットワークでは、レイテンシーを増やすことができるため、適用可能な場合は、お客様やエージェント、転送エンドポイントを測定して考慮する必要があります。

  • ビジネスユースケースを再現します。エージェントが会議および転送を使用する場合は、必ずこれらのシナリオをテストしてください。循環転送は推奨されませんが、それらも同様にテストしてください。

  • 同じネットワークセグメント上にあるワークステーション環境を含め、エージェントが使用する機器を使用してエージェント環境を再現します。

レイテンシーのテスト要件

レイテンシーを効率的にテストするには、次のものが必要です。

  • [agent_latency] をキャプチャするために通話記録が有効になっていること。通話記録がない場合は、[overall_latency] のみ計算できます。

  • お客様の電話のソース。テストの場合は、お客様からの実際の通話で通話品質を確認します。

  • エージェントの電話機 (オーディオを外部デバイスにリダイレクトする場合)。このデバイスの入出力を記録できる必要があります。

  • サードパーティーの転送エンドポイント (該当する場合)。テストは、実際の通話またはサードパーティーからの転送で実行される場合に最適です。

  • 録音または解析のソフトウェアが搭載されたエージェントのワークステーション。

  • 再現可能なユースケース。再現できない問題については、トラブルシューティングが難しくなる場合があります。

  • NTP、またはタイムスタンプを同期させて特定の問い合わせや、それらの発生時刻 (特に複数のタイムゾーンでアクティビティが発生した場合) を特定するメソッド。

ソフトフォンを使用した受信通話のテスト

このプロセスでは、レイテンシーのテストシナリオを ~ 15 秒で完了できます。結果の分析とタイムスタンプのマーキングには、1 回の記録につき約 1〜2 分かかります。

  1. 静かな場所に移動します。

  2. 外部のスピーカーからオーディオを再生し、それらが再生されていることを確認できるようにエージェントワークステーションを設定します。

  3. CCP にログインするには、エージェントワークステーションを使用します。

  4. エージェントワークステーションのオーディオキャプチャツールを使用して録音を開始します。

  5. お客様の電話ソースから、スピーカーフォンを使用して Amazon Connect インスタンスの着信番号に発信します。実際には、お客様の呼び出しをシミュレートするための外部の電話ソースを使用する場合があります。

  6. エージェントワークステーションのソフトフォンを使用して着信コールに応答します。

  7. お客様の電話がミュートされていないことを確認します。

  8. お客様側で、オブジェクトや手を使用して、机やテーブルの上を大きく叩いてから、すぐにお客様の電話をミュートします。

  9. 3 秒以上待ちます。少なくとも 3 回、ステップ 7~8 を繰り返します。

  10. エージェントワークステーションの録音を停止します。

  11. オーディオ分析ツールで録音を開きます。机の上で叩いた最初のタッピング音と、もう一方のエージェント回線のタップ音の両方が表示されます。3 つの差分と [overall_latency] の平均値を取得します。

  12. オプションで、[agent_latency] を計算するには、オーディオ解析ツールで関連する Amazon Connect の通話記録を開きます。最初のタップ音と相手側のエージェントに到達したときの両方を音声が表示されます。3 つの差分と [recording_latency] の平均値を取得します ([agent_latency] = [overall_latency] - [recording_latency])。必要に応じて操作を繰り返します。

ユースケースに合わせて、必要に応じてテストプランを変更します。ステップが変わっても、オーディオの録音と分析のプロセスは同じです。会議や転送をテストする必要がある場合は、通常どおり測定を行い、会議がサードパーティーの転送エンドポイントでアクティブになっているときに別の測定を行います。

テスト結果の解釈

[overall_latency] の増加の影響は約 300 ミリ秒で目立つようになり、クロストークが 500 ミリ秒を超えることがあります。影響と、受け入れ可能なレイテンシーのレベルは、ユースケースによって異なります。レイテンシーを短縮するために推奨される修復作業については、「PSTN とエージェント接続のレイテンシー」を参照してください。