4

Chrome ブラウザ v30 で自分の webrtc デモ コードを実行する際に問題があります。しかし、コードはFirefoxで完全に機能しています。onececandidate イベントは、オファーが他のピアによって受け入れられる前に発生します。一方、ピア接続は、オファーが受け入れられた後にのみ作成されます。このため、onicecandidate が発火すると、受信側でピア接続 null エラーで終了します。WebRTC と私のコードの流れを理解している限り、
ステップ 1: 発信者が呼び出しボタンを押します
ステップ 2: getUsermedia が呼び出されます
ステップ 3: ピア接続が作成されます
ステップ 4: オファーが発信者に送信されます
ステップ 5: オファーが送信されます
ステップ 6 : ピア接続は、発信者が呼び出しを受け入れた後にのみ作成されます。
ステップ 7 : ピア接続が回答を作成する
ステップ 8 : 回答が発信者に送信される
ステップ 9 : 発信者が icecandidate を着信者に送信する
ステップ 10 : 着信者が icecandidate を発信者に送信する

上記のフローの問題は、呼び出し先側で、ユーザーがオファーを受け入れた後にのみピア接続が作成されることです。しかし、オファーが作成された直後とオファーが受け入れられる前に、発信者側では、アイス候補が発信者に送信されます。呼び出し元側では、null エラーが発生します。

デバッグ ログをペーストビンに貼り付けました:- pastebinDOTcom/gMgaxbBp

この問題の解決策を教えてください。

4

2 に答える 2

7

私は自分でそれを理解しました。問題は、ピア接続のローカルの説明が設定されるとすぐにクロムにあり、氷の収集が開始されます。オファー/アンサーが完了した後にのみ、これらのアイス候補を転送する必要があります。何らかの方法でローカルに保存する必要があります。このコードが firefox で完全に機能する理由は、firefox では icecandidates が収集され、オファー自体に配置されるためです。そのため、icecandidate はオファー/アンサー自体で交換されます。

于 2013-11-21T07:45:05.413 に答える
0

以前に回答者の PeerConnection を作成します。少なくとも Firefox では、ICE 候補の収集を開始し、接続を高速化できます。そして、それはあなたの問題を解決すると思います。

于 2013-11-15T15:20:53.853 に答える