webRTC

時間 2019-11-09

標籤 webrtc 简体版

原文原文鏈接

WebRTC（Web實時通訊）是一種技術，使Web應用程序和網站來捕捉和可選的音頻和/或視頻流媒體，以及交換任意數據之間的瀏覽器不須要中介。該系列標準包括WebRTC可以共享數據和執行會議的對等，而不須要用戶安裝插件或任何其餘第三方軟件。html

WebRTC由幾個相互關聯的應用程序接口和協議共同來實現。你會發現這裏將幫助你理解WebRTC的基礎，如何設置和使用數據和媒體的鏈接、更多。git

接口github

1.RTCPeerConnection

表示本地計算機和遠程節點之間的鏈接的WebRTC。它是用來處理兩個對等體之間的高效的數據流web

2.RTCSessionDescription

表示會話的參數。每一個 rtcsessiondescription 由描述型指示提供/應答談判過程的描述和對 SDP 描述符的會議的一部分。瀏覽器

3.RTCIceCandidate服務器

表明候選人的網絡鏈接創建（ice）創建一個 rtcpeerconnection服務器。網絡

4.RTCIceTransportsession

表明一個互聯網鏈接創建信息（ice）運輸。app

5.RTCPeerConnectionIceEventless

表示與目標對象有關的事件發生的事件，一般一個rtcpeerconnection。只有一個事件是這種類型：icecandidate。

6.RTCRtpSender

Manages the encoding and transmission of data through a MediaStreamTrack 對於 RtcPeerConnection

7.RTCRtpReceiver

負責接收和解碼的數據經過一個 rtcpeerconnection 對於 mediastreamtrack。

8.RTCTrackEvent

Indicates that a new incoming MediaStreamTrack was created and an associated RTCRtpReceiver object was added to the RTCPeerConnection object.

9.RTCCertificate

Represents a certificate that an RTCPeerConnection uses to authenticate.

10.RTCDataChannel

Represents a bi-directional data channel between two peers of a connection.

RTCDataChannelEvent

Represents events that occur while attaching a RTCDataChannel to a RTCPeerConnection. The only event sent with this interface is datachannel.

RTCDTMFSender

Manages the encoding and transmission of dual-tone multi-frequency (DTMF) signaling for an RTCPeerConnection.

RTCDTMFToneChangeEvent

Indicates an occurrence of a of dual-tone multi-frequency (DTMF). This event does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated).

RTCStatsReport

Reports stats for a given MediaStreamTrack asynchronously.

RTCIdentityProviderRegistrar

Registers an identity provider (idP).

RTCIdentityProvider

Enables a user agent is able to request that an identity assertion be generated or validated.

RTCIdentityAssertion

Represents the identity of the a remote peer of the current connection. If no peer has yet been set and verified this interface returns null. Once set it can't be changed

RTCIdentityEvent

Represents an identity assertion generated by an identity provider (idP). This is usually for an RTCPeerConnection. The only event sent with this type is identityresult.

RTCIdentityErrorEvent

Represents an error associated with the identity provider (idP). This is usually for an RTCPeerConnection. Two events are sent with this type: idpassertionerror and idpvalidationerror.

GuidesEDIT

WebRTC architecture overview

Beneath the APIs that developers use to create and use WebRTC connections lie a number of network protocols and connectivity standards. This brief overview covers these standards.

Lifetime of a WebRTC session

WebRTC lets you build peer-to-peer communication of arbitrary data, audio, or video—or any combination thereof—into a browser application. In this article, we'll look at the lifetime of a WebRTC session, from establishing the connection all the way through closing the connection when it's no longer needed.

WebRTC API overview

WebRTC consists of several interrelated APIs and protocols which work together to support the exchange of data and media between two or more peers. This article provides a brief overview of each of these APIs and what purpose it serves.

WebRTC basics

This article takes you through the creation of a cross-browser RTC App. By the end of it, you should have working peer-to-peer data channel and media channel.

WebRTC protocols

This article introduces the protocols on top of which the WebRTC API is built.

Using WebRTC data channels

This guide covers how you can use a peer connection and an associated RTCDataChannel to exchange arbitrary data between two peers.

WebRTC connectivity

This article describes how the various WebRTC-related protocols interact with one another in order to create a connection and transfer data and/or media among peers.

TutorialsEDIT

Improving compatibility using WebRTC adapter.js

The WebRTC organization provides on GitHub the WebRTC adapter to work around compatibility issues in different browsers' WebRTC implementations. The adapter is a JavaScript shim which lets your code to be written to the specification so that it will "just work" in all browsers with WebRTC support.

Taking still photos with WebRTC

This article shows how to use WebRTC to access the camera on a computer or mobile phone with WebRTC support and take a photo with it.

A simple RTCDataChannel sample

The RTCDataChannel interface is a feature which lets you open a channel between two peers over which you may send and receive arbitrary data. The API is intentionally similar to the WebSocket API, so that the same programming model can be used for each.

Signaling and two-way video calling

Sample, we take the web socket chat system we've created in another example and add the ability to make video calls. The chat server is augmented to handle the WebRTC signaling.

ResourcesEDIT

Protocols

WebRTC-proper protocols

Related supporting protocols

SpecificationsEDIT

Specification	Status	Comment
WebRTC 1.0: Real-time Communication Between Browser	Working Draft	The initial definition of the API of WebRTC.
Media Capture and Streams	Editor's Draft	The initial definition of the object conveying the stream of media content.
Media Capture from DOM Elements	Editor's Draft	The initial definition on how to obtain stream of content from DOM Elements

In additions to these specifications defining the API needed to use WebRTC, there are several protocols, listed under resources.

SDPEDIT

Session Description Protocol (SDP) is a standard for describing the multimedia content of the connection such as resolution, formats, codecs, encryption, etc. so that both peers can understand each other once the data is transferring. This is, in essence, the metadata describing the content and not the media content itself.

The offer/answer process is performed both when a call is first established, but also any time the call's format or other configuration needs to change. Regardless of whether it's a new call, or reconfiguring an existing one, these are the basic steps which must occur to exchange the offer and answer, leaving out the ICE layer for the moment:

The caller calls RTCPeerConnection.createOffer() to create an offer.
The caller calls RTCPeerConnection.setLocalDescription() to set that offer as the local description (that is, the description of the local end of the connection).
The caller uses the signaling server to transmit the offer to the intended receiver of the call.
The recipient receives the offer and calls RTCPeerConnection.setRemoteDescription()to record it as the remote description (the description of the other end of the connection).
The recipient does any setup it needs to do for its end of the call, including adding outgoing streams to the connection.
The recipient then creates an answer by calling RTCPeerConnection.createAnswer().
The recipient calls RTCPeerConnection.setLocalDescription() to set the answer as its local description. The recipient now knows the configuration of both ends of the connection.
The recipient uses the signaling server to send the answer to the caller.
The caller receives the answer.
The caller calls RTCPeerConnection.setRemoteDescription() to set the answer as the remote description for its end of the call. It now knows the configuration of both peers. Media begins to flow as configured.