1、新手求助 Intel WebRTC SDK的伺服器搭建問題
修改伺服器管理員與來賓賬戶名，禁用來賓賬戶。
管理員賬戶使用復雜密碼
開啟防火牆，專用到哪些埠，就屬開哪些。
打開漏洞更新，最好先更新好漏洞，再設置外網到伺服器的通訊
在「本地安全設置」中加強設置，如：「用戶許可權」、「安全選項」等
有必要可以設置「本地安全設置」的「ip安全設置」
根據必要安裝功能與軟體，伺服器安裝的東西遵循越少越好
修改遠程埠
優化系統，如關閉不用的共享
關閉不適用的服務，如：DHCP
啟用SYN攻擊保護（網上可找到具體操作）
清理系統垃圾
暫時只想到這么多，有些要根據具體情況具體分析。
2、webrtc 需要後台伺服器嗎
sipdroid 1）架構 sip協議棧使用JAVA實現，音頻Codec使用skype的silk（Silk編解碼是Skype向第三方開發人員和硬體製造商提供免版版稅權認證(RF)的Silk寬頻音頻編碼器）實現。NAT傳輸支持stun server. 2）優缺點： NAT方面只支持STUN，無ICE框架
3、webrtc伺服器需要多少帶寬
webrtc中的帶寬自適應演算法分為兩種：
1， 發端帶寬控制， 原理是由rtcp中的丟包統計來動態的增加或減少帶寬，在減少帶寬時使用TFRC演算法來增加平滑度。
2， 收端帶寬估算， 原理是並由收到rtp數據，估出帶寬； 用卡爾曼濾波，對每一幀的發送時間和接收時間進行分析， 從而得出網路帶寬利用情況，修正估出的帶寬。
兩種演算法相輔相成， 收端將估算的帶寬發送給發端， 發端結合收到的帶寬以及丟包率，調整發送的帶寬。
下面具體分析兩種演算法：
2, 接收端帶寬估算演算法分析
結合文檔http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02以及源碼webrtc/moles/remote_bitrate_estimator/overuse_detector.cc進行分析
帶寬估算模型： d(i) = dL(i) / c + w(i) d(i)兩幀數據的網路傳輸時間差，dL(i)兩幀數據的大小差， c為網路傳輸能力， w(i)是我們關注的重點， 它主要由三個因素決定：發送速率， 網路路由能力， 以及網路傳輸能力。w(i)符合高斯分布， 有如下結論：當w(i)增加是，佔用過多帶寬（over-using)；當w(i)減少時，佔用較少帶寬（under-using)；為0時，用到恰好的帶寬。所以，只要我們能計算出w(i)，即能判斷目前的網路使用情況，從而增加或減少發送的速率。
演算法原理：即應用kalman-filters
theta_hat(i) = [1/C_hat(i) m_hat(i)]^T // i時間點的狀態由C, m共同表示，theta_hat(i)即此時的估算值
z(i) = d(i) - h_bar(i)^T * theta_hat(i-1) //d(i)為測試值，可以很容易計算出， 後面的可以認為是d(i-1)的估算值， 因此z(i)就是d(i)的偏差，即resial
theta_hat(i) = theta_hat(i-1) + z(i) * k_bar(i) //好了，這個就是我們要的結果，關鍵是k值的選取，下面兩個公式即是取k值的，具體推導見後繼博文。
E(i-1) * h_bar(i)
k_bar(i) = --------------------------------------------
var_v_hat + h_bar(i)^T * E(i-1) * h_bar(i)
E(i) = (I - K_bar(i) * h_bar(i)^T) * E(i-1) + Q(i) // h_bar(i)由幀的數據包大小算出
由此可見，我們只需要知道當前幀的長度，發送時間，接收時間以及前一幀的狀態，就可以計算出網路使用情況。
接下來具體看一下代碼：
[cpp] view
plaincopy
void OveruseDetector::UpdateKalman(int64_t t_delta,
double ts_delta,
uint32_t frame_size,
uint32_t prev_frame_size) {
const double min_frame_period = UpdateMinFramePeriod(ts_delta);
const double drift = CurrentDrift();
// Compensate for drift
const double t_ts_delta = t_delta - ts_delta / drift; //即d(i)
double fs_delta = static_cast<double>(frame_size) - prev_frame_size;
// Update the Kalman filter
const double scale_factor = min_frame_period / (1000.0 / 30.0);
E_[0][0] += process_noise_[0] * scale_factor;
E_[1][1] += process_noise_[1] * scale_factor;
if ((hypothesis_ == kBwOverusing && offset_ < prev_offset_) ||
(hypothesis_ == kBwUnderusing && offset_ > prev_offset_)) {
E_[1][1] += 10 * process_noise_[1] * scale_factor;
}
const double h[2] = {fs_delta, 1.0}; //即h_bar
const double Eh[2] = {E_[0][0]*h[0] + E_[0][1]*h[1],
E_[1][0]*h[0] + E_[1][1]*h[1]};
const double resial = t_ts_delta - slope_*h[0] - offset_; //即z(i)， slope為1／C
const bool stable_state =
(BWE_MIN(num_of_deltas_, 60) * fabsf(offset_) < threshold_);
// We try to filter out very late frames. For instance periodic key
// frames doesn't fit the Gaussian model well.
if (fabsf(resial) < 3 * sqrt(var_noise_)) {
UpdateNoiseEstimate(resial, min_frame_period, stable_state);
} else {
UpdateNoiseEstimate(3 * sqrt(var_noise_), min_frame_period, stable_state);
}
const double denom = var_noise_ + h[0]*Eh[0] + h[1]*Eh[1];
const double K[2] = {Eh[0] / denom,
Eh[1] / denom}; //即k_bar
const double IKh[2][2] = {{1.0 - K[0]*h[0], -K[0]*h[1]},
{-K[1]*h[0], 1.0 - K[1]*h[1]}};
const double e00 = E_[0][0];
const double e01 = E_[0][1];
// Update state
E_[0][0] = e00 * IKh[0][0] + E_[1][0] * IKh[0][1];
E_[0][1] = e01 * IKh[0][0] + E_[1][1] * IKh[0][1];
E_[1][0] = e00 * IKh[1][0] + E_[1][0] * IKh[1][1];
E_[1][1] = e01 * IKh[1][0] + E_[1][1] * IKh[1][1];
// Covariance matrix, must be positive semi-definite
assert(E_[0][0] + E_[1][1] >= 0 &&
E_[0][0] * E_[1][1] - E_[0][1] * E_[1][0] >= 0 &&
E_[0][0] >= 0);
slope_ = slope_ + K[0] * resial; //1/C
prev_offset_ = offset_;
offset_ = offset_ + K[1] * resial; //theta_hat(i)
Detect(ts_delta);
}
[cpp] view
plaincopy
BandwidthUsage OveruseDetector::Detect(double ts_delta) {
if (num_of_deltas_ < 2) {
return kBwNormal;
}
const double T = BWE_MIN(num_of_deltas_, 60) * offset_; //即gamma_1
if (fabsf(T) > threshold_) {
if (offset_ > 0) {
if (time_over_using_ == -1) {
// Initialize the timer. Assume that we've been
// over-using half of the time since the previous
// sample.
time_over_using_ = ts_delta / 2;
} else {
// Increment timer
time_over_using_ += ts_delta;
}
over_use_counter_++;
if (time_over_using_ > kOverUsingTimeThreshold //kOverUsingTimeThreshold是gamma_2， gamama_3=1
&& over_use_counter_ > 1) {
if (offset_ >= prev_offset_) {
time_over_using_ = 0;
over_use_counter_ = 0;
hypothesis_ = kBwOverusing;
}
}
} else {
time_over_using_ = -1;
over_use_counter_ = 0;
hypothesis_ = kBwUnderusing;
}
} else {
time_over_using_ = -1;
over_use_counter_ = 0;
hypothesis_ = kBwNormal;
}
return hypothesis_;
}
4、基於android的webrtc伺服器怎麼搭
android客戶端和抄伺服器端是基於襲IntentService的，具體如下：後台使用簡單的servlet，支持GET或POST。這個servlet最終返回給前台一個字元串flag，值是true或false，表示登錄是否成功。然後在安卓的ADT上創建一個安卓項目，建立兩個Activity，分別作為登錄界面和登錄成功界面。HTTP的訪問公共類，用於處理GET和POST請求。IntentService服務，用於在後台以隊列方式處理耗時操作。在AndroidManifest.xml中注冊IntentService。注意uses-permission節點，為程序開啟訪問網路的許可權。登陸界面處理，注意按鈕監聽事件中，使用Intent將要傳遞的值傳給service。接收廣播類中，同樣使用Intent將要傳遞的值傳給下一個Activity。在onCreate()中，動態注冊接收廣播類的實例receiver。在接收廣播類中，不要使用完畢後忘記注銷接收器，否則會報一個()?的異常。
5、webrtc怎麼獲取到視屏流發送到伺服器
webrtc是協議， 你說的應該是如何推流吧
6、webrtc android 信令伺服器怎麼寫
1.make 模塊名稱需要查看Android.mk文件的LOCAL_PACKAGE_NAME變數。2．mmm命令用於在源碼根目錄編譯指定模塊，參數為模塊的相對路徑。只能在第一次編譯後使用。比如要編譯Phone部分源碼，需要在終端中執行以下命令：$mmm packages/apps/phone 3．mm命令用於在模塊根目錄編譯這個模塊。只能在第一次編譯後使用。例如要編譯Phone部分源碼，需要在終端中執行以下命令：$cd packages/apps/phone $mm 註：mmm和mm命令必須在執行「.build/envsetup.sh」之後才能使用，並且只編譯發生變化的文件。如果要編譯模塊的所有文件，需要-B選項，例如mm -B。
7、WebRTC中的Signaling Server是不是起到了一個ICEServer的作用
我認為不是 兩個peer要會話就需要把各自的sdp發送到對方，如果兩者都在區域網(nat)之後內，怎麼發送？這容時候就需要一個在公網上的能直接訪問的中間者來傳遞消息，在這之前兩者都是tcp連接在中間伺服器上的。這個中間伺服器除了轉發sdp，還會傳遞candidate，它包含stun之後的信息，有了這個peer之間就能直接傳media數據了。peer通過ice組件向stun伺服器協商後獲得了candidate，所以這個信令伺服器並不是ICE server，用google 文檔上的話說，這個信令伺服器可以是普通的socketserver，也可以sip/xmpp/Websocket伺服器
8、webrtc stun伺服器必須是公網ip嗎
一般需要公網IP，如果不是公網IP，那麼只能讓兩個都能連上該伺服器的設備進行通信
也就是限制了它應盡的功能，這個stun伺服器主要用來穿透防火牆，進行兩個網路的通信，如果在同一個內網通信，就沒有太大的意義，但也是可以實現的