简介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 抓下来的是一坨混着几十路并发呼叫的巨型 pcapWireshark 打开卡半天还得靠肉眼从 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/sippcapsudo 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 的参数不多但有几个直接决定你能不能抓到、抓全。下面这张表是我在实际部署里会逐项确认的参数作用建议值不调的后果-i指定抓包网卡承载 SIP/RTP 的网卡抓错网卡目录一直空-pSIP 信令端口5060或你的实际端口非标端口信令解析不到拆不出会话-d输出根目录独立数据盘如 /data/sippcap写系统盘跑几天磁盘满-v日志级别首次部署开稳定后可关出问题没有日志可查快照长度snaplen在 0.2 版里通常走默认抓全包。如果你的 RTP 流量很大想省磁盘可以在编译前改源码里的 snaplen 常量但我不建议——截断的 RTP 没法做音频回放排障价值大打折扣。磁盘换真相这笔账划算。权限方面抓包需要 root 或者CAP_NET_RAW能力。生产上我一般用 systemd 配AmbientCapabilitiesCAP_NET_RAW避免整个进程跑在 root 下。0.2 版本身没有降权逻辑这点要自己在外层兜住。3.2 输出目录长什么样按天分目录按 Call-ID 命名跑起来之后目录结构大致是这样/data/sippcap/ └── 2024/ └── 06/ └── 18/ ├── a1b2c3d4e5f610.0.0.1_1718700000.pcap ├── f6e5d4c3b2a110.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 里的 maudio 行来跟进。如果 SDP 被加密比如某些 SRTP 场景或者协商过程不完整比如只抓到单向信令它就关联不上 RTP。解决确认抓包点能看到双向信令INVITE 和 200 OK 都要抓到SDP 才完整。如果是 SRTPpcapsipdump 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 isnt 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 包数。这个动作帮我提前发现过好几次单向音频和信令超时的问题比等用户投诉再查省事得多。抓包这件事宁可平时多存一点也别等出事时两手空空。希望帮到你。本文还有配套的精品资源点击获取