- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 17:11:18 +0000
- To: public-webrtc-logs@w3.org
> Prior to the last sCP change, any codec in sCP needed to be both in send and receive codecs. > Now it has to be in receive codecs only. I think a codec being required to be sendrecv was wrong, so I definitely like the direction of being able to set recvonly codecs in SCP! But I think it makes sense to also allow sendonly codecs for the sendonly use case, considering what you offer are the default preferences used unless the receiver has their own preferences. So I'm not trying to revert the progress, I'm trying to go one step further. - Can we say SCP accepts both sending codecs _and_ receiving codecs? Making both senders and receivers happy. > the new condition would be that all codecs must be in send codecs or receive codecs Correct. "OR", not "AND". > and the intersection between sCP and receive codecs must not be empty? Or rather the SCP codec filtered by the transceiver direction must not be empty. Either that or saying "any codec is fine, but at least one of them has to be sendrecv" as means to avoid `direction = 'sendrecv'` footgun. I don't have a strong preference -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2937#issuecomment-1942031155 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 17:11:20 UTC