拓冰网站定制 
简介SS7七号信令协议学习资料包以图片和网页文档形式系统整理了Signalling System No.7的核心内容覆盖从MTP底层传输到SCCP、TCAP上层应用的完整协议栈适合电信行业从业者、通信专业学生及协议研究者作为入门与进阶参考。压缩包内共607个文件包含465个jpg图片、138个htm网页文档、3个html及1个txt说明文件总大小仅3.43MBjpg图片直观展示信令消息格式、网络拓扑与流程示例htm文档则系统讲解MTP消息传递部分、SCCP信令连接控制、TCAP事务处理等各层功能。内容进一步涉及SS7网络架构、信令点与转接点配置、SCCP端到端连接、TCAP智能网应用、SS7与IP网络融合方案以及安全漏洞防护要点并配有实例分析举例说明呼叫建立、路由选择与计费场景有助于读者理解七号信令在现网中的实际运作机制。已有371人学习下载该资料包以图文结合的方式降低了协议学习门槛适合需要系统梳理信令知识的通信工程师与研究人员收藏使用。1. 为什么一套40年前的协议还在调度今天的电话与短信SS7与七号信令调试间里堆着三台信令服务器指示灯全绿但电话就是接不通。应用层日志没有任何报错最后用抓包工具盯了十分钟发现ISUP的IAM消息压根没从MTP3层交出去。这种时候你会意识到SS7七号信令这套协议栈虽然诞生于模拟电话时代今天依然在核心网里承担着呼叫建立、计费、漫游、短信投递这些最底层的信令调度。它和常说的7层协议模型不冲突它本身就是电信网自己的另一套七层——只不过每一层的历史包袱都还在。这篇文章不聊教科书定义而是从拿到一份SS7协议样本包之后怎么解析、怎么看参数、怎么踩坑出发把链路层、网络层、业务层一条线走通。适合正在做核心网联调、网关对接、信令分析平台的工程师也适合刚接触七号信令想快速上手抓包排查的人。2. 拆开SS7协议栈从MTP到TCAP每一层在信令流程里做什么2.1 四层结构里每一层完成什么任务SS7不是单一协议是一个协议族ITU-T Q.700系列把它组织成分层结构。最底下是MTP1处理物理层要么是E1/T1的时隙要么是经过SIGTRAN映射到IP承载。MTP2是链路层负责帧定位、差错检测、重发和流量控制类似TCP里确认与重传那套机制但用的是信令单元的格式。MTP3是网络层负责信令点之间的路由和流量管理消息根据DPC目的信令点编码转发相当于IP层加一部分路由协议的功能。MTP3之上挂了若干用户部分。ISUP负责电路相关信令比如一次普通电话呼叫的建立和释放消息类型有IAM、ACM、ANM、REL、RLC这是做呼叫分析最常接触的一层。SCCP信令连接控制部分在MTP3之上提供类似端口号的寻址能力通过子系统号SSN找到GT全局标题对应的业务TCAP事务能力应用部分承载的MAP、CAP这类移动网业务以及智能网业务都跑在SCCP之上。TUP是更老的回路线路控制协议在不少现网里已经被ISUP取代了遇到老样本包时偶尔还能看到。分层之间的关系不是严格的下层为上层服务那么简单。ISUP和SCCP都挂在MTP3之上ISUP关注的是电路SCCP关注的是事务。TCAP本身不管电路它只负责把一次远端操作的调用和返回对应起来像MAP里的位置更新、短信发送、鉴权请求都是通过TCAP的Invoke和ReturnResult完成的。理解这个分层抓包时才能一眼看出问题在哪个层MTP2的FSN不连续是链路问题ISUP的IAM没响应是呼叫控制问题TCAP的事务超时是应用层问题。2.2 信令点编码、子系统号与链路类型分析前必懂的三个概念信令点编码SPC是SS7网络里每个节点的地址常见的有ITU-T 14位格式和ANSI 24位格式写出来像3-128-1或1.2.3这样。抓包时OPC是源信令点编码DPC是目的信令点编码很多分析工具默认按ITU-T格式显示遇到ANSI的包会显示成很奇怪的大数字这就是最常见的看着地址不对其实解码格式错了的翻车点。子系统号SSN是SCCP层的地址扩展类似TCP端口号比如移动用户就是SSN 6MAP的各个服务有各自的SSN。还有SLS信令链路选择码它决定消息走哪条链路同一对OPC/DPC之间的同一次会话SLS必须保持一致消息才能按序到达。业务指示语SI在SIO字节里ISUP是SI5SCCP是SI3抓包过滤时用得上。链路类型也直接影响分析。A链路连接两个信令点B链路连接从属信令点与转接点C链路连接两个转接点D链路是准直联的延伸E链路是跨网络冗余。实际抓包时不一定要分清所有类型但要知道A/B/C/D/E中同一条链路上的消息顺序是可靠的跨链路汇聚过来的消息顺序不保证后面分析TCAP事务时这很关键。2.3 用tshark验证你手上的包来自哪一层拿到一份未知样本先别急着看懂内容先用工具确认链路类型和解码层级。这步非常建议做能省掉后面大量盲猜的时间。capinfos sample.pcap | grep -E Link type|Number of packets tshark -r sample.pcap -c 5 -V 2/dev/null | grep -E Message type|Service indicator|Destination point code|Source point codecapinfos输出的Link type如果是ss7说明抓包时已经指定了SS7链路类型Wireshark会自动挂上MTP2解析器。如果显示ETHERNET或者USER0说明包是裸IP承载或者链路类型没标对后面要么手动指定decode as要么重新抓包。第二条tshark命令取前5个包直接看MTP3层的Destination point code和Service indicator能快速判断样本是ISUP为主还是MAP为主。这个习惯帮我省掉了很多打开包发现一片黑的尴尬时间建议养成。3. 用Wireshark和tshark把SS7样本包拆成信令流程过滤、导出与重放3.1 解压样本先验明文件身份rar压缩包与pcap的边界标题里带了rar_protocols实际工作中拿到的协议样本经常是rar或zip压缩好的pcap解压后第一件事不是双击打开而是确认文件格式和链路类型。rar解压本身没什么技术含量重点是解压后别被文件名骗了一个叫SS7_trace.pcap的文件里面可能是普通的UDP封装也可能是真正的TDM链路采集。unar SS7_Protocols.rar # 如果系统里没有unar换成 unrar x SS7_Protocols.rar file sample.pcap capinfos sample.pcap | grep -E Link type|Capture length|Number of packetsfile命令确认pcap格式是pcap还是pcapngcapinfos是关键它告诉你这个文件的链路层类型。如果Link type是ss7可以直接用Wireshark按SS7解析如果Link type是ETHERNET且包里带着SCTP源端口2905说明是SIGTRAN承载需要按SCTP/M3UA路径解析。这一步确定了后面的过滤条件和协议变体选型才能选对。3.2 用过滤语法拆出ISUP与TCAP先看消息类型再看参数Wireshark的显示过滤器对SS7支持得不错关键是记住几个固定的过滤字段。只看MTP3层就用mtp3只看ISUP就用isup想看TCAP里的MAP操作就用tcap这些字段在Wireshark的Protocol列表里都能看到但命令行跑批处理时用tshark更顺手。# 列出所有ISUP消息类型及各类型数量 tshark -r sample.pcap -Y isup -T fields -e isup.message_type | sort | uniq -c | sort -rn # 按消息类型导出关键字段源点编码、目的点编码、SLS、CIC tshark -r sample.pcap -Y isup -T fields -e mtp3.opc -e mtp3.dpc -e mtp3.sls -e isup.cic -E headery -E separator,isup.message_type在Wireshark里显示为IAM、ACM、ANM这类可读字符串导出后做统计非常直观。mtp3.opc和mtp3.dpc是MTP3层的源点和目的点编码isup.cic是电路识别码这是把一次呼叫串起来的核心字段。注意不同版本Wireshark的字段名可能略有差异跑之前可以用tshark -G fields先确认字段名这个技巧能避免拿到一堆空值。3.3 用tcpreplay在本地回放控制速率比控制内容更重要抓包文件要在测试环境回放常见做法是用tcpreplay。直接默认参数回放有两个坑一是样本包可能是几小时甚至几天的采集tcpreplay会在一瞬间全部发完二是SS7样本的链路类型不是以太网时tcpreplay会报错。# 限速回放不要全速突袭 tcpreplay --pps50 -i lo sample.pcap # 如果样本链路类型不是以太网先指定数据链路类型再回放 tcpreplay --pps50 --dltss7 -i lo sample.pcap--pps50意思是每秒最多发50个包适合让上层状态机有足够时间处理事务。--dltss7是告诉tcpreplay样本原始链路类型是SS7避免回放时被当成普通以太网帧拆解出错。如果目标是复现真实信令流量压力可以把pps调大但如果目的是验证业务流程建议从低速率开始观察对端有没有超时重发再慢慢往上加。回放时可以同时起Wireshark抓回环口用-L参数确认接口支持什么链路类型。3.4 用Python按消息类型粗筛把几千个包变成一张直方图tshark做过滤已经很快但需要做更复杂的统计、按呼叫维度聚合、或者把结果接进自研平台时Python是绕不开的。我最常用的是pyshark它封装了tshark的解析能力可以当对象用比直接调用命令行更好处理结构体。import pyshark # 只加载ISUP层keep_packetsFalse避免把整包内容全部保留在内存 cap pyshark.FileCapture( sample.pcap, display_filterisup, keep_packetsFalse, ) count {} for pkt in cap: try: mt pkt.isup.message_type count[mt] count.get(mt, 0) 1 except AttributeError: # 个别包虽然有isup过滤命中的字段但层对象不完整跳过 continue print(sorted(count.items(), keylambda x: x[1], reverseTrue))pyshark的display_filter在FileCapture初始化时就传给tshark比逐个包再判断效率高得多。pkt.isup.message_type是字符串直接可以做分类统计。注意keep_packetsFalse这个参数不做深层引用时尽量打开否则几万包的文件内存占用会非常难看。AttributeError捕获的是那些在ISUP层解到一半但字段不齐全的包这类异常在混合流量里很常见不要让它中断整个循环。注意pyshark依赖tshark的可执行路径跑之前先确认tshark在系统PATH里否则FileCapture会直接抛ExecutableNotFound。4. 七号信令联调参数OPC/DPC、SLS、定时器与协议变体怎么配4.1 链路参数速查表这些参数填错了信令根本不通联调SS7网络时最常打交道的参数就那几个。整理成表格方便对照检查参数作用常见取值/格式填错时的表现OPC/DPC源/目的信令点编码ITU-T 14位点分式如3-128-1ANSI 24位消息被对端丢弃没有任何响应SIO服务信息八位组含子业务字段和业务指示语ISUP固定SI5SCCP固定SI3Wireshark能解出包对端协议栈不认SLS信令链路选择码值范围0~15或0~31同一呼叫需相同消息乱序ISUP呼叫建立失败CIC电路识别码16位ITU-T变体或12位ANSI变体呼叫与被叫电路对不上REL放错电路SSN子系统号MAP用6HLR、VLR各有定义SCCP路由失败TCAP请求无响应OPC/DPC配置错误是最难排查的一类问题因为现象和网络故障很像两边链路都显示正常但消息发出去石沉大海。我遇到过一对OPC配置反了的案例抓包看MTP3层地址完全反了对端协议栈直接把它们当成来自错误信令点的消息丢弃了。所以联调第一步不是看业务而是核对两端SPC表、SIO和SLS是否匹配。4.2 ISUP、MAP与协议变体ITU-T和ANSI真的不能混用ISUP协议有两个主要变体ITU-T Q.763和ANSI T1.113。两者在消息格式、参数编码和CIC位宽上有明显差异混用的结果是消息能解出来但关键参数错位比如把IAM里的被叫号码读成了一串乱码。移动核心网里的MAP协议跑在TCAP上规范可以在3GPP官网检索到TS 29.002是MAP的基础规范CAMEL的CAP在TS 29.078里。做核心网联调时去3GPP官网找原始规范比看二手参数表靠谱得多因为微小的字段顺序错误在现网里就是一条闭塞电路。协议变体选型要跟着现网走而不是跟着代码习惯走。国内运营商之间的信令网基本是ITU-T变体但接海外运营商或某些企业网关时ANSI变体的出现频率不低。拿到一个样本包先用tshark解一条ISUP消息看CIC字段解出来是否合理再决定后面整份文件按什么变体处理。Wireshark里可以在Telephony偏好设置里切换点编码格式和协议变体改完之后所有已加载包的解码结果会立即刷新。4.3 SIGTRAN承载下的配置SCTP偶联与M3UA的联动SS7不一定要跑在TDM链路上SIGTRAN让M3UA、M2UA这些适配层跑在SCTP之上IP网络承载SS7消息。这时候联调参数多了一层SCTP偶联、M3UA的本地/远端路由上下文。SCTP偶联状态可以用lksctp-tools里的ss命令或者netstat -anp | grep sctp查看确认偶联是ESTABLISHED而不是COOKIE_WAIT。M3UA层要配置的是本地信令点编码和对端信令点编码以及路由上下文Routing Context。实际项目中最常见的错误是M3UA配好了、SCTP也通了但消息到对端后对端不知道往哪个应用层送上因为路由上下文不匹配。排查时可以抓SCTP端口2905的包看M3UA的DAFT和Notification里有没有给明确的错误原因码Wireshark对M3UA的支持已经比较成熟错误原因可以直接看到。4.4 联调时最小可验证配置清单我一般直接把联调流程拆成一个检查清单每项通过再往下走物理链路或IP链路通如果是SIGTRANsctp偶联状态为ESTABLISHED如果是TDMMTP2状态为in service。MTP3层能否互发管理消息用SLTM/SLTA测试消息确认链路可用对端应回复SLTA。SCCP路由是否可达发起一个TCAP的Ping类操作看对端是否回ReturnResult。ISUP呼叫回路用测试号码发起一次呼叫观察IAM、ACM、ANM的完整交互。事务定时器检查TCAP的对话超时时间、ISUP的T1定时器配置要与对端对齐否则会出现一端已经释放、另一端还在等消息的死等。这套清单的价值在于把看起来通了和真的能承载业务分开。很多联调卡在第四步前两步全通但IAM发过去没反应这时候回头查OPC/DPC或者SIO往往能快速定位。5. 避坑SS7协议分析里最常见的五个翻车现场5.1 现象抓包文件打开全是黑色原始比特流连LSSU都看不到原因Wireshark把包当成了普通以太网/UDP负载没有启用SS7相关解析器。这最常见于SIGTRAN承载的抓包样本Wireshark没识别出SCTP端口对应的M3UA/M2UA。解决不要硬看十六进制先用capinfos确认Link type再通过Decode As把对应端口指认为mtp3或m3ua。tshark的命令行做法是-d sctp.port2905,mtp3把2905端口的SCTP载荷按MTP3解析。5.2 现象过滤isup一条消息都没有但抓包时确实看到了IAM原因ISUP消息可能因为MTP3层SIO字节的解码不正常导致Wireshark把业务指示语识别成未知从而挂不上ISUP解析器。另一种常见情况是消息不是标准MTP3封装而是直接从ISUP层开始抓的裸包。解决先解一个包看MTP3的Service indicator值如果是5就手动强制按ISUP解如果MTP3都没有就检查是不是抓包位置在TDM链路的物理层需要从MTP2开始启用解析器。5.3 现象OPC/DPC显示成0.0.0或者巨大的异常数字原因Wireshark默认的点编码格式和样本实际格式不匹配。ITU-T格式3-8-3显示为三段数字ANSI 24位也是三段数字但位宽和掩码完全不同用错格式后解码出来的地址完全没有意义。解决在Wireshark里进入Telephony偏好设置把点编码格式调成和样本一致命令行批处理时用-o参数指定mtp3.pc_format这个参数的具体取值在不同版本里叫法不同先tshark -G default查一下可用值。5.4 现象TCAP事务对应不起来同一对话的Invoke和ReturnError被拆开显示原因样本跨了多条信令链路抓取同一事务的消息走了不同SLS分析工具没做链路聚合导致TCAP层关联失败。IMEI鉴权、位置更新这类业务在正常负荷分担下就可能走不同链路抓包点如果不在一处根本拿不到完整对话。解决尽量在单条链路上抓包或者把多链路抓包的样本合并前先按时间校准再人工确认同一次对话的消息是否出现在同一OPC/DPC对。Wireshark里看TCAP时打开Preferences - Protocols - TCAP - Reassemble这个选项能缓解但不解决根本的跨链路问题。5.5 现象tcpreplay回放后对端一直报事务超时原因样本文件时间跨度大tcpreplay默认按文件里的相对时间戳加速回放几小时的包几秒就发完了上层协议的对话定时器全部被触发超时看起来就像全网故障。解决回放时限制速率--pps设成样本实际速率的1到2倍或者用--multiplier把回放倍速设成0.5这种慢速。更严谨的做法是用editcap先把样本做时间过滤只截取其中一段完整呼叫流程再把这段流程循环回放这样既不会超时也方便反复验证。6. 验证一份SS7分析结果靠不靠谱三个必做的手工校验分析工具给出的消息列表不一定等于真实信令互动。踩过几次坑之后我现在每份样本做完分析都会做三个手工校验。第一个是CIC一致性校验。一次普通呼叫的IAM、ACM、ANM、REL、RLCCIC必须完全相同SLS也必须相同如果工具里同一呼叫CIC对不上基本是抓包跨链路或者解码变体选错了。用一条tshark命令把CIC字段按时间打印出来肉眼扫一遍就能发现异常。第二个是MTP2层的序号连续性校验。一条正常链路上MTP2的FSN是连续递增的中间出现跳变说明抓包有丢包可能是抓包软件缓冲区溢出也可能是链路本身在重发。顺序校验用tshark导出mtp2.fsn字段把它和包序号做差差值不稳就说明样本本身不可靠后面任何分析结论都要打折扣。第三个是信令方向校验。IAM从主叫侧信令点发出、指向被叫侧REL应该反向。如果一份样本里IAM和REL都是从同一个OPC发往同一个DPC那说明要么抓到了两个方向的包混在一起没分类要么分析的议题本身就不是单次呼叫。这三个校验看起来基础但能过滤掉大量工具误判。我第一次搭SS7抓包环境时看着满屏原始比特流第一反应是怀疑抓包工具有问题后来才发现是点编码格式和解码规则没设置。现在每拿到一份新样本我会先把样本链路类型、协议变体和点编码格式写进工作笔记开头再逐层展开。希望帮到你。本文还有配套的精品资源点击获取 SS7七号信令协议栈详解：从MTP到ISUP的抓包与信令分析实战
简介SS7七号信令协议学习资料包以图片和网页文档形式系统整理了Signalling System No.7的核心内容覆盖从MTP底层传输到SCCP、TCAP上层应用的完整协议栈适合电信行业从业者、通信专业学生及协议研究者作为入门与进阶参考。压缩包内共607个文件包含465个jpg图片、138个htm网页文档、3个html及1个txt说明文件总大小仅3.43MBjpg图片直观展示信令消息格式、网络拓扑与流程示例htm文档则系统讲解MTP消息传递部分、SCCP信令连接控制、TCAP事务处理等各层功能。内容进一步涉及SS7网络架构、信令点与转接点配置、SCCP端到端连接、TCAP智能网应用、SS7与IP网络融合方案以及安全漏洞防护要点并配有实例分析举例说明呼叫建立、路由选择与计费场景有助于读者理解七号信令在现网中的实际运作机制。已有371人学习下载该资料包以图文结合的方式降低了协议学习门槛适合需要系统梳理信令知识的通信工程师与研究人员收藏使用。1. 为什么一套40年前的协议还在调度今天的电话与短信SS7与七号信令调试间里堆着三台信令服务器指示灯全绿但电话就是接不通。应用层日志没有任何报错最后用抓包工具盯了十分钟发现ISUP的IAM消息压根没从MTP3层交出去。这种时候你会意识到SS7七号信令这套协议栈虽然诞生于模拟电话时代今天依然在核心网里承担着呼叫建立、计费、漫游、短信投递这些最底层的信令调度。它和常说的7层协议模型不冲突它本身就是电信网自己的另一套七层——只不过每一层的历史包袱都还在。这篇文章不聊教科书定义而是从拿到一份SS7协议样本包之后怎么解析、怎么看参数、怎么踩坑出发把链路层、网络层、业务层一条线走通。适合正在做核心网联调、网关对接、信令分析平台的工程师也适合刚接触七号信令想快速上手抓包排查的人。2. 拆开SS7协议栈从MTP到TCAP每一层在信令流程里做什么2.1 四层结构里每一层完成什么任务SS7不是单一协议是一个协议族ITU-T Q.700系列把它组织成分层结构。最底下是MTP1处理物理层要么是E1/T1的时隙要么是经过SIGTRAN映射到IP承载。MTP2是链路层负责帧定位、差错检测、重发和流量控制类似TCP里确认与重传那套机制但用的是信令单元的格式。MTP3是网络层负责信令点之间的路由和流量管理消息根据DPC目的信令点编码转发相当于IP层加一部分路由协议的功能。MTP3之上挂了若干用户部分。ISUP负责电路相关信令比如一次普通电话呼叫的建立和释放消息类型有IAM、ACM、ANM、REL、RLC这是做呼叫分析最常接触的一层。SCCP信令连接控制部分在MTP3之上提供类似端口号的寻址能力通过子系统号SSN找到GT全局标题对应的业务TCAP事务能力应用部分承载的MAP、CAP这类移动网业务以及智能网业务都跑在SCCP之上。TUP是更老的回路线路控制协议在不少现网里已经被ISUP取代了遇到老样本包时偶尔还能看到。分层之间的关系不是严格的下层为上层服务那么简单。ISUP和SCCP都挂在MTP3之上ISUP关注的是电路SCCP关注的是事务。TCAP本身不管电路它只负责把一次远端操作的调用和返回对应起来像MAP里的位置更新、短信发送、鉴权请求都是通过TCAP的Invoke和ReturnResult完成的。理解这个分层抓包时才能一眼看出问题在哪个层MTP2的FSN不连续是链路问题ISUP的IAM没响应是呼叫控制问题TCAP的事务超时是应用层问题。2.2 信令点编码、子系统号与链路类型分析前必懂的三个概念信令点编码SPC是SS7网络里每个节点的地址常见的有ITU-T 14位格式和ANSI 24位格式写出来像3-128-1或1.2.3这样。抓包时OPC是源信令点编码DPC是目的信令点编码很多分析工具默认按ITU-T格式显示遇到ANSI的包会显示成很奇怪的大数字这就是最常见的看着地址不对其实解码格式错了的翻车点。子系统号SSN是SCCP层的地址扩展类似TCP端口号比如移动用户就是SSN 6MAP的各个服务有各自的SSN。还有SLS信令链路选择码它决定消息走哪条链路同一对OPC/DPC之间的同一次会话SLS必须保持一致消息才能按序到达。业务指示语SI在SIO字节里ISUP是SI5SCCP是SI3抓包过滤时用得上。链路类型也直接影响分析。A链路连接两个信令点B链路连接从属信令点与转接点C链路连接两个转接点D链路是准直联的延伸E链路是跨网络冗余。实际抓包时不一定要分清所有类型但要知道A/B/C/D/E中同一条链路上的消息顺序是可靠的跨链路汇聚过来的消息顺序不保证后面分析TCAP事务时这很关键。2.3 用tshark验证你手上的包来自哪一层拿到一份未知样本先别急着看懂内容先用工具确认链路类型和解码层级。这步非常建议做能省掉后面大量盲猜的时间。capinfos sample.pcap | grep -E Link type|Number of packets tshark -r sample.pcap -c 5 -V 2/dev/null | grep -E Message type|Service indicator|Destination point code|Source point codecapinfos输出的Link type如果是ss7说明抓包时已经指定了SS7链路类型Wireshark会自动挂上MTP2解析器。如果显示ETHERNET或者USER0说明包是裸IP承载或者链路类型没标对后面要么手动指定decode as要么重新抓包。第二条tshark命令取前5个包直接看MTP3层的Destination point code和Service indicator能快速判断样本是ISUP为主还是MAP为主。这个习惯帮我省掉了很多打开包发现一片黑的尴尬时间建议养成。3. 用Wireshark和tshark把SS7样本包拆成信令流程过滤、导出与重放3.1 解压样本先验明文件身份rar压缩包与pcap的边界标题里带了rar_protocols实际工作中拿到的协议样本经常是rar或zip压缩好的pcap解压后第一件事不是双击打开而是确认文件格式和链路类型。rar解压本身没什么技术含量重点是解压后别被文件名骗了一个叫SS7_trace.pcap的文件里面可能是普通的UDP封装也可能是真正的TDM链路采集。unar SS7_Protocols.rar # 如果系统里没有unar换成 unrar x SS7_Protocols.rar file sample.pcap capinfos sample.pcap | grep -E Link type|Capture length|Number of packetsfile命令确认pcap格式是pcap还是pcapngcapinfos是关键它告诉你这个文件的链路层类型。如果Link type是ss7可以直接用Wireshark按SS7解析如果Link type是ETHERNET且包里带着SCTP源端口2905说明是SIGTRAN承载需要按SCTP/M3UA路径解析。这一步确定了后面的过滤条件和协议变体选型才能选对。3.2 用过滤语法拆出ISUP与TCAP先看消息类型再看参数Wireshark的显示过滤器对SS7支持得不错关键是记住几个固定的过滤字段。只看MTP3层就用mtp3只看ISUP就用isup想看TCAP里的MAP操作就用tcap这些字段在Wireshark的Protocol列表里都能看到但命令行跑批处理时用tshark更顺手。# 列出所有ISUP消息类型及各类型数量 tshark -r sample.pcap -Y isup -T fields -e isup.message_type | sort | uniq -c | sort -rn # 按消息类型导出关键字段源点编码、目的点编码、SLS、CIC tshark -r sample.pcap -Y isup -T fields -e mtp3.opc -e mtp3.dpc -e mtp3.sls -e isup.cic -E headery -E separator,isup.message_type在Wireshark里显示为IAM、ACM、ANM这类可读字符串导出后做统计非常直观。mtp3.opc和mtp3.dpc是MTP3层的源点和目的点编码isup.cic是电路识别码这是把一次呼叫串起来的核心字段。注意不同版本Wireshark的字段名可能略有差异跑之前可以用tshark -G fields先确认字段名这个技巧能避免拿到一堆空值。3.3 用tcpreplay在本地回放控制速率比控制内容更重要抓包文件要在测试环境回放常见做法是用tcpreplay。直接默认参数回放有两个坑一是样本包可能是几小时甚至几天的采集tcpreplay会在一瞬间全部发完二是SS7样本的链路类型不是以太网时tcpreplay会报错。# 限速回放不要全速突袭 tcpreplay --pps50 -i lo sample.pcap # 如果样本链路类型不是以太网先指定数据链路类型再回放 tcpreplay --pps50 --dltss7 -i lo sample.pcap--pps50意思是每秒最多发50个包适合让上层状态机有足够时间处理事务。--dltss7是告诉tcpreplay样本原始链路类型是SS7避免回放时被当成普通以太网帧拆解出错。如果目标是复现真实信令流量压力可以把pps调大但如果目的是验证业务流程建议从低速率开始观察对端有没有超时重发再慢慢往上加。回放时可以同时起Wireshark抓回环口用-L参数确认接口支持什么链路类型。3.4 用Python按消息类型粗筛把几千个包变成一张直方图tshark做过滤已经很快但需要做更复杂的统计、按呼叫维度聚合、或者把结果接进自研平台时Python是绕不开的。我最常用的是pyshark它封装了tshark的解析能力可以当对象用比直接调用命令行更好处理结构体。import pyshark # 只加载ISUP层keep_packetsFalse避免把整包内容全部保留在内存 cap pyshark.FileCapture( sample.pcap, display_filterisup, keep_packetsFalse, ) count {} for pkt in cap: try: mt pkt.isup.message_type count[mt] count.get(mt, 0) 1 except AttributeError: # 个别包虽然有isup过滤命中的字段但层对象不完整跳过 continue print(sorted(count.items(), keylambda x: x[1], reverseTrue))pyshark的display_filter在FileCapture初始化时就传给tshark比逐个包再判断效率高得多。pkt.isup.message_type是字符串直接可以做分类统计。注意keep_packetsFalse这个参数不做深层引用时尽量打开否则几万包的文件内存占用会非常难看。AttributeError捕获的是那些在ISUP层解到一半但字段不齐全的包这类异常在混合流量里很常见不要让它中断整个循环。注意pyshark依赖tshark的可执行路径跑之前先确认tshark在系统PATH里否则FileCapture会直接抛ExecutableNotFound。4. 七号信令联调参数OPC/DPC、SLS、定时器与协议变体怎么配4.1 链路参数速查表这些参数填错了信令根本不通联调SS7网络时最常打交道的参数就那几个。整理成表格方便对照检查参数作用常见取值/格式填错时的表现OPC/DPC源/目的信令点编码ITU-T 14位点分式如3-128-1ANSI 24位消息被对端丢弃没有任何响应SIO服务信息八位组含子业务字段和业务指示语ISUP固定SI5SCCP固定SI3Wireshark能解出包对端协议栈不认SLS信令链路选择码值范围0~15或0~31同一呼叫需相同消息乱序ISUP呼叫建立失败CIC电路识别码16位ITU-T变体或12位ANSI变体呼叫与被叫电路对不上REL放错电路SSN子系统号MAP用6HLR、VLR各有定义SCCP路由失败TCAP请求无响应OPC/DPC配置错误是最难排查的一类问题因为现象和网络故障很像两边链路都显示正常但消息发出去石沉大海。我遇到过一对OPC配置反了的案例抓包看MTP3层地址完全反了对端协议栈直接把它们当成来自错误信令点的消息丢弃了。所以联调第一步不是看业务而是核对两端SPC表、SIO和SLS是否匹配。4.2 ISUP、MAP与协议变体ITU-T和ANSI真的不能混用ISUP协议有两个主要变体ITU-T Q.763和ANSI T1.113。两者在消息格式、参数编码和CIC位宽上有明显差异混用的结果是消息能解出来但关键参数错位比如把IAM里的被叫号码读成了一串乱码。移动核心网里的MAP协议跑在TCAP上规范可以在3GPP官网检索到TS 29.002是MAP的基础规范CAMEL的CAP在TS 29.078里。做核心网联调时去3GPP官网找原始规范比看二手参数表靠谱得多因为微小的字段顺序错误在现网里就是一条闭塞电路。协议变体选型要跟着现网走而不是跟着代码习惯走。国内运营商之间的信令网基本是ITU-T变体但接海外运营商或某些企业网关时ANSI变体的出现频率不低。拿到一个样本包先用tshark解一条ISUP消息看CIC字段解出来是否合理再决定后面整份文件按什么变体处理。Wireshark里可以在Telephony偏好设置里切换点编码格式和协议变体改完之后所有已加载包的解码结果会立即刷新。4.3 SIGTRAN承载下的配置SCTP偶联与M3UA的联动SS7不一定要跑在TDM链路上SIGTRAN让M3UA、M2UA这些适配层跑在SCTP之上IP网络承载SS7消息。这时候联调参数多了一层SCTP偶联、M3UA的本地/远端路由上下文。SCTP偶联状态可以用lksctp-tools里的ss命令或者netstat -anp | grep sctp查看确认偶联是ESTABLISHED而不是COOKIE_WAIT。M3UA层要配置的是本地信令点编码和对端信令点编码以及路由上下文Routing Context。实际项目中最常见的错误是M3UA配好了、SCTP也通了但消息到对端后对端不知道往哪个应用层送上因为路由上下文不匹配。排查时可以抓SCTP端口2905的包看M3UA的DAFT和Notification里有没有给明确的错误原因码Wireshark对M3UA的支持已经比较成熟错误原因可以直接看到。4.4 联调时最小可验证配置清单我一般直接把联调流程拆成一个检查清单每项通过再往下走物理链路或IP链路通如果是SIGTRANsctp偶联状态为ESTABLISHED如果是TDMMTP2状态为in service。MTP3层能否互发管理消息用SLTM/SLTA测试消息确认链路可用对端应回复SLTA。SCCP路由是否可达发起一个TCAP的Ping类操作看对端是否回ReturnResult。ISUP呼叫回路用测试号码发起一次呼叫观察IAM、ACM、ANM的完整交互。事务定时器检查TCAP的对话超时时间、ISUP的T1定时器配置要与对端对齐否则会出现一端已经释放、另一端还在等消息的死等。这套清单的价值在于把看起来通了和真的能承载业务分开。很多联调卡在第四步前两步全通但IAM发过去没反应这时候回头查OPC/DPC或者SIO往往能快速定位。5. 避坑SS7协议分析里最常见的五个翻车现场5.1 现象抓包文件打开全是黑色原始比特流连LSSU都看不到原因Wireshark把包当成了普通以太网/UDP负载没有启用SS7相关解析器。这最常见于SIGTRAN承载的抓包样本Wireshark没识别出SCTP端口对应的M3UA/M2UA。解决不要硬看十六进制先用capinfos确认Link type再通过Decode As把对应端口指认为mtp3或m3ua。tshark的命令行做法是-d sctp.port2905,mtp3把2905端口的SCTP载荷按MTP3解析。5.2 现象过滤isup一条消息都没有但抓包时确实看到了IAM原因ISUP消息可能因为MTP3层SIO字节的解码不正常导致Wireshark把业务指示语识别成未知从而挂不上ISUP解析器。另一种常见情况是消息不是标准MTP3封装而是直接从ISUP层开始抓的裸包。解决先解一个包看MTP3的Service indicator值如果是5就手动强制按ISUP解如果MTP3都没有就检查是不是抓包位置在TDM链路的物理层需要从MTP2开始启用解析器。5.3 现象OPC/DPC显示成0.0.0或者巨大的异常数字原因Wireshark默认的点编码格式和样本实际格式不匹配。ITU-T格式3-8-3显示为三段数字ANSI 24位也是三段数字但位宽和掩码完全不同用错格式后解码出来的地址完全没有意义。解决在Wireshark里进入Telephony偏好设置把点编码格式调成和样本一致命令行批处理时用-o参数指定mtp3.pc_format这个参数的具体取值在不同版本里叫法不同先tshark -G default查一下可用值。5.4 现象TCAP事务对应不起来同一对话的Invoke和ReturnError被拆开显示原因样本跨了多条信令链路抓取同一事务的消息走了不同SLS分析工具没做链路聚合导致TCAP层关联失败。IMEI鉴权、位置更新这类业务在正常负荷分担下就可能走不同链路抓包点如果不在一处根本拿不到完整对话。解决尽量在单条链路上抓包或者把多链路抓包的样本合并前先按时间校准再人工确认同一次对话的消息是否出现在同一OPC/DPC对。Wireshark里看TCAP时打开Preferences - Protocols - TCAP - Reassemble这个选项能缓解但不解决根本的跨链路问题。5.5 现象tcpreplay回放后对端一直报事务超时原因样本文件时间跨度大tcpreplay默认按文件里的相对时间戳加速回放几小时的包几秒就发完了上层协议的对话定时器全部被触发超时看起来就像全网故障。解决回放时限制速率--pps设成样本实际速率的1到2倍或者用--multiplier把回放倍速设成0.5这种慢速。更严谨的做法是用editcap先把样本做时间过滤只截取其中一段完整呼叫流程再把这段流程循环回放这样既不会超时也方便反复验证。6. 验证一份SS7分析结果靠不靠谱三个必做的手工校验分析工具给出的消息列表不一定等于真实信令互动。踩过几次坑之后我现在每份样本做完分析都会做三个手工校验。第一个是CIC一致性校验。一次普通呼叫的IAM、ACM、ANM、REL、RLCCIC必须完全相同SLS也必须相同如果工具里同一呼叫CIC对不上基本是抓包跨链路或者解码变体选错了。用一条tshark命令把CIC字段按时间打印出来肉眼扫一遍就能发现异常。第二个是MTP2层的序号连续性校验。一条正常链路上MTP2的FSN是连续递增的中间出现跳变说明抓包有丢包可能是抓包软件缓冲区溢出也可能是链路本身在重发。顺序校验用tshark导出mtp2.fsn字段把它和包序号做差差值不稳就说明样本本身不可靠后面任何分析结论都要打折扣。第三个是信令方向校验。IAM从主叫侧信令点发出、指向被叫侧REL应该反向。如果一份样本里IAM和REL都是从同一个OPC发往同一个DPC那说明要么抓到了两个方向的包混在一起没分类要么分析的议题本身就不是单次呼叫。这三个校验看起来基础但能过滤掉大量工具误判。我第一次搭SS7抓包环境时看着满屏原始比特流第一反应是怀疑抓包工具有问题后来才发现是点编码格式和解码规则没设置。现在每拿到一份新样本我会先把样本链路类型、协议变体和点编码格式写进工作笔记开头再逐层展开。希望帮到你。本文还有配套的精品资源点击获取