技術的な説明は以下のリンクから

下記のサイトには正しい事がシンプルに記載されてます。

https://www.tramsystem.jp/voice/voice-2844/

しかし、WebRTCの本質ではなく、ブラウザのみで今可能とされる事の認識です。

Docokame (どこカメ)はその根本から認識を再定義します。

 

上記サイトからの引用と解説。

 

WebRTCのメリット

 

1.機材の購入が不要

WebRTCを利用するにあたり、新しい機器などを購入する必要はありません。

最低限パソコンかスマホがあれば利用することが可能です。WebRTCは既存のインターネットの技術を組み合わせて開発された技術であるため、新たなハード機器を買う必要がないのです。

 

全くその通りです

 

2.アプリケーションのインストールが不要

新しい機器を買う必要もなければ、新しいアプリケーションをインストールする必要もありません。

 

WebRTCは技術的仕様でも記載した”Real-time Communication Between Browsers”にあるように、ブラウザの中で完結できる技術です。主要ブラウザであるChrome、Firefox、Safari、Edgeでも問題なく動くようになっています。

 

全くその通りです。 しかし、実装の良し悪しははっきりとあります。

 

3.通信がとても軽い

通信がとても軽いこともWebRTCの特徴です。これはサーバーを介さずにデータ通信ができることで実現されています。

 

一般的な一方向通信は「TCPプロトコル」を採用しています。このプロトコルではサーバーを介したデータ通信であり、クライアントからサーバーに接続を開始してから相手が受け取ったかを確認するまでが一連の流れになります。この一連の流れを何度も行うことでデータの通信を行います。

 

 

一方、WebRTCは「UDPプロトコル」を採用しています。TCPプロトコルとは違い即座にデータ送り、そのデータは送りっぱなしとなります。通信の開始や終了の処理がない分、通信が速くなるということです。

 

ここは、訂正が必要です。 WebRTCトランスポート・プロトコルはプロトコルは規定していません。

UDPでもTCPでも利用可能です。

具体的にDocokameで実装してるWebRTCプレイヤー

<div id="container" align="center">  

     Docokame Server WebRTC player<br><br>This player plays live near real time audio/video on any OS and mobile device, in all major browsers. This is original H264 video encoded by IP camera; server doesn't do any transcoding.

    <br>

    <A style="COLOR: darkgreen;" href="demohtml5WebRTCplayerSecure.html">Same page with signaling over secure WebSocket</A>

    <br><br>

    <video style="background-color:black" id="remoteVideo" width="800" height="450" autoplay playsinline controls muted></video>

    <script type="text/javascript">

//パラメータ

        //1.video要素のID

        //2. ライブ放送のエイリアス。対応するビデオエンコーディング。H264(AVC1), VP8, VP9; 音声エンコーディングのサポート: opus, G.711(PCMA/PCMU).

        //3. セッションベースの認証用セキュアトークンです。メディアサーバーとウェブサーバーが別のドメインで動作している場合は使用しないでください。

        //4. DocokameサーバーのIPアドレス。ドメイン名を指定した場合(ドメイン名は安全なウェブソケットでのシグナリングに使用する必要があります)、およびサーバーがNATの後ろにある場合は、ドメイン名とNATの背後にあるサーバー-javascriptファイルの修正で説明されているDocokamewebrtcplayer.jsを変更する必要があります。

        //5. ウェブソケットを介したシグナル伝達のためのDocokameサーバーのメインポート(デフォルトでは、安全でないウェブソケットの場合は5119、安全なウェブソケットの場合は443)。ファイアウォールでこれらのポートが開いていることを確認してください。

        //6. 安全なウェブソケットを使用する: trueの場合、ポートを安全なポート(デフォルトでは443)に設定し、Docokame ServerでSSL証明書を設定してください。このパラメータがfalseの場合、このウェブページがhttps:// で読み込まれると、ブラウザに「混合コンテンツ」の警告が表示されます。

        //7.実際のWebRTC ICE接続に単一のセントラルポートを使用する。trueにすると、WebRTC接続専用のDocokame Serverの定義済みの単一ポート(デフォルトでは5135)から、Webブラウザがストリーミングメディアを受信します。trueの場合、ファイアウォール/NATルーターでDocokame Server用のポート5135を開くだけで済みます(シグナリングポートの5119や443と一緒に)。falseの場合、WebRTC接続はランダムなポートで行われます。ファイアウォールですべてのポートを開くか、ファイアウォールでDocokame Serverを許可アプリとして追加する必要があります。

        //8. WebRTCのトランスポートプロトコル。udp "または "tcp "に設定します。中央のポートは、udpとtcpの両方に使用できます。

        webrtcPlayer = new DocokameWebRTCPlayer("remoteVideo", "livedemocam", "", "aws2.docokame.biz", "80", false, true, "tcp");

        //Comment out next line not to start playing when webpage loads. Then user will need to click on Play button to play; you may want to use a video element with overlayed Play button - check out our SDK for sample webpages.

        webrtcPlayer.Play();    //Start playing automatically when webpage loads. Notice that video element has a "muted" attribute; this is video-only stream anyway. A muted attribute helps to overcome Chrome's autoplay policy, and is not always needed, as described in http://www.umediaserver.net/phpBB3/viewtopic.php?f=29&t=3578

    </script>

  </div>

 

WebRTCのデメリット

 

たくさんのメリットを持っているWebRTCですが、場面によっては一方向通信の方が適している場面もあります。どのような場面にWebRTCを利用した方が良いのかを理解するためには、WebRTCのデメリットも理解しておきましょう。

 

ここも、基本は正しいのですが、以下を読んでいただくとデメリットは無くなります。

 

1.セキュリティ

WebRTCは、プロトコルにUDPを採用しています。これにより通信の軽さを実現している反面、セキュリティ面で信頼性が低下してしまうことに繋がります。

上述した通り、TCPはクライアントからサーバーに接続を開始してから、相手が受け取ったかを確認するまでが一連の流れです。つまり、相手がデータを受け取ったかを都度確認することができることで、到達性を担保しています。

一方、データを送りっぱなしとするUDPは、相手が本当にデータを受け取ったかを確認することができず、その分の信頼性が低下してしまうということです。

 

ここは、訂正が必要です。 UDPだから信頼性が低いは一見正しいようですが、本質的には何の関係性もありません。 WebRTCはSSLで暗号化して通信します。 また、先ほど説明済みですがTCPも使えます。

 

2.接続人数の限界

接続人数に限界があることもデメリットの一つです。

例えば、何かのライブ配信にWebRTCを利用しようとした時、配信側は視聴側の分まで変換を行う必要があります。つまり、視聴者が増えれば増えるほど配信側の負担が増えていきます。

負担が増えればサーバーダウンなどの問題にも繋がることを考えると、ビジネスで大人数でのWebRTCの利用は現実的ではありません。

 

訂正が必要です。 WebRTCはピアツーピアだけしか利用できないという実装ではありません。 クライアントサーバーもサポート可能です。

DocokameはWebRTCをクライアントサーバーで実装してまいす。つまり、クライアントの負荷変動は一切発生しません。

 

3.回線の問題点

回線の問題点もあります。この問題の解説については、まずNAT(Network Address Translation)について解説しましょう。

パソコンは、他のパソコンと識別するためにIPアドレスと呼ばれるアドレスが振り分けられており、このIPアドレスには”グローバルIPアドレス”と”プライベートIPアドレス”があります。

グローバルIPアドレスは、全世界に通用するIPアドレスで、プライベートIPアドレスはあるネットワーク環境の中でしか通用しないという違いがあります。

つまり、あるネットワーク環境から他のネットワーク環境にデータを送るときには、プライベートIPアドレスからグローバルIPアドレスに変換して、受け取った側でまたプライベートIPアドレスに変換する必要があります。そしてこのIPアドレスの変換作業のことを、NATと呼んでいます。

WebRTCのデメリットは、複雑なネットワーク環境によってNATが困難であることです。中継としてサーバーを設置する、といった対策を取ることも出来ますが、そうするとWebRTCのメリットである通信の軽さが失われてしまうという本末転倒な事態となります。

 

訂正が必要です。 WebRTCはピアツーピアだけしか利用できないという、実装ではありません。 クライアントサーバーもサポート可能です。

DocokameはWebRTCをクライアントサーバーで実装してます。つまり、NATの問題は簡単に回避可能です。