本記事は、WebRTCをエンタープライズで利用したいと考えている人（例えば情シスの人）向けに、WebRTCの技術的な内容をいくつかまとめた記事。

エンタープライズ向けWebRTCの外堀が埋まってきている

社内向けなどの施策で、たとえば先進的な技術をつかったコスト削減を狙う担当者はそれなりにいると思う。WebRTCは、そこで目をつけられる技術の1つだ。（典型的なケースでは、既存のWebビデオ会議などのリプレース候補など）

新技術を導入するとなると、当然のことながら観点の1つとしてセキュリティに目がいく。すなわち、社内で「WebRTCは安全に使えるのだろうか？」と考えるということだ。たとえば、「音声・映像のトラフィックが暗号化されていたとしても、インターネットに出るのは怖い」、と偉い人が言うかもしれない。これに対する一定の回答はあるので、本記事前半で紹介する。

また、WebRTC登場初期時は、エンタープライズな環境でのWebRTC導入に向けて、いくつか情シス担当者の頭を悩ますような制約も多かったが、制約を解除してくれるような機能も増え始めている。これについても本記事後半で紹介する。

トラフィックをインターネットに出さないために

最も簡単な方法は、IPレイヤではお互いにプライベートIPで通信できる前提(pingが互いに疎通)で、

  • 何らかのシグナリングサーバを自前で社内ネットワークに構築する
  • WebRTCのアプリケーションを自前で社内ネットワークに構築する
  • STUN/TURNサーバを利用しない
    • 具体的には、RTCPeerConnectionを作成するときに、ICEサーバを設定しなければ良い。(コンストラクタの引数に渡さない)
    • これで、端末が取得できるのは、自身のプライベートIPになる可能性が高い
    • 端末はそのプライベートIPを利用して、UDPでの接続を試みる(失敗した場合は、レイヤ3でIP疎通を確認＆レイヤ4でUDPの疎通を確認。UDPは後述)
    • 仮にSTUN/TURNサーバを利用する場合は、自前で社内ネットワークに構築する

という方法だ。

これによって、外部のサーバにIPを伝えることなく、社内のNW装置のみでトラフィックが流れる。ただし、注意点もあり、仮にどこかで設定を誤っていると、「社内」 ~ 「社外」　でWebRTCの通信を開始した場合、社内の端末はSTUN/TURNサーバを利用していないとしても、社外の端末(特にグローバルIPを持っているような端末)と接続されてしまう可能性がある。これは、WebRTCの内部で利用するプロトコル(ICE)の仕様だ。

STUN/TURNを利用しないのではなく、反対に全てのトラフィックをTURN経由にする方法もある。この場合は通信ログも取れる（ただし、デフォルトでは通信内容が暗号化されているので、中身は簡単には見れない）。社内システムの管理ポリシーによってはこの設定が好まれるかもしれない。

UDPポート範囲を制限する

2016/9頃からChrome M54から導入された機能として、UDPのポートレンジを制限する機能がある。参考。 エンタプライズな社内ネットワークは、必要最低限しかポートを開放しないポリシーも多いため、このポートレンジ制限機能は非常に役立つ。

情シスのネットワーク担当者と連携して開放するポートレンジを最小限に狭めることができる。具体的にはChromeポリシーから規定できる。参考。

認証HTTPプロキシを越えてTURNにつなぐ

WebRTCのトラフィックは、通常のWebアクセスのトラフィックと異なり、UDPを利用する。企業によっては、全てのトラフィックをプロキシ経由にさせるポリシーもあり、特に認証付きプロキシがデプロイされている場合に、WebRTCの利用が難しいケースもあった。

Chromeでもこれまでは対応しておらず、既存Issueだったが最近(2017/2)実装されたので、この認証付きプロキシ経由でTURNへ接続できるようになった。（ただし、全てのトラフィックがプロキシを疎通し、特に重い映像トラフィックが流れる場合は、プロキシの負荷・性能は要確認）

おまけ

ブラウザ入れられない問題

そもそも、Chrome入れられないんじゃ、という話はごもっとも…。

自前構築・運用つらい問題

WebRTCのサーバ群を自前で構築するのは、なかなか茨の道なので注意。特に、エンドユーザが使って通信NGが起きた場合のサポート・切り分けが大変。 この辺りは Build vs Buy Your WebRTC services の記事によくまとまっている。