Caton Media Xstream: 重新定义实时内容交付服务

编者按：随着公共互联网愈加复杂，best effort的基本原型已无法满足越来越多的有QoS保障需求的实时内容交付服务。而专线、卫星等传统解决方案存在部署成本高、周期长等问题，无法快速响应各类需求。LiveVideoStackCon邀请到了科腾科技的魏凌，为我们介绍Caton Media Xstream平台的解决方案。

文/魏凌

编辑/LiveVideoStack

大家好，我是来自科腾科技的魏凌。今天，我分享的是科腾科技新推出的一个实时内容交付服务平台，Caton Media Xstream。

科腾科技是一家以技术为核心驱动力的高科技公司，一直致力于为客户提供下一代IP网络高质量传输的完整解决方案，包括编解码器，大文件传输，IP分发等多项服务；我们相信通过IP网络的力量能够实现人与人，人与物，以及物与物之间全方位，高质量的实时交互，将世界连接在一起。今天，我分享的就是科腾新推出的服务平台Caton Media Xstream。我将从多个维度介绍该平台特点和背后的相关技术。

-01-

背景介绍

第一部分是背景介绍，包括互联网现状，挑战以及Caton Media Xstream的特点。

首先，我先介绍下为什么要做这么个平台，做这个平台是为了解决什么样的问题，这也是该平台存在的意义。

公共互联网发展至今，已经越来越复杂。其复杂性具体表现在几个方面：

一、当今公共互联网是由数量巨大，独立运营，通过Peering协议互相连接的ISP网络构成； 截止2021年3月，全球拥有超过99868个ISP运营商，且还在持续增长。ISP供应商可以大致分为三级，tier 1 ISP主要提供长距离的跨域网络连接，例如美国的GTT等；tier 2 ISP提供大区内网络连接覆盖,例如Cogent等; tier3 ISP提供最后一公里的网络连接覆盖，例如台湾的FET等；

二、如此多的ISP运营商之间的流量传输，会使用BGP路由进行传输，不同ISP之间有各种不透明的peering协议；我们可以了解到的就有不少原则，例如第一运营商会优先使用已经付费的连接；第二热土豆路由，供应商总是希望快速卸载数据包给其他的ISP网络；第三，有时候会为了获取更大的经济效益选择绕路；这些问题，都会导致公共互联网之间的基础协议和设施无法做到全球统一管理，来保证高质量的数据传输。

我们来看两个典型的在互联网传输中存在的具体问题。

一是频发的网络故障。有报告显示，2022年底，平均每周全球发生网络故障300次左右，特别是在美国，达到90次左右；这些网络故障随时都可能发生在正在传输的业务流的路径上；

二是ISP之间所谓的最佳路径，往往并不可靠，且无法控制。例如我们在某个真实的业务中发现，都是在日本东京的两个ISP网络，传输的延迟达到了将近200ms，我们用工具追踪路径发现，两个ISP的peering节点在美国，所以流量会通过美国绕一圈，导致延迟变大了将近100倍。

虽然网络面临的问题越来越多，但是我们对公共互联网的需求却越来越大。特别是广播级音视频传输领域，其对网络传输质量要求越来越高，这也是目前公共互联网要面临的最大挑战。

首先，从业务上，广播级大码率流媒体传输场景呈爆发式增长；例如7*24小时的专业媒体频道，专业体育赛事直播，远程演唱会和影院，远程医疗等等。

这些业务对网络传输的质量要求极高。包括高带宽，高可靠，低延迟，抗抖动的网络要求，还有长距离，高清晰度的业务要求。甚至，针对广播级视频流，需要保证的不是用户主观观感上无感知，而是从真实的数据包统计上没有出现任何CC ERROR（CC ERROR是针对广播领域TS流的一项分析指标，即需要零丢帧），PCR(节目参考时钟)精度要求极高，都是纳秒级别。PCR是广电领域DVB流的一个基础时钟，一个作用是为了同步头端和终端的27M时钟，会影响色度平衡和帧率；还有一个重要的作用就是保障视频和音频的时间同步。我们公司可以恢复PCR精度小于500ns。

针对上面的场景和要求，广电领域传统的解决方案往往采用例如电路专线，MPLS专线，卫星传输等方式。

这些方案虽然可以保障3个9到5个9的高可靠性，但缺点也很明显，成本极高，比公共互联网成本贵100倍以上；部署周期长，有时候需要几个月甚至更长，无法灵活应对需求；最后，即使是专线或者卫星，也无法避免单点故障；

这些都是科腾科技在服务客户时客户反映的真实的问题。广电领域也在挑战利用IP网络进行传输专业流媒体，在降低成本的同时依然可以达到专线级别的传输质量。科腾科技一直深耕广播级专业流媒体传输领域几十年，也深刻地意识到该挑战是目前广播级IP网络长距离流媒体传输最大的痛点。

所以，针对上面提到的矛盾和痛点，目前很多流行的IP解决方案都是尝试从协议层进行优化，保障在IP网络上的高可靠传输，例如SRT，ZIXI协议等等。但科腾是从另外一个角度出发，提出了一个基于全新C3架构的广播级流媒体传输服务平台，不仅限于传输协议优化，而是从整个系统层面为用户提供低成本，高可靠，长距离的完整的传输解决方案。

简单列举一下平台的一些基本特性，包括：

（1）智能化，指的是智能路由策略和流量工程，高吞吐量，我们平台支持超高码率视频流传输；

（2）高可靠，可以达到端到端6个9的传输可靠性；

（3）低成本，基于全球网络基础设施进行混合部署的overlay核心网，成本是极低的；

（4）低延迟，支持超低延迟的QoS需求的流媒体传输；

（5）最后是灵活部署，平台积极拥抱云原生，可扩展性和灵活性极高，可以灵活满足客户的传输需求。我从中选取前三点与传输相关的特性进行展开阐述。

-02-

技术分享

第二部分是技术分享。我将介绍我们平台的三个特性，也是与传输质量和可靠性相关的技术点，包括智能路由策略，自研传输协议，端到端可靠传输三个方面。智能路由策略是实现高可靠传输QoS的基本保障。自研协议保障的是点到点的传输质量，最后一点则是保障端到端的可靠传输机制。三者是相辅相成，共同实现了我们平台6个9的传输可靠性。

首先是智能路由策略；Caton Media Xstream平台采用了基于双层决策的智能路由策略。

第一层，中心式的路径图规划。如果把业务数据包比喻需要传输至目的地的包裹，汽车是承载该包裹的载体，这一步就是帮汽车规划好所有可能准时送到目的地的公路拓扑网，并为每条可能的路径设置权重和优先级。这里面包含了三个部分：实时网络全景地图，MoDAG算法，以及基于流的QoS分级策略。

第二层，分布式的路由决策。路径图上的每个节点都会实时维护与邻居节点的网络质量，当汽车行驶到该节点时，根据当前收集的所有子链路的网络质量，以及预测各个链路的变化趋势，选择最佳的下一跳路径进行传输，遇到临时修路封路，类比网络故障，汽车可以自动换路，选择另一条路径送达目的地。目标就是让所有的包裹都可以在满足各自业务需求的情况下，以最高的效率安全到达目的地。

中心式在先，分布式在后，二者是协同工作的，共同实现高效率、高可靠的路由策略。

下面我将展开阐述这两层策略的细节。

首先是中心化智能路由策略，要想实现流量在全球范围内的最佳路径规划，首先必须掌握全链路的网络状态信息，即实时网络全景地图。如图所示，我们在全球范围内部署了多台网络服务器作为C3核心网的pop节点，会实时探测相互之间的网络质量信息并上报C3控制面；相信很多公司都能做到对自己自建的核心网络进行高效的监控和告警，但我们更进一步，不仅仅采集自建核心网之间的网络数据，还会探测并收集该地区其他可探测的ASN网络数据，构建一个真正聚合众多ASN网络质量数据的实时网络全景地图。这些大数据也为C3架构持续优化和迭代升级提供重要的大数据支撑。

下一步，就是将获取到的实时网络全景地图输入到计算算法MoDAG（多源有向无环图算法）中。

第一步是预处理。首先在原始的full mesh地图上，排除故障链路和故障节点。定义故障节点和故障链路并不是单纯地看该节点或者链路的状态是不是可用，而是要评估过去一段时间内链路和节点的稳定性，如果无法满足该流的QoS要求，也需要将其排除在外。

第二步是将探测到的多种指标，例如丢包率、RTT, Jitter等进行归一化，并根据数学模型进行量化，作为每个节点和链路的权重和成本。这里也是需要考虑QoS分级的策略的。

最后再考虑节点计算资源和带宽，对整体的核心网进行统筹规划，做好负载均衡，提高带宽和资源的利用率。

做好预处理过程，就会进入真正的规划算法。算法的细节不方便透露，但是其中需要满足的几点要求可以和大家分享一下。

第一个是不相交路径原则，即至少存在两条路从源端到目标端，它们不经过相同的网络节点。这里面其实还包含了显式不相交路径和绝对不相交路径。显式不相交指的是在overlay网络可见的节点不相交。绝对不相交路径指的是包括底层网络节点在内的节点不相交，这个需要对网络的实际传输路径有大量的数据支撑来实现。例如，国外访问国内的两个pop点，看似不相交，但其底层网络，有可能都是通过相同的入口进入国内的。

第二点就是涉及到图论里的最小割概念，最小割指的是一个有向图里存在的最小数量的路径。当这些路径断开之后，图的源和目标之间无法连通，这个数量就是最小割。路径规划需要满足最小割大于等于2，这也是为了避免单链路故障导致的断流。

第三点就是在满足所有条件下，基于经典的最短路径算法进行优化，实现多源多目标的有向无环图最短路径算法，并为每条子路径分配优先级。

最后，得到的MoDAG路径图会下发给核心网的边缘节点，指导流的实际传输。

接下来介绍一下前面提到的QoS分级策略。该策略是基于每个stream定义的QoS, 大致分为广播级音视频流，对可靠性要求极高。RTC音视频流，特别是涉及到交互的，对延迟要求高；文本数据流是完全可靠传输；远程制作的音视频流，对延迟和Jitter的要求高。

根据不同的类型，我们将其抽象成Loss, Delay, Jitter等指标的量化值，由这些值来指导平台的一系列操作，包括边缘覆盖节点的选择，MoDAG算法中的计算，负载均衡，成本优化等方面综合考虑，以达到最佳的平衡状态。

总而言之，中心化智能路由策略是输出一个最佳的路径有向无环图，并将结果通过平台下发给流的源端的边缘节点，用以指导该流的传输。

那么，每个节点是如何利用该路径图来进行转发数据包的呢？这就是我们路由的第二层，分布式智能路由策略。

每个节点会对路径图里给出的所有可能的子路径进行网络质量探测，来选择当前最佳的子路径进行转发流量。

因为在计算路径图的时候，采用的是历史网络质量数据，而网络质量其实是一直在变化的，所以这里的探测其实就是取当前最新的网络状态来决策，但是决策的选择范围是逃不开平台规划出的路径图的。这也是双层智能路由策略的核心所在。

节点的网络质量探测，会获取更多的基础和高阶指标，并根据QoS将获取的指标进行归一化和量化，自适应调整发送的一系列参数，例如ARQ，FEC，换路策略等。

在各个节点中，除了探测网络链路质量，我们还加入了链路预测模型。我们会利用滤波器来预测单条链路的变化趋势。同时，当链路出现故障时，我们会尝试去预测可能出现的故障，是源端出口网络、还是中间链路，或者目的地入口网络的问题。根据预测的结果，来选择是否切换网络、还是切换下一跳的目的地，抑或切换同个机房的另一个pop点。

从图上也可以看出，我们核心网的自建pop其实是一个多ISP、多服务器的结构，极大的降低了单点故障的概率，也可以在转发到不同目的地时，选择最佳的ISP路由，达到最佳的转发效果。

对于节点来说，无论是链路探测、还是链路预测，最后都会用于指导流量的转发，即路径的选择上。当遇到网络波动或者网络故障时，及时、没有任何丢帧错误的路径切换，才是我们的最终目标。

总而言之，分布式的智能路由策略，就是将决策权下发给各个节点，节点在前面提到的链路探测和链路预测的基础上，自主的选择最佳的下一跳子链路。这里最佳链路的定义是需要根据当前业务流的QoS等级进行区分的，例如有些业务流可能对丢包比较敏感，那么在决策时，Loss Rate的权重就会比较大；各个节点之间还支持同时协同工作，任何节点都可以作为其他节点选择的Relay Server，共同保障整个流端到端的可靠传输；最后，这种路径切换是数据包级别的，每次的切换都会在下一个数据包的转发中立即生效，而且可以做到接收端不丢失任何数据帧。

总结一下，我们的路由策略是双层决策协同工作来进行的，中心化的策略是根据全景网络拓扑和历史网络质量信息，为流规划出一个最佳的路径图。

每个节点在这个路径图中，会根据当前最新的网络状态信息来选择路由，拥有转发的最终决策权。只有这样，才能在满足QoS的情况下，更好地应对网络的突发状况，做出最及时的变化，达到零丢帧的自适应故障避免效果。

那么，在已经有了智能路由策略后，如何保障数据包在两个pop点之间的传输可靠性呢？这就是我分享的第二部分，我们自研的传输协议CTP。我们的CTP协议与很多新兴的多媒体协议一样，都是基于UDP之上，做一些可靠性传输机制的优化。基本上各个技术公司都会自研协议，加入一些最适合自身业务的一些特性，当然，我们也不例外。所以我就抛砖引玉，只展开讲讲其中几个针对我们系统优化的特性，希望能给大家一些启发，也欢迎大家一起讨论这部分传输协议的优化内容。

接下来我将从4个方面介绍CTP的主要特性。

首先就是HARQ算法。HARQ就是混合式自动重传请求，是一种结合FEC与ARQ的技术。我们根据收集的网络大数据，设计了40多种HARQ的模式和算法，其中重传机制我们采用的是nack机制，FEC采用的是线性分组码和喷泉码相结合的机制，在不同的场景下，会选择不同的参数和机制，用于适应不同的网络状态和链路类型。

图上是我们同事早期做的一个性能测试，对比了标准TCP的吞吐量，当在网络延迟为200ms时，吞吐量提高了62倍。当然，现在很多基于UDP的协议都能做到很高的吞吐量，但我们的CTP很早就将其应用于流媒体传输中，而且会根据多年积累的网络经验，不断去优化迭代该协议。

我们的第一代CTP推出的时间其实是早于目前流行的SRT协议的，而且比SRT更早实现了Multipath的功能。我们同事在B站上分享了关于CTP的性能测试，加入了SRT/RIST协议的对比测试，如果大家有兴趣，可以自行观看。

第二个是网络丢包模型的预测。网络丢包模型可以简单的分为三种模式，一种是拥塞丢包，表现为丢包相对比较集中；一种为随机丢包，丢包分布相对比较随机；一种为混合模式。我们利用改进的Spike算法进行丢包模式的识别，将结果应用于不同物理链路下的HARQ和拥塞控制算法中，对算法的参数进行一些自适应的修正。

这里主要的核心想法就是，在拥塞丢包情况下应该避免增加码率，这样只会加剧网络的拥塞。而如果是链路的随机丢包，则应该加快重传和FEC效率，提高接收端的接收成功率。二者对于发送端来说，其实是完全不同的发送策略。如何提高预测的准确性，也是我们一直在优化的方向。

第三点就是经典的拥塞控制的算法。我们参考了WebRTC中的GCC算法，设计了优化的多源拥塞控制算法；大致的流程大同小异，包括探测，分析，结果，应用四个部分。

在我们的自研协议CTP中，主要的特点是一方面会将前面提到的丢包模式的结果应用到拥塞控制的分析模块进行优化；另一方面，我们基于C3系统的多源多目标的架构特性，在应用模块，针对性地做出了一些策略优化。多源多目标的架构我会在第三部分展开描述。对于拥塞控制的研究我们也一直有在进行。

最后一点，是网络编码。网络编码这个概念其实早在2000年提出，将传统的路由器引入编码功能，以提高信息的传输效率。图上是经典的解释网络编码原理的网络结构：蝴蝶网络，即假设每个链路每个时刻只能传输一个数据包。传统的发送方式，由于中间瓶颈链路的存在，两个接收端无法同时收到两个数据包。但如果每个节点加入了网络编码，就可以利用重编码功能实现同时接收，实现网络传输效率的提高。在我们的C3 overlay核心网pop点中，天然地支持编码功能，这也是我们引入该技术的基础所在。我们在某些要求超低延迟和抖动的业务场景中率先落地了网络编码功能，实现了很好的传输效果。对于其他业务场景，我们也在积极探索网络编码的潜力，优化网络传输质量。

我们对第二部分自研协议做个简单总结。其实协议只是传输中的一小部分，目前也有很多类似的协议应用于各种场景中，比如QUIC协议，SRT，ZIXI等多媒体传输协议等等。我们的自研协议是在C3架构上做出的我们认为最合适的优化策略。当然，我们也会持续地在这方面进行优化。

最后一部分，也是C3架构保障端到端高可靠传输的机制介绍。这部分我将从First-Last-mile的数据接入和middle-mile的核心网传输机制两方面展开描述。

First-Last-mile主要解决的是用户侧的数据如何高可靠的接入C3核心网。我们采取的策略有多边缘节点覆盖，双多径传输以及包级别的自适应路径切换三种机制共同保障。

Middle-mile主要解决的是长距离传输过程中遇到的网络波动和突发的网络故障。如何高效地、接收端零丢帧地避开有问题的链路，保障数据可靠的传输至接收端。

我也将介绍其中三种主要的机制，包括边缘聚合机制，反流避障机制以及无损在线升级机制。

我们来看First-Last-mile的第一点，多边缘节点覆盖。我们为每个用户端的每个ISP接入选择至多3个节点进行覆盖，无论是发送端还是接收端；匹配的原则会尽量满足混合pop覆盖，即保证有云主机pop点和自建机房pop点同时覆盖；云主机主要是考虑其稳定性，自建机房主要考虑的是成本和带宽。

第二是智能的分配策略，主要包含了服务器冗余原则，即两地三中心原则，三个边缘节点至少位于两个地方，三个不同的机房中心，ISP冗余原则（在匹配用户端ISP的前提下，选择多个ISP进行覆盖，同时我们还考虑了不同等级的ISP运营商的覆盖特点，以及根据历史大数据，自动筛选出最佳的ISP匹配）。当然，我们需要考虑负载均衡，平衡效率和成本之间的关系；最后一点是支持白名单和黑名单的功能，主要是为了一些用户自带的pop点时，可以满足定制化边缘覆盖的需求。

当用户侧也采用双网卡传输，每个网卡会分配三个边缘节点覆盖，此时有多达6条子链路可以使用，在带宽不足的情况下，自动启用带宽聚合功能，最大程度的保障用户所有流量都可以成功接入C3核心网；当出现网络波动或者故障，6条子路径可以实现零丢帧的自适应切换。最后，前面提到的多源拥塞控制也是基于这个模型进行的优化。CTP里面的拥塞控制不再仅仅给出单条链路的拥塞控制信号，还会综合所有子链路的情况，给予用户层一个综合的拥塞控制信号，一方面用于指导每个子链路的发送策略，另一方面用于指导用户层的发送策略，例如调整码率等等。

最后，也是最重要的一点，包级别的自适应路径切换。发送端SDK会利用原始数据包或者空闲时间段的链路探测包不断的进行链路质量探测。第一个机制就是自适应容灾避障机制，当探测到某条子链路出现突发故障，会迅速的切换至另一条子链路发送，结合丢包重传机制，可以保证只要有一条子链路是可用的情况下，所有数据包都可以无差别的传输至核心网中。我们还实现了QoS分级策略，不同的业务流可以有不同的切换策略。第三是针对不同的物理链路进行优化，因为用户端往往有多种不同的链路类型，包括cable, 5G, WiFi等。不同的链路会有不同的发送策略调整。最后是连接迁移，这其实也是通过协议保障的一个地方。

讲完First-Last-mile,我们再来看核心网内部Middle-mile的可靠性保障机制。

第一个是边缘聚合。当数据到达边缘节点，并转发给接收者时，下行链路出现了故障。该边缘节点会自动触发聚合机制，将数据包转发至另外的，也与该接收者建立好连接的其他边缘节点，通过其进行relay传输。保证接收者可以及时地、无错误地收到所有数据。实现这套机制，需要所有边缘节点协同工作才能达到这个效果。

显然，这个机制会增加接收者端的带宽消耗，针对带宽受限、对RTT不敏感的场景，我们也会自适应调整relay策略，把同时传输切换成逐次传输。

第二个是Middle-mile机制时反流避障机制。如图所示，当流量传输至一个节点时，如果只是其中一条子链路出现问题，那么该节点会自适应切换另外一条子链路；但是当所有子链路都出现了网络问题时，该节点会自动通知其父节点进行主动换路，而且会将传输失败的数据包反向发送给父节点，进行补偿传输。只要数据包在C3核心网络中的传输时间没有超过其应用规定的最大超时时间，该包就不会被主动丢弃，会尝试所有子路径，直至传输成功。

该机制是作为一种补偿机制，我们在实际业务中，有发生过几次该现象，最后用户端是没有感知到任何错误的。

最后，是核心网pop点的无损在线升级机制。作为一个SaaS平台，功能的迭代和升级不可避免。首先，我们保障了在升级过程中所有流量不间断，而且不会有任何丢帧错误发生，同时还实现了升级过程中，核心网的整体承载能力不下降。有些系统可能在升级某个pop点时，会将该点的流量先切到另一个pop点上，此时，接收端是会感知到该行为的，甚至会发生丢帧现象。而且这个pop点的升级过程中是无法承载任何流量传输的，这时候整个网络所能承载的最大流量其实是下降的。但我们的升级可以做到零丢帧的同时，整体承载能力不下降。如果把核心网比作一个传输水流的管道，那么在升级过程中，不仅仅管道中的流不受任何影响，同时管道的最大容量也不会有任何变化。实现的原理就是在控制面和数据面都采用了双主备的机制，主备之间的数据可以进行无损的信息同步。

我们公司搭建了一个在线demo展示，上面的视频是实时传输的视频流，一共有两条，一条是从新加坡传输至南京，另一条是从新加坡传输至美国俄勒冈。我提前录制了一个简短的视频，在那个时刻这个流是通过Caton Media Xstream平台实时传输的。图上有具体的单向延迟数据，右边显示的是实时的传输路径，用户可以直观地观察到当前流量是如何在路径树中进行传输和切换的。如果大家有兴趣，我们可以线下展示给大家看。

简单总结一下，C3平台之所以可以保障99.9999%的可靠性，一方面是在网络资源的选择和部署上，依靠多年网络传输方面的经验积累，搭建的高可靠overlay核心网络，这是硬件的力量；另一方面，就是靠各种机制和算法，来保障端到端的可靠传输，这是软件的力量；二者其实缺一不可。

-03-

Caton Cloud

最后，我将简单介绍一下Caton新推出的Caton Cloud平台生态提供的服务。

Caton Cloud是我们公司基于全新的技术和理念研发的下一代云服务平台。

从技术上，它拥抱云原生，充分利用现代云计算平台提供的能力，可靠性，扩展性，不可同日而语，对客户需求的满足敏捷而迅速；
从服务理念上，以用户为中心，更加重视用户的体验和感受。通过专业服务和技术革新，满足用户对质量和价格的需求.
从生态上，Caton Cloud是一个服务体系，聚焦在网络相关的服务，前面介绍的caton Media Xstream是其中最关键的网络传输服务；除此之外，我们还提供了一个实时网络性能监控和诊断服务，NetScope。

NetScope是一个提供网络性能监测与诊断服务的SAAS服务。我们为什么要做这个产品呢？我举个实际业务中遇到的问题：在一次新加坡到香港的SRT传输测试时，SRT中断了41秒，如果没有网络监控程序或者是常规的网络监控，就只能看到网络带宽下降了，可能还需要很多的第三方工具来判断到底是发送端的网络还是接收端的网络，或是中间的网络问题。

而NetScope分析平台不仅会自动告警，还会发现问题发生的现象和原因，上面这个例子就是平台已经分析出来因为中间网络两个运营商的交换，中断了41秒。NetScope是真正拥有网络故障归因分析能力的平台。

NetScope还提供多丰富的功能模块，包括网络性能总览，故障分析详情，以及最重要的周报月报等等，来指导进行网络设备或者视频传输系统的维护。我们可以给用户一个总结报告，告诉用户这一周内发生了多久的网络故障，某些地点经常因为什么问题引起网络中断，譬如本地网线问题，路由器问题，运营商线路接入问题等等，让运维工作真正做到有的放矢。

NetScope是一个网络性能监测与诊断服务的SaaS服务。它可以灵活部署在常见的平台设备中，除了基本的实时监控网络状态以外，核心功能是基于AI实现对网络事件更为智能的归因分析，它可以发现线路丢包是由于内网问题，还是路由器问题，或者宽带问题或者跨运营商线路交换问题引起，不用再使用第三方工具去查找线索，极大降低了故障的诊断时间。欢迎大家下载试用，更多产品和功能欢迎大家线下交流。

这就是我这次分享的全部内容，谢谢大家。