Appearance
Appearance
很久以前,一名从程序员转为故障排查人员、又转为系统管理员的人(就是我)发现自己必须过滤一些测试呼叫,这些呼叫是几位同事在测试新手机时通过他负责的网关系统发起的。
使用 ISUP、MEGACO、Q931、H225、H245 过滤呼叫是一项令人厌烦且缓慢的工作。我必须先根据主叫号码过滤 setup,一旦知道使用了哪个 circuit,就必须创建一个新的过滤器,把该呼叫的其他部分也加进去;由于捕获文件非常大,所有这些过滤和重新过滤都非常慢。这项任务相当机械化,是可以告诉计算机如何去做的事情。作为程序员,我自然决定写一个程序来替我完成。我从 perl 开始,从 CPAN 获取了一些模块,写了一组非常简单的 SCTP、Q931、MEGACO 和 ISUP 解码器(惭愧的是它们到现在还不在 CPAN 里!)。有了这些组件后,我写了一个相对简单的应用程序,把一个大的捕获文件拆分成单个呼叫的文件。
ugly_call_splitter.pl
这个 “ugly call splitter” 工作了几个月;过了一段时间,它被修改为能做更多事情(比如计算呼叫的保持时间)。有一天,一项新服务使通过网关的流量增加到了此前的大约 100 倍。到那时,ugly call splitter 已经不堪重负(更不用说它的作者了)。许多情况会让它失败,例如单个 SCTP packet 中有更多 ISUP PDUS,TCP 中的 Q931 也有同样情况;这些问题很容易解决,但有一个问题是该程序从未需要按每个呼叫处理的:H225 RAS 问题。
ugly call splitter 也需要解码 RAS packets,于是我去 CPAN 里搜寻,找到了 Decode::BER。不幸的是(对其他人来说也许是幸运的),我就是无法让该模块编译 H225 语法。那时我决定把 ugly call splitter 重写到 Wireshark 中,因为 Wireshark 已经能处理 H225。
我已经很多年没有写过 C 了,除了零星写几个补丁。此前我曾接触过 Wireshark 源代码,是为了帮助一位同事,他需要根据当时还不能过滤的一些属性来过滤 radius packets。我还想做的另一件事是恢复我的 C 能力;随着多年没有真正使用它,我的 C 水平正在退化。
第一次尝试没有名字。我采用了和 ugly call splitter 完全相同的方法,也就是用一整组 hash 来保存它收集到的信息,这些信息由 dissector 中的代码在被调用时创建 pdus。先从 ISUP 开始很容易,加入 Q931 稍微困难一些,H225 让我意识到我需要一种通用方法,能适配我想添加的每一种协议,于是我决定第一次重写它。
第二次尝试叫做 ECTAF(Ethereal Call Tracing and Analysis Facility);AVPs 和 AVPLs 构成了它所需的“通用方法”;有一个单一的数据结构保存与 PDUs 和 LEGs 相关的信息(在我为它找到好名字之前,我暂时把那个“东西”称为 thing),而它的大部分逻辑由 PDUs 和 LEGs 之间的 AVPL 操作组成。下一次转变是由于加入 MEGACO;我需要给 ECTAF 一种方式来导入 ISUP CICs 与 MEGACO Terminations 之间的映射表,为此我写了一个 AVPL parser。等我完成 parser 时,我注意到一件事:匹配逻辑是用 AVPLs 做的,而我有一个 AVPL parser……如果我从配置文件导入匹配逻辑会怎样?
第三次尝试叫做 STTF(Session and Transaction Tracing Facility),正是围绕这一点展开:从配置文件导入匹配逻辑。我继续把 PDU extraction 代码直接硬编码到相关 dissectors 中,直到有人告诉我还必须处理 SIP;除此之外,当时我还在帮助其他同事处理他们的系统,并注意到这种通用方法也可以用在 VoIP 范围之外,我只是需要能够在配置文件中告诉程序如何导入 PDUs。
第四次尝试叫做 TTT(Transaction Tracking Thing),后来简称为 “Thing”,重点就在于使用配置文件告诉它如何导入 PDUs,告诉它同一协议的 PDUs 如何相互关联,以及 PDUs 的 Groups 如何相互关联。这是这个东西的第一个发布版本。
我开始喜欢 “Thing” 这个名字,于是就以 Thing 的名字发布了它。后来名字改成了 MATE(根据 Ronnie Sahlberg 的提议)。随着这个 “Thing” 被公开,我听说了一些更好的实现方式,也因为几个问题注意到它缺少一些功能,于是我回到代码中,添加了一些功能,使它可以用于非电话协议。
未完待续……
Luis Ontanon
导入自 https://wiki.wireshark.org/Mate/Accident,时间为 2020-08-11 23:16:30 UTC