この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。
2020/5/29 にPreview としてリリースされたばかりの”Media optimization for Microsoft Teams”を実際に使ってみる話です。 前回の記事ではMedia optimization for Microsoft Teams を設定しました。 今回は実際にTeams 会議 を開催し、正常に動作することや通信帯域の変動、そしてPeer to Peer 通信の詳細などをテストを通して探っていきます。
テスト環境は以下の通り構築が完了しました。 WVD の2台の仮想のWindows 10 に2台のローカルデバイス(物理PC)からサインインし、Teams 会議に参加します。
2台の仮想のWindows 10 にそれぞれサインインしていることを確認します。 今回はSingle-session の条件でテストします。 Multi-session は別途実施予定です。
片方のセッションで Teams desktop app を起動し、会議を開催します。
Calender から “Meet now” を実行します。 日本語UI の場合は予定表 > 今すぐ開催 でしょうか。
会議名を適当に設定し、”Join now” で会議を開催します。
会議の参加者を右のPeople から追加することで、紹介可能です。 ”testuser000″ を招待しています。 以下の画面は2ユーザが会議に参加した状態です。
この時ローカルデバイス側ではWindows のファイアーウォールルールの追加設定が求められます。 “msrdc.exe” に対する許可設定ですのでローカルデバイス間のpeer to peer 通信で利用するものでしょう。 許可します。
今回のテスト環境では1台のローカルデバイスがカメラを持っていません。 継続的な通信が発生するようにカメラを持たないローカルデバイスから接続したセッションではYoutbe の動画を再生しているChrome をTeams 会議の中で画面共有しています。
この状態で通信状況をWireshark で確認します。 Wireshark の実行元のローカルデバイスは 192.168.0.38、もう1台のローカルデバイスは19.168.0.49 です。
Destination Port 7680 のTCP 通信を行っています。 ただこれは Teams の通信とは思えません。 7680 は Windows 10 の配信の最適化で利用するポートだからです。 紛らわしいので 配信の最適化をローカルデバイス側で無効化しておきます。
配信の最適化を停止したあとは2台のローカルデバイス間でのPeer to Peer 通信は確認出来ません。
リソースモニターで リモートデスクトップクライアント (msrdc.exe)の通信先を確認します。 Peer to Peer の対象は 192.168.0.49 となりますが、その宛先の通信はありません。 Wireshark の結果とこのリソースモニタの結果を見る限りローカルデバイス間でのPeer to Peer での通信は行っていないようです。
切り分けで2台のローカルデバイスでWindows 標準のファイアウォールを無効化して再度会議を開催しなおしてもPeer to Peer の通信は確認出来ず。
下の図でいう赤線部分の通信が発生すると想定していたのですがそのような通信が見つかりません。
結論から言うとローカルデバイス間のPeer to Peer の通信を確認することが出来ました。 上でテストしたTeams 会議は複数人全体のためPeer to Peer にはならず、Teams 通話を1対1で行った場合はローカルデバイス間でPeer to Peer 通信が行われることを確認しました。
Teams 通話中のパケットキャプチャが以下です。2台のローカルデバイス（192.168.0.38 と 192.168.0.49)間でUDP による通信を行っています。
ローカルデバイスをリソースモニタで見ていきます。 CPUリソースを消費順にソートします。 もっともCPUリソースを使っているのはリモートデスクトップクライアント(msrdc.exe)です。 これはMedia optimization の1つの役割であるデコードとレンダリングを仮想のWindows 10 からローカルデバイスにオフロードした結果です。
ネットワークについても対抗のローカルデバイスとなる”LIFEBOOK”と通信していることも確認できます。 ローカルデバイス間でPeer to Peer 通信しているということです。
本当はMedia Optimization を無効にした環境とで比較するのがよいのですが、今回は時間切れです。
まとめです。 2020/5/29 にPreviewリリースされたMedia optimization for Microsoft Teams を利用することで以下の2つの最適化が行われることを確認出来ました。
- デコードとレンダリングを仮想のWindows 10 からローカルデバイスへオフロード
- Teams 通話はローカルデバイス間はLANを経由してPeer to Peer 通信
一方、今回のテストから以下のような実際の運用に際して注意が必要な事柄もわかってきました。 もちろん今回は簡易なテストなのでもっとしっかりとした条件設定と内容でテスト結果の精度を上げる必要はありますが。
- ローカルデバイスのCPU処理負荷 （CPU 1core分相当、他処理含めて4core 搭載PCで50%を超えるCPU使用率も確認。）
- Peer to Peer となるのは1対1のTeams 通話などに限定。 Teams 会議では参加者が2名だけの場合でもPeer to Peer にはならず
- Peer to Peer 通信ではCamera （参加者の顔など）の通信だけで2Mbps の帯域消費（仮想のWindows 10 の画面転送通信＋ローカルデバイス間の通信）
- Peer to Peer 通信ではUDP のHigh port を使用。 （以下の青線部分）
次の記事ではMulti-session でのテストか、その前にMedia optimization を無効にしたときと有効にした時のCPUやネットワークリソースの消費の比較をやる予定です。
以下は、Peer to Peer 通信の問題が解決するまでに色々調べたりしていたことです。 書きっぷりも解決する前の状態で書いています。上の結論だけみれば良い話なので興味がある人は見てみてください。ほぼ自分の備忘ログです。
手順に漏れがないか公式ドキュメントを読み直すことにします。 とりあえず前提条件となりそうな事項をリストアップし再確認します。
マニュアルに記載のある事柄はすべて実施していることを確認出来ました。
ローカルデバイス間のPeer to Peer 通信は私が勝手に”存在する”と思い込んでいるだけかもしれません。
Media Optimization を説明する部分をマニュアルで再度探していきます。まずはマニュアルの冒頭の赤枠の部分です。 “With media optimization for Microsoft Teams, the Windows Desktop client handles audio and video locally for Teams calls and meetings. ” とのことで、Teams 通話と会議をローカル側で処理できるとあります。 ただ、具体的にどう処理されるのかは説明はありません。
次に参考になるのは”Teams for Virtualized Desktop Infrastructure” です。
以下のブロックでは”Currently, Teams on VDI with audio/video (AV) optimization is certified with Citrix. ” とあるようにOptimization はCitrix Virtual Apps and Desktops でCertified されているとあります。 まあこれは以前からの話ですし、今回の5/29 リリースの”Windows Virtual Desktop Media optimization for Microsoft Teams” は別に考えてよいでしょう。
もっとも気になるのは”Teams on VDI with calling and meetings“です。 Citrix でのアーキテクチャ図なので今テストしている”Windows Virtual Desktop Media optimization for Microsoft Teams”と一緒なのかもわからないのですが、基本的な考え方は大きく違わないのではと考えます。 Citrix の場合は 仮想のWindows 10 とローカルデバイス間をWebRTC で音声とビデオをストリーミングする構成です。
上の情報だけだとよくわからないので Citrix のドキュメントを確認します。
Citrix 利用時の最適化となりますが、その最適化の内容が具体的に何点か説明されています。
- ローカルデバイス側でのデコーディングやレンダリング
- 仮想のWindows 10 のCPUリソースを減らす
- その分ローカルデバイス側で処理（デコード、レンダリング）する
- 会議など複数人での通話、ビデオはPeer to Peer ではない
- 1対1の通話ならPeer to Peer
- ローカルデバイスからクラウド上のMicrosoft Teams サービスと通信するケースもある
上記ドキュメントの中にあるYoutube 動画がCitrix におけるTeams 最適化の効果を知るのにわかりやすかったです。 CPU消費の変化を具体的に動画の中で紹介していました。
以下のブロックでは会議やマルチパーティ通話ではPeer to Peer ではなくローカルデバイスとクラウド上のTeams サービスが通信するとも読み取れます。 私がテストしたのはTeams 会議だったのでそもそも Peer to Peer にならなかったのかなと思い始めました。 1対1の通話ならどうなるか気になります。
以下のブロックでの説明では可能であればという条件付きでCitrix Workspace アプリ（WVD でいえばリモートデスクトップクライアントに相当）でローカルデバイス間で通信するとのこと。
Microsoft Docs 掲載のものより詳細なアーキテクチャ図もあります。 オレンジ色の”New HDX Component” の処理はローカルデバイスへの処理のオフロード（デコード、レンダリング）部分になると思います。 ⑨の通信フローはローカルデバイスから他のローカルデバイスへの通信またはクラウド上のTeams サービスへの通信ですね。 これのWindows Virtual Desktop Media Optimization for Microsoft Teams 版が欲しいです。というか作ろうとしているが思ったより難航しているところでした。
- Microsoft Teamsを起動します。
- TeamsがO365に対する認証を行います。テナントポリシーがTeamsクライアントにプッシュダウンされ、関連するTURNおよびシグナリングチャネル情報がアプリに中継されます。
- TeamsはVDAで実行されていることを検出し、Citrix JavaScript APIへのAPI呼び出しを行います。
- Teams内のCitrix JavaScriptは、VDA上で実行されているWebSocketService.exeへのセキュアなWebSocket接続を開き（127.0.0. 1:9002）、ユーザーセッション内で実行されるWebSocketAgent.exeを起動します。
- WebSocketAgent.exeは、Citrix HDX Teamsリダイレクトサービス（CtxSvcHost.exe）を呼び出すことによって、汎用仮想チャネルをインスタンス化します。
- Citrix Workspaceアプリのwfica32.exe（HDXエンジン）は、Teamsの最適化に使用される新しいWebRTCエンジンであるHdxTeams.exeという新しいプロセスを生成します。
- HdxTeams.exeとTeams.exeは、双方向仮想チャネルパスを持ち、マルチメディア要求の処理を開始できます。—–ユーザー呼び出し——
- ピアA が 呼び出し ボタンをクリックします。Teams.exeはOffice 365のTeamsサービスと通信し、ピアBとのエンドツーエンドのシグナリングパスを確立します。Teamsは、サポートされている一連の呼び出しパラメーター（コーデック、解像度など、セッション記述プロトコル（SDP）サービスとして知られています）をHdxTeamsに要求します。これらの呼び出しパラメーターは、Office 365のTeamsサービスへのシグナリングパスを使用して、そこから他のピアに中継されます。
- SDPオファーまたは応答（シングルパスネゴシエーション）はシグナリングチャネル経由で実行され、対話型接続確立（ICE）接続チェック（Session Traversal Utilities for NAT（STUN）バインド要求を使用したNATおよびファイアウォールトラバーサル）が完了します。次に、Secure Real-time Transport Protocol（SRTP）メディアは、HdxTeams.exeと他のピア（または会議の場合はOffice 365会議サーバー）の間で直接やり取りされます。
あとは海外のブログなども色々見て周りました。 3つほどピックアップして紹介します。
Christiaan Brinkhoff さんのサイトでは media optimization for Microsoft Teams の導入手順が紹介されています。
以下の概念図も紹介されており、この方もローカルデバイス間のPeer to Peer 通信はあるとのこと。 ただ、具体的にどのような通信が行われるかまでの情報の紹介はまだありませんでした。
以下のサイト でもWVD でのAudio / Vide redirection （Media optimization for Microsoft Teams のこと）について導入手順等詳しく解説していました。 FSLogix についても細かく解説しているのがかなり有用です。 このサイトで言及されていましたがTeams のインストールタイプやキャッシュ構成によるディスク容量の多大な消費をどう扱うかはしっかりと考えないといけないことに気づきました。
“WVD COMMUNITY WEBSITE” ではWVD に関する最新情報を1週間単位でまとめて共有されています。 とりあえずここを見ておけばよいのではと思うくらい充実しています。
その中で”Myself and Stefan tested it this morning and we were both blown away by how good it was. I could see the redirection working perfectly with the CPU usage and bandwidth both being consumed on my local device instead of the WVD Desktop. AWESOME job Microsoft!!” と自分自身でのテスト結果について仮想マシンからローカルデバイス側へCPU使用率と帯域幅消費がオフロードされたことをコメントしていました。
ここまで。
