The browser used is Chrome... I have the caller and receiver code to generate SDP and ICE candidates. I get the caller code to generate proper SDP and ICE candidates with sd
(It sounds from comments that you're caching ICE candidates. Don't do that. I also suspect timing issues may be behind loss of some candidates.)
The whole point of Trickle ICE is to trickle candidates, that is, send candidates as soon as they become available.
With WebRTC, your app is responsible for signaling between peers, which is time-sensitive. So:
pc.localDescription no later than in the setLocalDescription success callback.pc.onicecandidate to start firing immediately after that callback. Send them.This is true on both sides (for offer and answer). What you want to see on the wire is:
offer, candidate, candidate, candidate
and the other way:
answer, candidate, candidate, candidate
What not to do:
setRemoteDescription when an offer comes in on the receiving end for any reason, or it wont be ready to receive candidates.Update 2:
Your sdp says a=recvonly and not a=sendrecv, which means the receiver is resigned to receive only, without send anything in return. One of two things can cause this:
offerToReceiveVideo:false and/or offerToReceiveAudio:false.pc.addStream in time for (before) pc.setLocalDescription.The second can happen if there's a race between getUserMedia and receiving an offer.
Update 3:
If all else fails, compare to working code. I've shared a cross-tab demo before in other answers, but it only sent video, didn't receive any.
Here's a modified version of that demo that only receives video from the remote camera instead. As usual, open it in two tabs in the same browser.
Note that in Firefox, after you hit Call, you have to physically focus the other tab before it allows access to the camera.