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:

* https://jsfiddle.net/wz51bker/1/(Sender)
* https://jsfiddle.net/qLrudx2k/1/(Receiver)

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

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

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

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 https://github.com/w3c/webrtc-pc/issues/2751#issuecomment-1180642015 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

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