Re: [webrtc-pc] Intended outcome when modifying direction in have-local-offer (#2751)

That matches what I see. I've got two js fiddles to help experimenting with:


The behaviour can be reproduced by pasting the following into the sender's console after starting the session(by exchanging the initial offers/answers):

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

let sender = Object.values(mediaStream.senders)[0];

const trans = pc.getTransceivers()[0];
console.dir({ trans, direction: trans.direction, currentDirection: trans.currentDirection });

dc.send(JSON.stringify({ type: 'offer', sdp: offer.sdp }))

It's clear that it does trigger a negotiationneeded event and in the subsequent offer the transceiver is `recvonly`. However, this is observed behaviour in Chrome, not what I would expect from the specification.

Based on the specification I would expect:

1. `removeTrack` causes the transceiver's direction to become `recvonly`
1. When applying the remote offer from the peer the transceiver's direction should change back to `sendonly` or `sendrecv` from `recvonly`.
1. When checking if negotiation is needed we would find that the transceiver's direction matches that of the remote description and no negotiation would be requested.

GitHub Notification of comment by k0nserv
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 11 July 2022 16:52:25 UTC