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认证密钥。

但是它不能抵御重放攻击；重放保护方法建议接收方维护好先前接收到的消息的索引，将它们与每个新接收到的消息进行比对，并只接收那些过去没有被播放过的新消息。这种方法十分依赖于完整性保护的使用（以杜绝针对消息索引的欺骗技术）。