参考：
www.csdn/article/2012-08-14/2808592
www.leiphone/0925-ce6093-webrtc.html
www.infoq/cn/news/2011/06/google-webrtc
WebRTC 百度 百科
Dongdong Deng <LibFetion@gmail> 写的WebRTC ppt
webrtcbook
Sam Dutton(Google Chrome Developer Relations) 写的WebRTC介绍
Harald Alvestrand写的RTCWEB Architecture
Colin Perkins – University of Glasgow写的WebRTC PPT
WebRTC :Ericsson Review 1.2012
WebRTC简介
WebRTC（Web Real-Time Communication，网络实时通信） 项目的最终目的主要是让Web开发者能够基于浏览器（Chrome\FireFox\...）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程， 只需编写简单的Javascript程序即可实现 ，W3C等组织正在制定Javascript 标准API，目前是WebRTC 1.0版本，Draft状态；另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台，形成开发者与浏览器厂商良好的生态环境。同时，Google也希望和致力于让WebRTC的技术成为HTML5标准之一，可见Google布局之深远。
WebRTC提供了视频会议的核心技术，包括 音视频的采集、编解码、网络传输、显示 等功能，并且还支持跨平台：windows，linux，mac，android。
WebRTC是一项在浏览器内部进行实时视频和音频通信的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得一项技术.
谷歌2011年6月3日宣布向开发人员开放WebRTC架构的源代码。这个源代码将根据没有专利费的BSD（伯克利软件发布）式的许可证向用户提供。目前，开发人员可访问并获取WebRTC的源代码、规格说明和工具等。
Google希望开源的WebRTC技术能够获得越来越多的浏览器厂商支持，WebRTC的网站已经宣布将在Chrome、Firefox和Opera上实现相应的API接口。Opera首席技术官H kon Wium Lie对媒体表示，Google能够把价值不菲的代码贡献出来非常了不起，Opera一直希望能够在浏览器中实现实时通信技术。
目前有关Web实时通信的技术标准正在制定当中，W3C的Web Real-Time Communication工作组在May 2011成立，
W3C的最新标准见 /2011/webrtc/editor/webrtc.html
最新版本是W3C Editor's Draft 16 January 2013
Editors:
Adam Bergkvist, Ericsson
Daniel C. Burnett, Voxeo
Cullen Jennings, Cisco
Anant Narayanan, Mozilla (until November 2012)
从作者所属公司及排序中可见 W3C 支持者的情况。
WebRTC实现了基于网页的视频会议，标准是WHATWG 协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯（Real-Time Communications (RTC)）能力。
HTTP->WebRTC演进路径
HTTP(Pre AJAX)：原始web，一页里发送请求后才返回另一页，如Geocities
AJAX(2004)：更新页面不需要刷新.如GMail.
Web Sockets(2008)：页面能建立双向通信（通过服务器中介)，如Trello。
WebRTC(2012)：页面之间的通信。
WebRTC的IETF标准
标准名称 Title Date
draft-alvestrand-rtcweb-stats-registry-00 A Registry for WebRTC statistics identifiers 2012/9/24
draft-burman-rtcweb-h264-proposal-00 H.264 as Mandatory to Implement Video Codec for WebRTC 2012/10/15
draft-dbenham-webrtc-videomti-00 H.264/AVC as Mandatory-to-Implement Video Codec for RTCweb 2012/10/15
draft-ietf-rtcweb-audio-01 WebRTC Audio Codec and Processing Requirements 2012/11/22
draft-ietf-rtcweb-rtp-usage-05 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP 2012/10/22
draft-jesup-rtcweb-data-protocol-03 WebRTC Data Channel Protocol 2012/9/7
draft-marjou-rtcweb-video-codec-00 Video codec for WebRTC. 2012/10/15
draft-nandakumar-rtcweb-sdp-00 SDP for the WebRTC 2012/10/15
draft-ohlsson-rtcweb-sdes-support-01 Support of SDES in WebRTC 2012/8/20
draft-reddy-rtcweb-mobile-00 Problems with WebRTC in Mobile Networks 2013/1/14
draft-yan-rtcweb-desktop-cloud-00 WebRTC Realization in Desktop Cloud 2012/9/12
WebRTC的W3C标准
W3C的最新标准见 /2011/webrtc/editor/webrtc.html
WebRTC架构图
架构图颜标识说明：
（1）紫部分是Web开发者API层；
（2）蓝实线部分是面向浏览器厂商的API层
（3）蓝虚线部分浏览器厂商可以自定义实现
Web API——第三方开发人员用来开发基于Web的应用，如视频聊天。
WebRTC Native C++ API——浏览器厂商用于实现Web API的函数集。
Session Management—— 抽象 session层，支持调用构建和管理层，由 应用开发者来决定如何实现协议。
VoiceEngine——音频媒体链的框架，从声卡到网络。
iSAC——一种用于VoIP和流音频的宽带和超宽带音频编解码器，iSAC采用16 kHz或32 kHz的采样频率和12—52 kbps的可变比特率。
iLBC——用于VoIP和流音频的窄带语音编解码器，使用8 kHZ的采样频率，20毫秒帧比特率为15.2 kbps，30毫米帧的比特率为13.33 kbps，标准由IETF RFC 3951和3952定义。
NetEQ for Voice——动态抖动缓存和错误隐藏算法，用于缓解网络抖动和丢包引起的负面影响。在保持高音频质量的同时尽可能降低延迟。
VideoEngine——视频媒体链的框架，从相机像头到网络，从网络到屏幕。
VP8——来自于WebM项目的视频编解码器，非常适合RTC，因为它是为低延迟而设计开发的。
Image enhancements——消除通过摄像头获取的图片的视频噪声等。
Architecture layers
● Data transport
○ Data path establishment: NAT traversal using ICE
○ Transmission: UDP (TCP backup)
○ Congestion management
● Data en
capsulation
○ RTP
○ Some non-RTP method for non-media data
● Data formats
○ Codec choices go here
● Connection management / signaling
● Presentation and control
● Local system support functions
Security in context
● All components (except the RTCWEBimplementing browser) must be assumed evil
● Browser that executes JS using RTCWEB is  responsible for both its own security and that of
victims it can reach (such as other tabs in the same browser, or other devices on the same LAN)
● Keep trust to a minimum
Data Transport
● Data path establishment: NAT traversal using ICE
○ Secures against "voice hammer" attacks
● Transmission: UDP (TCP backup)
○ Relays are sometimes needed
● Congestion management is necessary
○ Self-fair
○ Plays well with others
○ Would be nice not to invent one here
Data framing and securing
● RTP exists. We will reuse it.
● We have no need to carry unencrypted data.
○ SRTP for media
○ DTLS for non-media data
● DTLS-SRTP key negotiation
○ SDES key negotiation allows for retrospective decoding of wiretap data, reveals key to Web browser
● Note: UI issues are important for security
○ Mostly not IETF specs, but IETF knowledge informs W3C discussions
Data formats
● Data formats must be negotiated
○ Any consenting adults can agree on a data format
● A mandatory to implement codec prevents interoperability failure
● Need to focus on requirements for the baseline case (where MTI would come into play)
Connection Management
● Needed for setup:
○ Negotiation of data formats, transport options and security parameters (incl keys)
● Needed while connected:
○ Reaction to changed connectivity and needs (ex: resolutions)
● Least controversial proposal: ROAP
○ Specify a format for JS-Browser exchange
○ Usable as browser-to-browser format
○ Possible to gateway to SIP and XMPP
● We expect innovation in what-connects-to-what
● Active area of discussion!
Other Local Functions
● User action needs to cause net communication
○ Local and remote media mute -> stop/start sending
○ Display window size change -> change resolution
● Functions are needed to achieve usable applications
○ Automatic Gain Control -> consistent audio levels
○ Acoustic Echo Cancellation -> no feedback loops
○ Dynamic jitter buffers -> consistent (low) playout times
WebRTC的各种应用场景
Jingle(XMPP)
这种媒体流连接如何混音？如果在终端上混音，如何支持多达几十方的会议?
Signalling: make me an offer
1. Caller sends offer.
2. Callee receives offer.
3. Callee sends answer.
4. Caller receives answer.
Signalling: find me a candidate
1. Caller creates RTCPeerConnection object.
2. If success, c
allback passed IceCandidate.
3. Callee sends IceCandidate to callee.
4. Callee creates a new remote IceCandidate, adds to remote description.
5. Ping!
REST
代码例
PeerConnection位于WebRTC Native C++ API的最上层，它的代码实现来源于libjingle（一款p2p开发工具包），目前被应用于WebRTC中。其中关键的两个类定义是：
class  PeerConnectionObserver {
public:
virtual void OnError();
virtual void OnSignalingMessage(const std::string& msg);
virtual void OnAddStream(const std::string& stream_id,
int channel_id,
bool video);
virtual void OnRemoveStream(const std::string& stream_id,
int channel_id,
bool video);
};
该类定义了一个抽象的观察者。开发人员应该继承实现自己的观察者类。
class  PeerConnection {
public:
explicit PeerConnection(const std::string& config);
bool Initialize();
void RegisterObserver(PeerConnectionObserver* observer);
bool SignalingMessage(const std::string& msg);
bool AddStream(const std::string& stream_id, bool video);
bool RemoveStream(const std::string& stream_id);
bool Connect();
void Close();
bool SetAudioDevice(const std::string& wave_in_device,
const std::string& wave_out_device);
bool SetLocalVideoRenderer(cricket::VideoRenderer* renderer);
bool SetVideoRenderer(const std::string& stream_id,
cricket::VideoRenderer* renderer);
bool SetVideoCapture(const std::string& cam_device);
};
具体的函数说明可以查看相应的API介绍。
正如Google所说的，它一直在参与制定和实现 HTML 5标准中的视频会议和p2p通信部分 ，虽然还不是正式标准，但是我们可以从草案的示例中看到未来Web开发人员的使用情况：
// the first argument describes the STUN/TURN server configuration
var local = new PeerConnection('TURNS example', sendSignalingChannel);
local.signalingChannel(...); // if we have a message from the other side, pass it along here
// (aLocalStream is some GeneratedStream object)
local.addStream(aLocalStream); // start sending video
function sendSignalingChannel(message) {
... // send message to the other side via the signaling channel
}
function receiveSignalingChannel (message) {
// call this whenever we get a message on the signaling channel
local.signalingChannel(message);
}
/
/ (videoElement is some <video> element)
videoElement.s
rc = ObjectURL(event.stream);
};
WebRTC架构组件介绍
(1) Your Web App
Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。
(2) Web API
面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用。
这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三类,。
Network Stream API
MediaStream：MediaStream用来表示一个媒体数据流。
MediaStreamTrack在浏览器中表示一个媒体源。
RTCPeerConnection
RTCPeerConnection: 一个 RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。
RTCIceCandidate ：表示一个 ICE协议 的候选者。
RTCIceServer: 表示一个ICE Server。
Peer-to-peer Data API
w3mobile下载DataChannel：数据通道( DataChannel)接口表示一个在两个节点之间的双向的数据通道 。
(3) WebRTC Native C++ API
本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。
(4) Transport / Session
传输/会话层
会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议 
a. RTP Stack协议栈
Real Time Protocol
b. STUN/ICE 
可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接。
c. Session Management
一个抽象的会话层， 提供会话建立和管理功能。该层协议留给应用开发者自定义实现。
(5) VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。
VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先。
a. iSAC
Internet Speech Audio Codec
针对VoIP和音频流的宽带和超宽带音频编解码器，是WebRTC音频引擎的默认的编解码器
采样频率：16khz，24khz，32khz；（默认为16khz）
自适应速率为10kbit/s ~ 52kbit/；
自适应包大小：30~60ms；
算法延时：frame + 3ms
b. iLBC
Internet Low Bitrate Codec
VoIP音频流的窄带语音编解码器
采样频率：8khz；
20ms帧比特率为15.2kbps
30ms帧比特率为13.33kbps
标准由IETF RFC3951和RFC3952定义
c. NetEQ for Voice
针对音频软件实现的语音信号处理元件
NetEQ算法：自适应抖动控制算法以及语音包丢失隐藏算法。使其能够快速且高解析度地适应不断变化的网络环境，确保音质优美且缓冲延迟最小。
是GIPS公司独步天下的技术，能够有效的处理由于网络抖动和

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。