悲惨な Teams タウンホールミーティング – その経緯 OfficeExpert TrueDEM 原因の特定に役立ちました

通話不良が発生しているユーザーをサポートする際に最も難しく、最もイライラすることの 1 つは、すべての正しい情報を収集することです。通話中にユーザーが体験する内容に影響を与える可能性のある可動部分は非常に多くあります。認証から、デバイスと周辺機器、ローカル ネットワーク、ISP、そして Microsoft クラウド自体に至るまで。すべてが通話の品質に影響を与える可能性があります。これらすべてに、通話の参加者の数を掛けます。問題は、それを経験している参加者に起因する必要はないからです。

不正な通話に対処することがいかに難しいかをよく目にしますが、以下の例も例外ではありません。そこで、何が起こっているのかを把握することがいかに複雑であるか、そしてユーザー エクスペリエンスの監視が原因の特定にどのように役立つかを説明しましょう。

大規模なチーム 会館、学習センター等でのミーティング、会合、食事会、意見交換会、慈善活動等 ある顧客で約 500 人の参加者を集めて計画されました。
出席者は自宅とオフィスの両方から、さまざまな場所やタイムゾーンから参加していました。
主催者は全員同じオフィスに集まりました。

会議が始まり、主催者が出席者のミュートを解除するまではすべてが順調でした。画面上のディスカッションに参加させます。ミュート解除が機能しなかったようで、その代わりに突然、音質が劣化し始めました。参加者らは12～15分間、耳が聞こえない、何が起こっているのか理解できないと訴えていた。これを 500 人の出席者と比較すると、100 時間以上の潜在的な生産性損失が発生することになります。当然のことながら、これは経営幹部さえも注目するほどの大騒動を引き起こしました。その結果、IT 部門は何が起こったのかを調査することになりました。

用いて OfficeExpert TrueDEM、私たちはこの悲惨な Teams タウンホールコールを見て、何が起こったのか、そして PR のために何ができるのかを見ていきます。event それが再び起こらないようにします。

Microsoft Teams の通話や会議では、音声の問題が画面共有やビデオに関する問題よりもはるかに大きな影響を与える傾向があるため、音声品質は非常に重要です。ぼやけたビデオは、それはそれで迷惑ですが、しばらくは許容できる場合があります。音質が悪いと、そのトラックでの通信が停止する可能性があります。結局のところ、姿が見えなくても声が聞こえれば、コミュニケーションをとることができます。あなたの声が聞こえなかったり、音声が文字化けしたりすると、コミュニケーションは不可能になります。おそらくあなたが手話を知らない限り。私たちのほとんどが知らないことです。

分析に戻りましょう。 Microsoft Teams の通話を理解して分析するには、テクノロジを理解する必要があります。 Microsoft Teams が音声、ビデオ、その他のデータを送信する方法。

通話を送信するために、Microsoft Teams はさまざまな入力 (オーディオ、ビデオ、画面共有、アプリケーションなど) を個別のストリームに分割します。それらを再度分割すると、 本国行きの (クラウドから受け取るもの) ストリームと 外国行きの (クラウドに送信するもの) ストリーム。内容に応じて、これは少量のオーディオ、ビデオなどを表す小さなパケット (フレーム) にさらに分割されます。このようにして、送信される個々のパケットのサイズは最小限になります。つまり、もし パケットが失われる、影響は最小限に抑えられます。

Microsoft Teams は、毎秒の音声を次のように送信します。 それぞれに最大 50 ミリ秒の音声コンテンツを含む 20 フレームのシーケンス OfficeExpert TrueDEM リアルタイム プロトコル パケット (フレーム) を 30 秒間隔で両方向に追跡します。したがって、積極的に話す出席者の場合、1,500 秒間隔ごとに約 30 の音声パケットが送信されることが予想されます。これはビデオや他のパケットとは独立しており、個別に送信されます。

これは Teams のタウンホール会議であり、音声に問題があったため、最初にメイン スピーカーに注目することから始めるのは理にかなっています。結局のところ、この人は、他の人が聞き取りにくい音声の大部分を送信している人でした。

次の写真は午後7時頃の様子です。 （会議の開始）、彼女のデバイスから送信された音声パケットの数は予想されるレベルまで増加し、午後 7 時 51 分 30 秒頃までその状態が続きました。この時点で、送信されるパケットが大幅に減少していることがわかります。これは、他の人が彼女の声を聞くことができなかった理由を説明します。彼女の音声はクラウドに伝わらず、そのため他の参加者にも届きませんでした。

このユーザーの生データを見ると、問題が開始および終了した正確な時点がわかります。システムを通過する音声パケットはほとんどありません。

これは12分近く続きました。これは他のユーザーが述べていることと一致します。

だから今、私たちは正確に知っています いつ これが起こったのですが、何が原因だったのか分かりますか?

まず、ネットワーク接続について見てみましょう。ネットワーク接続が悪いと通話不良が発生することが多いためです。主催者からはネットワークの問題は報告されていませんでしたが、ご存じのとおり、WIFI 接続は不安定であることで有名です。したがって、そこから始めるのは理にかなっています。
データを見ると、アウトバウンド接続速度は時間の経過とともに安定しており、問題が始まった時点でも低下していないことがわかります。

注目に値するのは、音声の問題が発生した前後に、デバイスが大量の受信データを受信したことです (以下の最初のグラフを参照)。

この受信トラフィックの増加は、主に受信ビデオ ストリームによるものと思われます。ビデオパッケージが登場し始めているという事実がそれを証明しています（以下を参照）。

～ 2M ビット/秒の受信ビデオ トラフィックは、受信ビデオ ストリームの受信では正常ですが、2M ビット/秒が 2 ～ 3 分間のみ存在し、その後ほぼゼロに低下するのは興味深いことです。これは、ビデオを送信しているユーザーが単にカメラを閉じただけであることを示している可能性があります。あるいは、ビデオ ストリームもシステムを通過しなくなったということです。

誰がビデオを「送信」したかを確認すると、他に 1 人のユーザーだけがビデオを送信していることがすぐにわかり、そのユーザーがミュートを解除していたことがわかりました。データを見ると、2分後にカメラを閉じただけのようです。したがって、受信ビデオ データのピークは予想どおりであり、他のユーザーがカメラを停止したため、その程度の短時間しか続きませんでした。

では、ネットワークではないとしたら、デバイスで何かが起こったのでしょうか?

次のステップは、メイン スピーカーのデバイスで何が起こっているかを詳しく調べることです。送信パケットのドロップが確認されたユーザー。

こちらを見てみましょう TrueDEM データを見ると、このユーザーは Teams のみを実行しており、他のプログラムはすべて閉じていたことがわかります。 CPU と RAM の使用率は正常の範囲内にあり、12 分間の音声不良を説明できるものは何もありませんでした。実際、問題が発生した前後では、CPU と RAM に目立ったピークは見られませんでした。

周辺機器の入出力デバイスが役割を果たしたのでしょうか?

次に、どのようなキャプチャおよびレンダリング デバイスが使用されているかを見ていきます。次の表は、ユーザーが AV Bridge MatrixMIX と呼ばれる周辺 AV 制作システムを使用して通話を主導していたことを示しています。これは、Teams タウン ホールのような大規模な会議を主導するのに役立つハードウェア ツールで、音声やビデオなどの管理にも役立ちます。

Teams タウン ホール ミーティングの主催者が出席者のミュートを解除しようとしている頃、受信ビデオのレンダリングが開始されることがわかります。これは、ミュートが解除されていた出席者がカメラを起動したことが原因であることはすでにわかっています。したがって、必ずしも期待できないものがあるとは限りません。

しかし、疑わしいのは、これがオーディオに問題が発生し始めるまさにその瞬間でもあるということです。

このような状況に陥った人はおそらくそうでしょうが、話者は問題を解決するためにいくつかのことを試みます。午後8時02分頃にカメラを停止し、オーディオシステムを変更したようです。この瞬間から、システムは AV オーディオ ブリッジの代わりに内部オーディオ (AMD ハイ デフィニション オーディオ デバイス) を使用するようになり、その時点でオーディオ パケットが再び送信され始め、オーディオの問題が解決されたように見えます。

だからした オーディオシステムを停止すると解決しますか、それともカメラがオフになっていたことも要因でしょうか?

(上の表では) 数分後 (~20:07)、AV Bridge システムを使用してカメラが再起動されていることがわかります。音声パケット数に影響を与えません。したがって、メインスピーカーがビデオをオフにしたことがこのケースの要因ではなかった可能性が非常に高いです。

事実に基づいて控除できるのは以下のとおりです OfficeExpert TrueDEM 以下のことを明らかにした：

Teams のタウンホール会議は、ミュート解除された参加者が追加されるまでは正常に機能していました。

その時点で、ビデオとオーディオのメイン スピーカーによって使用される AV 制作システムでオーディオの送信に問題が発生し始めているようです (オーディオ パッケージは 1500 分以内に 0 からほぼ XNUMX に減少します)。それは参加者のミュートを解除したこと、ミュートを解除した参加者がカメラを起動したときに突然受信したビデオ データでしょうか?それとも、おそらく、ありそうもないことですが、同じ瞬間にそれが起こったのは単なる偶然でしょうか？言うのは難しいです。

実際のところ、問題の原因は明らかにメイン スピーカー (出力オーディオ パッケージではない) にあり、外部の AV 制作システムに起因している可能性が最も高いです。外部 AV Bridge システム オーディオの使用から内部デバイス オーディオの使用に切り替えると、問題が解決されたようです。

この通話はリハーサルが行われており、参加者のミュートを解除するなど主催者が行ったことはいずれも間違っていなかった。ただし、原因が AV 制作システムである可能性が高く、受信ビデオが原因である可能性が高いことがわかっているため、特定の一般的な推奨事項を作成でき、将来の使用のために検証する必要があることがわかります。