[MUSIC PLAYING] CHAD HART: Thanks, [INAUDIBLE]. As [INAUDIBLE] mentioned,
my name is Chad Hart. About three years ago I
started up a blog largely to help me make
some notes and meet some of the other
technical people inside WebRTC, called
"WebRTC Hacks." And that's really got me much,
much more into the industry. Today I'm going to talk
about servers for WebRTC. So German touched
on part of that in the previous presentation. There was a lot
of questions here that were very server specific. I hope I'll answer some of them. Probably not all of
them, but certainly some. So as German started out,
usually when you see WebRTC, you hear about it, it's
peer-to-peer, right? And you can send
VoIP peer-to-peer. And there's a lot of focus on
the browser and the browser and a browser in a mobile app. And then you usually
see some sort of diagram like this that shows just the
signaling stuff down there. And I always like starting out-- I was always very kind of scared
of like, what's going on here? I knew how to program in the
browser and do JavaScript. But the server
side stuff is hard. So, I can say the
server side stuff, it doesn't have to be that hard. It can be in some situations. But definitely getting going,
it shouldn't scare you off. And I'm going to
walk through some of those aspects
during this talk here. So, if you go into more detail-- and this is actually from
the W3C WebRTC spec-- there's actually a
lot of elements here. It's not just two
little browsers, right? And a bunch of these are
the actual servers here. And I'm going to explain
what these things are. There's four main types
of servers in WebRTC. There's signaling, which
basically you always need. There's NAT traversal. And I'll spend
some time on this. This is really
important, especially for production environments. I mean realistically,
you probably should have this in your
application development environment, but there's
different levels you can do. Media servers and
gateways, they're really application
dependent, depending on what you want to do. And we'll discuss some of
those applications in a moment. So let's start out right
away from signaling. And I think as you've
discovered now, WebRTC is not just peer-to-peer. You need to have this
signaling server. WebRTC's peer-to-peer for
media, but WebRTC is not peer-to-peer for signaling. And why do you need signaling? We just talked a
moment about this thing called Session
Description Protocol. I can say I spent many, many
hours, with help from experts, trying to build
an SDP guide here. It's a very, very complex thing. But it's important
because SDP basically defines the capabilities
and permissions of what one one side-- what one browser can handle. And it needs to share that
and negotiate that information with the other browser. So all that information is
encapsulated inside SDP. And while it's possible
to manipulate SDP-- and there's a lot,
actually, of use cases where you might want
to do that today. Most of those are more
advanced use cases. And certainly if you're
just starting out, you really don't need
to worry about SDP, and the contents of SDP. What you do need to
worry about though is, how do you get SDP from one
browser to another browser, or from one of your
clients to another client? And that's what
signaling is all about. It's about transferring
that SDP from one browser to the other browser. So one of my favorite
ways to illustrate this is actually using one
of the official GitHub-- or one of the official
Google sources on GitHub. Here, I'll just
load up my browser. And I like this because it
walks through the process that you saw Herman present
just previously, step by step. So we start by
getting the media. That's our get user
media CR screen here. We create a peer connection. And this next step
is really where the signaling part comes in. We're going to create an offer. And you can actually see
that actual offer down here. Again, this is just for
Illustrative purposes. If you're doing more
advanced situations, you can actually go in and
edit this and change this. If you want to prioritize
certain codecs or capabilities or remove certain types
of network connections, you can do all that. There's other ways to do it too,
but that's available to you. So then we're going
to set our offer. Then we're going to
go to the other side. We're going to create an answer. We're going to send our answer. And now here, we're connected So this seems like there's
lots to the process, when you see that first. But really, if you just go
through some of the examples, you can see, in reality,
there's not as much going on as you might think. There's a lot of things that go
on that are automated and taken care of for you as
part of the APIs. So the next step
is, OK, you need to send this SDP from one
browser to another browser. How do you do that? You need to have
some sort of server. You need to have something
that transfers that. And the reality is, the
server could really almost be everything. There's actually a
spec written that says that sending WebRTC
via avian carrier, which means a bird, a pigeon,
a passenger pigeon. Because in theory--
it doesn't actually work with most browsers. But you could actually
send this SDP, stick it on a carrier pigeon,
send them off, and then take that SDP and interpret it. People like fippo
have gone so far as to reduce that SDP down so
you can send it with a tweet, or close to it. But to create a
signalling server, it does not have
to be very complex. You just need something that
will pass that SDP from one side the other side. Last week we had a great
session in San Francisco focused on mobile. But actually as just a
kind of an introduction in one of the slides
from one of our sponsors, TokBox there, Cesar Guirao put
together just a really simple 32 line signalling server here. And as you see on
the screen, this is actually all you need for
a lot of applications here. And all this is doing
is just taking-- you can see a message
from one client, takes it, and broadcasts
and sends it out to all the other clients. So not to glance
over signaling-- it can get pretty complex-- but actually most of
the issues of signaling don't really have
to do with WebRTC. Most of the other issues
are general elements that you need to deal
with with your application in the first place. So you need to find, who can
actually create a session? Who's allowed to use the system? You've got user authentication. To what level, what degrees
were they allowed to do? What controls do they have? There's security
and access controls. If you're dealing with
mobile environments and you don't want
to kill your battery and you don't want your
signaling to be too chatty and keeping your phone on,
keeping the network awake the whole time, you need to
think about things like push notification services. One aspect that I will say
can get very difficult, especially as you get into
large scale production dealing with millions, tens of millions,
hundreds of millions, is scale. Daniel Petersson later on today
has a really great presentation that will talk through a lot
of the aspects of scaling out a service. So he'll spend a lot
more time on that topic. And in general, there's
a lot of other things that your application is doing
that you need to consider. And if you have a more
robust advanced application, odds are you have
some sort of signaling mechanism, some aspects there. So then the
challenge comes into, how do you map some of
those existing application capabilities into
what you need and what you want to do with WebRTC? So how do you get or
use a signaling server? One approach to getting
started with WebRTC is actually just go to a
communications platform as a service provider. Our sponsors Twilio and TokBox
are two examples of those. Since signaling is basically
a mandatory part of WebRTC, every CPaaS provider
has some sort of signaling built in
to their framework. But if you don't want
to do that, as I showed, it can be actually really
simple to run your own. And there's several frameworks
out there, some of them I've listed here, that can help
you get going really quickly, or help give you
some basic signaling. At the end of the day,
if you search on GitHub, you'll find dozens or hundreds
of potential signaling options and different ways to do this. Beyond that, there's a lot of
other more specific signaling and messaging type services
that are designed specifically for sending messages
between elements, or mediating those
sorts of things. And you can see
some of those here, like Firebase, PubNub, even
Google Cloud Messenger, which Daniel will talk about
a little bit later. So that's signaling. The next segment here
we're going to go into is NAT traversal firewalls. And these are devices that
are part of the network. And one of the
challenges with WebRTC versus, say, existing
telecom systems is, when there's no
connection, you can't just go tell your user,
oh I'm sorry, you have to go change your network. No one's going to go and tweak
their firewall or their router just so they can
make a call with you. So a lot of the work
that's been put into WebRTC and the standards are
about getting around that sort of process
so you as a user, and your users at
home or at work can just have a very quick,
simple call with WebRTC without having to
worry about the network or making any changes. So to start out, I'd like to
talk about the NAT problem. And NAT stands for Network
Address Translation. And in traditional web systems,
you have a web server here. And they're really
set up for your users at home or at work for
talking to those web servers. And this system
works pretty well. Systems that are to do
this, all the network configuration for doing this has
been pretty well established. If there's something out
on the world wide web, generally you're
allowed to go get it as long as it's over HTTP,
follows the usual parameters. WebRTC breaks this,
because now we're talking about doing
peer-to-peer media. We're not just going from
your client to the server. We're actually going
from client to client. And we're just sending things
direct, is peer-to-peer. And that's really where
a lot of the issues start to come into play. So most networks are
behind these NAT devices. And NAT devices exist
for a lot of reasons. But fundamentally, before
IPv6, there wasn't enough address space out there. And for management purposes,
your ISP or your IR manager generally put in some
sort of NAT device. And you had a local address,
so a couple of examples of local addresses here. And these addresses are
used within the local LAN, the local environment
behind the NAT. And what's exposed externally
is a different address. And the problem
with WebRTC is, I need to have this client
talk to that client. So how do I know its address? The way these clients
look to the outside world, it actually shows the
external IP address. But to really reach
this client, I need to know how to get
through that external one, and also find the
local internal address, and be able to differentiate
that between one of dozens, hundreds, thousands, tens of
thousands of potential clients within that local area network. So that's problem number one. Problem number two is there's
different types of traffic. There's TCP. There's UDP, which is
more beneficial for VoIP, because TCP has reliable
connections that will retransmit. But in most cases
for Voice over IP, there's no time for
that retransmission. If that packet or that
message doesn't get through, it's too late. You're better off just
throwing it away and not bogging down the network. And TCP and UDP, they
follow certain port ranges, particularly UDP. And a common practice for
security reasons for a firewall is basically just
to block anything that doesn't look like
it should be there, or that you don't want to
have access-- so prevent external hackers from
penetrating your network or finding some service
and exploiting it. So firewalls very typically
block certain ports, or they block UDP altogether. So just to recap,
some of the problems and some of the
addressing scheme that you should keep in
mind when using WebRTC, there's three main aspects to
addresses you need to remember. One is the IP address. And I showed all IPv4 addresses,
but this could also be IPv6. There's ports that
you need to deal with. There's common ports
like 80 and 443, but then there's a whole big
range of UDP ports out there. And then there's the protocol
that we talked about, UDP or TCP. And one of the great things
that's built in to WebRTC and that has been standardized
to help get around some of these firewall
and NAT problems is called Interactive
Connectivity Establishment, or ICE. And as you see
here, basically ICE is a protocol for allowing a
client behind a NAT or firewall device to talk to another
one that may or may not also be behind a NAT or
firewall device. And there's two types of servers
that handle ICE transactions. And I'll go through it in more
detail what these things are. But the first is a STUN server,
Session Traversal Utilities for NAT. They're pretty archaic names. But the second one
is a TURN server. And I'll show what these are. So the first one
is the STUN server. And we talked about
the problem here. I need to know, as
a user, basically, what does my
external address look like so I can include that
addressing information externally? And the easiest way to do
that, just like you can-- some web pages,
websites offer this is, let's just go out to
a server and ask it, what is my IP address? So it goes out. STUN server basically is,
you do a request and ask, what is my IP address? And it returns not
the internal one. It returns the external
address that it sees here. The second type here essentially
acts like a relay server. And this is TURN. So when you can't make
a connection via STUN for whatever reason,
TURN servers generally have a well known
public IP address that both clients can reach,
just like your web server. And the media ends
up being relayed through that media server,
or through that TURN server. So comparing these two
items, the important thing is to remember, one
is STUN, one is relay. When it comes to cost,
STUN is very scalable, because it doesn't
have to do much. You're just basically
asking for an IP address. It sends back that information. TURN, on the other hand,
is much more intensive, because it's relaying
all your media. And someone has to pay for
that bandwidth and that server at the end of the day. So TURN ends up being
a lot more expensive. Another challenge
with TURN, if you don't architect your network
right or have enough, you can actually introduce
delays and latencies, which can hurt quality. So how often are these different
types of relays and TURN servers needed here? So generally STUN is
almost always needed. I asked Varun-- he'll be giving
a talk later on-- to maybe pull some stats from his
callstats.io database to see what's the latest
on the number of users that need to have a relay to
be able to use a TURN server. That's around 24%. And TokBox, another sponsor
that's here with us today-- this data is a few
months old now. But for them, you can see it
ranges quite a bit from day to day or from month to month. But on average it's
somewhere around 10% or so of all WebRTC calls
require this TURN server. So you can see, even
though TURN's expensive, if you're running a
production network, is it OK for 10%
of your users not to be able connect
or make a call? In most cases I'm
guessing it's no. So this is why it's
really important to include a TURN server. And using these TURN
servers is actually is relatively simple actually,
making use of a TURN server. And I'll show you quickly
how to do this here. So the first thing you want
to do with a TURN server is actually just get
a nice service object. Now here, I'll load
up my terminal. Briefly, let me just clear. And you'll see
here in this case, I'm going to use a
TURN server from one of our sponsors, Twilio. This is a very
simple REST API call. Most of the vendors, people
who offer TURN servers have libraries you're going to
have to read in to make this. And so I'm just going to do
this very simple REST API call to the TURN server,
essentially asking it for a nice service object. And I'll walk through what
that looks like in a moment. And then I'm just going to pipe
this to a simple Python command just to format it and
make it look nice. So you can see here, what
this returns is a list of different ICE servers. And I'll walk through-- I'll show in a moment-- let me walk through here-- what some of these things are. And you see the first
one is a STUN server. You can see this other
one here is a TURN server. And there's a few
different varieties. You can see they use different
protocols here, TCP and UDP. And ideally your
TURN server is going to give you a bunch of different
options for connecting. So in case you come
across some firewall that, for whatever reason, blocks
TCP or block certain ports on TCP or blocks UDP, you
have many different options for getting through
and connecting. And as you can see here,
just to recap the same thing, shows the different objects. I think I touched
on most of this. The key thing with TURN
servers, I'd say almost 100% of the time, they're going to
have some sort of user name and password, because it's
using some sort of network asset and you don't want someone else
just hijacking and relaying media through your server and
running up your bandwidth bill. So there's always some
sort of credentials. And generally there is
a time to live element with all the TURN servers too. And this lets you know how long
those credentials or those, actually, TURN
servers are valid for. So I showed a couple different
types of ICE candidates and protocols. So the TURN server you
go out and you ask it for different options. So some of the options we've
talked about a little bit, UDP. Again, this is really
what's best for VoIP. This provides the lowest
latency, and overall the best performance. But sometimes it's blocked. The next alternative is TCP. And if TCP doesn't
work for some reason, or if there's some
packet inspection going on that might be blocking
it, the last option is actually doing TLS over
TCP, encrypting the traffic. Now, TLS over TCP in
some ways is not great because you're actually
encrypting the traffic twice. WebRTC's traffic by
default is encrypted and you're encrypting it again. You're not really providing any
security benefit on top of it. You're just doing this
to hopefully allow-- so that the firewall permits
the traffic to go through. And you'll see turns
candidates for this. As you see in this
example I have here, the last one is turns. That lets you know
it's TLS over TCP. And if we look, different types
of TURN, what kind of TURNs types. Most of them, in general, allow
TURN over TCP, followed by-- I'm sorry, most
allow TURN over UDP. That's the biggest chunk,
this blue one here. Again, thank you
Varun for sharing some of this recent data. TURN TCP is smaller. And generally, the
TURN TLS element is the smallest portion that's
required, or used in a network. And most TURN servers
actually will, as I showed in the two
examples before, they're going to try all these. And hopefully your
connection will be made in priority of what
provides the best performance or the best capabilities. So, just to recap some other
terminology you saw there, there's a couple of different
ICE candidate types. A host candidate is when
you can use a local address. So probably what
happened when we tried doing the Jitsi
Meet call that German used to open the session, most
of us, since we're all on the same network,
were probably able to use a local address
and connect that way. That's known as
a host candidate. You may hear another term
called your reflexive or server reflexive candidate. That's an address that's
returned from a STUN server. It's reflexive, basically
get reflected back unless you know what your address is. And the last one is
really, a relay candidate. And that's coming
from a TURN server. And we can actually-- some other great tools
on webrtc.github.io, there's a lot of
tools you can use to test your ICE connection. This is really
helpful when you're trying to diagnose or make sure
your TURN server is working. It's really good to be able
to go and use some third party code to do this. You see here, I have
already prepopulated from the ICE servers object,
the servers I had here. But essentially, all you do
is you put in the address it gives you. You put in the username
and the password. And you'll see, typically,
STUN servers often times don't require a username or
password because people aren't as concerned about using those. You can add an
additional if you want. And you basically go and
you gather candidates. And you can see
here, this will vary. You can try this on
your mobile phone. You get a different
set of candidates than you would here in
an office at Google. I got a completely different set
of candidates inside my hotel room. You can filter this, if
you want to just look at relay candidates. I'll just look at all
of them here quickly. And you can see a bunch of
different options including UDP, UDP over IPv6,
UDP over IPv4. So this shows you all
the different, basically, ways or methods that are being
tried to connect your one peer to another peer. Again, this all happens as
part of the ICE process, behind the scenes. So in most cases, you
don't need to worry about this, unless you're
doing some more advanced troubleshooting or diagnostics. The key is really to
emphasize that this is all stuff that is happening
as part of the ICE process. And you're going to get these
relay candidates and reflexive candidates when you use
a STUN and a TURN server. I included a couple
of other links here. We'll show later on
another great cool tool from the official
Google WebRTC source, you know testwebrtc.org. There's some capabilities
to test there. I just showed some of the other
trickle ICE testing, sample there too. So when you go from, if you
want to actually use or deploy your own TURN server
or when you considering using a TURN service,
there are a couple of things to keep in mind. Just probably one of the
highest level or simplest ones to start out with
is, you really want to have some level of
redundancy, and ideally geographic
distribution, especially if you have users
that are distributed throughout the world. The TURN server relays media. So you want to consider
the latency that happens between the user
and that TURN server and the TURN server
on the other side. If the TURN server I'm trying
to call from here in Brazil, and my TURN server is up in my
home in Boston, and for someone else down here in Brazil, that's
going to be a really long loop and delay. It's not going to lead to
a very good voice quality. It's much better if my
audience is in Brazil to have a TURN server
that's in Brazil, or one that has a very low
latency or a close connection. So just to conclude on the
TURN server section here, what are some of the ways
to get a TURN server? Well, most of the
CPaaS providers include some sort
of TURN option. Again, this is
something that everyone should have in production. If you want to run your own,
there are several options out there. My personal favorite
is the coturn server, which is widely used. But there are others as well. And there are several
dedicated TURN services where perhaps you don't want
to use a larger communications platform as a service API set. You just care about having
access to that TURN server and doing some of the
things I showed you earlier where you just basically
go and get the ICE servers and add that ICE servers object
into your peer connection. There's a bunch of services
that allow you to just do that. And they generally
charge based on bandwidth for the amount of
bandwidth you use. So, next I'd like to
talk about media servers. And there's a few reasons why
you might need a media server. German talked earlier about
doing multiparty calls. This is where you have
multiple users calling in the same line, similar
to what we showed early on with the Jitsi video meet. Recording is actually very
common, popular application for making advantage
of media servers. Any time you want to do any
sort of media manipulation-- this is another aspect, right? Perhaps you want to do
some image processing on the stream that's too
processor intensive to do locally, or you want to
take advantage of some cloud algorithms to do that. So media manipulation
is another one. And live broadcasting is
another emerging application for using media servers. First I'd like to start and talk
about the multiparty scenario. And WebRTC is a
peer-to-peer technology when it comes to media. So the simplest
approach to start out with doing a multiparty
call is to just connect up multiple peers and
add them all together. And this is a perfectly valid,
technically possible thing you can do. But you'll see, adding a
third party is not really that big a deal. You don't have that many
different streams to deal with. But as you start adding
more and more parties, you can see that there's this
exponential effect in terms of the number of streams
that each client needs to deal with, and also
for your overall network, the amount of bandwidth
that's required to send all this information around. And the challenge
here is, especially if you're dealing with
mobile devices or anything on a battery, the more streams
you have, the more decoding it requires. It's going to chew
up your battery and probably not lead
to a great experience. So the traditional way
of solving this problem is through an approach called
MCU or multipoint control unit. And this essentially just
takes all the streams, and you send your stream to
a centralized media server. That centralized media
server mixes it together and sends it back out
to all of the clients. And this is actually pretty,
from a client perspective, this is a pretty
simple approach. You don't have to deal with
connections and connectivity to potentially dozens or
however many other clients. You're only dealing
with a connection to one other element, and
dealing with that connection. And that other element takes
care of everything for you. Now the downside of
this is this approach is actually very processor
intensive on the server side. So this requires
a lot of capacity. And as I'll show
here in a moment, part of the challenge with
MCU is it doesn't actually give you a whole lot of layout
options, because the MCU is taking in all those streams,
mixing them together into a single stream,
and sending that back. And generally when
that mixing happens, it's downsampling or
downsizing the image. It's resizing things. So the people on the other end
aren't getting the same images that are being sent out. And using these
services, generally you need to define or
decide exactly how do you want to have
that screen be laid out. Oftentimes, to save on
processing capacity, the MCU will actually
include a view of yourself, which might be a little
bit weird to see yourself with a little bit of delay
there in an unmirrored fashion. So some of the
downsides of the MCU, beyond just the general cost-- because they're
very CPU intensive-- tend to be they're
limited in layout options and they don't give the
client really any ability to control, or limited
ability to control what the layout would look like. So another approach emerged
called a selective forwarding unit, an SFU. And this essentially acts like a
video or a media stream router. And I should add in here, the
primary use cases for all these tend to be video. But there's no reason
audio wouldn't work with any of these scenarios. The advantage of the audio is
generally a lot less bandwidth, so you can actually
get away with the SFU-- or with the peer-to-peer
approach a lot more. But as I illustrated
in the slide, it doesn't make the
problem go away. It just lets you add
more clients than you could potentially otherwise. So transitioning
back to the SFU, this is much more
flexible approach where, instead of relying
on the central media server to do all this processing
and mix things, the client basically
sends up one stream. And in a very
lightweight process, the SFU basically
copies that stream and sends it back
to everyone else. And this is much
more lightweight because the SFU only needs to
do decryption to pass it along. And this ends up being,
in a lot of cases, a lot more scalable, a
lot more cost effective. You're basically passing on some
of the cost burden of the media server from the media
server to the clients, which lowers your price
and helps increase scale. But as you can see,
some of the downside here is it this can end up
using a lot of bandwidth, both in your network and
potentially on the receive side in your clients. So a newer and more
advanced method for dealing with that bandwidth
issue is known as simulcast. And unlike before where
basically the SFU was just passing along generally
a high bit rate stream or a single
type of stream, simulcast is basically each
client simultaneously sends more than one media stream. Generally one is of a high
bit rate, HD-type stream, and generally the other one is
a lower bit rate type thumbnail. And so both of these
streams get sent to the SFU. And the SFUs generally have
enough logic and intelligence to say, not everyone out
there needs to see 10, or in this case, five different
HD video streams at a time. Usually the way these
calls are set up is you have one
active talker that gets the most real
estate, whoever's presenting or speaking. And everyone else gets
a smaller thumbnail. And this allows you to scale
up a lot higher because now instead of sending back all
those HD video streams down to every client,
you're just sending a few smaller thumbnail,
low bit rate video streams. And as a client-- in this case, I'm showing an
example from Jitsi video bridge that we showed earlier. But Google Hangouts
works the same way. As a client, you have the
ability to select, actually, I want to look at this
person or this screen. And the SFU then has the logic
to send each individual client whatever streams they request. So there's a lot more
flexibility, a lot more control. And ultimately this ends up to
a much better user interfaces and user experiences on
the application side. So this is really the state
of the art of media servers and where people
are going today. Now there are additional
and more advanced techniques coming. I don't have time
to cover that today. But in general, in
most applications you can do pretty well with an
SFU or a simulcast application today So how you get and how do
you use a media server? Well many of the CPaaS providers
generally have something or they're adding
something here. So you can always go there. There are a number of
open source products out there that you can
go and take advantage of. Their capabilities and use
cases vary quite a bit. Some of these are SFUs. Some of these are MCUs. Some of them let
you do either one. And there are use cases where
you might want to do an MCU, or others where an
MCU doesn't make sense and you just need the SFU. And then there is an industry
of commercial vendors who sell software-based systems
or hardware-based systems that do media servers too. So again, this is for
applications that require larger scale, multiparty video. There are a number
of tricks and hacks you can do that try to
increase the number of users you can get inside a
multiparty situation, without using a media server. But generally there's
always some limits or some other limitations
that, if you go big enough, you want to have a media server. The last topic I won't
spend a lot of time on, but I did want to
introduce is gateways. And this was talked about in
some of the Q&A previously. Gateways are for
when you're not just talking browser to browser. Standard WebRTC
is good for that. But what if you
want to go and make a call from a browser to
the telephone network, to somebody's mobile phone
through the native Dialer app or to someone at home? There are gateway products. The core part of
gateways basically need to do two things. There's some signaling aspects
and there's some media aspects. The media aspect, at least,
is a little more standardized, because it's
standardized by WebRTC. So you need to convert that
media from SRTP-DTLS inside of WebRTC to something else. And generally that's just
plain RTP without encryption. But it might be-- and oftentimes there's
a codec conversion, or there might be a conversion
of codecs from the Opus codec, which is most commonly
used, to a more, in this case, a
telecom-oriented codec. Signaling side can be
a little more complex, because WebRTC doesn't
define exactly how you need to do the signaling. It just tells you
need to figure out a way to pass SDP from
one side to another through that
offer-answer mechanism. You need a way then to convert
whatever signaling mechanism you have to the
standardized signaling mechanisms that are out
there in the existing telecom-telephony world
with protocols like SIP. So just to conclude here,
you can't completely ignore servers. In a lot of cases, you don't
need to have all these servers. But at a minimum, you have
to have a signaling server, and you really should probably
have a STUN and a TURN server. Oftentimes STUN and TURN,
they're the same in one server. If you don't want to actually
pay for a STUN server, a lot of people use the Google
one which they leave open and allow you to use. And so just conclude
with some considerations on the signaling side. If you can leverage the existing
application infrastructure and the existing
signaling mechanisms that you have already
in your application, that will make
things a lot easier. If that's not possible
or if you don't have that or if it's not practical,
at least getting started, signaling can be pretty
easy and you don't actually need to have a lot of code. Or you can take
advantage of open source or other commercial
products out there. NAT traversal side, again,
just to reinforce probably the biggest problem that comes
into play with people that are new to WebRTC
when they start to deploy it is, some
portion of their calls don't work because they
never deployed a TURN server. You have to deploy this. Media servers, important
for multiparty recording, very specific situations. These come into play-- it only matters if
your application needs one of these things. If your application
doesn't, then you don't necessarily need to
worry about media service. If you are dealing
with multiparty video, the state of the art is
an SFU with simulcast. And lastly, if you
want to connect to some other network, most
typically a SIP network that's out there in existing
corporate environments, you're going to have
a gateway to do that. And there's a number of
products and techniques. With that, we can
take some questions. [APPLAUSE] [MUSIC PLAYING]
