WebRTC主要的重點是建立瀏覽器之間的即時網路通訊，不過這個規格還很新，基本上能完整支援的瀏覽器目前只有Chrome21以上的版本。不過他能做的應用非常有趣，所以一定要放進主軸。
WebRTC所制定的規格，大概可以分成三個部分，一個部分是getUserMedia，透過他就可以取得本地端的Web Camera以及麥克風資源。從設備輸入的音訊與視訊，會經由Stream API所定義的方式包裝。另外PeerConnection（目前將要改名為RTCPeerConnection，W3C的規格文件已經改了，不過Chrome的實作還沒好），則是用來建立瀏覽器間直接連線的介面，Stream可以透過這個介面建立起來的連線傳送，然後在對方的瀏覽器播放。透過這樣的功能，就可以建立網路電話或是視訊會議這樣的應用。
通常在應用時，還需要跟File API中的Blob URL以及html5中的Video/Audio元素搭配，來讓影音可以播送出來。
接下來做詳細一點的介紹。
getUserMedia是Navigator物件的一個方法，他可以接受三個參數，第一個叫做MediaStreamContraints，其實就是一個物件 {video:boolean, audio:boolean} ，來指定要存取的是聲音、視訊還是兩者皆有。第二個參數是執行成功時呼叫的Callback函數，MediaStream會傳送給這個函數處理。第三個參數是錯誤發生時呼叫的Callback函數，如果使用者拒絕瀏覽器存取資源，就會呼叫這個Callback。
通常在視訊會議或網路電話的應用中，比較少直接使用MediaStream物件。通常都是使用Blob URL來把MediaStream轉成參考到串流的URL，然後指派給Video或Audio元素的src屬性後播放。MediaStream定義的是包含Track List以及MediaStream這樣的抽象結構，讓我們可以對串流做管理，並不讓我們直接操作（讀寫）串流。規格中其實還有定義了怎樣利用他進行錄音，不過目前好像還沒有瀏覽器實作，所以就暫時不管他，反正接下來想做的只是視訊會議應用。
PeerConnection的操作就比前面幾個複雜很多，主要原因是為了瀏覽器直接連線。基本上，連線的兩個端點，很可能都位於具備NAT功能的防火牆或寬頻分享器之後，而且一個電腦，也可能有不只一個IP。為了讓兩台電腦可以連線，需要利用一台位於網際網路上的伺服器，利用STUN或是TURN來偵測要連線的機器與網路對外連線是怎樣對應到不同的IP與port。同時，雙方還必須透過ICE的方式不斷交換各自的IP等連線資訊，直到雙方建立直接連線，或是確定無法連線為止。
PeerConnection物件的constructor接收兩個參數，第一個是用來指定要使用的STUN/TURN伺服器，第二個是一個Callback，會接收到建立連線的候選資訊，在裡面要用一些方法（透過WebSocket或是XMLHttpRequest甚至post，所以通常雙方得先連線到一台提供交換資訊的伺服器），把這些資訊傳遞給對方處理。連線建立有發起方與接受方，發起方首先要產生一個自己的SessionDescription，立面是一些建立連線Session的資訊，把它設定給localDescription屬性，然後傳給對方。對方收到資訊後，會把它設定為remoteDescription，然後利用他建立自己的SessionDescription，設定為自己的localDescription後回傳。在收到回傳的SessionDescription後，必須把它設定為remoteDescription，然後雙方就可以呼叫startIce()方法，交換連線候選資訊。
連線建立後，透過他的onAddStream事件，以及appendStream方法，就可以收到對方傳來的MediaStream，並送出自己的MediaStream。收到以後處理的方式跟本地端使用getUserMedia是一樣的，就交給Video/Audio元素來播放。
不過目前用來偵測並建立連線的技術，STUN在雙方都在NAT之後時常常無法建立連線，而TURN必須使用一個位在網際網路上的機器代轉資料，對於傳送視訊這樣的應用來說，這種作法不太合適。另外，目前瀏覽器的功能也尚未完整，例如STUN、TURN、ICE等，可能還不是完整的實作。不過一般來說，只要兩台機器在同一個網路之內，問題應該就不太大，至少可以測試。
明天就先寫一個基本的視訊會議功能出來測試一下，然後考慮一下視訊會議的需求，實作出一個合理的流程。
另外，STUN、TURN、NAT Tranversal、ICE對很多人來說大概都是相當陌生的名詞（其實我也是），在widipedia上面有一些說明：
iThome鐵人賽
看影片追技術