企业官网建设流程全解析

1. 项目概述与核心价值

最近在做一个需要实时传输音频的嵌入式项目，甲方对通信安全有硬性要求，明文传输的方案直接被否了。这让我不得不重新审视音频流传输的整个链路，最终决定在传统的RTP（Real-time Transport Protocol）封装基础上，集成SRTP（Secure Real-time Transport Protocol）来实现端到端的安全加密。用C++从头实现这套东西，听起来有点“造轮子”，但市面上现成的库要么太臃肿，要么对嵌入式平台支持不好，要么加密流程像个黑盒，出了问题排查起来能让人崩溃。自己实现一遍，虽然前期折腾，但对RTP/RTCP的报文结构、SRTP的加密上下文管理、密钥派生过程会有刻骨铭心的理解，后期定制和优化也方便得多。

简单来说，这个项目就是解决“如何安全地发送一段音频数据包”。RTP负责把连续的音频流（比如从麦克风采集的PCM数据）切割成一个个带有时序和序列号的小包，加上头信息，让它能在网络上按序、及时地传输。而SRTP则是在RTP的外面套上一层“保险箱”，对载荷（你的音频数据）和关键的头字段进行加密和完整性保护，防止被窃听或篡改。在VoIP、视频会议、直播推流这些对实时性和安全性都有要求的场景里，这套组合拳是基础中的基础。

如果你正在用C++开发音视频通信、对讲机、直播SDK或者任何需要安全传输实时媒体的应用，那么理解如何手动封装RTP并为其披上SRTP的加密铠甲，会是一个非常有价值的技能点。这不仅仅是调用几个API，更是对网络、密码学、实时系统编程的一次深度实践。

2. 核心思路与方案选型

2.1 为什么选择RTP/RTCP + SRTP？

实时音频传输面临几个核心挑战：时序同步、丢包处理、网络抖动和安全性。TCP的可靠传输机制（重传、有序）会引入不可控的延迟，不适合实时流。UDP虽然快，但它是无连接的，丢包、乱序、重复包都得自己处理。

RTP协议就是跑在UDP之上的应用层协议，它完美地补上了UDP的短板：

• 序列号（Sequence Number）：16位，用于检测丢包和乱序。接收方通过序列号的连续性就能知道有没有包丢了。
• 时间戳（Timestamp）：32位，这是RTP的灵魂。它记录了载荷数据第一个字节的采样时刻。接收方根据这个时间戳，结合时钟频率（Clock Rate），就能知道应该在什么时间播放这个包的数据，从而消除网络抖动（Jitter）的影响，实现平滑播放。
• 同步源标识（SSRC）：32位，唯一标识一个流源。在一个RTP会话中，每个发送者（比如一个参会者）都有一个独立的SSRC，防止冲突。

RTCP（RTP Control Protocol）是RTP的伴生协议，用于传输控制信息，比如发送/接收报告（SR/RR），用来反馈网络质量（丢包率、抖动），实现基本的QoS监控。

而SRTP，则是RTP的安全扩展。它没有定义新的报文格式，而是在RTP/RTCP包的基础上，通过加密和认证变换，提供：

1. 机密性：使用对称加密算法（如AES）加密RTP/RTCP的载荷。
2. 完整性：使用消息认证码（如HMAC-SHA1）保护整个包（头+载荷）不被篡改。
3. 重放保护：通过序列号和滑动窗口机制，拒绝接收已经处理过的旧包。

选择自己用C++实现，而不是直接拉一个libsrtp2，主要基于以下几点考量：

• 可控性：嵌入式环境资源紧张，需要精确控制内存和CPU占用。自己实现的代码可以只包含必需的功能，裁剪掉所有冗余。
• 可调试性：加密过程、密钥派生、认证标签计算，每一步都清晰可见。当出现加密解密失败、认证不通过时，可以逐字节比对，快速定位是算法实现问题、密钥问题还是数据问题。
• 学习价值：这是最根本的。通过实现，你会真正理解SRTP的主密钥（Master Key）、主盐（Master Salt）是如何通过密钥派生函数（KDF）生成会话中实际使用的加密密钥、认证密钥和盐值的。这个过程的清晰理解，对于后续配置和排查SRTP相关问题至关重要。

2.2 整体架构设计

我们的系统将分为几个清晰的模块：

1. RTP封装/解析模块：负责将原始的音频帧（如20ms的PCM数据）打包成RTP报文，以及从网络收到的UDP包中解析出RTP报文。
2. SRTP加密/解密模块：负责管理加密上下文（密钥、算法、ROC等），对出站的RTP/RTCP包进行加密和添加认证标签，对入站的包进行验证和解密。
3. 密钥管理模块：负责安全地生成、存储、交换主密钥和主盐。在实际项目中，这部分通常与信令协议（如SIP、WebRTC的信令）结合，通过DTLS-SRTP或SDES等方式进行交换。在我们的实现指南中，我们会模拟一个简单的密钥交换过程。
4. 网络收发模块：使用BSD Socket（或类似接口）进行UDP数据的发送和接收。这部分相对独立，我们的核心聚焦在前三个模块。

数据流向可以概括为：发送端：音频采集 -> 音频帧 -> RTP封装（加头）-> SRTP加密/认证 -> UDP发送接收端：UDP接收 -> SRTP验证/解密 -> RTP解析（去头）-> 音频帧 -> 音频播放/Jitter Buffer

3. RTP报文封装详解与C++实现

3.1 RTP固定头部结构解析

RTP固定头部长度为12字节，这是我们必须精确掌握并能在内存中准确映射的结构。RFC 3550定义了它的格式，我们用C++结构体来定义它，并注意内存对齐和字节序（网络字节序为大端）。

#include <cstdint> // 使用标准整数类型 // 假设为小端系统，网络字节序为大端，需要使用htonl/htons, ntohl/ntohs转换 struct RTPHeader { uint8_t csrcCount : 4; // CSRC计数，通常为0 uint8_t extension : 1; // 扩展位 uint8_t padding : 1; // 填充位 uint8_t version : 2; // 版本，必须为2 uint8_t payloadType : 7; // 载荷类型，如PCMA=8, PCMU=0, OPUS=120 uint8_t marker : 1; // 标记位，对于音频，通常标识静音后的第一个包 uint16_t sequenceNumber; // 序列号，每发送一个RTP包递增1 uint32_t timestamp; // 时间戳，根据采样频率递增 uint32_t ssrc; // 同步源标识，随机生成 // 可选：贡献源列表（CSRC List），当csrcCount>0时存在 // uint32_t csrc[15]; };

关键字段解读与实操要点：

• payloadType (PT): 这是接收方识别音频编码格式的唯一依据。必须在信令阶段（如SDP）协商一致。例如，G.711 μ-law对应0，G.711 A-law对应8，OPUS对应动态值（如120）。我们的代码里需要维护一个映射表。
• sequenceNumber: 从随机值开始，每发送一个包就加1，溢出后回绕。接收方需要用这个来统计丢包。计算丢包率的公式大致是：丢包数 = 期望序列号 - 最大接收序列号 - 1。期望序列号是上一个收到的序列号加1。
• timestamp: 这是实现流畅播放的关键。它的增量不是时间，而是采样点数。例如，使用8kHz采样率，每20ms发送一个包，那么每个包的时间戳增量就是8000 Hz * 0.020 s = 160个采样点。第一个包的时间戳通常也取一个随机值。
• SSRC: 必须在整个RTP会话中全局唯一。通常使用随机数生成。如果发生冲突（概率极低），需要通过RTCP BYE报文和新的SSRC来解决。
• marker (M): 在音频中，常用于标记一个谈话突发的开始（例如，静音检测后的第一个语音包），接收方可以据此进行一些优化处理。

注意：上述结构体在内存中的布局依赖于编译器和平台。为了确保与网络报文二进制布局完全一致，通常需要禁用结构体对齐（如GCC的__attribute__((packed))），或者更稳妥的做法是，不使用结构体直接映射，而是手动通过指针偏移和字节序转换函数来读写每个字段。后者是更推荐、更可移植的做法。

3.2 封装音频数据为RTP包

假设我们采集到的是一段20ms的PCM数据（160个采样点，16位单声道，即320字节）。封装过程如下：

#include <vector> #include <cstring> #include <arpa/inet.h> // 用于htonl, htons class RtpPacket { public: std::vector<uint8_t> buffer; // 存储完整的RTP报文 RtpPacket(uint16_t seq, uint32_t ts, uint32_t ssrc, uint8_t pt, bool marker, const uint8_t* payloadData, size_t payloadLen) { buffer.resize(12 + payloadLen); // 固定头 + 载荷 uint8_t* p = buffer.data(); // 版本2，其他标志位默认为0 p[0] = (2 << 6) | (0 << 5) | (0 << 4) | 0; // csrcCount=0 p[1] = (marker ? 0x80 : 0x00) | (pt & 0x7F); // 序列号和时间戳转换为网络字节序 *reinterpret_cast<uint16_t*>(&p[2]) = htons(seq); *reinterpret_cast<uint32_t*>(&p[4]) = htonl(ts); *reinterpret_cast<uint32_t*>(&p[8]) = htonl(ssrc); // 拷贝载荷数据 if (payloadLen > 0 && payloadData) { std::memcpy(&p[12], payloadData, payloadLen); } } const uint8_t* data() const { return buffer.data(); } size_t size() const { return buffer.size(); } };

封装过程中的注意事项：

1. 时间戳的连续性：时间戳必须单调递增，且增量要准确反映载荷中包含的媒体时长。如果音频输入设备暂时没有数据（静音），发送端通常会发送静音包（Silence Insertion Descriptor, SID）或直接停止发送，但时间戳的“时钟”不能停，下一个语音包的时间戳需要基于采样率继续推算，否则接收端会认为时间出现了巨大的跳跃，导致播放异常。
2. 序列号的处理：序列号递增很简单，但要小心多线程环境下的竞争条件。建议用一个原子变量或加锁来管理发送序列号。
3. 载荷对齐：某些编码格式（如AAC）可能有特殊的载荷结构或需要添加AU头。我们的示例是最简单的PCM情况。对于像OPUS这样的有损编码，还需要考虑编码器本身输出的数据包格式。

4. SRTP安全加密原理与实现

4.1 SRTP加密流程与密钥派生

SRTP的核心在于会话密钥的派生和加密/认证过程。我们不会使用一个固定的密钥，而是通过一个密钥派生函数（KDF），从共享的主密钥（Master Key）和主盐（Master Salt）为每个SSRC和特定的包索引派生出独一无二的会话密钥（Session Key）和会话盐（Session Salt）。

为什么需要密钥派生？直接使用主密钥加密所有包是危险的。如果攻击者破解了一个包的密钥，就等于破解了所有包。通过KDF，每个包（或每一组包）使用的加密密钥都不同，实现了前向保密的一个较弱形式，并限制了密钥暴露的影响范围。

SRTP默认使用AES-CM（AES in Counter Mode）进行加密，使用HMAC-SHA1进行认证。密钥派生过程如下：

1. 定义关键参数：

   • master_key: 主密钥（例如，AES-128为16字节，AES-256为32字节）。
   • master_salt: 主盐（14字节）。
   • key_derivation_rate: 密钥派生速率，通常为0（每个SSRC派生一次），也可以设为非零值定期更新密钥。
   • packet_index: 包索引，是一个48位的值，由高16位的回绕计数（ROC）和低32位的RTP序列号组成。ROC用于处理序列号回绕（65535->0）。

2. 生成会话密钥和盐： SRTP需要三种密钥材料：加密密钥k_e、认证密钥k_a、和盐键k_s。它们通过一个伪随机函数（在AES-CM下，就是AES本身作为PRF）来生成。

   • 构造一个label。对于加密密钥，label = 0x00；对于认证密钥，label = 0x01；对于盐键，label = 0x02。
   • 构造输入块：x = (0x00 | sessionSalt | label | packet_index_48bits | 0x00)，共128位（16字节）。
   • 使用master_key对x进行AES加密，输出128位，即为所需的密钥材料。

   在实际实现中，为了效率，我们通常不是为每个包都派生一次，而是为每个SSRC在ROC变化时（或根据key_derivation_rate）派生出一组会话密钥。

4.2 C++实现SRTP加密上下文

下面是一个高度简化的SRTP上下文类，用于管理密钥和状态：

#include <array> #include <vector> #include <openssl/aes.h> // 使用OpenSSL作为加密后端示例 #include <openssl/hmac.h> #include <openssl/sha.h> class SrtpContext { public: enum class CryptoSuite { AES_CM_128_HMAC_SHA1_80, // 80位认证标签 AES_CM_128_HMAC_SHA1_32 // 32位认证标签 }; SrtpContext(CryptoSuite suite, const std::vector<uint8_t>& masterKey, const std::vector<uint8_t>& masterSalt) : suite_(suite), masterKey_(masterKey), masterSalt_(masterSalt), roc_(0) { // 根据suite_初始化密钥长度等参数 deriveSessionKeys(0); // 为ROC=0初始化会话密钥 } // 加密并认证一个RTP包 bool protect(RtpPacket& packet, uint32_t ssrc) { // 1. 获取包索引 (ROC << 16 | seq) uint16_t seq = ntohs(*reinterpret_cast<const uint16_t*>(packet.data() + 2)); uint64_t packetIndex = (static_cast<uint64_t>(roc_) << 16) | seq; // 2. 如果需要（根据ROC），重新派生会话密钥 // 这里简化处理，假设ROC不变 // 3. 生成加密流（AES-CTR的密钥流） std::vector<uint8_t> keystream = generateAesCmKeystream(packetIndex, ssrc, packet.buffer.size() + authTagLen()); // 4. 加密载荷：RTP载荷部分与密钥流进行异或 size_t payloadOffset = 12; // 固定头之后 size_t payloadLen = packet.buffer.size() - payloadOffset; for (size_t i = 0; i < payloadLen; ++i) { packet.buffer[payloadOffset + i] ^= keystream[i + (payloadOffset - 12)]; // 密钥流从对应位置开始 } // 5. 计算认证标签（HMAC-SHA1 over 整个包 + ROC） std::vector<uint8_t> tag = computeAuthTag(packet, ssrc, packetIndex); // 6. 将认证标签附加到包尾 packet.buffer.insert(packet.buffer.end(), tag.begin(), tag.end()); return true; } // 验证并解密一个SRTP包 bool unprotect(const uint8_t* data, size_t len, RtpPacket& outPacket, uint32_t ssrc) { // 1. 分离数据和认证标签 size_t tagLen = authTagLen(); if (len <= tagLen) return false; size_t dataLen = len - tagLen; const uint8_t* receivedTag = data + dataLen; // 2. 从RTP头中解析序列号，并结合ROC猜测包索引 uint16_t seq = ntohs(*reinterpret_cast<const uint16_t*>(data + 2)); // 这里需要一个ROC的猜测和同步算法（滑动窗口），是SRTP实现中最复杂的部分之一 // 简化：假设我们知道正确的ROC uint64_t packetIndex = (static_cast<uint64_t>(roc_) << 16) | seq; // 3. 验证认证标签 // 需要根据data和猜测的packetIndex重新计算tag，并与receivedTag比较 // if (!verifyAuthTag(data, dataLen, ssrc, packetIndex, receivedTag)) return false; // 4. 认证通过后，生成密钥流并解密载荷 // ... 解密过程与加密对称 ... // 5. 更新ROC（如果序列号发生了回绕） // if (seq < lastSeq && (lastSeq - seq) > 0x8000) roc_++; // 简单回绕检测 return true; } private: CryptoSuite suite_; std::vector<uint8_t> masterKey_; std::vector<uint8_t> masterSalt_; uint32_t roc_; // 回绕计数 std::vector<uint8_t> encKey_; // 当前会话加密密钥 std::vector<uint8_t> authKey_; // 当前会话认证密钥 std::vector<uint8_t> saltKey_; // 当前会话盐键 void deriveSessionKeys(uint32_t roc) { // 实现基于masterKey, masterSalt和roc的密钥派生 // 使用AES-CM作为PRF // 生成encKey_, authKey_, saltKey_ } std::vector<uint8_t> generateAesCmKeystream(uint64_t packetIndex, uint32_t ssrc, size_t length) { // 根据RFC3711，构造AES-CTR的计数器（IV） // IV = (salt_key * 2^16) XOR (ssrc * 2^64) XOR (packet_index * 2^16) // 然后使用encKey_对计数器进行AES加密，生成密钥流 std::vector<uint8_t> keystream(length); // ... 调用OpenSSL AES_ctr128_encrypt ... return keystream; } std::vector<uint8_t> computeAuthTag(const RtpPacket& packet, uint32_t ssrc, uint64_t packetIndex) { // 计算HMAC-SHA1，输入是整个RTP包（加密后）+ ROC（作为额外认证数据） std::vector<uint8_t> tag(authTagLen()); // ... 调用OpenSSL HMAC ... return tag; } size_t authTagLen() const { return (suite_ == CryptoSuite::AES_CM_128_HMAC_SHA1_80) ? 10 : 4; // 80位=10字节，32位=4字节 } };

实现中的核心难点与技巧：

1. ROC同步与重放保护：接收端在不知道发送端ROC的情况下，需要正确猜出包索引才能解密。标准做法是维护一个滑动窗口，记录已接收的包索引，并尝试用当前的ROC和ROC-1去验证认证标签。一旦验证成功，就更新本地的ROC。同时，这个滑动窗口也用于检测和拒绝重放包。
2. AES-CTR模式的使用：AES-CM就是AES-CTR模式。计数器（IV）的构造必须严格按照RFC，任何偏差都会导致加解密双方生成的密钥流不同，从而解密失败。IV由会话盐、SSRC和包索引共同决定。
3. 认证数据的范围：计算HMAC时，输入数据包括整个加密后的RTP包（头+加密载荷），以及隐式的ROC（对于RTP包，是包索引的高32位？这里需仔细查RFC，实际是包索引的48位整体以某种形式参与）。认证标签保护了数据的完整性和来源真实性。
4. 性能优化：为每个包重新派生密钥和生成密钥流是昂贵的。实践中，会为每个SSRC预计算一定量的密钥流，或者使用高效的计数器模式实现。

5. 完整流程串联与调试

5.1 发送端与接收端工作流

发送端伪代码流程：

// 初始化 SrtpContext srtpCtx(CryptoSuite::AES_CM_128_HMAC_SHA1_80, masterKey, masterSalt); UdpSocket txSocket; uint16_t seq = random(); uint32_t timestamp = random(); uint32_t ssrc = random(); while (hasAudioFrame) { // 1. 采集音频帧 AudioFrame frame = captureAudio(); // 2. 编码（如果是压缩格式，如OPUS） // std::vector<uint8_t> encoded = opusEncoder.encode(frame); // 3. 封装RTP RtpPacket rtpPacket(seq++, timestamp, ssrc, payloadType, isFirstFrame, frame.data(), frame.size()); timestamp += samplesPerFrame; // 根据采样率增加 // 4. SRTP保护 srtpCtx.protect(rtpPacket, ssrc); // 5. 发送UDP txSocket.sendTo(rtpPacket.data(), rtpPacket.size(), remoteAddr); }

接收端伪代码流程：

// 初始化 SrtpContext srtpCtx(/* 相同的suite, masterKey, masterSalt */); UdpSocket rxSocket; JitterBuffer jitterBuffer; // 抖动缓冲区 AudioRenderer renderer; while (running) { // 1. 接收UDP数据 std::vector<uint8_t> packet = rxSocket.receive(); // 2. SRTP解保护（验证+解密） RtpPacket parsedPacket; // 假设有解析构造函数 if (srtpCtx.unprotect(packet.data(), packet.size(), parsedPacket, expectedSsrc)) { // 3. 解析RTP头，获取序列号、时间戳等 // 4. 放入Jitter Buffer进行排序和抗抖动处理 jitterBuffer.insertPacket(std::move(parsedPacket)); } else { // 认证失败或解密失败，记录日志，丢弃包 logError("SRTP unprotect failed"); } // 5. 从Jitter Buffer中按时间戳取出并播放 if (auto frame = jitterBuffer.getNextFrame()) { // 解码（如果是压缩格式） // AudioFrame decoded = opusDecoder.decode(frame->payload); renderer.play(frame->payload); } }

5.2 常见问题与排查技巧实录

在实际集成和调试中，你会遇到各种各样的问题。下面是我踩过的一些坑和解决方法：

问题1：接收端解密失败，播放出来是噪音或无声。

• 排查思路：
  1. 检查主密钥和主盐：确保发送和接收双方使用的是完全相同的master_key和master_salt。一个字节都不能错。建议在调试初期，将双方配置的密钥和盐打印出来（Hex格式）进行比对。
  2. 检查加密套件：双方必须协商使用相同的CryptoSuite（如AES_CM_128_HMAC_SHA1_80）。
  3. 检查ROC/包索引：这是最棘手的部分。接收端必须能正确重建发送端的48位包索引。在日志中同时打印发送端的序列号、ROC和计算出的包索引，以及接收端猜测的包索引。如果接收端ROC落后或超前，解密就会失败。确保你的ROC同步算法（滑动窗口）正确实现了。
  4. 检查AES-CTR的IV生成：严格按照RFC 3711第4.1.1节生成IV。将发送端生成的IV和接收端为同一个包生成的IV都打印出来对比。常见的错误是SSRC或包索引的字节序弄错，或者与盐键拼接的顺序不对。
  5. 检查载荷偏移：确认你加密/解密的是RTP载荷部分（从第13字节开始），而不是整个UDP数据报。RTP头是不加密的（但受认证保护）。

问题2：SRTP认证失败，包被丢弃。

• 排查思路：
  1. 认证密钥不一致：同解密失败，先核对主密钥和主盐。
  2. 认证标签长度不匹配：对方发送的是80位标签，你尝试用32位验证，肯定失败。确认authTagLen()。
  3. 认证数据范围不一致：计算HMAC时输入的数据必须完全一致。RFC规定，对于RTP包，认证数据是整个SRTP包（RTP头+加密载荷+ROC），其中ROC是以32位大端整数形式附加的。确保双方在计算认证标签时，附加ROC的方式一致。
  4. 重放攻击：可能是正常的包因为网络延迟，到达时落在了重放保护窗口之外。可以适当调大滑动窗口的大小，但要注意安全权衡。

问题3：音频播放有卡顿或加速。

• 排查思路：
  1. 时间戳错误：这是首要怀疑对象。检查发送端时间戳的增量是否正确。计算公式：timestamp_increment = clock_rate * packet_duration / 1000。例如，48kHz采样率，20ms包间隔，增量应为960。如果增量计算错误，接收端的播放时钟就会错乱。
  2. Jitter Buffer配置不当：缓冲区太小，无法抵抗网络抖动，导致欠载（卡顿）；缓冲区太大，引入的延迟过高。需要根据网络状况动态调整。
  3. 序列号不连续：大量丢包会导致Jitter Buffer等待超时，产生卡顿。监控接收端的丢包率。如果丢包严重，需要启用前向纠错（FEC）或重传（NACK）机制。

问题4：内存泄漏或性能瓶颈。

• 排查思路：
  1. 避免频繁分配内存：在音频处理这种高实时性的循环中，new/delete或std::vector的频繁分配/释放是致命的。使用内存池或预分配循环缓冲区来管理RTP包和音频帧。
  2. 优化加密操作：AES加密是计算密集型操作。可以考虑使用硬件AES指令（如Intel的AES-NI）来加速。OpenSSL的EVP接口在支持时会自动使用硬件加速。
  3. 简化日志：在稳定前可以打详细日志，但在性能测试和最终发布时，务必关闭调试日志，特别是那些在每次收发包时都打印的日志。

调试工具箱建议：

• Wireshark：这是终极武器。它可以解析RTP/RTCP/SRTP报文（需要输入主密钥和主盐）。在Wireshark中看到“Decrypted SRTP”字样，并且能播放出音频，是验证整个流程是否正确的最直观方法。
• 十六进制转储：在关键节点（加密前、加密后、发送前、接收后、解密后）将数据包以Hex形式打印出来，进行逐字节比对。
• 单元测试：为RTP封装、SRTP密钥派生、加密、解密分别编写单元测试，使用RFC中提供的测试向量进行验证，确保基础算法的正确性。

6. 进阶考量与生产环境建议

当你基本跑通流程后，为了达到生产级应用，还需要考虑更多：

1. 密钥管理：我们示例中使用的是静态密钥。真实场景必须使用动态密钥交换，如DTLS-SRTP（WebRTC的标准）或ZRTP。这涉及到DTLS握手、证书交换等更复杂的网络编程。核心思想是在媒体通道建立前，先通过一个安全的信令通道协商出SRTP所需的主密钥和主盐。
2. 抗丢包与抗抖动：实现一个自适应的Jitter Buffer。它不仅要缓冲数据，还要根据网络延迟的变化动态调整缓冲区大小，并在丢包时进行适当的插值或使用FEC/重传恢复的数据。
3. 多线程与异步IO：音频采集、编码、RTP打包、加密、网络发送可能需要在不同的线程中流水线作业，以充分利用多核CPU。同样，接收、解密、解码、播放也需要高效的线程间通信。
4. 支持更多编码格式：除了PCM，集成像OPUS、AAC、G.711这样的编码器。注意，编码器通常有内部延迟，需要在时间戳计算中考虑进去。
5. 完整的RTCP实现：实现SRTCP，并定期发送/接收RR/SR报文，计算往返时间（RTT）、丢包率、抖动，用于网络质量评估和可能的码率自适应。
6. 代码健壮性：添加全面的错误处理、超时机制、连接状态管理。网络环境是不可靠的，代码必须能优雅地处理各种异常。

从头实现RTP/SRTP是一个系统工程，它强迫你去理解实时流媒体传输的每一个细节。虽然过程充满挑战，但当你听到加密后的音频流在另一端被清晰、安全地还原出来时，那种成就感是无与伦比的。这份指南提供了一个坚实的起点和清晰的路线图，希望能帮你避开我当年走过的那些弯路。记住，多写测试，多用Wireshark验证，从最简单的PCM明文RTP开始，逐步加上加密层，每一步都确保稳固后再前进。