I'm working on a webRTC solution where only one peer sends video, and the other one just listens. So far, I've managed to do so by calling getUserMedia() but not attaching any tracks to the connection, but the browser asks for permission anyway which is misleading, as in fact no tracks from offering side are added to connection.
As offerToReceive* options are now deprecated, docs say that the preferred way to achieve this is using transmitters.
I've tried creating an offer on receiving side, adding the transceiver:
con.addTransceiver('video', { direction: 'recvonly' })
and on answering side,
const transceivers = con.getTransceivers()
stream.getVideoTracks().forEach((track, i) => {
transceivers[i].sender.replaceTrack(track)
})
but then I get an exception on the offering side
Failed to execute 'setLocalDescription' on 'RTCPeerConnection': Failed to set local offer sdp: The order of m-lines in subsequent offer doesn't match order from previous offer/answer.
which is true, because somehow the second offer has different m=video section IDs, and answering side throws a 701 STUN server address is incompatible..
How do I achieve one-way video calls?
OK looks like I've managed to get it working without the client calling getUserMedia.
I guess the problem lays somewhere in the process of renegotiations, since I tried to stick to the "client always offers, server always answers" schema.
Having thoroughly read the MDN, I've got rid of explicit calls to createOffer and createAnswer and let the browser decide.
More on this on MDN: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setLocalDescription https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setRemoteDescription