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
.
I have no idea if it is supposed to behave like that or not as I am begginer.
Thanks in advance.
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:
and, on the answerer side, the tracks you add outside of
'stable'
state are added to the answer:But in Chrome, it's broken, firing
negotiationneeded
twice on the offerer, once per track added:and firing
negotiationneeded
twice on the answerer side, which isn't even in'stable'
state: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:
"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."
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):