RTCRtcpFeedback.parameter should be optional #395

Closed
ibc opened this Issue Feb 29, 2016 · 4 comments

Projects

None yet

3 participants

@ibc
Contributor
ibc commented Feb 29, 2016

http://ortc.org/wp-content/uploads/2015/11/ortc.html#idl-def-RTCRtcpFeedback

9.2.1 Dictionary RTCRtcpFeedback Members

parameter of type DOMString

For a type of "ack" or "nack", valid values for parameters are the "ack" and "nack" Attribute Values enumerated in [IANA-SDP-15]("sli", "rpsi", etc.). For a type of "ccm", valid values for parameters are the "Codec Control Messages" enumerated in IANA-SDP-19, etc.).

type of type DOMString

Valid values for type are the "RTCP Feedback" Attribute Values enumerated in [IANA-SDP-14]("ack", "ccm", "nack", etc.).

However, in the SDP generated by Chrome I see:

a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb

So, shouldn't parameter be optional?

@aboba
Contributor
aboba commented Feb 29, 2016

Yes, in the case of the Generic NACK, feedback message, the parameter attribute would be unset. I believe this is also true for goog-remb, no?

@ibc
Contributor
ibc commented Feb 29, 2016

I believe this is also true for goog-remb, no?

No idea, but given the above SDP generated by Chrome M48 I expect it's true too.

@aboba aboba added a commit that referenced this issue Feb 29, 2016
@aboba aboba Clarification for Generic NACK
Fix for issue #395
79f5338
@aboba aboba added a commit that referenced this issue Feb 29, 2016
@aboba aboba For Generic NACK, RTCRtcpFeedback.parameter is unset
Fix for Issue #395
873fc00
@robin-raymond
Contributor

Resolved in PR.

@ibc
Contributor
ibc commented Mar 1, 2016

🍰

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment