xAssistは、通信プロトコルとしてWebRTCを使用して、ピアツーピア接続を介したリアルタイム通信を可能にするように構成できます。WebRTCはかなり複雑なドメインであり、リアルタイムトランスポートプロトコルを使用してオーディオとビデオを送信します。ネットワークインフラストラクチャがWebRTC通信をブロックしておらず、アウトバウンドトラフィックとリターントラフィックを許可していることを確認してください。
最適なユーザーエクスペリエンスを得るには、最新の Google Chrome または Microsoft Edge (Chromium ベース) ブラウザーを使用することをお勧めします。WebブラウザがコンピューターのWebカメラ、マイク、およびスピーカーにアクセスできることを確認してください、そうしないとxAssistが正しく機能しません。
Microsoft Active Directory 環境では、グループ ポリシーによって、コンピューターの Web カメラとマイクへのアクセスを拒否できます。ウェブカメラにアクセスできることを確認してください。
xAssistは、利用可能な帯域幅に継続的に適応します。使用可能な帯域幅が低い場合、ストリーミング品質は自動的に低下します。これは主にビデオ品質に適用されますが、ビデオフィードが中断された場合でも、オーディオを送信できる必要があります。
全体として、xAssistは、xAssistを使用するために必要な帯域幅を決定するために、さまざまな要因に依存しています。一般に、次の帯域幅要件が適用されます。
レイテンシーもxAssistを使用する際の重要な要素です。
手記: 低レイテンシーは高レイテンシーよりも優れています。
UDPは、2つのプロトコルの違いによって引き起こされるパケット転送の遅延を減らすため、TCPよりも優先されます。
プロキシ経由のUDPをサポートしているブラウザはないため、UDPを使用する場合は、データがプロキシをバイパスする必要があります。パケット インスペクションは、遅延が長くなります。多くの場合、パケット インスペクションを使用する場合の遅延が非常に大きくなり、ビデオ コールの確立が妨げられます。
STUNサーバは非常に単純なジョブを実行し、ネットワークアドレス変換(NAT)サービスの背後にある実際のパブリックIPアドレスとポートをクライアントに通知します。STUNサーバーを使用することで、クライアントがインターネット上の他のクライアントからのピアツーピア接続を受け入れているかどうかを推測できます。
TURN サーバは、ピアツーピア接続を確立できないクライアントにフォールバック ソリューションを提供し、2 つのピア間のメディア サーバ プロキシとして機能します。
シグナリングは、クライアント間でビデオおよびオーディオ ストリームを開始するために使用されます。xAssistでは、シグナリングは、通常の通話の場合はフロントラインコマンドセンターを介して、電話会議の場合は選択的転送ユニットを介して行われます。
WebRTCはICEを使用して、クライアント(Webおよびスマートグラス)が通話で相互に通信するための最適な方法(ピアツーピア、クライアント間のネットワークアドレス変換(NAT)によるピアツーピア(STUNサーバを使用)、またはTURNサーバを使用したリレー)を見つけようとします。
通常の通話(会議ではない)の場合、クライアント(Smart GlassおよびWeb UI経由のExpert)の最初のオプションは、直接ピアツーピア接続です。このオプションは HOST と呼ばれます。
次のオプションは、クライアント間のネットワーク アドレス変換 (NAT) を使用してピアツーピア接続を確立することです。このオプションは REFLEXIVE と呼ばれます。これは、STUNサーバが、異なるローカルネットワーク間のピアツーピア通信を可能にするクライアントのパブリックIPとポートを見つけようとすることを意味します。
最後のオプションは、ビデオストリームとオーディオストリームをリレーするTURNサーバを使用することです。このオプションは RELAY と呼ばれます。
HOSTまたはREFLEXIVEオプションが使用可能な場合、ビデオストリームとオーディオストリームはピアツーピア(エンドツーエンドの暗号化)であり、3つのオプションのさまざまな候補を収集するためのSTUN/TURNサーバとの通信は非常に限られているはずです。
最初の 2 つのオプションのいずれも使用できない場合(対称 NAT、ファイアウォール、またはその他の問題により)、クライアントは TURN サーバ経由のリレー通信を使用します(エンドツーエンドの暗号化が引き続き行われます)。
電話会議の場合、各クライアントは他のクライアントではなく SFU と通信します。その後、SFU は、通話中の他のすべてのクライアントにストリームを送信します。通常の 1 対 1 の通話と同様に、SFU への通信オプションは HOST、REFLEXIVE、または RELAYED であり、各クライアントと SFU 間のビデオおよびオーディオ ストリームはエンドツーエンドで暗号化されます。つまり、SFU は受信ストリームを復号化し、新しい暗号化されたストリームをクライアントに送信します。したがって、クライアント間の暗号化はエンドツーエンドではなく、ホップバイホップです。
上記のルールでは、NATがエンドポイントに依存しないマッピング(できればアドレス依存フィルタリングまたはエンドポイントに依存しないフィルタリング)を行うように設定されている場合、クライアント(Web UI経由のスマートグラスおよびエキスパート)が送信トラフィックと応答を返すトラフィックを持つことを許可する必要があります。
以下のセクションで説明するすべてのルールを実装できない場合(ITポリシーなど)、WebRTCはインタラクティブ接続の確立(ICE)セクションで説明されているように、可能な限り最適なオプションを自動的に選択します。
| ホスト/IP | タイプ | プロトコル |ポート |TCP/UDP | |-----------------------------------|--------------------|-------------|------|---------| |frontlineworker.com/[ドメイン] |アプリケーションサーバ | HTTPS/WSS の| 443 | TCP |
インバウンドおよびアウトバウンドUDPトラフィックを許可する必要があります。ポート範囲は、Web ブラウザーのグループ ポリシーを使用して構成できます。
| 趣旨 | 宛先 IP |プロトコル | ポート| |------------------------|--------------------|----------|---------------| |WebRTCピア接続 | リモートピアの IP | UDP | 1025 から 65535 |
TeamViewerは、xAssistユーザーを地域に最適なSTUN/TURNサーバーに自動的に割り当てる負荷分散メカニズムを含む、分散型STUN/TURNサーバーのグローバルネットワークを提供します。
|地域|IP 範囲 |趣旨| 宛先 IP |プロトコル| ポート| |------|------------------|-------|-----------------------------------------|--------|------------------| |グローバル|* |ターン | turn.svc.frontlineworker.com | TCP |8080 | |グローバル|* | スタン| turn.svc.frontlineworker.com | UDP |8080, 40000-45000 | |EU | 20.54.230.192/29 |ターン | eu-{0..10}.turn.svc.frontlineworker.com | TCP |8080 | |EU | 20.54.230.192/29 |STUN | eu-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 | |米国 | 20.84.226.80/29 |ターン | us-{0..10}.turn.svc.frontlineworker.com | TCP |8080 | |米国 | 20.84.226.80/29 |STUN | us-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 | |SA | 20.201.68.120/29 |ターン | sa-{0..10}.turn.svc.frontlineworker.com | TCP |8080 | |SA | 20.201.68.120/29 |STUN | sa-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 | |JP | 20.210.56.40/29 |ターン | jp-{0..10}.turn.svc.frontlineworker.com | TCP |8080 | |JP | 20.210.56.40/29 |STUN | jp-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 | |で| 52.140.81.48/29 |TURN | in-{0..10}.turn.svc.frontlineworker.com | TCP |8080 | |で| 52.140.81.48/29 |STUN | in-{0..10}.turn.svc.frontlineworker.com | UDP |8080、40000-45000 |
*リージョン/DNSにより、以下のいずれかを解決する
手記: webrtc.svc.frontlineworker.com への HTTPS/TCP 443 アクセスは、TURN サーバ クレデンシャルを取得するためにも必要です。
TeamViewerは、地域に基づいてxAssistユーザーに最適なSFUを自動的に割り当てる負荷分散メカニズムを含む、分散SFUのグローバルネットワークを提供します。
電話会議を有効にするには、シグナリングのために HTTPS / TCP 443 経由で webrtc.svc.frontlineworker.com 到達可能である必要があります。
|地域| IP 範囲 | ホスト| タイプ |プロトコル | ポート|TCP/UDP| |------|----------------|--------------------------------------|---------------------------------|---------|-----------|-------| |グローバル|* |webrtc.svc.frontlineworker.com |マルチコール ゲートウェイ シグナリング |HTTPS/WSS|443 |TCP | |EU |20.54.230.192/29|eu-webrtc.svc.frontlineworker.com |マルチコール ゲートウェイ シグナリング |HTTPS/WSS|443 |TCP | |EU |20.54.230.192/29|eu-{0..10}.sfu.svc.frontlineworker.com|マルチコール ゲートウェイ ビデオ/オーディオ/RTP | RTP |40000-45000|UDP | |米国 |20.84.226.80/29 |us-webrtc.svc.frontlineworker.com |マルチコール ゲートウェイ シグナリング |HTTPS/WSS|443 |TCP | |US |20.84.226.80/29 |us-{0..10}.sfu.svc.frontlineworker.com|マルチコール ゲートウェイ ビデオ/オーディオ/RTP | RTP |40000-45000|UDP | |SA |20.201.68.120/29|sa-webrtc.svc.frontlineworker.com |マルチコール ゲートウェイ シグナリング |HTTPS/WSS|443 |TCP | |SA |20.201.68.120/29|sa-{0..10}.sfu.svc.frontlineworker.com|マルチコール ゲートウェイ ビデオ/オーディオ/RTP | RTP |40000-45000|UDP | |JP |20.210.56.40/29 |jp-webrtc.svc.frontlineworker.com |マルチコール ゲートウェイ シグナリング |HTTPS/WSS|443 |TCP | |JP |20.210.56.40/29 |jp-{0..10}.sfu.svc.frontlineworker.com|マルチコール ゲートウェイ ビデオ/オーディオ/RTP | RTP |40000-45000|UDP | |IN |52.140.81.48/29 |in-webrtc.svc.frontlineworker.com |マルチコール ゲートウェイ シグナリング |HTTPS/WSS|443 |TCP | |IN |52.140.81.48/29 |in-{0..10}.sfu.svc.frontlineworker.com|マルチコール ゲートウェイ ビデオ/オーディオ/RTP | RTP |40000-45000|UDP の|
*リージョン/DNSにより、以下のいずれかを解決する
手記: webrtc.svc.frontlineworker.com への HTTPS/TCP 443 アクセスは、SFU に対する認証にも必要です。
基盤となるWebRTCフレームワークは、すべての接続でDTLSとSRTPを強制するため、ビデオとオーディオはエンドツーエンドで暗号化されます。
Turn を使用しても、パケットは受信者によってのみ復号化され、Turn サーバーによって復号化されることはありません。
ピアから SFU への DTLS/SRTP を使用したエンドツーエンドの強制暗号化。SFU は、メディアを復号化して再暗号化し、受信者に送信します。ピアのメディアが永続ストレージに保存されることはありません。
使用される暗号スイートは TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 です。