CN114553735B - 一种多媒体数据故障分析方法、系统和存储设备 - Google Patents

Abstract

本申请涉及多媒体技术领域，特别涉及一种多媒体数据故障分析方法、系统和存储设备。所述一种多媒体数据故障分析方法，包括步骤：客户端进行目标对象异常检测，若目标对象存在异常，则收集待判断信息发送至平台端。通过该方法客户端自行检测故障，自行上报故障信息，直接减少平台端服务器检测的开销，并且实现了有问题就立即收集、立即分析，整个过程无需任何人工参与，节约人力成本。

Description

一种多媒体数据故障分析方法、系统和存储设备

技术领域

本申请涉及多媒体技术领域，特别涉及一种多媒体数据故障分析方法、系统和存储设备。

背景技术

在音视频领域，专业级音视频业务平台通常由于平台大、信令交互复杂，导致了故障较难分析及追溯；而传统的通过平台日志及报文人工分析的方式，也存在分析效率低、分析准确性低等问题。SIP(Session Initialization Protocol，会话初始协议)是一个基于文本的应用层控制协议，可用于创建、修改和释放一个或多个参与者的会话；SIP协议拥有较高可扩展性，它可以结合SDP协议(Session Description Protocol，会话描述协议)来建立多媒体会话，在音视频领域应用较广泛。RTP协议(Real-time Transport Protocol，实时传输协议)，是用于在音视频等多媒体数据实时传输场景下使用的协议，RTCP(Real-timeTransport Control Protocol，实时传输控制协议)，主要用于提供服务质量的监控与反馈。

在现有的SIP协议及音视频故障分析方案中，有利用监控程序实现信令流程监控的，也有通过平台主动下发流程检测的；利用监控程序实现信令流程监控，存在系统资源开销较大、故障检测形式单一的缺点；而通过平台主动下发检测，却需要运维人员介入，无法实现实时检测、自动分析。

发明内容

鉴于上述问题，本申请提供了一种多媒体数据故障分析方法，用以解决现有基于SIP协议的故障分析检测要么平台端资源开销大，要么需要人工参与的技术问题。具体技术方案如下：

一种多媒体数据故障分析方法，包括步骤：

客户端进行目标对象异常检测，若目标对象存在异常，则收集待判断信息发送至平台端。

进一步的，所述“客户端进行目标对象异常检测”前，具体还包括步骤：

客户端初始化时，在目标对象处理流程中，添加目标对象故障检测钩子函数。

进一步的，还包括步骤：

所述平台端接收所述待判断信息，并对所述待判断信息进行处理分析得故障原因。

进一步的，所述“并对所述待判断信息进行处理分析得故障原因”，具体还包括步骤：

根据上报的故障类型进行分类，并分析目标对象关键信息；

根据所述关键信息从目标对象服务中获取对应的目标信息；

对所述目标信息进行分析得故障原因。

进一步的，所述目标对象包括：信令和媒体；

所述“根据所述关键信息从目标对象服务中获取对应的目标信息”，具体还包括步骤：

若为信令故障，则根据关键信息的Call-ID信息，从信令服务获取对应会话流程信令交互，针对平台端的Session，分析交互过程的异常；

若为媒体故障，则根据信令服务获取到的媒体Session，获取指定SDP协商交互，分析交互流程的异常输出；

所述“对所述目标信息进行分析得故障原因”，具体还包括步骤：

与正常的信令交互及媒体处理流程进行比对分析，保存故障信息及分析结果。

进一步的，所述目标对象包括：信令和媒体；

所述“若目标对象存在异常，则收集待判断信息发送至平台端”，具体还包括步骤：

若信令存在故障，则获取信令交互信息，并发送对应故障信息和信令交互信息至平台端；

若媒体存在故障，则获取媒体收发信息，并发送对应故障信息和媒体收发信息至平台端。

进一步的，所述目标对象包括：信令和媒体；

所述“在目标对象处理流程中，添加目标对象故障检测钩子函数”，具体还包括步骤：

在信令协议栈和媒体处理流程中，添加故障检测钩子函数。

进一步的，所述信令包括：SIP信令。

为解决上述技术问题，还提供了一种多媒体数据故障分析系统，具体技术方案如下：

一种多媒体数据故障分析系统，包括：客户端和平台端；

所述客户端包括一种多媒体数据故障分析方法提及的客户端，所述平台端包括一种多媒体数据故障分析方法提及的平台端。

为解决上述技术问题，还提供了一种存储设备，具体技术方案如下：

一种存储设备，所述存储设备包括一种多媒体数据故障分析方法提及的客户端。

本发明的有益效果是：一种多媒体数据故障分析方法，包括步骤：客户端进行目标对象异常检测，若目标对象存在异常，则收集待判断信息发送至平台端。通过该方法客户端自行检测故障，自行上报故障信息，直接减少平台端服务器检测的开销，并且实现了有问题就立即收集、立即分析，整个过程无需任何人工参与，节约人力成本。

上述发明内容相关记载仅是本申请技术方案的概述，为了让本领域普通技术人员能够更清楚地了解本申请的技术方案，进而可以依据说明书的文字及附图记载的内容予以实施，并且为了让本申请的上述目的及其它目的、特征和优点能够更易于理解，以下结合本申请的具体实施方式及附图进行说明。

附图说明

附图仅用于示出本申请具体实施方式以及其他相关内容的原理、实现方式、应用、特点以及效果等，并不能认为是对本申请的限制。

在说明书附图中：

图1为具体实施方式所述一种多媒体数据故障分析方法的流程图一；

图2为具体实施方式所述一种多媒体数据故障分析方法的流程图二；

图3为具体实施方式所述一种多媒体数据故障分析方法的示意图；

图4为具体实施方式所述一种多媒体数据故障分析系统的模块示意图；

图5为具体实施方式所述一种存储设备的模块示意图。

上述各附图中涉及的附图标记说明如下：

400、一种多媒体数据故障分析系统，

401、客户端，

402、平台端，

500、存储设备。

具体实施方式

为详细说明本申请可能的应用场景，技术原理，可实施的具体方案，能实现目的与效果等，以下结合所列举的具体实施例并配合附图详予说明。本文所记载的实施例仅用于更加清楚地说明本申请的技术方案，因此只作为示例，而不能以此来限制本申请的保护范围。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中各个位置出现的“实施例”一词并不一定指代相同的实施例，亦不特别限定其与其它实施例之间的独立性或关联性。原则上，在本申请中，只要不存在技术矛盾或冲突，各实施例中所提到的各项技术特征均可以以任意方式进行组合，以形成相应的可实施的技术方案。

除非另有定义，本文所使用的技术术语的含义与本申请所属技术领域的技术人员通常理解的含义相同；本文中对相关术语的使用只是为了描述具体的实施例，而不是旨在限制本申请。

在本申请的描述中，用语“和/或”是一种用于描述对象之间逻辑关系的表述，表示可以存在三种关系，例如A和/或B，表示：存在A，存在B，以及同时存在A和B这三种情况。另外，本文中字符“/”一般表示前后关联对象是一种“或”的逻辑关系。

在本申请中，诸如“第一”和“第二”之类的用语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何实际的数量、主次或顺序等关系。

在没有更多限制的情况下，在本申请中，语句中所使用的“包括”、“包含”、“具有”或者其他类似的表述，意在涵盖非排他性的包含，这些表述并不排除在包括所述要素的过程、方法或者产品中还可以存在另外的要素，从而使得包括一系列要素的过程、方法或者产品中不仅可以包括那些限定的要素，而且还可以包括没有明确列出的其他要素，或者还包括为这种过程、方法或者产品所固有的要素。

与《审查指南》中的理解相同，在本申请中，“大于”、“小于”、“超过”等表述理解为不包括本数；“以上”、“以下”、“以内”等表述理解为包括本数。此外，在本申请实施例的描述中“多个”的含义是两个以上(包括两个)，与之类似的与“多”相关的表述亦做此类理解，例如“多组”、“多次”等，除非另有明确具体的限定。

在本实施例中，一种多媒体数据故障分析方法可应用在一种多媒体数据故障分析系统上，所述一种多媒体数据故障分析系统包括：客户端和平台端。

本申请的核心技术思想在于：通过对客户端进行软件上的改进，使得客户端可以主动进行故障检测，及主动进行故障上报，进而触发平台端接收对应待判断信息，进而进行故障分析。如此可以减少平台端服务器检测的开销，且实现了有问题立即收集、立即分析。

以下将结合图1至图3对一种多媒体数据故障分析方法的具体实施方式展开说明：

如图1所示，一种多媒体数据故障分析方法包括步骤：

步骤S101：客户端进行目标对象异常检测。在本实施例中目标对象包括：信令和媒体。其中信令主要为SIP信令。

在客户端进行初始化时，就会在目标对象处理流程中，添加目标对象故障检测钩子函数。即在信令协议栈和媒体处理流程中，添加故障检测钩子函数。如此在信令及视频处理时，客户端会主动进行异常检测，无需如现有技术一样需要平台端发送故障检测指令给客户端，客户端才进行故障检测指令，如此可大大减少平台端服务器检测的开销。本实施例中，主要针对SIP协议栈在SIP会话过程、SDP协商过程、RTP传输处理过程的异常，进行捕获，并通过故障检测钩子函数返回应用层；在故障检测钩子函数中，将对各阶段的异常进行分类、封装，并发送到平台端。

步骤S102：若目标对象存在异常，则收集待判断信息发送至平台端。即若信令存在故障，则获取信令交互信息，并发送对应故障信息和信令交互信息至平台端；

若媒体存在故障，则获取媒体收发信息，并发送对应故障信息和媒体收发信息至平台端。本实施例中的媒体包括：音视频数据。

如图2所述，步骤S102后，还包括步骤S203：所述平台端接收所述待判断信息，并对所述待判断信息进行处理分析得故障原因。其中步骤S201至步骤S202与步骤S101至步骤S102相同，故此不做重复说明。

进一步的，所述“并对所述待判断信息进行处理分析得故障原因”，具体还包括步骤：

根据上报的故障类型进行分类，并分析目标对象关键信息；

根据所述关键信息从目标对象服务中获取对应的目标信息；

对所述目标信息进行分析得故障原因。

所述“根据所述关键信息从目标对象服务中获取对应的目标信息”，具体还包括步骤：

若为信令故障，则根据关键信息的Call-ID信息，从信令服务获取对应会话流程信令交互，针对平台端的Session，分析交互过程的异常；

若为媒体故障，则根据信令服务获取到的媒体Session，获取指定SDP协商交互，分析交互流程的异常输出；

所述“对所述目标信息进行分析得故障原因”，具体还包括步骤：

与正常的信令交互及媒体处理流程进行比对分析，保存故障信息及分析结果。具体可为：如信令交互流程，应根据SIP信令的RFC规范流程进行比对分析(如标准INVITE会话流程)，如收到183Session Progress，应对应分析发送INVITE的头部及SDP是否异常，并接收SDP错误信息。或如媒体协商，应根据SDP协商规则，分析是否存在相同的音视频编码，是否协商了加密，是否都携带ICE信息。

以上整体的流程示意图如图3所示，大致流程为：接收到故障上报，解析故障分类及关键信息，接着分两个情况，如果是信令故障，则从信令服务获取关联信令信息和从媒体服务获取音视频关联信息，如果是媒体故障，则从媒体服务获取音视频关联信息。而后对比正常信令交互及媒体处理流程，最后保存故障信息及分析结果。

以上方法采用客户端主动检测故障，主动上报的方式，触发平台端进行故障收集，利用平台端综合管理能力，收集关联服务器的故障关联信息，并完成故障自动分析，该过程不需要任何运维人员参与，全程自动进行，降低了大型平台的运维成本投入，提高了运维效率。同时减少了平台端服务器的开销。

以下参阅图4，对一种多媒体数据故障分析系统400的具体实施方式展开说明：

一种多媒体数据故障分析系统400，包括：客户端401和平台端402。其中所述客户端401与所述平台端402通信连接。

客户端401用于：进行目标对象异常检测。在本实施例中目标对象包括：信令和媒体。其中信令主要为SIP信令。

在客户端401进行初始化时，就会在目标对象处理流程中，添加目标对象故障检测钩子函数。即在信令协议栈和媒体处理流程中，添加故障检测钩子函数。如此在信令及视频处理时，客户端401会主动进行异常检测，无需如现有技术一样需要平台端402发送故障检测指令给客户端401，客户端401才进行故障检测指令，如此可大大减少平台端402服务器检测的开销。

本实施例中，主要针对SIP协议栈在SIP会话过程、SDP协商过程、RTP传输处理过程的异常，进行捕获，并通过故障检测钩子函数返回应用层；在故障检测钩子函数中，将对各阶段的异常进行分类、封装，并发送到平台端402。

若目标对象存在异常，则收集待判断信息发送至平台端402。即若信令存在故障，则获取信令交互信息，并发送对应故障信息和信令交互信息至平台端402；

若媒体存在故障，则获取媒体收发信息，并发送对应故障信息和媒体收发信息至平台端402。

所述平台端402接收所述待判断信息，并对所述待判断信息进行处理分析得故障原因。

进一步的，平台端402还用于：根据上报的故障类型进行分类，并分析目标对象关键信息；

根据所述关键信息从目标对象服务中获取对应的目标信息；

对所述目标信息进行分析得故障原因。

所述平台端402还用于：

若为信令故障，则根据关键信息的Call-ID信息，从信令服务获取对应会话流程信令交互，针对平台端的Session，分析交互过程的异常；

若为媒体故障，则根据信令服务获取到的媒体Session，获取指定SDP协商交互，分析交互流程的异常输出；

与正常的信令交互及媒体处理流程进行比对分析，保存故障信息及分析结果。具体可为：如信令交互流程，应根据SIP信令的RFC规范流程进行比对分析(如标准INVITE会话流程)，如收到183Session Progress，应对应分析发送INVITE的头部及SDP是否异常，并接收SDP错误信息。或如媒体协商，应根据SDP协商规则，分析是否存在相同的音视频编码，是否协商了加密，是否都携带ICE信息。

以上系统400中，对于客户端401，其添加自动检测故障，自动信息收集，自动上报故障信息；对于平台端402，其根据故障分类，收集关联服务的信息，根据上报信息的关联性，参照标准流程及交互处理，自动分析故障原因。整个系统的运行不需要任何运维人员参与，全程自动进行，降低了大型平台的运维成本投入，提高了运维效率。同时减少了平台端402服务器的开销。

以下参阅图5，对一种存储设备500的具体实施方式展开说明：

所述存储设备500包括但不限于：个人计算机、服务器、通用计算机、专用计算机、网络设备、嵌入式设备、可编程设备、智能移动终端等。

所述存储设备500存储有指令集，其指令集用于执行：进行目标对象异常检测。在本实施例中目标对象包括：信令和媒体。其中信令主要为SIP信令。

在存储设备500进行初始化时，就会在目标对象处理流程中，添加目标对象故障检测钩子函数。即在信令协议栈和媒体处理流程中，添加故障检测钩子函数。如此在信令及视频处理时，存储设备500会主动进行异常检测。

本实施例中，主要针对SIP协议栈在SIP会话过程、SDP协商过程、RTP传输处理过程的异常，进行捕获，并通过故障检测钩子函数返回应用层；在故障检测钩子函数中，将对各阶段的异常进行分类、封装，并发送到平台端。

若目标对象存在异常，则收集待判断信息发送至平台端。即若信令存在故障，则获取信令交互信息，并发送对应故障信息和信令交互信息至平台端；

若媒体存在故障，则获取媒体收发信息，并发送对应故障信息和媒体收发信息至平台端。

该存储设备500会主动检测故障，主动上报的方式，触发平台端进行故障收集，无需平台端主动进行故障手机，减少了平台端服务器的开销，且无需人工参与，降低了大型平台的运维成本投入，提高了运维效率。

最后需要说明的是，尽管在本申请的说明书文字及附图中已经对上述各实施例进行了描述，但并不能因此限制本申请的专利保护范围。凡是基于本申请的实质理念，利用本申请说明书文字及附图记载的内容所作的等效结构或等效流程替换或修改产生的技术方案，以及直接或间接地将以上实施例的技术方案实施于其他相关的技术领域等，均包括在本申请的专利保护范围之内。

Claims (5)

1.一种多媒体数据故障分析方法，其特征在于，包括步骤：

客户端初始化时，在信令协议栈和媒体处理流程中，添加目标对象故障检测钩子函数；

客户端进行目标对象异常检测，若目标对象存在异常，则收集待判断信息发送至平台端；

所述平台端接收所述待判断信息，并对所述待判断信息进行处理分析得故障原因；

所述“并对所述待判断信息进行处理分析得故障原因”，具体还包括步骤：

根据上报的故障类型进行分类，并分析目标对象关键信息；

根据所述关键信息从目标对象服务中获取对应的目标信息；

对所述目标信息进行分析得故障原因；

所述目标对象包括：信令和媒体；

所述“根据所述关键信息从目标对象服务中获取对应的目标信息”，具体还包括步骤：

若为信令故障，则根据关键信息的Call-ID信息，从信令服务获取对应会话流程信令交互，针对平台端的Session，分析交互过程的异常；

若为媒体故障，则根据信令服务获取到的媒体Session，获取指定SDP协商交互，分析交互流程的异常输出；

所述“对所述目标信息进行分析得故障原因”，具体还包括步骤：

与正常的信令交互及媒体处理流程进行比对分析，保存故障信息及分析结果。

2.根据权利要求1所述的一种多媒体数据故障分析方法，其特征在于，所述目标对象包括：信令和媒体；

所述“若目标对象存在异常，则收集待判断信息发送至平台端”，具体还包括步骤：

若信令存在故障，则获取信令交互信息，并发送对应故障信息和信令交互信息至平台端；

若媒体存在故障，则获取媒体收发信息，并发送对应故障信息和媒体收发信息至平台端。

3.根据权利要求1或2所述的一种多媒体数据故障分析方法，其特征在于，所述信令包括：SIP信令。

4.一种多媒体数据故障分析系统，其特征在于，包括：客户端和平台端；

所述客户端包括权利要求1至3任一项所述的客户端，所述平台端包括权利要求1至3任一项所述的平台端。

5.一种存储设备，其特征在于，所述存储设备包括权利要求1至3任一项所述的客户端。