次の方法で共有


ネットワークの推奨事項

この記事では、ネットワーク環境が音声およびビデオ通話の品質にどのような影響を与えるかをまとめます。 音声、ビデオ、アプリケーション共有を含む 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 のバイパスが推奨されるその他の理由は以下のとおりです。
  • VPN は通常、リアルタイム メディアをサポートする設計または構成になっていません。
  • また VPN では、Communication Services に必要である UDP がサポートされていない場合があります。
  • さらに VPN では、既に暗号化されているメディア トラフィックの上に追加の暗号化レイヤーを導入します。
  • VPN デバイス経由のヘアピン トラフィックが原因で、Communication Services への接続が効率的でないおそれがあります。
QoS の実装 サービスの品質 (QoS) を使用して、パケットの優先順位付けを構成します。 QoSにより、通話の品質が向上するほか、通話の品質の監視とトラブルシューティングが行いやすくなります。 QoS は、マネージド ネットワークのすべてのセグメントで実装される必要があります。 ネットワークが適切にプロビジョニングされ帯域幅が確保されている場合も、予定外のネットワーク イベントが発生した際に QoS によってリスクが緩和されます。 QoS を使用すると、そういった予定外のイベントが品質に悪影響を及ぼすことのないように、音声トラフィックが優先順位付けされます。
Wi-Fi の最適化 VPN と同様に、Wi-Fi ネットワークは必ずしもリアルタイム メディアをサポートするように設計または構成されていません。 Communication Services をサポートするよう Wi-Fi ネットワークを計画または最適化することは、高品質なデプロイを実現するうえで重要な考慮事項です。 次の点を考慮します。
  • QoS または Wi-Fi Multimedia を実装して、メディア トラフィックが Wi-Fi ネットワーク上で適切に優先順位付けされるようにします。
  • Wi-Fi バンドとアクセス ポイントの場所を計画および最適化します。 2.4 GHz 帯でもアクセス ポイントの配置によっては適切なエクスペリエンスを実現できるかもしれませんが、アクセス ポイントは、この帯で動作する他のコンシューマー デバイスの影響を頻繁に受けます。 5 GHz 帯の方が密度が高いため、リアルタイム メディアに適しています。ただし、十分な範囲をカバーにするためにアクセス ポイントを増やす必要があります。 さらに、エンドポイントもこの帯をサポートし、これらの帯を使用するよう構成する必要があります。
  • デュアルバンド Wi-Fi ネットワークを使用している場合は、バンド ステアリングの実装を検討します。 バンド ステアリングは、デュアルバンドのお客様が 5 GHz 帯を使用するようにする技術で、Wi-Fi ベンダーによって実装されます。
  • 同じチャネルのアクセス ポイントが互いに近すぎると、信号の重複と意図しない競合が発生し、結果としてユーザー エクスペリエンスが低下するおそれがあります。 隣接するアクセス ポイントが、重複しないチャネルに配置されるようにします。
ワイヤレス ベンダー各社は、そのワイヤレス ソリューションをデプロイするうえで独自の推奨事項を持っています。 固有のガイダンスについては、お使いの Wi-Fi ベンダーにご相談ください。

オペレーティング システムとブラウザー (JavaScript SDK 向け)

Communication Services の音声およびビデオ SDK では、特定のオペレーティング システムとブラウザーがサポートされます。 通話 SDK でサポートされるオペレーティング システムとブラウザーについては、通話の概念説明ドキュメントを参照してください。

次のステップ

次の記事が役立つ可能性があります。