When Firefox calles Chrome i get: DOMException: Error processing ICE candidate
Reported by
bogdanos...@gmail.com,
Aug 29
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Caller side (alice) is google chrome browser ( creates offer with audio constraint set to true) 2. Callee side (bob) is firefox browser (waiting for caller to send offer to create answer, audio constraint set to true) What is the expected behavior? WebRTC offer/answer & ice candidate exchange should happen between two browser and flow of media starts. What went wrong? During the ice gathering stage of the WebRTC exchange. Google Chrome generates local ice candidates normaly, only when it starts receiving remote candidates to be added the " DOMException: Error processing ICE candidate " occurs on the google chrome browser. It only receives one remote candidate from Firefox and others throw the DOMException error. Did this work before? No Does this work in other browsers? N/A Chrome version: 68.0.3440.106 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: When the roles are reversed the exchange goes on without a problem. No error is thrown. Note: Tested on local machine.
,
Aug 29
you seem to be missing a setRemoteDescription call before calling addIceCandidate. Throwing an error is appropriate in that case is expected. Now why setRemoteDescription is not called is another question.
,
Aug 29
,
Aug 30
Thanks for responding and noticing that setRemoteDescription is missing. I have tested the scenario in different examples:
1. Chrome calling Chrome
2. Firefox calling Chrome
3. Chrome calling Firefox
And only in the example when Chrome calls Firefox setRemoteDescription isn't fired, in all other examples remoteDescription is set. I see with console logs that Firefox doesn't set localDescription, so it sends null to Chrome.
So I looked into the code and it looks like the problem was that Firefox didn't return the right value when pc.createAnswer was called.
The code that was causing the problem was:
this.pc.createAnswer(answerParams)
.then( answer => {
if (hold) {
this.pc.setLocalDescription(this.sdp.inactive(answer));
} else {
this.pc.setLocalDescription(answer);
}
console.warn(`${answer.type}\n ${answer.sdp}`);
})
The new code that made it work is:
this.pc.createAnswer(answerParams)
.then( answer => {
console.warn(`${answer.type}\n ${answer.sdp}`);
if (hold) {
return this.pc.setLocalDescription(this.sdp.inactive(answer));
} else {
return this.pc.setLocalDescription(answer);
}
})
,
Aug 31
hbos@: Can you take a look? From the discussion it looks like this is not a bug. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by bogdanos...@gmail.com
, Aug 29