►
From YouTube: WebRTC: Web Real-Time Communications
Description
WebRTC, Web Real-Time Communications, is revolutionizing the way web users communicate, both in the consumer and enterprise worlds.
WebRTC adds standard APIs and built-in real-time audio and video capabilities and codecs to browsers without a plug-in. With just a few lines of JavaScript, web developers can add high quality peer-to-peer voice, video, and data channel communications to their collaboration, conferencing, telephony, or even gaming site or application.
Slides from presentation at:
https://datatracker.ietf.org/meeting/100/materials/slides-100-edu-sessm-webrtc-tutorial-part-1-00
A
Sass
fall
joint
standards,
effort
between
the
internet,
internet
engineering,
task
force
us
and
the
world
wide
web
consortium
or
w3c.
So
IETF
is
responsible
for
all
the
protocols,
of
course,
and
many
of
the
protocols
actually
virtually
all
of
them
are.
They
already
exist.
Okay,
the
intention
was
not
to
have
to
create
a
bunch
of
new
stuff,
but
we
have
had
to
create
extensions
in
the
IETF
and
I'll
talk
about
a
few
of
those
later
on.
A
The
RTC
web
working
group
in
the
IETF
is
the
one
that
has
them
its
main
focus
on
WebRTC
I've
listed
some
others
here
that
are
that
have
related
activities
as
well.
So
anyway,
it's
it's
spread
throughout
the
IETF,
or
at
least
has
been
for
the
past
few
years.
The
JavaScript
API
is
are
developed
in
w3c
and
there
are
two
groups
there:
the
web
RTC
working
group
and
the
media
capture
task
force.
So
if
you
hear
RTC
web,
that's
IETF.
A
If
you
hear
web
RTC,
that's
in
w3c
and
in
general,
when
you
hear
people
refer
to
WebRTC
in
general,
they're
referring
to
the
JavaScript
API
is
defined
in
w3c,
although
what
IETF
does
is
rather
important
here
as
well,
just
briefly
on
protocols
I'm
not
going
to
go
through
these
in
detail.
These
are
all
the
protocols
that
end
up
getting
used
at
some
point
and
in
some
way
with
WebRTC
I
do
want
to
call
out
a
couple
of
them.
A
Let's
say
I
wonder
if
this
will
give
me
a
pointer
here,
yes,
but
you
can't
break
and
see
it
very
well.
The
main
thing
I
want
to
point
out
is
that
media
is
sent
using
SRTP
and
that
actually
sits
here
basically
uses
using
DTLS
for
UDP
packets.
The
data
channel,
which
I'll
talk
more
about
later
uses
SCTP
and
D,
TLS
and
UDP.
These
are
the
the
ice
related
protocols,
like
I
mentioned
before,
and
SDP
we'll
talk
about
it
a
little
bit
more.
A
So
what
this
is?
It's
really
interesting
when
I
talk
about
WebRTC,
it
turns
out
that
in
every
crowd,
typically
people
either
are
communications,
people
or
they're
web
people,
and
it's
tricky
to
create
a
tutorial
for
both,
because
you
actually
need
to
understand
some
of
both
so
I'm
gonna
talk
now
about
what's
new
for
web
developers,
there
are
two
new
API
pieces
again.
This
is
in
w3c,
one
is
capturing
of
local
media.
So
without
a
plug-in
you
can
get
access
to
the
camera
and
microphone.
A
Now
there
are
some
extra
specs
that
define
how
to
get
access
to
what's
playing
in
a
video
element
and
in
fact,
your
screen
and
window
as
well.
The
another
specification
defines
the
peer
connection
and
that's
a
term
you're
going
to
hear
a
lot.
The
peer
connection
is
what
provides
the
ability
to
transport,
both
media
and
data
between
two
client
browsers.
You
will
often
hear
me,
say:
media
peer-to-peer,
it's
media
and
data.
So
if
you
hear
me
say
that
I'm
in
most
cases
referring
to
both
okay.
So
very
briefly,
there
are
several
steps
here.
A
This
is
not
everything
to
building
a
web
RTC
application.
These
are
the
pieces
approximately
in
order
that
a
JavaScript
application
would
have
to
do
in
order
to
add
in
WebRTC
functionality.
Okay
and
the
first
one
is
getting
access
to
local
media.
That's
done
using
the
getusermedia
call
and
I'll
show
a
little
bit
more
specifics
later,
but
one
of
the
important
things
here
is
that
this
is
where
the
user
is
asked
for
permission:
I'm
not
going
to
cover
the
the
details
on
that.
A
But
I
will
show
examples
later
on
when
you
call
getusermedia
you're,
given
a
media
stream,
which
consists
one
or
more
MediaStream
tracks
and
I'll
give
more
details
on
on
these
later.
But
basically,
you
need
to
have
local
media
in
order
to
send
it.
You
need
to
set
up
a
peer
connection
and
the
rtcpeerconnection
api
is
the
one
that
does
that
I've
listed
here.
A
All
of
the
things
that
the
peer
connection
actually
does
or
provides
an
API
surface
for
so
a
lot
of
what
we
think
of
as
WebRTC
really
lives
here
now,
once
you
have
a
peer
connection,
that
doesn't
mean
that
any
media
is
flowing
yet
okay,
the
simplest
way
to
have
media
flow
is
to
call
add
track.
This
is
a
peer
connection
call
and
what
it
does
is
it
basically
tells
the
browser
I
want
you
to
negotiate
how
to
send
media.
A
But
the
main
thing
you
need
to
know
right
now
is
that
there
are
functions
for
creating
this
session
description,
the
offer
and
answer
and
then
functions
for
telling
your
browser.
What
it
is
that
you're,
actually
using
which
session
description,
one
thing
that
I
didn't
show
in
this
diagram
is
the
signaling
channel
and
you'll.
Hear
me:
I
talked
about
this
at
the
very
beginning.
The
signaling
channel
is
just,
however,
you
send.
However,
you
communicate
your
low-level
session
description
information
before
you
have
a
peer
connection
going,
so
it's
not
standardized.
Okay.
A
Okay.
So,
in
a
little
bit
more
detail
here,
navigator
Media
devices,
I
getusermedia,
is
how
you
get
access
to
cameras
and
microphones,
and
there
is
the
permissions
check
now,
once
you
have
that
media
there's
a
new
method
that
was
added
to
video
and
audio
elements.
This
is
interesting.
We
actually
had
to
add
this
ourselves
in
the
WebRTC
specifications
initially,
but
it
then
was
moved
into
HTML
itself.
A
So
the
point
here
is
that,
instead
of
just
setting
the
source
of
a
video
element
to
be
a
URL,
you
can
now
call
you
can
set
the
source
object
to
be
your
media
stream
directly.
Okay.
So
it's
not
going
to
fetch
a
resource,
that's
at
the
that's
referenced
by
URL.
Instead,
it's
going
to
use
a
local
local,
local
media
stream.
You
can
also
create
new
media
streams
as
well.
A
So
just
briefly
in
the
in
the
model
that
we
have,
of
course
you
can,
you
can
load
content
from
files
or
whatever,
but
what's
really
being
added
here?
Is
the
ability
locally
to
get
access
to
the
camera
and
microphone
now,
interestingly,
the
peer
connection
is
actually
both
a
source
and
a
sink
for
media,
because
you
can
send
media
over
a
peer
connection,
in
which
case
when
you're
sending
it,
it's
obviously
a
sync
when
you're
receiving
it
it's
a
source.
A
So
here
are
a
couple
of
examples
of
what
what
the
permissions
prompt
looks
like
when
you
call
getusermedia
you're,
going
to
be
asked
whether
you're
giving
permission
to
use
the
camera
and
microphone
or
in
the
case
of
Firefox,
they
tend
to
allow
you
to
select
the
you
know
which
device
you
want
to
use,
but
in
either
case
once
it's
set
up
both
browsers.
Allow
you
to
change
which
device
you're
using
if
you
have
more
than
one.
A
The
key
here
is
that
you
cannot
use
getusermedia
without
a
permissions
check,
at
least
once
there
are
conditions
under
which
the
browser
is
allowed
to
save
that
permission.
I'm
not
gonna,
go
into
it
because
there
there
are
some
subtleties
in
that.
But
it's
something
that's
important
when
you're
building
an
application
to
keep
in
mind
that
at
least
the
first
time,
someone
visits
your
site
they're
going
to
have
to
agree
to
this
permission,
prompt
okay.
A
A
For
example,
one
of
the
other
things
that's
interesting
about
a
media
stream
is
that
the
intent
one
of
the
intents
of
a
media
stream
is
that
the
collected
tracks
are
to
be
kept
synchronized
to
the
best
ability
of
the
browser
and,
if
you
think
about
it,
if
you
have
a
camera
on
a
person
and
a
microphone,
you
do
want
to
make
sure
that
the
audio
that's
coming
out
matches
the
movement
of
their
lips.
Okay,
so
the
browser
works
pretty
hard
to
actually
maintain
that
as
much
as
possible.
A
It's
not
possible
to
guarantee
this
in
all
cases,
guarantee
synchronization,
because
if
your
media
came
from,
let's
say
several
different
peer
connections
into
your
current
browser,
they
may
all
have
different
clocks
and
it's
not
clear
exactly
how
you
would
synchronize
them.
But
again
the
browser
will
do
what
it
can.
A
A
So
I'm
gonna
jump
around
just
a
little
bit
because
I
had
reordered
these
so
I'll
come
back
to
this
in
a
minute.
I
want
to
talk
about
sdp,
offer
answer
so
again.
This
is
how
do
you
get
the
information
about
which
codex
to
use
any
bandwidth
information,
perhaps
candidate,
addresses
at
which
one
browser
can
find
the
other
browser?
These
things
all
live
in
something
called
SDP.
We
use
this
session
description
protocol
just
doesn't
zip
or
approximately,
as
in
sip,
to
describe
the
media
session
at
the
protocol
level.
A
A
So
with
respect
to
s
with
respect
to
WebRTC
this
protocol
level,
configuration
information
is
just
treated
as
a
blob.
Okay,
the
it's
not
expected
at
the
application
that
JavaScript
application
will
ever
have
to
look
at
it.
So
now,
let's
just
take
a
look
at
what
the
application
does
have
to
do,
though,
and.
A
Yes,
I'll
come
back
to
that
of
the
slide,
so
here
we
have
our
two
browsers
in
the
in
the
center
down
here
and
what
we
want
to
do
is
actually
set
up
the
de
pere
connection
and
and
make
it
so
that
media
can
flow
between
the
two.
So
this
browser
here,
the
one
on
the
Left,
calls
create
offer
and
is
given
an
SDP
blob.
A
So
what
this
browser
then
does
is
it
calls
set
local
description
with
that
offer.
So
what
is
returned
here
from
create
offer
is
an
offer
it's
this
STP
blob,
so
the
application
needs
to
tell
the
browser.
Yes,
this
is
what
I'm
using
locally,
but
it
has
to
do
something
else
too.
It
is
the
job
of
the
application
to
send
this
offer
over
the
signaling
channel
to
the
other
browser,
and
then
the
other
browser
takes
the
same
thing.
A
So
this
remote
offer
and
look
they're
the
same
okay,
but
from
this
person
from
the
perspective
of
this
browser,
it's
the
remote
offer.
So
this
browser
calls
set
remote
description.
Excuse
me,
this
code
called
set
remote
description
to
tell
the
browser
here.
This
is
the
description
that
the
other
guy
is
using.
A
Now
once
that's
happened,
this
side
can
call
create
answer
to
generate
the
answer.
For
for
this
offer,
and
once
the
right-sized
has
right
side
has
the
answer
which
is
right
here.
It
calls
set
local
description
just
like
this.
One
did
over
here
with
the
offer
this
one's
doing
it
with
the
answer
and
then
just
like
before
the
application
is
responsible
for
sending
this
answer
over
the
signaling
channel
to
the
other
browser.
A
A
So
I
just
want
to
mention
here
that
there
are
a
number
of
extensions
that
were
made
to
sdp
in
order
for
WebRTC
to
work.
One
is
bundle,
and
actually
this
is.
This
is
particularly
interesting
because,
as
we
worked
on
this,
we
found
that
basically
everybody's
been
wanting
to
do
this
for
a
long
time
anyway.
A
A
Here's
one
example
right.
So
if
we're
signaling
using
sip,
we've
got
some
sip
library
in
in
JavaScript
here,
and
so
we
have
the
web
server
as
usual
that
that
the
HTML
application
comes
from,
but
then
for
the
signaling.
The
library
that
we
have
is
set
up
to
contact,
sip,
proxy
or
registrar
server,
just
as
the
as
you
would
normally
force
it.
The
only
thing
that's
really
different
here
is
that
the
SIP
signaling
information
is
sent
using
the
WebSocket
protocol,
and
this
is
not
a
new
RFC.
A
That's
one
of
the
other
things
in
there
in
the
update
this
has
been
around
for
a
while
now,
but
this
RFC
defines
SIP
transport
over
WebSockets.
So
this
is
what
you
would
do
if
you
have
an
existing
sip
infrastructure
and
you
just
want
to
use
the
WebRTC
front-end.
Essentially,
there
are
a
variety
of
libraries
that
you
can
use
to
do
that.
A
Okay,
briefly,
for
audio
the
browsers
are
required
to
implement
both
opus
and
g.711
opus
was
developed
here
in
the
IETF.
It's
a
great
codec
sounds
wonderful.
G.711
works!
That's
what
I'll
say
about
it!
The
browser
is
also
expected
to
support
DTMF,
which
are
basically
the
you
know.
The
events
you
get
when
you
press
the
buttons
on
it
on
a
keypad
for
video.
The
requirements
are
h.264
and
vp8.
A
A
So,
just
briefly,
I
want
to
talk
about
the
the
data
channel.
Again
it
uses
SCTP,
basically
the
the
data
channel.
We
wanted
to
make
sure
that
we
had
congestion
and
flow
control
for
an
arbitrary
data
channel,
and
so
that's
why
we
use
SCTP
on
top
of
DTLS
and
UDP
I.
Understand
that
some
of
the
design
of
quick,
or
at
least
some
of
the
motivation
for
how
quick
was
designed
came
from
experience
with
building
the
data
channel
in
WebRTC.
A
So,
from
a
JavaScript
standpoint,
it's
one
of
the
peerconnection
API
is
you
call
create
data
Channel,
and
what
you
get
back
is
something
that
has
a
send
method
and
an
on
message.
You
can
set
an
on-message
handler
by
default.
Data
channels
are
bi-directional,
but
you
can
change
that
and
you
can
send
any
any
string
or
any
of
the
various
array
buffer
types.
A
So
very
briefly,
about
security.
There's
a
lot
that
could
be
said
about
this.
Your
media
is
always
encrypted
in
WebRTC,
we
actually
mandate
the
use
of
SRTP.
This
was
a
contentious
point,
but
the
world
is
used
to
it
now.
So
just
just
expect
that
and
this
I
actually
got
rid
of
these
slides
because
they're
just
very
confusing.
A
There
is
a
mechanism
now
in
the
specification,
an
identity,
proxy
mechanism
and
essentially
the
SRTP,
is
great,
because
you
know
that
your
media
is
protected
and
to
end
from
browser
to
browser.
But
how
do
you
know
that
you're
actually
talking
to
the
person
you
want
to
be
talking
with
on
the
other
end?
A
New
low-level
controls
in
WebRTC
and
going
forward
we're
eventually
going
to
only
be
recommending
the
use
of
those
the
reason
I
stuck
it
at
the
end
here
is
because
they're
not
implemented
anywhere
yet,
even
though
the
specification
you
know
assumes
that
everyone
is
implementing
them
today,
so
I'm
gonna
walk
through
an
example.
Here
we
have
one
browser
one
and
browser
to
browser.
A
One
has
two
streams
in
it,
one
that
was
defined
within
browser
one
and
is
being
sent
over
a
peer
connection
and
one
that
was
defined
in
browser
two,
that's
being
sent
over
a
peer
connection
and
received
by
browser
one
okay.
Now
what
I'm,
showing
here
is
effectively
what
you
see
in
the
SDP
in
SDP.
There
is
an
EM
line
or
a
media
line
for
each
one
of
these
bi-directional
s,
RTP
streams,
so
this
shows
media
going
to
the
right.
This
is
media
going
to
the
left.
A
A
A
A
A
A
So
and
I
modified
the
diagram
a
little
bit,
it's
actually
each
browser
has
a
transceiver
for
each
M
line,
so
there
would
be
one
two,
three
four
transceivers
that
this
browser
has
and
for
that
this
browser
has-
and
this
transceiver
has
pointers
to
this
sender
and
well.
You
know
this
receiver,
which
doesn't
have
anything
in
it.
Okay,.
A
Just
briefly,
the
status
of
the
I
want
to
talk
about
the
status
of
the
API.
So
again
the
JavaScript
API
is
are
being
standardized
in
w3c.
There
are
two
main
specifications:
the
WebRTC
spec
and
the
media
capture
and
streams.
Spec
both
of
them
are
now
a
candidate
recommendation
stage.
The
WebRTC
spec
just
went
to
candidate
recommendation
stage
a
couple
weeks
ago,
so
WebRTC,
unfortunately
I've
had
this
bullet
up
for
a
while.
A
When
I
give
this
presentation
core
is
stable,
just
cleaning
up
edge
cases
now,
so
we're
still
cleaning
up
edge
cases,
even
with
it
being
at
candidate
recommendation,
but
we're
getting
close.
What
we
really
need
is
implementations
for
the
media
capture
and
stream
spec
yeah.
It's
it's
been
closed.
For
a
long
time
again,
we
need
some
stuff
implemented
for
the
IETF
protocols,
I'm
not
going
to
try
to
list
all
of
them.
A
:
Jennings
maintains
a
dependencies
draft
which,
which
is
always
interesting
to
look
at
to
see
just
how
many
specifications
there
are
that
wherever
our
TC
depends
on
and
then,
of
course,
for
the
individual
groups,
you
can
follow
their
progress
like
you
would
normally.
Just
briefly.
There
are
tools
that
have
popped
up.
You
know
out
in
the
world
to
help
with
WebRTC.
There
are
a
variety
of
libraries
I'm
not
going
to
list
them
here.
I
mentioned
there
are
sip
signaling
libraries.
There
are
several
of
those
there
are
hosted
signaling
services.
A
A
There
are
also
some
higher-level
api's.
If
you
just
don't
want
to
code
all
of
the
stuff
that
you've
seen
you
can
use
some
of
these
simpler,
api's
fun
links.
You
can
look
those
up
on
your
own
if
you're,
interested
and
I
thought
it'd
be
good
to
talk
about
this
I
almost
wanted
to
start
with
this
one.
Facebook
chat,
Google
Hangouts
in
duo
and
Amazon
Mayday
all
use
WebRTC.
A
C
C
B
Thank
you,
then
I
think
that
was
a
shorter
than
usual,
because
I've
seen
dues
presentation
during
hate
hours
done
before
I
think
is
still
very
interesting,
and
it's
very
difficult
to
actually
condense
six
years
of
work
and
multiple
specification
into
into
45
minutes.
You
did
a
great
job
there
I'm
going
to
try
to
do
that
in
in
in
just
one
slide.
So
it's
an
even
bigger
challenge
and
then
I
go
through
everything.
B
You
said
in
the
next
two
slides
right,
just
to
repeat
everything,
but
first
my
name
is
Alex
Squire
I'm,
actually
living
and
residing
here
in
Singapore
and
I'll
participate
in
both
w3c
Andy
Andy
IETF,
mend
me
on
web
RTC,
but
also
on
browser
testing
and
tools,
web
drivers
and
things
like
that.
Those
we
went
to
GS
confession
last
year
already,
so
us
I
hope
you
going
to
enjoy
having
high
ETF
in
town.
We
know
we
very
happy
it's
here.
So
speaking
about
web
RTC,
you
have
the
two
aspects.
B
You
have
the
JavaScript
API,
which
most
of
the
web
developer
interested
in
and
then
you
have.
What
you
know
is
a
change
on
the
wire
with,
of
course,
is
more
of
the
scope
of
IETF
and
needs
to
work.
So
if
you
get
a
you
know
satellite
picture
of
the
specification,
even
though
there
are
more
than
20
the
most
important
one
are
listed
here
and
the
good
news
is
all
of
them-
went
into
the
latest
stage
of
recommendation
and
w3c
or
are
already
a
specification
in
IETF
I.
B
Think
that's
the
first
IETF,
where
we
only
need
one
session
of
RTC
web
and
not
to
as
as
we
used
to
so
that's
great.
That
means
consensus
is
reached
for
everything.
That
is
the
specification,
but
that
doesn't
mean
that
the
implementation
actually
is
at
the
same
level.
So
you
went
through
the
specification.
Let's
look
a
little
bit
about
the
implementation
during
the
lifetime
of
web
RTC,
there
was
really
two
pivots
and
for
people
that
want
to
have
all
the
gory
details.
There
is
a
fantastic
block
by
the
the
web,
RTC
Mozilla
team.
B
B
You
can
see
free
main
stage
where
at
the
beginning,
you
were
speaking
about
streams,
so
you
could
get
a
stream
from
your
camera
with
audio
and
video
inside
anywhere
passing
a
string
right,
history,
I'm,
sorry,
and
then
we
went
into
a
track
model
where,
instead
of
saying
you
know,
I
just
want
to
stream.
Actually
I
would
like
to
do
track.
So
one
use
case
that
make
us
think
like
that
was
the
web
cam
plus
screen
sharing.
You
know,
I'm
presenting
a
PowerPoint
I
want
to
stream.
B
My
PowerPoint
and
I
want
to
stream
my
face
in
my
voice,
then
I
will
need
two
video
tracks
and
one
audio
track,
and
that
was
getting
complicated
with
the
stream
API,
among
other
things
that
were
complicated
with
the
stream
API
another
use
case
very
simple
I'm
using
a
mobile
and
I
want
to
switch
during
a
call
between
the
front
camera
and
the
back
camera
right.
This.
This
video
is
the
same
time
might
be
not
the
same
resolution,
but
there
is
no
reason.
B
Why
would
be
complicated,
and
so
we
came
with
a
replace
track
API
that
was
specifically
dedicated
to
that
use
case
when
you
want
to
switch
to
two
tracks
of
the
same
type.
In
that
case,
the
video
type,
while
keeping
the
rest
without
going
through
an
entire
cutting
the
call
renegotiating
the
call
and
restarting
the
call.
B
Eventually
we
brought
in
a
more
fine-grain
API
like
that,
and
we
wanted
to
make
the
the
glue
with
with
the
SDP
and
all
the
exchange
real
format
who
were
using
the
signaling
format
at
that
time,
and
that's
where
the
transceiver
came
and
transceiver
has
a
lot
of
very
good
application,
not
those
that
you're
gonna
see
directly
in
in
an
application.
You're
gonna
write
yourself,
there's
not
a
lot
of
new
API,
but
it
will
allow,
for
example,
for
a
call
to
successfully
go
through
in
a
tenth
of
a
time
me
too
right.
B
So
we
call
that
click
to
Earl
to
first
media,
when
you
click
accept
the
call
button.
How
long
does
it
take
before
you
actually
in
the
call
and
start
talking
with
someone
with
the
original
version?
That
will
be
one
to
two
seconds
with
full
eyes?
Then
we
bring
treacle
eyes.
We
bring
that
down
to
100
something
milliseconds
with
the
things
that
add
transceiver
and
the
new
API
will
bring
in.
You
will
be
able
to
go
close
to
the
experience
you
get
with
a
real
phone
call
today,
which
is
ultimately
what
we
want.
B
There
is
no
difference
between
a
call
over
the
Internet
and
a
call
with
a
real
telephone
line,
no
difference
between
voice
and
audio
right.
So
if
you
look
at
this
free
generation,
not
all
the
browsers
are
equally
advanced
and,
of
course
the
specification
was
still
in
flux.
So
if
we
go
to
the
next
slide,
we
can
see
the
what
was
presented
by
Chrome
last
week.
So
last
week
was
the
technical
plenary
meeting
of
w3c
done
an
hai
at
the
Troy
to
participate
there
and
flew
in
this
morning
and
chrome
presented.
B
That
slide,
which
is,
as
far
as
we
know,
the
latest
state
of
the
art
status
of
about
his
implementation
in
chrome,
so
get
stack,
track,
constrain
receiver,
so
part
of
the
second
generation
of
the
API
are
here,
but
not
all
of
it.
So
the
sender,
which
is
the
Pender
of
the
receiver,
app
track
on
track
and
so
on
is
still
to
be
expected
in
a
few
revision.
B
Lastly,
a
unified
plan,
which
is
the
standard
way
of
doing
simulcast
a
good
way
to
actually
adapt
the
resolution
in
case
of
bad
bandwidth
or
a
lot
of
people
joining
a
call,
is
still
using
Plan,
B
or
old
version
in
Chrome,
and
it's
blocking
a
little
bit
the
standardization
effort
where
Firefox
is
already,
for
example,
using
the
the
real
unified
plan
according
to
chrome,
that
should
be
completed
by
the
end
of
this
year
or
first
quarter
next
year
on
firefox
a
little
bit
simpler.
Everything
is
there
except
transceiver
and
I.
B
B
Safari
is
interesting.
Safari
was
a
little
bit
late
to
the
party,
but
that
gave
us
an
advantage.
They
didn't
have
any
Easter
recall
implementation
of
WebRTC
based
on
older
spec,
so
they
directly
went
for
the
latest
version
of
the
spec,
so
they
directly
went
into
the
track
and
not
the
stream
generation
of
the
API.
Unfortunately,
they
based
on
the
Google
code,
so
it
was
too
complicated
to
switch
to
unify
plan
and
still
using
Plan
B.
B
There
are
a
few
other
things
that
are
still
improve,
above
because
there
are
the
latest
implementation
of
of
WebRTC,
but
one
year
ago
Safari
was
not
supporting
WebRTC.
So
today
we
have
all
the
major
browsers
that
support
web
RTC,
including
Safari
on
iOS,
and
that's
really
a
big
step
forward
right
edge.
B
Well,
it's
difficult
to
answer
for
Microsoft.
They
have
different
approach
depending
on
the
product
and
will
you
ask
to
there's
one
thing
we
know
for
sure
Internet
Explorer
will
never
get
WebRTC.
They
want
people
to
move
away
from
with
all
the
old
windows
and
get
into
Windows
10,
so
they're,
putting
all
the
latest
API
on
edge.
They
think
that
if
they
put
the
WebRTC
API
in
Internet
Explorer,
that
will
give
that
will
not
give
enough
incentive
from
people
to
move
away
from
windows
7
edge
as
to
implementation.
B
Today,
one
is
based
on
low
RTC,
with
a
polyfill
on
top
and
another
one
that
is
the
web,
RTC
1.0,
but
first
generation,
which
is
the
ad
stream
and
remove
stream
implementation.
And
finally,
they
have
a
third
implementation
for
native
that
supports
web
RTC
and
is,
as
far
as
we
know,
burner,
told
me
last
week
the
the
most
advanced
we
support
for
vp9
and
things
like
that,
for
example.
So
originally
the
biggest
problem
with
the
edge
was
that
they
were
only
supporting
a
very
proprietary
codec
called
h.264.
B
You
see
that
was
the
SVC
flavor
of
264
used
by
Skype.
Now
it's
getting
much
better
h.264.
The
vanilla
h.264
is
in
vp8
as
well.
Vp9
with
SVC
is
coming
in
some
of
the
three
different
stacks
they
have
at
Microsoft.
So
here
again
slowly
by
the
end
of
the
year,
things
will
be
interoperable
enough,
so
you
can
initiate
a
call
with
edge
and
receive
a
call
from
any
other
browser
with
at
least
one
codec.
That
will
be
understood
by
each
side.
B
So
w3c,
unlike
IETF,
require
that
test
exists
before
you
can
become
a
standard.
So
we
had
compliance
test
which
is
test
of
the
JavaScript
API
and
that's
very
interesting
for
web
developer,
because
you
can
check
if
not
only
the
API
exists,
but
she
behaved
according
to
the
spec
or
not,
and
so
we
were
not
close
to
consensus
last
year,
so
not
a
lot
of
tests
with
written
and
they
were
written
mainly
by
people
that
were
volunteering
their
time
Herald
over
there
myself
and
someone
called
Dominic
from
the
w3c,
where
basically
the
free
weekend
contributors.
B
B
What's
interesting
is
not
the
number
of
tab
themselves,
but
the
coverage
only
10%
of
the
spec
was
really
tested
one
year
ago
and
nowadays
last
week
we
did
another
check
and
we
went
up
to
70%.
So
we
went
from
10
to
70%
all
thanks
to
we
fought
from
people
here
in
Singapore
working
on
spec's
next
slide
again.
What
does
that
mean
if
you
web
developer?
Well,
if
I'm
a
web
developer,
I
have
two
choices:
I
can
look
at
the
spec
there.
B
Beautiful
I
really
want
what
the
spec
is
selling,
but
the
implementation
in
a
browser
is
not
there.
So
I
need
to
make
a
practical
choice
and
that's
where
things
like
jQuery
came
in
and
that's
where
some
polyfill
and
some
adaptors
are
also
coming
for
WebRTC.
So
if
you
had
to
choose
between
the
browser
you
look
for,
you
could
use
this
test
suite
to
see
which
one
is
the
most
compliant.
So
in
June,
2017
Safari
was
the
most
compliant.
Oh,
my
god
that
was
a
shock
for
Firefox.
B
Well,
they
were
not
the
most
compliant
by
by
a
lot
and
still
50%
of
the
test.
We're
family
right.
So
those
tales
are
very
fine
granularity
and
you
have
to
take
them
into
account.
I
think
the
presentation
we
did
before
in
terms
of
third
or
second
generation
and
where
they
are
is,
is
giving
you
a
better
idea.
So
Firefox
is
great
getting
the
latest
thing
in.
They
have
almost
everything
there.
B
You
want
to
test
the
latest
thing
test
test
it
against
Firefox,
Chrome
and
Safari
are
not
far
away
behind
and
you
can
expect
everything
to
stabilize
by
quarter.
1,
2018
and
I
know
you
heard
that
before,
but
before
the
specs
were
still
in
flux,
now
they're
in
candidate
recommendation,
which
means
there
will
no
be
any
change
in
the
API.
So
in
the
object
that
you
can
use
in
a
browser,
so
the
only
difference
now
is
whether
they
implemented
or
not
right.
B
So
that's
that's
the
situation
as
of
today
to
be
able
to
test
and
to
make
the
things
better.
The
browser
vendors
beyond
the
usual
JavaScript
testing,
also
implementing
the
new
new
new
test
tools,
especially
one
kite
that
was
developed
here
in
Singapore,
for
all
the
browser
vendors
to
actually
test
specifically
web
RTC.
In
the
cases
where
having
only
one
browser
at
a
time
is
not
enough.
Nowaday,
the
JavaScript
API
is
pretty
ok,
everybody
know
what
they
need
to
do
to
make
it
work.
B
But
what
doesn't
work
is
when
many
people
try
to
connect
each
other
right
edge,
try
to
connect
to
Safari
in
the
same
call
with
someone
on
Chrome
on
different
operating
system.
That's
not
something!
We
had
a
tool
as
a
standard
Committee
to
test
before,
and
we
didn't
have
a
lot
of
visibility
in
that
and
that's
where
we
were
getting
most
tickets
from
from
the
users.