★ FEATURED ARTICLE 简介围绕G.711音频编码与RTP实时传输的工程示例面向音视频开发、VoIP及流媒体初学者。内容完整呈现了从G.711音频文件读取、RTP包头构造序列号、时间戳、同步源标识到UDP发送的封装流程并区分了北美常用的μ-law与欧洲A-law两种编码方式帮助理解不同场景下的音频编码选择。压缩包共4个文件2.16MB包含C源文件、SDP会话描述、一段test.g711测试音频及readme说明文档结构精简可直接对照学习。其中的g711_rtp.c给出了可运行的封装实现a.sdp则提供媒体类型、端口等会话参数配合VLC即可验证RTP流是否成功接收并播放。目前已有1486人学习。对于希望快速掌握G.711封装RTP、理解SDP协商机制和VLC收流逻辑的开发者来说这是一份清晰的实践参考能直观看到RTP包字段设置、负载填充与会话建立过程为后续VoIP开发或流媒体调试打下扎实基础。1. G.711封装RTP传输先定包长和PT再写码做某公司语音网关对接时我第一次把G.711编码后的数据直接塞进UDP发送结果对端播放器全是“嘶嘶”杂音拨号音都识别不了。后来发现问题不在编码而在封装G.711只是音频编码格式必须按RTP载荷格式打包固定12字节头填上PT、序号和时间戳接收端才能重建媒体流。这个过程看着简单但包长、时间戳步长和PT值任何一个对不上就会出现难排查的音频故障。这篇文章整理了G.711封装RTP的完整流程从20ms包长计算、RTP头部字段填写到C语言封装实现以及多路并发和收流验证适合正在做VoIP网关、门禁对讲和软交换接入的开发者。2. 怎么让G.711进RTP包包长、载荷格式与RTP头字段2.1 先看清G.711编码PCMU与PCMA怎么选G.711是一种波形语音编码标准固定采样率8000Hz每个样本编码后占1字节编码总码率64kbps。它有两个变体PCMU采用μ律压扩主要用在北美和日本PCMA采用A律压扩主要用在欧洲和中国。国内设备对接时PCMA更常见但很多SIP网关默认同时提供两种。选择时不是看哪个更“好”而是看对端在SDP应答里选了哪个。如果两端一直协商成PCMU封装函数就按PCMU处理不能因为本地采集数据来自A律编码就混着打包。负载格式上G.711是“裸字节流”类型的RTP载荷没有额外载荷头。也就是说RTP载荷区域就是连续的G.711编码字节。一个RTP包里放多少字节取决于你打算把多少毫秒的音频打成一个包。计算方法是def frame_bytes(ms: int, sample_rate: int 8000) - int: return ms * sample_rate // 1000这段代码把毫秒变成采样数20ms包对应160个样本30ms包对应240个样本。由于G.711每样本正好1字节样本数就是载荷字节数。在实际工程里我一般用20ms作为默认值因为它在延迟和网络开销之间比较平衡。如果对端设备强制要求30ms也可以把封装参数里的帧长改成30但要注意带宽预算30ms包的载荷240字节每秒钟约33.3个包总码率仍然是64kbps只是包数量减少了一些。2.2 RTP固定头字段哪个字段决定能不能打通RTP固定头是12字节G.711封装时通常不扩展RTP头。这里给出字段模板字段取值建议说明Version2RTP版本号固定2Padding0不填充Extension0无扩展头CSRC count0无CSRCMarker0/1静音包或帧边界可置1Payload Type0或8PCMU0PCMA8Sequence Number随机初值每包1接收端检测乱序Timestamp随机初值每包160与采样率严格绑定SSRC随机标识同一媒体源这里最容易出问题的是时间戳。G.711时钟频率等于采样率8000Hz所以时间戳的单位是采样周期不是毫秒。20ms语音对应160个采样周期时间戳必须加160如果你写成加1接收端的抖动缓冲区会认为包间隔只有0.125毫秒产生大量乱序或超前。许多第一次封装RTP的开发者会犯这个错先入为主地以为时间戳就是毫秒。另一个关键是序号和时间戳的初值可以是任意随机数不一定要从0开始。原因是为了安全避免被猜出媒体流起始位置。只要发送过程中严格递增接收端就能正常工作。需要强调的是时间戳的递增步长必须和实际负载字节数一致一个20ms G.711包payload_len160那么时间戳就加160。如果你把两帧合成一个包payload_len320时间戳就要加320。封装函数不要用固定步长要根据实际载荷长度计算这样不同包长切换时才不会出错。在C语言里定义RTP头时我的习惯是这样typedef struct { uint8_t byte0; uint8_t byte1; uint16_t seq; uint32_t ts; uint32_t ssrc; } rtp_header_t;byte0和byte1按位填充seq、ts、ssrc在写入网络前必须转成网络字节序。很多开发者只关注载荷忽略头部字节序导致抓包看到时间戳大端小端颠倒接收端解析出的波形完全错乱。2.3 包长怎么选20ms不是唯一正确解包长影响端到端延迟、抗丢包能力和带宽。常用包长有10ms、20ms、30ms、40ms。下表是几种包长的参数对比包长载荷字节每秒包数有效载荷占比等价附加值10ms8010067%高包率CPU和网络中断多20ms1605080%默认推荐30ms24033.386%延迟稍高包少40ms3202589%延迟更高上表中的“每包附加40字节”指RTP头12字节、UDP头8字节、IP头20字节。包越短包头占比越高调度频率也越高包越长延迟越大且一旦丢包损失的信息也更多。实际项目中我一般固定用20ms但如果对端要求低延迟比如数字中继对接会降到10ms这时要确保CPU足够否则音频采集线程出现抖动会导致更严重的质量问题。选包长不只是本地参数还要看SDP协商。SDP里不会直接写包长但可以通过aptime:20表示建议包长。虽然多数网关不强制检查谨慎起见封装前最好把本地ptime和对端能力都打出来确认一致。如果遇到对端只支持40ms而你按20ms发对端可能会因为缓冲不足产生间歇性丢音。动手前最后一次检查清单一般是确认编码方式是PCMU还是PCMA确认SDP里协商出的PT值确认包长对应的时间戳步长最后再写发送循环。这套顺序看着基础却能避开后面一大半的返工。3. 把G.711帧封装成RTP包一段可编译的C实现3.1 封装函数设计输入编码帧输出完整RTP包有了前面字段定义封装函数可以写得很紧凑。这里提供一段我在模拟项目X里用过的C代码函数负责把一帧G.711载荷填进RTP头并更新会话状态。#include stdint.h #include string.h #include arpa/inet.h typedef struct { uint16_t seq; uint32_t timestamp; uint32_t ssrc; } rtp_session_t; int g711_to_rtp(rtp_session_t *s, uint8_t *payload, int payload_len, uint8_t *out, int out_cap, int pt, int marker) { if (out_cap payload_len 12) return -1; out[0] 0x80; out[1] (uint8_t)((marker ? 0x80 : 0) | (pt 0x7F)); out[2] (uint8_t)((s-seq 8) 0xFF); out[3] (uint8_t)(s-seq 0xFF); uint32_t ts_be htonl(s-timestamp); memcpy(out 4, ts_be, 4); uint32_t ssrc_be htonl(s-ssrc); memcpy(out 8, ssrc_be, 4); memcpy(out 12, payload, payload_len); s-seq 1; s-timestamp payload_len; return payload_len 12; }逻辑说明函数把G.711的载荷和RTP头字节拼接到同一个输出缓冲返回RTP包总长度。第0字节固定0x80表示版本2且无填充无扩展第1字节同时写入marker和PT。seq、timestamp、ssrc在内存里必须以网络字节序传输所以这里用htonl把32位整数转成大端。函数尾部同步推进会话计数seq加1timestamp增加payload_len保证下一包的状态连续。注意一种边界情况如果payload_len不固定时间戳步长等于载荷长度这一点需要和发送端帧计数器保持一致。比如你采集到160字节就调用一次那么时间戳增量始终是160如果你在某次循环里凑了两帧320字节再调一次时间戳就加320。接收端不会关心你包内放了多少音频只会按时间戳的差值来恢复播放时长所以绝不能出现“实际20ms载荷但时间戳加了320”的错误。3.2 调用方式与发送循环从编码器到UDP socket封装函数本身不负责网络发送实际工程里调用它的是一个采集发送循环。常见做法是先创建UDP socket绑定本地端口然后进入循环从音频采集设备读一帧PCM数据经过G.711编码器得到160字节的G.711载荷调用g711_to_rtp得到完整RTP包最后用sendto发往SDP协商出的对端地址。// 伪代码发送一包20ms的G.711音频 rtp_session_t sess { .seq 1, .timestamp 0, .ssrc 0x12345678 }; int fd socket(AF_INET, SOCK_DGRAM, 0); struct sockaddr_in peer; while (running) { uint8_t pcm[320]; uint8_t g711[160]; uint8_t packet[172]; int nread read_audio_frame(pcm, 320); encode_g711(pcm, nread, g711); // 16bit PCM - 8bit G.711 int pkt_len g711_to_rtp(sess, g711, 160, packet, sizeof(packet), 0, 0); sendto(fd, packet, pkt_len, 0, (struct sockaddr*)peer, sizeof(peer)); }这段伪代码里read_audio_frame从采集设备读入320字节的PCMencode_g711按2:1压缩成160字节。PT固定传0表示PCMU如果协商结果是PCMA这里应该传8。sendto的目的是把完整RTP包交给UDP协议栈RTP不保证可靠顺序也不需要ACK。我一般会在主循环里加入一个发送节奏判断如果当前系统时间是下一个发包时刻则发送否则继续读取而不是用sleep硬等否则调度抖动会被音频播放放大。使用socket时需要注意sendto返回的长度应等于pkt_len如果返回小于pkt_len说明底层发送缓冲不足需要把包拆开或增大发送缓冲。这个现象在并发包率高时会出现表现为抓包看到少了一包。若遇到可以用setsockopt调整SO_SNDBUF到16KB以上同时考虑把发送队列从主循环拆到独立线程。3.3 与SDP协商对接PT值如何保持一致RTP封装只是链路后半段前半段是SIP或其它信令把两个端点拉通。SDP里会描述媒体格式和端口例如maudio 5004 RTP/AVP 0 8 artpmap:0 PCMU/8000 artpmap:8 PCMA/8000这里m行第一个数字是对端希望接收RTP流的端口0和8分别代表PCMU和PCMA两种编码。本端发送时payload type必须用对端在应答中实际选择的编号而不能凭记忆写死。很多设备协商时会选PCMA并回复PT8如果发送端继续按PT0封装抓包看头部没问题但接收端媒体处理器不会把该PT路由到解码器导致对端显示媒体状态正常却听不到声音。我习惯在项目里维护一张PT映射表把信令选择的PT号映射到编码类型和帧长SDP PT编码采样率包长0PCMU800020ms8PCMA800020ms96动态PT800020ms动态PT通常出现在不同编码共存时需要从artpmap行解析实际格式。解析时应同时读取“编码名/采样率”和“aptime”行ptime可能不是20例如aptime:30表示建议30ms包长。我一般在回调里更新封装参数同时重置会话序号和时间戳初值避免SDP变更后仍然延续旧会话的计数。实际封装时marker位的使用也有讲究。在RTP会话开始时第一个包常把marker置1表示这包是语音突发的开始帮助接收端做缓冲对齐。普通通话过程中marker为0。如果实现了静音抑制在静音结束后第一包语音也要把marker置1。我的经验是即使不启用VAD也保持“会话首包置1”这让对端更容易跳过前导缓冲。marker不参与PT协商它只是头里的一位不用在SDP里声明。4. 封装期间最容易翻车的五个点避坑清单封装G.711 RTP的代码不多但调试时每个字段都可能是雷区。下面的问题都是我实际遇到或同行分享过的按“现象—原因—解决”整理。排查时不要逐个试先抓包再看PT、时间戳和SSRC方向就清楚了。提示RTP排错时先看时间戳增量再看PT最后看SSRC。三样都没问题才值得检查网络丢包。4.1 对端听到“沙沙”声和爆破音现象接通后对端语音嘈杂像收音机白噪声请求重拨时双音多频也无法识别。原因时间戳没有按采样率步进。常见实现把时间戳当成毫秒来加或把每次实际经过的墙钟时间换算成采样周期后累加结果包与包之间的时间戳增量不是160接收端抖动缓冲区错位把正常语音当成乱序数据处理。解决让时间戳每包增加payload_len。如果payload_len固定160则每包加160初值随机即可。代码里不要用当前系统时间取模也不要根据发送间隔动态修正保持单调递增。排查时用抓包工具连续统计20个包的timestamp差值正常应该全是160出现随机值就去查封装状态是不是被多线程并发写。4.2 通话前几秒正常之后声音逐渐变调现象刚开始对话正常大约十几秒后声音明显变慢或变快最后对端难以听懂。原因发送节奏由软件sleep控制。sleep(20)在系统负载高时实际等待可能变成20.5ms累积下来每秒少发0.5ms时间戳却仍按160步进。接收端按时间戳恢复播放会不断拉长或压缩音频听感就是变调。解决不要用sleep控制发送节奏改由音频采集驱动的定时器或回调。采集设备本身有固定时钟每采到160个样本就发一包即使发送线程临时阻塞也只能丢包不会造成时间戳漂移。若必须用主循环应该在采集间隙用“目标时间戳-当前时间戳”计算等待而不是固定sleep。4.3 抓包PT类型与SDP不一致对端静音现象SDP协商成功呼叫建立RTP包也在持续发送但对端播放静音媒体统计里收包数为0或丢包率100%。原因封装函数里写死了PT0而对端在应答里选择了PCMA的PT8某些网关还会把动态PT映射到96-127写死就更对不上。接收端检查载荷类型不是它协商的格式会直接丢弃。解决在SDP协商回调中更新封装参数发送时从rtp_session_t里读取pt字段。动态PT也一样先把artpmap解析出的编码名映射成内部枚举再传给封装函数。排查时对比抓包里的PT值和SDP报文列出实际协商后的PT号而不是看配置文件。4.4 RTP长度正常但接收端出现“拉长音”现象通话过程中接收方听到一个字被拉长拖尾有时还伴随爆音抓包看包间隔有空缺。原因静音抑制/语音活动检测开启后静音期间不发包接收端在没有后续数据时无法确定静音持续多久只能重复最后收到的语音帧产生拉长音。这不是RTP封装错误而是发送策略问题。解决静音期间发送静音包载荷可以是全0字节或者重复静音帧并保持时间戳正常步进有条件的话实现舒适噪声用低电平的随机噪声填充。很多网关对静音包的处理是“收到任何RTP包都把缓冲清空”所以至少保证静音期间不低于每20ms发一包。4.5 多路并发时不同通道的声音串线现象同时跑多个通话时通道A里偶尔听到通道B的说话声切换频繁时更明显。原因多个RTP会话共用一个封装函数但会话状态没有隔离或者多个通道用了同一个SSRC、同一个UDP源端口接收端按SSRCPT区分媒体源冲突后就会把两个流混在一起。解决每个通话建立独立的rtp_session_tSSRC用随机数生成且确保同一本地端口上的不同通道不用同一个SSRC。如果并发量高还应单独记录源端口让每路(RTP源地址, 源端口, SSRC)组合唯一。排查时给每路打日志打印SSRC和源端口重复就会立刻暴露。以上五个问题现象都在音频层根因在封装层。遇到类似情况我第一件事是抓包确认三件套PT、时间戳增量和SSRC分别和SDP、包长、会话表对照一遍。排除了封装问题再去看网络和声学部分。5. 多路并发发送时的会话表与时间戳管理解决并发串线问题单路封装跑通后马上会遇到多路并发比如一台网关同时处理8路或16路通话。这时候如果还按单路全局变量写就等着串线和时间戳混乱。5.1 会话结构与独立状态每个RTP会话必须持有独立的seq、timestamp、ssrc以及当前PT和对端地址。不要把状态放在全局结构里被多路共用。典型会话结构如下typedef struct { uint16_t seq; uint32_t timestamp; uint32_t ssrc; int pt; int frame_ms; struct sockaddr_in peer; } rtp_channel_t;每个通道实例对应一路通话。seq和timestamp在呼叫开始时随机初始化之后只由该通道的发送循环更新。ssrc建议用伪随机数生成比如xorshift生成后要和已有通道比较避免重复。若通道数多我一般用哈希表按call_id索引通话结束时销毁状态。static uint32_t rng_state 0x9E3779B9; uint32_t xorshift32() { rng_state ^ rng_state 13; rng_state ^ rng_state 17; rng_state ^ rng_state 5; return rng_state; }这段伪随机数生成器简单且速度快多路并发时每创建一路通话就调用一次取SSRC同时和历史值比较。注意rng_state在进程启动时要重新赋初值否则每次重启都产生相同序列跨进程会话会撞SSRC。5.2 时间戳基准不要用全局计数器常见误用是为了简化定义一个全局递增计数器每发一个RTP包就加160所有通道共用。这样第一路正常第二路创建晚一些初始时间戳就沿用当前全局值导致第二路开始时间戳与包序号不同步。正确做法是每路内部维护自己的时间戳创建会话时用随机值作为初值发送时只和本路的payload_len绑定额外加上去。这样即使两路的发包节奏不一致时间戳也各自自洽。代码上发送函数不再接收全局步长而是从通道结构里读void send_g711_frame(rtp_channel_t *ch, uint8_t *payload, int len) { uint8_t pkt[336]; int n g711_to_rtp(ch-sess_state, payload, len, pkt, sizeof(pkt), ch-pt, 0); sendto(fd, pkt, n, 0, (struct sockaddr*)ch-peer, sizeof(ch-peer)); }这里ch-sess_state的类型就是第3章的rtp_session_t封装函数只负责改自己那份seq和timestamp。调用的地方不需要关注其他路每路相当于一个独立有限状态机。5.3 发送线程与队列避免一路阻塞拖垮全部多路并发时网络发送最好与音频采集解耦。常见做法是每个通道一个独立发送协程/线程或者用一个全局发送队列采集线程把封装好的包入队发送线程统一从队尾取包并发送。第二种方式开销小但要注意队列长度和丢包策略。我一般这样处理每个通道循环调用一次send_g711_frame后检查对方socket是否可写如果UDP发送缓冲满就丢弃这包并记录计数而不是阻塞等待。VoIP对实时性要求高宁可丢当前包也不能把后续包都卡住。这个策略需要在测试中调并发8路时队列深度设为64即可一路抖动几十毫秒不会造成大面积丢包。5.4 包长不一致时的混合场景对接不同对端有些要求20ms有些要求30ms。如果每个通道用不同的frame_ms发送节奏也要跟着变化。多路循环里不能统一按20ms tick发包否则30ms通道会多发包。常见做法是每个通道记录一个next_send_tick每次循环先检查“当前时间 next_send_tick”满足才封装发送然后按帧长推进下一次时间。这样以时间驱动代替计数驱动包长不一致的通道也能共存。uint32_t next_tick_ms[16]; uint32_t now_ms; for (int i 0; i channel_count; i) { rtp_channel_t *ch channels[i]; if (now_ms next_tick_ms[i]) { uint8_t g711[240]; read_encoder_frame(ch, g711, ch-frame_bytes); send_g711_frame(ch, g711, ch-frame_bytes); next_tick_ms[i] now_ms ch-frame_ms; } }这里的frame_ms和frame_bytes必须对应20ms通道的frame_bytes是16030ms通道的frame_bytes是240。每次循环先看时间是否到点到点才读一次编码帧并发送。用这个方式不同包长的通道可以平滑共存不会出现某个通道因为其他通道调度频率高而被饿死。5.5 并发测试里的观察指标多路并发调试时重点关注三个指标每路的呼入呼出成功率、抓包里每路seq连续性、以及音频主观试听是否有串线。如果seq出现跳号说明发送队列丢包或发送线程来不及处理。多路场景下的RTP封装错误往往不是封装函数本身而是状态隔离和调度问题。只要每路状态独立、时间戳自洽、发送节奏由帧长驱动并发问题就会少掉一大半。6. 收流端验证技巧抓包核对时间戳、SSRC与可听化测试封装完别急着联调先用本机回环验证RTP包是否合法。这里给你一套我从抓包到试听的检查流程。第一个检查点抓包过滤RTP流看头三包记录的PT、seq、timestamp增量。正常情况下PT等于你和对端协商好的类型seq连续timestamp每包加固定值16020ms包。可以用一个简单的Python接收脚本验证import socket, struct s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind((0.0.0.0, 5004)) prev_ts None prev_seq None while True: data, addr s.recvfrom(4096) if len(data) 12: continue pt data[1] 0x7f seq struct.unpack(!H, data[2:4])[0] ts struct.unpack(!I, data[4:8])[0] if prev_ts is not None: ts_diff ts - prev_ts seq_diff (seq - prev_seq) 0xffff print(fPT{pt} seq_delta{seq_diff} ts_delta{ts_diff}) prev_ts, prev_seq ts, seq脚本说明收到RTP包后解析PT、seq、时间戳打印期望值。PT应该等于协商值seq_delta大多为1ts_delta应该是160或对应包长的采样数。如果seq_delta出现大于1说明发送侧丢包或没控制住节奏。第二个检查点把收到的载荷落盘成纯音频文件用播放器按8kHz、8bit、非压缩格式试听。G.711载荷本身是PCMU或PCMA编码播放器要选择对应的μ律/A律格式否则听起来就是刺耳白噪声。试听时如果听到单个字拉长优先怀疑静音抑制导致的时间戳缺口如果声音断续再查网络丢包。第三个检查点多路并发时打印每个通道的SSRC确认没有重复。同一个UDP端口下如果出现两个SSRC相同的包接收端会毁掉两路语音。检查方式是写日志或者抓包工具按SSRC着色一眼就能发现相同颜色。从那以后我每次对接G.711网关都先跑一遍“三查”查PT是否和SDP一致查时间戳增量是否等于包长采样数查SSRC是否唯一三查通过后才开始听音频。这套流程帮我少熬了好几个通宵希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
