webrtc don mcgregor research associate moves institute
DESCRIPTION
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 3TRANSCRIPT
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
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
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
WebRTC
• Which led to WebRTC, video and audio in web pages– W3C standard: http://www.w3.org/TR/webrtc/– IETF standard:
https://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
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
8
The Problems
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
10
Signaling
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
12
Overall
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
14
With Simulation
• DIS includes intercom PDUs, which enable voice communication between simulation participants. It should be possible to replicate this in the browser.
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.
16
ExamplePeerjs server (in cloud)
1. Peer: register a name,“mv3500”
2. Peer: open default connection,Then request a DataConnectionTo “mv3500”
3. DataConnection Object(send, data() event handler)
WebrtcServer.htmlWebrtcClient.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/WebrtcDataChannel
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/getusermedia/intro/