本節主要介紹WebRTC音視頻服務端的處理
通過前面的例子我們知道運行WebRTCDemo即可看到P2P的效果，實際應用中我們不可能讓用戶自己去裏面設置對方的IP和音視頻端口，
而且即使設置了對方的IP和端口也不一定能運行起來，因爲P2P如果雙方不在同一個網段則還需穿透NAT，那服務端具體該如何部署呢？
1、信令服務：
想知道信令服務的作用前您先想想通訊雙方彼此都不知道對方在哪裏，怎麼與對方建立連接，怎麼給對方發起視頻請求？
想到這裏我們是不是會想到雙方都應該先跟一個服務器建立連接，所以這就是信令服務的作用，具體如下圖：
2、打洞服務：打洞的原理理解了其實很簡單，主要思路就是通過STUN服務器獲取自己的ip,port及NAT信息，
然後通過信令服務器交換這些信息,最後兩客戶端根據各自得到的ip,port,NAT信息進行相應的穿透，
現在開源STUN代碼很多，網上也有很多介紹這方面的問題，有興趣的可以找相關資料看看.
補充:不過對NAT進步一研究你會發現內網下多重NAT穿透是個比較麻煩的事情，網上有一些專門研究多層NAT穿透的論文,
正因爲STUN方式不能完全解決P2P問題,所以後面出現了ICE,而libjingle就是ICE思想的具體實現。
3、媒體轉發服務：P2P失敗時，客戶端先將RTP包發給媒體服務，然後再通過服務器轉發給對方，
實際上很多視頻會議都是這麼實現的,在多人視頻通訊的情況下如果都通過P2P來實現則會給客戶端帶來很大的壓力,
特別是手機端負載有限的情況下,這宗點點的轉發方式的弊端尤爲明顯,但如果通過RelayServer,客戶端壓力可大大減輕。
補充：如果要考慮多人視頻，直播，如三方會議同時廣播給幾千人觀看，這就設置到服務端的編解碼，混音，屏幕疊加等等功能，
這是一個比較負責的課題，也是語音通信廠商的核心技術，後面會整理一篇文章專門介紹這方面的內容。