Intent to Implement and Ship: RTCRtpSender / RTCRtpReceiver.getCapabilities()

[Florent Castelli]

Contact emails orp...@chromium.org Spec https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-getcapabilities

https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getcapabilities

Reviewed as part of WebRTC. Summary The getCapabilities() method returns the most optimistic view of the capabilities of the system for sending media of the given kind. It does not reserve any resources, ports, or other state but is meant to provide a way to discover the types of capabilities of the browser including which codecs or RTP extensions may be supported.

Motivation Users sometimes need to check the capabilities of the client. The sender capabilities can currently be retrieved by parsing the SDP generated when making an offer. This parsing is complex and error prone. There is currently no way to get the full capabilities of a receiver as they could differ from the sender's.

Without this feature, developers would also often hardcode the capabilities based on the user agent.

Interoperability risk Firefox: No public signals Edge: Shipped Safari: No public signals Web developers: Positive

Low risk. The feature is in the spec and is easy to detect. It has also been stable for a while and is not controversial.

Compatibility risk Low risk. The API has not been implemented in other browsers except for Edge which implements the version from ORTC specification which is mostly compatible.

Ongoing technical constraints None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes OWP launch tracking bug https://crbug.com/857451

Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6206698196828160 Requesting approval to ship?

Yes

[Chris Harrelson]

LGTM1

There appears to be WPT testing here. In the future please add this to the intent; the template includes such a section.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSVxfacW7UetTBj%2Bj3BrYT%3D5EzXj3tRB9b4K-8K_PddfVg%40mail.gmail.com.

[Philip Jägenstedt]

LGTM2, parsing SDP and making assumption based on UA sniffing sound like decidedly not fun for web developers.

Glad to see there's a baseline of tests in WPT already, and presumably some additional test coverage will be added as part of the implementation as I've been so happy to see happen by routine with WebRTC recently :)

If I have one ask, it is to make sure that other browser vendors are well aware of this change, by finding or filing bugs tracking this. Pointing to this thread or https://crbug.com/857451 as well as tests they can use would be great.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSVxfacW7UetTBj%2Bj3BrYT%3D5EzXj3tRB9b4K-8K_PddfVg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_vKk%3D1CG5Hk-0Q9GXSHLP3MbWjUnX-0Cy3TBCh8zxQWg%40mail.gmail.com.

[Joe Medley]

Florent,

Is there a reason you didn't add the tracking bug to the Chrome Status entry?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

On Mon, Jul 9, 2018 at 8:48 AM Florent Castelli <orp...@chromium.org> wrote:

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Florent Castelli]

Chris: Will do next time. Which template are you referring to? I used the one after filling the feature on Chrome Status.

Philip: Apart from Edge, the other browsers are still using an older version of the native WebRTC library that didn't have the matching feature. They should be able to implement it quickly when they upgrade to the latest version. I'll see what I can do regarding filling bugs.

Joe: It was an oversight on my part and the Chrome Status entry is now updated.

[Joe Medley]

Ok, thanks. 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG99%2BsaAw429uE_FqrRUuD9-%3DA%3D_xgErs2ZwWS7gxEp_Dg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[dull...@chromium.org]

Hi Florent,

The spec mentions that this feature would increase the fingerprinting surface but I can't find any details about the data returned by these methods. Could you describe what the impact on fingerprinting will be? 

Thanks,

Christian

[Florent Castelli]

The data returned is the list of supported codecs with a succint list of encoding parameters and RTP extensions.

This data will likely be the same for all browsers of the same version on a given platform.

Also as I said, that data can be retrieved from the SDP generated to initiate a negotiation and is required for the protocol to work.

A sample output for the sender audio capabilities on my machine can be seen below:

{

  "codecs": [

    {

      "channels": 2,

      "clockRate": 48000,

      "mimeType": "audio/opus",

      "sdpFmtpLine": "useinbandfec=1;minptime=10"

    },

    {

      "channels": 1,

      "clockRate": 16000,

      "mimeType": "audio/ISAC"

    },

    {

      "channels": 1,

      "clockRate": 32000,

      "mimeType": "audio/ISAC"

    },

    {

      "channels": 1,

      "clockRate": 8000,

      "mimeType": "audio/G722"

    },

    {

      "channels": 1,

      "clockRate": 8000,

      "mimeType": "audio/PCMU"

    },

    {

      "channels": 1,

      "clockRate": 8000,

      "mimeType": "audio/PCMA"

    },

    {

      "channels": 1,

      "clockRate": 32000,

      "mimeType": "audio/CN"

    },

    {

      "channels": 1,

      "clockRate": 16000,

      "mimeType": "audio/CN"

    },

    {

      "channels": 1,

      "clockRate": 8000,

      "mimeType": "audio/CN"

    },

    {

      "channels": 1,

      "clockRate": 48000,

      "mimeType": "audio/telephone-event"

    },

    {

      "channels": 1,

      "clockRate": 32000,

      "mimeType": "audio/telephone-event"

    },

    {

      "channels": 1,

      "clockRate": 16000,

      "mimeType": "audio/telephone-event"

    },

    {

      "channels": 1,

      "clockRate": 8000,

      "mimeType": "audio/telephone-event"

    }

  ],

  "headerExtensions": [

    {

      "uri": "urn:ietf:params:rtp-hdrext:ssrc-audio-level"

    }

  ]

}

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9482fa2b-bd5b-4978-bd0b-f5547fffe0d0%40chromium.org.