WebRTC never fires onIceCandidate
The above solution of Rob W from Jan 3 '15 worked for me at first but led to another problem.
I included {'offerToReceiveAudio':true,'offerToReceiveVideo':true} in the createOffer and createAnswer calls and onIceCandidate was called as described.
However, if I got it right, offerToReceive... means to only receive but not to send a stream. I figured that out because of the a=recvonly in the sdp offer and the a=sendonly in the sdp answer. As a result, only the caller could see the callees video but not vice versa.
As Rob states correctly:
other ways to get media in the SDP include [...] calling peerConnection.addStream with a media stream that you got from getUserMedia
Adding the stream was what I had done already in the first place. However, my sending of the sdp happened before that adding because my logical flow was mixed up. Bringing that into the right order (addStream -> sdp = getLocalDescription -> send(sdp)) and removing the offerOptions did the trick for me.
Hope this helps anyone.
In Chrome 38 and earlier, OfferToReceiveAudio defaulted to true. Starting from Chrome 39, OfferToReceiveAudio defaults to false, as announced by a WebRTC engineer at PSA: Behavior change to PeerConnection.createOffer constraint OfferToReceiveAudio (quoted below).
Because of this change, the SDP returned by createOffer does not contain any media, and therefore the ICE gathering process never starts. You can notice the consequences of this change by observing that the ICE events are never triggered, and the PeerConnection's iceGatheringState and iceConnectionState stay "new".
To make sure that the ICE gathering starts and complete, you have to add media to your offer, e.g. by setting OfferToReceiveAudio:true in the following constraints to your offer (either as a parameter of the PeerConnection constructor, or as a parameter to the peerConnection.createOffer method):
{
mandatory: {
OfferToReceiveAudio: true
}
}
(other ways to get media in the SDP include setting OfferToReceiveVideo:true, or calling peerConnection.addStream with a media stream that you got from getUserMedia)
webrtc-discuss: PSA: Behavior change to PeerConnection.createOffer constraint OfferToReceiveAudio:
I'm going to submit a change (https://webrtc-codereview.appspot.com/16309004/) to change the behavior of RTCPeerConnection.createOffer. The change is expected to be included in Chrome M39.
What's changed:
Currently if the OfferToReceiveAudio constraint is not specified in PeerConnection.createOffer, the resulted offer SDP will have an "m=audio" line even if there is no audio track attached to the PeerConnection. In other words, OfferToReceiveAudio defaults to true.
After my change, OfferToReceiveAudio no longer defaults to true. Whether the offer SDP has an "m=audio" line depends on if any audio track has been attached to the PeerConnection.
What's not changed:
The behavior of setting an explicit value for OfferToReceiveAudio remains the same, i.e. OfferToReceiveAudio:true will result in an "m=audio" line regardless of the existence of audio tracks; OfferToReceiveAudio:false will result in no "m=audio" line regardless of the existence of audio tracks, unless setLocalDescription has been called with an SDP containing an "m=audio" line, in which case the new offer SDP will mark the audio content inactive instead of removing the audio content.