pcapsipdump：按SIP Call-ID拆分pcap，一个通话一个文件

简介pcapsipdump 是一款基于 libpcap 开发的开源 SIP 嗅探工具能够监听指定网络接口自动识别 SIP 信令与 RTP 媒体流并将每个会话单独保存为命名友好的 pcap 文件结果可直接用 tcpdump、Wireshark 打开分析。该工具主要面向 VoIP 运维、网络排障和协议分析人员也可用于学习 SIP 会话建立与媒体协商的全过程。压缩包内共有 16 个文件以 C/C 源码与头文件为核心配合 Makefile 编译脚本、init 服务管理脚本、spec 打包配置以及 README、ChangeLog 等文档包体仅 15KB。阅读源码可以理解按会话拆分抓包、呼叫表维护、文件命名规则等关键实现同时附带的平台适配文件有助于在 Red Hat、Debian、Solaris 等环境中完成编译部署阅读文档也能快速掌握用法和扩展思路。开发者可据此梳理抓包流程并根据实际需求新增过滤规则或输出格式。该资源已有 298 人学习适合想深入 libpcap 抓包原理或开发自定义 VoIP 监测工具的开发者。1. 拆 SIP 会话的 pcap sip dump一个通话一个文件省掉你半夜扒包的命一个语音网关同时跑着几十路通话客户投诉其中一路声音断续。tcpdump 把整个接口的包全录下来了但你想单独看这一路的 RTP 流却发现要么在 Wireshark 里按时间硬切把前后其他路的包也剪进来要么靠 IP 和端口手筛IP 头一 NAT端口一对不上全白干。pcapsipdump 这类按 SIP call-id 自动拆包的 pcap sip dump 工具解决的就是这个尴尬一个通话一个 pcap 文件每个文件里只有这一路的 SIP 信令和 RTP 媒体包拿到手直接用 Wireshark 打开看 RTP 统计不用自己写脚本从几十万包里捞那几万个媒体包。它适合语音运维、VoIP 开发、抓包分析这几类人尤其是懒得为每个现场写 Python 解析器的人。2. 安装与编译老工具的 configure 三连与新系统的三个坑pcapsipdump 是那种很纯粹的老牌 C 程序整个项目就一个核心二进制依赖极轻但越轻的东西在现在的新系统上反而越容易在编译阶段翻车。这一章先把依赖、参数确认、编译排错走通后面抓包才稳。2.1 依赖确认libpcap 是唯一硬依赖但版本有讲究pcapsipdump 抓包用的不是自己实现的收包逻辑而是直接基于 libpcap 的 pcap_open_live 和 pcap_loop所以系统里必须装 libpcap 的开发头文件。Debian/Ubuntu 系是libpcap-devCentOS/RHEL 系是libpcap-devel。这里有一个新系统容易踩的版本问题比较新的发行版带的 libpcap 是 1.9.x 甚至 1.10.x而 pcapsipdump 0.2 是较早的代码对 libpcap 的 API 调用还是老一套。多数情况是兼容的但如果编译时出现pcap_createsrcstr、pcap_open这类符号找不到的报错基本可以判定是 libpcap 头文件路径没被 configure 找到而不是代码本身的问题。安装依赖的命令Debian/Ubuntu 系sudo apt-get install -y build-essential libpcap-devCentOS/RHEL 系sudo yum install -y gcc make libpcap-devel逻辑说明第一段命令把编译工具链和 libpcap 开发头文件一起装上第二段是红帽系对应的包名注意libpcap-dev和libpcap-devel只差一个后缀但缺了哪一个在编译阶段都会直接报找不到pcap.h。参数说明如果你用的是 RHEL 9 这类默认启用 dnf 的系统把yum换成dnf即可包名不变。2.2 configure 三连与两个典型编译错误源码包解开之后是标准的 autotools 工程当前目录下执行三板斧tar zxf pcapsipdump-0.2.tar.gz cd pcapsipdump-0.2 ./configure make逻辑说明configure会检查 libpcap 头文件和链接库的位置同时确认当前平台是否支持pcap_setdirection这类可选 APImake编译出名为pcapsipdump的二进制。参数说明整个包没有复杂的 configure 开关默认生成的二进制就在./pcapsipdump不需要make install也能直接跑这点对只想在服务器上临时用一下的场景很友好。编译期最常见的报错有两类。第一类是找不到pcap.hfatal error: pcap/pcap.h: No such file or directory原因几乎都是只装了运行时库libpcap0.8或libpcap没装带头文件的-dev/-devel包补齐上面的依赖命令重跑即可。第二类是链接阶段报undefined reference to pcap_*这通常不是缺库而是 libpcap 的库文件路径没在默认链接目录里。我一般会先find /usr -name libpcap.so*确认库在哪个目录如果库存在只是路径偏就在 configure 前加环境变量CPPFLAGS-I/usr/include LDFLAGS-L/usr/lib ./configure逻辑说明这行命令把头文件路径和库搜索路径显式指给编译器绕过 configure 默认搜索路径的盲区。参数说明CPPFLAGS影响预处理阶段的头文件查找LDFLAGS影响链接阶段的.so查找如果 libpcap 在/usr/local下把两个路径相应替换。别上来就改源码先查路径这是我被这个问题折腾过两次之后学到的习惯。2.3 权限与快速验证非 root 抓包全是玄学问题编译完先别急着上生产接口用 loopback 接口做一个 10 秒的快速验证。pcapsipdump 底层走的是 raw socket 收包普通用户在很多发行版上没权限抓到的包数量恒为 0。所以验证命令最好直接带sudosudo ./pcapsipdump -i lo -w /tmp/siptest -T 5 -v -L逻辑说明-i lo指定 loopback 接口-w指定输出目录-T 5表示每个通话的拆包文件上限为 5 分钟-v会把 SIP 信令明文也落盘成文本文件-L让工具把状态写到系统日志。参数说明这个组合不是为了抓真实流量而是确认二进制能正常启动、能打开接口、能创建输出目录。跑几秒后sudo pkill pcapsipdump然后看/tmp/siptest下有没有生成带时间戳的文件。验证的另一个点是输出目录权限。pcapsipdump 拿到-w目录后如果目录不存在不会自动创建而是直接放弃写入并打印错误信息。所以脚本里要先mkdir -p这也是后面所有自动化脚本里我固定的第一行命令。3. 参数拆解从“能跑”到“按我的通话粒度拆包”pcapsipdump 的参数不算多但每个参数的语义和 tcpdump 不太一样容易按惯性理解错。比如-T不是抓包总时长而是单个通话文件的最大时长-m不是内存限制而是媒体停多久后主动关闭文件。这一章把参数按“必会和选调”拆开讲参数表放前面后面展开场景。3.1 必会参数-i、-r、-w、-v先看这张参数表后面对照场景解释参数作用典型值-i指定抓包接口eth0、any-r从已有 pcap 文件回放拆包mixed.pcap-w输出目录/var/tmp/calls-v把每个通话的 SIP 明文写入同名的.sip文件无-T单个通话拆包文件的最大时长分钟15-H让 Wireshark 正常识别时间戳无-m媒体流停止多久后关闭当前文件秒60-i最常用的值是any意思是对所有接口收包。这个值在语音网关和软交换排障时特别好用因为很多时候你根本不确认媒体流走了哪块网卡。但注意any模式下抓到的包没有具体接口信息如果服务器上有多块网卡且需要按网卡区分流量来源还是老老实实指定物理接口。-r把磁盘上已有的 pcap 文件作为输入工具只做离线拆包不碰网卡。这个参数是这套工具里我最常用的现场先 tcpdump 录一个混合包拿回来夜里再慢慢拆完全不占在线资源。-w指定输出目录配合-r就是一条离线生产线。-v在拆出来.pcap的同时额外生成一个同名.sip文本文件里面是这一路通话的 SIP 信令原文。比如呼叫 ID 是abc123会生成abc123.pcap和abc123.sip。我之前排查一个注册失败问题就是靠这个文本文件直接 grep 401 和 403 的分布在几分钟内锁定了是认证密码错而不是媒体问题。使用姿势上我习惯的“标配启动命令”长这样sudo ./pcapsipdump -i eth0 -w /var/tmp/calls -T 15 -H -v -L逻辑说明-i eth0指定从业务网卡收包-w指定拆包输出目录-T 15限制每个通话 pcap 最多 15 分钟-H输出兼容时间戳的文件头-v同步落文本信令-L把工具自身运行状态写 syslog方便出问题时留痕。参数说明-T 15不是抓包时长而是单通话上限这个数字按你业务里最长通话的预期来设太短会把长通话硬切成几个文件设太长文件会很大。3.2 拆分行为参数-T、-H、-m 的语义与配合-T的语义值得再强调一次它是“单个通话文件的时间上限”。工具从 INVITE 开始计时到-T分钟如果这个通话还在继续会滚动写到下一个文件但 call-id 不变靠 Wireshark 打开时你会发现是同一路 RTP 被切成了两段。实际排障时这个副作用不大因为你按时间看还是连续的一段流只是文件数量多一个。-H全称是 “Wireshark compatibility” 之类的作用它的作用是保证生成文件的 pcap 头里的时间戳格式能被 Wireshark 直接识别。没有-H时部分环境生成的 pcap 头时间戳是微秒精度新版 Wireshark 在某些场景会提示时间偏移。加了-H之后基本没遇到过时间轴错乱所以我的脚本里-H永远是常驻参数。-m是媒体停止多久后关闭文件的超时参数单位秒。这个参数解决的是“通话已经结束但因为 keepalive 包一直没停文件一直被占着”的问题。比如有些 SIP 终端挂了电话还会继续发 OPTIONS 保活如果没有-m这个通话的 pcap 文件会被一直写下去直到被-T切段。设成-m 60表示媒体流停 60 秒没新包就把当前文件关闭后续再来的 keepalive 就不再往这个文件里写了。选参数的思路按场景来如果你只关心信令完整性-T设 30 甚至 60 分钟都没关系信令包本来就不大如果你要拿 RTP 流做丢包率分析文件越纯粹越好-T 15加-m 60的组合会让每个文件里只有完整通话很少掺尾巴。监控长时间在线的设备时-m尤其关键这是我被一个设备“通话结束但文件一直变大”坑过一次之后才彻底搞懂的。3.3 调试辅助-L 与前台日志的取舍-L参数把运行状态写进系统日志适合放到后台跑的场景。不带-L时工具在前台打印一行行摘要每抓到一个新通话会打一条记录。我实际用的守则是短时间现场抓包用前台模式CtrlC 直接停线上长期抓包用nohup配合-L日志走 syslog不占用终端。nohup sudo ./pcapsipdump -i eth0 -w /var/tmp/calls -T 15 -H -v -m 60 -L /dev/null 21 逻辑说明这条命令把 pcapsipdump 放到后台运行-m 60避免 keepalive 把文件拖到天荒地老-L把状态写进系统日志nohup保证 SSH 断开后进程不跟着挂。参数说明/dev/null 21丢弃前台输出因为有了-L已经不需要前台打印了如果要停掉后台的抓包用sudo pkill pcapsipdump不要用 killall后者权限要求更高。4. 抓包实战从混合流量里把三通并发通话拆成独立文件上一章把参数讲完这一章直接跑一个完整流程模拟某办公室的三通并发通话其中一路有视频媒体端口各不相同先用 tcpdump 录一段混合包再用 pcapsipdump 拆开验证。整个过程在临时环境里跑重点看拆包结果和文件组织方式。4.1 第一步先录一段混合流量模拟环境里三路 SIP 终端之间互拨其中一路带视频协商RTP 端口从 40000 到 40004 不等。现场录制时我一般先用 tcpdump 定点抓一会儿sudo tcpdump -i eth0 -s 0 -w /tmp/capture_mix.pcap -Z root port 5060 or portrange 40000-40004逻辑说明-s 0表示抓整个包不截断保证 SDP 里的媒体信息是完整的-Z root让 tcpdump 抓包时切换到 root 权限并读取抓包逻辑port 5060 or portrange 40000-40004把 SIP 信令和这一段动态端口的 RTP 都收进来。参数说明抓包时长建议覆盖完至少一路完整通话比如 60 秒左右包量不用太大主要是演示拆包逻辑。这段混合 pcap 里既有 INVITE、200 OK、BYE 等信令也有三路的语音/视频 RTP 包混在一起大概一万多个包。直接拿 Wireshark 打开也能看但三路媒体流在时间轴上叠着定位某一路的问题很费眼。4.2 第二步用 pcapsipdump 离线拆包拿到混合包后用-r模式离线拆包这是不占用在线资源最理想的方式sudo ./pcapsipdump -r /tmp/capture_mix.pcap -w /tmp/split_output -T 15 -H -v -m 60逻辑说明-r让工具进入回放模式逐个读包并按 call-id 聚合每个新的 call-id 自动新建文件-w指定输出目录同一个 call-id 的 SIP 和 RTP 包会持续写入同一个文件直到 BYE 或超时关闭。参数说明-H和-v与在线模式完全一致-T 15在本例中不会被触发因为每路通话都很短-m 60保证收到 BYE 后 60 秒内如果还有媒体包也合并进同一个会话文件。输出目录里的内容大致长这样/tmp/split_output/ ├── call_001_a3f9.pcap ├── call_001_a3f9.sip ├── call_002_4e11.pcap ├── call_002_4e11.sip ├── call_003_b708.pcap └── call_003_b708.sip逻辑说明.pcap文件是这一路完整通话的 SIPRTP 包.sip文件是这一路的信令文本方便直接 grep 消息码和头域。参数说明文件名前缀是工具按 call-id 的前几位生成的不保证全局唯一如果有两个对话的 call-id 前缀相同工具会追加区分标识。这个现象很少见但如果遇到不要慌打开.sip文件对比 call-id 全值即可区分。用capinfos快速确认每个文件的包数量和时间跨度for f in /tmp/split_output/*.pcap; do echo $f capinfos $f | grep -E Number of packets|First packet time|Last packet time done逻辑说明这个循环对每个 pcap 文件执行capinfos只提取包数量和时间范围三个字段。如果你看到每个文件只有几百个包而不是混在一起的上千个包说明按会话拆分成功。参数说明grep -E里三个模式分别对应包计数、起始和结束时间如果某个文件缺了Last packet time说明文件可能被-m强制截断属于正常现象。4.3 第三步打开拆包结果验证媒体完整性这是我最看重的验证环节。拆包完成后我会直接对比混合包和拆分包的“会话完整性”tshark -r /tmp/split_output/call_001_a3f9.pcap -Y rtp | wc -l tshark -r /tmp/capture_mix.pcap -Y rtp | wc -l逻辑说明第一条命令统计拆包文件里的 RTP 包数量如果媒体包基本保留说明拆分过程没有丢 RTP第二条统计混合包里总的 RTP 包数两者大致相等或略少少了的是其他通路的媒体就说明拆分没有损伤数据。参数说明-Y rtp的显示过滤语法在 Wireshark 新版本里等价于rtp协议族老版本tshark可能不支持-Y改用-R rtp效果相同。这个验证不能省。我在某次排障时遇到过拆出来的 pcap 只有信令没有媒体的情况原因是抓包点设备和 SIP 信令不在同一跳RTP 走过别的路径。如果直接拿拆包文件看 RTP 统计就会误判媒体根本没有到网关实际只是没抓到而已。5. 避坑排查五条血泪经验覆盖 0 字节、乱文件名和拆错通话pcapsipdump 用起来的坑集中在几个特定的“翻车”场景多数不是工具本身的问题而是和抓包环境、参数误用纠缠在一起。这五条是我自己或帮别人排查过的真实现场记录按现象、原因、解决三步写清楚。5.1 抓了半天输出目录里全是 0 字节文件现象启动命令后输出目录里确实生成了文件但每个文件大小为 0或者压根没有新文件生成。原因最常见的是非 root 启动导致收不到包其次是-w指向的目录不存在工具直接静默退出创建流程。还有一种情况是接口选错比如业务流量走了eth1但-i指定的eth0上干干净净。解决先确认权限直接用sudo启动再用tcpdump -i eth0 -c 10先验证这个接口上有包在跑确认接口有流量后再启动 pcapsipdump。输出目录必须提前mkdir -p或者脚本里先执行创建命令。我自己的习惯是把目录创建、权限赋值写到启动脚本前两行避免每次手动补。5.2 同一路通话被拆成了两个文件现象和同一通话对象连续打了两次电话第二次的包没有并到第一次的文件里而是生成了新文件。原因这不是工具随机乱拆而是两次呼叫的 call-id 本身不同。很多 SIP 终端会在一次通话的多次 INVITE 重传中改变 Call-ID 的大小写格式pcapsipdump 对 call-id 是大小写敏感的另外某些设备在 update 或 re-INVITE 时会生成新的 Call-ID。两段 RTP 流对应的不是同一个 call-id 时工具自然当成新通话处理。解决先用.sip文件里的 Call-ID 头域确认两次的 call-id 是否一致。如果确实是同一通通话但 call-id 变了目前版本没有自动合并开关只能靠人工按时间范围把两个 pcap 拼接。实践中更常见的是大小写不一致旧版本工具严格比对字符串小写化处理后就能正常聚合我建议先用文本对比确认是不是大小写问题再考虑拼接方案。5.3 Wireshark 打开拆包文件时间轴乱跳现象用 Wireshark 打开拆出的 pcap时间轴不连续RTP 流的间隔明显异常但用 tcpdump 抓的原始文件没问题。原因pcap 文件头的时间戳格式兼容性问题。pcapsipdump 在写入文件头时有些环境下写的时基是微秒精度Wireshark 按默认的纳秒精度解析导致时间轴错位。这个问题在老版本 libpcap 上更容易出现。解决启动参数加-H让工具以兼容模式写入文件头如果已经生成了文件用capinfos -E可以查看文件实际精度再用editcap -T转换精度。现在我的所有启动脚本里默认带上-H基本没再遇到过时间轴乱跳。5.4 call-id 里的特殊字符导致文件名乱码现象输出目录里出现%、/等字符开头的文件或子目录文件系统报错或者文件打不开。原因部分 UA 生成的 Call-ID 里包含、:、/甚至空格。pcapsipdump 直接用 call-id 的一部分拼文件名这些字符在文件系统里有特殊含义。比如包含/的时候工具会认为自己要写到子目录里而子目录根本不存在于是写入失败。解决在-w目录里看到乱码文件时先用.sip文件里的完整 call-id 对照确认哪些文件被异常命名。旧版本常量里没有自动清洗逻辑最省事的做法是在批量拆包后执行一个统一重命名脚本把所有文件名里的危险字符替换成下划线。这个坑出现概率不高一旦出现就是批量问题所以我的处理脚本里固定先跑一遍清理。5.5 拆包后媒体丢了一部分统计丢包率虚高现象拿拆出来的 pcap 文件做 RTP 丢包率分析发现丢包率异常高但原始混合包数据看起来一切正常。原因这是我在一个视频通话排查里遇到的视频通话有多路 RTP 流但 pcapsipdump 按 call-id 聚合文件时把音频和视频按同一会话范围写入而视频流如果有独立的 RTCP 间隔策略超时后工具提前关闭文件后到的视频包就“丢”了实际上是没写进当前文件。这种丢包是工具层面的时间窗口问题不是网络丢包。解决分析丢包率时不要把其中一个 pcap 文件的媒体包数当成全量先确认该通话实际有几路 RTP 流再看文件时间范围是否完整覆盖。如果需要精确的媒体质量分析优先用-m 120拉大关闭窗口或者直接回到原始 pcap 包按端口做 RTP 统计。从那以后我只要做丢包率分析都会先把拆包文件的时间跨度打出来看一眼确认文件确实是完整的通话范围才下结论。6. 进阶技巧批量拆完后用 5 行脚本把异常通话挑出来拆包文件一多一个个用 Wireshark 打开看效率太低。我的固定操作是拆包结束后先跑一个 bash 循环把每个 pcap 的 RTP 包数、时间跨度、丢包率指标批量拉出来数值异常的直接列入排查清单最后再针对那一路打开 Wireshark 细看。for f in /tmp/split_output/*.pcap; do cnt$(tshark -r $f -Y rtp 2/dev/null | wc -l) pkt$(capinfos $f 2/dev/null | awk -F: /Number of packets/{gsub(/ /,,$2);print $2}) echo $f RTP$cnt PKT$pkt done | awk $2 ~ /RTP0/ {print NO RTP: $1}逻辑说明循环体里对每个拆包文件分别统计 RTP 包数和总包数最后一行的awk把 RTP 包数为 0 的文件单独拎出来打印。这类文件通常意味着只有信令没有媒体优先级最高最先排查。参数说明tshark -Y rtp如果碰到损坏的文件会报错2/dev/null把报错吞掉不影响循环awk -F: /Number of packets/里的字段分隔符是冒号因为capinfos的输出格式是Number of packets: 1234。做完这层筛选我还会对 RTP 包数最多的几个峰值文件再做一次时延分布检查用tshark的-T fields把 RTP 时间戳导出来看有没有乱序跳跃。一般到这步问题基本都能定位到具体某一路通话。某次客户投诉会议系统“声音时断时续”我远程跑不了抓包现场同事按我脚本录了一段混合包我回公司后拆完靠上面这个循环在五分钟内挑出那一路 RTP 包数量异常的 pcap再结合.sip文件里的 SDP 和重传记录确认是对端网关的 RTP 端口在通话中途被防火墙改写了端口映射导致后半段媒体走了错路。从那以后我每次拆完包都强制走一遍这个批量筛选流程确认没有异常文件才继续做深度分析希望帮到你。本文还有配套的精品资源点击获取