简介七号信令SS7是电信网呼叫建立、路由与计费的核心协议栈这份资料面向通信工程师、协议开发人员及高校相关专业学生帮助系统理解MTP三层结构、SCCP面向连接服务、TCAP事务处理机制以及信令点SP与转接点STP组成的网络架构。压缩包共收录607个文件以465张jpg示意图和138个htm文档为主另有少量html与txt说明整体仅3.43MB图片适合快速查看信令流程与消息格式htm网页文档便于按章节离线学习与检索。内容除了协议分层、信令数据单元与路由方式还涉及SS7与IP网融合、智能网应用及安全防护等实践议题并配有实例分析能够帮助读者从原理到应用建立完整认知。目前已有373人学习对于从事通信网络运维、协议研发或相关课题研究的读者是低成本入门与进阶的好材料尤其适合通信课程设计、资格认证或技术调研场景。1. 一张异常话单背后为什么还要懂SS7七号信令一张话单对不上账通常先怀疑计费系统再怀疑中继最后才想到信令。可实际排查里七号信令SS7往往是那个藏在黑匣子里的变量IAM 消息没到对端批价就无从谈起SCCP 的全局标题翻译错了短信中心就收不到下一跳。SS7.rar 这类名字的压缩包经常就是信令工程师从局方环境导出的解析工具、离线 pcap 和说明文档的合集。下面用五章把它拆开先立分层认知再跑通最小解析链路然后讲几个高频坑最后给出两个能验证“我没解析错”的办法。适合做协议开发、话单核对和信令链路运维的从业者也适合刚接手 SS7 测试系统的新人。2. 看懂SS7协议栈MTP、SCCP、TCAP的分层逻辑与必调参数2.1 分层结构把SS7消息当快递包裹看只要是第一次接触 SS7 的人都会先被 MTP1、MTP2、MTP3、SCCP、TCAP 这一串缩写吓住。把它当快递包裹看就顺了MTP1 是运输车辆负责把物理信号送到相邻节点MTP2 是装卸工解决一条链路上的差错重传和定位MTP3 是分拨中心看目的信令点编码把包裹往哪个方向送SCCP 是填写收件人手机号负责从信令点找到具体业务子系统TCAP 是快递员承载一次完整的业务操作会话比如位置更新、短消息、智能网触发。解析一条 SS7 消息时我更关心每一层暴露出来的“可读字段”协议层职责解析时重点看的字段MTP2链路级可靠传输BSN、FSN、LI、CRCMTP3信令网路由SIO、DPC、OPC、SLSSCCP端到端寻址Called/Calling Party Address、GT、SSNTCAP业务操作会话Transaction ID、Opcode、Dialogue ID很多新手喜欢直接翻到 ISUP 层看 CIC或者翻到 TCAP 层看操作码这没有错但路由出了问题你会傻眼MTP3 的 DPC 指错了局ISUP 层看到的就全是“对端不存在”SCCP 的 GT 翻译配错TCAP 层干脆一条消息都看不到。所以做信令解析的第一步不是急着读业务字段而是先把层与层之间的“路由索引”对清楚。MTP2 的长度指示 LI 也是经常被误解的字段。它在 MSU 里表示后面 SIF 的 16 位字数不是字节数。解析时如果不乘 2后面所有字段都会偏移这个在第 4 章还会专门展开。MTP3 的 SIO 字节里有业务指示语0x03 通常是 SCCP0x05 通常是 ISUP看到这个值你就能判断这条 MSU 里装的是什么业务。2.2 寻址与路由参数DPC、OPC、SLS、CIC谁决定一条消息MTP3 的路由标签是 SS7 网络里的“门牌号”。DPC 是目的信令点编码OPC 是源信令点编码SLS 是链路选择码用来在多条链路之间做负荷分担。ISUP 里还有一个 CIC是电路识别码用来关联一条具体的话路。它们的分工差异很大翻车的方式也完全不同参数含义常见误用DPC目的信令点编码不区分 14/24 位格式导致值对不上OPC源信令点编码把 OPC/DPC 填反路由链路直接不通SLS链路选择码以为是随机数其实同一业务常常固定CIC电路识别码同一个中继群内重复话路串线拿到一个 pcap 的第一件事我会先用 tshark 确认 MTP3 层是不是真的被解析出来了tshark -r ss7_workspace/trace.pcap -Y mtp3 -T fields \ -e mtp3.dpc -e mtp3.opc -e mtp3.sls \ -E headery -E separator, | head -20这个命令的关键在-Y mtp3只有 Wireshark 把报文识别成 MTP3 之后mtp3.dpc、mtp3.opc这些字段才有值。如果输出只有表头没有数据说明抓包点不在 MTP3 层或者报文被当成了别的协议——最常见的是 Sigtran 环境里被识别成 SCTP/M3UA需要用-d参数强制解码这个坑在第 4 章详细讲。-E headery会输出首行字段名-E separator,把分隔符设成逗号方便直接贴进表格工具。用head -20限制行数先看前 20 条消息的分布别一上来就全量导。信令点编码还有一个隐蔽问题ITU-T 标准是 14 位点编码ANSI 和中国国内规范多用 24 位点编码。14 位和 24 位的位段排布不同同一个十六进制字节按 14 位拆和按 24 位拆出来的 DPC/OPC 完全不是一回事。很多解析工具默认 ITU-T拿国内 24 位的抓包去喂就会得到一堆莫名其妙的数字。提示开始解析前先确认这份 pcap 来自哪种点编码格式再决定后续所有字段解析的宽度。这一步错了后面全是白干。SLS 在一个呼叫里通常是固定的但在负荷分担场景下同一条话路的 ISUP 消息可能经由不同链路到达抓包顺序不代表发送顺序。做性能分析时我会同时抓两条链路的 pcap再按 CIC 和事务 ID 合并排序而不是只看单一链路的顺序。3. 从压缩包到可读报文解析七号信令的最小工具链与脚本3.1 解开SS7.rar先看包内文件清单别急着双击这类工程压缩包不管叫什么名字第一步永远是先看里面有什么。有的包里是 Wireshark 插件有的是 Python 脚本有的是抓包说明文档和 pcap 样例。用 7-Zip 列出内容是很常见的做法7-Zip 照常能解开 rar 格式不一定非得装专门的 rar 解压软件7z l SS7.rar 7z x SS7.rar -o./ss7_workspace7z l只列清单不释放文件适合先确认包内目录结构7z x会保留压缩包内的目录层级。注意-o后面不要加空格直接跟目标路径这个参数一旦写成-o ./workspace就会路径不生效算是个老坑。解压之后先找说明文档重点看两件事抓包点的信令点编码格式是 14 位还是 24 位抓包环境是 TDM E1 还是 Sigtran over IP。这两项直接决定后面所有解析脚本怎么写。常见压缩包里一般会有三类文件抓包/回放脚本、字段说明文档、离线 pcap 样例。说明文档比代码更值得先读因为它写的是现场配置。代码插件只是工具配置错了工具也会给你错误答案。3.2 用tshark把原始帧变成字段表离线 pcap 最方便的输出方式是用 tshark 直接抽字段。相比打开图形界面一条消息点过去命令行方式适合批量核对tshark -r ss7_workspace/trace.pcap \ -Y mtp3 || sccp || tcap \ -T fields \ -e frame.number \ -e mtp3.opc -e mtp3.dpc -e mtp3.sls \ -e sccp.called_party -e tcap.opcode \ -E headery -E separator, \ -2参数的作用分别是-r指定 pcap-Y做显示过滤mtp3 || sccp || tcap表示只要这三层有任意一层就会被保留-T fields进入字段输出模式-e指定要打印的字段-2表示做两遍解析Wireshark 的 SS7 dissector 经常需要依赖后续层才能反推前面的协议边界不加-2会有一批消息显示为 malformed。如果tcap.opcode一列为空说明该条消息不是 TCAP 承载的业务也可能是 SCCP 层没被正确识别。前者是正常的比如 ISUP 消息本来就不走 TCAP后者需要检查 SCCP 是否被错误解码成了其他协议。要快速看一个呼叫的基本流程是否完整我会用另一种统计方式tshark -r trace.pcap -Y isup -T fields -e isup.message_type \ | sort | uniq -c | sort -rn输出会统计 IAM、ACM、ANM、REL、RLC 各出现多少次。一个正常结束的呼叫IAM 和 RLC 的数量应该接近如果 RLC 明显少于 REL说明很多释放消息没有收到释放完成确认这就是一条值得往下查的线索。注意这只是数量级判断不是绝对结论真实网络里还有互放、久叫不应等分支。3.3 自己用Python解析一条IAM手写解析器的最小实现tshark 能告诉你怎么看但如果你要做自动核对或接进自己的平台还是需要一段可控的解析代码。下面这段代码处理从 SIO 开始的 MSU 正文假设它是 ITU-T 14 位点编码的路由标签布局import struct ISUP_MSG {1: IAM, 6: ACM, 7: ANM, 12: REL, 16: RLC} def parse_mtp3_label(sio_and_label: bytes): # sio_and_label 长度至少 51 字节 SIO 4 字节路由标签 # 14 位点编码的路由标签是 32 位DPC 高 14 位OPC 中间 14 位SLS 低 4 位 label struct.unpack(I, sio_and_label[1:5])[0] dpc (label 18) 0x3FFF opc (label 4) 0x3FFF sls label 0x0F return dpc, opc, sls def parse_isup(sio_and_label_and_isup: bytes): dpc, opc, sls parse_mtp3_label(sio_and_label_and_isup) isup sio_and_label_and_isup[5:] cic struct.unpack(H, isup[:2])[0] mtype isup[2] return dpc, opc, sls, cic, ISUP_MSG.get(mtype, hex(mtype)) # 用你 pcap 里复制的 MSU 十六进制替换这一行 raw_msg bytes.fromhex(01 05 12 34 56 78 00 01 06.replace( , )) dpc, opc, sls, cic, type_name parse_isup(raw_msg) print(fOPC{opc} DPC{dpc} SLS{sls} CIC{cic} TYPE{type_name})这段代码先读 MTP3 路由标签struct.unpack(I, ...)按大端取出 4 字节整数(label 18) 0x3FFF取高 14 位作为 DPC(label 4) 0x3FFF取中间 14 位作为 OPClabel 0x0F取低 4 位作为 SLS。0x3FFF 是 14 位掩码0x0F 是 4 位掩码如果你要适配 24 位点编码这里的位置必须重排。ISUP 部分从 MTP3 之后的第 5 个字节开始CIC 占 2 字节消息类型占 1 字节。IAM、ACM、ANM、REL、RLC 这些消息类型都有数值对应代码里用字典转成可读名字。如果你解析到未知类型会输出十六进制值这时候先别急着当成垃圾消息查一下是不是新规范或厂商私有扩展。真实解析里IAM 的被叫号码还要继续解析 BCD 编码的号码字段这段先用消息类型验证解析通路号码字段交给 Wireshark 的isup.called_party_number去提取更稳妥。4. 解析七号信令的常见问题排查点编码、长度与SCCP的5个坑4.1 过滤条件筛了半天一张表是空的现象拿到一份 Sigtran 环境的 pcap用-Y ss7过滤结果一条消息都没有。原因SS7 过滤器只匹配 MTP 层而 Sigtran 抓包里的信令载荷是被封装在 SCTP 里的 M3UA 消息。Wireshark 默认不会把它当 M3UA 解析而是当成普通 SCTP 数据块看不到 DPC/OPC 自然什么都筛不出来。解决先用-d指定端口对应的协议常见 M3UA 端口是 2905tshark -r sigtran.pcap -d tcp.port2905,m3ua \ -Y m3ua || mtp3 \ -T fields -e m3ua.protocol_data.opc -e m3ua.protocol_data.dpc \ -E headery-d tcp.port2905,m3ua是强制解码规则让 Wireshark 把该端口流量按 M3UA 处理。强制解码之后M3UA 里的协议数据字段才会暴露出来。如果端口不是 2905先看 pcap 里 SCTP 实际目的端口再改。图形界面里对应的操作是右键“Decode As”命令行里就是-d。4.2 长度指示不当字节算字段一路越界现象解析脚本报“长度字段越界”或者打印出来的被叫号码里全是奇怪的 ASCII 字符和 Wireshark 里看到的不一致。原因MTP2 的 LI 字段单位是 16 位字不是字节。很多第一次写解析器的人拿到 LI 直接用LI 3当 SIF 长度结果每一条消息的接口都偏了。FISU 的 LI 是 0LSSU 是 1 或 2MSU 从 2 往上但表示的是后面 SIF 的字数。解决先把 LI 字段乘 2 转成字节数再做切片。校验方法很简单取一条消息LI5按 5×210 字节切 SIF如果后续字段能正常对齐到 IAM、ACM 的消息类型说明宽度对了。解析失败时不要盯着字段值改掩码先回过来看 LI 的换算。4.3 14位和24位点编码混用DPC/OPC全对不上现象Wireshark 里显示的信令点编码是一串很长的数字你解析脚本里出来的却是一个小得多的数或者同一个 pcap两个工具读出的 DPC 完全不同。原因国内规范常见的 24 位点编码和 ITU-T 的 14 位点编码排布不同。14 位编码的路由标签是 DPC 14 位OPC 14 位SLS 4 位24 位编码不是简单把 14 加 10而是有自己的位段布局。用 14 位的解析逻辑去读 24 位的报文拆出来的值自然不是本来的点编码。解决解析之前先确定点编码格式。在 Wireshark 里通过协议首选项设置信令点编码格式自写脚本时按对应格式设计位段。解析结果最好和 Wireshark 对拍一次对不上就先排查点编码格式再排查位操作。这一步错了后面所有按 DPC 分表的统计都不可信。4.4 SCCP的GT和SSN标志位没置位TCAP业务全看不见现象明明有大量 SCCP 消息但 TCAP 层一张空表。检查 SCCP 的 Called Party 字段时GT 和 SSN 显示为空。原因SCCP 被叫地址字段的地址指示语里用 bit 标记后面是否包含 GT、是否包含 SSN、是否包含路由。如果这些标志位没有正确置位即使载荷里有地址内容解析器也不会去读。另一个常见原因是 SSN 子系统号没配置消息只能到信令点不能继续路由到 HLR、MSC 这类业务节点。解决看 SCCP 消息时先解析地址指示语字节确认 Called Party Address 里的 GT 类型、编号计划、翻译类型和 SSN 都有值。GT 的存在价值是解决跨网寻址如果对端只需要 DPC 寻址那 GT 为空是正常的但凡是跨信令点的业务寻址GT 和 SSN 必须一起出现。调试时可以先用 Wireshark 的sccp.called_party字段确认地址结构再回头改解析器。4.5 同一CIC的消息乱序统计结果忽好忽坏现象单独看每一条 ISUP 消息都正常但解析呼叫流程时发现 ACM 出现在 IAM 之前或者 REL 之后没有再等到 RLC。原因同一对信令点之间存在多条链路SLS 决定消息走哪条链路。负荷分担下同一次呼叫的消息可能分散到不同链路抓包只抓了其中一条序列自然对不上。链路倒换发生时SLS 的映射关系还会临时变化让问题更隐蔽。解决做流程核对时按 CIC 和 TCAP 事务 ID 对消息重新排序不要依赖抓包顺序。测试环境里可以固定链路选择策略让同一 CIC 始终走同一链路能省掉大量排序的麻烦。5. 验证SS7解析结果两个可复现的字段自检技巧5.1 字段级对拍tshark结果和自己解析器逐字段diff解析器写完最怕出“看起来对但字段错了”的问题。我会把 tshark 的输出和自己脚本的输出各导成一份 CSV用 diff 做字段级对拍tshark -r trace.pcap -Y isup -T fields \ -e frame.number -e mtp3.dpc -e isup.message_type \ -E headery tshark_out.csv python my_parser.py trace.pcap my_out.csv diff (cut -d, -f1-3 tshark_out.csv) (cut -d, -f1-3 my_out.csv) | head -20diff 没有输出说明至少 frame.number、DPC、消息类型这三列完全一致。如果只有少数行不一致优先看点编码格式如果大量不一致多半是 MTP3 层就开始错位了。Windows 环境没有进程替换的话先把两份 CSV 存成文件再 diff道理一样。5.2 状态机验收一条完整呼叫必须走通IAM→ACM→ANM→REL→RLC字段对拍通过之后再做一次流程级验证。固定一个 CIC检查同一通话的消息序列是否符合预期expected [IAM, ACM, ANM, REL, RLC] actual extract_messages(trace.pcap, cic0x1234) for step, name in enumerate(expected): if actual[step] ! name: print(f第{step1}条期望{name}实际{actual[step]}) break else: print(呼叫流程五步齐全)注意这个验收只适用于固定 CIC 的单通话测试场景。真实网络里有后向释放、早期 ACM、互放等分支消息顺序不是教科书式的所以代码里我用了逐步比对并输出第一个不匹配的字段而不是要求全表完全等于 expected。验证目的是发现解析器有没有漏消息、字段有没有错位不是为了证明网络符合理想流程。我以前在这个环节吃过亏写解析器时拿一段 Wireshark 的导出数据做样本字段全对没想到换了 pcap 就翻车。后来养成习惯每接一份新抓包先做tshark 自己脚本的对拍再跑一次流程验收两关都过了才把结果交给下游。这个习惯帮我在后面处理 SCCP 和 TCAP 业务解析时省了很多返工希望帮到你。本文还有配套的精品资源点击获取
