简介：面向网络协议分析与VoIP运维人员的开源SIP抓包工具源码包，基于libpcap实现，可在指定网卡上监听并自动识别SIP/RTP会话，将每一路通话单独保存为命名规范的.pcap文件，便于后续用tcpdump、Wireshark等工具打开分析，适合排查SIP信令交互、RTP媒体流质量及呼叫建立异常等场景。压缩包共16个文件，约15KB，以cpp与h源码构成核心抓包与会话表逻辑，另含Makefile及makefile-helpers编译辅助脚本、check_libpcap.c依赖检测程序，并附带RedHat、Debian、Solaris等平台的init脚本、sysconfig配置样例与spec打包描述，以及LICENSE、ChangeLog和两份README说明文档，跨平台部署信息较为完整。已有300人学习下载，读者可据此了解基于libpcap的会话分流实现思路，参考其按会话命名落盘的目录组织方式，并借助各平台启动脚本快速完成编译与运行验证。
1. 抓包文件里翻不出 SIP 信令？先把这个 0.2 版的小工具跑起来
排查一通电话打不通，最难受的不是没日志，而是日志里全是 RTP 的 UDP 流，SIP 信令却像蒸发了一样。Wireshark 打开一个几百兆的 pcap，过滤sip只剩零星几条，剩下的全是媒体包和无关流量，翻到怀疑人生。pcapsipdump-0.2.tar.gz就是冲着这个场景来的：它从 pcap 里把 SIP 会话一条条拆出来，按会话落成独立的抓包文件，信令和对应的 RTP 归到一起，后面用 Wireshark 单开一个会话文件看，比在大文件里大海捞针舒服得多。这个包是 0.2 版源码压缩包，C 写的命令行工具，依赖 libpcap，编译出来就一个可执行文件，适合做 SIP 信令分析、呼叫问题定位、批量会话归档的从业者。下面按「它到底怎么切会话 → 编译和参数怎么配 → 哪些地方会翻车」的顺序拆。
2. 会话切分的底层逻辑：它凭什么把一条呼叫拎出来
2.1 从 SIP 头字段到会话键的映射
这个工具的核心不是「过滤 SIP 包」，而是「按会话聚合」。它读 pcap 的每个包，识别 UDP/TCP 上的 SIP 报文，然后从报文里抽 Call-ID、From tag、To tag 这几个字段，拼成一个会话标识。同一个 Call-ID 下的 INVITE、100 Trying、180 Ringing、200 OK、ACK、BYE 会被归到同一个会话文件里；如果这个会话协商出了 SDP，里面描述的 RTP 五元组也会被登记下来，后续匹配到的 RTP 包一并写进同一个文件。
理解这一点很关键：它做的是「会话级重组」，不是「协议级解码」。所以它不会帮你把 SIP 消息渲染成流程图，也不会解析 SDP 里的编解码参数，它只负责把属于同一次呼叫的包挑出来、放到一起。真正的解析还是交给 Wireshark。这个分工决定了它的适用边界——批量归档、快速定位某一路呼叫，它很顺手；要做信令流程统计、字段级报表，得在它输出的会话文件上再跑别的脚本。
会话键的拼法有个细节值得注意：Call-ID 是主键，但同一 Call-ID 下可能存在多个 dialog（比如 reinvite 或者 fork 出来的分支），这时候 From tag 和 To tag 就起作用了。常见做法是用 Call-ID 加两个 tag 的组合来区分 dialog，工具在 0.2 版里对这块的处理相对朴素，遇到复杂的 fork 场景可能出现会话被合并或者拆得过细的情况，后面避坑章节会具体说。
2.2 为什么用 libpcap 而不是自己解析链路层
它依赖 libpcap 做抓包读取，这是很务实的选择。pcap 文件可能是以太网链路、可能是 Linux cooked capture（抓 any 接口时常见）、也可能是带 VLAN tag 的，链路层头部长度不固定。libpcap 的pcap_open_offline加pcap_next_ex把链路层解析这层脏活接过去了，工具只需要在拿到的包里按偏移找 IP 头、再找 UDP/TCP 头。自己写链路层解析，光是 VLAN 双层 tag 和 SLL 头就能让人调半天。
代价是它对非 IP 流量、IP 分片、以及某些隧道封装（比如 IP-in-IP）处理不了。如果你的抓包点在内核隧道出口，包里套着 GRE 或者 VXLAN，工具按固定偏移找传输层头就会错位，SIP 一条都识别不出来。这不是 bug，是设计取舍——它假设输入是「常规的、未封装的 IP 承载 SIP」。抓包位置选对了，这个假设就成立；选在隧道口，就得先解封装再喂给它。
2.3 输出文件的命名与目录组织
默认行为是把每个会话写成一个独立的 pcap 文件，文件名通常带会话序号或者 Call-ID 片段。这一点在实际使用中影响很大：一次大批量处理可能产出成千上万个文件，如果命名里不带可读的 Call-ID，事后找某一路呼叫还是得靠 grep。我的习惯是编译后先跑一个小样本，看它实际生成的文件名格式，再决定要不要在外部套一层重命名脚本，把 Call-ID 或者主叫号码拼进文件名。
输出目录也要提前规划。它不会自动按日期或者分机号建子目录，所有会话文件平铺在一个目录里。几千个文件平铺，ls都要卡一下，更别说用文件管理器翻了。常见做法是外层用 shell 按抓包时间段或者输入文件名建目录，工具的输出目录指到对应子目录里，归档结构自己控。
3. 编译与参数配置：从 tar.gz 到能跑的命令行
3.1 依赖检查与编译步骤
拿到pcapsipdump-0.2.tar.gz之后，先确认系统里有 libpcap 的开发头文件。只装运行时库不够，编译要pcap.h。Debian/Ubuntu 系装libpcap-dev，RHEL/CentOS 系装libpcap-devel。没有这一步，./configure或者直接make会在第一个#include <pcap.h>处报错。
# 解包并进入源码目录 tar -xzf pcapsipdump-0.2.tar.gz cd pcapsipdump-0.2 # 确认 libpcap 开发头文件在位（能输出路径说明装好了） ls /usr/include/pcap.h /usr/include/pcap/pcap.h 2>/dev/null # 老式 autotools 项目，先看有没有 configure ls configure Makefile 2>/dev/null # 有 configure 就走标准流程 ./configure && make # 没有 configure 的裸 Makefile 项目，直接 make，必要时指定头文件路径 make CFLAGS="-I/usr/include" LDFLAGS="-lpcap"编译逻辑说明：这个年代的 C 小工具，构建系统可能是 autotools，也可能就是一个手写 Makefile。先ls看有没有configure，有就走./configure && make，它会自己探测 libpcap 的位置；没有就直接make，如果报找不到pcap.h，用CFLAGS把 include 路径补上，链接阶段缺符号就用LDFLAGS补-lpcap。参数上，-I是头文件搜索路径，-lpcap是链接时找libpcap.so，这两个是最常需要手动干预的地方。
编译产物一般就是当前目录下的pcapsipdump可执行文件。先别急着上大文件，用./pcapsipdump -h或者不带参数跑一下，看它打印的用法，确认参数名和你的预期一致——不同小版本的参数拼写可能有出入，以它自己打印的为准。
3.2 核心参数逐个说清
这类工具的参数不多，但每个都直接影响输出结果，逐个过一遍比照抄命令有用。
| 参数 | 作用 | 常见取值与注意点 |
|---|---|---|
-r <file> | 指定输入 pcap 文件 | 只读离线文件时必填，路径带空格要引号 |
-i <iface> | 从网卡实时抓 | 需要相应权限，生产环境慎用实时模式 |
-w <dir>或输出目录参数 | 指定会话文件输出位置 | 目录要提前建好，工具一般不自动创建多级目录 |
-f <bpf> | 附加 BPF 过滤表达式 | 如udp port 5060，能大幅减少无关包 |
-v/ 调试开关 | 打印处理过程信息 | 排查「为什么没切出会话」时先开它 |
参数的实际拼写以-h输出为准，上表是按这类工具的通用约定整理的。重点说两个容易配错的：
第一个是 BPF 过滤。很多人以为工具内部已经只处理 SIP 了，就不加-f。实际上它要读遍整个 pcap 才能判断哪些是 SIP，大文件下这是纯浪费。加-f "udp port 5060 or tcp port 5060"能把输入量砍掉一大截，处理速度差别很明显。但要注意，如果你的 SIP 跑在非标准端口上，这个过滤会把信令也滤掉，得按实际端口改。
第二个是输出目录。工具的写文件逻辑通常是「打开就写」，目录不存在时行为可能是静默失败或者直接报错退出，取决于实现。稳妥做法是跑之前mkdir -p建好，跑完ls | wc -l数一下文件数，和预期会话数对得上再往下走。
3.3 一个可复现的最小跑通流程
拿一个已知包含 SIP 呼叫的 pcap 做验证，流程固定成四步：建目录、跑工具、数文件、抽一个会话用 Wireshark 验证。
# 1. 准备输入与输出目录 mkdir -p ./out_sessions INPUT=./sample_call.pcap # 2. 带 BPF 过滤跑一遍，开调试输出观察处理过程 ./pcapsipdump -r "$INPUT" -f "udp port 5060" -w ./out_sessions -v 2>&1 | tee run.log # 3. 数一下切出多少会话文件 ls ./out_sessions | wc -l # 4. 抽第一个会话文件，确认里面有 INVITE 和对应 RTP FIRST=$(ls ./out_sessions | head -n 1) tcpdump -nn -r "./out_sessions/$FIRST" 2>/dev/null | head -n 20逻辑说明：第 2 步把标准错误也重定向进日志，是因为这类工具的调试信息多半走 stderr，不重定向的话终端一滚就没了，出问题没法回看。-v打开后能看到它识别到多少 SIP 包、切出多少会话，这个数字和ls | wc -l对不上就说明有会话在写文件阶段失败了。第 4 步用tcpdump -nn快速看会话文件内容，-nn关掉名字解析，输出干净，能直接看到 SIP 方法名和 RTP 的端口对。如果第一个文件里只有 RTP 没有 INVITE，说明会话切分把信令和媒体分到了不同文件，这就是要进避坑章节的问题。
提示：验证阶段一定用小样本。几百兆的 pcap 跑一遍可能几分钟，参数配错了重跑的时间成本很高，先用几十兆、包含两三个呼叫的文件把参数调对。
4. 避坑与排查：五个真实会卡住人的地方
4.1 跑完一个会话文件都没有
现象：命令正常退出，输出目录空的，日志里也没明显报错。
原因：最常见的是 BPF 过滤写错端口，把 SIP 全滤掉了；其次是抓包点不对，pcap 里根本没有 SIP 流量，只有 RTP；还有一种情况是 SIP 跑在 TCP 上而过滤只写了udp port 5060。
解决：先去掉-f参数裸跑一遍，看能不能切出会话。能切出来说明是过滤表达式的问题，按实际端口和传输层协议改。裸跑还是空，就用tcpdump -nn -r input.pcap | grep -i -E "invite|register|bye"确认输入文件里到底有没有 SIP 信令，没有的话问题在抓包环节，不在工具。
4.2 信令和 RTP 被拆到两个文件里
现象：一个会话文件里只有 SIP，另一个只有 RTP，两边对不上。
原因：SDP 里的媒体地址和端口没被正确登记，或者 RTP 的实际五元组和 SDP 协商的不一致（NAT 环境下很常见，SDP 里写的是私网地址，实际 RTP 从公网地址来）。
解决：这是 NAT 场景的典型问题，工具按 SDP 里的地址匹配 RTP，NAT 一转换就匹配不上。处理办法是在抓包侧尽量选在 NAT 之后、能看到真实媒体流的位置；或者在输出后按时间窗口和端口范围做二次关联。指望工具自己穿透 NAT 做关联不现实，它没有 NAT 表信息。
4.3 同一路呼叫被切成好几个文件
现象：一次呼叫的 INVITE、200 OK、BYE 分散在多个会话文件里。
原因：会话键依赖 Call-ID 加 tag 组合，某些设备生成的 tag 不规范，或者 reinvite 过程中 tag 变化，导致工具认为是新会话。fork 场景下同一 Call-ID 有多个分支，也会被拆开。
解决：先确认是不是 fork 或者 reinvite 导致的正常拆分，如果是，按 Call-ID 在输出目录里 grep 文件名或者内容，把相关文件归组看。如果 tag 本身不规范，工具层面改不了，只能在输出后写脚本按 Call-ID 重新合并。这也是为什么前面强调输出文件名最好带 Call-ID——不带的话这一步只能靠包内容 grep，慢很多。
4.4 大文件跑到一半内存涨上去或者变慢
现象：处理几百兆以上的 pcap 时，进程内存持续上涨，速度越来越慢。
原因：工具要在内存里维护会话表，会话数越多，表越大。如果输入里 SIP 会话极其密集（比如高并发呼叫场景），会话表膨胀是必然的。另外输出文件句柄如果没及时关闭，文件描述符也会耗尽。
解决：把大 pcap 按时间切片，用editcap -c或者按时间范围拆成多个小文件分批跑，每批跑完清空输出目录再下一批。这样内存峰值可控，出问题也好定位是哪一段。切片大小按机器内存定，一般单批控制在几千个会话以内比较稳。
4.5 编译过了但运行时报找不到库
现象：./pcapsipdump报error while loading shared libraries: libpcap.so.x。
原因：编译时链接到了某个版本的 libpcap，运行环境里没有对应版本的运行时库，或者库在非标准路径。
解决：ldd ./pcapsipdump | grep pcap看它找的是哪个 soname，确认系统里有没有。缺就装对应的运行时包；库在非标准路径就用LD_LIBRARY_PATH临时指过去，或者把它加进系统库搜索路径。这个坑在容器里跑最容易遇到——编译镜像和运行镜像不是同一个，运行时库没带过去。
5. 批量归档与二次校验：把工具用成流水线的一环
单次跑通只是起点，实际工作里更常见的是「每天一批抓包，按呼叫归档，出问题时能快速回查」。这时候工具本身只是流水线的一个环节，前后得配上切片、命名、校验。
我的做法是外层套一个脚本，输入是一个目录下的所有 pcap，输出是按日期和输入文件名分层的会话目录，每个会话文件重命名时把 Call-ID 拼进去。重命名这一步不能省——工具默认的文件名对回查不友好，带上 Call-ID 之后，拿到用户报障的 Call-ID 直接find就能定位到文件，不用打开 Wireshark 一个个翻。
#!/bin/bash # 批量处理目录下所有 pcap，按输入文件名建子目录，会话文件重命名带 Call-ID set -u IN_DIR="./pcaps" OUT_ROOT="./sessions" mkdir -p "$OUT_ROOT" for f in "$IN_DIR"/*.pcap; do base=$(basename "$f" .pcap) outdir="$OUT_ROOT/$base" mkdir -p "$outdir" # 单文件处理，BPF 按实际信令端口调整 ./pcapsipdump -r "$f" -f "udp port 5060" -w "$outdir" >/dev/null 2>&1 # 从每个会话文件里抽 Call-ID，拼进新文件名 for s in "$outdir"/*; do [ -f "$s" ] || continue cid=$(tcpdump -nn -A -r "$s" 2>/dev/null \ | grep -i -m1 "Call-ID:" \ | sed 's/.*Call-ID:[[:space:]]*//; s/\r//') if [ -n "${cid:-}" ]; then safe_cid=$(echo "$cid" | tr -c 'A-Za-z0-9._-' '_') mv "$s" "$outdir/${safe_cid}.pcap" fi done done逻辑说明：外层循环按输入文件分目录，保证不同批次的会话不混在一起。内层用tcpdump -A把会话文件按 ASCII 打印，grep -m1只取第一条 Call-ID，sed去掉前缀和回车符。tr -c把 Call-ID 里可能出现的特殊字符（比如@、:）替换成下划线，避免文件名非法。参数上，-m1是性能关键——一个会话文件里 Call-ID 会出现很多次，取第一条就够，不加这个在大文件上会慢很多。
跑完之后做一次校验，确认没有空文件、没有重命名冲突：
# 找出 0 字节的会话文件（切分失败的信号） find ./sessions -type f -size 0 -print # 检查重命名后是否有同名覆盖（同一 Call-ID 多 dialog 时会撞名） find ./sessions -type f -name "*.pcap" -printf "%f\n" | sort | uniq -d第一条命令找空文件，空文件说明那个会话在写阶段就失败了，通常是输入包不完整或者权限问题。第二条找重名，同一 Call-ID 下有多个 dialog 时，重命名会撞名，后一个覆盖前一个，这是静默丢数据，必须查。撞名的话在文件名里再加一个序号或者 tag 后缀区分。
这套流程跑顺之后，回查一个呼叫的路径就变成：拿到 Call-ID →find ./sessions -name "*${CID}*"→ Wireshark 打开对应文件。比在大 pcap 里过滤快一个数量级，尤其是抓包保留周期长、历史文件多的时候。
从那以后我每次上批量归档，都强制先拿两三个已知呼叫的小样本把「切分 → 重命名 → 校验」整条链路走一遍，确认文件数、Call-ID、RTP 关联都对得上，再放开跑全量。这个习惯救过我好几次——有一次 BPF 端口写错，小样本阶段就发现了，要是直接上全量，几百个文件全是空的，重跑的时间够喝两杯咖啡。希望帮到你。
本文还有配套的精品资源，点击获取
