Android WebRTC 音視訊開發總結（三）

前面介紹了WebRTCDemo的基本結構，本節主要介紹WebRTC音視訊服務端的處理，，轉載請說明出處（部落格園RTC.Blacker）。

 

通過前面的例子我們知道執行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,客戶端壓力可大大減輕。 

補充：如果要考慮多人視訊，直播，如三方會議同時廣播給幾千人觀看，這就設定到服務端的編解碼，混音，螢幕疊加等等功能，

這是一個比較負責的課題，也是語音通訊廠商的核心技術，後面會整理一篇文章專門介紹這方面的內容。