Chrome WebRTC over TCP

Question

私は間にゲートウェイを使用してTCP経由でWebRTCメディアを作成しようとしていますが、ICE接続フェーズで興味深い問題があります。さらに進歩を遂げる前に、私はUDPの設定が同じで、すべてが正しく動作することを知っておくことが重要です。

a=candidate:1 1 tcp 1 <gw_ip> <gw_port> typ host tcptype passive generation 0 

はまた、私はパッシブとしての属性の設定を送信している：我々は、単一のTCP候補を（メディアポートは、同じポートを含むように修正された）を含むように、リモートアンサーSDPを変更するゲートウェイで

：

a=setup:passive 

秒Chromeでのリモート記述を適用した後、私は私がバインド成功応答で答えてるゲートウェイ（私はトランザクションIDとメッセージ整合性の両方をチェックした上でSTUN BIND要求を受けたことだし、彼らはうまくいくようです）。

このクロムの後では、ICEチェック（DTLSメッセージではありません）を続行しません。私は外観を撮影した「共有ソケット上でSTUNバインディング応答メッセージを無視する」

を

：私はいくつかのエラーが起こっていたかどうかを確認するためにクロムのログを有効にしていると私は、興味深い出力を見つけましたクロムソースコードでは、これは表示されているようですが、クロムは共有ソケットを使用していますが、理由はわかりません。

アイデア？ありがとう！

Answer 1

深い調査の結果、TCPストリームがゲートウェイ側で正しく解析されていないことがわかりました。

このストリームは、インバウンド/アウトバウンドデータに適用されていない長さのフレーミングメカニズムを使用するため、プロセスパイプラインでいくつかの問題が発生します。

フレーミングメカニズムの詳細についてはrfc5389を参照してください： https://tools.ietf.org/html/rfc5389