Microsoft Teams

Microsoft Teams VoIP監視のエッセンス

2022年4月15日
翻訳: 島田 麻里子

この記事は米Catchpoint Systems社のブログ記事 Essentials of Microsoft Teams VoIP Monitoringの翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。


Microsoft Office 365は、他のツールよりも優位性があります。
Office 365のエコシステムにより、ユーザはリモートワークをしながら簡単に他の人と共同して働くことができます。
ユーザは幅広いソリューションから選択することができ、Office 365は、これらのツール間の容易な統合という、さらなる利点を提供します。

Microsoft Office 365の月間アクティブユーザ数は2億人を超えています。
COVID-19の大流行により、Office 365に依存するユーザは増える一方です。
2020年11月のMicrosoft Teamsのデイリーアクティブユーザは1億1500万人で、同年4月の7500万人から大幅に増加しています。

MS Teamsは、チャット、メディア、ビデオ会議、スクリーンシェア、ファイル共有、および組み込みの統合機能を通じて、個人のコラボレーションを支援し、生産性を向上させることができます。
バーチャルミーティングなど、企業にとって重要な機能は、社員が日常的に多用するものです。

パンデミック状況により、ビジネスミーティング、顧客トレーニング、カンファレンスなどの開催に、MS Teamsは欠かせない存在となっています。
リモートワークの従業員にとって、良好な従業員体験を確保することが重要になってきました。

MS Teamsなどのビジネスクリティカルなツールのパフォーマンスを企業が監視できるように、Catchpointは新しいカスタムモニタを構築しました。
カスタムモニタは、MS TeamsのVoIPコールの状態を追跡し、パフォーマンスの低下が検出された場合に通知します。

重要なVoIPのパフォーマンス指標

このカスタムモニタのセットアップと内部動作を深く掘り下げる前に、VoIPコールのパフォーマンスを可視化するために必要なコア・パフォーマンス指標を明確に理解する必要があります。
これらの指標により、VoIPコールの品質を評価することができ、次のような質問に答えることができるはずです。

このような問題を念頭に置き、VoIPの通話品質を測定するために不可欠な3つの指標、ラウンドトリップタイム、ジッタ、パケットロスを選びました。

ラウンドトリップタイム(RTT)

パケットが送信元から送信先まで往復するのにかかる時間はRTTと呼ばれ、ミリ秒単位で報告されます。
RTTがより低い値を持ち、オーディオセッション全体で安定していることを確認する必要があります。

図1.ラウンドトリップタイム(RTT)の計算
図1.ラウンドトリップタイム(RTT)の計算

ジッタ

ジッタ(揺らぎ)は、特定の時刻に配信されると予想されたパケット間の遅延を元に計算されます。

オーディオセッションにおいてはジッタが重要であり、パケットが配信されていても、エンドユーザ体験に影響を与えます。
ジッタが大きく、パケットの位置がずれると、受信者はメッセージを理解することができなくなります。
ジッタはミリ秒単位で報告されます。

図2.ネットワーク輻輳によるジッタ
図2.ネットワーク輻輳によるジッタ

パケットロス

パケットロスは、ネットワーク上を移動する1つまたは複数のデータパケットが宛先に到達しない場合に発生します。
一般的にワイヤレスネットワークでのデータ伝送のエラーや、ネットワークの輻輳によって引き起こされます。
パケットロスは、失われたパケット数で測定されます。

図3.パケットロス
図3.パケットロス

カスタムモニタの実装を理解する

MS Teams VoIPカスタムモニタは、オーディオセッションの開始、応答と参加、セッションの品質測定の3つの主要なコンポーネントに依存しています。
それぞれの構成要素を見て、技術的な面を理解しましょう。

オーディオセッションの開始

オーディオセッションに参加するために、私たちはMS Teamsの通話ボットに頼っています。
このボットは、ChromeブラウザでMicrosoft Teams Web版を使用して起動されます。

Google Puppeteerを使って、Microsoft TeamsのWeb版にログインして音声セッションを開始するまでのユーザ・ジャーニー全体をシミュレートしています。
これにより、エンドユーザの操作を再現し、WebRTC上でオーディオセッションを開始することができます。

WebRTCは、Webやネイティブアプリケーションで音声、映像、データ通信をリアルタイムに行うためのオープンソースプロジェクトです。
Microsoft TeamsのWebクライアントとネイティブアプリは、音声とビデオの通信にこのWebRTCを利用しています。

オーディオセッションへの応答・参加

Catchpointスクリプトからの呼び出しを自動で受け付けるために、Azure上のボット、Node 12 LTSを搭載したLinux環境を使用します。
すべての着信を処理するために、アプリはMicrosoft Graphs Communications APIを使用しています。
このボットは、Catchpointスクリプトから開始された通話に確実に応答し、通話品質を分析するためのオーディオセッションメトリクスを取得することを可能にします。

オーディオセッションの品質測定

オーディオセッションが確立されると、オーディオセッションのパフォーマンス情報を収集するために、chrome://webrtc-internalsに依存します。
これにより、ラウンドトリップタイム、パケットロス、ジッタなど、進行中のWebRTCセッションに関するメトリックスを収集することができます。

カスタムモニタの実行フロー

図4.カスタムモニタアーキテクチャ
図4.カスタムモニタアーキテクチャ
  1. Catchpoint Portalは、エンタープライズ・ノード上でカスタム・スクリプトを開始します。
    スクリプトファイル名など、スクリプトに関連する詳細をノードに渡し、実行させます。
  2. Catchpoint Linuxのノードには、カスタムスクリプトが配置されます。
    関連する依存関係はすべて事前にインストールされています。
  3. Google Puppeteerを利用するためにNodeJSスクリプトを起動し、Microsoft Teamsの呼び出しを開始します。
    この呼び出しは、Azureにホストされているボットによって自動的に受け入れられます。
  4. また、このスクリプトは、進行中の WebRTC セッションのメトリクスを保持する新しいクロームタブで chrome://webrtc-internals を起動します。
    これらの指標はCatchpointに報告され、インサイト機能で取り込まれ、様々なチャートにプロットされます。
  5. Azure Nodejs Appは、ボットを構築するためにMicrosoftのBot Builderフレームワークを使用しています。
    Botからの呼び出しを自動で受け付けるために、アプリはMicrosoftのグラフAPIを使用しています。

セットアップが完了したら、総合ダッシュボードでカスタムモニタが収集したデータを視覚化することができます。
下のスクリーンショットでは、右上に3つの重要な指標が表示され、それぞれの平均値が表示されています。

また、各指標を時系列で強調表示することで、急上昇や急降下をすぐに確認することができます。
上記の3つの指標以外にも、送受信された総バイト数、総テスト時間を収集しています。

図5.Microsoft Teams監視のためのCatchpointダッシュボード
図5.Microsoft Teams監視のためのCatchpointダッシュボード

まとめ

VoIPには驚くべき進歩があり、インターネット上でのオーディオ品質を向上させました。
しかし、パケットロスは依然として大きな問題であり、性能に影響を及ぼしています。
パケットロスが多いと、オーディオセッションの品質が低下し、通信に支障を来たします。

ジッタは、パケットは配信されるものの、期待される時間や順序とは異なってしまう、もう一つの要因です。
これによって音声は歪み、理解しにくくなるため、エンドユーザにとっては非常に迷惑な話です。

リアルタイム通信を計測する場合、ラウンドトリップタイムが重要になります。
高音質のためには、オーディオセッション全体のRTT時間が低く安定していることが必要です。

Microsoft Teamsのカスタムモニタは、エンドユーザ体験の評価やオーディオセッションの品質測定に最適な方法です。
パフォーマンスの劣化を把握・分析し、エンドユーザ体験に変化があった場合にアラートを発することができます。