- From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Nov 2018 00:03:05 +0000
- To: public-webrtc-logs@w3.org
@orphis After negotiation, "codecs that the receiver is currently prepared to receive" refers to codecs included within m-lines that are sendrecv or recvonly. However, with respect to what happens prior to negotiation, is the receiver "currently prepared to receive" media before SLD/SRD is called? I think this is a bit of a slippery slope because if we allow receiver.getParameters() to return configuration prior to negotiation, we'll need to answer some basic questions such as whether this is to reflect what would be produced from createOffer() OR what the receiver is actually configured to receive, which can be different. Some questions: 1. Is receiver.getParameters() affected by setCodecPreferences()? For example, if a codec is removed via setCodecPreferences(), is it returned by receiver.getParameters()? If the goal is to reflect what codecs would appear in createOffer(), it seems odd to me to return the same codec set as would be in RTCRtpReceiver.getCapabilities() if a codec was removed via setCodecPreferences. But if it about what "the receiver is prepared to receive" one could argue that prior to calling SLD/SRD, the receiver really isn't configured to receive anything so no codecs should be returned. 2. Is receiver.getParameters() affected by direction? What if direction is set to "sendonly" so that the receiver is not prepared to receive any codecs? While this does affect what is produced in createOffer(), again one could argue that it doesn't affect what "the receiver is prepared to receive" prior to completion of negotiation. -- GitHub Notification of comment by aboba Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2032#issuecomment-440086938 using your GitHub account
Received on Tuesday, 20 November 2018 00:03:07 UTC