WebRTC PeerConnection Manual Test Help Page

The test page is intended for testing WebRTC calls. This is how you set up a normal call:

1. Open this page in two tabs.
2. Start the peerconnection server. Click on the question mark next to the 'server' field for instruction on how to do that. The easiest thing is to start it on localhost, but you can start it on any machine you like and connect to hostname:8888.
3. Click the Connect button in both tabs.
4. Click the Call:Negotiate button in one of the tabs. You should see a bunch of printouts when this happens. Note that no streams are sent to begin with (although you could run steps 5-6 before this step to get streams even in the initial call).
5. Grant media access using the checkboxes and Request button.
6. Add the local stream by clicking the "Add" button, in both tabs.
7. Now you must re-negotiate the call by clicking on Negotiate again.
8. You should now have a call up and both sides should be receiving media data (depending on what access you granted on the respective pages).
9. You can now choose to stop, re-request, re-send or disable streams in any way you like, or hang up and re-start the call. You don't need to disconnect: that's done automatically when you close the page. Hanging up is NOT done automatically though.

Detailed descriptions:

• Connect - once a connection is established, you generally won't need to click this button again. Connecting really isn't something related to WebRTC as such, it's just the signalling solution.
• Note that if more than two users/machines have established a connection to the same PC server, you will get an error when pressing this button. The test is hard-coded to only allow 2 peers on the server at the same time.
• Pressing the Add button for local streams will in effect add the current local stream, such as it is, to the current peerconnection.
• If you request user media again, it will overwrite the current local stream with the new one. This means that pressing Add will add the stream you just got from the request. The code will not attempt to stop or remove the previous stream from the peerconnection, so depending on peerconnection's semantics the old stream will remain with the peerconnection (perhaps the streams will be sent simultaneously?)
• Hang Up will clear away peer connections on both sides, and a new call can be started if desired. The peers remain connected to the peerconnection server.
• The Toggle buttons will set the .enabled properties on the first video and audio track for the local or remote stream, respectively. This is effectively a temporary "mute" for the streams.
• Stop terminates a stream, which means it will no longer send any more data.
• Remove will remove the current local stream from the current peerconnection. For instance, you should be able to send a stream, remove it, re-request a new stream and send that within the same call. Note that re-requesting user media overwrites the current media stream, so the reverse is not possible.
• The PeerConnection constraints field can pass in constraints for the peerconnection to be established. The code will attempt to eval the code you write in and pass it whenever the code asks for constraints. [experimental]
• The Force Opus checkbox will remove all codecs except OPUS for all outgoing messages sent by this page. Note that this ONLY means that we are guaranteed to send Opus to the other side; it does NOT mean that the other side will necessarily send Opus to us. To do that, you need to check the box on the other side too. You can either check the box before the call, or check the box and then re-send the local stream.