srtp對rtp擴展欄位加密嗎

1. Licode—基於webrtc的SFU/MCU實現

WebRTC的魅力解析: 作為W3C/IETF聯合制定的協議，WebRTC致力於在無需插件的環境下，實現跨瀏覽器的多媒體應用，強調非中心化會話，並無縫融入HTML5的生態體系。它包含了前沿的音視頻演算法，通過跨平台封裝，讓開發者能夠輕松構建為Web、App或Windows應用，同時支持分布式部署，以適應各種環境需求。

Licode的創新架構: Licode以其獨特的SFU/MCU功能脫穎而出，其架構由客戶端（ErizoClient, NuveClient）和伺服器端（Nuve、ErizoController、ErizoAgent、MessageBus）組成。Nuve負責業務服務和全局管理，ErizoController則處理信令，而ErizoAgent和ErizoJS則是媒體處理的核心，它們封裝了webrtc、libav/libnice等關鍵技術。Licode博客提供了Nuve源碼的深入剖析，展示了其對webrtc的精巧處理，包括丟包重傳（ARQ）、前向糾錯（FEC）和帶寬管理（如GCC/REMB）等復雜演算法。

核心技術詳解: Licode的核心亮點在於RTP轉發部分，使用libav處理編解碼，libnice負責ICE連接和SDP管理，而libsrtp則為RTP/RTCP提供加密保護。其網路架構是關鍵，採用了流水線-Handler設計，將ICE轉換、DTLS/SRTP、RTP/RTCP處理等環節高效整合，通過Pipeline-Handler模型實現。例如，Pipeline中包含了RtcpFeedbackGenerationHandler、RtpRetransmissionHandler等組件，確保了數據的穩定傳輸。

分布式保障與資源管理: Licode引入分布式保活機制，通過EC和Nuve的協調，利用資料庫的秒級檢查確保節點存活。資源管理上，Licode採用了publish-subscribe模型，靈活地管理設備、內容和伺服器資源，與H.323的緊密耦合相比，顯得更為高效和易於擴展。

總結與展望: 本文對Licode進行了深入探討，特別是其網路流水線、分布式保活和資源管理技術的巧妙運用。雖然可能存在一些不完善之處，但Licode的實用性和前瞻性無疑為WebRTC的開發者和應用者提供了寶貴的參考。期待與讀者共同探討，共同進步。

2. srtp是什麼意思

安全實時傳輸協議(Secure Real-time Transport Protocol)。

其是在實時傳輸協議(Real-time Transport Protocol)基礎上所定義的一個協議，旨在為單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。

由於實時傳輸協議和實時傳輸控制協議（Real-time Transport Control Protocol或RTCP）有著緊密的聯系，安全實時傳輸協議同樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（Secure RTCP或SRTCP）；

安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。

對於 RTP 和 RTCP 應用程序來說, SRTP 和 SRTCP 是可選項, 而且即使使用了 SRTP 和 SRTCP 協議, 它們提供的各種功能(例如加密和認證) 也都是可以獨立選擇使用或者不使用的。

唯一的例外就是當使用 SRTCP 的時候消息認證(message authentication)是必選的。

數據流加密

為了提供對數據流的保密，需要對數據流進行加密和解密。關於這一點，安全實時傳輸協議（結合安全實時傳輸控制協議）只為一種加密演算法，即AES制定了使用標准。這種加密演算法有兩種加密模式，它們能將原始的AES塊密文轉換成流密文：

分段整型計數器模式——一種典型的計數器模式，它允許對任意塊的隨機訪問——這一點對於實時傳輸協議的數據流在可能丟包的不可靠網路上進行傳輸是非常必要的。一般情況下，幾乎所有的函數都能被作為計數器使用，只要它在一次循環中重復的次數不要太多就可以。

但是，用於實時傳輸協議數據加密的僅僅是一個普通的整型遞增計數器。運行在這一模式下的AES是其默認的加密演算法，它使用的是默認128位長度的加密密鑰和默認112位長度的會話鹽密鑰。

f8模式——輸出反饋模式的一個變種，它增加了定位功能並改變了初始化功能。其加密密鑰和鹽密鑰的默認值和計數器模式下的AES是一樣的。運行在這種模式下的AES被用於UMTS3G移動網路。

除了AES加密演算法，安全實時傳輸協議還允許徹底禁用加密，此時使用的是所謂的「零加密演算法」。它可以被認為是安全實時傳輸協議支持的第二種加密演算法，或者說是它所支持的第三種加密模式。

事實上，零加密演算法並不進行任何加密，也就是說，加密演算法把密鑰流想像成只包含「0」的流，並原封不動地將輸入流復制到輸出流。這種模式是所有與安全實時傳輸協議兼容的系統都必須實現的，因為它可以被用在不需要安全實時傳輸協議提供保密性保證而只要求它提供其它特性（如認證和消息完整性）的場合。

盡管從技術上來說安全實時傳輸協議能輕松地納入新的加密演算法，但安全實時傳輸協議標准指出除上述加密演算法以外的新的加密演算法不一定能被簡單地添加到一些安全實時傳輸協議的具體實現中去。

添加一種新的加密演算法並確保它與安全實時傳輸協議標准相兼容的唯一有效方式是發布一個明確定義該演算法的新的伴生的標准跟蹤RFC。

認證、完整性和重放保護

以上列舉的加密演算法本身並不能保護消息的完整性，攻擊者仍然可以偽造數據——至少可以重放過去傳輸過的數據。因此，安全實時傳輸協議標准同時還提供了保護數據完整性以及防止重放的方法。

為了進行消息認證並保護消息的完整性，安全實時傳輸協議使用了HMAC-SHA1演算法（在RFC 2104中定義）。這種演算法使用的是默認160位長度的HMAC-SHA1認證密鑰。

但是它不能抵禦重放攻擊；重放保護方法建議接收方維護好先前接收到的消息的索引，將它們與每個新接收到的消息進行比對，並只接收那些過去沒有被播放過的新消息。這種方法十分依賴於完整性保護的使用（以杜絕針對消息索引的欺騙技術）。