- ホーム
- /
- 投稿記事
この記事の内容新機能および変更された機能に関する情報
この表では、新しい機能や機能、既存のコンテンツへの変更、および導入ガイドで修正された主なエラーについて説明します。
Webex ビデオ メッシュ ノード ソフトウェアの更新については、https://help.webex.com/en-us/article/jgobq2/Webex-Video-Mesh-release-notes を参照してください。
日付 | 変更 |
|---|---|
2024年2月9日。 |
|
2023年8月31日。 |
|
2023年7月31日。 |
|
2023年7月28日。 |
|
2023年6月15日。 |
|
| 2023年5月16日。 |
|
2023 年 3 月 27 日 |
|
2023年3月02日。 |
|
2022 年 7 月 7 日 |
|
2022 年 6 月 30 日 | https://github.com/CiscoDevNet/webex-video-mesh-node-provisioningで新しい一括プロビジョニング スクリプトに関する情報を追加しました。 |
2022 年 6 月 14 日 | Unified CM とビデオ メッシュ ノード間の Exchange 証明書チェーンに ECDSA 証明書を含めるために、証明書チェーンを交換する手順を変更しました |
2022 年 5 月 18 日 | Reflectorツールのダウンロードサイトをhttps://github.com/CiscoDevNet/webex-video-mesh-reflector-clientに変更しました。 |
4月 29,2022 日 | 「すべての外部 Webex ミーティングでメディアをビデオ メッシュに保存する」の新機能に関する情報を追加しました。 |
2022 年 3 月 25 日 | 管理用ポートとプロトコルでのポート使用状況の更新。 |
Decemeber 10、2021 | CMS 2000 を追加し、ビデオ メッシュ ノード ソフトウェアのシステムとプラットフォームの要件で ESXi 7 にアップグレードする古い CMS 1000s のアップグレードの問題を指摘しました。 |
2021 年 8 月 30 日 | Webex が展開の正しいソース国であることを確認するための情報が、「ソース国が正しいことを確認する」に追加されました。 |
2021 年 8 月 27 日 | 分析レポートの可視性に関するプライベートミーティングのサポートと制限のメモを追加しました。 |
2021 年 8 月 13 日 | 次の新しいプライベート ミーティング機能に関する情報を追加しました。
|
2021年7月22日。 | システムがコールの正しい発信元の場所を持っていることを確認する方法に関する情報を追加しました。 正しいソースロケーションは、効率的なルーティングに役立ちます。 「原産国が正しいことを確認する」を参照してください。 |
2021 年 6 月 25 日 | Webex アプリのフル機能 Webex エクスペリエンス機能は、ビデオ メッシュ ノードを使用するクライアントとデバイスのビデオ メッシュと互換性がないことに注意してください。 |
2021 年 5 月 7 日 | ビデオ メッシュ クラスタ展開のガイドラインで推奨されるクラスタ サイズを 100 に修正しました。 |
2021/04/12 | 新しい DNS ゾーンではなく、Webex ゾーンを使用するようにビデオ メッシュの Expressway TCP SIP トラフィック ルーティングの設定 を更新しました。 |
2021 年 2 月 9 日 |
|
2020年12月11日 |
|
2020/10/22 |
|
| 2020年10月19日水曜日 |
|
| 2020/09/18 |
|
| 2020 年 8 月 26 日 |
|
2020年8月4日（火） |
|
| 2020 年 7 月 9 日 |
|
2020 年 6 月 26 日 |
|
| 2020 年 6 月 9 日 |
|
| 2020年5月21日水曜日 | 管理用のポートとプロトコルとビデオメッシュのプロキシサポートの要件を更新しました。 |
| 2020 年 5 月 15 日 | ビデオ メッシュの概要を更新しました。 |
| 2020年4月25日。 |
|
2020 年 1 月 22 日 |
|
2019 年 12 月 12 日 |
|
2019/12/10 |
|
2019 年 11 月 4 日 |
|
| 2019 年 10 月 18 日 |
|
2019 年 9 月 26 日 |
|
2019 年 9 月 13 日 |
|
| 2019 年 8 月 29 日 |
|
2019年7月24日。 |
|
2019年7月9日水曜日 |
|
2019 年 5 月 24 日 |
|
2019 年 4 月 25 日 |
|
2019 年 4 月 11 日 |
|
Webex ビデオ メッシュの概要
Webex ビデオ メッシュ は、状況に応じてオンプレミスとクラウドの会議リソースの最適な組み合わせを見つけます。 オンプレミス会議は、十分なローカルリソースがある場合、前提にとどまります。 ローカルリソースが消耗されると、電話会議はクラウドまで展開します。
ビデオ メッシュ ノードは、オンプレミスの Cisco UCS サーバーにインストールされ、クラウドに登録され、Control Hub で管理されるソフトウェアです。 2 人の間の Webex ミーティング、Webex パーソナル会議室、Webex スペース ミーティング、Webex アプリの通話は、ローカルのオンネット ビデオ メッシュ ノードにルーティングできます。 ビデオ メッシュは、利用可能なリソースを使用する最も効率的な方法を選択します。
ビデオ メッシュは、次の利点を提供します。
通話はオンプレミスで保管できるので、品質が改善され、遅延が軽減されます。
オンプレミス リソースが上限に達したり、利用不可能になったりした場合、通話はクラウドに透過的に延長されます。
単一の管理インターフェイスでクラウドからビデオ メッシュ クラスタを管理します。 Control Hub (https://admin.webex.com ) を選択してください。
リソースおよびスケール容量は、必要に応じて、最適化することができます。
クラウドの機能とオンプレミス電話会議を 1 つのシームレスなユーザー エクスペリエンスに統合します。
クラウドはより多くの会議リソースが必要な場合でも常時使用可能なため、容量の懸念が払拭されます。 最悪のシナリオでは、容量計画を行う必要はありません。
https://admin.webex.comの容量と使用状況、およびレポートデータのトラブルシューティングに関する高度な分析を提供します。
ユーザーがオンプレミスの標準ベースの SIP エンドポイントとクライアントから Webex ミーティングにダイヤルインするときに、ローカルメディア処理を使用します。
Cisco Webex ミーティングにコールインするオンプレミスのコール制御（Cisco Unified Communications Manager または Expressway）に登録された SIP ベースのエンドポイントとクライアント（Cisco エンドポイント、Jabber、サードパーティの SIP）。
Webex ミーティングに参加する Webex アプリ (会議室デバイスとのペアリングを含む)。
Webex ミーティングに直接参加する Webex 会議室およびデスクデバイス。
ネット上の SIP ベースのエンドポイントとクライアントに対して、最適化された音声とビデオのインタラクティブ ボイス レスポンス (IVR) 機能を提供することができます。
H.323、IP ダイヤルイン、Skype for Business (S4B) エンドポイントは、引き続きクラウドからミーティングに参加します。
1080p をサポートできるミーティング参加者がローカルのオンプレミス ビデオ メッシュ ノード経由でホストされている場合、ミーティングのオプションとして 1080p 30fps 高解像度ビデオをサポートします。 (出席者が進行中のミーティングにクラウドから参加しても、オンプレミスのユーザーはサポートされているエンドポイントで引き続き 1080p 30fps を使用します)。
強化され、差別化された QoS (Quality of Service) マーキング: 音声 (EF) とビデオ (AF41) の分離。
Webex ビデオ メッシュは現在、Webex Webinars をサポートしていません。エンドツーエンド暗号化ミーティング（E2EE ミーティング）をサポートします。 顧客がビデオ メッシュを展開し、E2EE ミーティング タイプを選択すると、セキュリティが強化され、データ (メディア、ファイル、ホワイトボード、注釈) が安全に保たれ、サードパーティによるアクセスや変更がブロックされます。 詳細については、「ゼロトラストミーティングの展開」を参照してください。
プライベート ミーティングは現在、エンドツーエンド暗号化をサポートしていません。
ビデオ メッシュ ノードを使用するクライアントとデバイス
私たちは、関連するクライアントやデバイスタイプとビデオメッシュを相互運用できるように努めています。 すべてのシナリオをテストすることはできませんが、このデータがベースになっているテストは、リストされているエンドポイントとインフラストラクチャの最も一般的な機能をカバーします。 デバイスまたはクライアントがないことは、テストの欠如と Cisco からの公式サポートの欠如を意味します。
クライアントまたはデバイスの種類 | ポイント ツー ポイント コールでビデオ メッシュ ノードを使用する | マルチパーティ ミーティングでビデオ メッシュ ノードを使用する |
|---|---|---|
Webex アプリ (デスクトップとモバイル) | はい | はい |
会議室デバイスや Webex Board を含む Webex デバイス。 (完全なリストについては、「エンドポイントと Webex アプリの要件」セクションを参照してください。) | はい | はい |
Webex アプリとサポートされている Room、Desk、および Board デバイス間の室内ワイヤレス共有。 | はい | はい |
Unified CM に登録されたデバイス (IX エンドポイントを含む) とクライアント (Jabber VDI 12.6 以降、Webex VDI 39.3 以降)、Webex スケジュール済みまたは Webex パーソナル会議室ミーティングへのコール。* | いいえ | はい |
VCS/Expressway に登録されたデバイス、Webex スケジュール済みまたは Webex パーソナル会議室のミーティングへのコール。* | いいえ | はい |
Webex クラウド登録ビデオ デバイスに Webex マイビデオ システムにコール | 適用なし | はい |
Webex アプリ ウェブ クライアント ( https://web.webex.com) | はい | はい |
Cisco Webex Calling に登録された電話 | いいえ | いいえ |
Webex自分のビデオシステムにコールバックして、プレミス登録されたSIPデバイスへ | 適用なし | いいえ |
*すべてのオンプレミスのデバイスとクライアントがVideo Meshソリューションでテストされていることを保証することはできません。
フル機能の Webex エクスペリエンスとのビデオ メッシュの非互換性
Webex アプリでフル機能の Webex エクスペリエンスを有効にすると、Webex アプリはビデオ メッシュ ノードでサポートされません。 この機能は現在、シグナリングとメディアを Webex に直接送信しています。 今後のリリースでは、Webex アプリとビデオ メッシュが互換性を持つようになります。 デフォルトでは、ビデオ メッシュを使用する顧客に対してこの機能を有効にしませんでした。
ビデオ メッシュとフル機能の Webex エクスペリエンスに問題がある可能性があります。
その機能の導入後に導入にビデオ メッシュを追加した場合。
ビデオ メッシュへの影響を知らずにこの機能を有効にした場合。
問題が発生した場合は、Cisco アカウント チームに連絡して、フル機能の Webex エクスペリエンス トグルを無効にします。
ビデオ メッシュ ノードでのサービスの質
ビデオ メッシュ ノードは、ビデオ メッシュ ノードとのすべてのフローで音声とビデオ ストリームを区別できるポート範囲を有効にすることで、推奨される Quality of Service (QoS) のベスト プラクティスに準拠します。 この変更により、QoS ポリシーを作成し、ビデオ メッシュ ノードとの間の送受信トラフィックを効果的に区別することができるようになります。
これらのポートの変更に伴い、QoS の変更も行われました。 ビデオ メッシュ ノードは、オーディオ（EF）とビデオ（AF41）の両方に対して、SIP 登録済みエンドポイント（オンプレミスの Unified CM または VCS Expressway が登録済み）からのメディア トラフィックを適切なサービス クラスで個別にマークし、特定のメディア タイプによく知られているポート範囲を使用します。
オンプレミスの登録済みエンドポイントからの送信トラフィックは常に、通話コントロール (Unified CM または VCS Expressway) 上での構成に基づいて決定されます。
詳細については、ビデオ メッシュで使用されるポートとプロトコルのQoS表と、ビデオ メッシュ展開タスク フローでQoSを有効または無効にする手順を参照してください。
Webex アプリは、共有ポート 5004 経由でビデオ メッシュ ノードに接続し続けます。 これらのポートは、Webex アプリとエンドポイントによって、ビデオ メッシュ ノードへの STUN 到達可能性テストにも使用されます。 カスケード用のビデオ メッシュ ノードからビデオ メッシュ ノードへの接続先ポートの範囲は 10000 ～ 40000 です。ビデオ メッシュのプロキシ サポート
ビデオ メッシュは、明示的、透過的な検査と非検査プロキシをサポートします。 これらのプロキシをビデオ メッシュ展開に結び付けることで、エンタープライズからクラウドへのトラフィックを保護および監視できます。 この機能は、シグナリングおよび管理用 https ベースのトラフィックをプロキシに送信します。 透過プロキシについては、ビデオ メッシュ ノードからのネットワーク要求はエンタープライズネットワーク ルーティング ルールにより、特定のプロキシに転送されます。 ノードでプロキシを実装した後、ビデオメッシュ管理インターフェイスを使用して証明書管理と全体的な接続ステータスを確認できます。
| メディアはプロキシを通して転送されません。 クラウドに直接到達するために、メディア ストリームに必要なポートを開く必要があります。 詳細は、管理用のポートとプロトコルを参照してください。 |
次のプロキシ タイプはビデオ メッシュによりサポートされています。
明示的プロキシ (検査または検査なし)—明示的なプロキシを使用して、プロキシサーバー使用するクライアント (ビデオ メッシュ ノード) を指示します。 このオプションは、次のいずれかの認証タイプに対応しています。
なし—追加の認証は必要ありません。 (HTTP または HTTPS 明示的プロキシの場合)
ベーシック—HTTP ユーザー エージェントがリクエストを行う際にユーザー名とパスワードを指定するために使用されます。 (HTTP または HTTPS 明示的プロキシの場合)
ダイジェスト—機密情報を送信する前にアカウントの識別を確認するために使用され、ネットワークを経由して送信する前に、ユーザー名とパスワードにハッシュ機能を適用します。 (HTTPS 明示的プロキシの場合)
NTLM—ダイジェストと同様に、NTLM は機密情報を送信する前にアカウントの ID を確認するために使用されます。 ユーザー名およびパスワードの代わりに Windows 資格情報を使用します。 この認証スキームでは、複数の交換が完了する必要があります。 (HTTP 明示的プロキシの場合)
透過型プロキシ (検査なし)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。
透過型プロキシ (検査あり)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。 ビデオ メッシュでは http(s) 構成の変更は必要ありませんが、ビデオ ノードはプロキシを信頼できるようにするためにルート証明書を必要とします。 プロキシの検査は、アクセスする Web サイトや許可されないコンテンツのタイプに関するポリシーを施行するために、一般的に IT が使用します。 このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。
ビデオ メッシュでサポートされる解像度とフレームレート
この表は、ビデオ メッシュ ノードでホストされているミーティングで、送信者と受信者の観点からサポートされている解像度とフレームレートについて説明します。 送信者クライアント(アプリまたはデバイス)はテーブルの上段にあり、受信者クライアントはテーブルの左側の列にあります。 2 人の参加者間の対応するセルは、ネゴシエートされたコンテンツ解像度、セクションごとのフレーム、およびオーディオ ソースをキャプチャします。
| 解像度は、ビデオ メッシュ ノードのコール容量に影響します。 詳細については、「ビデオ メッシュ ノードの容量」を参照してください。 |
解像度とフレームレート値は XXXpYY として組み合わされます。たとえば、720p10 は、10 フレーム/秒で 720p を意味します。
送信側行と受信側列の定義略語（SD、HD、および FHD）は、クライアントまたはデバイスの高解像度を示します。
SD—標準の定義 (576p)
HD—高解像度 (720p)
FHD—フル ハイビジョン (1080p)
レシーバー | 差出人の名前 | ||||||
|---|---|---|---|---|---|---|---|
Webex アプリ | Webex アプリ モバイル | SIP 登録デバイス (HD) | SIP 登録デバイス (FHD) | Webex 登録デバイス (SD) | Webex 登録デバイス (HD) | Webex 登録デバイス (FHD) | |
Webex アプリ デスクトップ | 720pの10 ミックスオーディオ* | 720pの10 音声が混在 | 720pの30 音声が混在 | 720pの30 音声が混在 | 576ページ コンテンツ音声** | 720pの30 音声が混在 | 720pの30 音声が混在 |
Webex アプリ モバイル | — | — | — | — | — | — | — |
SIP 登録デバイス (HD) | 720pの30 コンテンツ音声 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 |
SIP 登録デバイス (FHD) | 1080p30 音声が混在 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 |
| Webex 登録デバイス (SD) | 1080pの15 音声が混在 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 |
Webex 登録デバイス (FHD) | 1080p30 音声が混在 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 |
* コンテンツ音声とは、共有されている特定のコンテンツ（ストリーミングビデオなど）から再生される音声を指します。 この音声ストリームは、通常のミーティングの音声とは異なります。
** 混合音声とは、ミーティング参加者の音声とコンテンツ共有からの音声のミックスです。
ビデオ メッシュの要件
ビデオ メッシュは、ハイブリッド サービスのライセンス要件に記載されているオファーで利用できます。
ビデオ メッシュの通話制御とミーティングの統合要件
ビデオ メッシュを使用するには、通話制御と既存のミーティング インフラストラクチャは必要ありませんが、2 つを統合できます。 ビデオ メッシュと通話制御およびミーティング インフラストラクチャを統合する場合は、環境が次の表に示す最低条件を満たしていることを確認してください。
コンポーネントの目的 | 最小のサポートされているバージョン |
|---|---|
オンプレミス通話制御 | Cisco Unified Communications Manager リリース 11.5(1) SU3 以降。 (最新の SU リリースをお勧めします。) Cisco Expressway-C または E、リリース X8.11.4 以降。 (詳細については、Expressway リリースノート の「重要な情報」セクションを参照してください。) |
ミーティングのインフラストラクチャ | Webex Meetings WBS33 以降。 (Cloud Collaboration Meeting Room サイト オプションで利用可能なメディア リソース タイプ リストがある場合、Webex サイトが正しいプラットフォームにあることを確認できます。)
サイトがビデオ メッシュの準備ができていることを確認するには、カスタマー サクセス マネージャー (CSM) またはパートナーに連絡してください。 |
フェールオーバー処理 | Cisco Expressway-C または E、リリース X8.11.4 以降。 (詳細については、Expressway リリースノート の「重要な情報」セクションを参照してください。) |
エンドポイントと Webex アプリの要件
コンポーネントの目的 | の詳細 |
|---|---|
サポートされるエンドポイント | Webex ビデオの互換性とサポートを参照してください。 |
Webex アプリのサポートバージョン | ビデオ メッシュは、デスクトップ (Windows、Mac) およびモバイル (Android、iPhone、iPad) 用の Webex アプリをサポートしています。 サポートされているプラットフォーム用のアプリをダウンロードするには、https://www.webex.com/downloads.htmlにアクセスしてください。 |
サポート対象のコーデック | サポートされている音声およびビデオ コーデックについては、「Webex|通話およびミーティングのビデオ仕様」を参照してください。 ビデオ メッシュの注意事項:
|
サポートされている Webex 登録済みの Room、Desk、Board デバイス | 次のデバイスがテストされ、ビデオ メッシュ ノードで動作することが確認されます。 |
ビデオ メッシュ ノード ソフトウェアのシステムおよびプラットフォーム要件
プロダクション環境
本番環境では、ビデオ メッシュ ノード ソフトウェアを特定のハードウェア構成にデプロイする方法が 2 つあります。
各サーバを 1 つの仮想マシンとして設定できます。これは、多くの SIP エンドポイントを含む展開に最適です。
VMNLite オプションを使用して、複数の小さな仮想マシンで各サーバを設定できます。 VMNLite は、ほとんどのクライアントとデバイスが Webex アプリと Webex 登録済みエンドポイントである展開に最適です。
これらの要件は、すべての設定で共通です。
VMware ESXi 7 または 8、vSphere 7 または 8
ハイパースレッディングの有効化
プラットフォームハードウェアから独立して動作するビデオ メッシュ ノードには、専用の vCPU と RAM が必要です。 他のアプリケーションとのリソースの共有はサポートされていません。 これは、ビデオ メッシュ ソフトウェアのすべての画像に適用されます。
CMS プラットフォーム上の Video Mesh Lite (VMNLite) イメージでは、VMNLite イメージのみをサポートします。 VMNLite ソフトウェアを使用した CMS ハードウェアには、他のビデオ メッシュ イメージやビデオ メッシュ 以外のアプリケーションを使用することはできません。
ハードウェア構成 | 単一の仮想マシンとしての本番環境の展開 | VMNLite VM を使用した本番環境の展開 | 注 | ||
|---|---|---|---|---|---|
Cisco Meeting Server 1000 (CMS 1000) |
| 3つの同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| ビデオ メッシュ ノードには、このプラットフォームをお勧めします。
| ||
仕様ベースの構成 (2.6 GHz Intel Xeon E5-2600v3 以降のプロセッサが必要) |
| 3つの同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| 各ビデオ メッシュ 仮想マシンには、CPU、RAM、およびハード ドライブが専用に予約されている必要があります。 設定中に［CMS1000］または［VMNLite］オプションを使用します。 NFSストレージのピークIOP(毎秒入出力操作)は300IOPSです。 | ||
Cisco Meeting Server 2000（CMS 2000） | 8つの同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| 24個の同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| ビデオ メッシュ ノードには、このプラットフォームをお勧めします。 各ブレードは、ブレードごとに予約済みの CPU、RAM、およびハードドライブを備えた Cisco Meeting Server 1000 である必要があります。 NFS ストレージのピーク IOP は 300 IOPS です。 |
デモ環境
基本的なデモの目的で、以下の最小要件を備えた仕様ベースのハードウェア構成を使用できます。
14vCPU (ビデオ メッシュ ノードは 12、ESXi は 2)
8 GB メインメモリ
20 GB ローカルハードディスクスペース
2.6 GHz Intel Xeon E5-2600v3 もしくはそれ以上のプロセッサ
| このビデオ メッシュの設定は Cisco TAC ではサポートされていません。 |
デモソフトウェアの詳細については、「ビデオ メッシュ ノード デモソフトウェア」を参照してください。
帯域幅要件
ビデオ メッシュ ノードは、アップロードとダウンロードの両方が正常に機能するには、10 Mbps の最小インターネット帯域幅が必要です。
ビデオ メッシュのプロキシ サポートの要件
ビデオ メッシュ ノードと統合できる次のプロキシ ソリューションを正式にサポートしています。
透過プロキシ用の Cisco Web Security Appliance (WSA)
明示的プロキシ用の Squid
明示的なプロキシまたは検査する透過的な検査プロキシ (トラフィックを復号化) の場合、Web インターフェイスの Video Mesh ノード信頼ストアにアップロードする必要があるプロキシのルート証明書のコピーが必要です。
以下の明示的なプロキシと認証タイプの組み合わせをサポートしています。
http および https による認証がありません
http および https による基本認証
https のみによるダイジェスト認証
http のみによる NTLM 認証
透過プロキシについては、ルーター/スイッチを使用して、HTTPS/443 トラフィックをプロキシに移動する必要があります。 また、Web Socket を強制的にプロキシに移動することもできます。 (Web ソケットは https を使用します。)
ビデオ メッシュでは、ノードが正しく機能するように、クラウド サービスへの Web ソケット接続が必要です。 明示的な検査プロキシと透過的な検査プロキシでは、適切な websocket 接続のために http ヘッダーが必要です。 変更されると、Websocket 接続は失敗します。
ポート 443 で websocket 接続障害が発生すると（透過的な検査プロキシが有効になっている）、Control Hub で登録後の警告が表示されます。 「Webex ビデオ メッシュ SIP は正しく動作していません。」 プロキシが有効になっていない場合、同じ警告が発生する可能性があります。 websocket ヘッダーがポート 443 でブロックされている場合、メディアはアプリと SIP クライアント間ではフローしません。
メディアがフローしていない場合、ポート 444 経由の https トラフィックが失敗した場合にしばしば発生します。
ポート 444 トラフィックはプロキシによって許可されていますが、これはプロキシを検査し、websocket を壊すことになります。
これらの問題を修正するには、ポート 443 で「バイパス」または「スプライス」（検査を無効にする）を行う必要がある場合があります。 *.wbx2.com および *.ciscospark.com
ビデオ メッシュ ノードの容量
ビデオ メッシュはソフトウェアベースのメディア製品であるため、ビデオ メッシュ ノードの容量は異なります。 特に、Webex クラウドのミーティング参加者はノードに負荷をかけます。 Webex クラウドへのカスケードが増えると、容量が少なくなります。 能力に影響を与えるその他の要因:
デバイスとクライアントの種類
ビデオ解像度
ネットワークの品質
ピーク負荷
展開モデル
| ビデオ メッシュの使用は、Webex ライセンス数には影響しません。 |
一般に、クラスタにノードを追加しても、カスケードを設定するためのオーバーヘッドがあるため、容量が倍増しません。 これらの数字を一般的なガイダンスとして使用します。 以下のことをおすすめします：
展開の共通のミーティング シナリオをテストします。
Control Hub の分析を使用して、展開がどのように進化しているかを確認し、必要に応じて容量を追加します。
| 低通話量（特にオンプレミスに発信する SIP コール）でのオーバーフローは、スケールの真の反映ではありません。 ビデオ メッシュ アナリティクス (Control Hub > Resources > Call Activity) は、オンプレミスで発信されるコール レッグを示します。 メディア処理のためにカスケードからビデオ メッシュ ノードに入ってきたコール ストリームを指定しません。 ミーティングでリモート参加者数が増加すると、ビデオ メッシュ ノード上のオンプレミス メディア リソースが増加し、消費されます。 |
この表には、通常のビデオ メッシュ ノードのさまざまなミックスの参加者およびエンドポイントの容量範囲が一覧表示されます。 テストには、ローカル ノード上のすべての参加者とのミーティングと、ローカルとクラウドの参加者が混在するミーティングが含まれます。 Webex クラウドの参加者が増えると、キャパシティは範囲の下限に達する見込みです。
シナリオ | 解像度 | 参加者の容量 |
|---|---|---|
Webex アプリ参加者だけのミーティング | 720p | 小惑星の一覧 |
1080p | 90～100 | |
Webex アプリ参加者のみとのミーティングと 1 対 1 の通話 | 720p | 六〇、一〇〇 |
1080p | 90～100 | |
SIP 参加者だけのミーティング | 720p | 七〇、八〇 |
SIP 参加者だけのミーティング | 1080p | 30～40 |
Webex アプリと SIP 参加者とのミーティング | 720p | 小惑星の一覧 |
|
|
VMNLiteの容量
主に Webex アプリとクラウド登録エンドポイントを含む展開には、VMNLite を推奨します。 これらの展開では、ノードは標準設定が提供するより多くのスイッチングと少ないトランスコーディングリソースを使用します。 ホストに複数の小さな仮想マシンを展開すると、このシナリオのリソースが最適化されます。
この表には、さまざまなミックスの参加者およびエンドポイントの容量範囲が一覧表示されます。 テストには、ローカル ノード上のすべての参加者とのミーティングと、ローカルとクラウドの参加者が混在するミーティングが含まれます。 Webex クラウドの参加者が増えると、キャパシティは範囲の下限に達する見込みです。
シナリオ | 解像度 | サーバー上の 3 つの VMNLite ノードを持つ参加者容量 |
|---|---|---|
Webex アプリ参加者だけのミーティング | 720p | 250～300 |
1080p | 小惑星の一覧 | |
Webex アプリ参加者のみとのミーティングと 1 対 1 の通話 | 720p | 小惑星の一覧 |
1080p | 小惑星の一覧 |
| Webex アプリ ミーティングの基本解像度は 720p です。 ただし、共有すると、参加者のサムネイルは 180p になります。 |
ビデオ メッシュのクラスタ
ビデオ メッシュ ノードをクラスタに展開します。 クラスタは、ネットワーク近接性など、同様の属性を持つビデオ メッシュ ノードを定義します。 参加者は次の条件に応じて、特定のクラスタまたはクラウドを使用します。
オンプレミス クラスタに到達できる企業ネットワーク上のクライアントは、そのクラスタに接続します。これは、企業ネットワーク上のクライアントの主な優先事項です。
ビデオ メッシュ プライベート ミーティングに参加するクライアントは、オンプレミス クラスタにのみ接続します。 これらのプライベート ミーティング用に別のクラスタを作成できます。
オンプレミス クラスタに到達できないクライアントはクラウドに接続します。これは、社内ネットワークに接続されていないモバイル デバイスの場合です。
選択したクラスタは、ロケーションだけでなく、レイテンシーにも依存します。 たとえば、ビデオ メッシュ クラスタよりも STUN 往復遅延（SRT）が低いクラウド クラスタは、ミーティングの候補として優れている可能性があります。 このロジックは、ユーザが SRT 遅延の大きい地理的に遠いクラスタに着陸するのを防ぎます。
各クラスタには、必要に応じて他のクラウド ミーティング クラスタ間で、ビデオ メッシュ プライベート ミーティングを除き、ミーティングをカスケードするロジックが含まれています。 カスケードは、ミーティングのクライアント間のメディアにデータパスを提供します。 ミーティングはノード間で分散され、クライアントは、ネットワーク トポロジ、WAN リンク、リソース使用率などの要因に応じて、最寄りの最も効率的なノードに着陸します。
クライアントの ping メディア ノードに対する能力によって、到達可能性が決定されます。 実際のコールでは、UDP や TCP など、さまざまな潜在的な接続メカニズムが使用されます。 通話の前に、Webex デバイス (Room、Desk、Board、および Webex アプリ) が Webex クラウドに登録され、通話のクラスタ候補のリストが表示されます。
| ビデオ メッシュ クラスタ内のノードは、相互に障害のない通信を必要とします。 また、他のすべてのビデオ メッシュ クラスタのノードとの障害のない通信も必要です。 ファイアウォールがビデオ メッシュ ノード間のすべての通信を許可していることを確認します。 |
プライベート ミーティングのクラスタ
プライベート ミーティング用のビデオ メッシュ クラスタを予約できます。 予約済みクラスタがいっぱいになると、プライベート ミーティング メディアは他のビデオ メッシュ クラスタにカスケードアウトします。 予約済みクラスタがいっぱいになると、プライベート ミーティングと非プライベート ミーティングは、残りのクラスタのリソースを共有します。
プライベート ミーティング以外のミーティングでは、予約済みクラスタを使用せず、プライベート ミーティングにこれらのリソースを予約します。 プライベート ミーティング以外のミーティングでネットワーク上のリソースが不足している場合、代わりに Webex クラウドにカスケードアウトします。
ビデオ メッシュのプライベート ミーティング機能の詳細については、「プライベート ミーティング」を参照してください。
| すべてのビデオ メッシュ クラスタをプライベート ミーティングに予約する場合、ショート ビデオ アドレス形式 (meet@your_site) を使用できません。 これらのコールは現在、適切なエラー メッセージなしで失敗します。 一部のクラスタを予約解除しておくと、ショート ビデオ アドレス形式のコールがこれらのクラスタを介して接続できます。 |
ビデオ メッシュ クラスタ展開のガイドライン
一般的なエンタープライズ展開では、クラスタごとに最大 100 ノードを使用することを推奨します。 システムには、100 ノードを超えるクラスタ サイズをブロックするハード制限が設定されていません。 ただし、より大きなクラスタを作成する必要がある場合は、Cisco Account Team を通じて Cisco エンジニアリングでこのオプションを確認することを強くお勧めします。
リソースが近似したネットワークプロキシミティ(類似性)を有する際に数を少なくしてクラスタを作成します。
クラスタを作成するときは、同じ地理的地域と同じデータセンターにあるノードのみを追加します。 広域ネットワーク（WAN）全体のクラスタリングはサポートされていません。
一般的には、頻繁にその地域でミーティングを開催するエンタープライズでクラスタを展開します。 エンタープライズの中のさまざまな WAN のロケーションで使用可能な帯域に、クラスタを配置することを計画してください。 時間をかけて、観察されるユーザーのパターンに基づいて、クラスタごとに点かいして、拡張していくことができます。
異なったタイムゾーンに配置されたクラスタは、通話パターンの違ったピーク/不通状態の時間帯の利点を生かして、効果的に複数の地点にサービスを提供できます。
2 つの別々のデータセンター (EU と NA など) に 2 つのビデオ メッシュ ノードがあり、各データセンターを介してエンドポイントが結合されている場合、各データセンターのノードはクラウド内の 1 つのビデオ メッシュ ノードにカスケードされます。 これらのカスケードはインターネットで行われます。 クラウド参加者 (ビデオ メッシュ参加者の 1 人の前に参加する) がある場合、ノードはクラウド参加者のメディア ノードを介してカスケードされます。
タイムゾーンの多様性
タイムゾーンの多様性により、クラスタはオフピークタイムを共有することができます。 例: Northern California クラスタと New York クラスタのある会社では、総合的なネットワークの滞在性は、地理的に多様性のあるユーザー人口にサービスを提供する二つのロケーションの間であまり高くありません。 リソースが Northern California クラスタで使用量がピークに達したときに、New York クラスタはオフ ピークになり、追加の容量をもつことがよくあります。 同じことが、New York クラスタがピーク時の間の Northern California クラスタにも適用されます。 これらは効率的なリソースの展開に使用される唯一のメカニズムではなく、2 つともメインのメカニズムでもあります。
クラウドにオーバーフロー
すべてのオンプレミス クラスタの容量に達すると、オンプレミスの参加者は Webex クラウドにオーバーフローします。 これは、すべてのコールがクラウドでホストされていることを意味するものではありません。 Webex は、リモートまたはオンプレミス クラスタに接続できない参加者のみをクラウドに転送します。 オンプレミスもしくはクラウドの参加者の両方の通話において、オンプレミスクラスタはクラウドにブリッジ[カスケード]接続され、全参加者を単一通話にまとめます。
ミーティングをプライベート ミーティング タイプとして設定した場合、Webex はすべての通話をオンプレミス クラスタに保存します。 プライベート ミーティングはクラウドにオーバーフローすることはありません。
Webex デバイスが Webex に登録される
到達可能性の決定に加えて、クライアントはNAT (STUN)を通じてUDPのSimple Traversalを使用して、一定期間ごとの往復遅延テストも実施します。 STUN 往復 (SRT) 遅延は実際の通話の間の可能性のあるリソースを選択する際に重要な要素となります。 複数のクラスタが展開される際、プライマリ選択基準は情報が得られた SRT 遅延に基づきます。 到達可能性テストはバックグラウンドで実施され、ネットワーク変更を含む要素の数で開始されます。まだこれで発信設定時間に影響を及ぼす遅延は起こりません。 次の二つの例では可能性のある到達可能性テストの結果が示されています。
ラウンド トリップ遅延テスト - クラウド デバイスがオンプレミス クラスタに到達できません
ラウンド トリップ遅延テスト - クラウド デバイスがオンプレミスのクラスタに正常に到達します
コールがセットアップされるたびに、学習された到達可能性情報が Webex クラウドに提供されます。 これによりクラウドは顧客の使用可能なクラスタおよび通話の種類に関連したロケーションにおいて最適なリソース (クラスタもしくはクラウド) を選択できます。 優先クラスタで利用可能なリソースがない場合、すべてのクラスタは SRT 遅延に基づいてアベイラビリティについてテストされます。 希望するクラスタは最も低い SRT 遅延で選択されます。 プライマリ クラスタがビジーの場合、セカンダリ クラスタからオンプレミスで通話が行われます。 ローカルの到達可能なビデオ メッシュ リソースは、最小 SRT 遅延の順に最初に試行されます。 ローカル リソースが消費されると、参加者はクラウドに接続されます。
クラスタの定義とロケーションは、参加者にとって最高の総合的なエクスペリエンスを提供する展開にとって非常に重要です。 理想的には展開は顧客がいる場所にリソースを提供できるべきです。 十分なリソースが通話の主な部分を顧客が行うところに割り当てられておらず、内線ネットワークの帯域幅がより一層、ユーザーを遠くのクラスタに接続するために消費されています。
オンプレミスとクラウド通話
同じクラスタ親和性 (クラスタへの近接性に基づく基本設定) を持つオンプレミス Webex デバイスは、コールに対して同じクラスタに接続します。 異なるオンプレミス クラスタの親和性を持つオンプレミス Webex デバイスは、異なるクラスタに接続し、クラスタはクラウドにカスケードして、2 つの環境を 1 つのコールに結合します。 これにより、Webex クラウドをハブとし、オンプレミス クラスタをミーティングのスポークとして動作させるハブとスポークデザインが作成されます。
異なるクラスタ アフィニティによるオンプレミス通話
Webex デバイスは、到達可能性に基づいてオンプレミスのクラスタまたはクラウドに接続します。 以下で最も一般的なシナリオの例が示されています。
Webex Cloud デバイスがクラウドに接続する
Webex オンプレミス デバイスがオンプレミス クラスタに接続する
Webex オンプレミス デバイスがクラウドに接続する
250 ms 以上の STUN 往復遅延に基づくオーバーフローのクラウド クラスタの選択
ノード選択の優先順位は、ローカルに展開されているビデオ メッシュ ノードですが、オンプレミス ビデオ メッシュ クラスタへの STUN 往復（SRT）遅延が許容される往復 250 ms（通常、オンプレミス クラスタが別の大陸で設定されている場合に発生します）を超えると、システムはビデオ メッシュ ノードではなく、その地理的に最も近いクラウド メディア ノードを選択するシナリオをサポートします。
Webex アプリまたは Webex デバイスは、サンノゼのエンタープライズ ネットワーク上にあります。
サンノゼとアムステルダムのクラスタは容量があるか利用できません。
上海クラスターへのSRT遅延は250ミリ秒以上であり、メディアの品質問題を導入する可能性が高い。
サンフランシスコのクラウド クラスタには、最適な SRT 遅延があります。
上海のビデオ メッシュ クラスタは考慮から除外されます。
その結果、Webex アプリはサンフランシスコのクラウド クラスタにオーバーフローします。
プライベート ミーティング
プライベート ミーティングは、ビデオ メッシュを通じてすべてのメディアをネットワークに隔離します。 通常のミーティングとは異なり、ローカル ノードがいっぱいになると、メディアは Webex クラウドにカスケードされません。 ただし、デフォルトでは、プライベート ミーティングはネットワーク上の異なるビデオ メッシュ クラスタにカスケードできます。 地理的な場所を超えたプライベート ミーティングの場合、図の HQ1_VMN to Remote1_VMN のようなクラスタ間カスケードを許可するには、ビデオ メッシュ クラスタが互いに直接接続している必要があります。
クラスタ間の障害のないカスケードを許可するには、必要なポートがファイアウォールで開いていることを確認します。 詳細は、管理用のポートとプロトコルを参照してください。
プライベート ミーティングのすべての参加者は、ミーティング主催者の Webex 組織に属している必要があります。 Webex アプリまたは認証済みビデオ システム (UCM/VCS または Webex 登録済みビデオ デバイスに登録された SIP エンドポイント) を使用して参加できます。 VPNまたは MRA でネットワークにアクセスする参加者は、プライベートミーティングに参加できます。 しかし、ネットワークの外からは誰もプライベートミーティングに参加できません。
ビデオ メッシュでサポートされる展開モデル
- ビデオ メッシュ展開でサポートされています
-
データセンター（推奨）または非武装地帯（DMZ）のいずれかでビデオ メッシュ ノードを展開できます。 詳細については、「ビデオ メッシュで使用されるポートとプロトコル」を参照してください。
DMZ 展開では、デュアル ネットワーク インターフェイス（NIC）を使用してクラスタ内のビデオ メッシュ ノードを設定できます。 この展開では、内部エンタープライズ ネットワーク トラフィック（ボックス間通信、ノード クラスタ間のカスケード、およびノードの管理インターフェイスにアクセスするために使用されます）を外部クラウド ネットワーク トラフィック（外部世界への接続に使用され、クラウドへのカスケード）から分離できます。
デュアル NIC は、ビデオ メッシュ ノード ソフトウェアのフル、VMNLite およびデモ バージョンで動作します。 1:1 NAT セットアップの後ろにビデオ メッシュを展開することもできます。
ビデオ メッシュ ノードをコール制御環境に統合できます。 たとえば、Unified CM と統合されたビデオ メッシュを使用した展開については、「ビデオ メッシュおよび Cisco Unified Communications Manager の展開モデル」を参照してください。
サポート対象のアドレス変換タイプは以下の通りです。
IP プールを使用する動的ネットワーク アドレス変換 (NAT)
動的ポート アドレス変換 (PAT)
1:1のNAT
他の形態の NAT でも、正しいポートとプロトコルが使われる限り機能するはずですが、テストをしていないため、当社は正式にはサポートしません。
IPv4
ビデオ メッシュ ノードの静的 IP アドレス
- ビデオ メッシュ展開ではサポートされていません
-
IPv6
ビデオ メッシュ ノードの DHCP
シングルNICとデュアルNICが混在するクラスタ
広域ネットワーク（WAN）上のビデオ メッシュ ノードのクラスタリング
ビデオ メッシュ ノードを通過しない音声、ビデオ、またはメディア:
電話からの音声
Webex アプリと標準ベースのエンドポイント間のピアツーピア通話
ビデオ メッシュ ノードの音声終了
Expressway C/E ペア経由で送信されるメディア
Webex からのビデオコールバック
ビデオ メッシュおよび Cisco Unified Communications Manager の展開モデル
これらの例では、一般的なビデオ メッシュ展開を示し、ビデオ メッシュ クラスタがネットワークに適合する場所を理解するのに役立ちます。 ビデオ メッシュの展開は、ネットワーク トポロジの要素に依存することに注意してください。
データ センターの場所
オフィスの場所と規模
インターネット アクセスの場所と能力
一般的に、ビデオ メッシュ ノードを Unified CM または Session Management Edition (SME) クラスタに結び付けようとします。 ベスト プラクティスとして、ノードをローカルのブランチにできるだけ集中管理するようにしてください。
Video Mesh は Session Management Edition (SME) をサポートしています。 Unified CM クラスタは SME を介して接続することができ、ビデオ メッシュ ノードに接続する SME トランクを作成する必要があります。
ハブと Spoke アーキテクチャ
この展開モデルには、集中管理されたネットワークとインターネット アクセスが含まれます。 一般的に、中央の場所の従業員の密度は高くなります。 この場合、ビデオ メッシュ クラスタを中央に配置して、メディア処理を最適化できます。
ブランチの場所にクラスタを置くことは、短期では利点をもたらさず、最適なルーティングをもたらすと言えません。 ブランチ間で頻繁なコミュニケーションがある場合のみのみ、ブランチにクラスタを展開することをお勧めします。
地理的な分布
地理的に分散された展開は相互接続されていますが、地域間で顕著な遅延を示すことがあります。 リソースの欠如により、各地理的場所のユーザー間でミーティングがあるときに、短期でセットアップするには最適でないカスケードを生じさせる場合があります。 このモデルでは、地域のインターネット アクセスの近くにビデオ メッシュ ノードを割り当てることを推奨します。
SIP ダイヤルによる地理的な分布
この展開モデルには、地理的な Unified CM クラスタが含まれます。 各クラスタには、ローカルのビデオ メッシュ クラスタのリソースを選択するための SIP トランクを含めることができます。 2 番目のトランクは、リソースが制限される場合に、Expressway ペアへのフェイルオーバー パスを提供できます。
ビデオ メッシュで使用されるポートとプロトコル
ビデオ メッシュの展開を成功させ、ビデオ メッシュ ノードのトラブルのない動作を保証するには、プロトコルで使用するためにファイアウォールの次のポートを開きます。
Webex Teams の全体的なネットワーク要件については、「Webex サービスのネットワーク要件」を参照してください。
Webex サービスのファイアウォールとネットワーク プラクティスの詳細については、「ファイアウォール トラバーサル ホワイトペーパー」を参照してください。
潜在的な DNS クエリの問題を緩和するには、エンタープライズ ファイアウォールを構成するときに、DNS のベストプラクティス、ネットワーク保護、および攻撃の識別 に従うようにしてください。
設計に関する詳細情報は、「ハイブリッド サービスの設定済みアーキテクチャ、CVD」を参照してください。
マネジメント用のポートとプロトコル
| ビデオ メッシュ クラスタ内のノードは、相互に障害のない通信を必要とします。 また、他のすべてのビデオ メッシュ クラスタのノードとの障害のない通信も必要です。 ファイアウォールがビデオ メッシュ ノード間のすべての通信を許可していることを確認します。 |
クラスタ内のビデオ メッシュ ノードは、同じ VLAN またはサブネット マスクにある必要があります。
目的 | [Source] | 移動先 | ソース IP | ソースポート | 転送プロトコル | 宛先 IP | 移動先ポート |
|---|---|---|---|---|---|---|---|
管理 | マネジメントコンピュータ | ビデオ メッシュ ノード | 必須 | 任意 | TCP, HTTPS | ビデオ メッシュ ノード | 443 |
ビデオ メッシュ管理コンソールへのアクセス用 SSH | マネジメントコンピュータ | ビデオ メッシュ ノード | 必須 | 任意 | TCP | ビデオ メッシュ ノード | 22 |
クラスター内通信 | ビデオ メッシュ ノード | ビデオ メッシュ ノード | クラスタ内の他のビデオ メッシュ ノードの IP アドレス | 任意 | TCP | ビデオ メッシュ ノード | 8443 |
管理 | ビデオ メッシュ ノード | Webex クラウド | 必須 | 任意 | UDP, NTP UDP, DNS TCP、HTTPS（WebSockets） | 任意 | 123* 53* |
カスケード信号方式 | ビデオ メッシュ ノード | Webex クラウド | 任意 | 任意 | TCP | 任意 | 443 |
カスケード メディア | ビデオ メッシュ ノード | Webex クラウド | ビデオ メッシュ ノード | すべて*** | UDP | 任意 特定のアドレス範囲については、「Webex サービスのネットワーク要件」の「Webex メディアサービスの IP サブネット」セクションを参照してください。 | 5004 50000から53000 詳細については、「Webex サービスのネットワーク要件」の「Webex サービス – ポート番号とプロトコル」セクションを参照してください。 |
カスケード信号方式 | Vidoの網のクラスタ (1) | Vidoの網のクラスタ (2) | 任意 | 任意 | TCP | 任意 | 443 |
カスケード メディア | Vidoの網のクラスタ (1) | Vidoの網のクラスタ (2) | Vidoの網のクラスタ (1) | すべて*** | UDP | 任意 | 5004 50000から53000 |
管理 | ビデオ メッシュ ノード | Webex クラウド | 必須 | 任意 | TCP, HTTPS | 必要なだけ** | 443 |
管理 | ビデオ メッシュ ノード (1) | ビデオ メッシュ ノード (2) | ビデオ メッシュ ノード (1) | 任意 | TCP、HTTPS（WebSockets） | ビデオ メッシュ ノード (2) | 443 |
内部コミュニケーション | ビデオ メッシュ ノード | 他のすべてのビデオ メッシュ ノード | ビデオ メッシュ ノード | 任意 | UDP | 任意 | 10000から40000 |
* OVA 内のデフォルトの構成は、NTP と DNS に対して構成されます。 OVA では、それらのポートをインターネットへの発信用に開く必要があります。 ローカル NTP および DNS サーバを設定する場合、ファイアウォールを通じてポート 53 および 123 を開く必要はありません。
** 一部のクラウドサービス URL は予告なく変更される場合があるため、ビデオ メッシュ ノードのトラブル フリー操作には ANY が推奨されます。 URL に基づいてトラフィックをフィルタリングする場合は、「Webex サービスのネットワーク要件
」の「ハイブリッドサービス用 Webex Teams URL」セクションを参照してください。
***ポートは、QoS を有効にするかどうかによって異なります。 QoS を有効にすると、ポートは 52,500-59499、63000-64667、59500-62999、および 64688-65500 です。 QoS がオフの場合、ポートは 34,000 ～ 34,999 です。
ビデオ メッシュのトラフィック署名 (Quality of Service Enabled)
ビデオ メッシュ ノードが DMZ のエンタープライズ側またはファイアウォール内に配置されている展開では、Webex Control Hub にビデオ メッシュ ノードの設定があり、管理者が QoS ネットワーク マーキングのためにビデオ メッシュ ノードで使用されるポート範囲を最適化できます。 この [サービスの質（Quality of Service）] 設定はデフォルトで有効になっており、音声、ビデオ、およびコンテンツ共有に使用されるソース ポートをこの表の値に変更します。 この設定では、UDP ポート範囲に基づいて QoS マーキング ポリシーを設定して、音声とビデオまたはコンテンツ共有を区別し、すべての音声に EF の推奨値を、ビデオおよびコンテンツ共有に AF41 の推奨値を設定できます。
表と図には、QoSネットワーク構成の主な焦点であるオーディオおよびビデオストリームに使用されるUDPポートが表示されます。 UDP を介したメディアに対するネットワーク QoS マーキングポリシーは次の表の焦点ですが、Webex ビデオ メッシュ ノードは、一時的なポート 52500 ～ 65500 を使用して Webex アプリのプレゼンテーションとコンテンツ共有のための TCP トラフィックを終了します。 ビデオ メッシュ ノードと Webex アプリの間にファイアウォールが存在する場合、これらの TCP ポートも適切に機能できるようにする必要があります。
| ビデオ メッシュ ノードはトラフィックをネイティブにマークします。 このネイティブ マーキングは、一部のフローでは非対称であり、ソース ポートが共有ポート（さまざまな宛先および宛先ポートへの複数のフローに対して 5004 のような単一のポート）であるか、またはそうでないか（ポートが範囲内に収まるが、その特定の双方向セッションに固有の場合）によって異なります。 ビデオ メッシュ ノードによるネイティブ マーキングを理解するには、ビデオ メッシュ ノードが 5004 ポートをソース ポートとして使用していない場合に音声 EF をマークすることに注意してください。 Video Mesh to Video Mesh カスケードや Video Mesh to Webex アプリなどの双方向フローには、非対称にマークされます。これは、ネットワークを使用して、提供された UDP ポート範囲に基づいてトラフィックを指摘する理由です。 |
| ソース IP アドレス | 宛先 IP アドレス | ソース UDP ポート | 宛先 UDP ポート | 元の DSCP マーク | メディアタイプ |
ビデオ メッシュ ノード | Webex クラウド メディア サービス | 35000 から 52499 | 5004 | AF41 | STUN パケットのテスト |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 52500 から 59499 | 5004 | EF | 音声 |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 63000 から 64667 | 5004 | AF41 | ビデオ |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 59500から62999 | 50000から51499 | EF | 音声 |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 64668から65500 | 51500 から 53000 | AF41 | ビデオ |
| ビデオ メッシュ ノード | ビデオ メッシュ ノード | 10000から40000 | 10000から40000 | — | 音声 |
| ビデオ メッシュ ノード | ビデオ メッシュ ノード | 10000から40000 | 10000から40000 | — | ビデオ |
| ビデオ メッシュ ノード | Unified CM SIP エンドポイント | 52500 から 59499 | Unified CM SIP プロファイル | EF | 音声 |
| ビデオ メッシュ ノード | Unified CM SIP エンドポイント | 63000 から 64667 | Unified CM SIP プロファイル | AF41 | ビデオ |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 52500 から 59499 | 5004 | EF | 音声 |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 63000 から 64667 | 5004 | AF41 | ビデオ |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 59500から62999 | 50000から51499 | EF | 音声 |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 64668から65500 | 51500 から 53000 | AF41 | ビデオ |
| ビデオ メッシュ ノード | Webex Teams アプリケーションまたはエンドポイント* | 5004 | 52000 から 52099 | AF41 | 音声 |
| ビデオ メッシュ ノード | Webex Teams アプリケーションまたはエンドポイント | 5004 | 52100 から 52299 | AF41 | ビデオ |
*メディア トラフィックの方向により、DSCP マーキングが決まります。 ソース ポートがビデオ メッシュ ノード（ビデオ メッシュ ノードから Webex Teams アプリまで）からの場合、トラフィックは AF41 のみとしてマークされます。 Webex Teams アプリまたは Webex エンドポイントから発信されるメディア トラフィックには別の DSCP マーキングがありますが、ビデオ メッシュ ノードの共有ポートからのリターン トラフィックは含まれません。
| UDP ソース ポートの差別化 (Windows Webex アプリ クライアント): 組織で UDP ソース ポートの差別化を有効にしたい場合は、ローカル アカウント チームに連絡してください。 これが有効になっていない場合、音声とビデオの共有は Windows OS で区別できません。 ソース ポートは、Windows デバイスでの音声、ビデオ、およびコンテンツ共有でも同じです。 |
ビデオ メッシュのトラフィック署名 (サービスの品質が無効になっています)
ビデオ メッシュ ノードが DMZ に配置されている展開では、Webex Control Hub にビデオ メッシュ ノードの設定があり、ビデオ メッシュ ノードで使用されるポート範囲を最適化できます。 この [サービス品質（Quality of Service）] 設定は、無効（デフォルトで有効）にすると、オーディオ、ビデオ、およびコンテンツ共有に使用されるソース ポートを、ビデオ メッシュ ノードから 34000 ～ 34999 の範囲に変更します。 ビデオ メッシュ ノードは、すべての音声、ビデオ、およびコンテンツ共有を AF41 の単一の DSCP にネイティブにマークします。
| 送信元ポートは宛先に関係なくすべてのメディアで同じであるため、この設定が無効になっている場合、ポート範囲に基づいて音声とビデオまたはコンテンツ共有を区別することはできません。 この設定により、Quality of Service が有効になっているメディア用のファイアウォール ピン穴をより簡単に設定できます。 |
表と図には、QoS が無効になっている場合にオーディオおよびビデオ ストリームに使用される UDP ポートが表示されます。
| ソース IP アドレス | 宛先 IP アドレス | ソース UDP ポート | 宛先 UDP ポート | 元の DSCP マーク | メディアタイプ |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 34000 から 34999 | 5004 | AF41 | 音声 |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 34000 から 34999 | 5004 | AF41 | ビデオ |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 34000 から 34999 | 50000から51499 | AF41 | 音声 |
| ビデオ メッシュ ノード | Webex クラウド メディア サービス | 34000 から 34999 | 51500 から 53000 | AF41 | ビデオ |
| ビデオ メッシュ ノード | ビデオ メッシュ ノード | 10000から40000 | 10000から40000 | AF41 | 音声 |
| ビデオ メッシュ ノード | ビデオ メッシュ ノード | 10000から40000 | 10000から40000 | AF41 | ビデオ |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 34000 から 34999 | 5004 | AF41 | 音声 |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 34000 から 34999 | 5004 | AF41 | ビデオ |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 34000 から 34999 | 50000から51499 | AF41 | 音声 |
ビデオ メッシュ クラスタ | ビデオ メッシュ クラスタ | 34000 から 34999 | 51500 から 53000 | AF41 | ビデオ |
| ビデオ メッシュ ノード | Unified CM SIP エンドポイント | 52500 から 59499 | Unified CM SIP プロファイル | AF41 | 音声 |
| ビデオ メッシュ ノード | Unified CM SIP エンドポイント | 63000 から 64667 | Unified CM SIP プロファイル | AF41 | ビデオ |
ビデオ メッシュ ノード | Webex クラウド メディア サービス | 35000 から 52499 | 5004 | AF41 | STUN パケットのテスト |
| ビデオ メッシュ ノード | Webex Teams アプリケーションまたはエンドポイント | 5004 | 52000 から 52099 | AF41 | 音声 |
| ビデオ メッシュ ノード | Webex Teams アプリケーションまたはエンドポイント | 5004 | 52100 から 52299 | AF41 | ビデオ |
Webex Meetings トラフィックのポートとプロトコル
目的 | [Source] | 移動先 | ソース IP | ソースポート | 転送プロトコル | 宛先 IP | 移動先ポート |
|---|---|---|---|---|---|---|---|
ミーティングへの発信 | アプリ (Webex アプリのデスクトップおよびモバイル アプリ) Webex 登録済みデバイス | ビデオ メッシュ ノード | 必須 | 任意 | UDP および TCP (Webex アプリで使用されます) SRTP (どれでも) | 必要なだけ** | 5004 |
ミーティングへの SIP デバイス通話 (SIP シグナリング) | Unified CM または Cisco Expressway コール制御 | ビデオ メッシュ ノード | 必須 | 短期（>=1024） | TCP または TLS | 必要なだけ** | 5060 または 5061 |
カスケード接続 | ビデオ メッシュ ノード | Webex クラウド | 必須 | 34000 から 34999 | UDP、SRTP (任意の)* | 必要なだけ** | 5004 50000から53000*** |
カスケード接続 | ビデオ メッシュ ノード | ビデオ メッシュ ノード | 必須 | 34000 から 34999 | UDP、SRTP (任意の)* | 必要なだけ** | 5004 |
| ポート 5004 は、すべてのクラウド メディアとオンプレミスのビデオ メッシュ ノードに使用されます。 Webex アプリは、共有ポート 5004 経由でビデオ メッシュ ノードに接続し続けます。 これらのポートは、Webex アプリと Webex 登録済みエンドポイントによって、ビデオ メッシュ ノードへの STUN テストにも使用されます。 カスケード用のビデオ メッシュ ノードからビデオ メッシュ ノードへの接続先ポート範囲は 10000 ～ 40000 です。* TCP もサポートされていますが、メディアの品質に影響する可能性があるため、推奨されていません。 |
** IP アドレスで制限する場合は、「Webex サービスのネットワーク要件」に記載されている IP アドレス範囲を参照してください。
*** Expressway はすでにこのポート範囲を Webex クラウドに使用しています。 そのためほとんどのデプロイでは、ビデオ メッシュのこの新しい要件に対応するためのアップデートは不要です。 ただし、展開に厳しいファイアウォール ルールがある場合、ビデオ メッシュ用にこれらのポートを開くためにファイアウォールの構成を更新する必要がある場合があります。
組織で Webex を最大限に活用するには、ファイアウォールを構成して、ポート 5004 宛てのすべてのアウトバウンド TCP および UDP トラフィックと、そのトラフィックへのインバウンド応答を許可します。 上記のポート要件は、ビデオ メッシュ ノードが LAN (優先) または DMZ に展開され、Webex アプリが LAN に展開されていることを前提としています。
ビデオ メッシュのビデオ品質とスケーリング
以下に、カスケードが作成される一般的なミーティング シナリオを示します。 ビデオ メッシュは、利用可能な帯域幅に応じて適応性があり、それに応じてリソースを配布します。 ビデオ メッシュ ノードを使用するミーティングのデバイスの場合、カスケード リンクは、平均帯域幅を削減し、ユーザーのミーティング エクスペリエンスを改善する利点を提供します。
| 帯域幅のプロビジョニングと容量計画のガイドラインについては、推奨アーキテクチャのドキュメントを参照してください。 |
ミーティングのアクティブなスピーカーに基づいて、カスケードリンクが確立されます。 各カスケードには最大 6 つのストリームを含めることができ、カスケードは 6 人の参加者に制限されます (Webex アプリ/SIP から Webex クラウドへの方向に 6 つ、反対方向に 5 つ)。 各メディア リソース (クラウドとビデオ メッシュ) は、カスケード全体ですべてのリモート 参加者のローカル エンドポイント要件を満たすために必要なストリームをリモート側に要求します。
柔軟なユーザー エクスペリエンスを提供するために、Webex プラットフォームはミーティング参加者にマルチストリーム ビデオを実行できます。 この同じ機能は、ビデオ メッシュ ノードとクラウド間のカスケード リンクに適用されます。 このアーキテクチャでは、エンドポイントのレイアウトなど、さまざまな要因によって帯域幅の要件が異なります。
アーキテクチャ
このアーキテクチャでは、Cisco Webex に登録されたエンドポイントは、スイッチングサービスにクラウドとメディアにシグナリングを送信します。 オンプレミス SIP エンドポイントは、コール制御環境 (Unified CM または Expressway) にシグナリングを送信し、ビデオ メッシュ ノードに送信します。 メディアはトランスコーディングサービスに送信されます。
クラウドとプレミスの参加者
ビデオ メッシュ ノードのローカル オンプレミスの参加者は、レイアウト要件に基づいて必要なストリームを要求します。 これらのストリームは、ビデオ メッシュ ノードからローカル デバイス レンダリング用のエンドポイントに転送されます。
各クラウドおよびビデオ メッシュ ノードは、クラウド登録デバイスまたは Webex アプリであるすべての参加者から HD および SD の解像度を要求します。エンドポイントに応じて、最大 4 つの解像度（通常 1080p、720p、360p、180p）を送信します。
カスケード
ほとんどの Cisco エンドポイントは、1 つのソースから 3 つまたは 4 つのストリームを、さまざまな解像度（1080p ～ 180p）で送信できます。 エンドポイントのレイアウトは、カスケードの一番端に必要なストリームの要件を決定します。 アクティブなプレゼンスでは、メイン ビデオ ストリームが 1080p または 720p、ビデオ ペイン（PiPS）が 180p です。 等しいビューの場合、ほとんどの場合すべての参加者の解像度は 480p または 360p です。 ビデオ メッシュ ノードとクラウド間で作成されたカスケードは、両方向に 720p、360p、180p も送信します。 コンテンツは単一のストリームとして送信され、音声は複数のストリームとして送信されます。
クラスタごとの測定を提供するカスケード帯域幅グラフは、Webex Control Hub の [分析] メニューで利用できます。 Control Hub では、ミーティングごとにカスケード帯域幅を設定できません。
| ミーティングあたりのネゴシエートされたカスケード帯域幅の最大値は、すべてのソースと送信可能な複数のメインビデオストリームに対して 20Mbps です。 この最大値には、コンテンツ チャネルまたは音声は含まれません。 |
複数のレイアウトの例を持つメインビデオ
次の図は、ミーティングのシナリオの例と、複数の要因が機能しているときに帯域幅がどのように影響を受けるかを示しています。 この例では、すべての Webex アプリと Webex に登録されているデバイスが、1x720p、1x360p、1x180p ストリームをビデオ メッシュに送信しています。 カスケードでは、720p、360p、180p のストリームが両方向に送信されます。 その理由は、カスケードの両側に 720p、360p、180p を受信している Webex アプリと Webex 登録デバイスがあるためです。
| 図では、送信および受信データの帯域幅番号は目的のみです。 すべての可能なミーティングとそれに付随する帯域幅要件を完全に網羅しているわけではありません。 異なるミーティングシナリオ（参加した参加者、デバイス機能、ミーティング内のコンテンツ共有、ミーティング中の任意の時点でのアクティビティ）は、異なる帯域幅レベルを生成します。 |
下の図は、クラウドとプレミスの登録済みエンドポイントとアクティブなスピーカーを持つミーティングを示しています。
同じミーティングで、下の図は、ビデオ メッシュ ノードとクラウドの両方向に作成されたカスケードの例を示しています。
同じミーティングで、以下の図は、クラウドからのカスケードの例を示しています。
下の図は、Webex Meetings クライアントと同じデバイスを持つミーティングを示しています。 ビデオ メッシュ ノードは現時点では Webex Meetings をサポートしていないため、システムは Webex Meeting クライアントのアクティブ スピーカーの追加の HD ストリームとともに、アクティブ スピーカーと最後のアクティブ スピーカーを高解像度で送信します。
Webex サービスの要件
パートナー、カスタマー サクセス マネージャー (CSM)、またはトライアルの担当者と協力して、ビデオ メッシュ用の Cisco Webex サイトと Webex サービスを正しくプロビジョニングします。
Webex サービスの有料サブスクリプションを持つ Webex 組織が必要です。
ビデオ メッシュを最大限に活用するには、Webex サイトがビデオ プラットフォーム バージョン 2.0 にあることを確認してください (Cloud Collaboration Meeting Room サイト オプションでメディア リソース タイプ リストが利用可能な場合、サイトがビデオ プラットフォーム バージョン 2.0 にあることを確認できます)。
ユーザープロファイルで Webex サイトの CMR を有効にする必要があります。 (SupportCMR 属性で CSV を一括アップデートするにあたり実行できます).
詳細については、付録の「機能比較とコラボレーション会議室ハイブリッドからビデオ メッシュへの移行パス」を参照してください。
原国が正しいことを確認する
ビデオ メッシュはWebexの国際配信メディア (GDM) 機能を使って、より最適なメディア ルーティングを実現します。 最適な接続を実現するため、企業に最も近いクラウド メディアを選択して、 Webexへのビデオ メッシュ カスケードをWebexします。 その後トラフィックがWebexバックボーンを通過し、ミーティングのWebexマイクロサービスと対話します。 このルーティングにより待ち時間を最小限に抑え、 Webexバックボーンのトラフィックを維持し、インターネットをオフにします。
GDM をサポートするために、MaxMind をこのプロセスの GeoIP ロケーション プロバイダーとして使用します。 効率的なルーティングを確保するために、MaxMind がパブリック IP アドレスの場所を正しく識別していることを確認します。
| 1 | Web ブラウザで、この URL に Expressway またはエンドポイントのパブリック IP アドレスを最後に入力します。 次のような応答を受け取ります。 |
| 2 | ことを確認します |
| 3 | ロケーションが間違っている場合は、https://support.maxmind.com/geoip-data-correction-request/correct-a-geoip-locationでパブリックIPアドレスのロケーションを修正するリクエストをMaxMindに送信してください。 |
ビデオ メッシュの前提条件を完了する
このチェックリストを使用して、ビデオ メッシュ ノードをインストールして設定し、Webex サイトをビデオ メッシュと統合する準備ができていることを確認します。
| 1 | 以下のことを確認してください。
| ||
| 2 | パートナー、カスタマー サクセス マネージャー、またはトライアルの担当者と協力して、Webex 環境を理解し、ビデオ メッシュに接続する準備を整えます。 詳細については、「Webex サービスの要件」を参照してください。 | ||
| 3 | ビデオ メッシュ ノードに割り当てるには、次のネットワーク情報を記録します。
| ||
| 4 | インストールを開始する前に、Webex 組織でビデオ メッシュが有効になっていることを確認してください。 このサービスは、Cisco Webex ハイブリッド サービスのライセンス要件に記載されているとおり、特定の有料 Webex サービス サブスクリプションを持つ組織で利用できます。 Ciscoパートナーもしくはアカウントマネジャーにアシスタンスを受けるために連絡してください。 | ||
| 5 | ビデオ メッシュ ノード ソフトウェアのシステム要件とプラットフォーム要件で説明されているように、ビデオ メッシュ ノードのサポートされているハードウェアまたは仕様ベースの構成を選択します。 | ||
| 6 | サーバーが VMware ESXi 7 または 8、および vSphere 7 または 8 を実行しており、VM ホストが動作していることを確認してください。 | ||
| 7 | ビデオ メッシュを Unified CM コール制御環境と統合していて、ミーティング プラットフォーム全体で参加者リストを一貫させる場合は、Unified CM クラスタ セキュリティ モードが TLS 暗号化トラフィックをサポートするように混合モードに設定されていることを確認してください。 この機能が動作するには、エンドツーエンドで暗号化されたトラフィックが必要です。 Unified CM 環境を混合モードに切り替える方法の詳細については、『Security Guide for Cisco Unified Communications Manager』のTLS設定の章を参照してください。 機能およびエンドツーエンド暗号化の設定方法の詳細については、Active Controlソリューションガイドを参照してください。 | ||
| 8 | プロキシ (明示的、透過的な検査、または透過的な非検査) をビデオ メッシュと統合する場合は、「ビデオ メッシュのプロキシ サポートの要件」に記載されている要件に従っていることを確認してください。 |
次に行うこと
ビデオ メッシュ展開タスク フロー
始める前に
| 1 |
VMware ESXi または vCenter を実行しているホスト サーバにビデオ メッシュ ノードを展開するには、次の手順を使用します。 ノードを作成するソフトウェアをオンプレミスにインストールし、ネットワーク設定などの初期設定を実行します。 後でクラウドに登録できます。 |
| 2 |
最初にコンソールにサイン インします。 ビデオ メッシュ ノード ソフトウェアにはデフォルトのパスワードがあります。 ノードを構成する前に、この値を変更する必要があります。 |
| 3 | コンソールでのビデオ メッシュ ノードのネットワーク構成の設定 仮想マシンでノードをセットアップするときに設定しなかった場合は、この手順を使用してビデオ メッシュ ノードのネットワーク設定を構成します。 静的 IP アドレスを設定し、FQDN/ホスト名と NTP サーバを変更します。 DHCP は現在サポートされていません。 |
| 4 | 次の手順を使用して、デュアル ネットワーク インターフェイス（デュアル NIC）展開の外部インターフェイスを設定します。 ノードがオンラインに戻り、内部ネットワーク構成を確認した後、ネットワークの DMZ にビデオ メッシュ ノードを展開している場合は、外部ネットワーク インターフェイスを設定して、エンタープライズ（内部）トラフィックを外部（外部）トラフィックから分離できます。 また、デフォルトのルーティング ルールに例外やオーバーライドを設定することもできます。 |
| 5 | ビデオ メッシュ ノードを Webex Cloud に登録する この手順を使用して、ビデオ メッシュ ノードを Webex クラウドに登録し、追加の設定を完了します。 Control Hub を使用してノードを登録する場合、ノードが割り当てられているクラスタを作成します。 クラスタは一つ以上のメディア ノードを有し、ユーザーに特定の地理的なエリアでサービスを提供します。 登録手順はまた、SIP 通話設定を構成し、アップグレード スケジュールを設定し、メール通知をサブスクライブします。 |
| 6 | 次のタスクを使用して、Quality of Service（QoS）を有効にして検証します。
ビデオ メッシュ ノードがオーディオ (EF) とビデオ (AF41) の両方に対して SIP トラフィック (オンプレミス SIP 登録エンドポイント) を適切なサービス クラスで個別に自動的にマークし、特定のメディア タイプに既知のポート範囲を使用する場合は、QoS を有効にします。 この変更で、 QoS ポリシーを作成し、必要に応じてクラウドからリターン トラフィックを効果的に記述します。 Reflector Tool の手順を使用して、ファイアウォールで正しいポートが開かれていることを確認します。 |
| 7 |
ビデオ メッシュと統合するプロキシのタイプを指定するには、次の手順を使用します。 透過的な検査プロキシを選択した場合は、ノードのインターフェイスを使用して、ルート証明書をアップロードしてインストールし、プロキシを確認し、潜在的な問題をトラブルシューティングできます。 |
| 8 | ビデオメッシュをコール制御タスクフローと統合するに従い、コール制御、セキュリティ要件、およびビデオメッシュをコール制御環境に統合するかどうかに応じて、次のいずれかを選択します。
SIP デバイスは直接到達性をサポートしていないため、オンプレミスの登録済みの SIP デバイスとビデオ メッシュ クラスタ間の関係を確立するには、Unified CM または VCS Expressway 設定を使用する必要があります。 コール制御環境に応じて、Unified CM または VCS Expressway をビデオ メッシュ ノードにトランクするだけで済みます。 |
| 9 | Unified CM とビデオ メッシュ ノード間の証明書チェーンの交換 このタスクでは、Unified CM およびビデオ メッシュ インターフェイスから証明書をダウンロードし、証明書をアップロードします。 このステップでは、2 つの製品間のセキュアな信頼を確立し、セキュアなトランク構成と組み合わせて、組織内の暗号化された SIP トラフィックと SRTP メディアがビデオ メッシュ ノードに着陸できるようにします。 |
| 10 | 組織とビデオ メッシュ クラスタのメディア暗号化を有効にする 組織および個々のビデオ メッシュ クラスタのメディア暗号化をオンにするには、次の手順を使用します。 この設定により、エンドツーエンドの TLS セットアップが強制され、ビデオ メッシュ ノードを指すセキュアな TLS SIP トランクが Unified CM 上に配置されている必要があります。 |
| 11 |
Webex ミーティングのビデオ メッシュ ノードに最適化されたメディアを使用して、すべての Webex アプリとデバイスに参加するには、Webex サイトでこの設定を有効にする必要があります。 この設定を有効にすると、クラウド内のビデオ メッシュとミーティング インスタンスがリンクされ、ビデオ メッシュ ノードからカスケードが発生します。 この設定が有効になっていない場合、Webex アプリとデバイスは Webex ミーティングのビデオ メッシュ ノードを使用しません。 |
| 12 | |
| 13 | セキュアなエンドポイント上でミーティングのエクスペリエンスを確認する エンドツーエンドの TLS セットアップでメディア暗号化を使用している場合は、これらの手順を使用して、エンドポイントが安全に登録され、正しいミーティングエクスペリエンスが表示されていることを確認します。 |
ビデオ メッシュの一括プロビジョニング スクリプト
ビデオ メッシュ展開で多くのノードを展開する必要がある場合は、プロセスに時間がかかります。 https://github.com/CiscoDevNet/webex-video-mesh-node-provisioning のスクリプトを使用して、VMWare ESXi サーバーにビデオ メッシュ ノードをすばやく展開できます。 スクリプトを使用する手順については、readme ファイルをお読みください。
ビデオ メッシュ ノード ソフトウェアのインストールと設定
VMware ESXi または vCenter を実行しているホスト サーバにビデオ メッシュ ノードを展開するには、次の手順を使用します。 ノードを作成するソフトウェアをオンプレミスにインストールし、ネットワーク設定などの初期設定を実行します。 後でクラウドに登録できます。
以前にダウンロードしたバージョンを使用するのではなく、Control Hub (https://admin.webex.com) からソフトウェアパッケージ (OVA) をダウンロードする必要があります。 この OVA は Cisco 証明書によって署名され、顧客管理者の資格情報を使用して Control Hub にサインインした後にダウンロードできます。
始める前に
サポートされているハードウェア プラットフォームおよびビデオ メッシュ ノードの仕様要件については、「ビデオ メッシュ ノード ソフトウェアのシステムおよびプラットフォーム要件」を参照してください。
これら必要条件を確認します:
以下のコンピューター:
VMware vSphere クライアント 7 または 8。
サポートされているオペレーション システムのリストは、VMware 文書を参照してください。
ビデオ メッシュ ソフトウェア OVA ファイルをダウンロードしました。
以前にダウンロードしたバージョンではなく、Control Hub から最新のビデオ メッシュ ソフトウェアをダウンロードします。 このリンクからソフトウェアにアクセスすることもできます（ファイルは約1.5GBです）。
古いバージョンのソフトウェアパッケージ (OVA) は、最新のビデオ メッシュ アップグレードと互換性がありません。 これにより、アプリケーションのアップグレード中に問題が発生する可能性があります。 このリンクから最新バージョンのOVAファイルをダウンロードしてください。
VMware ESXi または vCenter 7 または 8 がインストールされ、実行されているサポートされているサーバ
仮想マシンのバックアップとライブ移行を無効にします。 ビデオ メッシュ ノード クラスタはリアルタイム システムです。仮想マシンが一時停止すると、これらのシステムが不安定になります。 (ビデオ メッシュ ノードでのメンテナンス作業については、Control Hub のメンテナンスモードを使用してください。)
| 1 | コンピュータを使用して、VMware vSphere クライアントを開き、サーバ上の vCenter または ESXi システムにサインインします。 | ||||
| 2 | に移動 だ | ||||
| 3 | の OVFテンパートを選択ページで、［ローカルファイル］をクリックし、次に［ファイルを選択］をクリックします。 videomesh.ovaファイルが保存されている場所に移動し、ファイルを選択して、［次へ］をクリックします。
| ||||
| 4 | の 名前とフォルダを選択ページ、を入力します 仮想マシン名 ビデオ メッシュ ノード (「Video_Mesh_Node_1」など) で、仮想マシン ノードの展開が可能な場所を選択し、「次へだ 検証チェックが実行されます。 完了すると、テンプレートの詳細が表示されます。 | ||||
| 5 | テンプレートの詳細を確認し、［次へ］をクリックします。 | ||||
| 6 | の 設定ページで、展開設定のタイプを選択し、をクリックします。 次へだ
オプションは、リソース要件の増加順に一覧になっています。
| ||||
| 7 | の ストレージを選択ページで、Thick Provision Lazy ZeroedのデフォルトのディスクフォーマットとDatastore DefaultのVMストレージポリシーが選択されていることを確認し、次へだ | ||||
| 8 | の ネットワークを選択ページで、エントリのリストからネットワークオプションを選択し、仮想マシンへの接続を提供します。
DMZ 展開では、デュアル ネットワーク インターフェイス（NIC）を使用してビデオ メッシュ ノードを設定できます。 この展開では、内部エンタープライズ ネットワーク トラフィック（Interbox 通信、ノード クラスタ間のカスケード、およびノードの管理インターフェイスにアクセスするために使用されます）を外部クラウド ネットワーク トラフィック（外部世界への接続に使用され、Webex へのカスケード）から分離できます。 クラスタ内のすべてのノードはデュアル NIC モードである必要があります。シングル NIC とデュアル NIC の混合はサポートされていません。
| ||||
| 9 | [テンプレートのカスタマイズ] ページで、次のネットワーク設定を構成します。
必要に応じて、ノードにサインインした後で、ネットワーク設定の設定をスキップし、コンソールでビデオ メッシュ ノードのネットワーク設定を行う手順に従います。 | ||||
| 10 | の 完了する準備ができましたページで、入力した設定がこの手順のガイドラインと一致していることを確認し、をクリックします。 仕上げだ OVA の展開が完了すると、ビデオ メッシュ ノードが VM のリストに表示されます。 | ||||
| 11 | ビデオ メッシュ ノード VM を右クリックし、だ ビデオ メッシュ ノード ソフトウェアは、VM ホストにゲストとしてインストールされます。 コンソールにサインインし、ビデオ メッシュ ノードを設定する準備ができました。 ノード コンテナーが出てくるまでに、数分間の遅延がある場合があります。 初回起動の間、ブリッジ ファイアウォール メッセージが、コンソールに表示され、この間はサイン インできません。 |
次に行うこと
ビデオ メッシュ ノード コンソールにログインする
最初にコンソールにサイン インします。 ビデオ メッシュ ノード ソフトウェアにはデフォルトのパスワードがあります。 ノードを構成する前に、この値を変更する必要があります。
| 1 | VMware vSphere クライアントから、ビデオ メッシュ ノード VM に移動し、[コンソール] を選択します。 ビデオ メッシュ ノード VM が起動し、ログイン プロンプトが表示されます。 ログイン プロンプトが表示されない場合は、Enter を押します。 簡単にシステムが起動することを示すメッセージを確認できます。 |
| 2 | 以下のデフォルト ユーザー名とパスワードを使用して、ログインします: ビデオ メッシュ ノードに初めてログインするため、管理者のパスフレーズ (パスワード) を変更する必要があります。 |
| 3 | (現在の) パスワード欄には、(上から) デフォルトのパスワードを入力し、Enter を押します。 |
| 4 | 新しいパスワード欄には、新しいパスフレーズを入力して、Enter を押します。 |
| 5 | 新しいパスワードの修正には、新しいパスワードを再入力して、Enter を押します。 「パスワードが正常に変更されました」というメッセージが表示され、最初のビデオ メッシュ ノードの画面に、不正アクセスが禁止されているというメッセージが表示されます。 |
| 6 | Enter を押して、メイン メニューを読み込みます。 |
次に行うこと
コンソールでのビデオ メッシュ ノードのネットワーク構成の設定
仮想マシンでノードをセットアップするときに設定しなかった場合は、この手順を使用してビデオ メッシュ ノードのネットワーク設定を構成します。 静的 IP アドレスを設定し、FQDN/ホスト名と NTP サーバを変更します。 DHCP は現在サポートされていません。
OVA 展開時にネットワーク設定を構成しなかった場合は、次の手順が必要です。
| 内部インターフェイス（トラフィックのデフォルトインターフェイス）は、CLI、SIP トランク、SIP トラフィックおよびノード管理に使用されます。 外部（外部）インターフェイスは、ノードから Webex へのカスケードトラフィックとともに、Webex への HTTPS およびウェブソケット通信用です。 |
| 1 | VMware vSphere クライアントからノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 ネットワーク設定を初めてセットアップした後、ビデオ メッシュが到達可能な場合は、セキュア シェル (SSH) を使用してノード インターフェイスにアクセスできます。 | ||
| 2 | ビデオ メッシュ ノード コンソールのメイン メニューから、オプション を選択します。 2 設定の編集 をクリックし、 をクリックします。 選択するだ | ||
| 3 | ビデオ メッシュ ノードで通話が終了するプロンプトを読み、[はい] をクリックします。 | ||
| 4 | [スタティック] をクリックし、内部インターフェイス、[マスク]、[ゲートウェイ]、および [のIPアドレス] を入力します。 DNS ネットワークの 値。
| ||
| 5 | 組織の NTP サーバまたは組織で使用できる別の外部 NTP サーバを入力します。 NTP サーバを設定してネットワーク設定を保存した後、[コンソールからビデオ メッシュ ノードの健全性を確認する] の手順に従って、指定された NTP サーバを介して時間が正しく同期されていることを確認できます。
| ||
| 6 | (オプション) 必要に応じて、ホスト名またはドメインを変更します。
| ||
| 7 | [保存] をクリックし、[変更をクリックします。保存して再起動する] をクリックします。 ドメインを提供した場合、保存中に DNS 検証が実行されます。 FQDN (ホスト名およびドメイン) が提供される DNS サーバー アドレスを使用して解決できない場合、警告が表示されます。 警告を無視して保存することを選択できますが、FQDN がノードで設定された DNS に解決されるまで、コールは機能しません。 ビデオ メッシュ ノードが再起動すると、ネットワーク設定の変更が有効になります。 |
次に行うこと
ソフトウェアイメージがインストールされ、ネットワーク設定(IPアドレス、DNS、NTPなど)で設定され、エンタープライズネットワーク上でアクセス可能になると、クラウドにセキュアに登録する次のステップに進むことができます。 ビデオ メッシュ ノードで設定された IP アドレスは、エンタープライズ ネットワークからのみアクセスできます。 セキュリティの観点から、ノードは強化され、顧客管理者のみがノード インターフェイスにアクセスして設定を実行できます。
ビデオ メッシュ ノードの外部ネットワーク インターフェイスの設定
ノードがオンラインに戻り、内部ネットワーク構成を確認した後、ネットワークの DMZ にビデオ メッシュ ノードを展開している場合は、外部ネットワーク インターフェイスを設定して、エンタープライズ（内部）トラフィックを外部（外部）トラフィックから分離できます。
| 1 | ビデオ メッシュ ノード コンソールのメイン メニューから、オプション を選択します。 5 外部IPの設定 をクリックし、 をクリックします。 選択するだ | ||
| 2 | ノードで外部 IP アドレス オプションを有効にするには、[1 有効/無効]、[選択]、[はい] をクリックします。 | ||
| 3 | 最初のネットワーク設定と同様に、IPアドレス（外部）、マスク、およびゲートウェイの値を入力します。
| ||
| 4 | [保存して再起動] をクリックします。 ノードは再び再起動してデュアル IP アドレスを有効にし、次に基本的なスタティック ルーティング ルールを自動的に設定します。 これらの規則では、プライベートクラス IP アドレスとのトラフィックは内部インターフェイスを使用し、パブリッククラス IP アドレスとのトラフィックは外部インターフェイスを使用します。 後で、独自のルーティング ルールを作成できます。たとえば、オーバーライドを設定し、内部インターフェイスから外部ドメインへのアクセスを許可する必要がある場合などです。
| ||
| 5 | 内部および外部IPアドレスの設定を検証するには、コンソールのメインメニューから［4 Diagnostics］に移動し、［Ping］を選択します。 | ||
| 6 | pingフィールドに、テストする接続先アドレス（外部接続先や内部IPアドレスなど）を入力し、［OK］をクリックします。
|
次に行うこと
ビデオ メッシュ ノード API
ビデオ メッシュ ノード API を使用すると、組織管理者はビデオ メッシュ ノードに関連するパスワード、内部および外部のネットワーク設定、メンテナンス モード、サーバ証明書を管理できます。 これらのAPIは、Postmanのような任意のAPIツールを介して呼び出すことができます。 ユーザは、適切なエンドポイント（ノード IP または FQDN のいずれかを使用できます）、メソッド、ボディ、ヘッダー、承認などを使用して API を呼び出し、必要なアクションを実行し、以下の情報に従って適切な応答を取得する必要があります。
VMN 管理 API
ビデオ メッシュ管理 API を使用すると、組織管理者はビデオ メッシュ ノードのメンテナンス モードと管理者アカウント パスワードを管理できます。
メンテナンスモードのステータスを取得する
現在のメンテナンスモードのステータスを取得します (予想されるステータス: オン、オフ、保留中、または要求)
[GET] https://<node_ip>/api/v1/external/maintenanceMode
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Success"
},
"result": {
"isRegistered": true,
"maintenanceMode": "pending/requested/on/off",
"maintenanceModeLastUpdated": 1691135731847
}
}サンプル応答2:
{
"status": {
"code": 401,
"message": "login failed: incorrect password or username"
}
}サンプル応答3:
{
"status": {
"code": 429,
"message": "Too Many Requests"
}
}メンテナンスモードを有効または無効にする
ビデオ メッシュ ノードをメンテナンス モードにすると、コール サービスが適切にシャットダウンされます（新しいコールの受け入れを停止し、既存のコールが完了するまで最大 2 時間待機します）。
[PUT] https://<node_ip>/api/v1/external/maintenanceMode
| アクティブコールがない場合にのみ、この API を呼び出します。 |
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"maintenanceMode": "on"
}maintenanceMode - 設定するメンテナンスモードのステータス - "on" または "off"。
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Your request to enable/disable maintenance mode was successful."
}
}サンプル応答2:
{
"status": {
"code": 409,
"message": "Maintenance Mode is already on/off"
}
}サンプル応答3:
{
"status": {
"code": 400,
"message": "Bad Request - wrong input"
}
}管理者パスワードの変更
管理者ユーザーのパスワードを変更します。
[PUT] https://<node_ip>/api/v1/external/password
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"newPassword": "new"
}newPassword- ビデオ メッシュ ノードの「管理者」アカウントに設定する新しいパスワード。
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully set the new passphrase for user admin."
}
}サンプル応答2:
{
"status": {
"code": 400,
"message": "Enter a new passphrase that wasn't used for one of the previous 3 passphrases."
}
}VMN ネットワーク API
ビデオ メッシュ ネットワーク API を使用すると、組織管理者は内部および外部のネットワーク設定を管理できます。
外部ネットワーク構成の取得
外部ネットワークが有効または無効になっているかどうかを検出します。 外部ネットワークが有効になっている場合、外部 IP アドレス、外部サブネットマスク、外部ゲートウェイも取得します。
[GET] https://<node_ip>/api/v1/external/externalNetwork
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully fetched external network configuration."
},
"result": {
"ip": "1.1.1.1",
"mask": "2.2.2.2",
"gateway": "3.3.3.3"
}
}サンプル応答2:
{
"status": {
"code": 200,
"message": "External network not enabled."
}
}サンプル応答3:
{
"status": {
"code": 500,
"message": "Failed to get external network configuration."
}
}外部ネットワーク設定の編集
外部ネットワーク設定を変更します。 この API を使用して、外部 IP アドレス、外部サブネットマスク、外部ゲートウェイを使用して外部ネットワークインターフェイスを設定または編集し、外部ネットワークを有効にすることができます。 また、外部ネットワークを無効にすることもできます。 外部ネットワーク設定の変更を行った後、ノードはこれらの変更を適用するために再起動します。
[PUT] https://<node_ip>/api/v1/external/externalNetwork
| これは、デフォルトの管理パスワードが変更された新しく展開されたビデオ メッシュ ノードに対してのみ設定できます。 ノードを組織に登録した後、この API を使用しないでください。 |
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
外部ネットワークの有効化:
{
"externalNetworkEnabled": true,
"externalIp": "1.1.1.1",
"externalMask": "2.2.2.2",
"externalGateway": "3.3.3.3"
}外部ネットワークの無効化:
{
"externalNetworkEnabled": false
}externalNetworkEnabled- 外部ネットワークを有効/無効にするブール値 (true または false)
externalIp - 追加する外部 IP
externalMask - 外部ネットワークのネットマスク
externalGateway - 外部ネットワークのゲートウェイ
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully saved the external network configuration. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}サンプル応答2:
{
"status": {
"code": 200,
"message": "Successfully disabled the external network. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}サンプル応答3:
{
"status": {
"code": 400,
"message": "One or more errors in the input: Value should be boolean for 'externalNetworkEnabled'"
}
}サンプル応答4:
{
"status": {
"code": 400,
"message": "External network configuration has not changed; skipping save of the external network configuration."
}
}内部ネットワークの詳細を取得する
ネットワークモード、IP アドレス、サブネットマスク、ゲートウェイ、DNS キャッシュの詳細、DNS サーバ、NTP サーバ、内部インターフェイス MTU、ホスト名、ドメインを含む内部ネットワーク構成の詳細を取得します。
[GET] https://<node_ip>/api/v1/external/internalNetwork
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully fetched internal network details"
},
"result": {
"dhcp": false,
"ip": "1.1.1.1",
"mask": "2.2.2.2",
"gateway": "3.3.3.3",
"dnsCaching": false,
"dnsServers": [
"4.4.4.4",
"5.5.5.5"
],
"mtu": 1500,
"ntpServers": [
"6.6.6.6"
],
"hostName": "test-vmn",
"domain": ""
}
}サンプル応答2:
{
"status": {
"code": 500,
"message": "Failed to get Network details."
}
}サンプル応答3:
{
"status": {
"code": 500,
"message": "Failed to get host details."
}
}DNS サーバーの編集
DNS サーバーを新しいサーバーで更新します。
[PUT] https://<node_ip>/api/v1/external/internalNetwork/dns
| この変更を行う前に、ノードをメンテナンスモードにします。 ノードをメンテナンスモードに移行する方法の詳細については、「メンテナンスモードを有効または無効にする」を参照してください。 |
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"dnsServers": "1.1.1.1 2.2.2.2"
}dnsServers - 更新される DNS サーバー。 複数のスペースで区切られた DNS サーバが許可されます。
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully saved DNS servers"
}
}サンプル応答2:
{
"status": {
"code": 409,
"message": "Requested DNS server(s) already exist."
}
}サンプル応答3:
{
"status": {
"code": 424,
"message": "Maintenance Mode is not enabled. Kindly enable Maintenance Mode and try again for this node."
}
}NTP サーバの編集
NTP サーバを新しいサーバで更新します。
[PUT] https://<node_ip>/api/v1/external/internalNetwork/ntp
| この変更を行う前に、ノードをメンテナンスモードにします。 ノードをメンテナンスモードに移行する方法の詳細については、「メンテナンスモードを有効または無効にする」を参照してください。 |
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"ntpServers": "1.1.1.1 2.2.2.2"
}ntpServers - 更新される NTP サーバー。 複数のスペース区切りの NTP サーバが許可されます。
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully saved the NTP servers."
}
}サンプル応答2:
{
"status": {
"code": 409,
"message": "Requested NTP server(s) already exist."
}
}サンプル応答3:
{
"status": {
"code": 424,
"message": "Maintenance Mode is not enabled. Kindly enable Maintenance Mode and try again for this node."
}
}ホスト名とドメインを編集する
ビデオ メッシュ ノードのホスト名とドメインを更新します。
[PUT] https://<node_ip>/api/v1/external/internalNetwork/host
| この変更を行う前に、ノードをメンテナンスモードにします。 ノードが再起動して変更を適用します。 ノードをメンテナンスモードに移行する方法の詳細については、「メンテナンスモードを有効または無効にする」を参照してください。 |
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"hostName": "test-vmn",
"domain": "abc.com"
}hostName - ノードの新しいホスト名。
domain - ノードのホスト名の新しいドメイン（オプション）。
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully saved the host FQDN. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}サンプル応答2:
{
"status": {
"code": 400,
"message": "Unable to resolve FQDN"
}
}サンプル応答3:
{
"status": {
"code": 409,
"message": "Entered hostname and domain already set to same."
}
}DNS キャッシュを有効または無効にする
DNS キャッシュを有効または無効にします。 DNS チェックが解決するために 750 ms を超えることが多い場合、または Cisco サポートが推奨する場合は、キャッシュを有効にすることを検討してください。
[PUT] https://<node_ip>/api/v1/external/internalNetwork/dnsCaching
| この変更を行う前に、ノードをメンテナンスモードにします。 ノードが再起動して変更を適用します。 ノードをメンテナンスモードに移行する方法の詳細については、「メンテナンスモードを有効または無効にする」を参照してください。 |
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"dnsCaching": true
}dnsCaching - DNSキャッシュの設定。 ブール値（true または false）を受け入れます。
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully saved DNS settings changes. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}サンプル応答2:
{
"status": {
"code": 400,
"message": "One or more errors in the input: 'dnsCaching' field value should be a boolean"
}
}サンプル応答3:
{
"status": {
"code": 409,
"message": "dnsCaching is already set to false"
}
}インターフェイス MTU の編集
ノードのネットワーク インターフェイスの最大伝送ユニット（MTU）をデフォルト値 1500 から変更します。 1280 ～ 9000 の値を指定できます。
[PUT] https://<node_ip>/api/v1/external/internalNetwork/mtu
| この変更を行う前に、ノードをメンテナンスモードにします。 ノードが再起動して変更を適用します。 ノードをメンテナンスモードに移行する方法の詳細については、「メンテナンスモードを有効または無効にする」を参照してください。 |
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"internalInterfaceMtu": 1500
}internalInterfaceMtu - ノードのネットワークインターフェイスの最大伝送ユニット。 値は 1280 ～ 9000 の間である必要があります。
リクエストヘッダー:
「コンテンツタイプ」: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully saved the internal interface MTU settings. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}サンプル応答2:
{
"status": {
"code": 400,
"message": "One or more errors in the input: 'internalInterfaceMtu' field value should be a number"
}
}サンプル応答3:
{
"status": {
"code": 400,
"message": "Please enter a number between 1280 and 9000."
}
}VMN サーバ証明書 API
ビデオ メッシュ サーバ証明書 API を使用すると、組織管理者はビデオ メッシュ ノードに関連する証明書を作成、更新、ダウンロード、および削除できます。 詳細については、「Unified CM とビデオ メッシュ ノード間の証明書チェーンの交換」を参照してください。
CSR 証明書の作成
提供された詳細に基づいて、CSR（証明書署名リクエスト）証明書と秘密キーを生成します。
[POST] https://<node_ip>/api/v1/externalCertManager/generateCsr
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
{
"csrInfo":
{
"commonName": "1.2.3.4",
"emailAddress": "abc@xyz.com",
"altNames": "1.1.1.1 2.2.2.2",
"organization": "VMN",
"organizationUnit": "IT",
"locality": "BLR",
"state": "KA",
"country": "IN",
"passphrase": "",
"keyBitSize": 2048
}
}commonName - 共通の名前として与えられたビデオ メッシュ ノードの IP/FQDN。（必須）
emailAddress - ユーザーのメールアドレス。 (オプション）
altNames - サブジェクト代替名（オプション）。 複数のスペースで区切られた FQDN が許可されます。 指定されている場合は、共通名を含める必要があります。 altNames が提供されていない場合、altNames の値として commonName を取ります。
組織 - 組織/会社名。（オプション）
organizationUnit - 組織単位、部門、グループ名など（オプション）
地域 - 都市/地域。 (オプション）
州 - 州/州。 (オプション）
国 - 国/地域。 略称は2文字。 2文字以上は入力しないでください。 (オプション）
パスフレーズ - 秘密鍵パスフレーズ。 (オプション）
keyBitSize - 秘密鍵ビットサイズ。 許容される値は、デフォルトで 2048、または 4096 です。（オプション）
リクエストヘッダー:
コンテンツタイプ: 「application/json」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully generated CSR"
},
"result": {
"caCert": {},
"caKey": {
"fileName": "VideoMeshGeneratedPrivate.key",
"localFileName": "CaPrivateKey.key",
"fileLastModified": "Fri Jul 21 2023 08:12:25 GMT+0000 (Coordinated Universal Time)",
"uploadDate": 1689927145422,
"size": 1678,
"type": "application/pkcs8",
"modulus": "S4MP1EM0DULU2"
},
"certInstallRequestPending": false,
"certInstallStarted": null,
"certInstallCompleted": null,
"isRegistered": true,
"caCertsInstalled": false,
"csr": {
"keyBitsize": 2048,
"commonName": "1.2.3.4",
"organization": "VMN",
"organizationUnit": "IT",
"locality": "BLR",
"state": "KA",
"country": "IN",
"emailAddress": "abc@xyz.com",
"altNames": [
"1.1.1.1",
"2.2.2.2"
],
"csrContent": "-----BEGIN CERTIFICATE REQUEST-----\nS4MP1E_C3RT_C0NT3NT\n-----END CERTIFICATE REQUEST-----"
},
"encryptedPassphrase": null
}
}サンプル応答2:
{
"status": {
"code": 400,
"message": "Private key already exists. Delete it before generating new CSR."
}
}サンプル応答3:
{
"status": {
"code": 400,
"message": "CSR certificate already exists. Delete it before generating new CSR."
}
}サンプル応答4:
{
"status": {
"code": 400,
"message": "CSR certificate and private key already exist. Delete them before generating new CSR."
}
}サンプル応答5:
{
"status": {
"code": 400,
"message": "There were one or more errors while generating the CSR: The \"Country\" field must contain exactly two A-Z characters."
}
}CSR 証明書をダウンロード
生成された CSR 証明書をダウンロードします。
[GET] https://<node_ip>/api/v1/externalCertManager/csr
［送信してダウンロード］オプションからファイルをダウンロードすることもできます。
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
-----BEGIN CERTIFICATE REQUEST-----
S4MP1E_C3RT_C0NT3NT
-----END CERTIFICATE REQUEST-----サンプル応答2:
{
"status": {
"code": 404,
"message": "Could not download, CSR certificate does not exist."
}
}秘密鍵をダウンロード
CSR 証明書とともに生成された秘密キーをダウンロードします。
[GET] https://<node_ip>/api/v1/externalCertManager/key
［送信してダウンロード］オプションからファイルをダウンロードすることもできます。
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
-----BEGIN RSA PRIVATE KEY-----
S4MP1E_PR1V4T3_K3Y
-----END RSA PRIVATE KEY-----サンプル応答2:
{
"status": {
"code": 404,
"message": "Could not download, private key does not exist."
}
}CSR 証明書を削除する
既存の CSR 証明書を削除します。
[削除] https://<node_ip>/api/v1/externalCertManager/csr
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully deleted the CSR certificate"
}
}サンプル応答2:
{
"status": {
"code": 404,
"message": "CSR certificate does not exist."
}
}秘密鍵を削除する
既存の秘密キーを削除します。
[削除] https://<node_ip>/api/v1/externalCertManager/key
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully deleted the private key"
}
}サンプル応答2:
{
"status": {
"code": 404,
"message": "Private key does not exist."
}
}CA 署名付き証明書と秘密鍵をインストールする
提供された CA 署名付き証明書と秘密キーをビデオ メッシュ ノードにアップロードし、ノードに証明書をインストールします。
[POST] https://<node_ip>/api/v1/externalCertManager/uploadInstallCaCert
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
Body:
'form-data' を使用して、次のファイルをアップロードします。
CA 署名付き証明書 (.crt) ファイルで、キーは 'crtFile' です。
キーを「keyFile」とする秘密キー（.key）ファイル。
リクエストヘッダー:
コンテンツタイプ: 「multipart/form-data」
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully installed certificate and key. It might take a few seconds to reflect on the node."
},
"result": {
"caCert": {
"fileName": "videoMeshCsr.crt",
"localFileName": "CaCert.crt",
"fileLastModified": 1689931788598,
"uploadDate": 1689931788605,
"size": 1549,
"type": "application/x-x509-ca-cert",
"certStats": {
"version": 0,
"subject": {
"countryName": "IN",
"stateOrProvinceName": "KA",
"localityName": "BLR",
"organizationName": "VMN",
"organizationalUnitName": "IT",
"emailAddress": "abc@xyz.com",
"commonName": "1.2.3.4"
},
"issuer": {
"countryName": "AU",
"stateOrProvinceName": "Some-State",
"organizationName": "ABC"
},
"serial": "3X4MPL3",
"notBefore": "2023-07-21T09:28:19.000Z",
"notAfter": "2024-12-02T09:28:19.000Z",
"signatureAlgorithm": "sha256WithRsaEncryption",
"fingerPrint": "11:22:33:44:AA:BB:CC:DD",
"publicKey": {
"algorithm": "rsaEncryption",
"e": 65537,
"n": "3X4MPL3",
"bitSize": 2048
},
"altNames": [],
"extensions": {}
}
},
"caKey": {
"fileName": "VideoMeshGeneratedPrivate.key",
"localFileName": "CaPrivateKey.key",
"fileLastModified": 1689931788629,
"uploadDate": 1689931788642,
"size": 1678,
"type": "application/pkcs8",
"modulus": "S4MP1EM0DULU2"
},
"certInstallRequestPending": true,
"certInstallStarted": null,
"certInstallCompleted": null,
"isRegistered": true,
"caCertsInstalled": false,
"csr": {
"keyBitsize": 2048,
"commonName": "1.2.3.4",
"organization": "VMN",
"organizationUnit": "IT",
"locality": "BLR",
"state": "KA",
"country": "IN",
"emailAddress": "abc@xyz.com",
"altNames": [
"1.1.1.1",
"2.2.2.2"
],
"csrContent": "-----BEGIN CERTIFICATE REQUEST-----\nS4MP1E_C3RT_C0NT3NT\n-----END CERTIFICATE REQUEST-----"
},
"encryptedPassphrase": null
}
}サンプル応答2:
{
"status": {
"code": 400,
"message": "Could not parse the certificate file. Make sure it is a properly formatted certificate and try again."
}
}サンプル応答3:
{
"status": {
"code": 400,
"message": "Private Key does not match Certificate (different modulus)"
}
}サンプル応答4:
{
"status": {
"code": 202,
"message": "Certificate and private key PENDING installation. It might take a few seconds to reflect on the node. If the node is in maintenance mode, it will get installed once it is disabled."
}
}CA 署名付き証明書をダウンロード
ノードにインストールされた CA 署名付き証明書をダウンロードします。
[GET] https://<node_ip>/api/v1/externalCertManager/caCert
［送信してダウンロード］オプションからファイルをダウンロードすることもできます。
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
-----BEGIN CERTIFICATE-----
S4MP1E_C3RT_C0NT3NT
-----END CERTIFICATE-----サンプル応答2:
{
"status": {
"code": 404,
"message": "Could not download, CA certificate does not exist."
}
}CA 署名付き証明書を削除する
ノードにインストールされている CA 署名付き証明書を削除します。
[削除] https://<node_ip>/api/v1/externalCertManager/caCert
承認: ビデオ メッシュ ユーザー名 (admin) とパスワードを使用した基本認証。
回答の例:
サンプル応答1:
{
"status": {
"code": 200,
"message": "Successfully deleted the CA certificate."
}
}サンプル応答2:
{
"status": {
"code": 404,
"message": "CA certificate does not exist."
}
}共通 API 応答
以下に挙げるのは、上記のAPIの使用中に遭遇する可能性のあるサンプルレスポンスです。
サンプル応答1: 基本認証で提供される間違ったクレデンシャル。
{
"status": {
"code": 401,
"message": "login failed: incorrect password or username"
}
}サンプル応答2: VMN はこれらの API をサポートする必要なバージョンにアップグレードされません。
{
"status": {
"code": 421,
"message": "Misdirected Request 1:[undefined]"
}
}サンプル応答3: ヘッダーに間違った参照者が入力されました (ヘッダーが予期されなかった場合)。
{
"status": {
"code": 421,
"message": "Misdirected Request 2:[https://x.x.x.x/setup]"
}
}サンプル応答4: レート制限を超過しました。しばらくしてから試してください。
{
"status": {
"code": 429,
"message": "Too Many Requests"
}
}内部ルーティングルールと外部ルーティングルールの追加
デュアル ネットワーク インターフェイス (NIC) 展開では、外部および内部インターフェイスにユーザ定義のルート ルールを追加することで、ビデオ メッシュ ノードのルーティングを微調整できます。 デフォルトのルートはノードに追加されますが、例外を作成できます。たとえば、内部インターフェイスを介してアクセスする必要がある外部サブネットまたはホストアドレス、または外部インターフェイスからアクセスする必要がある内部サブネットまたはホストアドレスなどです。 必要に応じて、次の手順を実行します。
| 1 | ビデオ メッシュ ノード インターフェイスから、[5 外部 IP 設定] を選択し、[選択] をクリックします。 | ||
| 2 | [3 ルーティングルールの管理] を選択し、[選択] をクリックします。 このページを初めて開くと、デフォルトのシステム ルーティング ルールがリストに表示されます。 デフォルトでは、すべての内部トラフィックは内部インターフェイスを経由し、外部トラフィックは外部インターフェイスを経由します。
次の手順で、これらのルールに手動によるオーバーライドを追加できます。 | ||
| 3 | 必要に応じて次の手順に従います。
各ルールを追加すると、ユーザー定義ルールとして分類されたルーティング ルール リストに表示されます。
|
 | カスタムルーティングルールにより、他のルーティングとの競合が発生する可能性があります。 たとえば、SSH 接続をビデオ メッシュ ノード インターフェイスにフリーズするルールを定義できます。 この場合、次のいずれかを実行し、ルーティング ルールを削除または変更します。
|
ビデオ メッシュ ノードを Webex Cloud に登録する
この手順を使用して、ビデオ メッシュ ノードを Webex クラウドに登録し、追加の設定を完了します。 Control Hub を使用してノードを登録する場合、ノードが割り当てられているクラスタを作成します。 クラスタは一つ以上のメディア ノードを有し、ユーザーに特定の地理的なエリアでサービスを提供します。 登録手順はまた、SIP 通話設定を構成し、アップグレード スケジュールを設定し、メール通知をサブスクライブします。
始める前に
一旦ノードの登録を開始すると、60 分以内に完了する必要があり、そうでなければ、再び最初からやり直しになります。
ブラウザのポップアップ ブロッカーが無効になっているか、https://admin.webex.comの例外を許可していることを確認してください。
最上の結果を得るために、同じデータセンターにあるクラスタのすべてのノードを展開してください。 動作方法とベストプラクティスについては、「ビデオ メッシュのクラスタ」を参照してください。
ビデオ メッシュ ノードをクラウドに登録しているホストまたはマシンから、登録されている Webex クラウドとビデオ メッシュ IP アドレス (デュアル NIC 環境、特にビデオ メッシュ ノードの内部 IP アドレス) に接続する必要があります。
| 1 |
管理者資格情報を使用して Control Hub にサインインします。 Control Hub 管理機能は、Control Hub の管理者として定義されているユーザーのみ利用できます。 詳細については、「顧客アカウントの役割」を参照してください。 | ||
| 2 | を選択して、
| ||
| 3 | ビデオ メッシュ ノードがインストールされ、設定されていることを確認してください。 ［はい、登録する準備ができました...］をクリックし、［次へ］をクリックします。 | ||
| 4 | ［新規作成］または［クラスタを選択］で、次のいずれかを選択します。
| ||
| 5 | [FQDN または IP アドレスを入力] で、ビデオ メッシュ ノードの完全修飾ドメイン名（FQDN）または内部 IP アドレスを入力し、[次へ] をクリックします。
FQDN は IP アドレスに直接解決する必要があります。 FQDN の検証を実行して、タイプミスや設定ミスマッチを排除します。
| ||
| 6 | [アップグレードスケジュール] から、時間、頻度、およびタイムゾーンを選択します。 デフォルトは毎日のアップグレードスケジュールです。 特定の日に毎週のスケジュールに変更できます。 アップグレードが利用可能になると、ビデオ メッシュ ノード ソフトウェアは、選択した時間に自動的にアップグレードされます。
| ||
| 7 | [メール通知] で、サービスアラームとソフトウェアアップグレードに関する通知をサブスクライブする管理者のメールアドレスを追加します。 管理者のメール アドレスが自動的に追加されます。 必要に応じて削除できます。 | ||
| 8 | ビデオ品質設定をオンに切り替えて、1080p 30fps ビデオを有効にします。 この設定では、ビデオ メッシュ ノードでホストされているミーティングに参加する SIP 参加者は、すべて社内ネットワーク内にあり、高精細デバイスを使用している場合、1080p 30fps ビデオを使用できます。 この設定は、ノードのすべてのクラスタに適用されます。
| ||
| 9 | [登録を完了] の情報を読み、[ノードに移動] をクリックして Webex クラウドにノードを登録します。 新しいブラウザ タブを開き、ノードを確認します。 このステップでは、ノードの IP アドレスを使用してビデオ メッシュ ノードを保護します。 登録プロセス中に、Control Hub がビデオ メッシュ ノードにリダイレクトします。 IP アドレスを安全リストに登録する必要があります。そうしないと、登録が失敗します。 ノードがインストールされているエンタープライズ ネットワークから登録プロセスを完了する必要があります。 | ||
| 10 | [Webex ビデオ メッシュ ノードへのアクセスを許可] にチェックを入れ、[続行] をクリックします。 | ||
| 11 | [許可] をクリックします。 アカウントが検証され、ビデオ メッシュ ノードが登録され、「登録完了」というメッセージが表示され、ビデオ メッシュ ノードが Webex に登録されたことを示します。 ビデオ メッシュ ノードは、組織のエンタイトルメントに基づいてマシンの資格情報を取得します。 生成されたマシンのクレデンシャルは定期的に失効し、更新されます。 | ||
| 12 | ポータル リンクをクリックするか、タブを閉じて [ビデオ メッシュ] ページに戻ります。 [ビデオ メッシュ] ページで、登録したビデオ メッシュ ノードを含む新しいクラスタが表示されます。
この時点で、ビデオ メッシュ ノードは、認証用に発行されたトークンを使用して、セキュアなチャネルを介して Cisco クラウド サービスと通信する準備ができています。 ビデオ メッシュ ノードは、Docker Hub (docker.com、docker.io) とも通信します。 Docker は、ビデオ メッシュ ノードによって、世界中のさまざまなビデオ メッシュ ノードに配布するためのコンテナを保存するために使用されます。 Cisco だけが Docker Hub に書き込む資格情報を持っています。 ビデオ メッシュ ノードは、読み取り専用クレデンシャルを使用して Docker Hub に連絡し、アップグレード用のコンテナをダウンロードできます。
|
注意点
ビデオ メッシュ ノードと Webex 組織に登録された後の機能については、次の情報を念頭に置いてください。
新しいビデオ メッシュ ノードを展開すると、Webex アプリと Webex に登録されたデバイスは新しいノードを最大 2 時間認識しません。 クライアントは、起動中のクラスタ到達性、ネットワーク変更、またはキャッシュの有効期限を確認します。 2 時間待つか、回避策として Webex アプリを再起動するか、Webex Room または Desk デバイスを再起動します。 その後、通話アクティビティは Control Hub のビデオ メッシュ レポートでキャプチャされます。
ビデオ メッシュ ノードは単一の Webex 組織に登録されます。マルチテナント デバイスではありません。
ビデオ メッシュ ノードを使用するものと使用しないものを理解するには、ビデオ メッシュ ノードを使用する クライアントとデバイスの表を参照してください。
ビデオ メッシュ ノードは、Webex サイトまたは別の顧客またはパートナーの Webex サイトに接続できます。 たとえば、サイト A はビデオ メッシュ ノード クラスタを展開し、example1.webex.com ドメインに登録しました。 サイト A のユーザーが mymeeting@example1.webex.com にダイヤルインする場合、ビデオ メッシュ ノードを使用し、カスケードを作成できます。 サイト A のユーザーが yourmeeting@example2.webex.com にダイヤルすると、サイト A のユーザーはローカルのビデオ メッシュ ノードを使用して、サイト B の Webex 組織のミーティングに接続します。
次に行うこと
追加のノードを登録するには、次の手順を繰り返します。
アップグレードが利用可能な場合は、できるだけ早く適用することをお勧めします。 アップグレードするには、次の手順を実行します。
プロビジョニング データは、セキュアなチャネルを介して Cisco 開発チームによって Webex クラウドにプッシュされます。 プロビジョニング データが署名されます。 コンテナの場合、プロビジョニング データには、名前、チェックサム、バージョンなどが含まれます。 ビデオ メッシュ ノードはまた、セキュアなチャネルを介して Webex クラウドからプロビジョニング データを取得します。
ビデオ メッシュ ノードがプロビジョニング データを取得すると、ノードは読み取り専用のクレデンシャルで認証し、特定のチェックサムと名前を使用してコンテナをダウンロードし、システムをアップグレードします。 ビデオ メッシュ ノードで実行される各コンテナには、画像名とチェックサムがあります。 これらの属性は、セキュアなチャネルを使用して Webex クラウドにアップロードされます。
ビデオ メッシュ ノードの Quality of Service (QoS) を有効にする
始める前に
図と表でカバーされている必要なファイアウォール ポートの変更を行います。 ビデオ メッシュで使用されるポートとプロトコルを参照してください。
QoS でビデオ メッシュ ノードを有効にするには、ノードがオンラインである必要があります。 この設定を有効にすると、メンテナンスモードまたはオフライン状態のノードは除外されます。
| 1 | https://admin.webex.comの顧客ビューから] の順に選択し、ビデオ メッシュ カードの [設定の編集] をクリックします。 | ||
| 2 | [Quality of Service] までスクロールし、[Enable] をクリックします。 有効にすると、オンプレミスの SIP クライアント/エンドポイントおよび固有の DSCP マーキングを含むクラスタ内カスケードの音声とビデオに使用される大きな離散ポート範囲（オンプレミスのコール制御設定によって決定されます）を取得します。
ビデオ メッシュ ノードからのすべての SIP およびカスケード トラフィックは、音声では EF およびビデオでは AF41 でマークされます。 離散ポート範囲は、他のビデオ メッシュ ノードおよびクラウド メディア ノードへのカスケード メディアのソース ポート、および SIP クライアント メディアのソースおよび宛先ポートとして使用されます。 Webex Teams アプリとカスケードメディアは、宛先共有ポート 5004 とポート ramge 50000–53000 を引き続き使用します。
QoS ポート範囲で 1 つずつ有効になっているノードを示すステータス メッセージが表示されます。 保留中のノードを確認をクリックすると、QoSに保留中のノードのリストを表示できます。 この設定を有効にするには、ノードのコール トラフィックに応じて最大 2 時間かかる場合があります。 | ||
| 3 | 2時間後にQoSが完全に有効になっていない場合は、詳細な調査をサポートするケースを開く ノードは再起動し、新しいポート範囲で更新されます。 |
設定を無効にすると、音声とビデオの両方に使用されるポート範囲が小さく、統合されます（34000 ～ 34999）。 ビデオ メッシュ ノード（SIP、カスケード、クラウド トラフィックなど）からのすべてのトラフィックは、AF41 の単一のマーキングを取得します。
Web インターフェイスで Reflector ツールを使用してビデオ メッシュ ノード ポート範囲を確認する
リフレクタツール（Python スクリプトを介したビデオ メッシュ ノード上のサーバとクライアントの組み合わせ）は、必要な TCP/UDP ポートがビデオ メッシュ ノードから開かれているかどうかを確認するために使用されます。
始める前に
https://github.com/CiscoDevNet/webex-video-mesh-reflector-clientからReflector Tool Client（Pythonスクリプト）のコピーをダウンロードします。
スクリプトが正常に動作するには、Python 2.7.10 以降を環境で実行していることを確認してください。
現在、このツールは、ビデオ メッシュ ノードおよびクラスタ内検証への SIP エンドポイントをサポートしています。
| 1 | https://admin.webex.com の顧客ビューから、次の手順に従って、ビデオ メッシュ ノードのメンテナンス ノードを有効にします。 |
| 2 | ノードが Control Hub で [メンテナンス準備完了] ステータスを表示するのを待機します。 |
| 3 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 手順については、「Web インターフェイスからビデオ メッシュ ノードを管理する」を参照してください。 |
| 4 | 使用するプロトコルに応じて、［Reflector Tool］までスクロールし、［TCP Reflector Server］または［UDP Reflector Server］のいずれかを起動します。 |
| 5 | [Start Reflector Server] をクリックし、サーバーが正常に起動するまで待ちます。 サーバが起動すると通知が表示されます。 |
| 6 | ビデオ メッシュ ノードに到達するネットワーク上のシステム（PC など）から、次のコマンドを使用してスクリプトを実行します。
実行の最後に、必要なすべてのポートが開いている場合、クライアントは成功メッセージを表示します。
必要なポートが開いていない場合、クライアントは失敗したメッセージを表示します。
|
| 7 | ファイアウォールのポートの問題を解決してから、上記の手順を再実行します。 |
| 8 | クライアントを実行する
|
プロキシ統合用のビデオ メッシュ ノードの設定
ビデオ メッシュと統合するプロキシのタイプを指定するには、次の手順を使用します。 透過型のプロキシまたは明示的なプロキシを選択した場合、ノードのインターフェイスを使用してルート証明書をアップロードしてインストール、プロキシ接続を確認し、潜在的な問題をトラブルシューティングすることができます。
始める前に
サポートされているプロキシ オプションの概要については、「ビデオ メッシュのプロキシ サポート」を参照してください。
| 1 | ビデオ メッシュのセットアップ URL を入力 | ||||||||||
| 2 | [信頼ストアとロキシ] に移動して、次のオプションを選択します。
透過的または明示的なプロキシの次の手順に従います。 | ||||||||||
| 3 | [ルート証明書またはエンティティ終了証明書のアップロード] をクリックし、明示的または透過的検査プロキシのルート証明書を検索し、選択します。 証明書はアップロードされていますが、インストールされていません。証明書をインストールするにはノードを再起動する必要があるためです。 証明書発行者名の矢印をクリックして詳細を確認するか、間違っている場合は [削除] をクリックして、ファイルを再度アップロードしてください。 | ||||||||||
| 4 | 透過型の検査または明示的プロキシの場合、[プロキシ接続を確認する] をクリックして、ビデオ メッシュ ノードとプロキシ間のネットワーク接続性をテストします。 接続テストが失敗した場合は、エラーメッセージが表示され、問題を解決するための理由と方法が示されます。 | ||||||||||
| 5 | 接続テストが合格した後、明示的プロキシの場合、トグルをオンにして、このノードからすべてのポート 443 https 要求を明示的プロキシ経由でルーティングします。 この設定を有効にするには 15 秒かかります。 | ||||||||||
| 6 | [すべての証明書を信頼ストアにインストールする(HTTPS 明示プロキシまたは透過型のプロキシで表示される)] または [再起動](ルート証明書が追加されない場合に表示される) をクリックして、プロンプトを読み、準備が完了したら [インストール] をクリックします。 ノードが数分以内に再起動されます。 | ||||||||||
| 7 | ノードが再起動したら、必要に応じて再度サインインして、[概要] ページを開き、接続チェックを確認してすべて緑色のステータスになっていることを確認します。 プロキシ接続の確認は webex.com のサブドメインのみをテストします。 接続の問題がある場合、インストール手順に記載されているクラウド ドメインの一部がプロキシでブロックされているという問題がよく見られます。 |
ビデオ メッシュをコール制御タスク フローと統合する
ビデオ メッシュ上の Webex ミーティングの SIP ダイヤルインをルーティングするように SIP トランクを設定します。 SIP デバイスは直接到達性をサポートしていないため、オンプレミス SIP デバイスとビデオ メッシュ クラスタ間の関係を確立するために、ユニファイド CM または VCS Expressway 設定を使用する必要があります。
始める前に
一般的な導入例については、「ビデオ メッシュおよび Cisco Unified Communications Manager の展開モデル」を参照してください。
ビデオ メッシュは、Unified CM と SIP シグナリング間の TCP または TLS をサポートします。 VCS Expressway では SIP TLS はサポートされていません。
Unified CM では、各 SIP トランクは最大 16 個のビデオ メッシュ接続先（IP アドレス）をサポートできます。
Unified CM では、SIP トランク セキュリティ プロファイルの着信ポートをデフォルト（非セキュア SIP トランク プロファイル）にできます。
ビデオ メッシュは 2 つのルート パターンをサポートします。 sitename.webex.com とmeet.ciscospark.com。 他のルート パターンはサポートされていません。
ビデオ メッシュは 3 つのルート パターンをサポートします。 webex.com（ショートビデオアドレス用）、sitename.webex.com、meet.ciscospark.com 他のルート パターンはサポートされていません。
短縮ビデオアドレス形式（meet@webex.com）を使用すると、常にビデオメッシュノードが通話を処理します。 ビデオメッシュを有効にしていないサイトへの通話でも、ビデオメッシュノードが通話を処理します。
コール制御環境とセキュリティ要件に応じて、次のいずれかのオプションを選択します。
|
ビデオ メッシュの Unified CM セキュア TLS SIP トラフィック ルーティングの設定
| 1 | ビデオ メッシュ クラスタの SIP プロファイルを作成します。 | ||
| 2 | ビデオ メッシュ クラスタ用の新しい SIP トランク セキュリティ プロファイルを追加します。 | ||
| 3 | ビデオ メッシュ クラスタを指す新しい SIP トランクを追加します。
| ||
| 4 | Webex クラウド フェールオーバーの Expressway を指すために SIP トランクを作成します。
| ||
| 5 | ビデオ メッシュ クラスタへのコールの新しいルート グループを作成します。 | ||
| 6 | クラウドへのオーバーフローのために、Expressway への通話用の新しいルート グループを作成します。 | ||
| 7 | ビデオ メッシュ クラスタおよび Expressway へのコールの新しいルート リストを作成します。 | ||
| 8 | Webex ミーティングのショート ビデオ アドレス ダイヤル形式の SIP ルート パターンを作成します。 短いビデオ アドレス ダイヤル機能により、ユーザーはビデオ システムを使用して Webex ミーティングまたはイベントに参加するために、Webex サイト名を記憶する必要がなくなりました。 ミーティングまたはイベント番号を知る必要があるため、ミーティングにすばやく参加できます。 | ||
| 9 | Webex サイトの SIP ルート パターンを作成します。 | ||
| 10 | Webex アプリ ミーティングの SIP ルート パターンを作成します (下位互換性): |
ビデオ メッシュの Unified CM TCP SIP トラフィック ルーティングの設定
| 1 | ビデオ メッシュ クラスタの SIP プロファイルを作成します。 | ||
| 2 | ビデオ メッシュ クラスタ用の新しい SIP トランク セキュリティ プロファイルを追加します。 | ||
| 3 | ビデオ メッシュ クラスタを指す新しい SIP トランクを追加します。
| ||
| 4 | Expressway を宛先とする、新しい SIP トランクを作成します。
| ||
| 5 | ビデオ メッシュ クラスタへのコールの新しいルート グループを作成します。 | ||
| 6 | クラウドへのオーバーフローのために、Expressway への通話用の新しいルート グループを作成します。 | ||
| 7 | ビデオ メッシュ クラスタおよび Expressway へのコールの新しいルート リストを作成します。 | ||
| 8 | Webex ミーティングのショート ビデオ アドレス ダイヤル形式の SIP ルート パターンを作成します。 短いビデオ アドレス ダイヤル機能により、ユーザーはビデオ システムを使用して Webex ミーティングまたはイベントに参加するために、Webex サイト名を記憶する必要がなくなりました。 ミーティングまたはイベント番号を知る必要があるため、ミーティングにすばやく参加できます。 | ||
| 9 | Webex サイトの SIP ルート パターンを作成します。 | ||
| 10 | Webex アプリ ミーティングの SIP ルート パターンを作成します。 |
ビデオ メッシュの Expressway TCP SIP トラフィック ルーティングの構成
| 1 | ビデオ メッシュ クラスタを指すゾーンを作成します。 | ||||||||||||||||||||||
| 2 | Webex サイトのビデオ メッシュ クラスタのダイヤル パターンを作成します。
| ||||||||||||||||||||||
| 3 | フェールオーバーのためにクラウド Expressway を指すトラバーサル クライアントとゾーン ペアを作成します。 | ||||||||||||||||||||||
| 4 | Expressway-E につながるトラバーサル クライアント ゾーンへのフォールバック サーチ ルールを作成します。 | ||||||||||||||||||||||
| 5 | Expressway-E から 。 [新規] をクリックして、Webex ゾーンを追加します。 X8.11 以前のバージョンでは、この目的のために新しい DNS ゾーンを作成しました。 | ||||||||||||||||||||||
| 6 | クラウド Expressway のダイヤル パターンを作成します。 | ||||||||||||||||||||||
| 7 | Expressway-C に登録された SIP デバイスの場合、ブラウザでデバイスの IP アドレスを開き、[設定（Setup）] に移動し、[SIP] までスクロールし、[タイプ] ドロップダウンから [標準] を選択します。 |
Unified CM とビデオ メッシュ ノード間の証明書チェーンの交換
証明書交換を完了して、Unified CM インターフェイスとビデオ メッシュ インターフェイスの間で双方向の信頼を確立します。 セキュアなトランク構成により、証明書は信頼できる Unified CM から組織内の暗号化された SIP トラフィックと SRTP メディアが信頼されたビデオ メッシュ ノードに着陸することを許可します。
| クラスタ化された環境では、各ノードに CA 証明書とサーバ証明書を個別にインストールする必要があります。 |
始める前に
セキュリティ上の理由から、ノードのデフォルトの自己署名証明書の代わりに、ビデオ メッシュ ノードで CA 署名証明書を使用することをお勧めします。
| 1 | ビデオ メッシュ ノード インターフェイスを開きます（IP アドレス/セットアップ、たとえば | ||||
| 2 | サーバー証明書にアクセスし、必要に応じて証明書とキーペアをリクエストしてアップロードします。
| ||||
| 3 | 別のブラウザタブで、Cisco Unified OS Administration から 。 検索条件を入力し、［検索］をクリックし、証明書または証明書信頼リスト（CTL）のファイル名を選択し、［ダウンロード］をクリックします。 Unified CM ファイルを覚えやすい場所に保存し、Unified CM インスタンスをブラウザ タブで開いたままにしておきます。 | ||||
| 4 | [ビデオ メッシュ ノード インターフェイス] タブに戻り、[信頼ストアとプロキシ] をクリックし、オプションを選択します。
クラウドに登録されたビデオ メッシュ ノードが正常にシャットダウンし、通話が終了するまで最大 2 時間待機します。 CallManager.pem 証明書をインストールするには、ノードが自動的に再起動します。 オンラインに戻ると、CallManager.pem 証明書がビデオ メッシュ ノードにインストールされるとプロンプトが表示されます。 その後、ページを再読み込みして新しい証明書を表示できます。 | ||||
| 5 | [Cisco Unified OS の管理] タブに戻り、[証明書のアップロード/証明書チェーン] をクリックします。 [証明書の目的] ドロップダウン リストから証明書名を選択し、ビデオ メッシュ ノード インターフェイスからダウンロードしたファイルを参照して、[開く] をクリックします。 | ||||
| 6 | ファイルをサーバーにアップロードするには、［ファイルのアップロード］をクリックします。 証明書チェーンをアップロードする場合は、チェーン内のすべての証明書をアップロードする必要があります。
|
組織とビデオ メッシュ クラスタのメディア暗号化を有効にする
組織および個々のビデオ メッシュ クラスタのメディア暗号化をオンにするには、次の手順を使用します。 この設定により、エンドツーエンドの TLS セットアップが強制され、ビデオ メッシュ ノードを指すセキュアな TLS SIP トランクが Unified CM 上に配置されている必要があります。
設定 | 結果 |
|---|---|
Unified CM はセキュアなトランクで構成されており、このビデオ メッシュ コントロール ハブ設定は有効になっていません。 | コールが失敗します。 |
Unified CM はセキュアなトランクで構成されておらず、このビデオ メッシュ コントロール ハブ設定が有効になっています。 | コールは失敗しませんが、非セキュア モードに戻ります。 |
| Cisco エンドポイントは、エンドツーエンド暗号化が機能するように、セキュリティ プロファイルと TLS ネゴシエーションで設定する必要があります。 それ以外の場合は、TLS で設定されていないエンドポイントからクラウドにコールがオーバーフローします。 すべてのエンドポイントが TLS を使用するように設定できる場合にのみ、この機能を有効にすることを推奨します。 |
| 1 | https://admin.webex.comの顧客ビューから］を選択し、ビデオメッシュカードの［設定］をクリックします。 |
| 2 | [メディア暗号化] までスクロールし、設定をオンに切り替えます。 この設定により、組織のビデオ メッシュ ノードを通過するすべてのメディア チャネルで暗号化が必須になります。 コールが失敗する可能性のある状況と、エンドツーエンドの暗号化が機能するために必要な状況については、前の表と注意事項に注意してください。 |
| 3 | [すべて表示] をクリックし、セキュアな SIP トラフィックを有効にする各ビデオ メッシュ クラスタで次の手順を繰り返します。 |
Webex サイトのビデオ メッシュを有効にする
Webex ミーティングのビデオ メッシュ ノードに最適化されたメディアを使用して、すべての Webex アプリとデバイスに参加するには、Webex サイトでこの設定を有効にする必要があります。 この設定を有効にすると、クラウド内のビデオ メッシュとミーティング インスタンスがリンクされ、ビデオ メッシュ ノードからカスケードが発生します。 この設定が有効になっていない場合、Webex アプリとデバイスは Webex ミーティングのビデオ メッシュ ノードを使用しません。
| 1 | https://admin.webex.comの顧客ビューから、[ミーティング]カードからWebexサイトをクリックし、[設定]をクリックします。 |
| 2 | ［サービス］>［ミーティング］>［サイト設定］の順にクリックし、共通設定にアクセスします。 ［共通設定］から、［Cloud Collaboration Meeting Rooms（CMR）］をクリックし、［メディアリソースタイプ］の［ビデオメッシュ］を選択し、下部の［保存］をクリックします。
この設定は、クラウド内のビデオ メッシュとミーティング インスタンスをリンクし、ビデオ メッシュ ノードからカスケードを実行できるようにします。 設定は 15 分後に環境全体に入力されます。 この変更が入力された後に開始される Webex ミーティングは、新しい設定をピックアップします。 このフィールドをクラウド（デフォルトのオプション）に設定したままにしておくと、すべてのミーティングがクラウドでホストされ、ビデオ メッシュ ノードは使用されません。 |
Webex アプリ ユーザーにコラボレーション ミーティング ルームを割り当てる
セキュアなエンドポイント上でミーティングのエクスペリエンスを確認する
これらの手順を使用して、エンドポイントがセキュアに登録され、適切なミーティング エクスペリエンスが実現していることを確認してください。
| 1 | セキュアなエンドポイントからミーティングに参加します。 |
| 2 | デバイスにミーティングの名簿が表示されていることを確認します。 この例は、ミーティング リストがタッチパネルのあるエンドポイントでどのように表示されるかを示しています。
|
| 3 | ミーティング中に、[通話の詳細] から Webex 会議に関する情報にアクセスします。 |
| 4 | 暗号化セクションで [タイプ] が [AES-128] であり、[ステータス] が [オン] であることを確認します。
|
ビデオ メッシュ分析
アナリティクスは、Webex 組織のオンプレミスのビデオ メッシュ ノードとクラスタの使用方法に関する情報を提供します。 メトリクス ビューの履歴データを使用すると、オンプレミス リソースの容量、使用率、可用性を監視することで、ビデオ メッシュ リソースをより効果的に管理できます。 この情報を使用して、クラスタにビデオ メッシュ ノードを追加したり、新しいクラスタを作成したりするための決定を行うことができます。 ビデオ メッシュ アナリティクスは、Control Hub の 。
組織内のデータ分析をサポートするには、グラフのデータを拡大し、特定の時間帯のみ取り出すことができます。 分析については、レポートをスライス&ダイスして、より細分化した詳細を表示することもできます。
| ビデオ メッシュ アナリティクスおよびトラブルシューティング レポートは、ローカル ブラウザーに設定されているタイム ゾーンでデータを表示します。 |
分析
ビデオ メッシュ アナリティクスは、エンゲージメント、リソース使用率、帯域幅使用率のカテゴリで、長期的な傾向（最大 3 か月のデータ）を提供します。
ライブモニタリング
ライブ モニタリング タブは、組織内のアクティビティをほぼリアルタイムで表示します。 最大 1 分の集計と、すべてのクラスターまたは特定のクラスターの過去 4 時間または 24 時間を表示することができます。 Control Hub のこのタブは、過去 4 時間の間 1 分ごと、過去 24 時間の間 10 分ごとに自動的に更新されます。
ビデオ メッシュ ライブ モニタリング レポートへのアクセス、フィルタリング、保存
ビデオ メッシュがアクティブで、少なくとも 1 つの登録済みビデオ メッシュ ノードを持つクラスタがある場合、ビデオ メッシュ ライブ モニタリング レポートは、Control Hub (https://admin.webex.com) の [トラブルシューティング] ページで利用できます。
| 1 | https://admin.webex.com の顧客ビューから [アナリティクス] を選択し、画面の右上にある [ビデオ メッシュ] をクリックします。
| ||||
| 2 | 左側のトグルから、データの表示時間を絞り込むオプションを選択します。
| ||||
| 3 | 必要に応じて次のオプションを使用して、チャートと対話します。
| ||||
| 4 | レポートでデータをフィルタリングした後、詳細をクリックします
|
の上にカーソルを合わせると、チャートの簡単な説明が表示されます。
ビデオ メッシュ アナリティクスのアクセス、フィルター、保存
ビデオ メッシュ メトリック レポートは、ビデオ メッシュがアクティブで、少なくとも 1 つの登録済みビデオ メッシュ ノードを持つクラスタがある場合、Control Hub ( https://admin.webex.com) の [分析] ページで利用できます。
| 1 | https://admin.webex.com の顧客ビューから [アナリティクス] を選択し、画面の右上にある [ビデオ メッシュ] をクリックします。 | ||||||
| 2 | 探しているデータの種類に応じて、カテゴリをクリックします。
| ||||||
| 3 | 右側のドロップダウンリストから、オプションを選択して、データを表示したい時間を絞り込むことができます。
| ||||||
| 4 | 次のオプションを使用して、必要に応じてチャートやドーナツ グラフを操作することができます。
| ||||||
| 5 | レポートでデータをフィルタリングした後、詳細をクリックします
| ||||||
| 6 | アナリティクス ビューをリセットする場合は、フィルター バーからすべてのフィルタを消去します。 |
ビデオ メッシュで利用可能な分析
Control Hub で使用可能な分析の詳細については、「Analytics for Your Cloud Collaboration Portfolio」の「ビデオ メッシュ」セクションを参照してください。
ビデオメッシュの監視ツール
監視ツールコントロールハブ組織がビデオ メッシュ展開の健全性を監視するのに役立ちます。 ビデオ メッシュ ノード、クラスター、またはその両方で以下のテストを実行して、特定のパラメータに対する結果を得ることができます。
シグナリング テスト- SIP シグナリングおよびメディア シグナリングがビデオ メッシュ ノードとWebexクラウド メディア サービス間で発生するかどうかをテストします。
カスケード テスト- ビデオ メッシュ ノードとWebexクラウド メディア サービス間でカスケードが確立できるかどうかをテストします。
到達可能性テスト- ビデオ メッシュ ノードがWebexクラウド メディア サービスのメディア ストリームの宛先ポートに到達できるかどうかをテストします。 また、ビデオ メッシュ ノードがこれらのポートを介してメディア コンテナに関連付けられたクラウド クラスターと通信できるかどうかもテストします。
テストを実行すると、ツールはシミュレートされたミーティングを作成します。 テストが終了すると、レポートにトラブルシューティングのヒントを含むシンプルな合格または不合格の結果が表示されます。 テストを定期的に実行するようにスケジュール設定することも、オンデマンドでテストを実行することもできます。 詳細については、次のサイトを参照してください。ビデオ メッシュのメディア ヘルス モニタリングを選択します。
即時テストを実行
この手順を使用して、Control Hub 組織に登録されたビデオ メッシュ ノードおよび/またはクラスタ上で、オンデマンドのメディアの健全性のモニタリングと到達可能性テストを実行します。 結果は Control Hub でキャプチャされ、00:00 UTC から開始して 6 時間ごとに集計されます。
| 1 | ログインするコントロールハブを表示し、を選択します。 | ||
| 2 | ブラウザのテストを設定に移動し、今すぐテストに移動し、テストするノードやクラスターをチェックします。
| ||
| 3 | クリックテストを実行を選択します。 |
次に行うこと
結果は Control Hub のモニタリング ツールの概要ページに表示されます。 デフォルトでは、すべてのテストの結果が一緒に表示されます。 ブラウザの署名、カスケード接続、または到達可能性を使用して、特定のテストに従って結果をフィルタリングします。
スライダ付きのタイムライン上の点は、組織全体のテスト結果の集計を示します。 クラスタ レベルのタイムラインには、各クラスタの集計結果が表示されます。
| タイムラインには、米国のフォーマットで日付が表示される場合があります。 プロファイル設定で言語を変更すると、ローカル形式で日付が表示されます。 |
タイムライン上の点の上にカーソルを合わせて、テスト結果を表示します。 各ノードの詳細なテスト結果も確認できます。 クラスタレベルのタイムラインのポイントをクリックすると、詳細な結果が表示されます。
結果はサイドパネルに表示され、シグナリング、カスケード、到達可能性に分類されます。 テストが成功したかどうか、スキップされたかどうか、またはテストが失敗したかどうかを表示することができます。 修正の可能性を含むエラーコードも結果と共に表示されます。
用意されているトグルを使用して、さまざまなパラメータの成功率を表形式で表示します。
| スキップされたテスト、部分的な失敗、または失敗は、一定期間継続して発生しない限り、重要ではありません。 |
定期テストを設定する
この手順を使用して、定期的なメディア ヘルス モニタリングと到達可能性テストを設定し、開始します。 これらのテストは、デフォルトで 6 時間ごとに実行されます。 これらのテストは、クラスタ全体、クラスタ固有、またはノード固有のレベルで実行できます。 結果は Control Hub でキャプチャされ、00:00 UTC から開始して 6 時間ごとに集計されます。
| 1 | ログインするコントロールハブを表示し、を選択します。 |
| 2 | ブラウザのテストを設定に移動し、定期テストに移動し、テストするノードやクラスターをチェックします。 |
| 3 | オプションを選択します。
|
| 4 | [次へ] をクリックします。 |
| 5 | クラスタとノードのリストを確認して、定期的なテストを実行します。 以上の条件をクリアしたら、次をクリックします。設定をクリックして、現在の構成をスケジュールします。 |
次に行うこと
結果は Control Hub のモニタリング ツールの概要ページに表示されます。 デフォルトでは、すべてのテストの結果が一緒に表示されます。 ブラウザの署名、カスケード接続、または到達可能性を使用して、特定のテストに従って結果をフィルタリングします。
スライダ付きのタイムライン上の点は、組織全体のテスト結果の集計を示します。 クラスタ レベルのタイムラインには、各クラスタの集計結果が表示されます。
| タイムラインには、米国のフォーマットで日付が表示される場合があります。 プロファイル設定で言語を変更すると、ローカル形式で日付が表示されます。 |
タイムライン上の点の上にカーソルを合わせて、テスト結果を表示します。 各ノードの詳細なテスト結果も確認できます。 クラスタレベルのタイムラインのポイントをクリックすると、詳細な結果が表示されます。
結果はサイドパネルに表示され、シグナリング、カスケード、到達可能性に分類されます。 テストが成功したかどうか、スキップされたかどうか、またはテストが失敗したかどうかを表示することができます。 修正の可能性を含むエラーコードも結果と共に表示されます。
用意されているトグルを使用して、さまざまなパラメータの成功率を表形式で表示します。
| スキップされたテスト、部分的な失敗、または失敗は、一定期間継続して発生しない限り、重要ではありません。 |
ビデオ メッシュ ノード ミーティングでオンプレミス SIP デバイスの 1080p HD ビデオを有効にする
この設定により、組織はオンプレミスの登録済みの SIP エンドポイントに 1080p の高精細ビデオを使用でき、ミーティングの容量が少なくなります。 ビデオ メッシュ ノードがミーティングを主催する必要があります。 参加者は以下の条件で 1080p 30fps ビデオを使用できます。
すべて会社のネットワークの中にあります
オンプレミスの登録済み高精細対応 SIP デバイスを使用しています。
この設定は、ビデオ メッシュ ノードを含むすべてのクラスタに適用されます。
| クラウドに登録されたデバイスは、この設定がオンまたはオフになっていても、1080p ストリームの送受信を続けます。 |
| 1 | https://admin.webex.comの顧客ビューから］を選択し、ビデオメッシュカードの［設定］をクリックします。 |
| 2 | [ビデオ品質] をトグルさせます。 この設定がオフの場合、デフォルトは 720p です。 |
Webex アプリがサポートするビデオ解像度については、「通話とミーティングのビデオ仕様」を参照してください。
プライベート ミーティング
プライベート ミーティング機能は、オンプレミスのメディアを終結させることにより、ミーティングのセキュリティを強化します。 プライベートミーティングをスケジュールする場合、メディアはクラウドにカスケードすることなく、常に企業ネットワーク内のビデオ メッシュ ノードで終結します。
ここに示すように、プライベート ミーティングはメディアをクラウドにカスケードすることはありません。 メディアはビデオ メッシュ クラスタで完全に終了します。 ビデオ メッシュ クラスタは、相互にのみカスケードできます。
プライベート ミーティング用のビデオ メッシュ クラスタを予約できます。 予約済みクラスタがいっぱいになると、プライベート ミーティング メディアは他のビデオ メッシュ クラスタにカスケードアウトします。 予約済みクラスタがいっぱいになると、プライベート ミーティングと非プライベート ミーティングは、残りのクラスタのリソースを共有します。
プライベート ミーティング以外のミーティングでは、予約済みクラスタを使用せず、プライベート ミーティングにこれらのリソースを予約します。 プライベート ミーティング以外のミーティングでネットワーク上のリソースが不足している場合、代わりに Webex クラウドにカスケードアウトします。
| フル機能の Webex エクスペリエンスが有効になっている Webex アプリは、ビデオ メッシュと互換性がありません。 詳細については、「ビデオ メッシュ ノードを使用するクライアントとデバイス」を参照してください。 |
プライベート ミーティングのサポートと制限
ビデオ メッシュは次のようにプライベート ミーティングをサポートします。
プライベート ミーティングは Webex バージョン 40.12 以降で利用できます。
プライベート ミーティング タイプを使用できるのは、スケジュールされたミーティングのみです。 詳細については、「Cisco Webex プライベートミーティングをスケジュール」の記事を参照してください。
Webex アプリから開始または参加するフル機能ミーティングでは、プライベート ミーティングを利用できません。
現在のビデオ メッシュでサポートされているデバイスを使用できます。
ノードは現在の画像を使用できます。 72vCPUと23vCPU。
プライベート ミーティング ロジックは、メトリクスのギャップを作成しません。 Control Hub では、プライベート ミーティング以外のミーティングと同じメトリクスを収集します。
一部のユーザーはこの機能をアクティブにしないため、組織が 90 日以内にプライベート ミーティングを持っていない場合、プライベート ミーティングのアナリティクス レポートは表示されません。
プライベート ミーティングは、ビデオ エンドポイントから 1 方向のホワイトボードをサポートします。
制限事項
プライベート ミーティングには次の制限があります。
プライベート ミーティングは音声の VoIP のみをサポートしています。 Webex Edge 音声または PSTN はサポートしていません。
プライベート ミーティングにパーソナル会議室 (PMR) を使用することはできません。
プライベート ミーティングは、クラウド録画、文字起こし、Webex Assistant など、クラウドへの接続を必要とする Webex 機能をサポートしていません。
Webex アプリとペアリングされている未認証のクラウド登録ビデオ システムからプライベート ミーティングに参加することはできません。
デフォルトのミーティング タイプとしてプライベート ミーティングを使用する
Control Hub で、組織の今後のスケジュール済みミーティングをプライベート ミーティングに指定できます。
| 1 | https://admin.webex.comの顧客ビューから。 |
| 2 | ビデオメッシュカードから設定の編集をクリックします。 [ プライベート ミーティング ] までスクロールし、設定を有効にします。 |
| 3 | 変更を保存します。 |
この設定を有効にすると、以前にスケジュールされたミーティングも含め、組織のすべてのミーティングに適用されます。
(オプション) プライベート ミーティング用にクラスタを予約する
プライベート ミーティングと非プライベート ミーティングは通常、同じビデオ メッシュ リソースを使用します。 しかし、プライベート ミーティングはメディアをローカルに保つ必要があるため、ローカル リソースが枯渇したときに、クラウドへのオーバーフローを設定することはできません。 その可能性を軽減するために、ビデオ メッシュ クラスタをセットアップして、プライベート ミーティングのみを開催できます。
Control Hub では、プライベート ミーティングを主催するためにクラスタのみを設定します。 この設定により、非プライベート ミーティングがそのクラスタを使用できなくなります。 プライベート ミーティングは、デフォルトでそのクラスタを使用します。 クラスタにリソースが不足している場合、プライベート ミーティングは他のビデオ メッシュ クラスタにのみカスケードされます。
プライベート ミーティングから予想されるピーク使用量を処理するために、プライベート クラスタをプロビジョニングすることを推奨します。
| すべてのビデオ メッシュ クラスタをプライベート ミーティングに予約する場合、ショート ビデオ アドレス形式 (meet@your_site) を使用できません。 これらのコールは現在、適切なエラー メッセージなしで失敗します。 一部のクラスタを予約解除しておくと、ショート ビデオ アドレス形式のコールがこれらのクラスタを介して接続できます。 |
| 1 | https://admin.webex.comの顧客ビューから] の順に選択し、ビデオ メッシュ カードの [すべて表示] をクリックします。 |
| 2 | リストからビデオ メッシュ クラスタを選択し、[クラスタ設定を編集] をクリックします。 |
| 3 | [プライベートミーティング] までスクロールし、設定を有効にします。 |
| 4 | 変更を保存します。 |
プライベート ミーティングのエラー メッセージ
この表には、プライベート ミーティングに参加するときにユーザに表示される可能性のあるエラーが一覧表示されます。
エラーメッセージ | ユーザーアクション | 理由 |
|---|---|---|
外部ネットワークアクセスが拒否されました プライベート ミーティングに参加するには、社内ネットワーク上にいる必要があります。 社内ネットワーク外にあるペアリングされた Webex デバイスはミーティングに参加できません。このようなシナリオでは、ラップトップ、モバイルを社内ネットワークに接続し、ペアリングされていないモードでミーティングに参加してみてください。 | 外部ユーザーは、VPN または MRA なしで社内ネットワーク外から参加します。 | プライベート ミーティングに参加するには、外部ユーザーは VPN または MRA を介して社内ネットワークにアクセスする必要があります。 |
外部ユーザーは VPN を使用していますが、未認証のデバイスとペアリングされています。 | デバイスメディアは、VPN を介して企業ネットワークにトンネルしません。 デバイスはプライベート ミーティングに参加できません。 代わりに、VPN に接続した後、リモート ユーザーはデスクトップまたはモバイル クライアントからデバイスのペアリングされていないモードでプライベート ミーティングに参加する必要があります。 | |
使用可能なクラスタがありません このプライベート ミーティングをホストするクラスタは、最大キャパシティ、到達不可能、オフライン、または登録されていません。 IT 管理者に問い合わせてください。 | ユーザーは社内ネットワーク (オンプレミスまたは VPN によるリモート) にありますが、プライベート ミーティングに参加できません。 | ビデオ メッシュ クラスタは次のとおりです。
|
未認証 主催者組織のメンバーではないため、このプライベートミーティングに出席する権限がありません。 ミーティングの主催者に連絡してください。 | 主催者組織とは異なる組織のユーザーがプライベート ミーティングに参加しようとしています。 | 主催者組織に属するユーザーのみがプライベート ミーティングに参加できます。 |
主催者組織とは異なる組織のデバイスがプライベート ミーティングに参加しようとします。 | 主催者組織に属するデバイスのみがプライベート ミーティングに参加できます。 |
すべての外部Webexミーティングでメディアをビデオ メッシュ上に保持
メディアがローカルのビデオ メッシュ ノードを使用すると、パフォーマンスが向上し、使用するインターネット帯域幅が少なくなります。
以前のリリースでは、内部サイトのミーティングのみにビデオメッシュの使用を制御していました。 外部Webexサイトで主催されているミーティングについては、これらのサイトはビデオ メッシュがWebexにカスケードできるかどうかを管理していました。 外部サイトでビデオ メッシュのカスケードが許可されない場合、メディアは常にWebexクラウド ノードを使用していました。
で... すべての外部 Webex Meetings のビデオ メッシュを好む 設定では、Webex サイトで利用可能なビデオ メッシュ ノードがある場合、メディアは外部の Webex サイトでホストされているミーティングのそれらのノードを通じて実行されます。 本表はWebexミーティングに参加する参加者の行動をまとめたものです。
| 設定は... | ビデオ メッシュ カスケードを有効にした内部Webexサイト上のミーティング | ビデオ メッシュ カスケードが無効になっている内部Webexサイト上のミーティング | ビデオ メッシュ カスケードが有効になっている外部Webexサイト上のミーティング | ビデオ メッシュ カスケードが無効な場合の外部Webexサイト上のミーティング |
|---|---|---|---|---|
| 有効 | メディアはビデオ メッシュ ノードを使用します。 | メディアはクラウドノードを使用します。 | メディアはビデオ メッシュ ノードを使用します。 | メディアはビデオ メッシュ ノードを使用します。 |
| 無効済み | メディアはビデオ メッシュ ノードを使用します。 | メディアはクラウドノードを使用します。 | メディアはビデオ メッシュ ノードを使用します。 | メディアはクラウドノードを使用します。 |
この設定はデフォルトでオフにされており、以前のリリースの動作が維持されています。 これらのリリースでは、ビデオ メッシュはWebexにカスケードされず、参加者はWebexクラウド ノードを通じて参加しました。
| 1 | 顧客ビューhttps://admin.webex.com、に移動して、すべて表示をビデオ メッシュ カードに入力します。 |
| 2 | リストからビデオ メッシュ クラスタを選択し、設定の編集を選択します。 |
| 3 | までスクロールすべての外部Webex Meetingsでビデオ メッシュを使用する設定を有効にします。 |
| 4 | 変更を保存します。 |
ビデオ メッシュ展開の使用を最適化する
すべてのクライアントをビデオ メッシュ クラスタに配置して、ビデオ メッシュを通じてユーザー エクスペリエンスを向上させることができます。 ビデオ メッシュ クラスタの容量が一時的にダウンしている場合、または使用量が増加している場合は、ビデオ メッシュ クラスタに着陸するクライアント タイプを制御することで、ビデオ メッシュ クラスタの使用率を最適化できます。 これにより、需要を満たすためにノードを追加できるようになるまで、既存のキャパシティを効果的に管理できます。
使用状況、使用状況、リダイレクト、オーバーフローの傾向については、Control Hub のアナリティクス ポータル を参照してください。 これらの傾向に基づいて、たとえば、デスクトップ クライアントまたは SIP デバイスをビデオ メッシュ クラスタに着陸させ、モバイル クライアントを Webex クラウド ノードに着陸させることを選択できます。 モバイル クライアントと比較して、デスクトップ クライアントと SIP デバイスは、より高い解像度をサポートし、より大きな画面を持ち、より多くの帯域幅を使用し、これらのクライアント タイプを使用して参加者のユーザー エクスペリエンスを最適化できます。
また、ほとんどの顧客が使用するクライアント タイプをビデオ メッシュ クラスタ上に配置することで、クラスタ容量を最適化し、ユーザー エクスペリエンスを最大化することもできます。
| 1 | Control Hub にサインインし、します。 または 。 |
| 2 | [クライアントタイプのインクルージョン設定] で、すべてのクライアントタイプがデフォルトでチェックされます。 ビデオ メッシュ クラスタの使用から除外するクライアント タイプのチェックを外します。 これらのクラスタは Webex クラウド ノードでホストされます。 |
| 3 | [保存] をクリックします。 |
ビデオ メッシュ ノードの登録解除
| 1 | https://admin.webex.comの顧客ビューから。 |
| 2 | ビデオ メッシュ カードの すべて表示 をクリックします。 |
| 3 | リソースのリストから、適切なクラスタに移動してノードを選択します。 |
| 4 | 。 ノードを削除してよいかどうかを確認するメッセージが表示されます。 |
| 5 | メッセージを読んで理解した後、[ノードの登録解除] をクリックします。 |
ビデオ メッシュ ノードの移動
| 1 | https://admin.webex.comの顧客ビューからを選択し、ビデオメッシュカードのすべて表示を選択します。 |
| 2 | リストから、移動するノードを選択し、[アクション] (垂直楕円) をクリックします。 |
| 3 | [ノードの移動] を選択します。 |
| 4 | ノードを移動する場所に適切なオプション ボタンを選択します。
|
| 5 | [ノードの移動] をクリックします。 ノードが新しいクラスタに移動します。
|
ビデオ メッシュ クラスタのアップグレード スケジュールの設定
特定のアップグレード スケジュールを設定するか、午前 3 時のデフォルト スケジュールを使用できます。 毎日の米国: アメリカ/ロサンゼルス 必要に応じて、今後のアップグレードを延期することを選択できます。
ビデオ メッシュのソフトウェア アップグレードは、クラスタ レベルで自動的に行われ、すべてのノードが常に同じソフトウェア バージョンを実行していることを保証します。 アップグレードは、クラスタのアップグレードのスケジュールに従って行われます。 ソフトウェア アップグレードが利用可能になると、スケジュールされたアップグレード時刻の前にクラスタを手動でアップグレードできます。
始める前に
| 緊急アップグレードは、利用可能になったらすぐに適用されます。 |
| 1 | https://admin.webex.comの顧客ビューから] の順に移動し、ビデオ メッシュ カードの [すべて表示] をクリックします。 | ||
| 2 | メディア リソースをクリックし、[クラスタ設定の編集] をクリックします。 | ||
| 3 | ［設定］ページの［アップグレード］までスクロールし、アップグレード スケジュールの時間、頻度、タイムゾーンを選択します。
| ||
| 4 | （オプション）必要に応じて［延期］をクリックして、後続のウィンドウまでアップグレードを1回延期します。 タイムゾーンの下に、次に利用可能なアップグレード日時が表示されます。 |
- アップグレードの動作
-
ノードはクラウドに対して定期的に更新プログラムが利用可能か確認するようにリクエストします。
クラウドはクラスターのアップグレード ウィンドウが出るまでアップグレードが利用可能になりません。 アップグレード ウィンドウが到着すると、クラウドへのノードの次の定期的な更新要求が更新情報を提供します。
ノードは安全なチャネルで更新をプルします。.
ノードへの着信コールのルーティングを停止するには、既存のサービスが適切にシャットダウンされます。 優美なシャットダウンにより、既存のコールが完了する時間 (最大 2 時間) も与えられます。
アップグレードがインストールされます。
クラウドは、一度にクラスタ内のノードの割合のアップグレードのみをトリガーします。
ビデオ メッシュ クラスタの削除
| 1 | https://admin.webex.comの顧客ビューから］を選択し、［すべて表示］をクリックします。 | ||
| 2 | リソースのリストから、削除するビデオ メッシュ リソースまでスクロールし、[クラスタ設定の編集] をクリックします。
| ||
| 3 | [クラスタの削除] をクリックし、次のいずれかを選択します。
|
ビデオ メッシュの非アクティブ化
始める前に
ビデオ メッシュを無効にする前に、すべてのビデオ メッシュ ノードの登録を解除します。
| 1 | https://admin.webex.comの顧客ビューから、ビデオメッシュカードの設定を選択します。 |
| 2 | [非アクティブ] を選択します。 |
| 3 | クラスタのリストを確認し、ダイアログで免責事項を読みます。 |
| 4 | チェックボックスをオンにして、この操作が理解されていることを確認し、ダイアログで [非アクティブ化] をクリックします。 |
| 5 | ビデオ メッシュを無効にする準備ができたら、[サービスの無効化] をクリックします。 非アクティブ化すると、すべてのビデオ メッシュ ノードとクラスタが削除されます。 ビデオ メッシュが設定されなくなりました。 |
ビデオ メッシュ ノード登録のトラブルシューティング
このセクションには、Webex クラウドへのビデオ メッシュ ノードの登録中に発生する可能性のあるエラーと、それらを修正するための手順が記載されています。
ドメインが解決できませんでした
このメッセージは、ビデオ メッシュ ノードで設定された DNS 設定が正しくない場合に表示されます。
ビデオ メッシュ ノードのコンソールにサインインし、DNS 設定が正しいことを確認します。
Could が SSL を通じてポート 443 を使用しサイトに接続できません
このメッセージは、ビデオ メッシュ ノードが Webex クラウドに接続できない場合に表示されます。
ネットワークがビデオ メッシュに必要なポートの接続を許可していることを確認します。 詳細については、「ビデオ メッシュで使用されるポートとプロトコル」を参照してください。
ThousandEyes とビデオ メッシュの統合
ビデオ メッシュ プラットフォームは ThousandEyes エージェントと統合され、ハイブリッド デジタル エコシステム全体でエンドツーエンドのモニタリングを実行できるようになりました。 この統合により、プロキシ、ゲートウェイ、ルーターなどの領域を可視化する幅広いネットワーク監視テストが提供されます。 顧客のネットワークインフラストラクチャに沿ってどこにでも問題を絞り込み、より高い精度で診断し、展開の効率を向上させることができます。
ThousandEyesインテグレーションの利点
- 複数のテストタイプから選択できます。 監視するアプリケーションまたはアセットに適切な 1 つ以上のテストを設定できます。
- 要件に固有のテストしきい値を設定できます。
- テスト結果は、ThousandEyes WebアプリとThousandEyes APIを介してリアルタイムで利用できます。
- トラブルシューティングにおける可視性の向上 – お客様は、ネットワーク内の問題の発生元を特定できるため、解決にかかる時間を短縮できます。
ビデオ メッシュの ThousandEyes の有効化
ビデオ メッシュ展開で ThousandEyes エージェントを有効にするには、次の手順を使用します。
| 1 | Control Hub から、画面の左下にある Hybrid をクリックします。 | ||
| 2 | ビデオメッシュカードの［設定の編集］をクリックします。 | ||
| 3 | ThousandEyes インテグレーションまでスクロールダウンします。 トグルはデフォルトで無効になります。 トグルをクリックして有効にします。 | ||
| 4 | [ThousandEyesユーザープロファイル] をクリックすると、ThousandEyes ウェブポータルが開き、管理者資格情報を使用してサインインします。 | ||
| 5 | サイドパネルにはアカウントグループトークンが表示されます。 | ||
| 6 | 表示アイコンをクリックし、［コピー］をクリックします。
| ||
| 7 | [Control Hub] タブに戻り、[エージェントトークン] フィールドにトークンを貼り付けます。 | ||
| 8 | [アクティベート]をクリックすると、ビデオメッシュ展開でThousandEyesが有効になります。 |
次に行うこと
- 5分後、ThousandEyesのWebページに戻り、［クラウドおよびエンタープライズエージェント］をクリックし、［エージェント設定］をクリックします。 エンタープライズエージェントの下にエージェントとしてリストされているすべてのノードを表示できます。 エージェントが表示されない場合は、Control Hub の ThousandEyes インテグレーション カードでエラー メッセージを確認します。
- エラーメッセージが表示されたら、トグルをクリックし、［非アクティブ化］をクリックします。 ThousandEyes エージェントを有効にする手順を繰り返し、正しいアカウント グループ トークンが [エージェント トークン] フィールドにコピーおよび貼り付けられることを確認します。
| 現在、ThousandEyes テストはプロキシの背後にあるビデオ メッシュ ノードをサポートしていません。 |
ThousandEyes を使用したテストの設定
ネットワークテスト – エージェント対エージェント
エージェントツーエージェントネットワークテストにより、ThousandEyesのユーザは、監視されたパスの両端にThousandEyesエージェントを持つことができ、次の2つの方向の両方または両方でパスをテストできます。 ソースからターゲット、またはターゲットからソース。 エージェント間テストの設定方法の詳細については、「エージェント間テストの概要」を参照してください。
サンプルテスト作成ダイアログを以下に示します。
SIP サーバー テスト
SIPサーバーテストは、ネットワーク測定、BGPデータ収集、そして最も重要なことに、SIPベースのVoIPインフラストラクチャに対するSIPサービスの可用性とパフォーマンステストを容易にします。
SIP サーバテストの設定方法の詳細については、「SIP サーバテスト設定」を参照してください。
サンプルテスト作成ダイアログを以下に示します。
RTP ストリームテスト
RTP ストリーム テストは、VoIP ユーザ エージェントとして動作する 2 つの ThousandEyes エージェント間でシミュレートされた音声データ ストリームを作成します。 RTP パケットは、トランスポートプロトコルとして UDP を使用して、1 つ以上のエージェントとターゲットエージェントの間で送信され、平均オピニオンスコア（MOS）、パケット損失、破棄、遅延、およびパケット遅延バリエーション（PDV）メトリックを取得します。 生成されたメトリックは、一方向のメトリック（ターゲットへのソース）です。 RTP ストリーム テストでは、サーバ ポート、通話時間、ディジッタ バッファ サイズ、コーデックの設定オプションが提供されます。
RTP ストリームテストの設定の詳細については、「RTP ストリームテストの設定」を参照してください。
サンプルテスト作成ダイアログを以下に示します。
Webex HTTP サーバー URL テスト
このテストは、ユーザーが Webex にアクセスしたときに接続するプライマリ ランディング ページを監視します。 サンプルテスト作成ダイアログを以下に示します。
権威ある Webex DNS サーバーテスト
このテストは、Webex ドメインが内部と外部の両方で適切に解決されていることを確認するために使用されます。 エンタープライズ エージェントを使用する場合は、[DNS サーバ] フィールドを更新して、内部ネーム サーバを使用します。 外部可視化のためにクラウド エージェントを使用する場合は、[ルックアップ サーバ] ボタンを使用して、権限のある外部ネーム サーバを自動入力します。 この例では、cisco.webex.com を解決するクラウド エージェントを示しています。 組織のドメインに更新する必要があります。
サンプルテスト作成ダイアログを以下に示します。
'
Web インターフェイスからのビデオ メッシュ ノードの管理
クラウドに登録されているビデオ メッシュ ノードにネットワークを変更する前に、Control Hub を使用してメンテナンス モードにする必要があります。 手順の詳細については、「ノードをメンテナンスモードに移動」を参照してください。
| メンテナンスモードは、特定のネットワーク設定変更(DNS、IP、FQDN)を行うか、RAM、ハードドライブなどのハードウェア保守の準備ができるように、シャットダウンまたはリブート用のノードの準備のみを目的としています。 ノードがメンテナンスモードになっている場合、アップグレードは行われません。 |
ノードをメンテナンスモードにすると、コールサービスが適切にシャットダウンされます（新しいコールの受け入れを停止し、既存のコールが完了するまで最大 2 時間待機します）。 コールサービスの優雅なシャットダウンの目的は、コールのドロップを引き起こすことなくノードの再起動またはシャットダウンを許可することです。
ビデオ メッシュの概要にアクセスする方法
次のいずれかの方法で Web インターフェイスを開くことができます。
フル管理者であり、すでにノードをクラウドに登録している場合は、Control Hub からノードにアクセスできます。
https://admin.webex.comの顧客ビューから。 ビデオメッシュカードの［リソース］で、［すべて表示］をクリックします。 クラスタをクリックし、アクセスするノードをクリックします。 [ノードに進む] をクリックします。
Webex 組織のフル管理者だけがこの機能を使用できます。 パートナーや外部フル管理者など、他の管理者はビデオメッシュリソースの [ノードに進む] オプションを利用できません。
ブラウザ タブで、
<IP address>/setup例えば、https://192.0.2.0/setupです。 ノード用に設定した管理者資格情報を入力し、[ サインイン] をクリックします。管理者アカウントが無効になっている場合、この方法は利用できません。 「Web インターフェイスからローカル管理者アカウントを無効または再有効にする」セクションを参照してください。
概要は既定のページで、次の情報があります。
[コールステータス(Call Status)]:ノードを介して継続中のコールの数を提供します。
[ノードの詳細(Node Details)]:ノード タイプ、ソフトウェア イメージ、ソフトウェア バージョン、OS バージョン、QoS ステータス、およびメンテナンス モードのステータスを提供します。
[ノードの健全性(Node Health)]:使用状況データ (CPU、メモリ、ディスク)、およびサービスステータス (管理サービス、メッセージングサービス、NTP 同期) を提供します。
[ネットワーク設定(Network Settings)]:ネットワーク情報を提供します。 ホスト名、インターフェイス、IP、ゲートウェイ、DNS、NTP、およびデュアル IP が有効になっているかどうか。
[登録の詳細(Registration Details)]:登録ステータス、組織名、組織 ID、ノードが属するクラスタ、およびクラスタ ID を提供します。
クラウド接続—ノードから Webex クラウドおよびノードが正常に実行するためにアクセスする必要があるサードパーティの宛先に一連のテストを実行します。
以下の3種類のテストが実行されます。 DNS 解決、サーバー応答時間、および帯域幅。
DNS テストは、ノードが特定のドメインを解決できることを検証します。 サーバが 10 秒以内に応答しない場合、これらのテストは失敗としてレポートされます。 応答時間が1.5秒から10秒の間であれば、オレンジ色の「警告色」で「渡された」と表示されます。 DNS 応答時間が 1.5 秒を超える場合、ノードの定期的な DNS チェックはアラームを生成します。
Connect テストは、ノードが特定の HTTPS URL に接続して応答を受信できることを検証します（プロキシまたはゲートウェイエラー以外の応答は、接続のエビデンスとして受け入れられます）。
概要ページから実行されるテストのリストは完全なものではなく、websocket テストは含まれません。
通話プロセスがクラウドへの Websocket 接続を完了できない、または通話関連サービスに接続できない場合、ノードはアラームを送信します。
各テストの横に [Pass] または [Fail] の結果が表示されます。このテキストの上にカーソルを合わせると、テスト実行時にチェックされた内容の詳細を確認できます。
次のスクリーンショットに示すように、ノードによってアラームが生成された場合、アラーム通知はサイドパネルにも表示されます。 これらの通知は、ノードの潜在的な問題を特定し、これらの問題をトラブルシューティングまたは解決する方法について提案します。 アラームが生成されなかった場合、通知パネルは表示されません。
ビデオ メッシュ ノード Web インターフェイスからのネットワーク設定の構成
ネットワーク トポロジが変更された場合は、各 Webex ビデオ メッシュ ノードの Web インターフェイスを使用し、そこでネットワーク設定を変更できます。 ネットワーク設定の変更に関する注意が表示される場合がありますが、Webex ビデオ メッシュ ノード設定を変更した後で、ネットワークに変更を加える場合に備えて、変更を保存できます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 | ||
| 2 | ネットワークに移動します。 ノードの現在のネットワーク設定が表示されます。 | ||
| 3 | 必要に応じて、ホストおよびネットワーク構成の以下の設定を変更します。
| ||
| 4 | [ホストとネットワーク設定の保存] をクリックし、ノードを再起動する必要があるというポップアップが表示されたら、[保存して再起動] をクリックします。 保存中は、すべてのフィールドがサーバ側で検証されます。 一般的に表示される警告は、サーバが到達できないか、クエリ時に有効な応答が返されなかったことを示します。たとえば、FQDN が指定された DNS サーバ アドレスを使用して解決できない場合。 警告を無視することで保存を選択できますが、ノードで構成された DNS に対して FQDN を解決できるまで通話は作動しません。 別の可能なエラー状態は、ゲートウェイ アドレスが IP アドレスと同じサブネットにない場合です。 ビデオ メッシュ ノードが再起動すると、ネットワーク設定の変更が有効になります。 | ||
| 5 | 必要に応じてNTPサーバーの以下の設定を変更します。
| ||
| 6 | [NTPサーバーの保存] をクリックします。
NTP サーバが FQDN であり、解決できない場合、警告が返されます。 NTP サーバの FQDN が解決されたが、解決された IP を NTP 時間に対して照会できない場合、警告が返されます。 |
ビデオ メッシュ ノード Web インターフェイスから外部ネットワーク インターフェイスを設定する
ネットワーク トポロジが変更された場合は、各 Webex ビデオ メッシュ ノードの Web インターフェイスを使用し、そこでネットワーク設定を変更できます。 ネットワーク設定の変更に関する注意が表示される場合があります。 ただし、Webex ビデオ メッシュ ノード設定を変更した後で、ネットワークに変更を加える場合は、変更を保存できます。
ネットワークの DMZ にビデオ メッシュ ノードを展開している場合は、外部ネットワーク インターフェイスを設定して、エンタープライズ（内部）トラフィックを外部（外部）トラフィックから分離できます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ネットワークに移動します。 ノードの現在のネットワーク設定が表示されます。 |
| 3 | [詳細] をクリックします。 |
| 4 | ［外部ネットワークを有効にする］をオンに切り替えて、［OK］をクリックしてノードの外部IPアドレスオプションを有効にします。 |
| 5 | [外部IPアドレス]、[外部サブネットマスク]、[外部ゲートウェイ]の値を入力します。 |
| 6 | [外部ネットワーク設定の保存] をクリックします。 |
| 7 | ［保存して再起動］をクリックして変更を確定します。 ノードがリブートしてデュアル IP アドレスを有効にし、基本的なスタティック ルーティング ルールを自動的に設定します。 これらの規則では、プライベートクラス IP アドレスとのトラフィックは内部インターフェイスを使用し、パブリッククラス IP アドレスとのトラフィックは外部インターフェイスを使用します。 後で、独自のルーティング ルールを作成できます。たとえば、オーバーライドを設定し、内部インターフェイスから外部ドメインへのアクセスを許可する必要がある場合などです。 |
| 8 | エラーが発生した場合は、［OK］をクリックしてエラーダイアログボックスを閉じ、エラーを修正し、もう一度［外部ネットワーク設定を保存］をクリックします。 |
次に行うこと
内部および外部 IP アドレスの設定を検証するには、「ビデオ メッシュ ノード Web インターフェイスから Ping を実行する」の手順を実行します。
外部接続先（例、cisco.com）をテストします。成功した場合、結果は接続先が外部インターフェイスからアクセスされたことを示します。
内部 IP アドレスをテストします。成功した場合、結果はアドレスが内部インターフェイスからアクセスされたことを示します。
ビデオ メッシュ ノード Web インターフェイスからの内部および外部ルーティング ルールの追加
デュアル ネットワーク インターフェイス (NIC) 展開では、外部および内部インターフェイスにユーザ定義のルート ルールを追加することで、ビデオ メッシュ ノードのルーティングを微調整できます。 デフォルトのルートはノードに追加されますが、例外を作成できます。たとえば、内部インターフェイスを介してアクセスする必要がある外部サブネットまたはホストアドレス、または外部インターフェイスからアクセスする必要がある内部サブネットまたはホストアドレスなどです。 必要に応じて、次の手順を実行します。
始める前に
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 | ||
| 2 | ネットワークに移動します。 ノードの現在のネットワーク設定が表示されます。 外部ネットワークを設定した場合は、[ルーティングルール（Routing Rules）] タブが表示されます。 | ||
| 3 | [ルーティングルール] タブをクリックします。 このページを初めて開くと、デフォルトのシステム ルーティング ルールがリストに表示されます。 デフォルトでは、すべての内部トラフィックは内部インターフェイスを経由し、外部トラフィックは外部インターフェイスを経由します。 次の手順で、これらのルールに手動によるオーバーライドを追加できます。 | ||
| 4 | ルールを追加するには、［ルーティングルールの追加］をクリックし、次のいずれかのオプションを選択します。
| ||
| 5 | [ルーティングルールの追加] をクリックします。 各ルールを追加すると、ユーザー定義ルールとして分類されたルーティング ルール リストに表示されます。 | ||
| 6 | ユーザー定義のルールを 1 つ以上削除するには、ルールの左側にある列のチェックボックスをオンにして、[ルーティングルールの削除] をクリックします。
|
| カスタムルーティングルールにより、他のルーティングとの競合が発生する可能性があります。 たとえば、SSH 接続をビデオ メッシュ ノード インターフェイスにフリーズするルールを定義できます。 この場合、次のいずれかを実行し、ルーティング ルールを削除または変更します。
|
ビデオ メッシュ ノード Web インターフェイスからのコンテナ ネットワークの設定
ビデオ メッシュ ノードは、ノード内で内部使用するためのサブネット範囲を留保します。 デフォルトの範囲は 172.17.42.0 ～ 172.17.42.63 です。 ノードは、この範囲から発信された外部からビデオ メッシュ ノード トラフィックに応答しません。 ネットワーク内の他のデバイスとの競合を避けるために、ノード コンソールを使用してコンテナ ブリッジ IP アドレスを変更することができます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ネットワークに移動します。 ノードの現在のネットワーク設定が表示されます。 |
| 3 | [詳細] をクリックします。 |
| 4 | 必要に応じて、［コンテナIPアドレス］と［コンテナサブネットマスク］の値を変更し、［コンテナネットワーク設定の保存］をクリックします。 |
| 5 | ［保存して再起動］をクリックして変更を確定します。 |
| 6 | エラーが発生した場合は、［OK］をクリックしてエラーダイアログボックスを閉じ、エラーを修正し、もう一度［コンテナネットワーク設定の保存］をクリックします。 |
ネットワーク インターフェイスの設定 MTU サイズ
すべての Webex ビデオ メッシュノードは、デフォルトでパス MTU (PMTU) 探索が有効になっています。 PMTU では、ノードは MTU の問題を検出し、自動的に MTU サイズを調整することができます。 ファイアウォールまたはネットワークの問題のために PMTU が失敗した場合、MTU の数より大きいパケットがあると、ノードはクラウドへの接続に問題がある場合があります。 下位の MTU サイズを手動で設定することで、この問題を修正することができます。
始める前に
すでにノードを登録している場合は、MTU 設定を変更する前に、ノードをメンテナンスモードにする必要があります。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ネットワークに移動します。 ノードの現在のネットワーク設定が表示されます。 |
| 3 | [詳細] をクリックします。 |
| 4 | ［インターフェイスMTU設定］セクションで、該当するフィールドに1280～9000バイトのMTU値を入力します。 外部インターフェイスを有効にしている場合は、内部インターフェイスと外部インターフェイスの両方の MTU サイズを個別に設定できます。 |
次に行うこと
MTU を変更するためにノードをメンテナンスモードにした場合は、メンテナンスモードをオフにします。
DNS キャッシュを有効または無効にする
ビデオ メッシュ ノードへの DNS 応答が定期的に 750 ms 以上かかる場合、または Cisco TAC が推奨する場合は、DNS キャッシュを有効にできます。 DNSのキャッシングをオンにすると、ノードはDNSの応答をローカルにキャッシュします。 キャッシュを使用すると、要求の遅延やタイムアウトが発生しにくくなり、接続アラーム、通話ドロップ、通話品質の問題が発生する可能性があります。 DNS キャッシュは DNS インフラストラクチャの負荷を軽減することもできます。
始める前に
ノードをメンテナンス モードに変更します。 メンテナンスモードのステータスがオンの場合（アクティブ コールが保留期間の終了時に完了またはドロップした場合）、DNS キャッシュを有効または無効にできます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ネットワークに移動します。 ノードの現在のネットワーク設定が表示されます。 |
| 3 | [詳細] をクリックします。 |
| 4 | [DNS キャッシュの設定（DNS Caching Configuration）] セクションで、[DNS キャッシュを有効にする（Enable DNS Caching））] をオンまたはオフに切り替えます。 |
| 5 | 確認ダイアログで「保存して再起動」をクリックします。 |
| 6 | ノードが再起動したら、Webex ビデオ メッシュ ノード インターフェイスを再開し、[概要] ページで接続チェックが成功していることを確認します。 |
DNS キャッシュを有効にすると、DNS キャッシュ統計に次の統計が表示されます。
統計 | 説明 |
|---|---|
キャッシュ エントリ | DNS キャッシュ サーバが保存した以前の DNS 解像度の数 |
キャッシュヒット | 顧客の DNS サーバーに問い合わせることなく、キャッシュがビデオ メッシュからの DNS 要求を処理したキャッシュ リセット以降の回数 |
キャッシュミス | 顧客の DNS サーバがキャッシュを介してではなく、ビデオ メッシュからの DNS 要求を処理したキャッシュ リセット以降の回数 |
キャッシュヒット率 | キャッシュが顧客の DNS サーバーに問い合わせることなく処理したビデオ メッシュからの DNS 要求の割合 |
キャッシュ サーバのアウトバウンド DNS クエリ | ビデオ メッシュ DNS キャッシュ サーバが顧客の DNS サーバに対して作成した DNS クエリの数 |
キャッシュ サーバ着信 DNS クエリ | ビデオ メッシュが内部 DNS キャッシュ サーバに対して作成した DNS クエリの数 |
アウトバウンドからインバウンドのクエリの比率 | Video Mesh が顧客の DNS サーバに対して作成した DNS クエリと、内部 DNS キャッシュ サーバに対して作成した Video Mesh のクエリの比率 |
1秒あたりの着信クエリ | ビデオ メッシュが内部 DNS キャッシュ サーバに対して作成した 1 秒あたりの DNS クエリの平均数 |
1秒あたりのアウトバウンドクエリ | ビデオメッシュが顧客の DNS サーバーに対して作成した 1 秒あたりの DNS クエリの平均数 |
アウトバウンド DNS 遅延 [時間範囲] | ビデオメッシュが顧客の DNS サーバーに対して作成した DNS クエリのうち、応答時間が記載された時間範囲内に落ちた割合 |
TAC 要求時に DNS キャッシュをリセットするには、[DNS キャッシュをワイプ（Wipe DNS Cache）] ボタンを使用します。 DNS キャッシュをワイプすると、キャッシュが補充されるにつれて高いアウトバウンドからインバウンドのクエリ比率が表示されます。 キャッシュを消去するために、ノードをメンテナンスモードに配置する必要はありません。
次に行うこと
ノードのメンテナンス モードを解除します。 その後、変更が必要な他のノードでタスクを繰り返します。
セキュリティ証明書のアップロード
ノードと syslog サーバなどの外部サーバ間の信頼関係を設定します。
| クラスタ化された環境では、各ノードに CA 証明書とサーバ証明書を個別にインストールする必要があります。 |
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 | ||
| 2 | syslog サーバなどの別のサーバで TLS を設定する場合、セキュリティ上の理由から、ノードのデフォルトの自己署名証明書の代わりに、ビデオ メッシュ ノードで CA 署名証明書を使用することをお勧め します。 ビデオ メッシュ ノードで証明書とキー ペアを作成してアップロードするには、[サーバー証明書] に移動し、次の手順に従います。
| ||
| 3 | 外部サーバの CA 証明書の署名方法に応じてオプションを選択します。
| ||
| 4 | 外部サーバが使用する証明書または証明書信頼リスト（CTL）を取得します。 ビデオ メッシュ ノードの証明書と同様に、外部サーバー ファイルを覚えやすい場所に保存します。 | ||
| 5 | [Webex ビデオ メッシュ ノード インターフェイス] タブに戻り、[信頼ストアとプロキシ] をクリックし、オプションを選択します。
クラウドに登録されているビデオ メッシュ ノードは、コールが終了するまで最大 2 時間待機し、一時的な非アクティブ状態（静止）になります。 証明書をインストールするには、ノードが再起動し、自動的に再起動する必要があります。 オンラインに戻ると、証明書がビデオ メッシュ ノードにインストールされたときにプロンプトが表示され、ページを再読み込みして新しい証明書を表示できます。 | ||
| 6 | 同じクラスタ内の他のすべてのビデオ メッシュ ノードで証明書または証明書チェーンのアップロードを繰り返します。 |
サポート用のビデオ メッシュ ログの生成
ログを Cisco に直接送信するように指示される場合もあれば、自分でダウンロードしてケースに添付することもできます。 Web インターフェイスからこの手順を使用して、ログを生成し、Cisco に送信するか、任意のビデオ メッシュ ノードからダウンロードします。 生成されたログ パッケージには、メディア ログ、システム ログ、およびコンテナ ログが含まれます。 このバンドルは、Webex への接続、プラットフォームの問題、通話のセットアップまたはメディアに有用な情報を提供し、シスコがビデオ メッシュ ノードの展開をトラブルシューティングできるようにします。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［トラブルシューティング］に移動し、［ログの送信］のとなりにあるオプションを選択します。
生成されたログは歴史的にノードに保存され、再起動後もノードに残ります。 アップロード ID がページに表示されます。 Support はこの値を使用して、アップロードされたログを識別します。 |
| 3 | ケースを開くか、Cisco TAC と対話する場合は、サポートエンジニアがログにアクセスできるように、アップロード識別子の値を含めます。 ログを Cisco に直接送信した場合、ログバンドルを TAC ケースにアップロードする必要はありません。 |
次に行うこと
ログが Cisco にアップロード中またはダウンロード中に、同じ画面からパケット キャプチャを実行できます。
サポート用のビデオ メッシュ パケット キャプチャの生成
パケット キャプチャ（PCAP）を実行し、Cisco に提出して詳細な分析を行うことができます。 パケット キャプチャは、ノードのネットワーク インターフェイスを通過するデータ パケットのスナップショットを取ります。 パケットをキャプチャして送信した後、Cisco は送信されたキャプチャを分析し、ビデオ メッシュ ノード展開のトラブルシューティングを支援できます。
始める前に
| パケット キャプチャ機能は、デバッグのみを目的としています。 アクティブなコールをホストしているライブ ビデオ メッシュ ノードでパケット キャプチャを実行すると、パケット キャプチャがノードのパフォーマンスに影響し、生成されたファイルが上書きされる可能性があります。 これにより、キャプチャされたデータが失われます。 パケットキャプチャは、ピーク時間外またはコール数がノードで 3 未満の場合のみ実行することを推奨します。 |
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | トラブルシューティングに移動します。 パケット キャプチャを開始し、ログを同時にアップロードできます。 |
| 3 | (オプション) [パケットキャプチャ] セクションでは、キャプチャを特定のインターフェイスのパケットに制限したり、特定のホストとの間でパケットでフィルタリングしたり、1 つ以上のポートでパケットでフィルタリングしたりできます。 |
| 4 | プロセスを開始するには、[パケットキャプチャの開始] 設定をオンにします。 |
| 5 | 完了したら、[パケットキャプチャの開始] 設定をオフに切り替えます。 |
| 6 | 1 つを選択します。
パッケージ キャプチャがアップロードされると、アップロード ID がページに表示されます。 Support はこの値を使用して、アップロードされたパケット キャプチャを識別します。 パケットキャプチャの最大サイズは 2 GB です。 |
| 7 | ケースを開くか、Cisco TAC と対話する場合は、アップロード識別子の値を含めて、サポート エンジニアがパケット キャプチャにアクセスできるようにします。 |
ビデオ メッシュ ノード Web インターフェイスから Ping を実行する
ビデオ メッシュ ノード Web インターフェイスから ping を実行できます。 このステップでは、入力した接続先をテストし、ビデオ メッシュ ノードに到達できるかどうかを確認します。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［トラブルシューティング］に移動し、［Ping］までスクロールし、［FQDNまたはIPアドレス］フィールドの［Pingを使用した接続のテスト］でテストする宛先アドレスを入力します。 |
| 3 | [Ping] をクリックします。 テストが実行され、ping が成功したか失敗のメッセージを確認できます。 テストにはタイムアウト制限がありません。 障害が発生した場合、またはテストが無期限に実行された場合は、入力した宛先値とネットワーク設定を確認してください。 |
ビデオ メッシュ Web インターフェイスからトレース ルートを実行する
ビデオ メッシュ ノード Web インターフェイスから traceroute を実行できます。 このステップは、ノードから入力する宛先に向かってパケットによって取られたルートを示します。 traceroute 情報を表示すると、特定の接続が貧弱である理由を特定し、問題を特定するのに役立ちます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［トラブルシューティング］に移動し、［Traceroute］までスクロールし、［FQDNまたはIPアドレス］フィールドの［ホストへのトレースルート］でテストする宛先アドレスを入力します。 テストが実行されると、トレース ルートの成功または失敗のメッセージが表示されます。 テストは16秒で終了します。 障害が発生した場合、またはテストがタイムアウトした場合は、入力した接続先値とネットワーク設定を確認してください。 |
ビデオ メッシュ ノード Web インターフェイスからの NTP サーバの確認
ネットワーク タイム プロトコル（NTP）サーバの FQDN または IP アドレスを入力して、ビデオ メッシュ ノードがサーバにアクセスできることを確認できます。 このテストは、時刻同期に問題があり、NTP サーバの到達可能性を除外する場合に役立ちます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［トラブルシューティング］に移動し、［NTPサーバーの確認］までスクロールし、［FQDNまたはIPアドレス］フィールドの［SNTPクエリ応答の表示］でテストする宛先アドレスを入力します。 テストが実行されると、クエリの成功または失敗のメッセージが表示されます。 テストにはタイムアウト制限がありません。 障害が発生した場合、またはテストが無期限に実行された場合は、入力した宛先値とネットワーク設定を確認してください。 |
Web インターフェイスの Reflector ツールでポートの問題を特定する
リフレクタツール（Python スクリプトを介したビデオ メッシュ ノード上のサーバとクライアントの組み合わせ）は、必要な TCP/UDP ポートがビデオ メッシュ ノードから開かれているかどうかを確認するために使用されます。
始める前に
https://github.com/CiscoDevNet/webex-video-mesh-reflector-clientからReflector Tool Client（Pythonスクリプト）のコピーをダウンロードします。
スクリプトが正常に動作するには、Python 2.7.10 以降を環境で実行していることを確認してください。
現在、このツールは、ビデオ メッシュ ノードおよびクラスタ内検証への SIP エンドポイントをサポートしています。
| 1 | https://admin.webex.com の顧客ビューから、次の手順に従って、ビデオ メッシュ ノードのメンテナンス ノードを有効にします。 |
| 2 | ノードが Control Hub で [メンテナンス準備完了] ステータスを表示するのを待機します。 |
| 3 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 手順については、「Web インターフェイスからビデオ メッシュ ノードを管理する」を参照してください。 |
| 4 | 使用するプロトコルに応じて、［Reflector Tool］までスクロールし、［TCP Reflector Server］または［UDP Reflector Server］のいずれかを起動します。 |
| 5 | [Start Reflector Server] をクリックし、サーバーが正常に起動するまで待ちます。 サーバが起動すると通知が表示されます。 |
| 6 | ビデオ メッシュ ノードに到達するネットワーク上のシステム（PC など）から、次のコマンドを使用してスクリプトを実行します。
実行の最後に、必要なすべてのポートが開いている場合、クライアントは成功メッセージを表示します。
必要なポートが開いていない場合、クライアントは失敗したメッセージを表示します。
|
| 7 | ファイアウォールのポートの問題を解決してから、上記の手順を再実行します。 |
| 8 | クライアントを実行する
|
ビデオ メッシュ ノード Web インターフェイスからデバッグ ユーザー アカウントを有効にする
Cisco TAC で Webex ビデオ メッシュ ノードへのアクセスが必要な場合は、デバッグ ユーザー アカウントを一時的に有効にして、サポートがさらにトラブルシューティングを実行できるようにすることができます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［トラブルシューティング］に移動し、［デバッグユーザーの有効化］設定をオンに切り替えます。 Cisco TAC に提供できる暗号化されたパスフレーズが表示されます。 |
| 3 | パスフレーズをコピーし、サポートチケットに貼り付けるか、サポートエンジニアに直接貼り付け、保存したら［OK］をクリックします。 |
デバッグ ユーザー アカウントは 3 日間有効で、その後有効期限が切れます。
次に行うこと
［トラブルシューティング］ページに戻り、［デバッグユーザーを有効にする］設定をオフに切り替えると、期限が切れる前にアカウントを無効にできます。
Web インターフェイスからビデオ メッシュ ノードを工場出荷時の状態にリセットする
登録解除のクリーンアップの一環として、Web インターフェイスからビデオ メッシュ ノードを初期設定にリセットできます。 このステップでは、ノードがアクティブである間に配置した構成は削除されますが、仮想マシンのエントリは削除されません。 後で、このノードをゼロからビルドする別のクラスタの一部として再登録することもできます。
始める前に
Control Hub に登録されているクラスタからビデオ メッシュ ノードの登録を解除するには、Control Hub を使用する必要があります。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［トラブルシューティング］に移動し、［初期設定へのリセット］までスクロールし、［ノードをリセット］をクリックします。 |
| 3 | 表示される警告プロンプトの情報がわかっていることを確認し、[リセット/リブート] をクリックします。 初期化した後にノードを自動的に再起動します。 |
Web インターフェイスからローカル管理者アカウントを無効または再有効にする
Webex ビデオ メッシュ ノードをインストールすると、最初にユーザー名「admin」の組み込みローカル アカウントを使用してサインインします。 ノードを Webex クラウドに登録すると、Webex 組織の管理資格情報を使用して、Control Hub からビデオ メッシュ ノードを管理できます。 これにより、Control Hub に適用される管理者アカウント ポリシーと管理プロセスもビデオ メッシュ ノードに適用されます。 さらに制御するには、組み込みの「管理者」アカウントを無効にして、Control Hub がすべての管理者認証と管理を処理できるようにします。
管理ユーザ アカウントを無効にする (または後で再有効にする) には、ノードをクラウドに登録した後で、次の手順を使用します。 管理者アカウントを無効にすると、Control Hub を使用してノード Web インターフェイスにアクセスする必要があります。
| Webex 組織のフル管理者だけがこの機能を使用できます。 パートナーや外部フル管理者など、他の管理者はビデオメッシュリソースの [ノードに進む] オプションを利用できません。 |
| 1 | https://admin.webex.comの顧客ビューから。 | ||
| 2 | ビデオメッシュカードの［リソース］で、［すべて表示］をクリックします。 | ||
| 3 | クラスタをクリックし、アクセスするノードをクリックします。 をクリックします。 ノードに移動だ | ||
| 4 | 管理に移動します。 | ||
| 5 | 管理者ユーザーサインインを有効にするのスイッチをオフにしてアカウントを無効にするか、オンにして再度有効にします。
| ||
| 6 | 確認画面で、［無効］または［有効］をクリックして変更を完了します。 |
管理者ユーザーを無効にすると、WebUI または SSH から起動した CLI を介してビデオ メッシュ ノードにサインインできません。 ただし、VMware ESXi コンソールから起動した CLI を使用して、管理ユーザ クレデンシャルを使用してサインインできます。
Web インターフェイスから管理者パスフレーズを変更する
Web インターフェイスを使用して、Webex ビデオ メッシュ ノードの管理者パスフレーズ (パスワード) を変更するには、次の手順を使用します。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［管理］に移動し、［パスフレーズの変更］の横にある［変更］をクリックします。 |
| 3 | ［現在のパスフレーズ］を入力し、［新しいパスフレーズ］と［新しいパスフレーズの確認］の両方に新しいパスフレーズ値を入力します。 |
| 4 | パスフレーズを保存をクリックします。 「パスワードが変更されました」というメッセージが表示され、サイン イン画面に戻ります。 |
| 5 | 新しい管理者ログインおよびパス フレーズ (パスワード) を使用してサイン インします。 |
Web インターフェイスからのパスフレーズの有効期限間隔の変更
この手順を使用して、Web インターフェイスを使用して 90 日のデフォルトのパスフレーズの有効期限間隔を変更します。 間隔が上がると、ビデオ メッシュ ノードにサインインするときに新しいパスフレーズを入力するように求められます。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | ［管理］に移動し、［パスフレーズの有効期限の変更］の横にある［有効期限間隔（日）］（最大365日）に新しい値を入力し、［パスフレーズの有効期限間隔を保存］をクリックします。 成功画面が表示されたら、［OK］をクリックして終了します。 |
管理ページには、最後のパスフレーズ変更日と、次回のパスワードの有効期限日も表示されます。
Syslog サーバへの外部ロギングの設定
syslog サーバーがある場合、Webex ビデオ メッシュ ノードを設定して、外部サーバーの監査証跡情報 (例:
管理者サインインの詳細
構成の変更 (メンテナンスモードのオン/オフを含む)
ソフトウェアの更新
ノードは、ある場合はログを集約し、10 分ごとにサーバに送信します。
| 1 | Webex ビデオ メッシュ ノード インターフェイスを開きます。 |
| 2 | 管理に移動します。 |
| 3 | [外部ロギング] の横にある [外部ロギングを有効にする] をオンに切り替えます。 |
| 4 | Syslog サーバの詳細については、ホスト IP アドレスまたは完全修飾ドメイン名と syslog ポートを入力します。 サーバがノードから DNS 解決可能でない場合は、[ホスト] フィールドで IP アドレスを使用します。 |
| 5 | プロトコル（UDPまたはTCP）を選択します。 TLS 暗号化を使用するには、[TCP] を選択し、[TLS を有効にする] をオンに切り替えます。 ノードと syslog サーバ間の TLS 通信に必要なセキュリティ証明書もアップロードしてインストールしてください。 証明書がインストールされていない場合、ノードはデフォルトで自己署名証明書を使用します。 ヘルプについては、「セキュリティ証明書のアップロード」を参照してください。 |
| 6 | [外部ログ設定の保存] をクリックします。 |
ログ メッセージのプロパティは次の形式に従います。 優先タイムスタンプ ホスト名 タグ メッセージ。
プロパティ | 説明 |
|---|---|
優先度 | 値は、次の式に基づいて、常に 131 です。 優先度 = (施設コード * 8) + 深刻度。 施設コードは「local0」の16です。 深刻度は「通知」の3です。 |
タイムスタンプ | タイムスタンプ形式は「Mmm dd hh:mm:ss」です。 |
ホスト名 | ビデオ メッシュ ノードのホスト名。 |
タグ | 値は常に syslogAuditMsg です。 |
メッセージ | メッセージは少なくとも 1KB の JSON 文字列です。 そのサイズは、10分間隔の集約イベントの数によって異なります。 |
メッセージの例を次に示します。
{
"events": [
{
"event": "{\hostname\": \"test-machine\", \"event_type\": \"login_success\",
\"event_category\": \"node_events\", \"source\": \"mgmt\", \"session_data\":
{\"session_id\": \"j02wH5uFTKB22SqdYCrzPrqDWkXIAKCz\", \"referer\":
\"https://IP address/signIn.html?%2Fsetup\", \"url\":
\"https://IP address/api/v1/auth/signIn\", \"user_name\": \"admin\",
\"remote_address\": \"IP address\", \"user_agent\": \"Mozilla/5.0
(Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/87.0.4280.67 Safari/537.36\"}, \"event_data\": {\"type\": \"Conf_UI\"},
\"boot_id\": \"6738705b-3ae3-4978-8502-13b74983e999\", \"timestamp\":
\"2020-12-07 22:40:27 (UTC)\", \"uptime\": 358416.23, \"description\":
\"Log in to Console or Web UI successful\"}"
},
{
"event": "{\hostname\": \"test-machine\", \"event_type\":
\"software_update_completed\", \"event_category\": \"node_events\", \"source\":
\"mgmt\", \"event_data\": {\"release_tag\": \"2020.12.04.2332m\"}, \"boot_id\":
\"37a8d17a-69d8-4b8c-809d-3265aec56b53\", \"timestamp\":
\"2020-12-07 22:17:59 (UTC)\", \"uptime\": 137.61, \"description\":
\"Completed software update\"}"
}
]
}ビデオ メッシュ アラートの Webhook
ビデオ メッシュは Webhook アラートをサポートし、組織管理者が特定のイベントに関するアラートを受信できるようにします。 管理者は、コールオーバーフローやコールリダイレクトなどのイベントを通知することを選択できるため、展開を監視するために Control Hub にログインする必要が最小限に抑えられます。 これは、管理者からターゲット URL が提供され、アラートが送信される Webhook サブスクリプションを作成することによって達成されます。 アラートに Webhook を使用すると、関連する開発者 API を使用せずにパラメータを監視することもできます。
次のイベント タイプは、Webhook を通じて監視できます。
クラスタコールリダイレクト - 特定のクラスタからリダイレクトされたコール。
組織通話オーバーフロー - 組織のクラウドへの通話オーバーフローの合計。
Webhook サブスクリプションの作成
| 1 | 管理者の資格情報を使用して Cisco Webex Developer ポータルにログインします。 |
| 2 | 開発者ポータルで、[ ドキュメント] をクリックします。 |
| 3 | 左側のスクロールバーから下にスクロールし、[完全なAPIリファレンス] をクリックします。 |
| 4 | 下に展開されているオプションから下にスクロールし、[Webhook] > [Webhookの作成] をクリックします。 |
| 5 | 次のパラメータを入力してサブスクリプションを作成します。 |
名前: 例 – ビデオ メッシュ Webhook アラート
targetUrl: 例: https://10.1.1.1/webhooks
リソース: videoMeshAlerts ビデオMeshAlerts
イベント: トリガー
所有: オーガニック
| targetUrl パラメータに入力された URL は、インターネットにアクセス可能で、Webex Webhook から送信された POST 要求を受け入れるように設定されたサーバを持っている必要があります。 |
開発者 API によるしきい値設定の設定
ビデオ メッシュ デベロッパー API を使用して、イベント（組織コールオーバーフローとクラスタコールリダイレクト）のしきい値を設定できます。 Webhook アラートがトリガーされるしきい値のパーセンテージ値を設定できます。 たとえば、しきい値が [組織通話のオーバーフロー（Org Call Overflow）] で 20 に設定されている場合、通話の 20% 以上がクラウドにオーバーフローするとアラートが送信されます。
Cisco Webex デベロッパー ポータルでしきい値を設定および更新するための 4 つの API セットが利用でき、以下に記載されています。
イベントしきい値設定のリスト
イベントしきい値設定の取得
イベントしきい値設定の更新
イベントしきい値設定のリセット
API は以下で利用できます。https://developer.webex.com/docs/api/v1/video-meshを選択します。
シナリオ 1 - オーバーフローした組織コールのしきい値を設定する
| 1 | [List Event Threshold Configuration API] をクリックします。 | ||
| 2 | セット | ||
| 3 | 以下の内容と同様の回答が送信されます。 | ||
| 4 | 次の値のコピー: | ||
| 5 | 次の値に貼り付けます: | ||
| 6 | [イベントしきい値設定の更新API] をクリックします。 | ||
| 7 | Update Event Threshold Configuration APIの本文にJSON構造体を貼り付けます。 | ||
| 8 | セット | ||
| 9 |
[実行]をクリックすると、[組織コールオーバーフロー]のしきい値が新しい値に設定されます。 |
次に行うこと
特定のイベントしきい値 ID に設定されているしきい値を表示するには、
[イベントしきい値設定の取得API] をクリックします。
イベントしきい値 ID を API のヘッダーに貼り付け、[実行] をクリックします。
デフォルトの最小しきい値と設定されたしきい値が、応答に表示されます。
シナリオ 2 - リダイレクトされたクラスタコールのしきい値を設定する
| 1 | [List Event Threshold Configuration API] をクリックします。 | ||
| 2 | セット | ||
| 3 | 応答は、組織内のすべてのクラスタの設定を一覧表示します。 | ||
| 4 |
次の値のコピー: | ||
| 5 | 次の値に貼り付けます: | ||
| 6 | [イベントしきい値設定の更新API] をクリックします。 | ||
| 7 | Update Event Threshold Configuration APIの本文にJSON構造体を貼り付けます。 | ||
| 8 | セット | ||
| 9 |
のしきい値である実行をクリックします。 クラスタコールがリダイレクトは新しい値に設定されます。 |
次に行うこと
特定のイベントしきい値 ID に設定されているしきい値を表示するには、
[イベントしきい値設定の取得API] をクリックします。
イベントしきい値 ID を API のヘッダーに貼り付け、[実行] をクリックします。
デフォルトの最小しきい値と設定されたしきい値が、応答に表示されます。
シナリオ3 - しきい値のリセット
| 1 | Reset Event Threshold Configuration APIをクリックします。 | ||
| 2 | クラスタまたは組織のイベントしきい値 ID をコピーして、 | ||
| 3 | ボディにJSON構造体を貼り付け、［実行］をクリックします。 | ||
| 4 |
しきい値が、デフォルトの最小値に設定されます。 |
ビデオ メッシュ デベロッパー API
ビデオ メッシュ デベロッパー API は、Webex デベロッパー ポータルを介してビデオ メッシュ展開の分析とモニタリング データを取得する方法です。 APIはhttps://developer.webex.com/docs/api/v1/video-meshでご利用いただけます。 サンプルクライアントは、次で入手できます。https://github.com/CiscoDevNet/video-mesh-api-clientを選択します。
ビデオ メッシュ ノードのデモ ソフトウェア
ビデオ メッシュ ノードのデモ ソフトウェアは、基本的なデモ目的でのみ使用します。 既存のプロダクション クラスタにデモ ノードを追加しないでください。 デモ クラスタは、本番環境よりも少ないコールを受け付け、クラウドに登録してから 90 日後に期限切れになります。
|
|
このリンクからデモ用ソフトウェアの画像をダウンロードしてください。
機能と仕様
ビデオ メッシュ ノード ソフトウェアの仕様ベースの設定については、「ビデオ メッシュ ノード ソフトウェアのシステムとプラットフォームの要件」を参照してください。
デモソフトウェアは、単一のネットワークインターフェイスまたはデュアルネットワークインターフェイスのいずれかをサポートしています。
容量
容量のデモ画像はテストしません。 基本的なミーティングシナリオをテストするためにのみ使用してください。 ガイダンスに従う使用事例を参照してください。
ビデオ メッシュ ノード デモ ソフトウェアの使用例
- オンプレミスに依存するメディア
-
デモ ソフトウェアを使ってノードを展開し、構成します。
以下の参加者を含めたミーティングを実行します。 Webex アプリの参加者、Webex エンドポイントの参加者、および Cisco Webex Board。
ミーティングが終了したら、https://admin.webex.comの顧客ビューからアナリティクスに移動して、ビデオ メッシュ レポートにアクセスします。 レポート内では、メディアがオンプレミスに留まっていたことを見ることができます。
- クラウドとオンプレミスの参加者によるミーティング
-
オンプレミスの Webex 参加者数人とクラウドの Webex 参加者数人で別のミーティングを実行します。
すべての参加者がミーティングにシームレスに加わって、参加することができることを観察します。
コンソールからビデオ メッシュ ノードを管理する
クラウドに登録されているビデオ メッシュ ノードにネットワークを変更する前に、Control Hub を使用してメンテナンス モードにする必要があります。 手順の詳細については、「ノードをメンテナンスモードに移動」を参照してください。
| メンテナンスモードは、特定のネットワーク設定変更(DNS、IP、FQDN)を行うか、RAM、ハードドライブなどのハードウェア保守の準備ができるように、シャットダウンまたはリブート用のノードの準備のみを目的としています。 ノードがメンテナンスモードになっている場合、アップグレードは行われません。 |
ノードをメンテナンスモードにすると、コールサービスが適切にシャットダウンされます（新しいコールの受け入れを停止し、既存のコールが完了するまで最大 2 時間待機します）。 コールサービスの優雅なシャットダウンの目的は、コールのドロップを引き起こすことなくノードの再起動またはシャットダウンを許可することです。
コンソールでビデオ メッシュ ノード ネットワーク設定を変更する
ネットワーク トポロジが変更された場合は、各ビデオ メッシュ ノードのコンソール インターフェイスを開き、そこでネットワーク設定を変更する必要があります。 ネットワーク設定の変更に関する注意が表示される場合がありますが、ビデオ メッシュ ノード設定を変更した後で、ネットワークに変更を加える場合に備えて、変更を保存できます。
| 1 | VMware vSphere クライアントからノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 ネットワーク設定を初めてセットアップした後、ビデオ メッシュが到達可能な場合は、セキュア シェル (SSH) を使用してノード インターフェイスにアクセスできます。 | ||
| 2 | ビデオ メッシュ ノード コンソールのメイン メニューから、オプション を選択します。 2 設定の編集 をクリックし、 をクリックします。 選択するだ | ||
| 3 | ビデオ メッシュ ノードで通話が終了するプロンプトを読み、[はい] をクリックします。 | ||
| 4 | [スタティック] をクリックし、内部インターフェイス、[マスク]、[ゲートウェイ]、および [のIPアドレス] を入力します。 DNS ネットワークの 値。
| ||
| 5 | 組織の NTP サーバまたは組織で使用できる別の外部 NTP サーバを入力します。 NTP サーバを設定してネットワーク設定を保存した後、[コンソールからビデオ メッシュ ノードの健全性を確認する] の手順に従って、指定された NTP サーバを介して時間が正しく同期されていることを確認できます。
| ||
| 6 | (オプション) 必要に応じて、ホスト名またはドメインを変更します。
| ||
| 7 | [保存] をクリックし、[変更をクリックします。保存して再起動する] をクリックします。 ドメインを提供した場合、保存中に DNS 検証が実行されます。 FQDN (ホスト名およびドメイン) が提供される DNS サーバー アドレスを使用して解決できない場合、警告が表示されます。 警告を無視して保存することを選択できますが、FQDN がノードで設定された DNS に解決されるまで、コールは機能しません。 ビデオ メッシュ ノードが再起動すると、ネットワーク設定の変更が有効になります。 |
ビデオ メッシュ ノードの管理者パスフレーズの変更
この手順を使用して、ノードのコンソールでビデオ メッシュ ノードの管理者のパスフレーズ（パスワード）を変更します。
| 1 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 2 | ビデオ メッシュ ノードの VM の VMware ESXi コンソールを開いてログインします。 |
| 3 | メインメニューにて、[3 管理者パス フレーズの管理]、[3 管理者パス フレーズの変更] のオプションを選択し、[Enter] を押します。 |
| 4 | パスワード期限の切れたページの情報を読み、[Enter] をクリックしてから、パスワード期限切れメッセージの後再度クリックします。 |
| 5 | Enter を押します。 |
| 6 | コンソールからサイン アウトした後、サイン イン画面に戻り、期限切れの管理者ログインとパスフレーズ (パスワード) を使用してサイン インします。 パスワードの変更が求められます。
|
| 7 | [古いパスワード] には、現在のパスフレーズを入力して Enter を押します。 |
| 8 | [新しいパスワード] には、新しいパスフレーズを入力して、Enter を押します。 |
| 9 | [新しいパスワードの再入力] には、新しいパスフレーズを再度入力して、Enter を押します。 「パスワードが変更されました」というメッセージが表示され、サイン イン画面に戻ります。
|
| 10 | 新しい管理者ログインおよびパス フレーズ (パスワード) を使用してサイン インします。 |
ビデオ メッシュ ノード コンソールから Ping を実行する
ビデオ メッシュ ノード コンソール インターフェイスから ping を実行できます。 このステップでは、入力した接続先をテストし、ビデオ メッシュ ノードに到達できるかどうかを確認します。
| 1 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 2 | ビデオ メッシュ ノード コンソールから、[4 診断] に移動し、[Ping] を選択します。 |
| 3 | [Ping]ping] フィールドで、IP アドレスやホスト名などテストしたい宛先アドレスを入力し、[OK] をクリックします。 テストが実行され、ping が成功したか失敗のメッセージを確認できます。 失敗のメッセージを受け取った場合、入力したこの宛先の値とネットワーク設定を確認します。 |
コンソールを介してデバッグユーザーアカウントを有効にする
サポートがビデオ メッシュ ノードへのアクセスを必要とする場合、コンソール インターフェイスを使用して、デバッグ ユーザー アカウントを一時的に有効にして、サポートがノードでさらにトラブルシューティングを実行できるようにすることができます。
| 1 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 2 | ビデオ メッシュ ノード コンソールから、[4 診断] に移動し、[2 デバッグユーザーアカウントを有効にする] を選択し、プロンプトの後、[はい] をクリックします。 |
| 3 | デバッグ ユーザー アカウントが正常に作成されたことを示すメッセージが表示された後、[OK] をクリックして、暗号化されたパスフレーズを表示します。 暗号化されたパスフレーズをサポートに送信します。 この一時アカウントと復号化されたパスフレーズを使用して、トラブルシューティングのためにビデオ メッシュ ノードに安全にアクセスします。 このアカウントは 3 日後に期限が切れるか、サポートが終了したときに無効にできます。 |
| 4 | 暗号化されたデータの最初と最後を選択し、サポート チケットとサポートに送信した電子メールにコピーペーストします。 |
| 5 | この情報をサポートに送信したら、ビデオ メッシュ ノード コンソールに戻り、任意のキーを押してメイン メニューに戻ります。 |
次に行うこと
アカウントは 3 日で期限切れになりますが、サポートがノードのトラブルシューティングが終了したことを示す場合、ビデオ メッシュ ノード コンソールを返し、[4 診断] に移動し、[3 デバッグユーザーアカウントを無効にする] を選択して、期限切れになる前にアカウントを無効にできます。
ビデオ メッシュ ノード コンソールからのログの送信
ログを Cisco に直接送信するか、セキュアコピー (SCP) 経由で送信するように指示される場合があります。 クラウドに登録したビデオ メッシュ ノードからログを直接送信するには、次の手順を使用します。
| 1 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 2 | メインメニューにて、[4 診断 ] のオプションをクリックし、Enter を押します。 |
| 3 | [4 ログ ファイルをエクスポート] をクリックし、希望する場合にはフィードバックを送信し、[次へ] をクリックします。 |
| 4 | オプションを選択します。
|
| 5 | [OK] を選択して、[ビデオ メッシュ ノード] メイン メニューに戻ります。 |
| 6 | (オプション) ログを Cisco に送信した場合は、5 Check Status of Log Files Sent to Cisco を選択します。 |
次に行うこと
 | ログを送信した後、Webex アプリから直接フィードバックを送信し、サポート担当者に必要な情報をすべて提供することをお勧めします。 |
コンソールからのビデオ メッシュ ノードの健全性の確認
ビデオ メッシュ ノード自体からノードの健全性を直接表示できます。 結果は通知されますが、トラブルシューティングの段階でクラウドに役立ちます。例えば、NTP 同期が動作していない場合、ネットワーク設定の NTP サーバー値を確認できます。
| 1 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 2 | ビデオ メッシュ ノード コンソールから、[4 診断] に移動し、[6 ノードの健全性の確認] を選択して、ノードに関する次の情報を表示します。
|
ビデオ メッシュ ノードでのコンテナ ネットワークの設定
ビデオ メッシュ ノードは、ノード内で内部使用するためのサブネット範囲を留保します。 デフォルトの範囲は 172.17.42.0 ～ 172.17.42.63 です。 ノードは、この範囲から発信された外部からビデオ メッシュ ノード トラフィックに応答しません。 ネットワーク内の他のデバイスとの競合を避けるために、ノード コンソールを使用してコンテナ ブリッジ IP アドレスを変更することができます。
| 1 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 2 | ビデオ メッシュ ノード コンソールのメイン メニューから、[4 診断] に移動し、[7 コンテナ ネットワークの設定] を選択します。 アクティブ通話がノードで終了することを示す注意の後に、[はい] をクリックします。 |
| 3 | 必要に応じて、コンテナ ブリッジ IP およびネットワーク マスクの値を変更して、[保存] をクリックします。 ビデオ メッシュ ノードの内部操作用に予約された IP アドレス範囲を含む、コンテナ ネットワーク情報を表示する画面が表示されます。 |
| 4 | [OK] をクリックします。 |
コンソールの Reflector ツールでポートの問題を特定する
リフレクタツール（Python スクリプトを介したビデオ メッシュ ノード上のサーバとクライアントの組み合わせ）は、必要な TCP/UDP ポートがビデオ メッシュ ノードから開かれているかどうかを確認するために使用されます。
始める前に
Reflector Tool Client（Pythonスクリプト）のコピーをダウンロードし、見つけやすい場所に解凍します。 zip ファイルには、スクリプトと readme ファイルが含まれています。
スクリプトが正常に動作するには、Python 2.7.10 以降を環境で実行していることを確認してください。
現在、このツールは、ビデオ メッシュ ノードおよびクラスタ内検証への SIP エンドポイントをサポートしています。
| 1 | https://admin.webex.com の顧客ビューから、次の手順に従って、ビデオ メッシュ ノードのメンテナンス ノードを有効にします。 |
| 2 | ノードが Control Hub で [メンテナンス準備完了] ステータスを表示するのを待機します。 |
| 3 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 4 | ビデオ メッシュ ノード インターフェイスから、[診断 > Reflector Server > TCP または (UDP) 用の Reflector Server] に移動します。 TCP または UDP のいずれかのサーバを起動します。 |
| 5 | 使用するプロトコルに応じて、［Reflector Tool］までスクロールし、［TCP Reflector Server］または［UDP Reflector Server］のいずれかを起動します。 |
| 6 | [Start Reflector Server] をクリックし、サーバーが正常に起動するまで待ちます。 サーバが起動すると通知が表示されます。 |
| 7 | ビデオ メッシュ ノードに到達するネットワーク上のシステム（PC など）から、次のコマンドを使用してスクリプトを実行します。
実行の最後に、必要なすべてのポートが開いている場合、クライアントは成功メッセージを表示します。
必要なポートが開いていない場合、クライアントは失敗したメッセージを表示します。
|
| 8 | ファイアウォールのポートの問題を解決してから、上記の手順を再実行します。 |
| 9 | クライアントを実行する
|
コンソールからビデオ メッシュ ノードを工場出荷時の状態にリセットする
登録解除のクリーンアップの一環として、ビデオ メッシュ ノードを初期設定にリセットできます。 このステップは、ノードが作動中の間に設定した構成を削除しますが、仮想マシンのエントリは削除しません。 後で、このノードをゼロからビルドする別のクラスタの一部として再登録することもできます。
始める前に
Control Hub に登録されているクラスタからビデオ メッシュ ノードの登録を解除するには、Control Hub を使用する必要があります。
| 1 | VMware vSphere クライアントまたは SSH を介して到達可能な IP アドレスにノード コンソール インターフェイスを開き、管理者の資格情報を使用してサインインします。 |
| 2 | ビデオ メッシュ ノード コンソールから、[4 診断] に移動し、[8 初期設定へのリセット] を選択します。 |
| 3 | 表示されるノードの情報を理解し、[リセット] をクリックします。 初期化した後にノードを自動的に再起動します。 |
既存のハードウェア プラットフォームをビデオ メッシュ ノードに移行する
既存のサポートされているプラットフォーム (Cisco Meeting Server を実行する CMS1000 など) をビデオ メッシュに移行できます。 移行プロセスをガイドするには、この手順を使用します。
| 手順は、ハードウェアプラットフォーム上のESXiのバンドルバージョンによって異なります。 |
始める前に
最新のビデオ メッシュ ノード ソフトウェア画像 (OVA) の新しいコピーをダウンロードします。 以前にダウンロードした OVA で新しいビデオ メッシュ ノードを展開しないでください。
| 1 | 仮想マシンインターフェイスにサインインし、プラットフォーム上で実行されているソフトウェアをシャットダウンします。 |
| 2 | プラットフォーム上で実行されていたソフトウェアアプリケーションを削除します。 プラットフォーム上にソフトウェアイメージが残っていない必要があります。 また、ビデオ メッシュ ノード ソフトウェアを同じプラットフォーム上の他のソフトウェアと一緒に実行することはできません。
|
| 3 | 新しい OVF または OVA ファイルから新しい仮想マシンを展開します。 |
| 4 | 仮想マシンの名前を入力し、ビデオ メッシュ ノード OVA ファイルを選択します。 |
| 5 | ディスクのプロビジョニングを [Thick] に変更します。 |
| 6 | ダウンロードしたmfusion.ovaソフトウェアの画像をアップロードします。
|
| 7 | 仮想マシンの実行中は、［ビデオ メッシュ ノード コンソールにログインする］に戻り、ビデオ メッシュ ノードの初期設定を続行します。 |
Collaboration Meeting Room Hybrid からビデオ メッシュへの機能の比較と移行パス
機能の比較
機能 | ビデオ メッシュと Cisco Webex Meeting Center ビデオ | CMR Hybrid |
|---|---|---|
ミーティング タイプ | スケジュール済み ワン クリック (インスタント) パーソナル ミーティング (PMR) プレミスおよびクラウドベースのミーティングのための一貫性のあるエクスペリエンス | スケジュール済みのみ |
スケジューリング | Webex 生産性向上ツール (Windows および Mac) @webex を使用するハイブリッド カレンダー スケジューリング Webex ポータル | Webex 対応の TelePresence Windows および Mac 生産性向上ツール TMS スケジューリング |
ミーティング参加のオプション | ダイヤルインとダイヤルアウト PIN で保護 (ホスト) One Button To Push (OBTP) | ダイヤルインのみ OBTP |
ミーティング体験 | Unified Roster (Webex クライアント) Unified コントロール (Webex クライアント) ミーティングのロック/ロック解除 TelePresence 参加者のミュート/ミュート解除 | Unified Roster なし (Webex クライアントおよび TelePresence Server) 個別のコントロール (Webex クライアントと TelePresence サーバー) |
容量と展開モデル | 無制限の容量 オンプレミスと自動オーバーフロー スイッチングとトランスコーディング | トランスコーディング容量は TelePresence サーバーから制約を受ける |
移行パスのチェックリスト
以下は、既存のサイトをビデオ プラットフォーム バージョン 2.0 に移行し、ビデオ メッシュと統合するためのサイトを準備する方法に関する高度な概要です。 この手順は、既存の環境に応じて変化します。 パートナーまたはカスタマー サクセス マネージャーと協力し、スムーズな移行を実現します。
Webex サイトで Meeting Center ビデオ会議機能がプロビジョニングされていることを確認してください。
サイト管理者は管理ポータルのアカウントを受け取ります。 管理者は Webex 組織にビデオ メッシュ ノードを展開します。
サイト管理者は、Cisco WebEx Meeting Center ビデオを使用可能にするために、すべてまたは一部の CMR ハイブリッド ユーザーに CMR 権限を割り当てます。
(オプション) このサブセットの CMR ハイブリッド セッション タイプを無効にし、その後、彼らのユーザー プロファイルで Cisco WebEx Meeting Center ビデオを有効にします。
サイト管理者がビデオ メッシュを設定し、[Cloud Collaboration Meeting Room オプション] でメディア リソース タイプとして ハイブリッド を選択します。
サイト管理者は、Cisco WebEx Meeting Center ビデオで使用するために、オンプレミスの TelePresence Management Suite (TMS) および One Button to Push (OBTP) をセットアップします。 詳細は、Cisco Webex Meeting Center ビデオ会議エンタープライズ展開ガイド 指導のため。
ユーザーに対して CMR 権限が有効になっている場合、Webex 生産性向上ツールはデフォルトで Cisco Webex Meeting Center ビデオバージョンになります。 ユーザーがスケジュールしたすべての新しいミーティングは Cisco Webex Meeting Center ビデオミーティングです。
招待状に会議室が含まれている場合、TMS を通じて OBTP 情報が会議室に渡されます (CMR ハイブリッド ミーティングのみ)。
CMR ハイブリッド ユーザーが Cisco WebEx Meeting Center ビデオに切り替わる前にセットアップした既存のミーティングは、顧客がオンプレミスの MCU と TMS の設定を保持している限り、機能します。
Cisco WebEx Meeting Center ビデオのミーティング情報を反映しようとして、既存の CMR ハイブリッド ミーティングを変更したり、アップデートしたりすることはできません。 ユーザーは、新しい招待状を使いたければ、以前のミーティングを削除して、新しいミーティングを作成する必要があります。
顧客がオンプレミスの MCU、TMS を引退させると、以前の CMR ハイブリッド ミーティングは機能しなくなります。 Cisco Webex Meeting Center ビデオ情報を含む新しいミーティングを作成する必要があります。
TelePresence 相互運用プロトコルとセグメントの切り替え
ビデオ メッシュは、1 画面および 3 画面の IX および TX エンドポイントの両方に対して、TelePresence Interoperability Protocol（TIP）とマルチプレックス（MUX）のネゴシエーションをサポートします。
3画面エンドポイントの場合、会議に十分な参加者がいる場合は、3画面すべてにビデオを表示する必要があります。 会議中の別の 3 画面システムでは、会議室切り替えの代わりにセグメント切り替えが行われます。 つまり、他の3画面システムの誰かが話すと、3つの画面すべてが大きくなる代わりに、アクティブなペインだけが大きくなるということです。 他の 2 つのペインは、他のシステムからのビデオによって入力されます。 小さく表示すると、すべての 3 つのペインが 1 つのバウンディングボックスと名前ラベルで一緒にレンダリングされます (すべてのデバイスでは、1 つまたは 3 つの画面)。
クラウドのホスティング リソースに応じて、一部のエンドポイントでは、フィルム ストリップの 3 画面会議室の 3 つの画面すべてが表示され、他のエンドポイントでは 1 つのペインのみが表示されます。 メディアがオンプレミスであっても、Webex アプリにはわずか 1 ペインしか表示されません。
1 つのノードからオーバーフローし、2 番目のノードにカスケードする大規模なミーティングでは、別のノードでホストされているエンドポイントから 3 画面システムをホストしているエンドポイントでも同じことが表示されます (レイアウトには 1 つのペインのみが表示されます)。 プレゼンテーションの共有では、コール パスを介して BFCP をネゴシエートする必要があります。
新機能および変更された機能に関する情報
この表では、新しい機能や機能、既存のコンテンツへの変更、および導入ガイドで修正された主なエラーについて説明します。
Webex ビデオ メッシュ ノード ソフトウェアの更新については、https://help.webex.com/en-us/article/jgobq2/Webex-Video-Mesh-release-notes を参照してください。
日付 | 変更 |
|---|---|
2024年2月9日。 |
|
2023年8月31日。 |
|
2023年7月31日。 |
|
2023年7月28日。 |
|
2023年6月15日。 |
|
| 2023年5月16日。 |
|
2023 年 3 月 27 日 |
|
2023年3月02日。 |
|
2022 年 7 月 7 日 |
|
2022 年 6 月 30 日 | https://github.com/CiscoDevNet/webex-video-mesh-node-provisioningで新しい一括プロビジョニング スクリプトに関する情報を追加しました。 |
2022 年 6 月 14 日 | Unified CM とビデオ メッシュ ノード間の Exchange 証明書チェーンに ECDSA 証明書を含めるために、証明書チェーンを交換する手順を変更しました |
2022 年 5 月 18 日 | Reflectorツールのダウンロードサイトをhttps://github.com/CiscoDevNet/webex-video-mesh-reflector-clientに変更しました。 |
4月 29,2022 日 | 「すべての外部 Webex ミーティングでメディアをビデオ メッシュに保存する」の新機能に関する情報を追加しました。 |
2022 年 3 月 25 日 | 管理用ポートとプロトコルでのポート使用状況の更新。 |
Decemeber 10、2021 | CMS 2000 を追加し、ビデオ メッシュ ノード ソフトウェアのシステムとプラットフォームの要件で ESXi 7 にアップグレードする古い CMS 1000s のアップグレードの問題を指摘しました。 |
2021 年 8 月 30 日 | Webex が展開の正しいソース国であることを確認するための情報が、「ソース国が正しいことを確認する」に追加されました。 |
2021 年 8 月 27 日 | 分析レポートの可視性に関するプライベートミーティングのサポートと制限のメモを追加しました。 |
2021 年 8 月 13 日 | 次の新しいプライベート ミーティング機能に関する情報を追加しました。
|
2021年7月22日。 | システムがコールの正しい発信元の場所を持っていることを確認する方法に関する情報を追加しました。 正しいソースロケーションは、効率的なルーティングに役立ちます。 「原産国が正しいことを確認する」を参照してください。 |
2021 年 6 月 25 日 | Webex アプリのフル機能 Webex エクスペリエンス機能は、ビデオ メッシュ ノードを使用するクライアントとデバイスのビデオ メッシュと互換性がないことに注意してください。 |
2021 年 5 月 7 日 | ビデオ メッシュ クラスタ展開のガイドラインで推奨されるクラスタ サイズを 100 に修正しました。 |
2021/04/12 | 新しい DNS ゾーンではなく、Webex ゾーンを使用するようにビデオ メッシュの Expressway TCP SIP トラフィック ルーティングの設定 を更新しました。 |
2021 年 2 月 9 日 |
|
2020年12月11日 |
|
2020/10/22 |
|
| 2020年10月19日水曜日 |
|
| 2020/09/18 |
|
| 2020 年 8 月 26 日 |
|
2020年8月4日（火） |
|
| 2020 年 7 月 9 日 |
|
2020 年 6 月 26 日 |
|
| 2020 年 6 月 9 日 |
|
| 2020年5月21日水曜日 | 管理用のポートとプロトコルとビデオメッシュのプロキシサポートの要件を更新しました。 |
| 2020 年 5 月 15 日 | ビデオ メッシュの概要を更新しました。 |
| 2020年4月25日。 |
|
2020 年 1 月 22 日 |
|
2019 年 12 月 12 日 |
|
2019/12/10 |
|
2019 年 11 月 4 日 |
|
| 2019 年 10 月 18 日 |
|
2019 年 9 月 26 日 |
|
2019 年 9 月 13 日 |
|
| 2019 年 8 月 29 日 |
|
2019年7月24日。 |
|
2019年7月9日水曜日 |
|
2019 年 5 月 24 日 |
|
2019 年 4 月 25 日 |
|
2019 年 4 月 11 日 |
|
Webex ビデオ メッシュの概要
Webex ビデオ メッシュ は、状況に応じてオンプレミスとクラウドの会議リソースの最適な組み合わせを見つけます。 オンプレミス会議は、十分なローカルリソースがある場合、前提にとどまります。 ローカルリソースが消耗されると、電話会議はクラウドまで展開します。
ビデオ メッシュ ノードは、オンプレミスの Cisco UCS サーバーにインストールされ、クラウドに登録され、Control Hub で管理されるソフトウェアです。 2 人の間の Webex ミーティング、Webex パーソナル会議室、Webex スペース ミーティング、Webex アプリの通話は、ローカルのオンネット ビデオ メッシュ ノードにルーティングできます。 ビデオ メッシュは、利用可能なリソースを使用する最も効率的な方法を選択します。
ビデオ メッシュは、次の利点を提供します。
通話はオンプレミスで保管できるので、品質が改善され、遅延が軽減されます。
オンプレミス リソースが上限に達したり、利用不可能になったりした場合、通話はクラウドに透過的に延長されます。
単一の管理インターフェイスでクラウドからビデオ メッシュ クラスタを管理します。 Control Hub (https://admin.webex.com ) を選択してください。
リソースおよびスケール容量は、必要に応じて、最適化することができます。
クラウドの機能とオンプレミス電話会議を 1 つのシームレスなユーザー エクスペリエンスに統合します。
クラウドはより多くの会議リソースが必要な場合でも常時使用可能なため、容量の懸念が払拭されます。 最悪のシナリオでは、容量計画を行う必要はありません。
https://admin.webex.comの容量と使用状況、およびレポートデータのトラブルシューティングに関する高度な分析を提供します。
ユーザーがオンプレミスの標準ベースの SIP エンドポイントとクライアントから Webex ミーティングにダイヤルインするときに、ローカルメディア処理を使用します。
Cisco Webex ミーティングにコールインするオンプレミスのコール制御（Cisco Unified Communications Manager または Expressway）に登録された SIP ベースのエンドポイントとクライアント（Cisco エンドポイント、Jabber、サードパーティの SIP）。
Webex ミーティングに参加する Webex アプリ (会議室デバイスとのペアリングを含む)。
Webex ミーティングに直接参加する Webex 会議室およびデスクデバイス。
ネット上の SIP ベースのエンドポイントとクライアントに対して、最適化された音声とビデオのインタラクティブ ボイス レスポンス (IVR) 機能を提供することができます。
H.323、IP ダイヤルイン、Skype for Business (S4B) エンドポイントは、引き続きクラウドからミーティングに参加します。
1080p をサポートできるミーティング参加者がローカルのオンプレミス ビデオ メッシュ ノード経由でホストされている場合、ミーティングのオプションとして 1080p 30fps 高解像度ビデオをサポートします。 (出席者が進行中のミーティングにクラウドから参加しても、オンプレミスのユーザーはサポートされているエンドポイントで引き続き 1080p 30fps を使用します)。
強化され、差別化された QoS (Quality of Service) マーキング: 音声 (EF) とビデオ (AF41) の分離。
Webex ビデオ メッシュは現在、Webex Webinars をサポートしていません。エンドツーエンド暗号化ミーティング（E2EE ミーティング）をサポートします。 顧客がビデオ メッシュを展開し、E2EE ミーティング タイプを選択すると、セキュリティが強化され、データ (メディア、ファイル、ホワイトボード、注釈) が安全に保たれ、サードパーティによるアクセスや変更がブロックされます。 詳細については、「ゼロトラストミーティングの展開」を参照してください。
プライベート ミーティングは現在、エンドツーエンド暗号化をサポートしていません。
ビデオ メッシュ ノードを使用するクライアントとデバイス
私たちは、関連するクライアントやデバイスタイプとビデオメッシュを相互運用できるように努めています。 すべてのシナリオをテストすることはできませんが、このデータがベースになっているテストは、リストされているエンドポイントとインフラストラクチャの最も一般的な機能をカバーします。 デバイスまたはクライアントがないことは、テストの欠如と Cisco からの公式サポートの欠如を意味します。
クライアントまたはデバイスの種類 | ポイント ツー ポイント コールでビデオ メッシュ ノードを使用する | マルチパーティ ミーティングでビデオ メッシュ ノードを使用する |
|---|---|---|
Webex アプリ (デスクトップとモバイル) | はい | はい |
会議室デバイスや Webex Board を含む Webex デバイス。 (完全なリストについては、「エンドポイントと Webex アプリの要件」セクションを参照してください。) | はい | はい |
Webex アプリとサポートされている Room、Desk、および Board デバイス間の室内ワイヤレス共有。 | はい | はい |
Unified CM に登録されたデバイス (IX エンドポイントを含む) とクライアント (Jabber VDI 12.6 以降、Webex VDI 39.3 以降)、Webex スケジュール済みまたは Webex パーソナル会議室ミーティングへのコール。* | いいえ | はい |
VCS/Expressway に登録されたデバイス、Webex スケジュール済みまたは Webex パーソナル会議室のミーティングへのコール。* | いいえ | はい |
Webex クラウド登録ビデオ デバイスに Webex マイビデオ システムにコール | 適用なし | はい |
Webex アプリ ウェブ クライアント ( https://web.webex.com) | はい | はい |
Cisco Webex Calling に登録された電話 | いいえ | いいえ |
Webex自分のビデオシステムにコールバックして、プレミス登録されたSIPデバイスへ | 適用なし | いいえ |
*すべてのオンプレミスのデバイスとクライアントがVideo Meshソリューションでテストされていることを保証することはできません。
フル機能の Webex エクスペリエンスとのビデオ メッシュの非互換性
Webex アプリでフル機能の Webex エクスペリエンスを有効にすると、Webex アプリはビデオ メッシュ ノードでサポートされません。 この機能は現在、シグナリングとメディアを Webex に直接送信しています。 今後のリリースでは、Webex アプリとビデオ メッシュが互換性を持つようになります。 デフォルトでは、ビデオ メッシュを使用する顧客に対してこの機能を有効にしませんでした。
ビデオ メッシュとフル機能の Webex エクスペリエンスに問題がある可能性があります。
その機能の導入後に導入にビデオ メッシュを追加した場合。
ビデオ メッシュへの影響を知らずにこの機能を有効にした場合。
問題が発生した場合は、Cisco アカウント チームに連絡して、フル機能の Webex エクスペリエンス トグルを無効にします。
ビデオ メッシュ ノードでのサービスの質
ビデオ メッシュ ノードは、ビデオ メッシュ ノードとのすべてのフローで音声とビデオ ストリームを区別できるポート範囲を有効にすることで、推奨される Quality of Service (QoS) のベスト プラクティスに準拠します。 この変更により、QoS ポリシーを作成し、ビデオ メッシュ ノードとの間の送受信トラフィックを効果的に区別することができるようになります。
これらのポートの変更に伴い、QoS の変更も行われました。 ビデオ メッシュ ノードは、オーディオ（EF）とビデオ（AF41）の両方に対して、SIP 登録済みエンドポイント（オンプレミスの Unified CM または VCS Expressway が登録済み）からのメディア トラフィックを適切なサービス クラスで個別にマークし、特定のメディア タイプによく知られているポート範囲を使用します。
オンプレミスの登録済みエンドポイントからの送信トラフィックは常に、通話コントロール (Unified CM または VCS Expressway) 上での構成に基づいて決定されます。
詳細については、ビデオ メッシュで使用されるポートとプロトコルのQoS表と、ビデオ メッシュ展開タスク フローでQoSを有効または無効にする手順を参照してください。
Webex アプリは、共有ポート 5004 経由でビデオ メッシュ ノードに接続し続けます。 これらのポートは、Webex アプリとエンドポイントによって、ビデオ メッシュ ノードへの STUN 到達可能性テストにも使用されます。 カスケード用のビデオ メッシュ ノードからビデオ メッシュ ノードへの接続先ポートの範囲は 10000 ～ 40000 です。ビデオ メッシュのプロキシ サポート
ビデオ メッシュは、明示的、透過的な検査と非検査プロキシをサポートします。 これらのプロキシをビデオ メッシュ展開に結び付けることで、エンタープライズからクラウドへのトラフィックを保護および監視できます。 この機能は、シグナリングおよび管理用 https ベースのトラフィックをプロキシに送信します。 透過プロキシについては、ビデオ メッシュ ノードからのネットワーク要求はエンタープライズネットワーク ルーティング ルールにより、特定のプロキシに転送されます。 ノードでプロキシを実装した後、ビデオメッシュ管理インターフェイスを使用して証明書管理と全体的な接続ステータスを確認できます。
| メディアはプロキシを通して転送されません。 クラウドに直接到達するために、メディア ストリームに必要なポートを開く必要があります。 詳細は、管理用のポートとプロトコルを参照してください。 |
次のプロキシ タイプはビデオ メッシュによりサポートされています。
明示的プロキシ (検査または検査なし)—明示的なプロキシを使用して、プロキシサーバー使用するクライアント (ビデオ メッシュ ノード) を指示します。 このオプションは、次のいずれかの認証タイプに対応しています。
なし—追加の認証は必要ありません。 (HTTP または HTTPS 明示的プロキシの場合)
ベーシック—HTTP ユーザー エージェントがリクエストを行う際にユーザー名とパスワードを指定するために使用されます。 (HTTP または HTTPS 明示的プロキシの場合)
ダイジェスト—機密情報を送信する前にアカウントの識別を確認するために使用され、ネットワークを経由して送信する前に、ユーザー名とパスワードにハッシュ機能を適用します。 (HTTPS 明示的プロキシの場合)
NTLM—ダイジェストと同様に、NTLM は機密情報を送信する前にアカウントの ID を確認するために使用されます。 ユーザー名およびパスワードの代わりに Windows 資格情報を使用します。 この認証スキームでは、複数の交換が完了する必要があります。 (HTTP 明示的プロキシの場合)
透過型プロキシ (検査なし)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。
透過型プロキシ (検査あり)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。 ビデオ メッシュでは http(s) 構成の変更は必要ありませんが、ビデオ ノードはプロキシを信頼できるようにするためにルート証明書を必要とします。 プロキシの検査は、アクセスする Web サイトや許可されないコンテンツのタイプに関するポリシーを施行するために、一般的に IT が使用します。 このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。
ビデオ メッシュでサポートされる解像度とフレームレート
この表は、ビデオ メッシュ ノードでホストされているミーティングで、送信者と受信者の観点からサポートされている解像度とフレームレートについて説明します。 送信者クライアント(アプリまたはデバイス)はテーブルの上段にあり、受信者クライアントはテーブルの左側の列にあります。 2 人の参加者間の対応するセルは、ネゴシエートされたコンテンツ解像度、セクションごとのフレーム、およびオーディオ ソースをキャプチャします。
| 解像度は、ビデオ メッシュ ノードのコール容量に影響します。 詳細については、「ビデオ メッシュ ノードの容量」を参照してください。 |
解像度とフレームレート値は XXXpYY として組み合わされます。たとえば、720p10 は、10 フレーム/秒で 720p を意味します。
送信側行と受信側列の定義略語（SD、HD、および FHD）は、クライアントまたはデバイスの高解像度を示します。
SD—標準の定義 (576p)
HD—高解像度 (720p)
FHD—フル ハイビジョン (1080p)
レシーバー | 差出人の名前 | ||||||
|---|---|---|---|---|---|---|---|
Webex アプリ | Webex アプリ モバイル | SIP 登録デバイス (HD) | SIP 登録デバイス (FHD) | Webex 登録デバイス (SD) | Webex 登録デバイス (HD) | Webex 登録デバイス (FHD) | |
Webex アプリ デスクトップ | 720pの10 ミックスオーディオ* | 720pの10 音声が混在 | 720pの30 音声が混在 | 720pの30 音声が混在 | 576ページ コンテンツ音声** | 720pの30 音声が混在 | 720pの30 音声が混在 |
Webex アプリ モバイル | — | — | — | — | — | — | — |
SIP 登録デバイス (HD) | 720pの30 コンテンツ音声 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 |
SIP 登録デバイス (FHD) | 1080p30 音声が混在 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 |
| Webex 登録デバイス (SD) | 1080pの15 音声が混在 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080pの15 音声が混在 |
Webex 登録デバイス (FHD) | 1080p30 音声が混在 | 720pの15 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 | 576ページ 音声が混在 | 1080pの15 音声が混在 | 1080p30 音声が混在 |
* コンテンツ音声とは、共有されている特定のコンテンツ（ストリーミングビデオなど）から再生される音声を指します。 この音声ストリームは、通常のミーティングの音声とは異なります。
** 混合音声とは、ミーティング参加者の音声とコンテンツ共有からの音声のミックスです。
ビデオ メッシュの要件
ビデオ メッシュは、ハイブリッド サービスのライセンス要件に記載されているオファーで利用できます。
ビデオ メッシュの通話制御とミーティングの統合要件
ビデオ メッシュを使用するには、通話制御と既存のミーティング インフラストラクチャは必要ありませんが、2 つを統合できます。 ビデオ メッシュと通話制御およびミーティング インフラストラクチャを統合する場合は、環境が次の表に示す最低条件を満たしていることを確認してください。
コンポーネントの目的 | 最小のサポートされているバージョン |
|---|---|
オンプレミス通話制御 | Cisco Unified Communications Manager リリース 11.5(1) SU3 以降。 (最新の SU リリースをお勧めします。) Cisco Expressway-C または E、リリース X8.11.4 以降。 (詳細については、Expressway リリースノート の「重要な情報」セクションを参照してください。) |
ミーティングのインフラストラクチャ | Webex Meetings WBS33 以降。 (Cloud Collaboration Meeting Room サイト オプションで利用可能なメディア リソース タイプ リストがある場合、Webex サイトが正しいプラットフォームにあることを確認できます。)
サイトがビデオ メッシュの準備ができていることを確認するには、カスタマー サクセス マネージャー (CSM) またはパートナーに連絡してください。 |
フェールオーバー処理 | Cisco Expressway-C または E、リリース X8.11.4 以降。 (詳細については、Expressway リリースノート の「重要な情報」セクションを参照してください。) |
エンドポイントと Webex アプリの要件
コンポーネントの目的 | の詳細 |
|---|---|
サポートされるエンドポイント | Webex ビデオの互換性とサポートを参照してください。 |
Webex アプリのサポートバージョン | ビデオ メッシュは、デスクトップ (Windows、Mac) およびモバイル (Android、iPhone、iPad) 用の Webex アプリをサポートしています。 サポートされているプラットフォーム用のアプリをダウンロードするには、https://www.webex.com/downloads.htmlにアクセスしてください。 |
サポート対象のコーデック | サポートされている音声およびビデオ コーデックについては、「Webex|通話およびミーティングのビデオ仕様」を参照してください。 ビデオ メッシュの注意事項:
|
サポートされている Webex 登録済みの Room、Desk、Board デバイス | 次のデバイスがテストされ、ビデオ メッシュ ノードで動作することが確認されます。 |
ビデオ メッシュ ノード ソフトウェアのシステムおよびプラットフォーム要件
プロダクション環境
本番環境では、ビデオ メッシュ ノード ソフトウェアを特定のハードウェア構成にデプロイする方法が 2 つあります。
各サーバを 1 つの仮想マシンとして設定できます。これは、多くの SIP エンドポイントを含む展開に最適です。
VMNLite オプションを使用して、複数の小さな仮想マシンで各サーバを設定できます。 VMNLite は、ほとんどのクライアントとデバイスが Webex アプリと Webex 登録済みエンドポイントである展開に最適です。
これらの要件は、すべての設定で共通です。
VMware ESXi 7 または 8、vSphere 7 または 8
ハイパースレッディングの有効化
プラットフォームハードウェアから独立して動作するビデオ メッシュ ノードには、専用の vCPU と RAM が必要です。 他のアプリケーションとのリソースの共有はサポートされていません。 これは、ビデオ メッシュ ソフトウェアのすべての画像に適用されます。
CMS プラットフォーム上の Video Mesh Lite (VMNLite) イメージでは、VMNLite イメージのみをサポートします。 VMNLite ソフトウェアを使用した CMS ハードウェアには、他のビデオ メッシュ イメージやビデオ メッシュ 以外のアプリケーションを使用することはできません。
ハードウェア構成 | 単一の仮想マシンとしての本番環境の展開 | VMNLite VM を使用した本番環境の展開 | 注 | ||
|---|---|---|---|---|---|
Cisco Meeting Server 1000 (CMS 1000) |
| 3つの同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| ビデオ メッシュ ノードには、このプラットフォームをお勧めします。
| ||
仕様ベースの構成 (2.6 GHz Intel Xeon E5-2600v3 以降のプロセッサが必要) |
| 3つの同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| 各ビデオ メッシュ 仮想マシンには、CPU、RAM、およびハード ドライブが専用に予約されている必要があります。 設定中に［CMS1000］または［VMNLite］オプションを使用します。 NFSストレージのピークIOP(毎秒入出力操作)は300IOPSです。 | ||
Cisco Meeting Server 2000（CMS 2000） | 8つの同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| 24個の同一の仮想マシンインスタンスとして展開します。それぞれには以下が含まれます。
| ビデオ メッシュ ノードには、このプラットフォームをお勧めします。 各ブレードは、ブレードごとに予約済みの CPU、RAM、およびハードドライブを備えた Cisco Meeting Server 1000 である必要があります。 NFS ストレージのピーク IOP は 300 IOPS です。 |
デモ環境
基本的なデモの目的で、以下の最小要件を備えた仕様ベースのハードウェア構成を使用できます。
14vCPU (ビデオ メッシュ ノードは 12、ESXi は 2)
8 GB メインメモリ
20 GB ローカルハードディスクスペース
2.6 GHz Intel Xeon E5-2600v3 もしくはそれ以上のプロセッサ
| このビデオ メッシュの設定は Cisco TAC ではサポートされていません。 |
デモソフトウェアの詳細については、「ビデオ メッシュ ノード デモソフトウェア」を参照してください。
帯域幅要件
ビデオ メッシュ ノードは、アップロードとダウンロードの両方が正常に機能するには、10 Mbps の最小インターネット帯域幅が必要です。
ビデオ メッシュのプロキシ サポートの要件
ビデオ メッシュ ノードと統合できる次のプロキシ ソリューションを正式にサポートしています。
透過プロキシ用の Cisco Web Security Appliance (WSA)
明示的プロキシ用の Squid
明示的なプロキシまたは検査する透過的な検査プロキシ (トラフィックを復号化) の場合、Web インターフェイスの Video Mesh ノード信頼ストアにアップロードする必要があるプロキシのルート証明書のコピーが必要です。
以下の明示的なプロキシと認証タイプの組み合わせをサポートしています。
http および https による認証がありません
http および https による基本認証
https のみによるダイジェスト認証
http のみによる NTLM 認証
透過プロキシについては、ルーター/スイッチを使用して、HTTPS/443 トラフィックをプロキシに移動する必要があります。 また、Web Socket を強制的にプロキシに移動することもできます。 (Web ソケットは https を使用します。)
ビデオ メッシュでは、ノードが正しく機能するように、クラウド サービスへの Web ソケット接続が必要です。 明示的な検査プロキシと透過的な検査プロキシでは、適切な websocket 接続のために http ヘッダーが必要です。 変更されると、Websocket 接続は失敗します。
ポート 443 で websocket 接続障害が発生すると（透過的な検査プロキシが有効になっている）、Control Hub で登録後の警告が表示されます。 「Webex ビデオ メッシュ SIP は正しく動作していません。」 プロキシが有効になっていない場合、同じ警告が発生する可能性があります。 websocket ヘッダーがポート 443 でブロックされている場合、メディアはアプリと SIP クライアント間ではフローしません。
メディアがフローしていない場合、ポート 444 経由の https トラフィックが失敗した場合にしばしば発生します。
ポート 444 トラフィックはプロキシによって許可されていますが、これはプロキシを検査し、websocket を壊すことになります。
これらの問題を修正するには、ポート 443 で「バイパス」または「スプライス」（検査を無効にする）を行う必要がある場合があります。 *.wbx2.com および *.ciscospark.com
ビデオ メッシュ ノードの容量
ビデオ メッシュはソフトウェアベースのメディア製品であるため、ビデオ メッシュ ノードの容量は異なります。 特に、Webex クラウドのミーティング参加者はノードに負荷をかけます。 Webex クラウドへのカスケードが増えると、容量が少なくなります。 能力に影響を与えるその他の要因:
デバイスとクライアントの種類
ビデオ解像度
ネットワークの品質
ピーク負荷
展開モデル
| ビデオ メッシュの使用は、Webex ライセンス数には影響しません。 |
一般に、クラスタにノードを追加しても、カスケードを設定するためのオーバーヘッドがあるため、容量が倍増しません。 これらの数字を一般的なガイダンスとして使用します。 以下のことをおすすめします：
展開の共通のミーティング シナリオをテストします。
Control Hub の分析を使用して、展開がどのように進化しているかを確認し、必要に応じて容量を追加します。
| 低通話量（特にオンプレミスに発信する SIP コール）でのオーバーフローは、スケールの真の反映ではありません。 ビデオ メッシュ アナリティクス (Control Hub > Resources > Call Activity) は、オンプレミスで発信されるコール レッグを示します。 メディア処理のためにカスケードからビデオ メッシュ ノードに入ってきたコール ストリームを指定しません。 ミーティングでリモート参加者数が増加すると、ビデオ メッシュ ノード上のオンプレミス メディア リソースが増加し、消費されます。 |
この表には、通常のビデオ メッシュ ノードのさまざまなミックスの参加者およびエンドポイントの容量範囲が一覧表示されます。 テストには、ローカル ノード上のすべての参加者とのミーティングと、ローカルとクラウドの参加者が混在するミーティングが含まれます。 Webex クラウドの参加者が増えると、キャパシティは範囲の下限に達する見込みです。
シナリオ | 解像度 | 参加者の容量 |
|---|---|---|
Webex アプリ参加者だけのミーティング | 720p | 小惑星の一覧 |
1080p | 90～100 | |
Webex アプリ参加者のみとのミーティングと 1 対 1 の通話 | 720p | 六〇、一〇〇 |
1080p | 90～100 | |
SIP 参加者だけのミーティング | 720p | 七〇、八〇 |
SIP 参加者だけのミーティング | 1080p | 30～40 |
Webex アプリと SIP 参加者とのミーティング | 720p | 小惑星の一覧 |
|
|
VMNLiteの容量
主に Webex アプリとクラウド登録エンドポイントを含む展開には、VMNLite を推奨します。 これらの展開では、ノードは標準設定が提供するより多くのスイッチングと少ないトランスコーディングリソースを使用します。 ホストに複数の小さな仮想マシンを展開すると、このシナリオのリソースが最適化されます。
この表には、さまざまなミックスの参加者およびエンドポイントの容量範囲が一覧表示されます。 テストには、ローカル ノード上のすべての参加者とのミーティングと、ローカルとクラウドの参加者が混在するミーティングが含まれます。 Webex クラウドの参加者が増えると、キャパシティは範囲の下限に達する見込みです。
シナリオ | 解像度 | サーバー上の 3 つの VMNLite ノードを持つ参加者容量 |
|---|---|---|
Webex アプリ参加者だけのミーティング | 720p | 250～300 |
1080p | 小惑星の一覧 | |
Webex アプリ参加者のみとのミーティングと 1 対 1 の通話 | 720p | 小惑星の一覧 |
1080p | 小惑星の一覧 |
| Webex アプリ ミーティングの基本解像度は 720p です。 ただし、共有すると、参加者のサムネイルは 180p になります。 |
ビデオ メッシュのクラスタ
ビデオ メッシュ ノードをクラスタに展開します。 クラスタは、ネットワーク近接性など、同様の属性を持つビデオ メッシュ ノードを定義します。 参加者は次の条件に応じて、特定のクラスタまたはクラウドを使用します。
オンプレミス クラスタに到達できる企業ネットワーク上のクライアントは、そのクラスタに接続します。これは、企業ネットワーク上のクライアントの主な優先事項です。
ビデオ メッシュ プライベート ミーティングに参加するクライアントは、オンプレミス クラスタにのみ接続します。 これらのプライベート ミーティング用に別のクラスタを作成できます。
オンプレミス クラスタに到達できないクライアントはクラウドに接続します。これは、社内ネットワークに接続されていないモバイル デバイスの場合です。
選択したクラスタは、ロケーションだけでなく、レイテンシーにも依存します。 たとえば、ビデオ メッシュ クラスタよりも STUN 往復遅延（SRT）が低いクラウド クラスタは、ミーティングの候補として優れている可能性があります。 このロジックは、ユーザが SRT 遅延の大きい地理的に遠いクラスタに着陸するのを防ぎます。
各クラスタには、必要に応じて他のクラウド ミーティング クラスタ間で、ビデオ メッシュ プライベート ミーティングを除き、ミーティングをカスケードするロジックが含まれています。 カスケードは、ミーティングのクライアント間のメディアにデータパスを提供します。 ミーティングはノード間で分散され、クライアントは、ネットワーク トポロジ、WAN リンク、リソース使用率などの要因に応じて、最寄りの最も効率的なノードに着陸します。
クライアントの ping メディア ノードに対する能力によって、到達可能性が決定されます。 実際のコールでは、UDP や TCP など、さまざまな潜在的な接続メカニズムが使用されます。 通話の前に、Webex デバイス (Room、Desk、Board、および Webex アプリ) が Webex クラウドに登録され、通話のクラスタ候補のリストが表示されます。
| ビデオ メッシュ クラスタ内のノードは、相互に障害のない通信を必要とします。 また、他のすべてのビデオ メッシュ クラスタのノードとの障害のない通信も必要です。 ファイアウォールがビデオ メッシュ ノード間のすべての通信を許可していることを確認します。 |
プライベート ミーティングのクラスタ
プライベート ミーティング用のビデオ メッシュ クラスタを予約できます。 予約済みクラスタがいっぱいになると、プライベート ミーティング メディアは他のビデオ メッシュ クラスタにカスケードアウトします。 予約済みクラスタがいっぱいになると、プライベート ミーティングと非プライベート ミーティングは、残りのクラスタのリソースを共有します。
プライベート ミーティング以外のミーティングでは、予約済みクラスタを使用せず、プライベート ミーティングにこれらのリソースを予約します。 プライベート ミーティング以外のミーティングでネットワーク上のリソースが不足している場合、代わりに Webex クラウドにカスケードアウトします。
ビデオ メッシュのプライベート ミーティング機能の詳細については、「プライベート ミーティング」を参照してください。
| すべてのビデオ メッシュ クラスタをプライベート ミーティングに予約する場合、ショート ビデオ アドレス形式 (meet@your_site) を使用できません。 これらのコールは現在、適切なエラー メッセージなしで失敗します。 一部のクラスタを予約解除しておくと、ショート ビデオ アドレス形式のコールがこれらのクラスタを介して接続できます。 |
ビデオ メッシュ クラスタ展開のガイドライン
一般的なエンタープライズ展開では、クラスタごとに最大 100 ノードを使用することを推奨します。 システムには、100 ノードを超えるクラスタ サイズをブロックするハード制限が設定されていません。 ただし、より大きなクラスタを作成する必要がある場合は、Cisco Account Team を通じて Cisco エンジニアリングでこのオプションを確認することを強くお勧めします。
リソースが近似したネットワークプロキシミティ(類似性)を有する際に数を少なくしてクラスタを作成します。
クラスタを作成するときは、同じ地理的地域と同じデータセンターにあるノードのみを追加します。 広域ネットワーク（WAN）全体のクラスタリングはサポートされていません。
一般的には、頻繁にその地域でミーティングを開催するエンタープライズでクラスタを展開します。 エンタープライズの中のさまざまな WAN のロケーションで使用可能な帯域に、クラスタを配置することを計画してください。 時間をかけて、観察されるユーザーのパターンに基づいて、クラスタごとに点かいして、拡張していくことができます。
異なったタイムゾーンに配置されたクラスタは、通話パターンの違ったピーク/不通状態の時間帯の利点を生かして、効果的に複数の地点にサービスを提供できます。
2 つの別々のデータセンター (EU と NA など) に 2 つのビデオ メッシュ ノードがあり、各データセンターを介してエンドポイントが結合されている場合、各データセンターのノードはクラウド内の 1 つのビデオ メッシュ ノードにカスケードされます。 これらのカスケードはインターネットで行われます。 クラウド参加者 (ビデオ メッシュ参加者の 1 人の前に参加する) がある場合、ノードはクラウド参加者のメディア ノードを介してカスケードされます。
タイムゾーンの多様性
タイムゾーンの多様性により、クラスタはオフピークタイムを共有することができます。 例: Northern California クラスタと New York クラスタのある会社では、総合的なネットワークの滞在性は、地理的に多様性のあるユーザー人口にサービスを提供する二つのロケーションの間であまり高くありません。 リソースが Northern California クラスタで使用量がピークに達したときに、New York クラスタはオフ ピークになり、追加の容量をもつことがよくあります。 同じことが、New York クラスタがピーク時の間の Northern California クラスタにも適用されます。 これらは効率的なリソースの展開に使用される唯一のメカニズムではなく、2 つともメインのメカニズムでもあります。
クラウドにオーバーフロー
すべてのオンプレミス クラスタの容量に達すると、オンプレミスの参加者は Webex クラウドにオーバーフローします。 これは、すべてのコールがクラウドでホストされていることを意味するものではありません。 Webex は、リモートまたはオンプレミス クラスタに接続できない参加者のみをクラウドに転送します。 オンプレミスもしくはクラウドの参加者の両方の通話において、オンプレミスクラスタはクラウドにブリッジ[カスケード]接続され、全参加者を単一通話にまとめます。
ミーティングをプライベート ミーティング タイプとして設定した場合、Webex はすべての通話をオンプレミス クラスタに保存します。 プライベート ミーティングはクラウドにオーバーフローすることはありません。
Webex デバイスが Webex に登録される
到達可能性の決定に加えて、クライアントはNAT (STUN)を通じてUDPのSimple Traversalを使用して、一定期間ごとの往復遅延テストも実施します。 STUN 往復 (SRT) 遅延は実際の通話の間の可能性のあるリソースを選択する際に重要な要素となります。 複数のクラスタが展開される際、プライマリ選択基準は情報が得られた SRT 遅延に基づきます。 到達可能性テストはバックグラウンドで実施され、ネットワーク変更を含む要素の数で開始されます。まだこれで発信設定時間に影響を及ぼす遅延は起こりません。 次の二つの例では可能性のある到達可能性テストの結果が示されています。
ラウンド トリップ遅延テスト - クラウド デバイスがオンプレミス クラスタに到達できません
ラウンド トリップ遅延テスト - クラウド デバイスがオンプレミスのクラスタに正常に到達します
コールがセットアップされるたびに、学習された到達可能性情報が Webex クラウドに提供されます。 これによりクラウドは顧客の使用可能なクラスタおよび通話の種類に関連したロケーションにおいて最適なリソース (クラスタもしくはクラウド) を選択できます。 優先クラスタで利用可能なリソースがない場合、すべてのクラスタは SRT 遅延に基づいてアベイラビリティについてテストされます。 希望するクラスタは最も低い SRT 遅延で選択されます。 プライマリ クラスタがビジーの場合、セカンダリ クラスタからオンプレミスで通話が行われます。 ローカルの到達可能なビデオ メッシュ リソースは、最小