WebRTC实时通信实战指南

webrtc

需积分: 21 71 浏览量更新于2024-07-17 收藏 24.28MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

《WebRTC实时通信》是一本由Salvatore Loreto和Simon Pietro Romano合著的专业书籍，该书针对WebRTC技术进行了深入探讨和实践指导。WebRTC（Web Real-Time Communication）是HTML5的一项核心技术，旨在使网页浏览器和其他网络应用能够进行实时音视频通信，无需依赖第三方插件。这本书于2014年出版，版权归Salvatore Loreto和Simon Pietro Romano所有，并获得了O'Reilly Media的发行，反映了作者在实时通信领域的最新研究成果和实践经验。书中详细介绍了WebRTC的工作原理、架构、关键组件（如RTCPeerConnection、RTCDataChannel等）、安全考量以及如何在实际项目中集成和优化WebRTC功能。读者可以从中了解到如何利用WebRTC实现视频会议、实时聊天、文件共享等实时交互应用场景。此外，该书还涵盖了如何处理网络状况变化、媒体编码与解码、跨平台兼容性等问题，以及如何处理隐私和安全问题，确保数据传输的安全可靠。作为第一版，该书在2014年4月15日首次发布，O'Reilly提供了在线版本供读者获取。对于教育机构、企业用户或个人希望通过深入学习来提升WebRTC技能的人士，这是一本不可或缺的参考资源。编者Simon St. Laurent和Allyson MacDonald对内容进行了精心编辑，生产编辑Kristen Brown、Copyeditor Charles Roumeliotis、Proofreader Eliahu Sussman、Indexer Angela Howard等专业人士参与了不同阶段的工作，保证了书籍的质量。封面设计由Karen Montgomery负责，内部设计则由David Futato操刀，插图则出自Rebecca Demarest之手。如果你想深入了解WebRTC技术并在开发过程中应用它，这本书会为你提供扎实的基础理论和实用案例，帮助你在实时通信领域取得成功。如果你在阅读过程中遇到任何疑问，可以参考书中的修订历史，或者访问O'Reilly官方网站查找最新的更新和答疑。

资源详情

资源推荐

WebRTC Architecture

WebRTC extends the client-server semantics by introducing a peer-to-peer communi‐

cation paradigm between browsers. The most general WebRTC architectural model (see

Figure 1-1) draws its inspiration from the so-called SIP (Session Initiation Protocol)

Trapezoid (RFC3261).

Figure 1-1. The WebRTC Trapezoid

In the WebRTC Trapezoid model, both browsers are running a web application, which

is downloaded from a different web server. Signaling messages are used to set up and

terminate communications. They are transported by the HTTP or WebSocket protocol

via web servers that can modify, translate, or manage them as needed. It is worth noting

that the signaling between browser and server is not standardized in WebRTC, as it is

considered to be part of the application (see “Signaling” on page 5). As to the data path,

a PeerConnection allows media to flow directly between browsers without any inter‐

vening servers. The two web servers can communicate using a standard signaling pro‐

tocol such as SIP or Jingle (XEP-0166). Otherwise, they can use a proprietary signaling

protocol.

The most common WebRTC scenario is likely to be the one where both browsers are

running the same web application, downloaded from the same web page. In this case

the Trapezoid becomes a Triangle (see Figure 1-2).

2 | Chapter 1: Introduction

www.it-ebooks.info

1. DTLS is actually used for key derivation, while SRTP is used on the wire. So, the packets on the wire are not

DTLS (except for the initial handshake).

Signaling

The general idea behind the design of WebRTC has been to fully specify how to control

the media plane, while leaving the signaling plane as much as possible to the application

layer. The rationale is that different applications may prefer to use different standardized

signaling protocols (e.g., SIP or eXtensible Messaging and Presence Protocol [XMPP])

or even something custom.

Session description represents the most important information that needs to be ex‐

changed. It specifies the transport (and Interactive Connectivity Establishment [ICE])

information, as well as the media type, format, and all associated media configuration

parameters needed to establish the media path.

Since the original idea to exchange session description information in the form of Ses‐

sion Description Protocol (SDP) “blobs” presented several shortcomings, some of which

turned out to be really hard to address, the IETF is now standardizing the JavaScript

Session Establishment Protocol (JSEP). JSEP provides the interface needed by an ap‐

plication to deal with the negotiated local and remote session descriptions (with the

negotiation carried out through whatever signaling mechanism might be desired), to‐

gether with a standardized way of interacting with the ICE state machine.

The JSEP approach delegates entirely to the application the responsibility for driving

the signaling state machine: the application must call the right APIs at the right times,

and convert the session descriptions and related ICE information into the defined mes‐

sages of its chosen signaling protocol, instead of simply forwarding to the remote side

the messages emitted from the browser.

WebRTC API

The W3C WebRTC 1.0 API allows a JavaScript application to take advantage of the

novel browser’s real-time capabilities. The real-time browser function (see Figure 1-3)

implemented in the browser core provides the functionality needed to establish the

necessary audio, video, and data channels. All media and data streams are encrypted

using DTLS.

Signaling | 5

www.it-ebooks.info

Datagram Transport Layer Security (DTLS)

The DTLS (Datagram Transport Layer Security) protocol (RFC6347) is designed to

prevent eavesdropping, tampering, or message forgery to the datragram transport of‐

fered by the User Datagram Protocol (UDP). The DTLS protocol is based on the stream-

oriented Transport Layer Security (TLS) protocol and is intended to provide similar

security guarantees.

The DTLS handshake performed between two WebRTC clients re‐

lies on self-signed certificates. As a result, the certificates themselves

cannot be used to authenticate the peer, as there is no explicit chain

of trust to verify.

To ensure a baseline level of interoperability between different real-time browser func‐

tion implementations, the IETF is working on selecting a minimum set of mandatory

to support audio and video codecs. Opus (RFC6716) and G.711 have been selected as

the mandatory to implement audio codecs. However, at the time of this writing, IETF

has not yet reached a consensus on the mandatory to implement video codecs.

The API is being designed around three main concepts: MediaStream, PeerConnec

tion, and DataChannel.

MediaStream

A MediaStream is an abstract representation of an actual stream of data of audio

and/or video. It serves as a handle for managing actions on the media stream, such as

displaying the stream’s content, recording it, or sending it to a remote peer. A Media

Stream may be extended to represent a stream that either comes from (remote stream)

or is sent to (local stream) a remote node.

A LocalMediaStream represents a media stream from a local media-capture device (e.g.,

webcam, microphone, etc.). To create and use a local stream, the web application must

request access from the user through the getUserMedia() function. The application

specifies the type of media—audio or video—to which it requires access. The devices

selector in the browser interface serves as the mechanism for granting or denying access.

Once the application is done, it may revoke its own access by calling the stop() function

on the LocalMediaStream.

6 | Chapter 1: Introduction

www.it-ebooks.info

剩余162页未读，继续阅读

dkddkk

粉丝: 7
资源: 16

WebRTC实时通信实战指南

Safari 的常见开发问题 Safari 的常见开发问题 Safari 的常见开发问题

Safari网页设计指导

WebRTC零基础开发者教程（带目录版本）

webrtc 权威指南 pdf

webrtc音视频实时互动技术 pdf

Android开发使用WebRTC实现通信

webrtc 实时音视频

vue webrtc 实时视频

webrtc 零基础开发者教程 pdf

vue使用webrtc实时监控电脑桌面

音视频WebRTC实时互动直播技术入门与实战

android使用WebRTC实现通信的案例

webrtc native开发实战pdf

aiortc+webrtc

webrtc 压测工具

unity3d webrtc开发包

webrtc 技术交流

socket和WebRTC相比

Android开发使用WebRTC实现用户之间通信

webrtc native开发实战 pdf

最新资源