ネットワークの推奨事項
この記事では、ネットワーク環境が音声およびビデオ通話の品質にどのような影響を与えるかをまとめます。 音声、ビデオ、アプリケーション共有を含む Azure Communication Services のリアルタイム メディアの品質には、多くの要素が影響します。 それらの要素には、ネットワークの品質と帯域幅、ファイアウォール、ホスト、デバイス構成などがあります。
ネットワークの品質
IP 経由のリアルタイム メディアの品質は、基になるネットワーク接続の品質、特に以下の量から大きな影響を受けます。
- 待機時間。 ネットワーク上の A 地点から B 地点に IP パケットが届くのにかかる時間。 このネットワーク伝達がどれだけ遅延するかは、2 地点間の物理的な距離と、トラフィックが経由するデバイスで発生する他のオーバーヘッドによって決まります。 待機時間は、一方向の時間かラウンドトリップ時間 (RTT) として測定されます。
- パケット損失。 特定の時間枠において失われるパケットの割合。 パケット損失は音声の品質に直接的に影響します。個々のパケットが失われる小規模なケースではほとんど影響はありませんが、連続して爆発的な損失が発生すると音声が完全に途切れます。
- パケット到着間ジッター (ジッターとも呼ばれます)。 連続するパケット間の遅延の変化の平均値。 Communication Services では、バッファーリングによって一定レベルのジッターに対応できます。 ジッターがバッファーリングを超過した場合にのみ、参加者はその効果に気付きます。
ネットワーク帯域幅
Communication Services の同時メディア セッションとその他のビジネス アプリケーションに必要な帯域幅をサポートできるよう、ネットワークを確実に構成してください。 帯域幅のボトルネックがないかエンドツーエンドのネットワーク パスをテストすることが、Communication Services のマルチメディア ソリューションのデプロイを成功させるうえで重要です。
次の帯域幅要件は、JavaScript SDK に対するものです。
| 帯域幅 | シナリオ |
|---|---|
| 40 Kbps | ピアツーピアの音声通話 |
| 500 Kbps | ピアツーピアの音声通話と画面共有 |
| 500 Kbps | 360 ピクセル、30 FPS のピアツーピア品質ビデオ通話 |
| 1.2 Mbps | 720 ピクセルの HD 解像度、30 FPS のピアツーピア HD 品質ビデオ通話 |
| 500 Kbps | 360 ピクセル、30 FPS のグループ ビデオ通話 |
| 1.2 Mbps | 720 ピクセルの HD 解像度、30 FPS の HD グループ ビデオ通話 |
| 1.5 Mbps | 1080 ピクセルの HD 解像度、30 FPS のピアツーピア HD 品質ビデオ通話 |
次の帯域幅要件は、Windows、Android、iOS のネイティブ SDK に対するものです。
| 帯域幅 | シナリオ |
|---|---|
| 30 Kbps | ピアツーピアの音声通話 |
| 130 Kbps | ピアツーピアの音声通話と画面共有 |
| 500 Kbps | 360 ピクセル、30 FPS のピアツーピア品質ビデオ通話 |
| 1.2 Mbps | 720 ピクセルの HD 解像度、30 FPS のピアツーピア HD 品質ビデオ通話 |
| 1.5 Mbps | 1080 ピクセルの HD 解像度、30 FPS のピアツーピア HD 品質ビデオ通話 |
| 500 Kbps/1 Mbps | グループ ビデオ通話 |
| 1 Mbps/2 Mbps | 1080 ピクセル画面上の 540 ピクセル ビデオでの HD グループ ビデオ通話 |
ファイアウォールの構成
Communication Services の接続では、高品質なマルチメディア エクスペリエンスを提供するために、特定のポートと IP アドレスへのインターネット接続が必要です。 これらのポートと IP アドレスへのアクセスがない場合、Communication Services は正しく機能しません。 有効にする必要がある IP 範囲の一覧と許可リストのドメインは次のとおりです。
| カテゴリ | IP 範囲または FQDN | Port |
|---|---|---|
| メディア トラフィック | Azure パブリック クラウド IP アドレス 20.202.0.0/16 の範囲 上記の範囲は、Media プロセッサまたは Azure Communication Services TURN サービスでの IP アドレス範囲です。 | UDP 3478 から 3481、TCP ポート 443 |
| シグナリング、テレメトリ、登録 | *.skype.com、*.microsoft.com、*.azure.net、*.azure.com、*.office.com | TCP 443、80 |
以下のエンドポイントは、米国政府 GCC High のお客様のみが到達可能である必要があります。
| カテゴリ | IP 範囲または FQDN | Port |
|---|---|---|
| メディア トラフィック | 52.127.88.0/21, 52.238.114.160/32, 52.238.115.146/32, 52.238.117.171/32, 52.238.118.132/32, 52.247.167.192/32, 52.247.169.1/32, 52.247.172.50/32, 52.247.172.103/32, 104.212.44.0/22, 195.134.228.0/22 | UDP 3478 から 3481、TCP ポート 443 |
| シグナリング、テレメトリ、登録 | *.gov.teams.microsoft.us、*.infra.gov.skypeforbusiness.us、*.online.gov.skypeforbusiness.us、gov.teams.microsoft.us | TCP 443、80 |
ネットワーク最適化
次のタスクは省略可能です。Communication Services のロールアウトに必須ではありません。 このガイダンスは、ご自分のネットワークになんらかの制限があるとわかっている場合に、ネットワークと Communication Services のパフォーマンスを最適化するために使用します。 さらに、以下の場合にも最適化が必要と考えられます。
- Communication Services の動作が遅い。 帯域幅が不足している可能性があります。
- 通話が繰り返し切断する。 切断は、ファイアウォールまたはプロキシのブロッカーによって発生する場合があります。
- 通話が雑音交じりで途切れる。または、音声がロボットのように聞こえる。 これらの問題は、ジッターまたはパケット損失によって発生する場合があります。
| ネットワーク最適化のタスク | 詳細 |
|---|---|
| ネットワークを計画する | このドキュメントには、通話用のネットワークに対する最小要件が記載されています。 ネットワークを計画するための Teams サンプルに関するページを参照してください。 |
| 外部名前解決 | Communication Services SDK を実行しているすべてのコンピューターが、通信サービスによって提供されるサービスを検出するために外部 DNS クエリを解決できるようにするほか、アクセスがファイアウォールによって妨げられていることのないようにします。 SDK で *.skype.com、*.microsoft.com、*.azure.net、*.azure.com、*.office.com のアドレスを解決できることを確認してください。 |
| セッション永続化の維持 | UDP 用のマップ済みネットワーク アドレス変換 (NAT) アドレスまたはポートが、ファイアウォールによって変更されないようにします。 |
| NAT プール サイズの検証 | ユーザーの接続に必要な NAT プール サイズを検証します。 複数のユーザーとデバイスが NAT またはポート アドレス変換 を使用して Communication Services にアクセスする場合は、パブリックにルーティング可能な各 IP アドレスの背後に隠されているデバイスが、サポートされる数を超過しないようにします。 ポート不足を防ぐために、適切なパブリック IP アドレスが NAT プールに割り当てられるようにしてください。 ポート不足は、内部のユーザーとデバイスが Communication Services に接続できなくなる原因となります。 |
| 侵入の検出と防止に関するガイダンス | アウトバウンド接続にセキュリティ レイヤーを追加するために侵入検出システムまたは侵入防止システムがお使いの環境にデプロイされている場合は、Communication Services の URL をすべて許可します。 |
| スプリットトンネル VPN の構成 | 仮想プライベート ネットワーク (VPN) をバイパスする Teams トラフィックのための代替パスを用意します。これは一般に分割トンネル VPN と呼ばれます。 分割トンネリングでは、Communications Services のトラフィックが VPN を経由せず、Azure に直接送信されます。 VPN をバイパスすると、メディアの品質に良い影響があり、VPN デバイスと組織のネットワークの負荷が減少します。 スプリットトンネル VPN を実装するには、VPN ベンダーにご相談ください。 VPN のバイパスが推奨されるその他の理由は以下のとおりです。
|
| QoS の実装 | サービスの品質 (QoS) を使用して、パケットの優先順位付けを構成します。 QoSにより、通話の品質が向上するほか、通話の品質の監視とトラブルシューティングが行いやすくなります。 QoS は、マネージド ネットワークのすべてのセグメントで実装される必要があります。 ネットワークが適切にプロビジョニングされ帯域幅が確保されている場合も、予定外のネットワーク イベントが発生した際に QoS によってリスクが緩和されます。 QoS を使用すると、そういった予定外のイベントが品質に悪影響を及ぼすことのないように、音声トラフィックが優先順位付けされます。 |
| Wi-Fi の最適化 | VPN と同様に、Wi-Fi ネットワークは必ずしもリアルタイム メディアをサポートするように設計または構成されていません。 Communication Services をサポートするよう Wi-Fi ネットワークを計画または最適化することは、高品質なデプロイを実現するうえで重要な考慮事項です。 次の点を考慮します。
|
オペレーティング システムとブラウザー (JavaScript SDK 向け)
Communication Services の音声およびビデオ SDK では、特定のオペレーティング システムとブラウザーがサポートされます。 通話 SDK でサポートされるオペレーティング システムとブラウザーについては、通話の概念説明ドキュメントを参照してください。
次のステップ
次の記事が役立つ可能性があります。
- 通話ライブラリについて学習する。
- クライアント - サーバー アーキテクチャについて学習する。
- 通話フローのトポロジについて学習する。