ネットワークの品質が低下した時の Amazon Connect での通話を体験してみる

皆さん、こんにちは。Amazon Connect アドベントカレンダー 2024、24日目の記事です！
他の方は Amazon Connect の新機能についてたくさん取り上げているので、今回わたしはあえてそれ以外のテーマを記事にしてみたいと思います。


## はじめに

Amazon Connect の CCP（Contact Control Panel）での通話品質には、通話に使う PC と Amazon Connect の間のネットワーク品質が極めて重要であることはご存知かと思います。Amazon Connect 管理者ガイドの [Contact Control Panel を使用するためのエージェントヘッドセットとワークステーションの要件 (CCP）](https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/ccp-agent-hardware.html)ページには「ワークステーション（PC）一台あたり 100kbps の帯域幅が最小要件である」と書いてあります。これは Amazon Connect に限らず、多くの VoIP（Voice over IP）システムが求める通信要件に共通する値でもあります。では、Amazon Connect の利用者は帯域幅だけに注目すればよいのでしょうか？ というと、もちろんそれだけでは足りなくて、Amazon Connect の CCP で快適な通話品質を確保するには、利用するネットワークのレイテンシ、 ジッタ（ゆらぎ）、パケットロスの3つが重要になってきます。たとえば、レイテンシが大きい場合、相手の声は遅れて聞こえるようになるため、とても会話がしづらくなります。ネットワークの品質によらず、遠くのリージョンの Amazon Connect を使えば当然レイテンシは大きくなりますので、できるだけ近くのリージョンの Amazon Connect を利用することを検討しましょう。また、パケットロスやジッタが大きくなると通話は途切れ途切れに聞こえるでしょう。
では、Amazon Connect を快適に利用するためには、具体的にどれくらいのレイテンシ、ジッタ、パケットロス を目安にすると良いのでしょうか？これは、利用者の感じ方や、普段使っている通話インフラやアプリケーションの品質との比較にもよると思いますが、[Amazon Connect 運用ワークショップ](https://catalog.workshops.aws/amazon-connect-operational-workshop/ja-JP) の [ネットワーク要件](https://catalog.workshops.aws/amazon-connect-operational-workshop/ja-JP/7amazonconnectagentoperations/2networkrequirements) のページでは以下の値を目安として紹介しています。

* レイテンシ（往復時間）：300ms 未満
    * ちなみに、ITU-T G.114 では 150ms 未満を推奨しています
    * 日本国内で構築・運用するVoIpシステムでは 100ms 未満を目安とすることが多いように思います
* ジッタ：30ms 未満
* パケットロス：平均 2% 未満


しかし、コンタクトセンターにとって通話品質は重要であり、そのインフラを預かる皆さんとしては、本当に上記の値をクリアしていれば、通話品質は問題ないと自信を持てるでしょうか？ 2%もパケットを失っても、通話品質に問題はないのでしょうか？

というわけで、この記事では上記のようなネットワーク損失をシミュレートして、その時の通話品質を実際に体験する方法をご紹介したいと思います。


## Chrome の開発者ツールでネットワークの品質をシミュレーションする方法

Chorme の開発者ツールを使うと、ネットワークの帯域やレイテンシ、[WebRTC アプリケーションのパケットロスなどをシミュレート](https://developer.chrome.com/blog/new-in-devtools-124?hl=ja#throttling)することができます。Chrome を起動したら、開発者ツールを開いてネットワークのタブに移動してください。さらに「スロットリングなし」の横の▼を押します。
![スクリーンショット 2024-12-21 18.08.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/361a9524-3e35-03db-a477-e00c2bdc182e.png)

「追加」を選択し、「カスタム プロファイルを追加」を選択します。
![スクリーンショット 2024-12-21 18.12.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/ed14fc95-d6a5-020a-7e63-e6045fdb0065.png) ![スクリーンショット 2024-12-21 18.14.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/fb8c148d-fe8e-5f06-6fe5-4477ddbca975.png)

適当なプロフィール名をつけて、各オプション値を設定します。


## テスト1: 最低要件の通信帯域で確認してみる

以下のようなカスタムプロファイルを作ってみましょう。
![スクリーンショット 2024-12-21 18.20.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/08f02a67-d0d9-8eb0-aaba-609d99c40fcd.png)

プロファイルを追加したら右上の x を押して、開発者コンソールのネットワークタブに戻ります。そして、今追加した「100kbps/100kbps」スロットリングプロファイルを選択します。これで、この Chome 上の通信帯域は Amazon Connect の最低要件を満たす、上り・下り共に 100kbps にスロットリングされます。（プロファイルが適用されると、“ネットワーク”タブの左端に “!” アイコンが表示されます。）
![スクリーンショット 2024-12-21 18.32.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/5f20b827-9382-d343-f50d-67b98b1454da.png) ![スクリーンショット 2024-12-21 18.33.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/7941a2a3-1c0b-cba8-fa51-d90a18b40d5c.png)

この状態で、Amazon Connect の CCP でテスト通話をしてみましょう。あとで通話状態を確認できるように録音を有効にすることをおすすめします。ただし、Chrome のスロットリングでシミュレートできるのは Amazon Connect と CCP 間の通信であることに留意してください。
![スクリーンショット 2024-12-22 7.42.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/e7be3acb-361f-a3c7-d537-2509ac1ec82e.png)

つまり、Amazon Connect の録音でスロットリングの影響を確認できるのはエージェントの音声（上りの通信）ということになります。ですので、このテストで Amazon Connect の録音を確認する場合はエージェントの音声に注目するとよいでしょう。（下り通信のスロットリングの影響は録音では確認できないので、CCP 上で聞いた音声などで確認する必要があります。）

さて、上り・下りの通信を 100kbps にスロットリングした場合の通話の結果はどうでしたか？特に問題なく通話ができていたのではないかと思います。



## テスト2: レイテンシを調整してみる
次に、レイテンシを色々変えてみて通話試験をしてみたいと思います。まず、レイテンシが 150ms 程度の場合をテストしてみましょう。以下のようなプロファイルを作成して、CCP でテスト通話をしてみましょう。
![スクリーンショット 2024-12-22 11.23.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/ff2ffb42-fd24-2a60-b08c-8121a1736218.png)

どうですか？これも特に問題なく通話できたのではないでしょうか？

次に、レイテンシを300msにして、テスト通話をしてみましょう。
![スクリーンショット 2024-12-22 11.23.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/4786012b-d39c-5a54-d17d-180a5f5afc3c.png)

もし、あなたが自分一人だけでテスト通話をしている場合は、レイテンシの影響はちょっと感じにくいかもしれません。そういう場合は、顧客役の携帯電話はマイクをミュートして、エージェント役の CCP は手元の時計を見ながら秒をカウントしてみてください（例：10時00分1秒、2秒、３、４、５、６、、、）。それを顧客役の携帯電話で聞くと、レイテンシを大きくした場合に声が遅れて聞こえることがわかるかと思います。もし、わかりにくい場合は通話中にプロファイルを150msと300msで切り替えながら、秒数をカウントしみてください。300ms の方が明らかに遅延が大きく感じるのではないでしょうか？


## テスト3: パケットロスを試してみる
今度はパケットロスの影響を確認してみましょう。パケットロスが多きくなると、音声は途切れ途切れになっていきますので今度のテストは結果がわかりやすいはずです。まずは、パケットロス2%のプロファイルを作成して、テスト通話をしてみましょう。
![スクリーンショット 2024-12-22 11.22.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/b4c6b9d7-079a-5e9f-cac4-4023cfc3bdb8.png)

これも特に問題は感じられなかったかと思います。この時の CCP ログを [CCP Log Parser](https://tools.connect.aws/ccp-log-parser/index.html) で開いてみると以下のようになります。
![スクリーンショット 2024-12-22 11.28.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/83f16f3d-369d-a370-b1f5-1eb59a3395a2.png)

これをみると、毎秒 1 個程度のパケットロスが生じていることがわかります。CCP では音声を 20ms ごとにサンプリングしているので、1 秒分の音声は 50 パケットになります。これの 2% のロスを設定したので、毎秒 1 パケット程度がロスしているということです。そして、人間の耳では 1 パケット = 20ms 分の音声が欠けてもそれを感じることは難しい、ということがわかります。

それでは次に、思い切って 10% 程度のロスを試してみましょう。プロファイルは以下のようにします。
![スクリーンショット 2024-12-22 11.41.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/bfc866d8-c070-3dc4-82f5-7663c9b47ee5.png)

今度は少し音質の劣化を感じられたのではないでしょうか？たとえば、音が途切れ途切れだったりするように感じられたかと思います。この時の CCP ログを [CCP Log Parser](https://tools.connect.aws/ccp-log-parser/index.html) で開くと以下のようになります。多少ばらつきがありますが、平均して10%程度のパケットロスがあることが確認できます。
![スクリーンショット 2024-12-23 10.32.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944903/b2b326f1-8a65-4ac1-6b70-05ed58a70e40.png)

ついでに、20%も試してみましょう。
さらに途切れがひどくなって、会話がしづらくなったことを確認できたかと思います。



## まとめ

Amazon Connect の利用者（エージェントと顧客の双方）にとって、通話品質は言うまでもなく重要です。そして、通話品質にはネットワークの品質が大きく影響することをこの記事の一連のテストで実際に体感することができたかと思います。ところで、こうしたネットワーク品質は不変ではなく、障害やその他の原因によってその品質は変動します。ですので、本番運用ではネットワークの品質を常時監視することが重要になってきます。上で見たように、Amazon Connect では CCP ログの中に毎回の通話におけるネットワークの品質指標（レイテンシ、パケットロス、ジッタ）を記録しているため、これを収集してモニタリングすることで各端末が利用しているネットワークの正常性を確認し、問題があった時に素早く対処することが可能になります（たとえば、[Operata](https://aws.amazon.com/jp/blogs/apn/operata-service-monitoring-and-assurance-for-cloud-contact-centers-and-amazon-connect/) のような 3rd party ソリューションもあります。）。しかし、このようなモニタリングの仕組みを用意しても、実際にネットワーク品質の低下を起こすことは難しくどうやってそれをテストをするかが課題になってきます。そんな時にも、この記事でご紹介した Chrome の 開発者ツールを利用することでテストを行うことができるかと思います。