Transcript WebRTCx - MOVES Institute

WebRTC
Don McGregor
Research Associate
MOVES Institute
[email protected]
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
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
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
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-ietfrtcweb-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
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
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
The Problems
The Internet
192.168.1.11
192.168.1.10
NAT
NAT
Remember the rules for NAT? How do we establish a connection?
8
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
Signaling
10
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
Overall
12
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
With Simulation
• DIS includes intercom PDUs, which enable
voice communication between simulation
participants. It should be possible to
replicate this in the browser.
14
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
Example
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
16
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
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