-
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
codec input to setParameters shouldn't be validated by preferred receive codecs #2989
Comments
Actually [[PreferredCodecs]] includes send codecs if set by this section: Agree that this is unclear. Ideally, we should validate it over the set of codecs in the remote description, if set; if remote description is not set, it seems to me that it can only be validated over the set of implemented send codecs. (And we may want to include language saying that we enable any implemented send codec that is selected by setParameters). |
I don't see that section setting [[PreferredCodecs]]. It does seem to assume that [[PreferredCodecs]] might contain send codecs, but I do not see anywhere that will put send codecs in there. The language probably needs to be updated to reflect that this will only contain recv codecs. |
Regarding whether preferences are send, receive or both, this was discussed at TPAC. We need to go through the spec and make sure everything is consistent with this decision, but I filed #3006 for this work in order to close all the overlapping codec issues such as this one |
Step 4 of the setParameters validation steps says: "If choosableCodecs is an empty list, set choosableCodecs to transceiver.[[PreferredCodecs]].".
transceiver.[[PreferredCodecs]] are receive codecs set through setCodecPreferences and shouldn't be used to validate send codec.
The text was updated successfully, but these errors were encountered: