Re: RTCRtpCapabilities "features" ?

The problem with the Capabilities/Setting from gUM is that it depends quite
a bit on the constraints model.  We're at the ietf/w3c interim today, and
one think I learned is that constraints is not a good foundation to build
on.  It's constantly in flux and often contentious, and there have even
been serious suggestions of dumping the whole thing.  So, I'd be hesitant
to rely directly on it.  I think we could get away with something more
simple.


On Fri, Apr 25, 2014 at 6:39 PM, Robin Raymond <robin@hookflash.com> wrote:

>
>
> 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 <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
>
>