javascriptwebrtcsdppeer-connectionrtcpeerconnection

How to set remote description for a WebRTC caller in Chrome without errors?


I hope there is no flaw in the logic.

Step 1: caller creates offer

Step 2: caller sets localDescription

Step 3: caller sends the description to the callee

//------------------------------------------------------//

Step 4: callee receives the offer sets remote description

Step 5: callee creates answer

Step 6: callee sets local description

Step 7: callee send the description to caller

//------------------------------------------------------//

Step 8: caller receives the answer and sets remote description

And here is the code for the above

const socket = io();
const constraints = {
  audio: true,
  video: true
};
const configuration = {
  iceServers: [{
    "url": "stun:23.21.150.121"
  }, {
    "url": "stun:stun.l.google.com:19302"
  }]
};

const selfView = $('#selfView')[0];
const remoteView = $('#remoteView')[0];

var pc = new RTCPeerConnection(configuration);

pc.onicecandidate = ({
  candidate
}) => {
  socket.emit('message', {
    to: $('#remote').val(),
    candidate: candidate
  });
};

pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    socket.emit('message', {
      to: $('#remote').val(),
      desc: pc.localDescription
    });
  } catch (err) {
    console.error(err);
  }
};

pc.ontrack = (event) => {
  // don't set srcObject again if it is already set.
  if (remoteView.srcObject) return;
  remoteView.srcObject = event.streams[0];
};

socket.on('message', async ({
  from,
  desc,
  candidate
}) => {
  $('#remote').val(from);
  try {
    if (desc) {
      // if we get an offer, we need to reply with an answer
      if (desc.type === 'offer') {
        await pc.setRemoteDescription(desc);
        const stream = await navigator.mediaDevices.getUserMedia(constraints);
        stream.getTracks().forEach((track) => pc.addTrack(track, stream));
        selfView.srcObject = stream;
        await pc.setLocalDescription(await pc.createAnswer());
        console.log(pc.localDescription);
        socket.emit({
          to: from,
          desc: pc.localDescription
        });
      } else if (desc.type === 'answer') {
        await pc.setRemoteDescription(desc).catch(err => console.log(err));
      } else {
        console.log('Unsupported SDP type.');
      }
    } else if (candidate) {
      await pc.addIceCandidate(new RTCIceCandidate(candidate)).catch(err => console.log(err));
    }
  } catch (err) {
    console.error(err);
  }
});


async function start() {
  try {
    // get local stream, show it in self-view and add it to be sent
    const stream = await requestUserMedia(constraints);
    stream.getTracks().forEach((track) => pc.addTrack(track, stream));
    attachMediaStream(selfView, stream);
  } catch (err) {
    console.error(err);
  }
}

socket.on('id', (data) => {
  $('#myid').text(data.id);
});


// this function is called once the caller hits connect after inserting the unique id of the callee
async function connect() {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    socket.emit('message', {
      to: $('#remote').val(),
      desc: pc.localDescription
    });
  } catch (err) {
    console.error(err);
  }
}

socket.on('error', data => {
  console.log(data);
});

Now this code throws an error while executing Step 8

DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote offer sdp: Called in wrong state: kHaveLocalOffer

DOMException: Failed to execute 'addIceCandidate' on 'RTCPeerConnection': Error processing ICE candidate

Tried to debug but didn't find any flaw in the logic or code. Noticed one weird thing that the the pc object has localDescription and currentLocalDescription and i think the callee who creates the answer must have both the description type to be answer but instead shows the localDescription to be offer and currentLocalDescription type is answer.

enter image description here I have no idea if it is supposed to behave like that or not as I am begginer.

Thanks in advance.


Solution

  • Your code is correct. This is a long-standing bug in Chrome with negotiationneeded.

    I've instrumented it in a fiddle (right-click and open in TWO adjacent windows, then click call in one).

    In Firefox, it works. The offerer negotiates once because you add two tracks (video/audio) at once:

    negotiating in stable
    onmessage answer
    

    and, on the answerer side, the tracks you add outside of 'stable' state are added to the answer:

    onmessage offer
    adding audio track
    adding video track
    

    But in Chrome, it's broken, firing negotiationneeded twice on the offerer, once per track added:

    negotiating in stable
    negotiating in stable
    onmessage offer
    DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
      Failed to set remote offer sdp: Called in wrong state: kHaveLocalOffer
    onmessage offer
    DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
      Failed to set remote offer sdp: Called in wrong state: kHaveLocalOffer
    onmessage offer
    DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
      Failed to set remote offer sdp: Called in wrong state: kHaveLocalOffer
    

    and firing negotiationneeded twice on the answerer side, which isn't even in 'stable' state:

    onmessage offer
    adding audio track
    adding video track
    negotiating in have-remote-offer
    negotiating in have-remote-offer
    onmessage offer
    DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
      Failed to set remote offer sdp: Called in wrong state: kHaveLocalOffer
    

    These extra events cause the havoc of reciprocal state errors seen on both ends here.

    To be specific, Chrome violates two parts of the spec here:

    1. "Queue a task" to fire this event. "queueing prevents negotiationneeded from firing prematurely, in the common situation where multiple modifications to connection are being made at once."

    2. If connection's signaling state is not "stable", abort these steps [to fire the event].

    Workaround

    Working around both Chrome bugs requires (using async/await for brevity):

    let negotiating = false;
    pc.onnegotiationneeded = async e => {
      try {
        if (negotiating || pc.signalingState != "stable") return;
        negotiating = true;
        /* Your async/await-using code goes here */
      } finally {
        negotiating = false;
      }
    }