pcapsipdump按呼叫拆分SIP抓包：编译、参数调优与排障实战

简介：pcapsipdump 是一款基于 libpcap 的开源 SIP 抓包工具，面向网络运维、VoIP 排障与安全分析人员。它监听指定网卡，将 SIP 信令与 RTP 媒体流按会话拆分，分别保存为独立命名的 .pcap 文件，可直接用 tcpdump、Wireshark 等工具打开分析，适合排查呼叫建立失败、媒体不通、信令异常等场景，也便于对 VoIP 流量做取证与回溯。资源包共 16 个文件，约 15KB，以 cpp 与 h 源码为核心，辅以 Makefile、makefile-helpers 等构建脚本，并附带 RedHat、Debian、Solaris 的 init 与 sysconfig 配置、spec 打包文件、LICENSE、ChangeLog 及多份 README 说明，覆盖编译、安装与跨平台部署所需材料。目前已有 298 人学习下载。借助该工具，读者可快速搭建 SIP 抓包环境，按会话粒度留存信令与媒体数据，结合 Wireshark 还原完整呼叫流程，定位问题环节，并参考各平台配置与打包脚本完成实际部署。

1. 从 pcapsipdump-0.2.tar.gz 说起：把 SIP 通话抓成可回放的单流 pcap

线上电话系统出问题，最让人头疼的不是复现，而是取证。用户说“刚才那通电话断断续续”，等你登上服务器，通话早结束了，tcpdump 抓下来的是一坨混着几十路并发呼叫的巨型 pcap，Wireshark 打开卡半天，还得靠肉眼从 SIP 信令里挑出问题那一路。pcapsipdump 就是冲着这个痛点来的：它监听网卡上的 SIP 流量，按每一通呼叫（Call-ID 维度）拆成独立的 pcap 文件，一通电话一个文件，事后直接拿单个文件回放、听 RTP、看信令时序。标题里的 pcapsipdump-0.2.tar.gz 是它的源码包，0.2 是早期版本号，体积很小，编译依赖也少，适合在话务服务器上常驻跑。这篇笔记面向正在被 SIP 排障折磨的运维和 VoIP 工程师，从编译、参数、抓包目录结构一路讲到丢包排查，让你能照着在自己的环境里跑起来，并且知道哪些参数不能乱动。

2. pcapsipdump 的工作方式与编译落地：它凭什么按呼叫拆流

2.1 它到底在抓什么：SIP 信令 + RTP 媒体一起落盘

pcapsipdump 不是简单的端口过滤器。它用 libpcap 抓包，但核心逻辑是解析 SIP 报文里的 Call-ID、From tag、To tag，把属于同一通呼叫的所有包归到一个会话对象里。默认情况下它同时抓 SIP（通常 5060）和该呼叫协商出来的 RTP 端口，所以一个输出文件里既有 INVITE/200 OK/ACK/BYE 这些信令，也有双向 RTP 音频流。这一点很关键：很多排障场景光看信令不够，你得把 RTP 丢包、抖动和信令里的 SDP 对起来看，pcapsipdump 把两者放在同一个文件里，省去了手工关联的功夫。

它的输出目录结构是<输出目录>/<年>/<月>/<日>/<Call-ID>_<时间戳>.pcap这种形式（不同版本细节略有差异，0.2 版以实际编译结果为准）。这意味着你挂一个采集节点跑一周，目录里就是按天分好的一堆单通话文件，找哪通电话直接按 Call-ID 或时间筛，不用再开巨型 pcap。

2.2 编译 pcapsipdump-0.2：三条命令和两个依赖

0.2 这个版本没有花哨的构建系统，典型做法是解包后直接 make。依赖主要是 libpcap 开发包，部分系统还需要 libpcap 的头文件路径。下面是我在 Debian/Ubuntu 系上的常规操作：

# 解包 tar -zxvf pcapsipdump-0.2.tar.gz cd pcapsipdump-0.2 # 安装编译依赖（libpcap 开发头文件） sudo apt-get install -y libpcap-dev build-essential # 编译，0.2 版通常直接 make 即可 make # 编译产物一般在当前目录，确认可执行文件生成 ls -l pcapsipdump

逻辑说明：tar -zxvf解出源码；libpcap-dev提供pcap.h和链接库，缺了它 make 会在#include <pcap.h>处报错；build-essential提供 gcc 和 make。参数上没什么可调的，0.2 版没有 configure 脚本，如果 make 报找不到 pcap 头文件，检查/usr/include/pcap.h是否存在，或者用-I手动指定路径。

编译成功后先别急着上生产，用-h看一眼它认哪些参数：

./pcapsipdump -h

不同发行版编译出来的参数列表可能略有出入，但核心几个是固定的：-i指定网卡，-d指定输出目录，-v提高日志级别，-p指定 SIP 端口。先把这几个记住，下一节展开。

2.3 最小可跑命令：指定网卡和输出目录

假设你的 SIP 服务器网卡是 eth0，想把抓到的通话存到/data/sippcap：

sudo mkdir -p /data/sippcap sudo ./pcapsipdump -i eth0 -d /data/sippcap -v

逻辑说明：-i eth0让 libpcap 在该网卡上进入混杂模式抓包；-d /data/sippcap是输出根目录，程序会自动在里面按日期建子目录；-v打开详细日志，启动时会打印监听的接口和端口，方便确认它真的在工作。参数上要注意，-d目录必须存在且当前用户有写权限，否则程序可能静默失败或者只报一行错就退出，这是新手最容易翻车的地方。

跑起来之后，用一台测试话机打一通电话，然后去/data/sippcap下看有没有生成 pcap 文件。如果目录是空的，先看-v日志里有没有 “listening on” 之类的字样，再确认 SIP 信令是否真的经过这块网卡——镜像口没配好、或者 SIP 走的是另一张网卡，都会导致抓不到。

3. 参数调优与抓包目录管理：让采集节点稳定跑一周

3.1 必调的四个参数：端口、快照长度、缓冲和权限

pcapsipdump 的参数不多，但有几个直接决定你能不能抓到、抓全。下面这张表是我在实际部署里会逐项确认的：

快照长度（snaplen）在 0.2 版里通常走默认，抓全包。如果你的 RTP 流量很大，想省磁盘，可以在编译前改源码里的 snaplen 常量，但我不建议——截断的 RTP 没法做音频回放，排障价值大打折扣。磁盘换真相，这笔账划算。

权限方面，抓包需要 root 或者CAP_NET_RAW能力。生产上我一般用 systemd 配AmbientCapabilities=CAP_NET_RAW，避免整个进程跑在 root 下。0.2 版本身没有降权逻辑，这点要自己在外层兜住。

3.2 输出目录长什么样：按天分目录，按 Call-ID 命名

跑起来之后，目录结构大致是这样：

/data/sippcap/ └── 2024/ └── 06/ └── 18/ ├── a1b2c3d4e5f6@10.0.0.1_1718700000.pcap ├── f6e5d4c3b2a1@10.0.0.2_1718700123.pcap └── ...

每个文件名里的 Call-ID 就是 SIP 信令里的那个唯一标识，后面跟的是会话建立时间戳。找某通电话时，先从 CDR 或者日志里拿到 Call-ID，再find一下：

find /data/sippcap -name "*a1b2c3d4e5f6*"

逻辑说明：-name用通配符匹配 Call-ID 片段，因为文件名里还带了时间戳，精确匹配反而容易漏。找到文件后直接wireshark 文件名.pcap打开，里面就是这一通呼叫的完整信令加媒体，Telephony 菜单还能直接播放 RTP 流。

3.3 磁盘和清理：别让采集节点自己把自己撑死

单通话 pcap 文件不大，一通几分钟的电话通常几百 KB 到几 MB，但高话务量下一天几千通，累积起来很可观。我的做法是配一个定时清理，保留最近 N 天：

# 删除 7 天前的抓包，按目录修改时间判断 find /data/sippcap -type f -name "*.pcap" -mtime +7 -delete

逻辑说明：-mtime +7表示修改时间在 7 天前，-delete直接删除。参数上要注意，这里按文件修改时间算，pcapsipdump 写文件是会话结束时落盘，所以基本等于通话结束时间，够用。如果你的合规要求必须留更久，就把天数调大，同时监控磁盘使用率，别等写满了才发现。

提示：清理脚本和 pcapsipdump 不要用同一个用户跑，避免权限交叉；清理用普通用户加 sudo 限定到具体目录，比 root 裸跑安全。

4. 避坑与排查：抓不到、拆不开、文件打不开的常见原因

4.1 目录一直是空的：先查镜像口和 SIP 端口

现象：pcapsipdump 跑起来了，日志也显示 listening，但打了几通电话，输出目录里一个文件都没有。

原因：最常见的是抓包网卡上没有 SIP 信令。要么镜像口没配好，要么 SIP 走的是另一张网卡，要么你的 SIP 端口不是 5060 而程序还在默认端口上等。

解决：先用 tcpdump 在目标网卡上确认能看到 SIP 包：tcpdump -i eth0 -n port 5060 -c 10。如果这里就没包，问题在网络层，跟 pcapsipdump 无关。如果有包但 pcapsipdump 不生成文件，检查-p参数是否和实际 SIP 端口一致，非标端口必须显式指定。

4.2 文件生成了但只有信令没有 RTP

现象：pcap 文件能打开，SIP 信令完整，但 RTP 流是空的或者只有单向。

原因：RTP 走的是动态协商端口，pcapsipdump 靠解析 SDP 里的 m=audio 行来跟进。如果 SDP 被加密（比如某些 SRTP 场景）或者协商过程不完整（比如只抓到单向信令），它就关联不上 RTP。

解决：确认抓包点能看到双向信令，INVITE 和 200 OK 都要抓到，SDP 才完整。如果是 SRTP，pcapsipdump 0.2 版本身不解密，抓到的 RTP 是密文，这是能力边界，不是 bug。这种场景要么在媒体网关侧抓，要么换支持解密的方案。

4.3 高并发下丢包：libpcap 缓冲不够

现象：话务高峰时，抓到的通话文件明显变少，或者文件里信令有缺口。

原因：libpcap 默认的抓包缓冲在高 PPS 下容易溢出，内核把包丢了，用户态根本看不到。

解决：0.2 版没有暴露缓冲参数，常规做法是在编译前调整源码里的pcap_open_live调用，把缓冲调大，或者用pcap_set_buffer_size（如果版本支持）。另一个思路是减小抓包范围，只抓 SIP 端口，RTP 交给专门的媒体抓包工具，降低单进程压力。这块没有银弹，得根据实际 PPS 试。

4.4 文件在 Wireshark 里打不开或提示损坏

现象：pcap 文件存在，但 Wireshark 报 “The file isn't a capture file in a format Wireshark understands”。

原因：多半是 pcapsipdump 进程在写文件时被 kill 或者磁盘写满，文件头没写完，留下半截文件。

解决：先看进程是不是异常退出，dmesg里有没有 OOM 记录。磁盘满导致的写失败最隐蔽，配一个磁盘水位告警。已经损坏的文件基本救不回来，这是没有后悔药的部分，所以磁盘监控必须做在前面。

5. 进阶用法：把单通话 pcap 接进自动化排障流水线

单通话 pcap 真正的价值不在手工打开看，而在于它能被脚本批量处理。我现在的习惯是，pcapsipdump 只负责落盘，后面接一个定时任务，用 tshark 把每个新文件的 SIP 响应码和 RTP 丢包统计抽出来，写进一张排障表。这样用户报障时，我先查表定位到具体 Call-ID，再打开对应 pcap 精看，效率比翻巨型抓包高一个量级。

下面这个脚本片段是我常用的抽取逻辑：

#!/bin/bash # 遍历当天新生成的 pcap，抽取 SIP 状态码和 RTP 包数 DIR="/data/sippcap/$(date +%Y/%m/%d)" for f in "$DIR"/*.pcap; do # 统计 SIP 响应码，看有没有 4xx/5xx/6xx sip_status=$(tshark -r "$f" -Y "sip.Status-Code" -T fields -e sip.Status-Code 2>/dev/null | sort -u | tr '\n' ',') # 统计 RTP 包数，粗略反映媒体是否正常 rtp_count=$(tshark -r "$f" -Y "rtp" -T fields -e frame.number 2>/dev/null | wc -l) echo "$(basename "$f"),$sip_status,$rtp_count" done

逻辑说明：-Y是 tshark 的显示过滤器，sip.Status-Code抓所有 SIP 响应码，sort -u去重后拼成一行，一眼能看出这通电话有没有被拒。rtp过滤器统计媒体包数量，如果 RTP 包数为 0 而信令正常，基本就是单向音频或者媒体没通。参数上，-T fields -e指定输出字段，比默认的详细输出好解析。这个脚本跑在抓包节点上，输出重定向到一个 CSV，再接 Grafana 或者简单的告警规则都行。

再进一步，可以把 Call-ID 和你的 CDR 系统做关联。CDR 里一般有主被叫、通话时长、挂断原因，把 Call-ID 作为 join key，就能实现“用户报障 → 查 CDR → 拿 Call-ID → 定位 pcap → 自动出信令摘要”这条链路。pcapsipdump 在这里扮演的是最底层的取证层，它不负责分析，但提供了分析所需的最干净的数据单元。

最后说个我自己的习惯：每次上线新的 SIP 设备或者改配置，我都会让 pcapsipdump 在测试环境跑满 24 小时，然后随机抽 20 通电话的 pcap 用 tshark 过一遍状态码和 RTP 包数。这个动作帮我提前发现过好几次单向音频和信令超时的问题，比等用户投诉再查省事得多。抓包这件事，宁可平时多存一点，也别等出事时两手空空。希望帮到你。

本文还有配套的精品资源，点击获取