WebRTC: Difference between revisions
No edit summary |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 15: | Line 15: | ||
===RTCPeerConnection=== | ===RTCPeerConnection=== | ||
The purpose of RTCPeerConnection is to negotiate a connection using the signalling channel (the Websocket forwarded through your nat). | |||
When you make an RTCPeerConnection, you should pass in a list of iceServers: | |||
<syntaxhighlight lang="javascript"> | |||
const configuration = {iceServers: [{urls: 'stun.l.google.com:19302'}]}; | |||
const pc = new RTCPeerConnection(configuration); | |||
</syntaxhighlight> | |||
There are two types of iceServers: | |||
* STUN servers are used to find the public IP and port of the client. | |||
** You can find a list of STUN servers [https://gist.github.com/mondain/b0ec1cf5f60ae726202e here]. | |||
* TURN servers are a fallback used to proxy data through the NAT. | |||
For each STUN server, you need to send it to the other peer via your signalling channel: | |||
<syntaxhighlight lang="javascript"> | |||
const configuration = {iceServers: [{urls: 'stuns:stun.example.org'}]}; | |||
</syntaxhighlight> | |||
The other client will add these as follows: | |||
<syntaxhighlight lang="javascript"> | |||
remoteConnection.addIceCandidate(e.candidate) | |||
</syntaxhighlight> | |||
Next the local and remote clients exchange descriptions: | |||
<syntaxhighlight lang="javascript"> | |||
const localOffer = await localConnection.createOffer(); | |||
localConnection.setLocalDescription(localOffer); | |||
signallingChannel.send(localConnection.localDescription) | |||
# On the remote | |||
const localOffer = signalingChannel.receiveAnswer(); // Actually a callback irl | |||
remoteConnection.setRemoteDescription(localOffer); | |||
const answer = await remoteConnection.createAnswer(); | |||
remoteConnection.setLocalDescription(answer); | |||
signallingChannel.send(remoteConnection.localDescription) | |||
# On the local | |||
const remoteDescription = signalingChannel.receiveAnswer(); | |||
localConnection.setRemoteDescription(remoteDescription); | |||
</syntaxhighlight> | |||
* Note that both clients can continue to update descriptions as the network updates. | |||
*: As long as the signalling is setup correctly, you don't need to worry about what RTCPeerConnection is doing under the hood. | |||
{{ hidden | RTCPeerConnection Example | | |||
Below is from [https://www.html5rocks.com/en/tutorials/webrtc/basics/ HTML5Rocks]. | Below is from [https://www.html5rocks.com/en/tutorials/webrtc/basics/ HTML5Rocks]. | ||
<syntaxhighlight lang="javascript"> | <syntaxhighlight lang="javascript"> | ||
| Line 84: | Line 128: | ||
}; | }; | ||
</syntaxhighlight> | </syntaxhighlight> | ||
}} | |||
===RTCDataChannel=== | ===RTCDataChannel=== | ||
| Line 114: | Line 159: | ||
==JavaScript API== | ==JavaScript API== | ||
===Multiple Clients=== | |||
To handle multiple clients, you simply have one RTCPeerConnection per client. | |||
==Native APIs (C++)== | ==Native APIs (C++)== | ||
| Line 119: | Line 166: | ||
==Resources== | ==Resources== | ||
* [https://www.html5rocks.com/en/tutorials/webrtc/basics/ HTML5Rocks: Getting Started with WebRTC (JS)] | * [https://www.html5rocks.com/en/tutorials/webrtc/basics/ HTML5Rocks: Getting Started with WebRTC (JS)] | ||
* [https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Simple_RTCDataChannel_sample MDN Simple RTCDataChannel sample] | |||
* [https://news.ycombinator.com/item?id=25933016 HackerNews: WebRTC is now a W3C and IETF standard] | |||
==References== | ==References== | ||