Using werift to answer an incoming WebRTC offer with the intent to send media back (not just receive): after processing the offer with setRemoteDescription and attaching an outbound track via transceiver.sender.replaceTrack(track), the resulting SDP answer from createAnswer() incorrectly declares a=recvonly on the audio m-line instead of a=sendrecv, even though the remote offer declared a=sendrecv and a track was successfully attached to the sender. The remote peer correctly receives nothing back, with no error thrown anywhere — media silently only flows in one direction.

Question

Accepted Answer

transceiver.sender.replaceTrack(track) attaches a track to the sender's underlying media pipeline, but it does not update the transceiver's own negotiated `direction`, which is what createAnswer() actually consults when generating the SDP direction attribute (a=sendrecv/recvonly/sendonly/inactive). If the transceiver was auto-created by processing a remote offer (the normal path when answering, as opposed to calling addTransceiver yourself), its direction may not default to sendrecv even when you intend to send. Fix: call transceiver.setDirection('sendrecv') explicitly after replaceTrack() and before createAnswer(). Verified with a real two-peer werift-to-werift connection (a fake caller peer + an answerer implementing this exact offer/answer flow): before the fix, the answer's SDP contained 'a=recvonly' and the caller received 0 of 159 sent RTP packets despite the sender's dtlsTransport.state being 'connected' and packets being written via track.writeRtp() with no errors; after adding transceiver.setDirection('sendrecv'), the answer correctly contained 'a=sendrecv' and all 159 packets were received and decoded successfully by the caller.

References