WebRTC 1.0规范详解：实时浏览器通信标准

webrtc

需积分: 10 123 浏览量更新于2024-07-28 收藏 534KB DOC 举报

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

领优惠券(最高得80元）

"WebRTC1.0:实时浏览器间通信" WebRTC（Web Real-Time Communication）是一种在浏览器之间实现实时通信的技术，它允许用户在不借助任何插件的情况下进行音频、视频通话以及数据共享。W3C（World Wide Web Consortium）是WebRTC规范的主要制定者，确保了该技术在不同浏览器之间的兼容性和标准化。最新编辑草案为2012年5月30日的版本，链接指向了http://dev.w3.org/2011/webrtc/editor/webrtc-20120530.html。这个草案是由来自Ericsson的Adam Bergkvist、Voxeo的Daniel C. Burnett、Cisco的Cullen Jennings和Mozilla的Anant Narayanan等专家共同编辑的。初始规范由Google的Ian Hickson编写，自2004年至2011年间，Apple、Mozilla Foundation和Opera Software ASA拥有版权。2011年7月26日后，所有变更由W3C WebRTC工作组进行，并遵循W3C的版权规则。 WebRTC规范的核心目标是提供一套API（应用程序编程接口），这些API能够处理音视频流的捕获、编码、传输和解码，同时确保数据的安全性。其主要内容包括： 1. **getUserMedia**: 这个API允许网页获取用户的媒体输入设备，如摄像头和麦克风，以便进行音视频流的采集。 2. **RTCPeerConnection**: 是WebRTC中最核心的组件，负责建立和维护两个浏览器之间的直接通信信道，支持音频、视频流的实时传输，以及数据通道的创建。 3. **RTCDataChannel**: 提供双向数据传输功能，允许用户在浏览器之间交换任意类型的数据，不受限于音视频流。 4. **Signaling**: 在两个浏览器之间建立连接时，需要通过信号通道（通常是一个非WebRTC的通信机制，如WebSocket或HTTP长轮询）来传递SDP（Session Description Protocol）和ICE（Interactive Connectivity Establishment）信息，以协商和建立连接。 5. **Security**: WebRTC采用了SSL/TLS加密，确保了音视频通信和数据传输的安全性。 6. **STUN/TURN**: STUN（Session Traversal Utilities for NAT）服务器帮助穿越网络地址转换（NAT），TURN（Traversal Using Relays around NAT）服务器则用于在STUN失败时作为中继，以克服网络访问障碍。 WebRTC的出现极大地推动了互联网应用的发展，使得在线教育、远程医疗、协作办公等多个领域受益。它不仅简化了开发流程，而且提高了用户体验，因为用户不再需要安装额外的插件或软件即可享受实时通信服务。随着技术的不断演进，WebRTC已成为现代Web应用不可或缺的一部分。

资源详情

资源推荐

AMediaStreamTrackobject’s reference to itsMediaStreamin the non-local media source case (an RTP source, as is the
case for aMediaStreamreceived over aPeerConnection) is always strong.
When a track belongs to aMediaStreamthat comes from a remote peer and the remote peer has permanently stopped 
sending data theendedeventmustbe fired on the track, as specified in [GETUSERMEDIA]. [[ OPEN ISSUE: How do you
know when it has stopped? This seems like an SDP question, not a media-levelquestion.]]
A track in aMediaStream, received with aPeerConnection,musthave itsreadyStateattribute [GETUSERMEDIA] set
toMUTED(1) until media data arrives.
In addition, aMediaStreamTrackhas itsreadyStateset toMUTEDon the B-side if the A-side disables the 
correspondingMediaStreamTrackin theMediaStreamthat is being sent. When the addstream event triggers on 
aPeerConnection, allMediaStreamTrackobjects in the resultingMediaStreamare muted until media data can be read
from the RTP source. [[ OPEN ISSUE: How do you know when it has been disabled? This seems like an SDP question, 
not a media-levelquestion.]]
3.3AudioMediaStreamTrack
TheAudioMediaStreamTrackis a specialization of of a normalMediaStreamTrackthat only carries audio and is 
extended to have the capability to send and/or receive DTMF codes.
interface AudioMediaStreamTrack : MediaStreamTrack {
    readonly attribute boolean canInsertDTMF;
    void insertDTMF (DOMString tones, optional long duration);
};
3.3.1Attributes
canInsertDTMFof typeboolean, readonly
ThecanInsertDTMFattributemustindicate if theAudioMediaStreamTrackis capable of sending DTMF.
3.3.2Methods
insertDTMF
When aAudioMediaStreamTrackobject’sinsertDTMF()method is invoked, the user agentmustqueue a task 
that that sends the DTMF tones.
The tone parameters is treated as a series of characters. The characters 0 to 9, A to D, #, and * generated the 
associated DTMF tones. The characters a to d are equivalent to A to D. The character , indicates a an delay of 2 
seconds before processing the next character in the tones parameter. Unrecognized characters are ignored.
The duration parameters indicates the duration in ms to play the each DTMF passed in the tones parameters. 
The duration can not be more than 6000 or less than 70. The default duration is 100 ms for each tone. The gap 
between tonesmustbe at least 50 ms but should be as short as possible. [[OPEN ISSUE: How are invalid values
handled?]]
If insertDTMF is called on the same object while an existing task for this object is generate DTMF is still running, 
the previous task is canceled. Calling insertDTMF with an empty tones parameter can be used to cancel any 
tones currently being send.

Editor Note: We need to add a callback that is set on the object that is called after the tones are sent. This
is needed to allow the application to know when it can send new tones without canceling the tones that 
are currently being sent.
Editor Note: It seems we would want a callback or event for incoming tones. The proposal sent to the list had them 
played as audio to the speaker but I don’t see how that is useful.
Parameter Type Nullable Optiona
l
Description
tones
DOMString
✘ ✘
duration
long
✘ ✔
Return type:void
4.Peer-to-peer connections
APeerConnectionallows two users to communicate directly, browser to browser. Communications are coordinated via a
signaling channel which is provided by unspecified means, but generally by a script in the page via the server, e.g. 
usingXMLHttpRequest.
CallingnewPeerConnection(configuration)creates aPeerConnectionobject.
Theconfigurationhas the information to find and access the [STUN] and [TURN] servers. There may be multiple servers 
of each type and any TURN server also acts as a STUN server.
A PeerConnection object has an associated ICE Agent, PeerConnection state, and ICE State. These are initialized when 
the object is created.
When thePeerConnection()constructor is invoked, the user agentmustrun the following steps. This algorithm has a 
synchronous section (which is triggered as part of the event loop algorithm).
1. Create an ICE Agent and letconnection’sPeerConnection     ICE Agent   be that ICE Agent and provide it the STUN
and TURN servers from the configuration array. The [ICE] will proceed with gathering as soon as the 
IceTransports constraint is not set to "none". At this point the ICE Agent does not know how many ICE 
components it needs (and hence the number of candidates to gather) but it can make a reasonable assumption 
and as the PeerConnection object gets more information, it can adjust the number of components.
2. Setconnection’sPeerConnection     readiness state   to"new".
3. Setconnection’sPeerConnection     ice state     to"new".
4. Letconnection’slocalStreamsattribute be an empty read-onlyMediaStreamarray.
5. Letconnection’sremoteStreamsattribute be an empty read-onlyMediaStreamarray.
6. Returnconnection, but continue these steps asynchronously.
7. Await a stable state. The synchronous section consists of the remaining steps of this algorithm.
During the lifetime of the PeerConnection object, the following procedures are followed:
1. If the ice state is "new" and the IceTransports constraint is not set to "none", itmustqueue a task to start 
gathering ICE address and set the ice state to "gathering".
2. If the ICE Agent has found one or more candidate pairs for any MediaTrack that forms a valid connection, the ICE
state is changed to "connected".
3. When the ICE Agent finishes checking all candidate pairs, if at least one connection has been found for some 
MediaTrack, the iceState is changed to "completed" and if no connection has been found for any MediaTrack, the