Re: RTCRtpCapabilities "features" ?

After looking into this further I think we should use the "Capabilities" 
/ "Settings" concept from GUM to satisfy this rtp "features" thingie.

( see http://dev.w3.org/2011/webrtc/editor/getusermedia.html#capabilities )

I think we could make the RTCP feedback capabilities use the 
"Capabilities" object from GUM (and we can look at other places in the 
spec which can use it too).

For example, a "nack" capability could be expressed in Capabilities as:

{ "nack": ["pli", "sli", "rpsi"] }

So in the RTCRtpCapabilities it would be defined as:

dictionary RTCRtpCapabilities {
     sequence<RTCRtpCodec> audioCodecs;
     sequence<RTCRtpCodec> videoCodecs;
     sequence<DOMString>   headerExtensions;
     Capabilities          features;          // not sure what else we 
might need feature wise to define
     Capabilities          rtcpFeedback; // specific capabilities 
related to RTCP feedback
};


And the definition of usage within the RTCRtpCodecParameters could be:

dictionary RTCRtpCodecParameters {
    unsigned byte                          payloadType = null;
    RTCRtpCodec                         codec;
    sequence<KeyValueParam>   formatParameters;
    Settings                                    rtcpFeedback;  // now 
simply a "Settings" as per GUM definition
};

( see http://dev.w3.org/2011/webrtc/editor/getusermedia.html#settings )

The only trouble with using "Settings" is that the settings for GUM 
currently says "It will be a DomString for properties of type 
PropertyValueSet." But in the case of "RTCP feedback" parameters in the 
RFC, feedback is not "pick one" option but allows for a "pick multiple". 
For example, RTCP feedback used for a specific codec can use both "pli" 
and "sli" simultaneously so using a "PropertyValueSet " doesn't work in 
that usage case.

I would therefor like to add "MultiPropertyValueSet" for our usage which 
is also a DomString [] just like "PropertyValueSet" except that the 
corresponding setting value would be a DomString [] (or a single 
DomString should be legal) instead of the only legal value being a 
single DomString so that "pick multi" option could be support for RTCP 
feedback.


With this defined we can point to the existing IANA registry for RTCP 
feedback definitions and call it a day.

-Robin



> Robin Raymond <mailto:robin@hookflash.com>
> April 24, 2014 at 10:55 PM
>
> dictionary RTCRtpCapabilities {
>     sequence<RTCRtpCodec> audioCodecs;
>     sequence<RTCRtpCodec> videoCodecs;
>     sequence<DOMString>   headerExtensions;
>     sequence<DOMString>   features;
> };
>
>
> What is "features"? Is this a IANA style namespace that defines 
> meaning to what rtp style "features" the browser engine supports?
>
> The description for "features" currently says 'Supported RTP features, 
> such as "nack" from [RFC4585 
> <http://internaut.com:8080/%7Ebaboba/ortc/ortc-4-24-2014-revised.html#bib-RFC4585>].'
>
> If it's a namespace type thing, would it define features such as 
> support rtcp feedback parameters and other "future" rtp/rtcp capabilities?
>
> Or is the intention to have "features" define exactly what stuff is 
> supported for feedback parameters as per in RFC 4585?
>
> If it's mean to define RTCP feedback mechanisms as per RFC 4585 then 
> it's not quite right since:
>
> rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
>
> rtcp-fb-pt = "*" ; wildcard: applies to all formats
> / fmt ; as defined in SDP spec
>
> rtcp-fb-val = "ack" rtcp-fb-ack-param
> / "nack" rtcp-fb-nack-param
> / "trr-int" SP 1*DIGIT
> / rtcp-fb-id rtcp-fb-param
>
> rtcp-fb-id = 1*(alpha-numeric / "-" / "_")
>
> rtcp-fb-param = SP "app" [SP byte-string]
> / SP token [SP byte-string]
> / ; empty
>
> rtcp-fb-ack-param = SP "rpsi"
> / SP "app" [SP byte-string]
> / SP token [SP byte-string]
> / ; empty
>
> rtcp-fb-nack-param = SP "pli"
> / SP "sli"
> / SP "rpsi"
> / SP "app" [SP byte-string]
> / SP token [SP byte-string]
> / ; empty
>
> .. would require a more detailed definition.
>
> Basically, to give clear indication for rtcp feedback support, the 
> capabilities would have to be more like this:
>
> dictionary RTCRtpCapabilities {
>     sequence<RTCRtpCodec> audioCodecs;
>     sequence<RTCRtpCodec> videoCodecs;
>     sequence<DOMString>   headerExtensions;
>     sequence<RTCRtcpFeedbackCapability>   feedbackParamters;
> };
>
>
> dictionary RTCRtcpFeedbackCapability {
>     DOMString  type;    // e.g. "ack", "nack", "trr-int", ...
>     sequence<DOMString >   value;    // e.g. for "nack" would be list 
> of "pli", "sli", "rpsi", "app"
> };
>
>
> I'm guessing since we already have a list of "RTCRtcpFeedbackParam" 
> for each codec which can indicate that information per codec for 
> feedback mechanisms that Rtc capability "features" is meant to be an 
> IANA style namespace set of features supported by the browser engine.
>
> But if a "feature" was listed as string "nack", does that mean the 
> browser engine supports all types of "nack", e.g.: "pli", "sli", 
> "rpsi", ... ? (personally, I don't think that makes much sense). If it 
> doesn't mean all are supported then does "nack" mean that 'at least 
> one (or more) of the "nack" feedback mechanisms are supported'? In 
> that case would we say "to know exactly what rtcp feedback mechanisms 
> are supported, the application would have to obtain the per codec rtcp 
> feedback parameters to know what feedback parameters are available"?
>
> So I propose that "features" is left as is, i.e. a sequence of 
> DOMStrings and that it represents an IANA style definition of RTP 
> "features" that are available and that for each feature we define what 
> that feature means. And in the case of "nack", I think 'at least one 
> or more of "pli", "sli, "rpsi", "app" is supported but details are 
> left to be discovered inside codec parameters.
>
> If others have use cases where we need a "capabilities" style 
> mechanism to discover more detailed but generalized (i.e outside each 
> codec) possible rtcp feedback mechanisms then I suggest we add 
> "sequence<RTCRtcpFeedbackCapability>   feedbackParamters;" to the 
> RTCRtpCapabilities dictionary, but I'm not in favour of that unless we 
> have a strong need.
>
> Thoughts?
>
> -Robin
>