Firefox supports getVideoTracks() and getAudioTracks() methods as of version 23.

https://developer.mozilla.org/en-US/docs/Web/API/MediaStream

Spawned from chromium bug: https://code.google.com/p/chromium/issues/detail?id=378205

Hi Sir,

I am trying to implement video conferencing between two peers using WebRTC and found below URL:
http://html5videoguide.net/presentations/WebDirCode2012/websocket/webrtc.html

Above works fine when button Start Video & Stop Video buttons are clicked & it displays my machines video. but when I click on connect button to connect with the some other machine, who is also at the same URL then nothing happens. Do I need to incorporate IP address of my machine or remote machine in the code for connecting through Web.rtc ? Do I need node.js running ? Please help.

Thanks in advance,
Awadesh Badaya

Blocked on #61

The testrtc page should ask for video+audio (and only once) so the user don't have to allow multiple getUserMedia requests (when the page is served over HTTPS).

Queue cron tasks to clean up rooms that have no occupants, or both occupants are not connected (and aren't experiencing a spurious disconnection).
https://cloud.google.com/appengine/docs/python/config/cron

Add a new "it" parameter that is passed down and used as the iceTransports member in the RTCConfiguration object. For now, since iceTransports doesn't do anything, specifying it=relay should cause all non-relay candidates to be discarded in the oncandidate callback, forcing the use of the relay.

Moving issue from webrtc tracker to github.
Quoth https://github.com/GoogleChrome/webrtc/blob/master/samples/web/content/apprtc/apprtc.py#L395

debug = self.request.get('debug')
if debug == 'loopback':
  # Set dtls to false as DTLS does not work for loopback.
  dtls = 'false'

Indeed, failing to disable DTLS causes errors like:
Error(transport.cc:101): Answerer must use either active or passive value for setup attribute.

Since SDES is eventually going to disappear in favor of DTLS we should make sure loopback calls work with DTLS as well. The answer is probably to set up a second PeerConnection on the same page.
Once the JS version is updated the same should be done for the Android & iOS sample apps.

OS: Ubuntu 14.04.1 LTS
Setup: use iptables to block nearly all outbound tcp (except 80 and 443) and udp (except dns and dhcp).

Repro steps:

1. Open https://test-rtc.appspot.com/
2. Press Start

Issue:
Test seems to hang at the "Data channel throughput" test. Perhaps it's missing a timeout?

Full test output below:
[ RUN ] MicrophoneTest
[ OK ] getUserMedia succeeded.
[ OK ] Audio track exists with label=Default
[ OK ] Audio num channels=1
[ OK ] Audio sample rate=44100
[ OK ] Audio power=-36.1199102794985
[ ------ ]
[ RUN ] UdpConnectivityTest
[ FAILED ] Failed to gather specified candidates
[ ------ ]
[ RUN ] TcpConnectivityTest
[ FAILED ] Failed to gather specified candidates
[ ------ ]
[ RUN ] HasIpv6Test
[ OK ] Gathered candidate with type: host address: 2620:0:1000:1600:a2e:5fff:fe0d:28c0
[ ------ ]
[ RUN ] CamResolutionsTest
[ INFO ] Supported resolution: (160x120)
[ INFO ] Supported resolution: (320x180)
[ INFO ] Supported resolution: (320x240)
[ INFO ] Supported resolution: (640x360)
[ INFO ] Supported resolution: (640x480)
[ INFO ] Resolution NOT supported: (768x576)
[ INFO ] Resolution NOT supported: (1024x576)
[ FAILED ] Camera does not support a mandatory resolution, (1280x720)
[ INFO ] Resolution NOT supported: (1280x768)
[ INFO ] Resolution NOT supported: (1280x800)
[ INFO ] Resolution NOT supported: (1920x1080)
[ INFO ] Resolution NOT supported: (1920x1200)
[ INFO ] Resolution NOT supported: (3840x2160)
[ INFO ] Resolution NOT supported: (4096x2160)
[ ------ ]
[ RUN ] CamCaptureTest
[ OK ] getUserMedia succeeded.
[ OK ] Video track exists with label = Microsoft® LifeCam VX-2000 (045e:0761)
[ INFO ] Checking if your camera is delivering frames for five seconds...
[ OK ] Expected: 640 === 640: Width OK
[ OK ] Expected: 480 === 480: Height OK
[ OK ] Expected: false === false: Camera is delivering frames
[ OK ] Expected: 0 === 0: Camera is sending non-black frames.
[ ------ ]
[ RUN ] Data channel throughput

http://googlechrome.github.io/webrtc/samples/web/content/constraints/

Nice new look of all demo pages!

I would suggest calling MediaStreamTrack::Stop on the video track before requesting a new gUM.
Currently, the new constraints are not applied since Chrome can't handle multiple video tracks with different constraints. (This will hopefully be fixed in M36.)

Copied from https://code.google.com/p/chromium/issues/detail?id=419452.

Browser: Chrome 39.0.2167.5

Output from the troubleshooting page at http://test.webrtc.org:

[ RUN ] MicrophoneTest
[ OK ] getUserMedia succeeded.
[ OK ] Audio track exists with label=Default
[ OK ] Audio num channels=1
[ OK ] Audio sample rate=48000
[ OK ] Audio power=-25.60951604743385
[ ------ ]
[ RUN ] UdpConnectivityTest
[ OK ] Gathered candidate with type: relay address: 23.251.136.126
[ ------ ]
[ RUN ] TcpConnectivityTest
[ OK ] Gathered candidate with type: relay address: 192.158.30.23
[ ------ ]
[ RUN ] HasIpv6Test
[ FAILED ] Failed to gather specified candidates
[ ------ ]
[ RUN ] CamResolutionsTest

The second time I ran the test, I got a javascript error here:

        theResolution[0] + 'x' + theResolution[1] + ')');

I just ran into an issue where FF nightly (33.0a1 2014-06-15) refused to work with the datachannel sample. It turned out that it failed because the success/error callbacks to setLocalDescription are missing (they're not optional per spec).
See e.g. https://github.com/GoogleChrome/webrtc/blob/master/samples/web/content/datachannel/js/main.js#L119

This seems to be used quite often, do a
grep -r setLocalDescription * | grep ')'
in the content directory.

I'll see if I can provide a patch.

As per #73 discussion.

Sending a single message over channel takes a lot less time than sending two messages, for some reason.

Created issue to track webrtc issue 2876 (https://code.google.com/p/webrtc/issues/detail?id=2876).

Make a loopback apprtc call and then press hang up. You see below errors in console.

Uncaught TypeError: Cannot read property 'iceConnectionState' of null main.js:465
Uncaught TypeError: Cannot read property 'signalingState' of null main.js:460

@hkjellander
output:
414. That’s an error.

The requested URL /p/chromium/issues/entry... is too large to process. That’s all we know.

URL:
https://code.google.com/p/chromium/issues/entry?comment=Browser%3A%20Chrome%2039.0.2166.2%0A%0AOutput%20from%20the%20troubleshooting%20page%20at%20http%3A%2F%2Ftest.webrtc.org%3A%0A%0A%5B%20RUN%20%20%20%20%5D%20MicrophoneTest%0A%5B%20%20%20%20%20OK%20%5D%20getUserMedia%20succeeded.%0A%5B%20%20%20%20%20OK%20%5D%20Audio%20track%20exists%20with%20label%3DDefault%0A%5B%20%20%20%20%20OK%20%5D%20Audio%20num%20channels%3D1%0A%5B%20%20%20%20%20OK%20%5D%20Audio%20sample%20rate%3D44100%0A%5B%20%20%20%20%20OK%20%5D%20Audio%20power%3D-Infinity%0A%5B%20------%20%5D%20%0A%5B%20RUN%20%20%20%20%5D%20UdpConnectivityTest%0A%5B%20%20%20%20%20OK%20%5D%20Gathered%20candidate%20with%20type%3A%20relay%20address%3A%20146.148.28.237%0A%5B%20------%20%5D%20%0A%5B%20RUN%20%20%20%20%5D%20TcpConnectivityTest%0A%5B%20%20%20%20%20OK%20%5D%20Gathered%20candidate%20with%20type%3A%20relay%20address%3A%2023.251.138.129%0A%5B%20------%20%5D%20%0A%5B%20RUN%20%20%20%20%5D%20HasIpv6Test%0A%5B%20%20%20%20%20OK%20%5D%20Gathered%20candidate%20with%20type%3A%20host%20address%3A%202620%3A%3A1043%3A9%3A943f%3Aaa0f%3Ae6ef%3A9595%0A%5B%20------%20%5D%20%0A%5B%20RUN%20%20%20%20%5D%20CamResolutionsTest%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(160x120)%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(320x180)%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(320x240)%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(640x360)%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(640x480)%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(768x576)%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(1024x576)%0A%5B%20%20%20INFO%20%5D%20Supported%20resolution%3A%20(1280x720)%0A%5B%20%20%20INFO%20%5D%20Resolution%20NOT%20supported%3A%20(1280x768)%0A%5B%20%20%20INFO%20%5D%20Resolution%20NOT%20supported%3A%20(1280x800)%0A%5B%20%20%20INFO%20%5D%20Resolution%20NOT%20supported%3A%20(1920x1080)%0A%5B%20%20%20INFO%20%5D%20Resolution%20NOT%20supported%3A%20(1920x1200)%0A%5B%20%20%20INFO%20%5D%20Resolution%20NOT%20supported%3A%20(3840x2160)%0A%5B%20%20%20INFO%20%5D%20Resolution%20NOT%20supported%3A%20(4096x2160)%0A%5B%20%20%20%20%20OK%20%5D%208%2F14%20resolutions%20supported.%0A%5B%20------%20%5D%20%0A%5B%20------%20%5D%20%0A%5B%20%20%20%20%20OK%20%5D%209%20out%20of%209%20tests%20passed%0A&labels=webrtc-troubleshooter%2CCr-Blink-WebRTC%2COS-Mac

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.

What steps will reproduce the problem?

1. Goto apprtc.appspot.com
2. Right click and select show controls
3. The control bar is hidden by waiting for someone to join.

What is the expected result?
should be visible

Sam do you want to grab this one?

Create a short guide for developers working on this repo.

• Use of GitHub: branches and forks.
• Use of JSHint: validation, use of .jshintrc, etc.
• HTML, CSS and JavaScript coding style (based on https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml).

Anything else?

Right now, the callee initiates the PeerConnection, which means during call setup, we need to wait for the caller to warm up the stack on their side. We should have the caller start the PeerConnection and let it idle until the callee connects.

can't download the code in zip

Steps to reproduce:

1. On mobile Chrome, navigate to https://kaptenjansson.github.io/webrtc/samples/web/content/manual-test/peer2peer/
2. Select "Request GetUserMedia"

Result: When viewing the test page in a mobile browser, the JavaScript debugging log does not appear. This normally appears on the left side of the page when viewing on desktop.

Expected: JavaScript debug information should appear for testing purposes.

The testrtc page needs to tear down the use of devices properly. Right now it hangs on to the video device after all tests have been executed.

Unclear if there is a Datastore wrapper than can do this automatically or if we need to do it by hand.

While accessing the page http://googlechrome.github.io/webrtc/samples/web/content/constraints/
and checking the details by connecting, it would be more useful if there are more of the informative texts(or explanatory texts) available for the constraints used and on what details and where to be checked

calls (successes and failures)

minutes

time to connect

Chrome is picky. We have implemented one of the first drafts on the constraints spec for resolutions. The minimum value for framerate should be set as minFrameRate.

Instead of having many getusermedia-xxxx samples, let's create a new subfolder called 'getusermedia' and move unprefixed versions underneath that dir. Same for 'peerconnection' and 'datachannel'.

'apprtc' and 'manual-test' can remain under 'content'.

Moving webrtc issue https://code.google.com/p/webrtc/issues/detail?id=2018 to github.

Fork constraints-and-stats.html to include googNoiseReduction, googNoiseSuppression, googEchoCancellation and googHighpassFilter as well.

AppRTC code should be updated to handle an ICE restart, e.g. should recover when someone switches networks.

Created issue for tracking remaining work for issue 2187 (https://code.google.com/p/webrtc/issues/detail?id=2187).

Ronghua knows the details on e2e. RTT can be obtained from connection.googRtt

1. Login to the http://kaptenjansson.github.io/webrtc/samples/web/content/manual-test/peer2peer/
2. Under Peer Connection section enter the Server info into the box next to the 'Signal server[?]:' and click on Connect next to the 'Peer ID'

Expected Result:
The alignment should not change

Actual Result:
The alignment changes as seen in the screen shot. This happens only when the details are entered and clicked on 'Connect'

I propose moving all manual WebRTC manual test pages in the chromium repo to github for more exposure and make it easier for people to contribute.

Main page currently used for manual testing is peerconnection.html which we should rename (including sub pages and javascript). It also uses adapter.js for polyfill and stylesheet.css for page layout.
http://src.chromium.org/chrome/trunk/src/chrome/test/data/webrtc/manual/

To do prior moving:

1. Catch actual error in RTCpeerconnection and callAnswer/Offer callbacks - In progress
2. Make sure it's compatible with Firefox - It currently works if you add the AV streams on both sides prior negotiating SDP, i.e. SDP renegotiation is not supported in FF yet (29)).
3. Rename peerconnection.html and peerconnection_manual.js (and belonging sub pages) - Need a new naming convention: webrtc_manual_test, webrtc_browser_api_test ? Suggestions are welcome (rather wanted ;))
4. Decide if we should import the pages to chromium repo after the move or just leave a readme pointing to github?

To do after moving:

1. Refactor the peerconnection_manual.js to make the code clearer and easier to work with.

What steps will reproduce the problem?

1. Browse to http://googlechrome.github.io/webrtc/samples/web/content/dtmf/
2. click Call and accept GUM request

What is the expected result?
Be able to establish a call and send DTMF tones.

What do you see instead?
The page at googlechrome.github.io says:
This demo requires the RTCPeerConnection method createDTMFSender() which is not support by this browser.

Moving issue 1380 (https://code.google.com/p/webrtc/issues/detail?id=1380) to github.

Currently in progress and is served at kaptenjansson.github.io/webrtc/samples/web/content/manual-test/peer2peer/.

Created issue to track webrtc issue 2875 (https://code.google.com/p/webrtc/issues/detail?id=2875)

adapter.js is being currently used in a lot of pages, but this require to use a (probably outdated) local copy, or use some tricks like RawGit. A better solution would be to publish it on Bower, that's as easy as add a bower.json file and register it's location, and it will be updated automatically.

All of the links in the README, which are also the links that can be found at http://googlechrome.github.io/webrtc/, do not work. They lead to a 404 error page like this: http://googlechrome.github.io/webrtc/samples/web/content/getusermedia/

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.

Because of http://crbug.com/374263, we can't use recent Mac chromium builds to bisect issues on apprtc. In particular, during the gUM call, the adapter.js line that tries to parse the version id fails, which, in turn, causes the gUM call to fail.

One suggestion by Niklas is to change adapter.js to assume latest version when the info is not available.

Thoughts?

See issue 2128 (https://code.google.com/p/webrtc/issues/detail?id=2128) for details.

I noticed that after a lot of attempts this demo still not working on chrome but it's working fine with firefox, and don't understand why!
In chrome i just see a black screen.
(Tried both in local and in remote official demo)

I would like to be able to automatically push master to AppRTC prod, instead of having to use appcfg.
See https://developers.google.com/cloud/devtools/repo/push-to-deploy.