1. WebRTC Don McGregor Research Associate MOVES Institute mcgredo@nps.edu

2. UDP on the Web We’ve seen Websockets, which are essentially TCP sockets for javascript and the web page Required some server-side code (the DISMap application did this for you) On the client side (in the HTML page) you made some javascript calls to establish a websocket connection 2

3. UDP on the Web But TCP has well-known problems for networked virtual environments –Higher latency and jitter –If packets are dropped, must go through a timeout-resend cycle What we’d like is something like UDP, but in a web context Unfortunately, there’s no concept of broadcast or multicast in the web protocols, but we can replicate unicast UDP 3

4. Commerical Trends People want to do video and audio chat. This has many of the same data requirements as NVEs –Low latency, low jitter, ability to drop packets, poor performance with timeout-retry People want to do audio and video chat in the web page Because the web, and people don’t want to install a stand-alone application like Skype 4

5. WebRTC Which led to WebRTC, video and audio in web pages –W3C standard: http://www.w3.org/TR/webrtc/http://www.w3.org/TR/webrtc/ –IETF standard: https://tools.ietf.org/html/draft-ietf- rtcweb-overview-14https://tools.ietf.org/html/draft-ietf- rtcweb-overview-14 Chrome and Firefox support in current, released browsers https://www.mozilla.org/en-US/firefox/hello/ –(Initiate from Firefox, copy & paste URL in Chrome) –Max two people in one chat

6. WebRTC The thing is, WebRTC also provides an interface for sending general UDP packets We can use this interface to send general data packets (such as DIS) This gives us near-classic UDP, minus broadcast and multicast. The lack of this hurts scalability 6

7. WebRTC: Problems Firewalls and NAT. With websockets we connected over port 80/443 –Those ports are usually open –The client was almost always establishing a connection to a server, which works well with NAT and proxies With WebRTC, we may be connecting two hosts, each behind a NAT. This makes things much more complex than websockets 7

8. The Problems 8 NAT The Internet NAT Remember the rules for NAT? How do we establish a connection? 192.168.1.10 192.168.1.11

9. Signaling Basically, the two hosts can go to a rendezvous point outside, on the internet –Exchange information such as codecs to use, each other’s public IP and port, etc –Crypto key data, codecs, etc. Standards for this include STUN and TURN This is outside WebRTC proper There are some free servers that can be used for this, or you can set up your own 9

10. Signaling 10

11. Signaling Both clients connect to the “signaling server” Info about public IPs and ports is exchanged A direct session through each side’s NAT can then be established Within one one network, where there is no NAT to traverse, we still do this step. The Javascript inside the browser has very limited ability to contact anyone on the local network 11

12. Overall 12

13. Details The user has to confirm that the page can access the camera and mic. This is not necessary for the data channels Contact the signaling server to get a connection Establish data connection 13

14. With Simulation DIS includes intercom PDUs, which enable voice communication between simulation participants. It should be possible to replicate this in the browser. 14

15. Example This will use a peer.js NodeJS server as the signaling server. This is a small piece of code we can either run on the cloud or locally. The client web pages will connect to this server, rendezvous, exchange information, and then establish a direct p2p connection A lot of operations are being hidden here. Other frameworks do similar things in different ways. 15

16. Example 16 Peerjs server (in cloud) 1. Peer: register a name, “mv3500” 2. Peer: open default connection, Then request a DataConnection To “mv3500” 3. DataConnection Object (send, data() event handler) WebrtcServer.html WebrtcClient.html

17. Example This is a bit contrived. We are effectively using the “mv3500” id as a magic ID, and errors will occur if someone else tries to connect a peer object with that name In reality we could set up another server to distribute these IDs—allow a random ID to be created on the peerjs server, then have clients connect to a server where they can be retrieved See https://github.com/mcgredonps/WebrtcDataChann el 17

18. Media Capture Getting access to the laptop camera and mic can be done via W3C APIs. This is good, because it’s reasonably standard The web page will ask the user if he wants to allow this. It’s easy for the user to miss the request, and he may not be asked again http://www.html5rocks.com/en/tutorials/getu sermedia/intro/ 18