Clarification in Section 7.3.2 #153

Closed
aboba opened this Issue Oct 2, 2014 · 1 comment

Projects

None yet

1 participant

@aboba
Contributor
aboba commented Oct 2, 2014

A question has arisen as to how RTCRtpReceiver.getCapabilities(kind) should behave with respect to codecs that have no intrinsic kind (such as RTX or RED). For example, if we assume that RTX and RED can be used with kind === 'audio' or 'video', should these codecs be returned regardless of the value of kind? Also, should RTX and/or RED be returned as a codec capability at all?

Below is some proposed text for Section 7.3.2 to describe the desired behavior of RTCRtpReceiver.getCapabilities:

getCapabilities, static
Obtain the receiver capabilities, based on kind. If kind is omitted or set to "", then all capabilities are returned. To avoid confusion, getCapabilities(kind) should return codecs with a matching intrinsic kind value, as well as codecs with no intrinsic kind, (such as the retransmission payload [RFC4588] and redundancy [RFC2198]), with the value of RTCRtpCapabilities.RTCRtpCodecCapability[i].kind set to the value of kind passed as an argument to RTCRtpReceiver.getCapabilities(kind).

@aboba
Contributor
aboba commented Oct 2, 2014

An update to the proposed text (assuming that codecs without an intrinsic kind are returned at all):

Obtain the receiver capabilities, based on kind. If kind is omitted or set to "", then all capabilities are returned. To avoid confusion, getCapabilities(kind) should return codecs with a matching intrinsic kind value, as well as codecs with no intrinsic kind, (such as the retransmission payload [RFC4588] and redundancy [RFC2198]). For codecs with no intrinsic kind, RTCRtpCapabilities.RTCRtpCodecCapability[i].kind returned by getCapabilities(kind> should be set to the value of kind if kind is equal to "audio" or "video". If the kind argument was omitted or set to "", then the value of RTCRtpCapabilities.RTCRtpCodecCapability[i].kind is set to "".

Also, in the same section, the following modified receive text is proposed:

receive
Media to be received is controlled by parameters. If receive() is called with invalid RTCRtpParameters, throw an InvalidParameters exception. The receive() method does not update parameters based on what is currently being received, so that the value of parameters remains that last passed to the receive() method. The RTCRtpReceiver object starts receiving when receive() is called for the first time, and changes the receiving parameters when receive() is called again. The RTCRtpReceiver object stops receiving when stop() is called. After receive returns, track is set, and the value of track.kind is determined based on the kind of the codecs provided in parameters.codecs. If parameters.codecs are all of a single kind then track.kind is set to that kind. If parameters.codecs are of mixed kind, throw an InvalidParameters exception. For this purpose a kind of "" is not considered mixed.

@aboba aboba closed this Oct 10, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Oct 14, 2014
Robin Raymond Address questions about RTCDtlsTransport.start(), as noted in: Issue #…
…146

Address questions about RTCRtpCodecCapability.preferredPayloadType, as noted in: Issue #147
Address questions about RTCRtpSender.setTrack() error handling, as noted in: Issue #148
Partially address 'automatic' use of scalable video coding (in RTCRtpReceiver.receive()) as noted in: Issue #149
Renamed RTCIceListener to RTCIceGatherer as noted in: Issue #150
Added text on multiplexing of STUN, TURN, DTLS and RTP/RTCP, as noted in: Issue #151
Address issue with queueing of candidate events within the RTCIceGatherer, as noted in: Issue #152
Clarify behavior of RTCRtpReceiver.getCapabilities(kind), as noted in: Issue #153
7a48e0b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment