简介pcapsipdump-0.2 是一款轻量级开源 SIP 协议网络嗅探工具基于 libpcap 实现专为网络协议分析、VoIP 故障排查及 SIP/RTP 会话研究设计适用于网络安全工程师、通信协议开发者及高校网络实验教学人员。资源包共16个文件涵盖核心功能代码2个C源文件、1个C校验文件、2个头文件、多平台适配配置Debian/Solaris/RedHat 初始化脚本与sysconfig模板、构建支持Makefile、spec规范、helper脚本及完整文档体系README系列、ChangeLog、LICENSE整体仅15KB结构紧凑、可读性强。已有298人学习下载适合快速部署至Linux环境进行SIP信令捕获与会话分离分析。用户可直接编译运行获得按会话自动切分、命名规范的独立.pcap文件兼容Wireshark/tcpreplay等主流分析工具同时通过源码可深入理解SIP状态机跟踪、RTP流识别与PCAP写入机制。1. pcapsipdump 是什么不是抓包工具而是 SIP 信令的“结构化翻译器”你手头有一堆.pcap文件Wireshark 打开后满屏是 TCP/UDP 流、十六进制载荷、乱序重传——但真正想看的是谁打了哪通电话主叫号是多少被叫是否振铃通话是否建立SIP 消息里藏了全部答案可手动翻包等于用显微镜数米粒。pcapsipdump-0.2.tar.gz就是这个场景下的“翻译器”它不抓包、不绘图、不建连接只做一件事——从原始 pcap 流中精准提取 SIP 协议交互按会话Call-ID聚类输出结构化文本日志。它把INVITE → 100 Trying → 180 Ringing → 200 OK → ACK这一整条信令链压缩成一行可 grep、可导入 Excel、可喂给 Python 脚本分析的纯文本记录。适合网络运维排查 VoIP 故障、安全团队分析 SIP 洪泛攻击特征、或教学实验中快速验证 SIP 状态机行为。它不依赖 GUI无图形界面命令行跑完即出结果内存占用低于 5MB连树莓派都能扛住——但别指望它解析 RTP 媒体流也别让它处理 TLS 加密的 SIP over TLSSIPS那是另一个世界的活。2. 编译与安装为什么必须自己编译而不是apt installpcapsipdump不在主流发行版的默认仓库中。Debian/Ubuntu 的apt search pcapsipdump返回空CentOS/RHEL 的dnf list pcapsipdump同样查无此物。这不是维护者偷懒而是项目定位决定的它极度轻量源码仅 3 个 C 文件依赖极简仅 libpcap且多年未大更新0.2 版本发布于 2014 年社区打包动力不足。强行用apt install或pip install只会导向错误包比如同名但功能完全不同的 Python 工具。必须从源码编译——这反而是优势你能确认二进制里没塞任何第三方 SDK所有逻辑透明可控。2.1 环境准备三步清掉常见编译拦路虎提示不要跳过libpcap-dev。只装libpcap运行时库.so会导致configure阶段报错pcap.h not found因为编译需要头文件.h和静态链接支持。# Ubuntu/Debian 系统 sudo apt update sudo apt install -y build-essential libpcap-dev # CentOS/RHEL 系统启用 PowerTools 或 CRB 仓库 sudo dnf groupinstall -y Development Tools sudo dnf install -y libpcap-develbuild-essential或Development Tools提供gcc,make,autoconf等基础构建链。libpcap-dev或libpcap-devel包含pcap.h头文件及开发用静态库pcapsipdump的configure脚本会检查它是否存在。若系统已装libpcap但没装-dev包./configure会卡在checking for pcap_open_live in -lpcap... no这是最常被忽略的坑。2.2 解压、配置、编译四行命令走完全流程# 1. 解压源码注意路径别解到 /tmp 下编译生成的 .o 文件可能被自动清理 tar -xzf pcapsipdump-0.2.tar.gz cd pcapsipdump-0.2 # 2. 运行 configure它会检测 libpcap 路径、C 编译器能力、并生成 Makefile ./configure # 3. 编译生成 pcapsipdump 可执行文件无后缀非 pcapsipdump.bin make # 4. 可选安装到系统路径若需全局调用否则直接用 ./pcapsipdump 即可 sudo make install./configure输出中必须看到checking for pcap_open_live in -lpcap... yes和configure: creating ./config.status否则编译必败。make过程极快通常 3 秒无警告即成功若出现error: PCAP_NETMASK_UNKNOWN undeclared说明libpcap-dev版本过低 1.0需升级系统或手动指定 pcap 路径见避坑章节。sudo make install默认将二进制复制到/usr/local/bin/你可用which pcapsipdump验证。不安装也完全可行后续命令统一用./pcapsipdump调用。2.3 验证安装用最小 pcap 文件测通第一行输出# 创建一个最简 SIP pcap用 tcpdump 抓 10 秒本地回环的 SIP 流需本机有 SIP 客户端发请求 sudo tcpdump -i lo -w test-sip.pcap -c 100 port 5060 # 运行 pcapsipdump 解析-s 参数指定 SIP 端口-n 不解析 DNS 名称加速 ./pcapsipdump -s 5060 -n test-sip.pcap预期输出类似2024-05-22 14:30:22.123456 | 127.0.0.1:5060 127.0.0.1:5061 | INVITE | sip:1001localhost | sip:1002localhost | Call-ID: abc123... | From: sip:1001localhost;tagxyz | To: sip:1002localhost这行输出证明libpcap 能读包、SIP 解析逻辑生效、时间戳与 IP 端口提取正确。若输出为空先检查test-sip.pcap是否真含 SIP 流Wireshark 打开后过滤sip确认若报错pcap_open_offline: test-sip.pcap: Permission denied说明文件权限不对chmod 644 test-sip.pcap。3. 核心用法从单文件解析到批量会话归档pcapsipdump的设计哲学是“一次只做一件事”所以它的参数不多但每个都直击要害。它不提供 Web UI不存数据库输出就是标准输出stdout或重定向到文件。这种极简换来的是稳定性和可管道化pipe能力——你可以把它嵌入 Bash 脚本、Logstash pipeline甚至用cron每小时解析新 pcap。3.1 基础解析-s、-n、-r三个参数定生死# 最常用组合指定 SIP 端口-s、跳过 DNS 反解-n、读取 pcap 文件-r ./pcapsipdump -s 5060 -n -r capture.pcap # 解析多个 pcap 文件注意-r 只接受单文件多文件需循环 for f in *.pcap; do echo $f ; ./pcapsipdump -s 5060 -n -r $f; done # 实时解析网卡流量-i 指定接口-w 写入临时 pcap-c 限制包数防撑爆磁盘 sudo ./pcapsipdump -s 5060 -n -i eth0 -w /tmp/live.pcap -c 500-s 5060强制 SIP 端口为 5060。关键点pcapsipdump不自动识别 SIP 端口它只扫描指定端口上的 UDP/TCP 流。若你的 SIP 走 5061TLS或私有端口如 6060必须显式指定否则漏掉全部会话。-n禁用 DNS 反向解析。不加此参数时它会对每个 IP 调用gethostbyaddr()若 DNS 服务器慢或不可达解析会卡住数秒甚至超时导致输出延迟或中断。生产环境务必加。-r读取离线 pcap 文件。这是最常用模式。注意它不支持.pcapng格式Wireshark 新默认若遇到pcap_open_offline: unknown file format错误用 Wireshark 导出为.pcapFile → Export Specified Packets → Format:libpcap。3.2 输出控制-o重定向与字段定制的隐秘开关pcapsipdump默认输出到终端但真实场景中你需要存档、去重、导入数据库。它的输出格式固定为竖线分隔|共 8 列时间戳、源IP:端口 目标IP:端口、方法、From URI、To URI、Call-ID、From tag、To tag。没有参数能增减字段但你可以用标准 Unix 工具二次加工# 1. 重定向到文件推荐用 -o比 shell 更可靠 ./pcapsipdump -s 5060 -n -r capture.pcap -o sip-log.txt # 2. 提取所有唯一 Call-ID排查重复注册 ./pcapsipdump -s 5060 -n -r capture.pcap | cut -d| -f6 | sort -u # 3. 统计各 SIP 方法出现次数看是否异常 INVITE 暴增 ./pcapsipdump -s 5060 -n -r capture.pcap | cut -d| -f3 | sort | uniq -c | sort -nr # 4. 过滤出失败呼叫含 4xx/5xx/6xx 响应行注意pcapsipdump 不解析响应码需 grep 响应行 ./pcapsipdump -s 5060 -n -r capture.pcap | grep -E SIP/2\.0 [456][0-9][0-9]-o sip-log.txt是官方推荐方式比 sip-log.txt更健壮尤其当输出含特殊字符时。字段顺序固定cut -d| -fX是最轻量的字段提取法。第 3 列-f3是 SIP 方法INVITE,ACK,BYE,REGISTER第 6 列-f6是Call-ID这是会话聚合的唯一键。注意pcapsipdump不输出 SIP 响应码如200 OK,404 Not Found它只输出请求行和响应行的起始部分如SIP/2.0 200 OK所以用grep SIP/2.0 [456]是捕获失败响应的唯一办法。3.3 批量处理Shell 脚本实现 pcap 目录自动化解析面对上百个 pcap 文件如每日按小时切片手动for循环易出错。写一个健壮脚本自动处理、去重、归档#!/bin/bash # save as: batch-parse.sh PCAP_DIR./pcaps OUTPUT_DIR./sip-logs PCAPSIPDUMP./pcapsipdump # 创建输出目录 mkdir -p $OUTPUT_DIR # 遍历所有 .pcap 文件 for pcap_file in $PCAP_DIR/*.pcap; do # 跳过不存在的 glob当目录为空时 [[ ! -f $pcap_file ]] continue # 生成日志文件名basename 去后缀 .log log_file$OUTPUT_DIR/$(basename $pcap_file .pcap).log echo Processing: $pcap_file - $log_file # 执行解析加超时防止卡死某些损坏 pcap 会让 pcapsipdump 挂起 timeout 30s $PCAPSIPDUMP -s 5060 -n -r $pcap_file -o $log_file 2/dev/null # 检查输出是否为空解析失败则 log 文件为空 if [[ ! -s $log_file ]]; then echo Warning: $log_file is empty. Check $pcap_file integrity. rm -f $log_file fi done echo Batch parsing completed.timeout 30s是血泪经验遇到 CRC 校验错误或截断的 pcappcapsipdump可能无限循环。30 秒超时后杀进程保证脚本不阻塞。2/dev/null屏蔽 stderr如pcap_open_offline错误避免干扰日志。错误信息可单独重定向2error.log。[[ ! -s $log_file ]]检查文件大小空文件意味着解析失败非 pcap 问题就是无 SIP 流及时清理避免误判。4. 避坑与常见问题排查五个让老手也皱眉的硬核陷阱pcapsipdump表面简单但底层依赖 libpcap 和 C 运行时在不同环境会触发隐蔽故障。以下是实测中踩过的 5 个典型坑每条都附带复现条件、根因和绕过方案。4.1 现象./configure报错checking for pcap_open_live in -lpcap... no原因系统装了libpcap.so运行库但缺失libpcap.a静态库或pcap.h头文件。configure脚本通过链接测试link test验证 libpcap 可用性找不到头文件则链接失败。解决安装-dev或-devel包Ubuntu/Debian 用libpcap-devCentOS/RHEL 用libpcap-devel。若已安装仍报错检查头文件路径find /usr -name pcap.h 2/dev/null若在/usr/include/pcap/pcap.h则需./configure CPPFLAGS-I/usr/include/pcap。4.2 现象编译时报错error: PCAP_NETMASK_UNKNOWN undeclared原因pcapsipdump-0.2源码中引用了较新 libpcap 的宏PCAP_NETMASK_UNKNOWN但你的系统 libpcap 版本太旧 1.0。该宏在 libpcap 1.0 中引入用于处理无法获取子网掩码的情况。解决升级 libpcap。Ubuntu 18.04 自带 ≥1.8可sudo apt install libpcap-dev强制更新若无法升级手动修改pcapsipdump.c第 123 行将PCAP_NETMASK_UNKNOWN替换为0这是一个安全的 fallback 值不影响核心功能。4.3 现象输出日志中 IP 显示为0.0.0.0或::端口为0原因pcapsipdump从 pcap 包中提取 IP/端口时依赖 libpcap 解析 IP 头。若 pcap 文件是用tcpdump -i any抓的混杂模式跨接口或使用了-P参数设置 snaplen 过小IP 头可能被截断导致解析失败。解决重新抓包确保snaplen足够。tcpdump -i eth0 -s 0 -w good.pcap port 5060-s 0表示完整抓包不截断。若必须用旧 pcap可用editcap -s 128 old.pcap new.pcap增大 snaplen 后再解析。4.4 现象同一 Call-ID 在输出中出现多次且时间戳相同原因pcapsipdump对每个 SIP 消息独立输出一行不合并会话。一个完整呼叫INVITE→200→ACK会输出 3 行Call-ID 相同。这不是 bug是设计如此。用户误以为“重复”是因为期望它像 Wireshark 的 “Follow SIP Stream” 那样聚合。解决用外部工具聚合。例如用awk按 Call-ID 分组./pcapsipdump -s 5060 -n -r cap.pcap | awk -F| {call[$6] call[$6] $0 \n} END {for (c in call) print --- Call-ID:, c, ---\n call[c]}4.5 现象解析结果中 From/To URI 为空显示为| |连续两个竖线原因SIP 消息的From:/To:头字段格式不规范。pcapsipdump使用简单字符串匹配strstr(buf, From:)若头字段换行如From:\r\n sip:userdomain或含多余空格匹配失败。解决此为解析器局限无完美修复。临时方案用tshark预处理提取标准格式 URItshark -r capture.pcap -Y sip.From or sip.To -T fields -e sip.From -e sip.To -E separator| -E quoted uri-raw.txt然后用脚本关联pcapsipdump的 Call-ID 和tshark的 URI。5. 进阶技巧用 Python 补全 pcapsipdump 的“盲区”pcapsipdump的强项是快、轻、准——但它不解析 SDP、不提取认证头、不判断呼叫状态成功/失败。这些“盲区”恰恰是 VoIP 分析的关键。我一般用 Python 写一个薄层包装器把pcapsipdump的输出作为输入补全语义。下面是一个实战脚本它接收pcapsipdump日志输出带状态标记的 CSV并导出失败呼叫的完整消息流。5.1 构建解析管道pcapsipdump → Python → 结构化 CSV#!/usr/bin/env python3 # save as: sip-analyze.py import sys import csv from datetime import datetime from collections import defaultdict def parse_pcapsipdump_line(line): 解析 pcapsipdump 一行输出返回字典 parts [p.strip() for p in line.strip().split(|)] if len(parts) 8: return None return { timestamp: parts[0], direction: parts[1], method: parts[2], from_uri: parts[3], to_uri: parts[4], call_id: parts[5], from_tag: parts[6], to_tag: parts[7] } def classify_call_status(messages): 根据消息序列判断呼叫状态 methods [m[method] for m in messages] if INVITE in methods and 200 OK in methods and ACK in methods: return success elif INVITE in methods and any(m.startswith(SIP/2.0 4) or m.startswith(SIP/2.0 5) or m.startswith(SIP/2.0 6) for m in methods): return failure else: return incomplete def main(): if len(sys.argv) ! 2: print(Usage: python sip-analyze.py pcapsipdump_log) sys.exit(1) # 按 Call-ID 聚合所有消息 calls defaultdict(list) with open(sys.argv[1], r) as f: for line in f: msg parse_pcapsipdump_line(line) if msg and msg[call_id]: calls[msg[call_id]].append(msg) # 准备 CSV 输出 with open(sip-report.csv, w, newline) as csvfile: fieldnames [call_id, start_time, end_time, status, from_user, to_user, message_count] writer csv.DictWriter(csvfile, fieldnamesfieldnames) writer.writeheader() for call_id, msgs in calls.items(): if not msgs: continue # 排序按时间戳升序pcapsipdump 输出已有序但保险起见 msgs.sort(keylambda x: x[timestamp]) status classify_call_status(msgs) start_time msgs[0][timestamp] end_time msgs[-1][timestamp] from_user msgs[0].get(from_uri, ).split()[0].replace(sip:, ) to_user msgs[0].get(to_uri, ).split()[0].replace(sip:, ) writer.writerow({ call_id: call_id, start_time: start_time, end_time: end_time, status: status, from_user: from_user, to_user: to_user, message_count: len(msgs) }) print(fReport saved to sip-report.csv ({len(calls)} calls)) if __name__ __main__: main()用法先运行./pcapsipdump -s 5060 -n -r capture.pcap -o dump.log再执行python sip-analyze.py dump.log。输出sip-report.csv含呼叫 ID、起止时间、状态success/failure/incomplete、主被叫用户名、消息数。可直接导入 Excel 做 PivotTable 分析失败率趋势。classify_call_status是核心逻辑它不依赖响应码字段pcapsipdump不提供而是扫描所有消息的method字段找200 OK和SIP/2.0 4xx等字符串——这正是pcapsipdump输出中实际存在的内容。5.2 提取失败呼叫的原始 SIP 消息定位根因的“后悔药”当sip-report.csv显示某次呼叫状态为failure你想看完整的 INVITE 请求和 404 响应原文含头字段细节pcapsipdump不提供此功能。但我们可以用tshark基于 Call-ID 精确提取# 从 CSV 中取出一个失败 Call-ID例如abc123-def456... CALL_IDabc123-def456 # 用 tshark 提取该 Call-ID 的所有 SIP 包并格式化输出-T json 更佳此处用 text 便于阅读 tshark -r capture.pcap -Y sip.Call-ID contains $CALL_ID \ -T fields -e frame.time -e ip.src -e ip.dst -e tcp.port -e udp.port \ -e sip.Request-Line -e sip.Status-Line -e sip.From -e sip.To \ -E separator | -E quoted $CALL_ID-detail.txt-Y sip.Call-ID contains $CALL_IDtshark 的显示过滤器精准匹配 Call-IDcontains防止因大小写或空格匹配失败。输出字段包含时间、IP、端口、请求/响应行、From/To 头一行一包清晰可读。此操作无需重跑pcapsipdump直接复用原始 pcap是真正的“后悔药”。从那以后我每次做 VoIP 故障复盘都强制走一遍这个流程pcapsipdump快筛 → Python 聚类打标 →tshark深挖。三者各司其职没有一个工具试图包打天下反而稳如磐石。希望帮到你。本文还有配套的精品资源点击获取
简介pcapsipdump-0.2 是一款轻量级开源 SIP 协议网络嗅探工具基于 libpcap 实现专为网络协议分析、VoIP 故障排查及 SIP/RTP 会话研究设计适用于网络安全工程师、通信协议开发者及高校网络实验教学人员。资源包共16个文件涵盖核心功能代码2个C源文件、1个C校验文件、2个头文件、多平台适配配置Debian/Solaris/RedHat 初始化脚本与sysconfig模板、构建支持Makefile、spec规范、helper脚本及完整文档体系README系列、ChangeLog、LICENSE整体仅15KB结构紧凑、可读性强。已有298人学习下载适合快速部署至Linux环境进行SIP信令捕获与会话分离分析。用户可直接编译运行获得按会话自动切分、命名规范的独立.pcap文件兼容Wireshark/tcpreplay等主流分析工具同时通过源码可深入理解SIP状态机跟踪、RTP流识别与PCAP写入机制。1. pcapsipdump 是什么不是抓包工具而是 SIP 信令的“结构化翻译器”你手头有一堆.pcap文件Wireshark 打开后满屏是 TCP/UDP 流、十六进制载荷、乱序重传——但真正想看的是谁打了哪通电话主叫号是多少被叫是否振铃通话是否建立SIP 消息里藏了全部答案可手动翻包等于用显微镜数米粒。pcapsipdump-0.2.tar.gz就是这个场景下的“翻译器”它不抓包、不绘图、不建连接只做一件事——从原始 pcap 流中精准提取 SIP 协议交互按会话Call-ID聚类输出结构化文本日志。它把INVITE → 100 Trying → 180 Ringing → 200 OK → ACK这一整条信令链压缩成一行可 grep、可导入 Excel、可喂给 Python 脚本分析的纯文本记录。适合网络运维排查 VoIP 故障、安全团队分析 SIP 洪泛攻击特征、或教学实验中快速验证 SIP 状态机行为。它不依赖 GUI无图形界面命令行跑完即出结果内存占用低于 5MB连树莓派都能扛住——但别指望它解析 RTP 媒体流也别让它处理 TLS 加密的 SIP over TLSSIPS那是另一个世界的活。2. 编译与安装为什么必须自己编译而不是apt installpcapsipdump不在主流发行版的默认仓库中。Debian/Ubuntu 的apt search pcapsipdump返回空CentOS/RHEL 的dnf list pcapsipdump同样查无此物。这不是维护者偷懒而是项目定位决定的它极度轻量源码仅 3 个 C 文件依赖极简仅 libpcap且多年未大更新0.2 版本发布于 2014 年社区打包动力不足。强行用apt install或pip install只会导向错误包比如同名但功能完全不同的 Python 工具。必须从源码编译——这反而是优势你能确认二进制里没塞任何第三方 SDK所有逻辑透明可控。2.1 环境准备三步清掉常见编译拦路虎提示不要跳过libpcap-dev。只装libpcap运行时库.so会导致configure阶段报错pcap.h not found因为编译需要头文件.h和静态链接支持。# Ubuntu/Debian 系统 sudo apt update sudo apt install -y build-essential libpcap-dev # CentOS/RHEL 系统启用 PowerTools 或 CRB 仓库 sudo dnf groupinstall -y Development Tools sudo dnf install -y libpcap-develbuild-essential或Development Tools提供gcc,make,autoconf等基础构建链。libpcap-dev或libpcap-devel包含pcap.h头文件及开发用静态库pcapsipdump的configure脚本会检查它是否存在。若系统已装libpcap但没装-dev包./configure会卡在checking for pcap_open_live in -lpcap... no这是最常被忽略的坑。2.2 解压、配置、编译四行命令走完全流程# 1. 解压源码注意路径别解到 /tmp 下编译生成的 .o 文件可能被自动清理 tar -xzf pcapsipdump-0.2.tar.gz cd pcapsipdump-0.2 # 2. 运行 configure它会检测 libpcap 路径、C 编译器能力、并生成 Makefile ./configure # 3. 编译生成 pcapsipdump 可执行文件无后缀非 pcapsipdump.bin make # 4. 可选安装到系统路径若需全局调用否则直接用 ./pcapsipdump 即可 sudo make install./configure输出中必须看到checking for pcap_open_live in -lpcap... yes和configure: creating ./config.status否则编译必败。make过程极快通常 3 秒无警告即成功若出现error: PCAP_NETMASK_UNKNOWN undeclared说明libpcap-dev版本过低 1.0需升级系统或手动指定 pcap 路径见避坑章节。sudo make install默认将二进制复制到/usr/local/bin/你可用which pcapsipdump验证。不安装也完全可行后续命令统一用./pcapsipdump调用。2.3 验证安装用最小 pcap 文件测通第一行输出# 创建一个最简 SIP pcap用 tcpdump 抓 10 秒本地回环的 SIP 流需本机有 SIP 客户端发请求 sudo tcpdump -i lo -w test-sip.pcap -c 100 port 5060 # 运行 pcapsipdump 解析-s 参数指定 SIP 端口-n 不解析 DNS 名称加速 ./pcapsipdump -s 5060 -n test-sip.pcap预期输出类似2024-05-22 14:30:22.123456 | 127.0.0.1:5060 127.0.0.1:5061 | INVITE | sip:1001localhost | sip:1002localhost | Call-ID: abc123... | From: sip:1001localhost;tagxyz | To: sip:1002localhost这行输出证明libpcap 能读包、SIP 解析逻辑生效、时间戳与 IP 端口提取正确。若输出为空先检查test-sip.pcap是否真含 SIP 流Wireshark 打开后过滤sip确认若报错pcap_open_offline: test-sip.pcap: Permission denied说明文件权限不对chmod 644 test-sip.pcap。3. 核心用法从单文件解析到批量会话归档pcapsipdump的设计哲学是“一次只做一件事”所以它的参数不多但每个都直击要害。它不提供 Web UI不存数据库输出就是标准输出stdout或重定向到文件。这种极简换来的是稳定性和可管道化pipe能力——你可以把它嵌入 Bash 脚本、Logstash pipeline甚至用cron每小时解析新 pcap。3.1 基础解析-s、-n、-r三个参数定生死# 最常用组合指定 SIP 端口-s、跳过 DNS 反解-n、读取 pcap 文件-r ./pcapsipdump -s 5060 -n -r capture.pcap # 解析多个 pcap 文件注意-r 只接受单文件多文件需循环 for f in *.pcap; do echo $f ; ./pcapsipdump -s 5060 -n -r $f; done # 实时解析网卡流量-i 指定接口-w 写入临时 pcap-c 限制包数防撑爆磁盘 sudo ./pcapsipdump -s 5060 -n -i eth0 -w /tmp/live.pcap -c 500-s 5060强制 SIP 端口为 5060。关键点pcapsipdump不自动识别 SIP 端口它只扫描指定端口上的 UDP/TCP 流。若你的 SIP 走 5061TLS或私有端口如 6060必须显式指定否则漏掉全部会话。-n禁用 DNS 反向解析。不加此参数时它会对每个 IP 调用gethostbyaddr()若 DNS 服务器慢或不可达解析会卡住数秒甚至超时导致输出延迟或中断。生产环境务必加。-r读取离线 pcap 文件。这是最常用模式。注意它不支持.pcapng格式Wireshark 新默认若遇到pcap_open_offline: unknown file format错误用 Wireshark 导出为.pcapFile → Export Specified Packets → Format:libpcap。3.2 输出控制-o重定向与字段定制的隐秘开关pcapsipdump默认输出到终端但真实场景中你需要存档、去重、导入数据库。它的输出格式固定为竖线分隔|共 8 列时间戳、源IP:端口 目标IP:端口、方法、From URI、To URI、Call-ID、From tag、To tag。没有参数能增减字段但你可以用标准 Unix 工具二次加工# 1. 重定向到文件推荐用 -o比 shell 更可靠 ./pcapsipdump -s 5060 -n -r capture.pcap -o sip-log.txt # 2. 提取所有唯一 Call-ID排查重复注册 ./pcapsipdump -s 5060 -n -r capture.pcap | cut -d| -f6 | sort -u # 3. 统计各 SIP 方法出现次数看是否异常 INVITE 暴增 ./pcapsipdump -s 5060 -n -r capture.pcap | cut -d| -f3 | sort | uniq -c | sort -nr # 4. 过滤出失败呼叫含 4xx/5xx/6xx 响应行注意pcapsipdump 不解析响应码需 grep 响应行 ./pcapsipdump -s 5060 -n -r capture.pcap | grep -E SIP/2\.0 [456][0-9][0-9]-o sip-log.txt是官方推荐方式比 sip-log.txt更健壮尤其当输出含特殊字符时。字段顺序固定cut -d| -fX是最轻量的字段提取法。第 3 列-f3是 SIP 方法INVITE,ACK,BYE,REGISTER第 6 列-f6是Call-ID这是会话聚合的唯一键。注意pcapsipdump不输出 SIP 响应码如200 OK,404 Not Found它只输出请求行和响应行的起始部分如SIP/2.0 200 OK所以用grep SIP/2.0 [456]是捕获失败响应的唯一办法。3.3 批量处理Shell 脚本实现 pcap 目录自动化解析面对上百个 pcap 文件如每日按小时切片手动for循环易出错。写一个健壮脚本自动处理、去重、归档#!/bin/bash # save as: batch-parse.sh PCAP_DIR./pcaps OUTPUT_DIR./sip-logs PCAPSIPDUMP./pcapsipdump # 创建输出目录 mkdir -p $OUTPUT_DIR # 遍历所有 .pcap 文件 for pcap_file in $PCAP_DIR/*.pcap; do # 跳过不存在的 glob当目录为空时 [[ ! -f $pcap_file ]] continue # 生成日志文件名basename 去后缀 .log log_file$OUTPUT_DIR/$(basename $pcap_file .pcap).log echo Processing: $pcap_file - $log_file # 执行解析加超时防止卡死某些损坏 pcap 会让 pcapsipdump 挂起 timeout 30s $PCAPSIPDUMP -s 5060 -n -r $pcap_file -o $log_file 2/dev/null # 检查输出是否为空解析失败则 log 文件为空 if [[ ! -s $log_file ]]; then echo Warning: $log_file is empty. Check $pcap_file integrity. rm -f $log_file fi done echo Batch parsing completed.timeout 30s是血泪经验遇到 CRC 校验错误或截断的 pcappcapsipdump可能无限循环。30 秒超时后杀进程保证脚本不阻塞。2/dev/null屏蔽 stderr如pcap_open_offline错误避免干扰日志。错误信息可单独重定向2error.log。[[ ! -s $log_file ]]检查文件大小空文件意味着解析失败非 pcap 问题就是无 SIP 流及时清理避免误判。4. 避坑与常见问题排查五个让老手也皱眉的硬核陷阱pcapsipdump表面简单但底层依赖 libpcap 和 C 运行时在不同环境会触发隐蔽故障。以下是实测中踩过的 5 个典型坑每条都附带复现条件、根因和绕过方案。4.1 现象./configure报错checking for pcap_open_live in -lpcap... no原因系统装了libpcap.so运行库但缺失libpcap.a静态库或pcap.h头文件。configure脚本通过链接测试link test验证 libpcap 可用性找不到头文件则链接失败。解决安装-dev或-devel包Ubuntu/Debian 用libpcap-devCentOS/RHEL 用libpcap-devel。若已安装仍报错检查头文件路径find /usr -name pcap.h 2/dev/null若在/usr/include/pcap/pcap.h则需./configure CPPFLAGS-I/usr/include/pcap。4.2 现象编译时报错error: PCAP_NETMASK_UNKNOWN undeclared原因pcapsipdump-0.2源码中引用了较新 libpcap 的宏PCAP_NETMASK_UNKNOWN但你的系统 libpcap 版本太旧 1.0。该宏在 libpcap 1.0 中引入用于处理无法获取子网掩码的情况。解决升级 libpcap。Ubuntu 18.04 自带 ≥1.8可sudo apt install libpcap-dev强制更新若无法升级手动修改pcapsipdump.c第 123 行将PCAP_NETMASK_UNKNOWN替换为0这是一个安全的 fallback 值不影响核心功能。4.3 现象输出日志中 IP 显示为0.0.0.0或::端口为0原因pcapsipdump从 pcap 包中提取 IP/端口时依赖 libpcap 解析 IP 头。若 pcap 文件是用tcpdump -i any抓的混杂模式跨接口或使用了-P参数设置 snaplen 过小IP 头可能被截断导致解析失败。解决重新抓包确保snaplen足够。tcpdump -i eth0 -s 0 -w good.pcap port 5060-s 0表示完整抓包不截断。若必须用旧 pcap可用editcap -s 128 old.pcap new.pcap增大 snaplen 后再解析。4.4 现象同一 Call-ID 在输出中出现多次且时间戳相同原因pcapsipdump对每个 SIP 消息独立输出一行不合并会话。一个完整呼叫INVITE→200→ACK会输出 3 行Call-ID 相同。这不是 bug是设计如此。用户误以为“重复”是因为期望它像 Wireshark 的 “Follow SIP Stream” 那样聚合。解决用外部工具聚合。例如用awk按 Call-ID 分组./pcapsipdump -s 5060 -n -r cap.pcap | awk -F| {call[$6] call[$6] $0 \n} END {for (c in call) print --- Call-ID:, c, ---\n call[c]}4.5 现象解析结果中 From/To URI 为空显示为| |连续两个竖线原因SIP 消息的From:/To:头字段格式不规范。pcapsipdump使用简单字符串匹配strstr(buf, From:)若头字段换行如From:\r\n sip:userdomain或含多余空格匹配失败。解决此为解析器局限无完美修复。临时方案用tshark预处理提取标准格式 URItshark -r capture.pcap -Y sip.From or sip.To -T fields -e sip.From -e sip.To -E separator| -E quoted uri-raw.txt然后用脚本关联pcapsipdump的 Call-ID 和tshark的 URI。5. 进阶技巧用 Python 补全 pcapsipdump 的“盲区”pcapsipdump的强项是快、轻、准——但它不解析 SDP、不提取认证头、不判断呼叫状态成功/失败。这些“盲区”恰恰是 VoIP 分析的关键。我一般用 Python 写一个薄层包装器把pcapsipdump的输出作为输入补全语义。下面是一个实战脚本它接收pcapsipdump日志输出带状态标记的 CSV并导出失败呼叫的完整消息流。5.1 构建解析管道pcapsipdump → Python → 结构化 CSV#!/usr/bin/env python3 # save as: sip-analyze.py import sys import csv from datetime import datetime from collections import defaultdict def parse_pcapsipdump_line(line): 解析 pcapsipdump 一行输出返回字典 parts [p.strip() for p in line.strip().split(|)] if len(parts) 8: return None return { timestamp: parts[0], direction: parts[1], method: parts[2], from_uri: parts[3], to_uri: parts[4], call_id: parts[5], from_tag: parts[6], to_tag: parts[7] } def classify_call_status(messages): 根据消息序列判断呼叫状态 methods [m[method] for m in messages] if INVITE in methods and 200 OK in methods and ACK in methods: return success elif INVITE in methods and any(m.startswith(SIP/2.0 4) or m.startswith(SIP/2.0 5) or m.startswith(SIP/2.0 6) for m in methods): return failure else: return incomplete def main(): if len(sys.argv) ! 2: print(Usage: python sip-analyze.py pcapsipdump_log) sys.exit(1) # 按 Call-ID 聚合所有消息 calls defaultdict(list) with open(sys.argv[1], r) as f: for line in f: msg parse_pcapsipdump_line(line) if msg and msg[call_id]: calls[msg[call_id]].append(msg) # 准备 CSV 输出 with open(sip-report.csv, w, newline) as csvfile: fieldnames [call_id, start_time, end_time, status, from_user, to_user, message_count] writer csv.DictWriter(csvfile, fieldnamesfieldnames) writer.writeheader() for call_id, msgs in calls.items(): if not msgs: continue # 排序按时间戳升序pcapsipdump 输出已有序但保险起见 msgs.sort(keylambda x: x[timestamp]) status classify_call_status(msgs) start_time msgs[0][timestamp] end_time msgs[-1][timestamp] from_user msgs[0].get(from_uri, ).split()[0].replace(sip:, ) to_user msgs[0].get(to_uri, ).split()[0].replace(sip:, ) writer.writerow({ call_id: call_id, start_time: start_time, end_time: end_time, status: status, from_user: from_user, to_user: to_user, message_count: len(msgs) }) print(fReport saved to sip-report.csv ({len(calls)} calls)) if __name__ __main__: main()用法先运行./pcapsipdump -s 5060 -n -r capture.pcap -o dump.log再执行python sip-analyze.py dump.log。输出sip-report.csv含呼叫 ID、起止时间、状态success/failure/incomplete、主被叫用户名、消息数。可直接导入 Excel 做 PivotTable 分析失败率趋势。classify_call_status是核心逻辑它不依赖响应码字段pcapsipdump不提供而是扫描所有消息的method字段找200 OK和SIP/2.0 4xx等字符串——这正是pcapsipdump输出中实际存在的内容。5.2 提取失败呼叫的原始 SIP 消息定位根因的“后悔药”当sip-report.csv显示某次呼叫状态为failure你想看完整的 INVITE 请求和 404 响应原文含头字段细节pcapsipdump不提供此功能。但我们可以用tshark基于 Call-ID 精确提取# 从 CSV 中取出一个失败 Call-ID例如abc123-def456... CALL_IDabc123-def456 # 用 tshark 提取该 Call-ID 的所有 SIP 包并格式化输出-T json 更佳此处用 text 便于阅读 tshark -r capture.pcap -Y sip.Call-ID contains $CALL_ID \ -T fields -e frame.time -e ip.src -e ip.dst -e tcp.port -e udp.port \ -e sip.Request-Line -e sip.Status-Line -e sip.From -e sip.To \ -E separator | -E quoted $CALL_ID-detail.txt-Y sip.Call-ID contains $CALL_IDtshark 的显示过滤器精准匹配 Call-IDcontains防止因大小写或空格匹配失败。输出字段包含时间、IP、端口、请求/响应行、From/To 头一行一包清晰可读。此操作无需重跑pcapsipdump直接复用原始 pcap是真正的“后悔药”。从那以后我每次做 VoIP 故障复盘都强制走一遍这个流程pcapsipdump快筛 → Python 聚类打标 →tshark深挖。三者各司其职没有一个工具试图包打天下反而稳如磐石。希望帮到你。本文还有配套的精品资源点击获取
