RE: RTCRtpCapabilities "features" ?

Probably the best way to figure this out is to come up with a list of the capabilities/settings we’re interested in.    Once we have this, it’ll be easier to figure out how to express it.

It would also be good to avoid going overboard.  ORTC doesn’t need to support every potential capability and setting to be useful.

From: Peter Thatcher [mailto:pthatcher@google.com]
Sent: Tuesday, May 20, 2014 4:08 PM
To: Robin Raymond
Cc: public-ortc@w3.org
Subject: 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<mailto: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




[cid:image001.jpg@01CF7448.C5325070]
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