RTCPeerConnection media stream working in firefox but not chrome

Trying to keep things as simple as possible, I create a media stream in a chrome extension like this:

var pc = new RTCPeerConnection(null);
chrome.desktopCapture.chooseDesktopMedia(['screen', 'window'], null, function(streamId) {
    var constraints = {
        audio: false,
        video: {
            mandatory: {
                chromeMediaSource: 'desktop',
                chromeMediaSourceId: streamId
            }
        }
    },
    success = function(stream) {
        pc.addStream(stream);
        pc.createOffer(function(offer) {
            pc.setLocalDescription(offer, function() {
                send('make_offer', name, offer);
            }, printError);
        }, printError);
    };
    getUserMedia(constraints, success, printError);
});

      

        
        
        
      

    

Currently my suggestion is received by a peer on a page in a browser. It looks like this (m is the message object with the offer):

var pc = new RTCPeerConnection(null);
pc.onaddstream = function(e) {
    var video = document.getElementById('video');
    video.src = URL.createObjectURL(e.stream);
};
pc.setRemoteDescription(new RTCSessionDescription(m.value), function() {
    pc.createAnswer(function(answer) {
        pc.setLocalDescription(answer, function() {
            send('make_answer', m.from, answer);
        }, printError);
    }, printError);
}, printError);

      

        
        
        
      

    

I have done this with and without ice servers, which looks like this when I use them:

var iceServers = {
    iceServers: [
        {url: 'stun:stun.l.google.com:19302'}
    ]
};

      

        
        
        
      

    

The peer currently receives and displays the stream in Firefox. Absolutely no problem. But it doesn't work in Chrome. Here is some sampled data from chrome: // webrtc-internals: firefox connection:

"ssrc_3309930214_send-transportId": {
 "startTime": "2014-09-30T01:41:11.525Z",
 "endTime": "2014-09-30T01:41:21.606Z",
 "values": "[\"Channel-video-1\",\"Channel-video-1\",\"Channel-video-1\"]"
},
"ssrc_3309930214_send-packetsLost": {
 "startTime": "2014-09-30T01:41:11.525Z",
 "endTime": "2014-09-30T01:41:21.606Z",
 "values": "[0,0,0,0,0,0,0]"
},

      

        
        
        
      

    

compound with chrome:

"ssrc_1684026093_send-transportId": {
 "startTime": "2014-09-30T01:41:57.310Z",
 "endTime": "2014-09-30T01:42:00.313Z",
 "values": "[\"Channel-audio-1\",\"Channel-audio-1\",\"Channel-audio-1\",\"Channel-audio-1\"]"
},
"ssrc_1684026093_send-packetsLost": {
 "startTime": "2014-09-30T01:41:57.310Z",
 "endTime": "2014-09-30T01:42:00.313Z",
 "values": "[-1,-1,-1,-1]"  // what is causing this??
},

      

        
        
        
      

    

Those seem important, but I'm not sure exactly about the implications. I have more data, but I don't know exactly what is important. The basic idea is that the data is propagated to firefox but not chrome, although no exceptions are being observed, which is what I see. Another suspicious piece of data comes up if I load a peer page in Chrome Canary (the last one):

Failed to load resource: net::ERR_CACHE_MISS

      

        
        
        
      

    

This is a console error and I don't know where it comes from. This happens after the response is sent from the partner back to the host (chrome extension).

Signaling done on wss: // testpoint is hosted at https: // I'm not sure where to go from here.

Update. Based on the answer and comment, I added a handler for the onicecandidate:

pc.onicecandidate = function(e) {
    console.log('This is the ice candidate.');
    console.log(e);
    if(!e.candidate) return console.warn('no candidate!');
    send('got_ice_candidate', name, e.candidate);
};

      

        
        
        
      

    

I also set up an equivalent peer-to-peer connection from browser to browser using the video:

var constraints = {
    audio: false,
    video: true
};
getUserMedia(constraints, success, printError);

      

        
        
        
      

    

This works great both from Firefox to Chrome and vice versa, so the problem might be Chrome specific ... There is a difference in how the ice is collected between the successful case and the extension case:

• There is no ice at all between browsers. There is one event, and e.candidate null
  
  .
• There are many events from extension to browser onicecandidate
  
  . They don't all agree. So maybe the chrome extension is obfuscating the STUN server? I dont know.

Thanks for your answers, I would like to know more what you have.