-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing RTCRtpTransceiver direction from recvonly to sendrecv on the answerer side doesn't fire negotiationneeded event #2919
Comments
After negotiation, pc2.transceivers[0] in "description" is "recvonly" (since pc1 has it as "sendonly" and pc2 didn't set it). Then you change it to "sendrecv". pc2.transceivers[0].[[Direction]] is now "sendrecv". The intersection of "sendrecv" and "recvonly" is "recvonly". This does not match transceiver.[[Direction]], which is "sendrecv". Therefore "true" should be returned. Current behavior is correct. (Suggestions for language to make this more obvious are welcome, of course) |
Assuming the following labels:
What is the algorithm when current local description is of type "answer"? I understand this
where "description is described as:
as:
while the reasoning you described sounds like
|
fiddles FTW https://jsfiddle.net/fippo/0dxnwuyc/ Firing ONN is what needs to be done since you need to create an offer to get out of the recvonly state. |
I'm sorry, will remember next time!
I totally agree. My concern is that, this doesn't arise from the W3C specification or I read it incorrectly. Splitting the W3C algorithm into pieces and looking from the pc2 perspective:
--
That's true, "description" from the pc2 perspecitve, is of type "answer"
I mark this as
I mark this as At the end of the day, |
In other words, can't we just write
|
The present language seems to be intended to not fire negotiationneeded when you change from sendrecv to recvonly or sendonly. I'm not sure that's wise, but that's how I interpret the language. |
Hrm... could that lead to removeTrack on a sendrecv transceiver without a track not firing which is unexpected: Footgun alert... |
The removeTrack algorithm bails in step 7 if the track is null, so it will never hit the "update the negotiation-needed flag" in step 12. |
The same will happen if we call replaceTrack(null) before calling removeTrack
I am not sure. To have sendrecv in local answer the other side had to offer sendrecv so after changing to sendonly or recvonly on the answerer side, the intersection will always differ. Take a look here, pc2 changes direction from sendrecv to recvonly and negotiationneeded is fired https://jsfiddle.net/pxrzh086/1/ |
5.3.3 in checking if negotiation is needed says:
This means that if offerer offered sendonly, answerer answered with recvonly and then the answerer changed its transceiver's direction to sendrecv, negotiationneeded event won't be fired.
The intersection of transceiver direction with the offered direction is recvonly (sendrecv x sendonly = recvonly) and the direction in the answer is also recvonly so there is no change.
Currently, browsers do the opposite thing i.e. they fire negotiationneeded event when the described situation occurs.
What's the expected behaviour?
Code:
The text was updated successfully, but these errors were encountered: