JUSTIN UBERTI: So what you all
think of the Google Glass Hangout this morning? [AUDIENCE CHEERING] JUSTIN UBERTI: What an amazing
way to show off the power of real-time communication. When I first heard about it,
they're going to jump out of an airship and have it all in a
Hangout, I was like, that's pretty incredible. But anyway, I'm Justin Uberti. And today, I'd like to tell
you all about WebRTC, a project to bring real-time
communication-- RTC-- to the open web platform. So I currently work on the
WebRTC team here at Google, which is part of the
Chrome project. Before joining WebRTC, I was
the lead in the Google Talk team, where we built some really
exciting applications, and also learned a lot of really
hard lessons about what it takes to do these kinds
of apps in a browser. I also kind of learned that some
people on the internet think I have really
small hands. I don't get it. So enough about me. Let me see what kind of
developers we have in the audience today. Raise your hand if you're
really familiar with the following technologies. WebRTC? OK. HTML5? Good. WebSockets? App Engine? SIP? OK. H 323? OK. You folks who raised your
hands, you have my condolences. So what exactly is WebRTC? Well, let me tell you
a little story. A couple years ago, when we
are working on what would become Hangouts, the Chrome
team approached us. And they said, the open web
platform has some amazing technology. And people are building
incredible apps with it. But there's one big
gap remaining. To build apps like Google Video
Chat, you need plugins. And these plugins have all sorts
of problems, security, everything. What would it take to take the
stuff you built for Google Video Chat and Hangouts,
and make it part of the open web platform? Well, we said, it would
be really complicated. I mean, we'd have all
these technology issues to figure out. And we'd have to deal
with like codec licensing, and open sourcing. And most of all, we'd have to
work with other browser manufacturers and other industry
players to make an actual standard for something
that can be implemented across all browsers and across
the entire web. And so in typical Google
fashion, the response we got back was, sounds like a plan. When can we have it? So we got to work. Where we didn't have the right
technology pieces in house, we went out and we acquired state
of the art, the very best technology out there. We assembled these pieces
into a system. And as we started talking to
other people, and we talked to other browser manufacturers,
Firefox, Opera, Microsoft. We talked to people who would
build apps on this platform, people like Skype, people
like Cisco. And we talked to the typical
telecom providers, folks like Ericsson, AT&T. They were all super excited
about this because it's potential, not just for the
web, but for the entire communications industry. So that's the premise of WebRTC,
RTC to build real-time communications into the fabric
of the web, where every browser has a built in, state
of the art communication stack, and create a new open
platform that any application and any device can use
to communicate. So think about that. This is where we're having,
the ability to get the communications industry-- a $2 trillion industry-- moving at web speed. And not only will the developers
be able to build and deploy voice and video apps,
just like any other web app, but we'll also start to see
communication being built in as a feature to all
sorts of apps. In a game, the ability to see
the opponent's face right as you checkmate them. Or in customer service on a
website, a shopping website, to be able to talk to a customer
service rep live in person with a single click. As WebRTC takes hold across
computers and all sorts of devices, we have the real
ability to create the next generation phone network, where
every WebRTC enabled device can communicate
with amazing audio and video quality. So take this quote
from NoJitter. This is a communications
industry blog. "WebRTC and HTML5 could enable
the same transformation for real time that the original
browser did for information." That's a pretty lofty
comparison. So how do we get there? Well first, we need to get
WebRTC in the hands of you, the developers. And here's where we're
at with that. The first WebRTC support is now
shipping in Chrome 21, the current Chrome Dev track. And also in Opera 12. We're expecting to have Firefox
join us before the end of the year. We've also brought WebRTC
support to Internet Explorer via ChromeFrame. And so we'll soon have
support across almost all desktop browsers. As this technology stabilizes,
we're also going to see web WebRTC start to appear in the
various mobile browsers. And for those building native
applications, either on desktop or mobile, we have
native versions of the WebRTC stack that are fully compatible
with their web counterparts. So the functionality the WebRTC
offers falls into three categories. The first, MediaStreams, also
known as get user media, is about getting access to the
user's camera and mic. There are a lot of cool
apps that can be built with just this. Next the technology called
PeerConnection. This is the engine behind making
high quality peer to peer voice and video
calls on the web. Last is a new bit of
functionality called DataChannels. It's so new, the spec for this
hasn't fully stabilized yet. But it has incredible
potential. The ability for any web app to
be a P2P app, to exchange application data peer to peer. Now let's take a look at
each one of these. Now, if you're following along
at home, and you want to try out the things about the show,
and you're running Chrome, you want to turn on the flags to
enable MediaStreams and PeerConnection. If you go to About Flags in your
Chrome build, you'll see these options in a list. And you turn on MediaStream
and PeerConnection. In the Dev channel on Chrome
21, you won't see a MediaStream option, because
it's now on by default. And if you don't want to turn
this on for your existing version of Chrome, you can
download Google Chrome Canary and run it side by
side with your existing version of Chrome. So first up, MediaStreams. A MediaStream represents a media
source, and can contain multiple media tracks that
can be of various types. So for example, if we get a
MediaStream for the user's webcam and mic, we'll have a
single stream, but a track for video, and a track for audio, as
shown in the diagram here. Now, in a video conference,
we could have multiple MediaStreams. And one MediaStream would exist
for each participant, each one with an audio
and video track. Now, once we have a MediaStream
we need a way to actually play it out. And fortunately, we have an
easy way to play audio and video in HTML via
the aptly named, audio and video elements. Now, in order to plug a
MediaStream into these elements, we first need a way
to get a URL that references the MediaStream. Fortunately, there's a method
called create object URL that does just that. Plug that URL into a tag, and
then media will start to play. Now lastly, how do we get
the MediaStream for the webcam and mic? So there's a new API called
getUserMedia. In Chrome, it's prefixed
as WebKit getUserMedia. And the API is async. So you call it, it prompts the
user for permission to access their devices. We spend a lot of time worrying about privacy and security. And that gives you back a
MediaStream via callback once it's successful. So here's that all
put together. Get user media, get a callback,
create URL, stuff it in a video tag. So let's see that in action. So here we get prompted
for our camera. I'll pick my good camera
right here. And there it is. Webcam access right
in the browser. Pretty cool. So now let's jazz it
up a little bit. So the first thing that
everybody does with getUserMedia is to make
a Photo Booth app. And we're not going to
be any exception. So let's add a button so that we
can draw the current video frame directly onto a campus,
just like a camera. So let's try that out. So here's our next sample. Get prompted. This time I'm going to tell it
to remember it, so I don't want you to do this again. OK, and so give a big thumbs
up for the camera here. And there's our Photo Booth. So of course, all good Photo
Booths need some sort of video effects. The web platform gives us some
great tools to do this. With CSS, we can apply a style
to any visual element, like a video tag or a canvas. So here, we can apply a black
and white effect, this built in webkit gray scale CSS. And so when the button is
clicked, we're going to apply that CSS class to the
video element. So I've made a demo. And I've got a couple more
effects in here. So let me show them
to you now. So I start up. And since I've remembered the
preference, it doesn't need to prompt me again. So let me try, we got
sepia tone here. And let's see, there's blur. And there's black and white. And I like black and white,
it looks real serious. So there's a lot of cool
stuff you can do just with these things. Now, that's what you can do
with a few lines of code. But I want to show you now
a complete Photo Booth application that uses
this technology. And the app I'm about to show
you is called Webcam Toy. And it's written by a guy named
Paul Neave, who got involved with WebRTC in the
very, very beginning. And so this thing uses Canvas
and WebGL pixel shaders to do some really amazing effects. There's over 100 effects
in this app. So there's some really
cool ones. Like, let me show you. This one's one of my
favorites here. Snow, it comes down and it sort
of builds up and stuff. And you can kind of clear
it off and stuff. It's really cool. And let's see, what else? The sketch one, this is also
one of my favorites. But what I really want to do is
I'm going to take a picture this room so I can remember
this moment here. All right, what's
a good effect? I like this one. [CAMERA SHUTTER SOUND] JUSTIN UBERTI: All right,
immortalized forever. OK, so one other thing that Paul
has done, though, is he's wired getUserMedia to do
real-time face recognition in JavaScript. So here we have real-time face
detection running in JavaScript. Now, I never thought I would
be saying those words. But here it is, as long as
I look at the camera. So this kind of gives
a new meaning to Chrome's incognito mode. So as you can see, some amazing
things are possible when we combine WebRTC with the
rest of the web platform. OK, so that's how we get
access to devices. Now PeerConnection Connection
will let us take those MediaStreams and send
them across the internet peer to peer. So PeerConnection, as its name
indicates, is the API they use to set up peer to
peer sessions. And it handles all the tricky
parts you need to establish a connection and run audio/video
over it, establishing the P2P link, managing the various
audio and video codecs, encryption, tuning the
audio/video stream to make best use of the available
bandwidth. But before we get into how
PeerConnection works, let's take a look at a typical voice
video application. I have Google Talk, let's
set up a call. So the app wants to be able to
send the media directly to the other side. But in order to do so, it needs
to establish the direct link and the details of how
the media should be sent. And the way it does that is sort
of by randevuing through the cloud by sending signaling
messages over its connection using a protocol like
XMPP or SIP. And these messages are relayed
to the other side. This exchange of parameters
allows both sides to successfully randevu and
establish the call. Now, what we could have just
taken that logic and stuffed it into the browser. The app would just tell the
browser where to connect to and to establish a SIP or XMPP
connection, just like a desktop app. But this isn't my makes sense
for a couple reasons. The app already has
a connection to the cloud using HTTP. And if we bake the signaling
protocol into the browser, we'd have to pick one that
everybody could agree on. That doesn't seem too likely,
given the various apps that are out there. And lastly, this connection
would have to deal with all the proxy and Firewall issues
that HTTP has already solved. So we didn't do this. What did we do? So we have an approach
that's called JSEP-- JavaScript Session Establishment
Protocol. And we thought, let's
put the minimum we need into the browser. In 2012, that's peer to peer
networking, codecs, and encryption. And let the app do
all the rest. The app can manage all the call
setup, using whatever mechanism it wants. The app will simply tell the
browser about the parameters it wants to use for the call
using things we call session descriptions. As long as the app has some
way to exchange session descriptions with the other
side, it can do this any way that it wants to. So for example, we could use
App Engine and use XML HTTP Request to post the session
descriptions using an adjacent encoding to App Engine. And have App Engine deliver them
to the remote side using the App Engine channel API. Or we could actually implement
the SIP protocol in JavaScript, convert the session
descriptions to SIP messages and send them
to existing SIP equipment out there. And so there's a ton of existing
SIP equipment, the phone network, soft switches,
existing enterprise video conferencing equipment. And people are already using
this today to have SIP Interop with WebRTC without forcing
WebRTC to have SIP built in. So the abstract PeerConnection
API allows us to handle either of these cases, along with a
whole set of others that I haven't mentioned. Now, the basic thing that a
PeerConnection needs is in local session description,
which holds the local parameters for the call in the
remote session description, which indicates the
remote parameters. It also needs the transport
candidates, which are the IP addresses and ports that the
remote side is reachable at. Sometimes these are included
within the session description. Now, I'm going to walk through
a call setup, and show how these parameters
are exchanged. One thing to note, the initial
parameters sent by the caller specify everything that a
caller is capable of. And we call that an offer. The response from the callee,
which indicates the negotiated or selected parameters,
is called an answer. So here's the first thing. The app creates the local
session description, the offer, passes into the
PeerConnection API, and sends it to the remote side using
whatever mechanism it wants. The caller gets it and gives it
to the PeerConnection API as the remote description. Then, assuming that the callee
accepts the call, generates their own session description,
passes it into PeerConnection, and sends it back to the
caller as an answer. The caller gets that answer and
gives it to PeerConnection as a receive session
description. Now, at this point, the browser
has everything it needs to establish the call, the
local session description, the remote session description,
the transport candidates, the P2P link gets
established, and media flows. So let's look at what this
looks like in code. The caller creates a
PeerConnection, plugs a MediaStream into it, which it
got from the getUserMedia API via add stream. It then creates an offer, plugs
it in, and sends it off to the callee. When the callee gets it, over
here on the right, it creates a PeerConnection, stuffs in
the offer via set remote description, and then creates
its own session description as an answer that it can send
back to the caller. The caller then gets its answer
on the left, sets call set remote description with the
received answer, and the set up is complete. So let's see how this
looks like in code. We're going to do the
offer/answer dance here in a single web page with two
PeerConnections. Instead of sending these
messages across the internet, we're going to just stuff them
directly into the appropriate PeerConnection So let's
try this out. Still like this incognito
mode. OK. So we start up the camera. And now, when we hit the call
button, we're going to spin up all the codec, P2P, crypto,
all that sort of stuff. And we should see the video
appear in the panel on the right as what the remote
user would see. Bang, there it is. Now, let me show
you that again. I'm going to hang it
up and call again. And there it goes. So you'll see that we have
this functionality. And as long as it's sending
session descriptions back and forth, the rest of it pretty
much manages itself. Now, that's kind of cheating. You know, passing the data back
and forth in a single web page isn't really that
interesting from a video call scenario. We want to call someone on the
other side of the planet, not in the same web page. So how are we to do This Well,
in order to make this into a real video calling app, we need
to send those session descriptions across
the internet. Now, let's look at how
we can do that. So it's really easy
to send a session description to the cloud. We just make it into a string,
and shoot it off over XML HTTP Request. But how can we receive them? Especially when this is a
real-time application. The caller doesn't want
to sit there forever waiting for the callee. We don't want to spend a
lot of time polling. What can we do? Well, App Engine gives us
a great tool for this. The Channel API provides an easy
to use, server to client signaling path for pushing
session descriptions from the server to the client. And App Engine takes care
of all the details. No matter how many users you
have, or where users are in the world, you can use
the same simple API to send down messages. So here's how it works. The first thing you do is
establish a channel. You can do this when serving
the web page to eliminate a round trip. So in the server, you simply
create a Channel API token and send it down in the
web page response. The app then uses the JavaScript
API with that token to bring up the back channel,
and you're ready to rock. You can send messages
from your server down to your client. So here we have Client B that
wants to send a message and link the session description
to Client A. It does so typically [? in the ?] POST using XML HTTP
Request to get the message up to App Engine. And then it codes an identifier
to indicate who it should be sent to. Now, your app can use the
identifier to find the right channel instance on
the server side. And once it does that, you
simply call [? send ?] the channel. And it gets pushed down to
Client A who receives it in a JavaScript callback,
super easy. So here's a snippet that shows
how this all works. At the top, the client brings up
the back channel using the App Engine API. Then, when it gets an incoming
call message in its callback, we can set the remote and local
descriptions, create an answer, and then shoot
that back using XHR. So these are some great little
examples to sort of show the basics of the API. But we also want to have a
complete video calling application, a reference sample
application, where we can show developers the
best ways to bring this stuff all together. And we also want it to be the
kind of application that we can use in our daily work, not
just a sample app, something that will be a full-fledged
reference application. So we created AppRTC. It runs on App Engine using
things like Channel API and Data Store, and shows how to use
the WebRTC APIs, handling session descriptions, making
call setup fast, and showing NAT Traversal works. And every AppRTC call
is fully encrypted. Now, I really want to
show this to you. So we've got some people
on the team. And they've been working
really hard on some updates to AppRTC. Now, I want to just sort of
check in with them real quick and make sure that they're not
getting too stressed out. So let's do that now. OK. Hey, Ray. You look pretty relaxed there. Did you get that work done
I wanted you to do? RAY: Yep, yep, sure did. WebRTC and App Engine
took care of the most complicated stuff. So I'm done, Justin. JUSTIN UBERTI: Well, I mean,
let me say, it looks great. I mean, not just the app,
but also your pool. You know, I wish I could
swing by later. Anyway, I've got to get
back to the session. It's going great. And I'll let you get
back to relaxing. Catch you later, Ray. RAY: See you, Justin. [APPLAUSE] JUSTIN UBERTI: So that's the
kind of quality that you can accomplish with WebRTC. Real calls across the
internet, right from your web browser. OK, so we just showed how
to send audio and video peer to peer. But what if we just
want to send data? Well, enter DataChannels. So DataChannels designed to
allow apps to exchange arbitrary application data
with low latency, high throughput and message rate,
and optionally unreliable semantics so you keep
chugging, even if you lose a packet. Now, there are lots of great
real world use cases that DataChannels are great for. If you have a game, and you want
to send the positions of bullets in a game, you don't
want to send that data over HTTP, to the server and back
with all the HTTP overhead. You can instead send it in a
very tight, efficient message over the peer to peer channel. For remote desktop apps, you can
do things like track the position of the mouse with
great responsiveness. And there's a lot of other
great examples. But one I particularly like
is the ability to create a secure, decentralized network. And you can imagine, in a place
were there's censorship of the internet, you could
provide this mechanism as a way where people can communicate
over a private encrypted channel. So here are the key features
of the DataChannel. To set it up, we're going
to leverage the PeerConnection setup. You do this sort of offer/answer
dance. We'll get the channel
bootstrapped. But then you can create
multiple channels. And those channels can all be
either reliable or unreliable. In a game, you might want your
state updates to be reliable, but projectiles can be sent over
an unreliable channel. Security and congestion control
is built right in. The app gets this for free. And we've tried to make
developers lives easier by keeping a similar API
to WebSockets. So that code written to use a
WebSocket should work just as well when coupled with
a DataChannel. So here's a simple usage
of DataChannels. We want to have two clients
exchanging data. They exchange session
descriptions to get the peer to peer link set up. And then, we're ready to go. We send the data. And it gets sent over the
internet using standard IETF protocols, SCTP, Datagram
TLS over UDP. It goes through a [? NAS ?],
it just works. This is going to be a
revolutionary technology. And here's what this
looks like in code. It's really simple. You just call on each side,
create DataChannel, you specify an identifier. This identifier is what allows
both channels to get connected together in the middle because
they're indicated by name. And then, once it's connected,
you just call/send on one side. And our message gets called on
the other side, just like WebSockets. Now, I wish I could show
this to you now. But as I mentioned before, we're
still finishing up the details of the spec. But expect to see this in Chrome
in the near future. So you can also imagine
some more complicated topologies for this. If we want to distribute data
between multiple peers, we can create a mesh, where each
endpoint is connected to each other endpoint. If you're creating like a
multiplayer game, this is a really easy way to get
multiplayer functionality without having to have a big
server infrastructure. But you can also imagine some
other interesting things. You create a graph. And say you want to be able to
send down a lot of data from your service. Instead of having to send the
data n times by unicasting it to all your clients, you can
instead construct a tree, and use peer to peer to push the
data very efficient to all your clients. Since you control the
application, you can have the application take the data and
it's distributed to other peers that it might
be connected to. There will be some amazing
things that will be created as a result of this technology. OK, so we went over a lot
of stuff really quickly. Let's review. We're building real-time
communication into the fabric of the web, providing amazing
new voice, video, and peer to peer functionality in the open
web platform, and enabling the communications industry
to move at web speed. This is a really
exciting time. We're really excited
on the team. We can't wait to see the
apps you guys are going to build on this. So MediaStreams are shipping
in Chrome 21. PeerConnection is in Chrome
20 behind a flag. But we're working hard to
try to stabilize it in time for Chrome 22. The DataChannel works is going
to follow along after that. And we expect to do this
by the end of the year. Opera is also shipping
MediaStreams now. And our friends at Mozilla, they
tell us they think that they get all this stuff done
by the end of the year. Now, for people using Internet
Explorer, we've got WebRTC running in ChromeFrame. And it works great. As we start to stabilize things,
we're also going to see stuff landing in
mobile browsers. And as I mentioned before, we
have native versions of the entire stack available for the
app builders out there. So here's our resident Icelandic
team member, Tommy Gunnarsson. He's showing off AppRTC running
here in IE, courtesy of ChromeFrame. So for more information about
ChromeFrame you check it out at google.com/chromeframe. Now, incidentally, we might
be thinking, well what is Microsoft doing about
supporting this natively in IE? Well, I don't know for sure. But I saw a couple of WebRTC
related job postings show up on the Microsoft career
site in the past week. So I'm pretty sure
they're investing pretty heavily in this. OK, so I'd like to show you
one more demo, or two more demos here of examples of what
third-party developers are doing with this technology. So the first is an application
called Twinsee. The team there has created a
WebRTC app that works on both web and on mobile. And I'm going to call them
up now using the app that they've built. MALE SPEAKER: Hello. JUSTIN UBERTI: Hey, guys. You're live at Google
I/O 2012. MALE SPEAKER: Wow. JUSTIN UBERTI: So tell me
about this app that you've built. . MALE SPEAKER: OK so let me
introduce ourselves. So I'm [? Michel Gien, ?] and I'm here with
[? Christian Giacomo. ?] And we founded Twinlife at the
beginning of this year. And the purpose of Twinlife
is connecting generations. So our focus right now is to
take Android tablets and smart TVs and make them usable by
older persons, so they can interact with their family,
their children and grandchildren. So our first building block is
this Twinsee service, which is made of an Android application,
using at the native WebRTC APIs,
which Christian integrated into Android. And web service, twinsee.net, to
connect users, whether they come from a Chrome browser, or
whether they come from a Twinsee application
on Android tablet. JUSTIN UBERTI: That's great. It feels like you guys
are right here in San Francisco with us. So when can I expect this
to be available? MALE SPEAKER: Twinsee will be
available for public testing on the Android Market in
the August time frame. So I'll show you here
in the mirror. You can see that this
tablet we're using right now is Asus Prime. And so if you have any
questions, contact us at twinsee.net. JUSTIN UBERTI: OK, that
looks great, guys. MALE SPEAKER: I hope you're have
at Google I/O. I wish we were there. JUSTIN UBERTI: Looks
great, guys. Well, that's really exciting. I'll let you guys
get some sleep. Talk to you later. [APPLAUSE] JUSTIN UBERTI: OK. So the last thing I want to
show, I know a ton of you are using GitHub to host and
share your code. So that's why I'm really excited
to introduce this next app called GitTogether, which
brings real-time communication to the GitHub community. Now, the guys who built this
have been involved with WebRTC since the very beginning. Let's call them up now. And they can tell you about
how this works. These guys have been
working on this. They're creating not just an
application, but also a JavaScript framework that
allows a lot of simplifications to be done
for people who are WebRTC developers. So that's everything for
WebRTC see today. We covered a lot of
stuff quickly. [APPLAUSE] JUSTIN UBERTI: Thank you. Oh, also, the GitTogether
is made by vline.com. Also, check out the Chrome
Developer sandbox. We've got some stuff
down there. There's a Voxeo, who is an
emergency response app being built using WebRTC. And we've also got a really
cool WebRTC based game called Who Am I? MIT Thank you all for coming. I'll be happy to answer any
questions that you might have. Step up to the microphone, so
the video can record it. AUDIENCE: In a lot of your
slides, you had a dotted line between the two browsers
on the bottom. Is that an actual connection
somehow. I mean, if both of them are
behind a net firewall, how do you get the peer to peer
communication to go? Is there actually a server
there that's-- JUSTIN UBERTI: So there's
a technology called ICE. And ICE is Interactive
Connectivity Establishment. And what it does is it basically
finds all the IP addresses that it can come up,
your local address, the address of your NAT or firewall,
or an address that could be hosted in
a data center. And it does interactive checks
to figure out what is the best path between the two peers
to establish data. In our experience with Google
Talk, we find that in about 90% of the cases, we can
actually establish a peer to peer link, even if both
sides are behind NAT. The rules of NAT are such that
if we know the address of the other person's NAT, we can still
get that peer to peer link going between two
peers using UDP. AUDIENCE: Thanks. AUDIENCE: Hi. Can you talk about
codec support? Because I know you guys have
acquired GIPS, and with that came iLBC and iSAC. But are you going to do
something like Opus support, or something like that? JUSTIN UBERTI: So this is all
a big topic for the IETF. But what we are planning
support, assuming we can work out all the licensing details,
VP8 will be our open, royalty free video codec. And then, as far as all your
codecs are concerned, we'll support G.711 for legacy
interoperability. We'll support iSAC. And we hope to support Opus,
assuming that Microsoft can help us out in the
licensing front. AUDIENCE: And can you talk about
iLBC voice quality on an Android platform? Have you guys had good
luck with it? I mean, are you seeing good
performance relative to a general cell phone call? JUSTIN UBERTI: We have the
person who wrote iLBC here sitting in the audience. AUDIENCE: That guy,
right there? JUSTIN UBERTI: Yeah, that guy. AUDIENCE: OK, I'll
talk to him. Thank you. AUDIENCE: Hi. Simple question, I saw on the
first demo that you showed how to use video. Well, you didn't show about
audio, but I guess audio is also included. Only on one to one conversation,
is there a way to make it broadcast? For example, this show can be
seen on the web page by multiple users? JUSTIN UBERTI: Yeah, so a
PeerConnection creates a connection between yourself
and a remote peer. And if you want to have a
multi-way conversation, there's a couple ways
you can do this. The first thing is you could
have multiple PeerConnections and establish a full mesh,
like I show here. If you have four participants,
you establish three PeerConnections, one of each
remote participant. This doesn't scale
all the way up. So one of the other things that
you can do as you get to be in a large conference, is
actually have a central server and create like a star topology,
where the other side, instead of being a
browser, is actually a server. And then using the WebRTC tools,
you can create a server that could do multi-party. AUDIENCE: OK, I think maybe
I asked you wrongly. I'm only interested one party
who is transmitting. The other ones don't need
to talk, only to listen. So it's like UDP
in that sense. JUSTIN UBERTI: Right, right. Sorry. In that case, the other side
wouldn't even have to call getUserMedia. So the side who calls
getUserMedia can specify whether it wants video
and/or audio. But you won't need to call
getUserMedia at all. So if you want to receive only,
you just would not call getUserMedia, and you wouldn't
call AddStream on that side. And then you would just play. AUDIENCE: I see. OK, thank you. JUSTIN UBERTI: Sure. AUDIENCE: So if you want to
stream to the server and save the recorded video, are there
components or libraries that are available? JUSTIN UBERTI: So I mean, if
you're familiar with media processing, you can build these
kind of servers using the WebRTC components. There is something in the WebRTC
spec for an API called Media Recorder. It's missing a lot of
detail right now. So it's not being implemented. But we expect, at some point in
time, there will be an easy way to do media recording. For right now, the easiest way
is to build a server, make a PeerConnection to it. And then you can then save
it out to a file there. AUDIENCE: So the component would
be the C++ libraries that you would bind
into your server? JUSTIN UBERTI: Yes. AUDIENCE: I had a question about
whether Screen Sharing is still in consideration
as a video source? JUSTIN UBERTI: It
absolutely is. The question is whether Screen
Sharing will be supported as a video source. And it's sort of one of these
things where we definitely want to support it, we have
the technology to do it. But in terms of making sure we
get something out there, v1 will be just video only. AUDIENCE: [INAUDIBLE]. JUSTIN UBERTI: You could also
do it with camera drivers. Although, the issue with camera
drivers is that their resolution will be artificially
limited. AUDIENCE: Do you have
plans to integrate with Server-Sent Events? JUSTIN UBERTI: Server-Sent
Events. Are you specific about what
you have in mind there? AUDIENCE: Well, to get the
session exchange pushed back the answer. JUSTIN UBERTI: I think I'll have
to get back you on that. I'm not sure I'm familiar
enough with the Server-Sent Events. AUDIENCE: They're part of the
[INAUDIBLE] working group specifications. JUSTIN UBERTI: We can
talk afterwards. AUDIENCE: Hi. There will be any SIP
integration in the future? Any way to make a phone
call using these API? JUSTIN UBERTI: Yeah, so we
actually have some demos-- I didn't show them today-- where you can actually make
a phone call to the PSTN. And there's a couple
ways you can do it. You can send JSON to your web
server, and have the web server then gateway
that to SIP. Or there's a product
called sipML5-- sipml5.org-- where they're actually
implementing a SIP stack within the browser itself. So it converts the session
descriptions to SIP messages right inside the web
application. So you can definitely do SIP
calls using this technology. AUDIENCE: Great. And there will be an SDK for
Android, or something? JUSTIN UBERTI: Yeah, we
have existing SDK. If you go to WebRTC.org, you
can download the code for running this on Android. AUDIENCE: Thank you very much. JUSTIN UBERTI: Sure. OK. Thank you all for coming. [APPLAUSE]
