Google I/O 2012 - WebRTC: HTML5でのリアルタイムオーディオ/ビデオとP2P (Google I/O 2012 - WebRTC: Real-time Audio/Video and P2P in HTML5)

字幕表動画を再生する

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]