この記事では、ネットワーク環境が音声通話とビデオ通話の品質に与える影響をまとめたものです。 多くの要因が、オーディオ、ビデオ、アプリケーション共有を含む Azure Communication Services のリアルタイム メディアの品質に寄与します。 一部の要因には、ネットワークの品質と帯域幅、ファイアウォール、ホスト、およびデバイスの構成が含まれます。
ネットワーク品質
基になるネットワーク接続の品質は、IP 経由のリアルタイム メディアに悪影響を及ぼす可能性があります。 最も重要な要因は次のとおりです。
- 待機時間。 ネットワーク上のポイント A からポイント B への IP パケットの取得にかかる時間。 ネットワーク伝達遅延は、2 つのポイント間の物理的な距離と、トラフィックが通過するデバイスによって発生するその他のオーバーヘッドの係数です。 待機時間は、一方向またはラウンドトリップ時間 (RTT) として測定されます。
- パケット損失。 特定の期間に失われたパケットの割合。 パケット損失はオーディオの品質に直接影響を与えます。個々の小さなパケットの損失はほとんど影響を及ぼしませんが、連続したバースト損失は完全なオーディオの途切れを引き起こす可能性があります。
- パケット間到着ジッター(ジッターとも呼ばれます)。 連続するパケット間の遅延の変化の平均値。 Communication Services は、バッファリングによって一部のレベルのジッターに適応できます。 ジッターがバッファリングを超えた場合にのみ、参加者はその影響に気付きます。
ネットワーク帯域幅
同時 Communication Services メディア セッションやその他のビジネス アプリケーションで必要な帯域幅をサポートするようにネットワークが構成されていることを確認します。 帯域幅のボトルネックに対するエンドツーエンドのネットワーク パスのテストは、マルチメディア Communication Services ソリューションのデプロイを成功させるために不可欠です。
JavaScript SDK の帯域幅要件は次のとおりです。
| 帯域幅 | シナリオ |
|---|---|
| 40 Kbps | ピアツーピアオーディオ通話 |
| 500 Kbps | ピアツーピア音声通話と画面共有 |
| 500 Kbps | 30FPSで360ピクセルのピアツーピア品質ビデオ通話 |
| 1.2 Mbps | HD 品質のピアツーピアビデオ通話は、30 FPS で HD 720 ピクセルの解像度です。 |
| 500 Kbps | 30 FPS で 360 ピクセルのグループ ビデオ通話 |
| 1.2 Mbps | 30 FPS で HD 720 ピクセルの解像度で HD グループビデオ通話 |
| 1.5 Mbps | ピアツーピアのHD品質のビデオ通話で、HD 1080ピクセルの解像度で30 FPSです。 |
ネイティブ Windows、Android、iOS SDK の帯域幅要件は次のとおりです。
| 帯域幅 | シナリオ |
|---|---|
| 30 Kbps | ピアツーピアオーディオ通話 |
| 130 Kbps | ピアツーピア音声通話と画面共有 |
| 500 Kbps | 30FPSで360ピクセルのピアツーピア品質ビデオ通話 |
| 1.2 Mbps | HD 品質のピアツーピアビデオ通話は、30 FPS で HD 720 ピクセルの解像度です。 |
| 1.5 Mbps | ピアツーピアのHD品質のビデオ通話で、HD 1080ピクセルの解像度で30 FPSです。 |
| 500 Kbps/1 Mbps | グループ ビデオ通話 |
| 1 Mbps/2 Mbps | HD グループビデオ通話、540ピクセルのビデオが1080ピクセルの画面で表示される |
ファイアウォールの構成
Communication Services 接続では、高品質のマルチメディア エクスペリエンスを提供するために、特定のポートと IP アドレスへのインターネット接続が必要です。 これらのポートと IP アドレスにアクセスしないと、Communication Services は正しく機能しません。 有効にする必要がある IP 範囲と許可するドメインの一覧は次のとおりです。
| カテゴリ | IP 範囲または FQDN | ポート |
|---|---|---|
| メディア トラフィック | Azure パブリック クラウド IP アドレスの範囲 20.202.0.0/16。 ここで指定する範囲は、メディア プロセッサまたは Azure Communication Services TURN サービスの IP アドレスの範囲です。 | UDP 3478 から 3481、TCP ポート 443 |
| シグナリング、テレメトリ、登録 | *.skype.com、*.microsoft.com、*.azure.net、*.azure.com、*.office.com | TCP 443、80 |
| Call Automation メディア | 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/38 | UDP: 3478、3479、3480、3481 |
| コールオートメーションのコールバックURL | *.lync.com、*.teams.cloud.microsoft、*.teams.microsoft.com、teams.cloud.microsoft、teams.microsoft.com、52.112.0.0/14、52.122.0.0/15、2603:1027::/48、2603:1037::/48、2603:1047::/48、2603:1057::/48、2603:1063::/38、2620:1ec:6::/48、2620:1ec:40::/42 | TCP: 443、80 UDP: 443 |
次のエンドポイントに到達できるのは、米国政府 GCC High のお客様のみです。
| カテゴリ | IP 範囲または FQDN | ポート |
|---|---|---|
| メディア トラフィック | 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 と呼ばれます。 分割トンネリングとは、Communication 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 では、特定のオペレーティング システムとブラウザーがサポートされます。 呼び出し元 SDK でサポートされるオペレーティング システムとブラウザーについては、 Calling の概念に関するドキュメントを参照してください。
次のステップ
- ライブラリの呼び出しについて詳しくは、こちらをご覧ください。
- クライアントとサーバーのアーキテクチャについて説明します。
- 呼び出しフロー トポロジについて説明します。
- Azure Communication Services と Azure ExpressRoute の統合について説明します。