webrtc雜談（轉）

參考：

http://www.csdn.net/article/2012-08-14/2808592

http://www. leiphone.com/0925-ce6093-webrtc.html

http://www.infoq.com/cn/news/2011/06/google-webrtc

WebRTC 百度 百科

Dongdong Deng <LibFetion@gmail.com> 寫的WebRTC ppt

http://webrtcbook.com

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的最新標準見 http://dev.w3.org/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的最新標準見 http://dev.w3.org/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 encapsulation

○ 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的各類應用場景

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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, callback passed IceCandidate.

3. Callee sends IceCandidate to callee.

4. Callee creates a new remote IceCandidate, adds to remote description.

5. Ping!

 

 

 

 

 

 

 

 

 

 

代碼例

        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.net', 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);

        }

        local.onaddstream = function (event) {

         // (videoElement is some <video> element)

         videoElement.src = URL.getObjectURL(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

        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公司獨步天下的技術，可以有效的處理因爲網絡抖動和語音包丟失時候對語音質量產生的影響。

        PS：NetEQ 也是WebRTC中一個極具價值的技術，對於提升VoIP質量有明顯效果，加以AEC\NR\AGC等模塊集成使用，效果更好。

 d. Acoustic Echo Canceler (AEC)

        回聲消除器是一個基於軟件的信號處理元件，能實時的去除mic採集到的回聲。

e. Noise Reduction (NR)

        噪聲抑制也是一個基於軟件的信號處理元件，用於消除與相關VoIP的某些類型的背景噪聲（嘶嘶聲，風扇噪音等等… …）

 (6) VideoEngine

        WebRTC視頻處理引擎

        VideoEngine是包含一系列視頻處理的總體框架，從攝像頭採集視頻到視頻信息網絡傳輸再到視頻顯示整個完整過程的解決方案。

         a. VP8

        視頻圖像編解碼器，是WebRTC視頻引擎的默認的編解碼器

        VP8適合實時通訊應用場景，由於它主要是針對低延時而設計的編解碼器。

        PS:VPx編解碼器是Google收購ON2公司後開源的，VPx如今是WebM項目的一部分，而WebM項目是Google致力於推進的HTML5標準之一

        b. Video Jitter Buffer

        視頻抖動緩衝器，能夠下降因爲視頻抖動和視頻信息包丟失帶來的不良影響。

        c. Image enhancements

        圖像質量加強模塊

        對網絡攝像頭採集到的圖像進行處理，包括明暗度檢測、顏色加強、降噪處理等功能，用來提高視頻質量。

 

For Web Developers

    提供JS API來實現音視頻採集，傳輸，顯示的Web應用

     navigator.getUserMedia

                navigator.getUserMedia('audio,video', Stream);

     MediaStream

                MediaStreamRecorder record();

                void stop();

     PeerConnection

                sendSignalingChannel()

                receiveSignalingChannel()

 

    Example1:

            Record a short audio message and upload it to the server.

    example1.txt:

    http://www.kgdb.info/wp-content/uploads/2011/11/example1.txt  

 

    Example2:

        PeerConnection Using example2.txt:

    http://www.kgdb.info/wp-content/uploads/2011/11/example2.txt   

 

For App Developers

    Build WebRTC from source:

    Create a working directory, enter it, and run:

    $ gclient config http://webrtc.googlecode.com/svn/trunk

    $ gclient sync --force

    sync will generate native build files for your environment using gyp

    Build

    $cd trunk

    $make

 

    Sample application:

    a simple video chat client and server using the PeerConnection C++ API.

 

    PeerConnection C++ API

    PeerConnection.htm:

    http://www.kgdb.info/wp-content/uploads/2011/11/PeerConnection.htm   

 

代碼庫分析

1、 視頻

        WebRTC的視頻部分，包含採集、編解碼(I420/VP8)、加密、媒體文件、圖像處理、顯示、網絡傳輸與流控(RTP/RTCP)等功能。

        視頻採集---video_capture

        源代碼在webrtc\modules\video_capture\main目錄下，包含接口和各個平臺的源代碼。

        在windows平臺上，WebRTC採用的是dshow技術，來實現枚舉視頻的設備信息和視頻數據的採集，這意味着能夠支持大多數的視頻採集設備；對那些須要單獨驅動程序的視頻採集卡（好比海康高清卡）就無能爲力了。

        視頻採集支持多種媒體類型，好比I420、YUY二、RGB、UYUY等，並能夠進行幀大小和幀率控制。

        視頻編解碼---video_coding

        源代碼在webrtc\modules\video_coding目錄下。

        WebRTC採用I420/VP8編解碼技術。VP8是google收購ON2後的開源實現，而且也用在WebM項目中。VP8能以更少的數據提供更高質量的視頻，特別適合視頻會議這樣的需求。

        視頻加密--video_engine_encryption

        視頻加密是WebRTC的video_engine一部分，至關於視頻應用層面的功能，給點對點的視頻雙方提供了數據上的安全保證，能夠防止在Web上視頻數據的泄漏。

        視頻加密在發送端和接收端進行加解密視頻數據，密鑰由視頻雙方協商，代價是會影響視頻數據處理的性能；也能夠不使用視頻加密功能，這樣在性能上會好些。

        視頻加密的數據源多是原始的數據流，也多是編碼後的數據流。估計是編碼後的數據流，這樣加密代價會小一些，須要進一步研究。

        視頻媒體文件--media_file

        源代碼在webrtc\modules\media_file目錄下。

        該功能是能夠用本地文件做爲視頻源，有點相似虛擬攝像頭的功能；支持的格式有Avi。

        另外，WebRTC還能夠錄製音視頻到本地文件，比較實用的功能。

        視頻圖像處理--video_processing

        源代碼在webrtc\modules\video_processing目錄下。

        視頻圖像處理針對每一幀的圖像進行處理，包括明暗度檢測、顏色加強、降噪處理等功能，用來提高視頻質量。

        視頻顯示--video_render

        源代碼在webrtc\modules\video_render目錄下。

        在windows平臺，WebRTC採用direct3d9和directdraw的方式來顯示視頻，只能這樣，必須這樣。

        網絡傳輸與流控

        對於網絡視頻來說，數據的傳輸與控制是核心價值。WebRTC採用的是成熟的RTP/RTCP技術。

 

 2、音頻

        WebRTC的音頻部分，包含設備、編解碼(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、聲音文件、聲音處理、聲音輸出、音量控制、音視頻同步、網絡傳輸與流控(RTP/RTCP)等功能。

        音頻設備---audio_device

        源代碼在webrtc\modules\audio_device\main目錄下，包含接口和各個平臺的源代碼。

        在windows平臺上，WebRTC採用的是Windows Core Audio和Windows Wave技術來管理音頻設備，還提供了一個混音管理器。

        利用音頻設備，能夠實現聲音輸出，音量控制等功能。

        音頻編解碼---audio_coding

        源代碼在webrtc\modules\audio_coding目錄下。

        WebRTC採用iLIBC/iSAC/G722/PCM16/RED/AVT編解碼技術。

        WebRTC還提供NetEQ功能---抖動緩衝器及丟包補償模塊，可以提升音質，並把延遲減至最小。

        另一個核心功能是基於語音會議的混音處理。

        聲音加密--voice_engine_encryption

        和視頻同樣，WebRTC也提供聲音加密功能。

        聲音文件

        該功能是能夠用本地文件做爲音頻源，支持的格式有Pcm和Wav。

        一樣，WebRTC也能夠錄製音頻到本地文件。

        聲音處理--audio_processing

        源代碼在webrtc\modules\audio_processing目錄下。

        聲音處理針對音頻數據進行處理，包括回聲消除(AEC)、AECM、自動增益(AGC)、降噪處理等功能，用來提高聲音質量。

        網絡傳輸與流控

        和視頻同樣，WebRTC採用的是成熟的RTP/RTCP技術。

 

Google WebRTC官網上列表了使用WebRTC技術的四個理由：

        互聯網成功的一個關鍵因素是一些核心技術如HTML、HTTP和TCP/IP是開放和免費實現的。目前，在瀏覽器通訊領域尚未免費、高質量、完整的解決方案。WebRTC就是這樣的技術。

        該技術已經集成了最佳的音頻、視頻引擎，並被部署到數以百萬級的終端中，通過超過8年的磨練。Google不會從該技術中收取費用。

        包含了使用S TUN、ICE、TURN、RTP-over-TCP的關鍵NAT和防火牆穿越技術，並支持代理。 

        構建在瀏覽器中，WebRTC經過提供直接映射到PeerConnection的信號狀態機來抽象信號處理。Web開發人員所以能夠選擇適合應用場景的協議（例如：SIP、XMPP/Jingle等等）。  

來源： http://www.infoq.com/cn/news/2011/06/google-webrtc

 

思考：Session Management 即會話控制協議，如SIP、H.323 不在WebRTC的API庫中，那麼WebRTC只是作了媒體面的功能，不可能支持QQ這樣的Message業務、在線地址簿。

        也許將來會集成SIP協議棧在內，須要爲服務器提供XMPP協議庫。

        或者終端與服務器之間採用http或自定義協議，而服務器之間採用SIP、XMPP協議。

         webRTC主要是提供了音、視頻編解碼的免費源代碼、SRTP、集成STUN\ICE技術、安全技術、及一個WEB終端的API庫架構，讓應用開發人員可以經過HTML標籤和JavaScript API就實現Web音頻、視頻通訊功能。將促進互聯網創新的實現，大量減小開發者的繁重開發任務，下降 創業型公司創新的成本，

      

        若是它要作點到點的通訊，須要P2P鏈接。但實際上這樣的應用模式（按IP地址來通訊）是沒有意義的。並且它沒法支持多方通訊。

        可行的應用模式仍須要IM\Presence服務器支持，提供多方通訊、用戶標識註冊、加強地址簿（不光是電話號碼）、在線狀態、地理位置信息、與社交網絡互通 等功能。仍須要STUN\ICE Server來作到跨越私網的通訊。

      

     WebRTC是一個支持網絡瀏覽器進行實時語音對話或視頻對話的軟件架構。WebRTC實現了基於網頁的視頻會議，同時經過無縫通信和 P2P全方位改變人們生活和工做的方式。

 

    WebRTC是Web Real-Time Communication（網絡實時通信）的縮寫，是一項在瀏覽器內部進行實時視頻和音頻數據通訊的技術，有望成爲 HTML5標準之一。 WebRTC的這些特性可使網絡應用進入一個新的階段。

   異步Javascript和XML使開發者可以 無需從新加載便可更新網頁內容，而WebRTC堪稱近年來最大的一次技術革新，加入了不少交互特性，爲網絡帶了不少革命性的新「天賦」，這些「天賦」定會使網絡世界向前邁一大步。

   若是說HTML5 已經讓世人眼前一亮的話，那WebRTC 就是創新的集大成者。直接鏈接到其餘瀏覽器爲網絡開發者提供了另外一種新的可能性，用戶間的直接互動革新了通信和遊戲應用的工做方式。如今的瀏覽器間要想實現直接通信，必須藉助第三方插件和專屬服務器。而 WebRTC 擁有開放標準，使瀏覽器間直通很容易在互聯網架構中實現。WebRTC 帶來了諸多改進：愈來愈多的圖像應用和視頻應用開始支持移動瀏覽器；一些重大新聞可以第一時間經過手機傳送到新聞機構；僅經過一行代碼便可實現網頁實時支持和反饋；無需軟件實現文件分享。

   在線實現視頻、圖像和音頻分享跟瀏覽網頁同樣容易。開發者能夠很輕易地將這些特性加入到產品中去。

   WebRTC 的興起之路也不得不考慮政治因素，P2P傳輸很難監管並且很差關閉。咱們已經在某些場合見識了社交網絡的威力，你能想象當社交網絡插上了實時音視頻通訊傳輸的翅膀會擦出怎樣的火花嗎

   WebRTC也會使電視會議和互聯網技術市場大幅縮水，從此咱們或許不會再須要Skype和Webex。未來， Skype、Cisco、和 Polycom的電視會議技術都將實現商品化。

   互聯網正在經歷着新一輪創新浪潮，這次浪潮使多平臺無縫通信和P2P直接通信成爲可能.

 

 

問題：

這個標準創建起來後，不少傳統的VoIP服務供應商將會逐漸衰落和死亡。那些一成不變的移動運營商將會面臨用戶的大量流失，由於他們會往新的服務提供商「遷移」。傳統的固話銷售和移動語音的使用將會慢慢消失，如今所流行的電話網絡將會一去不復還。

      回答：WebRTC自己沒有提供什麼新技術，只是提供了一個Web瀏覽器支持語音、視頻應用的框架性標準與媒體面處理的免費代碼。將來利用webRTC推出新應用將很是容易。在它以前，互聯網上已經有許多VOIP免費應用、許多免費代碼庫可獲得，PLMN走向衰亡是已經註定的，甚至被運營商所承認（LTE網絡中已經沒有CS域，只有基於VOIP的語音通訊，只有RCS+IMS），webRTC會加速這個過程，但它並非一個革命性的技術，不是殺手鐗，殺手鐗是LTE\WiFi，正由於帶寬提高，才致使Voip質量能夠知足通訊要求。

 

WebRTC堪稱近年來最大的一次技術革新，加入了不少交互特性，爲網絡帶了不少革命性的新「天賦」，而這些「天賦」使網絡世界向前邁一大步。

當開發者但願使用音頻或者視頻通話時，能夠直接使用已有的代碼，惟一須要作的只需在移動設備上建立一個獨立的應用程序。該標準提出後，許多傳統的VoIP服務供應商將逐漸衰落和死亡。傳統的固定銷售（電話銷售）以及傳統的語音設備將被淘汰，電話網絡的形式已一去不復還了。這對於移動運營商來講將面臨一種新的挑戰。

      回答：同上。webRTC不是革命，但它有可能成爲一個催化劑，加速免費VOIP應用取代PLMN的步伐。

本文轉自： http://blog.sina.com.cn/s/blog_90b4c7ff01018ovk.html