webrtc伺服器視頻搭建

⑴ WebRtc實現網頁和原生P2P視頻聊天，視頻通話

Webrtc已經成為視頻及時互動的標配，日常業務系統中，很多需要web打開就能視頻通話，實現類似微信視頻聊天的功能，但實施是在web上，由於還有業務app集成，同時也要在app原生端實現。

經過多次分析和參考google的官方demo,開發總結了一下：

1，webrtc庫盡量要匹配，如現在主流瀏覽器支持的是webrtc，m79,原生端盡量用這個原生庫打包。

2，web的全平台兼容挺難的，特別是ios上只支持safari內置版本，api和chrome稍有差異。

3，實施上視頻攝像頭對chrome 64位兼容不不是太好，建議自行封裝成chrome內核的客戶端

4，webrtc如只是p2p不需要特別伺服器，自已開發信令服務就可以啦，當要安裝turn server 國內常有打洞不成功需要轉發。

效果：

​​​

測試：https://m.ovmeet.com:5001/login.html

⑵ 新手求助 Intel WebRTC SDK的伺服器搭建問題

每個伺服器可能有不同的系統，但是我們都要對新的伺服器進行一些配置，例如香港伺服器，那麼伺服器的環境要如何配置呢？我相信這是很多新手站長的苦惱，其實這分三步就可以輕松搞定了。第一步：進入系統後我們把系統光碟里的I386文件復制到任何盤符都行，開始安裝IIS。進入「控制面板」，選「添加/刪除程序→添加/刪除Windows組件」，將「Internet信息服務（IIS）」前的小鉤去掉（如有），重新勾選中後按提示操作即可完成IIS組件的添加。用這種方法添加的IIS組件中將包括Web、FTP（可選可不選我們也可以用軟體建FTP伺服器）、NNTP和SMTP等全部四項服務。IIS網站搭建就不詳說了。第二步：裝好IIS後我們就要開始配置：AspJpeg、AspUpload、imail(可選別的版本）、JMAIL、JoekoeCMS3.0Free、LyfUpload.dll（復制到windows/systems32裡面，運行cmd→regsvr32+LyfUpload.dll,注冊這個組件）、MSXML、mysql、php、SQL2000第三步：待以上都裝好以後在配置IIS，具體步驟如下：1),web服務擴展裡面的ActiveServerPages￣｜Asp.NETv1.4322｜≯設置允許在伺服器端的包含文件__｜PHP配置允許：新建WBE服務擴展：擴展名：PHP→添加→瀏覽→查找范圍→PHP5→PHP5isapi.dll設置允許（在這之前先安裝PHP5）2),網站：屬性→主目錄→配置→選項→起用父路徑勾上.把上面這三部完成後，這樣一台香港伺服器環境就配置好了！伺服器找我！展翼小T

⑶ 用SRS快速搭建WebRTC推流和播放

WebRTC目前已經比較成熟了，播放也比較穩定，協議也已經成為了RFC，相應的開源項目也比較多。當然我覺得WebRTC還缺一個高性能簡單易用的伺服器，之前也分析過現有的伺服器，有各種問題，SRS很有機會解決這些問題。

目前SRS對WebRTC的支持進度如下：

相關Wiki：

在線演示，RTMP推流，HTTP-FLV和WebRTC播放：

在線演示，WebRTC推流，WebRTC播放：

自己用SRS搭建WebRTC伺服器，也非常容易，下面是操作步驟。

注意：必須要將本機的IP傳給Docker，否則會推流和播放失敗。

可以直接傳本機IP，例如： 192.168.1.3 。如果覺得直接傳IP比較麻煩，可以用腳本獲取IP。

macOS下執行命令，直接設置IP：

macOS下執行命令，用腳本獲取IP：

CentOS下執行命令，用腳本獲取IP：

啟動後，可以訪問 http://localhost:8080/ ，確認是否啟動成功。

Docker一定要設置對這個IP，否則會出現推流和播放失敗。

演示，WebRTC推流和播放，鏈接：

演示，RTMP推流，WebRTC播放。首先，用FFMPEG或OBS推送RTMP流到伺服器：

可播放的流地址：

⑷ WebRTC基於瀏覽器的開發

WebRTC需要通過長鏈接查找到通信雙方，然後通過 peer to peer 的方式傳輸音頻數據。

WebRTC中最主要的就是一個叫做 PeerConnection 的對象，這個是WebRTC中已經封裝好的對象。每一路的音視頻會話都會有唯一的一個 PeerConnection 對象，WebRTC通過這個 PeerConnection 對象進行視頻的發起、傳輸、接收和掛斷等操作。
PeerConnection中包含的屬性如下：

PeerConnection 中還包含了一些方法：

RTCSessionDescription 類型中包含了兩個屬性：

A向B發起通信請求

首先WebRTC需要一個信令伺服器，也就是一個socket鏈接用來發起視頻通信，發送WebRTC中的 offer 和回復 answer 。
如何搭建一個簡單的socket伺服器，可以找我的這篇文章《》，也可以是用webSocket搭建信令伺服器。

WebRTC需要打洞伺服器（一個 stun ，一個 turn ）來穿透防火牆等，我們需要配置打洞伺服器：

WebRTC由於是未來的一種即時通信的標准，所以目前在Chrome、Firefox和Opera瀏覽器中有內置插件，均提供一個全局的PeerConnection類。

創建PeerConnection的對象：

創建時需要傳入打洞伺服器的配置信息，如果不穿入打洞伺服器的配置信息，則只可以在內網中使用實時音頻通訊。

由於PeerConnection是全局的，所以我們可以通過另外的一種方式進行創建：

如何判斷瀏覽器是否支持WebRTC：

WebRTC也提供了一個全局單例來獲取本地的音視頻信息：

GetUserMedia需要傳入三個參數，第一個參數為配置信息，第二個參數為獲取成功的回調，第三個參數為獲取失敗的回調。
獲取到視頻流之後

創建一個offer並發送給指定的對象：

創建offer時要同時發送打洞伺服器配置信息，WebRTC給了一個監聽：

返回的參數中有一個 candidate 屬性，便是打洞伺服器的配置信息。

音頻通話請求是通過socket發來的，需要通過socket去監聽。

如果收到了offer，那麼需要將offer存到自己的peerConnection中，並且創建一個answer發送回對方。
將offer存入peerConnection中：

創建一個answer並返回給對方：

如果收到了打洞伺服器的配置信息，那麼需要將打洞伺服器的配置信息存入到 peerConnection 中：

發送給對方answer後便可以等待接受對方的數據流了：

至此，整個簡單的WebRTC的流程就完成了

⑸ 使用WebRTC搭建前端視頻聊天室——點對點通信篇

WebRTC給我們帶來了瀏覽器中的視頻、音頻聊天體驗。但個人認為，它最實用的特性莫過於DataChannel——在瀏覽器之間建立一個點對點的數據通道。在DataChannel之前，瀏覽器到瀏覽器的數據傳遞通常是這樣一個流程：瀏覽器1發送數據給伺服器，伺服器處理，伺服器再轉發給瀏覽器2。這三個過程都會帶來相應的消耗，佔用伺服器帶寬不說，還減緩了消息從發送到接收的時間。其實最理想的方式就是瀏覽器1直接與瀏覽2進行通信，伺服器不需要參與其中。WebRTC DataChannel就提供了這樣一種方式。

如果對WebRTC和DataChannel不太了解的同學，可以先閱讀如下文章：

- WebRTC的RTCDataChannel

- 使用WebRTC搭建前端視頻聊天室——信令篇

- 使用WebRTC搭建前端視頻聊天室——入門篇

當然伺服器完全不參與其中，顯然是不可能的，用戶需要通過伺服器上存儲的信息，才能確定需要和誰建立連接。這里通過一個故事來講述建立連接的過程：

不如釣魚去

一些背景：

現在，老劉聽說老姚釣魚技術高超，想和老姚討論釣魚技巧。只要老劉和老姚相互之間知道對方的門牌號以及憑證，就可以串門了:

老劉和老姚相互之間知道了對方的門牌號和小區出入憑證，他們相互之間有什麼需要交流的直接串門就行了，消息不再需要門衛老大爺來代為傳達了

換個角度

我們把角色做一個映射：

於是乎故事就變成了這樣：

這樣，就建立了一個點對點的信道，流程如下所示：

故事

老劉和老姚已經可以相互串門了，經過一段時間的交流感情越來越深。老姚的親友送了20斤葡萄給老姚，老姚決定送10斤給老劉。老姚畢竟年事已高，不可能一次帶10斤。於是乎，老姚將葡萄分成了10份，每次去老劉家串門就送一份過去。

這里可以做如下類比：

這其實就是通過datachannel傳輸文件的方式，首先將文件分片，然後逐個發送，最後再統一的進行組合成一個新的文件

分片

通過HTML5的File API可以將type為file的input選中的文件讀取出來，並轉換成data url字元串。這也就為我們提供了很方便的分片方式：

組合

通過datachannel發送的分片數據，我們需要將其進行組合，由於是data url字元串，在接收到所有包之後進行拼接就可以了。拼接完成後就得到了一個文件完整的data url字元串，那麼我們如何將這個字元串轉換成文件呢？

方案一：直接跳轉下載

既然是個dataurl，我們直接將其賦值給window.location.href自然可以下載，但是這樣下載是沒法設定下載後的文件名的，這想一想都蛋疼

方案二：通過a標簽下載

這個原理和跳轉下載類似，都是使用dataurl本身的特性，通過創建一個a標簽，將dataurl字元串賦值給href屬性，然後使用download確定下載後的文件名，就可以完成下載了。但是很快又有新問題了，稍微大一點的文件下載的時候頁面崩潰了。這是因為dataurl有大小限制

方案三：blob

其實可以通過給a標簽創建blob url的方式來進行下載，這個沒有大小限制。但是我們手上是dataurl，所以需要先進行轉換：

獲得blob後，我們就可以通過URL API來下載了：

這里有幾個點：

1. datachannel其實是可以直接傳送blob的，但是只有ff支持，所以傳data url

2. chrome下載是直接觸發的，不會進行詢問，firefox會先詢問後下載，在詢問過程中如果執行了revokeObjectURL，下載就會取消，囧

升級

如我們所知，WebRTC最有特點的地方其實是可以傳輸getUserMedia獲得的視頻、音頻流，來實現視頻聊天。但事實上我們的使用習慣來看，一般人不會一開始就打開視頻聊天，而且視頻聊天時很消耗內存的（32位機上一個連接至少20M左右好像，也有可能有出入）。所以常見的需求是，先建立一個包含datachannel的連接用於傳輸數據，然後在需要時升級成可以傳輸視頻、音頻。

看看我們之前傳輸的session description，它其實來自Session Description Protocol。可以看到wiki上的介紹：

這意味著什麼呢？我們之前建立datachannel是沒有加視頻、音頻流的，而這個流的描述是寫在SDP裡面的。現在我們需要傳輸視頻、音頻，就需要添加這些描述。所以就得重新獲得SDP，然後構建offer和answer再傳輸一次。傳輸的流程和之前一樣，沒什麼區別。但這一次，我們不需要傳輸任何的ice candidate，這里我曾經遇到了坑，經過國外大大的點撥才明白過來。

Peertc

我將datachannel和websocket組合，實現了一個構建點對點連接的庫Peertc，它提供非常簡潔的方式來建立連接和發送數據、文件和視頻/音頻流，詳情見github。走過路過的記得star一下哦，有什麼bug也非常希望能夠提出來。

最後

WebRTC的點對點方式能夠運用在很多場景：

- 如web qq這種Web IM工具，這就不說了

- 如象棋這種雙人對戰 游戲 ，每一步的數據伺服器時不關心的，所以完全可以點對點發送

- 一對一在線面試、在線教育，這其實是即時通信的一個業務方向

⑹ iOS開發之WebRTC和SIP(轉載)

1.SIP概念理解
2.【協議學習】SIP基本場景分析
3.企業開源SIP項目
4.SIP常見問題及處理
5.SIP基礎入門
6.我的IOS端SIP電話開發歷程
7.我的SIP開發之路
8.SIP協議&開源SIP伺服器搭建和客戶端安裝

1.WebRTC官網
2.大佬的筆記
3.WebRTC中文網
4.RTC.Blacker ->Android IOS WebRTC
5.iOS下音視頻通信-基於WebRTC
6.第六章 Webrtc伺服器搭建
7.webrtc學習: 部署stun和turn伺服器
8.webrtc編譯全過程
9.iOS下WebRTC音視頻通話（一）
10.iOS下WebRTC音視頻通話（二）-區域網內音視頻通話
11.WebRTC樣本
12.iOS下音視頻通信的實現-基於WebRTC

1. WebRTC簡介及其與SIP互通
2.SIP和WebRTC有什麼不同？

⑺ 用SRS搭建WebRTC流媒體伺服器實戰

WebRTC經過這么多年的發展，目前已經比較成熟的協議之一，播放也比較穩定，協議也已經成為了RFC，相應的開源項目也越來越多，但是基於WebRTC協議的部署簡單，性能強悍，功能強大流媒體伺服器的項目還比較稀少。之前了解到的伺服器比如Mediasoup，Janus，Medooze ，要麼就是設計復雜，接入成本要，要麼就是性能較差，還就是多種語言結合，學習成本較高。 而SRS聚焦視頻相關，功能專一，語言使用了高性能的c++,並且支持Rtmp轉Webrtc等其他強大的功能的媒體伺服器。

1.源碼編譯安裝運行SRS

使用這個命令開啟RTC支持

2.SRS常用命令

3.配置nginx代理
若不需要瀏覽器推流，可以不用設置nginx代理，使用localhost訪問

注意：your 代表需要配置你自己的域名信息，由於使用瀏覽器推流必須使用https協議，所以我這邊配置了證書
4.訪問配置的域名
訪問nginx配置的網址 https://webrtc.yourhost.com/
出現如下內容，則服務端架設成功

雖然整片文章看起來不復雜，流程很簡單。但是官網的文檔中的知識點比較分散，所以大家要想快速的搭建的話就參考我這篇文章