WebRTC allows real-time communication between browsers using peer-to-peer connections over the closest network route. It provides JavaScript access to a user's webcam and microphone via getUserMedia() and allows data exchange between clients via DataChannels. Connections are established through an Offer/Answer protocol where one client creates an offer and the other accepts it, then responds with an answer. This exchange uses the JavaScript Session Establishment Protocol to negotiate parameters like codecs and exchange ICE candidates for NAT traversal. Once the offer and answer are exchanged and accepted, a direct remote connection is established between clients for audio, video, and data.

1. WebRTC
Real-time Communication Between Browsers
http://www.w3.org/TR/webrtc/

2. Real Time Communication
• Initial Draft available: August 2011
• Peer-to-Peer connections over closest network
route
• getUserMedia()
– Provides javascript access to WebCam
– Provides javascript access to Microphone
• DataChannels
– Provides SSL connections between two P2P clients
– Can exchange data in String or TypedArray format

3. Peer-to-Peer Connections
• Offer-Answer connection agreements
– Request Offer/Answer Protocol (ROAP)
• Client A : Create Offer
• Client B : Accept Offer
• Client B : Create Answer
• Client A : Accept Answer
• Offer-Answer uses text-based JSEP messages
– Javascript Session Establishment Protocol
– Exchange ICE Candidates for NAT traversal

4. Example JSEP Offer (text)
v=0
o=Mozilla-SIPUA-33.0a1 17866 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:baad1344
a=ice-pwd:445db0ec9d0d0dfffbedbbeasdfff53d434409
a=fingerprint:sha-256
9F:34:0B:AF:02:D4:EB:DE:97:4B:0B:FE:66:27:2B:FC:80:68:6D:25:57:6F:4B:42:70:5C:B5:03:BE:B4:E2:E5
m=application 52523 DTLS/SCTP 5000
c=IN IP4 123.12.1.206
a=sctpmap:5000 webrtc-datachannel 16
a=setup:actpass
a=candidate:0 1 UDP 2130379007 123.12.1.123 52569 typ host
a=candidate:2 1 UDP 1694236671 123.123.123.47 52569 typ srflx raddr 123.11.1.116 rport 52369
a=candidate:2 2 UDP 1694236670 123.123.123.47 54617 typ srflx raddr 123.11.1.116 rport 52317

5. JSEP Exchange
• Fully compatible with Session Exchange over
RFC 1149 and its amendment, RFC 2549
Avian Carrier
Network Connection
Client A Client B
Avian Carrier
Avian Carrier

6. Connection Flow
Network Connection
Client A Client B
1
Both browsers must be on machines with network connectivity. This can be
either internet access or local LAN access over a router.
Assuming both machines have loaded the required WebRTC Javascript content,
no connectivity is required at this point to the original web page’s server.

7. Connection Flow
Network Connection
Client A Client B
2
Create OFFER
To begin a WebRTC exchange, one client must generate an Offer request. This
data includes what channels are desired, such as allowing or disallowing Video
or Audio channels, or the request to include DataChannels for communication.
This process may query all information available regarding ClientA’s current
network and audio/video status, such as IP addresses or available audio/video
bit-rates.

8. Connection Flow
Network Connection
Client A Client B
OFFER
3
Signal Offer to B
This Offer data is presented to Client B in any method available. There is no
digital or format requirement for this data transfer, and it is fully possible for
this data to be printed out and manually typed at the remote machine.
As long as the Offer request is reconstructed at Client B, the process may
continue.

9. Connection Flow
Network Connection
Client A Client B
4
Accept OFFER
Create ANSWER
Upon receiving an Offer, Client B is provided the chance to evaluate the criteria of
the Offer, such as available Audio, Video, and DataChannels expected, and
possibly propose alterations before this Offer is accepted.
Should Client B ignore this request, the Offer may be accepted by any other
machine, as Client A has no knowledge it has been read. Should Client B agree to
the conditions of the offer, it can Accept this offer and generate an answer which
will include Client B’s available IP addresses and supported bit-rates or formats.

10. Connection Flow
Network Connection
Client A Client B
5
Signal Answer to A
ANSWER
Using the extremely open flexibility of Offer and Answer protocols, Client B will
attempt to communicate it’s acceptance of the offer. Client B is now prepared
for the potential upcoming connection, and is awaiting connectivity requests
over the network.
No further communication is required to Client B, and Client B’s PeerConnection
will only accept connections that include the secure tokens present in the
Offer/Answer messages.

11. Connection Flow
Network Connection
Client A Client B
6
Accept ANSWER
Client A will process the provided Answer request. At this point Client A has the
options to respond to any change requests Client B has requested through
future exchanges.
Until the Answer is accepted, Client A may consider any other Answers that have
been provided by other Clients to Client A’s specific Offer.
Upon accepting, both Client A and Client B will then be in possession of both A
and B’s understanding of local and remote bit-rates, IP Addresses, and
capabilities. Client A’s offer request will no longer be usable.

12. WebRTC Connection Complete
Remote
RTC Connection Established
Client A Client B
Local
Local
Remote
Audio
Video
Data
After the final exchange, no further signals are required, and a remote
connection will open between Client A and B supporting any combination of
Audio, Video, and Data