RTCPeerConnection は、信号を交換するために選択されたトランスポート メカニズム (Websocket、Google チャネルなど) を気にしないことを読みました。リモートの必要性を完全にバイパスするために、これらの信号を収集し、JSON でエンコードし、外部メカニズム (チャット、電子メールなど) を使用して他のピアに送信するようにユーザーに依頼することは可能だと思いますか?サーバ？
少し POC を実行しましたが、これは両方のピアが同じマシン上にある場合にのみ機能するようです。どんな手掛かり？
ありがとう！
はい。各クライアントが他のクライアントの SDP (ICE 候補を含む) を受信する限り、PeerConnection. WebRTC は、アプリケーション開発者が採用するシグナリング メカニズムから分離されています。ただし、これらの信号を送信することは必須です。これにより、各クライアントは、どの IP ポートの組み合わせに注意を払う必要があるかを認識できます。
これらのシグナルを手動で交換して処理するようにユーザーに要求するのは、面倒な作業になる可能性があります。簡単にシグナルを中継できるSocket.ioを使用してシンプルなサーバーをセットアップすることをお勧めします。いつでも AJAX ポーリングも使用できます。
はい、メールまたはその他のトランスポートで送信できます。ユーザーにとって最良の結果が得られるとは思いませんが、それを行うための 1 つの方法です。
SDP オファーを受け取ったユーザーは、それをブラウザーに入力し、SDP 回答を取得して、要求を開始したユーザーに返信する必要があることを説明します。しかし、それがローカルで機能すると言うとき、あなたはそれをすべてやっていると思います。
ピアが接続できるようにするには、オファーと回答を 1 回だけ送信するため、ICE 候補も待機する必要があります。
いいえ-私が理解しているように、セッションの説明を単純に電子メールで送信することはできません。
ICEはピア間の最適なルートを確立します。ICE候補の数は、両方のクライアントの現在のネットワーク状況によって異なる可能性があると思います。
氷の候補とセッションの説明を受け取った後、クライアントが物理的な場所を移動すると（たとえば、別のWi-Fiネットワークに参加すると）、氷の候補が役に立たなくなります。つまり、クライアントは接続できなくなります。
私は専門家ではないので、簡単に間違っている可能性があります。その答えは、webrtcを使用して2つのクライアント用に独自のシグナリングシステムをセットアップする際に得たwebrtcの知識からのものです...
免責事項: 私はプッシャーで働いています。
はい、どんな輸送手段でも送ることができます。ただし、ほとんどのブラウザがサポートしているため、最近では websockets が非常に適しています。
@Vishnu で言及されているように、socket.io サーバーをセットアップできます。または、面倒なセットアップをしたくない場合は、 Pubnub やPusherなどのホストされたソリューションを使用できます。プッシャーを使用してwebRTC シグナリングのチュートリアルを作成したので、興味がある場合は Webosckets (+フォールバック) を作成しました。