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

k0nserv has just created a new issue for https://github.com/w3c/webrtc-pc:

== Intended outcome when modifying direction in have-local-offer ==
Hello,

I'm trying to understand something about local modifications during `have-local-offer`.

**Scenario:** A transceiver is created with a sending track, its direction defaults to `sendrecv`. There has been at least one negotiation and `currentDirection` is `sendonly`

**Events:**

1. A negotiation is started for some other reason
2. An offer is created with `createOffer`
3. The offer is applied as the local description
4. The existing track is removed with `removeTrack` this causes `direction` to change to `recvonly`.
5. An answer is received from the remote peer and applied as the remote description.

At this point what should the direction of the transceiver in question be: `recvonly`, `sendonly`, or `sendrecv`? 

By my reading of the specification it should be `sendrecv` if the remote peer answers with `sendrecv` or `sendonly` if the remote peer answered with `recvonly`. The reason for this is that when applying the remote answer the specification says to update both `transceiver.[[currentDirection]]` and `transceiver.[[direction]]` to the reversed value from the peer per step 4.5.9.2.13.2 of ["set a session description"](https://www.w3.org/TR/webrtc/#set-description) instructions.

It should be noted that libWebrtc doesn't do this, it leaves `transceiver.[[direction]]` untouched and only updates `transceiver.[[currentDirection]]`

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2751 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 15:22:39 UTC