webrtchacks / adapter

Shim to insulate apps from spec changes and prefix differences. Latest adapter.js release:

WebRTC adapter

adapter.js is a shim to insulate apps from spec changes and prefix differences in WebRTC. The prefix differences are mostly gone these days but differences in behaviour between browsers remain.

This repository used to be part of the WebRTC organisation on github but moved. We aim to keep the old repository updated with new releases.

Install

NPM

npm install webrtc-adapter

Bower

bower install webrtc-adapter

Usage

Javascript

Just import adapter:

import adapter from 'webrtc-adapter';

No further action is required. You might want to use adapters browser detection which detects which webrtc quirks are required. You can look at

adapter.browserDetails.browser

for webrtc engine detection (which will for example detect Opera or the Chromium based Edge as 'chrome') and

adapter.browserDetails.version

for the version according to the user-agent string.

NPM

Copy to desired location in your src tree or use a minify/vulcanize tool (node_modules is usually not published with the code). See webrtc/samples repo as an example on how you can do this.

Prebuilt releases

Web

In the gh-pages branch prebuilt ready to use files can be downloaded/linked directly. Latest version can be found at https://webrtc.github.io/adapter/adapter-latest.js. Specific versions can be found at https://webrtc.github.io/adapter/adapter-N.N.N.js, e.g. https://webrtc.github.io/adapter/adapter-1.0.2.js.

Bower

You will find adapter.js in bower_components/webrtc-adapter/.

NPM

In node_modules/webrtc-adapter/out/ folder you will find 4 files:

• adapter.js - includes all the shims and is visible in the browser under the global adapter object (window.adapter).
• adapter_no_global.js - same as adapter.js but is not exposed/visible in the browser (you cannot call/interact with the shims in the browser).

Include the file that suits your need in your project.

Development

Head over to test/README.md and get started developing.

Publish a new version

• Go to the adapter repository root directory
• Make sure your repository is clean, i.e. no untracked files etc. Also check that you are on the master branch and have pulled the latest changes.
• Depending on the impact of the release, either use patch, minor or major in place of <version>. Run npm version <version> -m 'bump to %s' and type in your password lots of times (setting up credential caching is probably a good idea).
• Create and merge the PR if green in the GitHub web ui
• Go to the releases tab in the GitHub web ui and edit the tag.
• Add a summary of the recent commits in the tag summary and a link to the diff between the previous and current version in the description, example.
• Go back to your checkout and run git pull
• Run npm publish (you need access to the webrtc-adapter npmjs package). For big changes, consider using a tag version such as next and then change the dist-tag after testing.
• Done! There should now be a new release published to NPM and the gh-pages branch.

Note: Currently only tested on Linux, not sure about Mac but will definitely not work on Windows.

Publish a hotfix patch versions

In some cases it may be necessary to do a patch version while there are significant changes changes on the master branch. To make a patch release,

• checkout the latest git tag using git checkout tags/vMajor.minor.patch.
• checkout a new branch, using a name such as patchrelease-major-minor-patch.
• cherry-pick the fixes using git cherry-pick some-commit-hash.
• run npm version patch. This will create a new patch version and publish it on github.
• check out origin/bumpVersion branch and publish the new version using npm publish.
• the branch can now safely be deleted. It is not necessary to merge it into the main branch since it only contains cherry-picked commits.

adapter's Issues

removing a mediastream from an element

from https://github.com/MicrosoftEdge/Demos/pull/68
-- removing a stream from an element works differently in different browsers.

The easiest solution which doesn't increase the API surface of adapter seems to pass null or false to attachMediaStream. Thoughts @alvestrand @KaptenJansson?

make adapter.js versions available on the gh-pages branch

coming from here: https://github.com/MicrosoftEdge/Demos/issues/90#issuecomment-127363723

the "easy" way to do this is probably to put adapter.js onto the gh-pages branch so we'd have them available as https://webrtc.github.io/adapter/adapter-0.2.1.js etc

The samples can then include that (or a -latest if we dare).
@samdutton @KaptenJansson?

Support Object RTC and Microsoft Edge

Will adapter.js support Object RTC and Microsoft Edge?

http://dev.modern.ie/platform/changelog/10525-pc/

Or, is someone working on a shim in another repo?

Need publishing procedure for NPM packages

Discovered today "the hard way" that "npm publish" grabs everything in the homedir by default and includes it as part of the package, whether it's junk or not. This needs to not happen - one can use "files" in package.json and/or an ".npmignore" file, or one can use a procedure / script that does a clean checkout before the "npm publish".

NPM install warns about unmet dependencies

npm WARN unmet dependency /home/test/dev/adapter/node_modules/testling/node_modules/browserify/node_modules/derequire/node_modules/esrefactor requires estraverse@'~0.0.4' but will load
npm WARN unmet dependency /home/test/dev/adapter/node_modules/testling/node_modules/browserify/node_modules/derequire/node_modules/estraverse,
npm WARN unmet dependency which is version 1.5.1

Make adapter.js more granular

From webrtc/samples#134

Currently, adapter.js uses navigator.mozGetUserMedia to detect the browser. As adapter.js expands to support more environments, we should make the feature detection and injection more granular, so that, for example, RTCPeerConnection can be handled even in environments (e.g. Firefox Add-ons, node.js) that do not have navigator.getUserMedia.

Broken build due to grunt-jscs has bumped to v2.0

@fippo @alvestrand @jan-ivar FYI

Doesn't recognize Opera for Android as a capable browser

I just reported this to Opera (bug DNA-43013), the problem is that window.chrome is not defined like in desktop version.

Don't know if we can do something here to be able to recognize this like user agent detection.

Need to support static methods on RTCPeerConnection

In implementing generateCertificate, which is a static method on RTCPeerConnection, we discovered that defining RTCPeerConnection as a function (and doing no more) hid the static method in Chrome (if the RTCPeerConnection class declaration was made visible).

Is it enough / correct to add "RTCPeerConnection.prototype = webkitRTCPeerConnection.prototype" to get static functions to work, or do we need to do something more complex?
We don't have any static functions so far, so I have nothing to test on.

Asking @fippo @jan-ivar for advice.

Provide a unified stats interface in adapter.js

Currently, adapter.js makes no attempt to unify the getStats behavior between different browsers. Now that the standard seems to be settling on a stats format, adapter.js should attempt to provide it.

This work item does not include munging the names of any stats keys. The goal is only to provide a unified, browser-independent access method.

fippo commented on Oct 8, 2014
something like https://github.com/HenrikJoreteg/RTCPeerConnection/blob/master/rtcpeerconnection.js#L431
? Ignores the track argument though.
Benjamin M. Schwartz

bemasc commented on Nov 6, 2014
I was thinking of something like bemasc/webrtc-adapter@71a5837

throws exception on chrome device emulator

Reproduce:

• Open chrome devtools
• Enable emulator
• Set device to "Apple iPhone 6"

Error:

Uncaught TypeError: Cannot read property '2' of null

/Users/chirp/node_modules/wildfire-client/node_modules/attachmediastream/node_modules/webrtc-adapter-test/adapter.js @ adapter.js:206

/Users/chirp/node_modules/wildfire-client/node_modules/getusermedia/node_modules/webrtc-adapter-test/adapter.js @ index-browser.js:80

Root of the problem: https://github.com/webrtc/adapter/blob/master/adapter.js#L232-L233

Add a section on README.md showing how to use bower to depend on this.

figure out if there is a way to test Edge through selenium

http://blogs.windows.com/msedgedev/2015/07/23/bringing-automated-testing-to-microsoft-edge-through-webdriver/
-- Edge just got support for this. Possibly might make more sense to do this in the samples which are already using Selenium.

@alvestrand :-)

Migrate requestUserMedia to be an overload of getUserMedia

If the first argument is not a function, you get the promise version.

getStats: shim different report names

#46 polyfilled the getStats but did not do any field name rewriting as I noticed in webrtc/samples#551

In that case it was type=ssrc vs type=outboundrtp.

Identifying what needs to be done here is probably the difficult part, maybe something that could be done more easily during the september F2F meeting @alvestrand @jan-ivar @vr000m?

Reduce leaking globals and create an explicit function exposing the globals we need.

No op add/removeEventListener methods

Currently Chrome unstable (45) has the navigator.medaDevices object but without addEventListener and removeEventListener methods.

This causes two tests to fail because we conditionally add addEventListener and removeEventListenerfunctions to navigator.medaDevices only if !navigator.mediaDevices.

@jan-ivar, @alvestrand, @fippo this was added in #45 to prevent some crash. Should we add something like this:

if (typeof navigator.mediaDevices.removeEventListener === 'undefined' ||
      typeof navigator.mediaDevices.addEventListener === 'undefined') {
    // in case someone wants to listen for the devicechange event.
    navigator.mediaDevices.addEventListener = function() { };
    navigator.mediaDevices.removeEventListener = function() { };

}

to make the tests pass on Chrome unstable?

adapter.js should not pollute the global namespace

From webrtc/samples#297

ibc commented on Dec 13, 2014
No one in the world should define a global function called trace() (and so many other window globals defined in adapter.js).

adapter.js seems to ignore any new design pattern and JS module system (AMD, CommonJS, etc).

Would you accept a PR removing all the global stuff and providing a library suitable to be loaded by any existing JS module loader without polluting the window global namespace?
Sam Dutton
Owner
samdutton commented on Dec 13, 2014
You have a point :).

adapter.js worked OK in the context of the demos it was initially built for but, of course, will cause namespace pollution in larger projects.

At the very least it would be great to refactor it from an object-oriented approach with no globals.

@juberti @KaptenJansson @phoglund WDYT?
Iñaki Baz Castillo

ibc commented on Dec 13, 2014
I mean something that can be loaded with npm install webrtc-adapter (and borwserified with browserify), and Bower, and so on.
Iñaki Baz Castillo

ibc commented on Dec 13, 2014
Let me know if you are interested and I will provide a PR.
Justin Uberti
Owner
juberti commented on Dec 14, 2014
yeah, I think it's time for adapter.js to grow up. Would you mind changing the title of this issue to be more descriptive?

And please provide an initial PR for the adapter - we'll then have to do a subsequent PR for changing all of our sample code.
Iñaki Baz Castilloibc changed the title from Please build modern JS to Make adapter.js a modern JS library (module systems aware) on Dec 14, 2014
Iñaki Baz Castillo

ibc commented on Dec 14, 2014
I will start in my own repo by creating a JS "project" (not a single adapter.js file), which will include Grunt/gulp tasks for linting, browserifying, etc.

Let me some time please, I will notify it here when done.
Sam Dutton
Owner
samdutton commented on Dec 14, 2014
Thanks for doing this!

adapter.js will be happy to get some attention :).
…
Justin Uberti
Owner
juberti commented on Dec 14, 2014
Before spending too much time, it would be good to get a high-level overview of what you expect it to look like in the end. I am all for avoiding global namespace pollution but I want to make sure we're not biting off too much here.
Christoffer Jansson
Owner
KaptenJansson commented on Dec 14, 2014
SGTM
Will

willscott commented on Dec 15, 2014
FYI - I've begun maintaining a CommonJS library to do something similar: https://www.npmjs.org/package/webrtc-adapter
Iñaki Baz Castillo

ibc commented on Dec 15, 2014
@willscott found that yesterday, I will do something similar, but including a new JS namespace to place in there all the util functions exposed by the current adapter.js.
Will

willscott commented on Dec 15, 2014
@ibc If I understand, you want to see createIceServer & similar explicitly exported, right?

My motivation was to be able to pull in adapter via browserify, and have it find what's in scope via typeof rather than probing navigator, which isn't available for firefox addons.

If the intermediate utility functions are useful, I'd be happy to see those exported.
Iñaki Baz Castillo

ibc commented 26 days ago
Hi, finally I've taken a different approach. It covers more than what adapter.js provides as it is a full wrapper over the RTCPeerConnection interface (along with all the other WebRTC interfaces and functions). It is loadable via Node+browserify, AMD, RequireJS, etc, and it does not pollute the global (window) namespace, even stuff like RTCPeerConnection, etc. Instead it provides a single entry module called "rtcninja":

https://github.com/ibc/rtcninja.js

The documentation is still missing however.
Justin Uberti
Owner
juberti commented 26 days ago
Thanks. 2KLOC seems kind of heavy though for this shim lib. I think we probably want to have something more like willscott's webrtc-adapter.

Perhaps the documentation will make the value more clear, but I was also somewhat wary of the various timers I saw in your implementation.

element.mozSrcObject = stream doesn't work in FF >= 34.0.5

Migrated from webrtc/samples#302

ibc commented on Dec 16, 2014
When Firefox is detected:

// Attach a media stream to an element.
attachMediaStream = function(element, stream) {
console.log('Attaching media stream');
element.mozSrcObject = stream;
};
This no longer works in FF 34.0.5 (nor in the today's Nightly version). BTW the "old fashion?" element.src = URL.createObjectURL(stream) does work.

I know that this spec is changing and honestly I don't know how the standard will finally be.

Not sure how to "fix" adapter.js in order to apply one way or another depending on the version of FF.
Iñaki Baz Castillo

ibc commented on Dec 16, 2014
NOTE: The problem is that in FF 34.0.5 typeof element.mozSrcObject !== 'undefined' so...
Justin Uberti
Owner
juberti commented on Dec 16, 2014
I think the currently preferred syntax in Moz is 'element.src = stream'. @samdutton
Iñaki Baz Castillo

ibc commented on Dec 17, 2014
Yep, and AFAIR that what the standard says (or will finally say). Anyhow, the problem is that a MediaStream object in Firefox stable 34.0.5 (and current Nightly) does include an attribute called mozSrcObject (but it does not work as before).
Iñaki Baz Castillo

ibc commented on Dec 17, 2014
@juberti No, Firefox 34 does not accept element.src = stream. Tested.

element.src = URL.createObjectURL(stream); seems the only way to make it work.

helper function for stopping a local stream

from https://github.com/webrtc/samples/pull/517/files#r32347016
do we want an equivalent of localStream.stop() which iterates over all audio and video tracks and stops them?

Remove console.logs

Please remove console calls

Figure out why jscs does not check camelCase

Example of it not working in #74.

dont modify the window object

When using this as a npm module, please don't modify the window object. This breaks encapsulation and makes this incompatible with other WebRTC tooling (temasys, iosrtc, others). Overriding globals is generally a bad idea, but doing it in an npm module on require is especially bad.

Update registration on Bower

Currently Bower registry still points to GoogleChrome repo, it needs to be removed and re-registered again pointing to that repo.

You can also check that info by executing from command line bower info adapter.js:

> bower info adapter.js
bower not-cached    git://github.com/GoogleChrome/webrtc.git#*
bower resolve       git://github.com/GoogleChrome/webrtc.git#*
bower checkout      adapter.js#master
bower resolved      git://github.com/GoogleChrome/webrtc.git#f21fef6177

{
  name: 'adapter.js',
  description: 'A shim to insulate apps from WebRTC spec changes and prefix differences',
  homepage: 'http://googlechrome.github.io/webrtc/',
  repository: {
    type: 'git',
    url: 'https://github.com/GoogleChrome/webrtc.git'
  },
  authors: [
    'The WebRTC project authors (http://www.webrtc.org/)',
    'Jesús Leganés Combarro "piranna" <[email protected]>'
  ],
  main: 'samples/web/js/adapter.js',
  moduleType: [
    'globals'
  ],
  keywords: [
    'WebRTC',
    'PeerConnection',
    'RTCPeerConnection',
    'getUserMedia',
    'Chrome',
    'Chromium',
    'Firefox'
  ],
  license: 'BSD-3-Clause',
  ignore: [
    '**/.*',
    'node_modules',
    'bower_components',
    'test',
    'tests',
    'Gruntfile.js',
    'index.html',
    'package.json',
    'samples/web/content',
    'samples/web/css',
    'samples/web/js/lib',
    'samples/web/js/videopipe.js'
  ]
}

No versions available.

Shim MediaStream.ended attribute until all apps have caught up?

Implement MediaStream.active/inactive attribute. (ended is deprecated)

Add console.log test case for when not loaded as a module

Current test case only validates the case when added as a module.

Investigate why translateIce test fails on travis

https://github.com/fippo/adapter/commit/7d69f861abffcde8f8b0bce0710fc38cf417c32b

Logging is broken

This was found by @tednakamura.

The following currently does not work when loaded as a module in nodejs hence the test does not work. Also it only tests the "module" case, filed #109 to cover the "non-module" case.

var webrtcUtils = {
  log: function() {
    // suppress console.log output when being included as a module.
    if (!(typeof module !== 'undefined' ||
        typeof require === 'function') && (typeof define === 'function')) {
      console.log.apply(console, arguments);
    }
  }
};

Also do note, this breaks logging when not loaded as a module, as seen in the basic datachannel demo.

@fippo I took a quick stab at it but could not get it work and since I did not implement this and do not know to much about modules, could you take a look? However if you do not have time in the nearest future, I will take another stab at it.

Chrome runs 52 test while FF runs 36

I've not dug into why, most likely a shim difference that accounts for this but still wanted to file an issue to remind me (or someone else) to really determine why.

bower invalid-meta webrtc-adapter is missing "ignore" entry in bower.json

bower update complains about the following for adapter:

• bower invalid-meta webrtc-adapter is missing "ignore" entry in bower.json

Will fix it soonish.

Bump package version to 1.3 and publish to npm

Would love to see an npm update with the latest fixes from @fippo @KaptenJansson

adapter.js versioning policy + minimum required versions

In order to make adapter.js dependable, there needs to be some kind of versioning system.

Currently, it is rather unclear what you need to do when upgrading adapter which keeps even me from using it. In the past, things have been removed without notice. And I want to do that in this PR https://github.com/webrtc/adapter/pull/18#discussion_r26180825 as well, so this is not a theoretic problem.

Let's use semver as follows:
Patch version: backward compatible fixes you absolutely want to pull in and that don't break anything.
Minor version: addition of new features.
Major version: removal of old APIs/functionality/workarounds in adapter.js.

The major version is a little tricky. We use adapter to shim functionality that is yet there or only exist newer versions of Chrome and Firefox. But we don't want to keep "old cruft" around forever. For example the shim of MediaStream.prototype.getAudioTracks (mid-2013)...

On talky, I am seeing chrome versions which do not support DTLS and some other ... interesting... errors. I do not want to support those versions anymore. If you use a 6+ month old browser you are probably getting an experience which is worse than what you should get...
Chromium 37 (possibly older versions of Chrome as well) seem to have an issue with opusfec.

Hence we should also require a minimum browser version (both FF and Chrome) and bump the major version if we change that.

thoughts @samdutton? (cc @bemasc @DamonOehlman)
The final version will be an empty file because we don't need a shim anymore! Not sure if that is a realistic goal but... :-)

No logs are printed for Firefox

Open a new tab and open the javascript console.
Enter https://test.webrtc.org and check the console output.

This appears to be Chrome
(index):20 spec: {"audio":{"optional":[{"sourceId":""}]},"video":{"optional":[{"sourceId":""}]}}
(index):20 chrome: {"audio":{"optional":[{"sourceId":""}]},"video":{"optional":[{"sourceId":""}]}}

While Firefox (38) prints
"This appears to be Firefox"
mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create

@jan-ivar any ideas? I've not had a chance to dig into why yet.

Note I noticed the SHA1 ssl certificate warnings FF also prints, will follow that up separately (create a new certificate perhaps using SHA-256).

Support running tests on Mac OS X

Current output of tests on OS X:

Installing browser
+ set -e
++ dirname ./node_modules/travis-multirunner/setup.sh
+ pushd ./node_modules/travis-multirunner
++ pwd -P
+ SCRIPTPATH=/Users/xanderdumaine/Code/adapter/node_modules/travis-multirunner
+ popd
++ /Users/xanderdumaine/Code/adapter/node_modules/travis-multirunner/node_modules/.bin/browser-version chrome stable
+ TARGET_BROWSER='chrome|stable|44.0.2403.130|https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb'
++ echo 'chrome|stable|44.0.2403.130|https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb'
++ cut '-d|' -f4
+ TARGET_URL=https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
++ echo 'chrome|stable|44.0.2403.130|https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb'
++ cut '-d|' -f3
+ TARGET_VERSION=44.0.2403.130
+ TARGET_PATH=/Users/xanderdumaine/Code/adapter/node_modules/travis-multirunner/browsers/chrome/44.0.2403.130
+ BINPATH=./browsers/bin
+ mkdir -p ./browsers/bin
+ '[' '!' -d /Users/xanderdumaine/Code/adapter/node_modules/travis-multirunner/browsers/chrome/44.0.2403.130 ']'
+ echo 'getting chrome 44.0.2403.130'
getting chrome 44.0.2403.130
+ source /Users/xanderdumaine/Code/adapter/node_modules/travis-multirunner/install-chrome.sh https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb /Users/xanderdumaine/Code/adapter/node_modules/travis-multirunner/browsers/chrome/44.0.2403.130
+++ echo https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
+++ sed -r 's/^.*\/([^\/]*)$/\1/'
sed: illegal option -- r
usage: sed script [-Ealn] [-i extension] [file ...]
       sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]
++ FNAME=
Starting browser
cat: /proc/sys/kernel/random/uuid: No such file or directory
readlink: illegal option -- f
usage: readlink [-n] [file ...]
could not find chrome executable: ./browsers/bin/chrome-stable

Command undefined terminated with non-zero exit code

Add trace.info() and trace.error() methods

webrtc/samples#130 (comment)

Firefox Unstable doesn't complete tests

Travis runs on Firefox Unstable end like this:

call enumerateDevices

ALSA lib control.c:951:(snd_ctl_open_noupdate) Invalid CTL
ALSA lib control.c:951:(snd_ctl_open_noupdate) Invalid CTL
ALSA lib control.c:951:(snd_ctl_open_noupdate) Invalid CTL
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM
ALSA lib control.c:951:(snd_ctl_open_noupdate) Invalid CTL
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM
No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.

Firefox version is 41.0a1.

Capture screen in FF37-OSX not working: constraintsToFF37 mess up the constraints

I've run into an issue trying to capture the screen in FF37. When I invoke getUserMedia, no screen or window is shared, no dialogue is shown, and this appears in the logs

spec: {"audio":false,"video":{"mandatory":{"maxWidth":640,"maxFrameRate":15,"minFrameRate":15},"mozMediaSource":"screen","mediaSource":"screen"}}
ff37: {"audio":false,"video":{"mandatory":{"maxWidth":640,"maxFrameRate":15,"minFrameRate":15},"advanced":[{"mozMediaSource":{"min":"screen","max":"screen"}},{"mediaSource":{"min":"screen","max":"screen"}}]}}
TypeError: 'mediaSource' member of MediaTrackConstraintSet '[object Object]' is not a valid value for enumeration MediaSourceEnum.

It looks like the mangling done by the function constraintsToFF37 is not working/needed for FF37, as commenting out the call to the function allows me to share the screen again. I've finally changed the code from

  getUserMedia = (webrtcDetectedVersion < 38)

to

  getUserMedia = (webrtcDetectedVersion < 37) 

and so far it's working fine. Could you please confirm this issue?

Thanks,

Add support for upcoming navigator.mediaDevices.enumerateDevices()

Original tracked in this crbug

MediaStreamTrack.getSources() will soon be deprecated.

tags for versioning

Bower use git tags to identify each one of the versions, adapter should add them.

renameIceURLs causes issue on firefox

Hi.

The renameIceURLs call causes issues on firefox in the following code:

config.iceServers.forEach(function (server) {
server.url = server.urls;
delete server.urls;
});

Basically, if the iceServers ALREADY only has server.url then this is wiped out and is set to undefined.

To put it another way, if the entry does not have 'urls' but is already defined as 'url' in the config then this buggers it up..

The correct way to do this should have been server.usr = server.url || server.urls where server.url take precedence

Regards

Investigate if we can use chromium stable-2 versions

Chromium builds

Issue created based on https://github.com/webrtc/adapter/pull/86#issuecomment-122756406

Add .md extension to LICENSE file

Add helper function for stopping all tracks, all video and all audio tracks.

Saves us from doing this in tons of places:
stream.getAudioTracks().forEach(function(track) { track.stop(); })

I propose adding the following methods:
stream.stopAllTracks()
stream.stopAllVideoTracks()
stream.stopAllAudioTracks()

@fippo, @juberti WDYT?

FYI: Note that Chrome actually has a non standard method called stream.getAllTracks().

Make adapter a npm module.

The previous existent package.json was just to manage dependencies for apprtc for travis and not a real package.json for this project.

Include support for iOS cordova-plugin-iosrtc?

The implementation: iosrtc is (afaik) following spec. the adapter is able to work by altering the UA check here but that is less than ideal when the actual browser is indeed a WebView.

Specify the main module in "package.json"

Currently, it's not possible to resolve something like this:

var adapter = require('webrtc-adapter-test');

This is fixed by adding "main": "adapter.js" to "package.json", which follows the standard node resolving process.

webkitGetUserMedia adapter fails in WebKit browsers other than Chrome

The demo at https://webrtc.github.io/samples/src/content/getusermedia/gum/ fails right now on BlackBerry 10 devices because the JavaScript assumes that Chrome is the only WebKit-based browser that supports navigator.webkitGetUserMedia:

} else if (navigator.webkitGetUserMedia) {
  webrtcUtils.log('This appears to be Chrome');

  webrtcDetectedBrowser = 'chrome';

  // the detected chrome version.
  webrtcDetectedVersion =
    parseInt(navigator.userAgent.match(/Chrom(e|ium)\/([0-9]+)\./)[2], 10);

A TypeError is thrown because "Chrom(e|ium)" does not appear in the BB10 User-Agent.

The sample works on BlackBerry 10.3.2 when I use Web Inspector to override the User-Agent and masquerade as Chrome.

Could we make webrtcDetectedVersion a bit more robust? There are other WebKit-based browsers out there that would probably trip over this too. It would be nice if the code could recover gracefully from navigator.userAgent not containing "Chrom(e|ium)", even if it ends up treating the browser the same as Chrome.

(The BlackBerry 10 browser is based on WebKit and supports webkitGetUserMedia in all releases. In BlackBerry 10.3.2, the BlackBerry Browser additionally supports WebRTC, but it doesn't currently support Promises or WebAudio.)

Consider using precommit hook in favor of grunt githooks

grunt githooks requires to be executed once after npm install to be properly added as a hook which is pretty inconvenient.

Adding it as a postinstall step in npm breaks npm when installing it as a dependency in other projects.

As suggested by @fippo, precommit hook does not come with this caveat and also it can separate tasks in a clear way, test, validation etc.

I filed this as an adapter issue but we should consider it collectively, e.g. for all webrtc/ sub repos.

@samdutton @alvestrand @fippo WDYT?

Add jsdoc style comments/documentation

Add tests for all public functions in adapter.js to detect interop issues

webrtc/samples#523 was caused by webrtc/adapter@04af828 where window.createIceServer was removed.

We should add tests for this, just a rudimentary check like "typeof foo !== undefined" for all expected public api functions/methods is better than nothing.

Also its easier then to make sure that when we do break something we properly update the version number to indicate it's incompatible.