關於WebRTC網上有好多介紹，這裏我就不詳細的敘述了。重點放在WebRTC的項目實施過程，涉及後續開發，將會有詳細介紹。
WebRTC是由谷歌提出的一套基於UDP協議的網頁流媒體協議。有以下幾個特點：
1、網頁間直接通信。即不需要安裝任何插件，通過網頁前端的JS程序，即可構建兩端的通信。
2、NAT穿透。不需要中間流媒體服務器進行中轉流媒體數據，通過NAT穿透協議ICE框架，即可實現NAT後的網頁端的P2P的通信。
3、提供基於非網頁端的開發庫，以構建基於WebRTC視頻傳輸的應用軟件。
由於目前還在發展和普及階段，所以只有Chrome、Firefox瀏覽器以及基於這兩款瀏覽器的內核的瀏覽器支持WebRTC協議。這是因爲Chrome、Firefox內核在底層由C++開發出供JS層調用的各種API，從而實現視頻傳輸功能。
基本的WebRTC通信架構如圖所示：
第一步：每個瀏覽器必須獲取自己的“候選（通信）地址”。所謂“候選地址”，即一個PC機可能包含多個網卡，而同時又包含內網IP和外網IP（在ICE協議裏，內網IP對應的外網IP被稱爲“反射地址”）。所以，WebRTC協議本身“借用”ICE協議（ICE協議包含stun協議和turn協議），獲取最佳的通信IP，通過能夠通信的IP地址來交換數據。譬如：內網IP在公網上是不能直接通信的，必須借用所在外網的IP地址來通信。而候選地址的提供由stun/turn服務器提供。好消息是，有許多公共的stun/turn服務器地址供直接使用。當然我們也可以搭建stun/turn服務器。關於ICE（也就是stun/turn協議）協議，後續會繼續介紹。
第二步：獲取的“候選地址”必須由信令服務器進行交換從而告知對方。初次之外，信令服務器還承擔其他信息的交互比如SDP報文。（即媒體信息，如編碼方式等）這些信息交換完成後，即可開始傳輸媒體數據。
第三步：媒體傳輸。當獲取可以通信的IP地址後，即開始交換媒體數據。在WebRTC中媒體的傳輸有新的理解方式。以往我們瞭解的數據傳輸是由一端發到一端。在WebRTC中，網頁端會構建一個媒體顯示控件，當開始通信時，會把自己的攝像頭加入“信令服務器”中。在本地端，當媒體顯示控件綁定到本地攝像頭時，將會顯示本地視頻，當媒體顯示控件綁定遠端攝像頭時，即顯示遠端攝像頭數據。WebRTC用這種方式實現視頻的傳輸。（雖然本質也是視頻發送接收，但注意WebRTC中在看待視頻傳輸這個問題的角度和往常的socket的send、receive有不同的理解）
但是，此次項目有個需求就是，必須保存流媒體數據！所以，就必須有一箇中間服務器進行中轉，然後通過中間服務器來處理視頻。目前開發較爲完善的WebRTC流媒體服務器是：Kurento。所以接下來就是研究Kurento流媒體服務器的使用問題，以後簡稱KMS。
