CN1996997A - 一种处理流媒体业务异常的方法及装置 - Google Patents

Abstract

本发明公开了一种处理流媒体业务异常的方法及装置，使用户在请求流媒体内容时更加清楚的知道终端或服务器发生的异常状况。本发明中服务器在与发送流媒体业务请求的终端设备进行连接的交互过程中发现异常时，继续与该终端建立流媒体连接；以及所述服务器将关于所述异常的提示信息转换为流媒体形式，并通过流媒体连接发送给所述终端设备。该装置包括接收单元、处理单元和发送单元。

Description

一种处理流媒体业务异常的方法及装置

技术领域

本发明涉及通信领域，特别是在请求流媒体业务过程中处理流媒体业务异常的方法及装置。

背景技术

流媒体是一种把影像和声音信息进行压缩处理后，以媒体流的方式(不是整个文件下载的方式)提供给用户观赏的技术。它实现了在低带宽环境下实时、连续地提供高质量影音效果的功能。流媒体技术包括媒体数据的采集、压缩、存储、传输等多项技术。流媒体部署到第二代/第三代移动网络后，运营商可以开展各种基于流媒体的多媒体业务，包括手机电视、手机点播、移动网络冲浪、场所监控、手机游戏、新闻、广告、视频会议、远程教育等业务。

一个典型的流媒体系统由用户终端(特别是手机)、接入网和流媒体服务器构成，参见图1所示。终端与服务器间使用实时流协议(Real Time StreamingProtocol，RTSP)进行请求或响应的信令交互，正常流程下服务器一般会使用实时传输协议(Realtime Transform Protocol，RTP)向终端发送媒体流，参见图2所示。

目前现有技术在终端向服务器请求下载流媒体内容时包括三步：1、终端发送描述访问内容的信息及接收服务器的响应；2、终端与服务器协商参数；3、终端向服务器请求播放内容及接收服务器的响应。如果上述三步都成功，则服务器开始向终端发送媒体流。若在步骤1或步骤2出现异常时，服务器根据异常的状况向终端发送实时流协议规定的相应的状态代码(Status-Code)和原因分析，并终止后续流程。例如，状态代码为404，对应的原因分析为“Not Found”，意思是所访问的内容不存在。

可见，状态代码为抽象的数值，只供终端进行程序识别和自动操作。抽象的数值只被程序理解或者专业的技术人员熟悉，一般用户很难从状态代码得知问题所在。协议预定义了原因分析的文字描述，但都是英文而且描述过于简单、专业，即使用户可以看到也未必了解原因并做出相应的处理。另外，原因分析虽然是为人类用户准备的，但客户端不需要检查或显示原因分析，更无需给出处理建议。原因分析具有不确定和可变性，RTSP协议规定文字性的原因解释只是建议采用，可任意更改，而不会对协议造成影响。

发明内容

本发明提供一种处理流媒体业务异常的方法及装置，使用户在请求流媒体内容时更加清楚的知道终端或服务器发生的异常状况。

本发明提供以下技术方案：

一种处理流媒体业务异常的方法，包括以下步骤：

服务器在与发送流媒体业务请求的终端设备进行连接的交互过程中发现异常时，继续与该终端设备建立流媒体连接；以及

所述服务器将关于所述异常的提示信息转换为流媒体形式，并通过所述流媒体连接发送给所述终端设备。

一种流媒体服务器，包括：

接收单元，用于接收终端设备发送的流媒体业务请求；

处理单元，用于在与所述终端设备进行连接的交互过程中发现异常时，继续与该终端建立流媒体连接，以及将关于所述异常的提示信息转换为流媒体形式；

发送单元，用于通过所述流媒体连接将流媒体形式的所述提示信息发送给所述终端设备。

一种通信系统，包括：

终端设备，用于向服务器发送请求并接收该服务器发送的响应消息和流媒体内容；

所述服务器，用于在与所述终端设备进行连接的交互过程中发现异常时，继续与该终端设备建立流媒体连接，以及将关于所述异常的提示信息转换为流媒体形式，并通过所述流媒体连接发送给所述终端设备。

本发明中服务器与终端设备进行连接交互过程中发现异常时继续向终端设备发送成功命令，与终端设备建立流媒体连接，实现通过流媒体形式向终端设备发送关于异常的提示信息，使用户清楚的知道发生的异常状况。

附图说明

图1为现有技术中流媒体系统的网络结构图；

图2为现有技术中网络结构及协议应用的示意图；

图3为本发明实施例中系统结构图；

图4为本发明实施例中流媒体服务器的结构图；

图5为本发明实施例中处理4xx和5xx所代表的异常状况的方法流程图；

图6为本发明实施例中利用3xx所代表的命令处理异常状况的方法流程图。

具体实施方式

为了使用户在请求流媒体内容时更加清楚的知道终端或服务器发生的异常状况，本实施例中服务器向终端发送提示性的流媒体内容，在流媒体内容中清楚的描述错误原因及处理意见。

为了可以成功下发提示性的流媒体内容，本实施例中服务器在发现异常状况时仍向终端发送成功命令。

在流媒体系统中，终端和流媒体服务器应用RTSP协议进行交互，关于RTSP协议的具体描述可参考RFC2326 RTSP。一次完整的RTSP交互由请求和响应组成，常用的RTSP请求消息有：描述(DESCRIBE)、操作(OPTIONS)、设置(SETUP)、播放(PLAY)、暂停(PAUSE)、断连(TEARDOWN)等。RTSP响应消息中定义了“状态行(Status-Line)”，即完整回应消息的第一行，依次由协议版本(RTSP-Version)、数字形式的状态代码、及相应的词语文本(Reason-Phrase)组成，各元素间以空格(SP)分隔，除了结尾的回车换行(CRLF)外，不允许出现单独的回车(CR)或换行(LF)符。一个状态行的格式实例如下：

Status-Line＝RTSP-Version SP Status-Code SP Reason-Phrase CRLF

其中，状态代码(Status-Code)由3位数字组成，表示请求消息是否被理解或被满足。原因分析(Reason-Phrase)是用简短的文字来描述状态代码产生的原因。状态代码用来支持自动操作，原因分析是为人类用户准备的，客户端不需要检查或显示原因分析。状态代码的第一位数字定义了回应的类别，后面两位数字没有具体分类。首位数字有5种取值可能：

1xx表示保留，将来使用。

2xx表示成功，操作被接收(received)、理解(understood)、接受(accepted)。

3xx表示重定向(Redirection)，要完成请求必须进行进一步操作。

4xx表示客户端出错，请求有语法错误或无法实现。

5xx表示服务器端出错，服务器无法实现合法的请求。

参见图3，本实施例中网络系统包括终端31、接入网33和流媒体服务器32。

接入网33为终端31和流媒体服务器32提供信息交互。

终端31通过接入网33向流媒体服务器32请求流媒体内容，在接收到流媒体服务器32返回的正确响应消息后继续发送下一个消息并接收到正确响应，如此循环往复，各消息中可能存在错误；在与流媒体服务器32建立播放连接后，接收流媒体内容。

流媒体服务器32通过接入网33接收终端31发送的各请求消息，并在发现消息异常时向终端31返回正确响应消息，在本地记录异常状况，当接收到播放请求消息时根据本地记录的异常向终端31发送与该异常对应的带有错误提示的流媒体内容，通知用户发生的异常并提供解决异常的建议。

参见图4，本实施例中流媒体服务器32包括接收单元401、处理单元402、记录单元403和发送单元404。

接收单元401接收终端31发送的各请求消息。

处理单元402对消息中的信息进行相关检查，在发现异常时指示记录单元403记录该异常，生成正确响应消息；在收到播放请求消息时从记录单元403里获取异常记录，向终端31发送带有错误提示的流媒体内容。

记录单元403根据处理单元402的检查结果记录异常状况。

发送单元404向终端31发送正确响应消息和带有错误提示的流媒体内容。

运营商在业务部署前可根据网络能力、服务器能力和终端类型，规划流媒体提示片断的属性，如标记(LOGO)、编码速率、音频/视频(Audio/Video，A/V)组合、文件格式、提示内容、元数据(META-DATA)等。然后运营商通过编码系统制作4xx/5xx状态代码对应的提示性的流媒体内容，将该流媒体内容按照流媒体服务器32要求的命名规则命名，批量上载到流媒体服务器32的指定目录。

上载流媒体内容后便可以在发生异常状况时应用，下面以状态代码4xx为例介绍一种应用实例，状态代码5xx的实施方式与4xx的相同。本实施例提供多种实现方案，如方案一是服务器32在发现异常时仍向终端31发送成功命令，与终端31建立流媒体连接并发送带有错误提示信息的流媒体内容；如方案二是利用重定向命令使终端31发送请求带有错误提示信息的流媒体内容的请求消息并获得该流媒体内容。

本实施例中的方案一

参见图5，本实施例中处理流媒体业务异常的方法具体流程如下：

步骤501：终端31向流媒体服务器32发送描述要访问的内容消息(Describe消息)。

步骤502：流媒体服务器32根据接收到的描述消息检查文件系统，并发现文件不存在，则在本地将本次请求标记为“内容不存在”，或标记404，然后向终端31返回状态行：200 OK，表示接受访问消息。

步骤503：终端31向流媒体服务器32发送设置(Setup)消息，该消息中包括终端参数、统一资源定位(URL)参数和认证计费参数。

步骤504：流媒体服务器32根据接收到的设置消息检查步骤503中所述的各参数的格式，发现有异常时将本次请求标记为“终端错误”，然后向终端31返回状态行：200 OK。

步骤505：终端31向流媒体服务器32发送播放(Play)请求消息，请求播放流媒体内容。

步骤506：流媒体服务器32根据接收到的播放消息检查内部资源(包括存储空间和CPU的承载能力等)，并在内部资源足够和发现本地已经标记的“内容不存在”和“终端错误”时，根据终端参数和异常种类选择适配的带有异常错误提示的流媒体内容，然后向终端31返回状态行：200 OK。

流媒体服务器32记录日志，在业务日志和计费数据记录(Charging DataRecording，CDR)中可扩展日志参数，说明本次播放的是错误提示性的流媒体内容还是正常播放的流媒体内容，便于播放统计和计费处理等。

步骤507：流媒体服务器32应用RTP协议向终端31发送与“内容不存在”和“终端错误”对应的带有异常错误提示的流媒体内容，其中还可以包括解决该异常的建议。

步骤508：终端31接收并播放带有异常错误提示的流媒体内容。

步骤509：流媒体内容播放完毕，终端31向流媒体服务器32发送断连(Teardown)消息，停止播放。

步骤510：流媒体服务器32结束流媒体内容的传输，向终端31返回200OK。

本实施例中的方案二

本实施例中服务器32通过重定向命令向终端31发送带有异常错误提示的流媒体内容的地址，并进一步向终端发送带有异常错误提示的流媒体内容。RTSP协议定义了的状态代码3xx代表重定向，下面以状态代码302为例进行说明。

参见图6，本实施例中处理流媒体业务异常的方法具体流程如下：

步骤601：终端31向流媒体服务器32发送描述要访问的内容消息(Describe消息)。

步骤602：流媒体服务器32根据接收到的描述消息检查文件系统，并发现请求的文件不存在，则在本地将本次请求标记为“内容不存在”，或标记404，然后向终端31返回状态行：200 OK，表示接受访问消息。

步骤603：终端31向流媒体服务器32发送设置消息，该消息中包括终端参数、统一资源定位参数和认证计费参数。

步骤604：流媒体服务器32根据接收到的设置消息检查步骤603中所述的各参数，发现各参数的格式有异常时将本次请求标记为“终端错误”，然后向终端31返回状态行：200 OK。

步骤605：终端31向流媒体服务器32发送播放请求消息，请求播放流媒体内容，该请求消息中包含请求的流媒体内容的地址，一个实例如下：

PLAY RTSP://SEVER-IP/1.3gp

步骤606：流媒体服务器32根据接收到的播放消息检查本地记录的标记，在发现标记“内容不存在”时，向终端31返回重定向代码302和URL：RTSP://SERVER-IP/tip/notfound.3gp，该地址提供带有与上述异常对应的提示信息，并以流媒体形式保存，提示信息还包括针对异常情况的解决办法。

步骤607：终端31收到响应后根据收到的URL再次向流媒体服务器32发送请求提示信息的流媒体业务请求消息。

服务器32在接收到请求提示信息的流媒体业务请求消息后可以有多种处理方式，如一种方式为：服务器32对该请求消息进行检查，重复步骤602到步骤605，或者采用方案一中所述的方法。如果发现该请求消息也出现异常时，将两次发现的异常所对应的提示信息转换为流媒体形式发送到终端31。如另一种方式为：服务器32在重定向命令中增加标志位，相应的，该请求消息中也包含该标志位；服务器32在发现该标志位时不需对该请求消息进行检查，直接发送成功命令，继续步骤608。这是一种较佳的实现方法。标志位可以是一种特殊的标志；或者是记录的终端31发送的请求次数，当连续N-1次发现终端错误时，在第N次接收到请求消息时不需对请求消息进行检查，直接向终端31返回成功命令。

步骤608：流媒体服务器32检查内部资源足够时向终端31返回状态行：200 OK。

步骤609：流媒体服务器32应用RTP协议向终端31发送带有异常错误提示的流媒体内容。

步骤610：终端31接收并播放与状态代码302对应的带有异常错误提示的流媒体内容。

步骤611：流媒体内容播放完毕，终端31向流媒体服务器32发送Teardown消息，停止播放，继续步骤612。或者，流媒体服务器32主动断开流媒体连接。

步骤612：流媒体服务器32结束流媒体内容的传输，向终端31返回状态行：200 OK。

本实施例中流媒体服务器在发现异常状况时在本地标记异常，并向终端发送正确响应消息，使终端可以正常接收到带有异常错误提示的流媒体内容，以使用户可以清楚的了解异常并获知解决办法。终端只要能正常使用流媒体业务就可利用本发明改善异常场景的体验，不需任何新开发。并且，用户不再因为手机的差别而有体验上的差异。

本发明在业务层解决了协议的不确定和灵活性，对于一个完整的、确定的流媒体业务系统，各种异常场景的原因解释和建议，可以在体验上由运营商统一预定义。本发明采用流媒体内容的形式提示用户，所以与终端操作系统支持的语言无关，运营商制作的流媒体内容中可使用任何语言。

同时，本发明不改动流媒体业务的基本架构和形态，仅占用服务器极少的存储空间(通常仅几百MB)。由于常见的异常场景有限，所以需要制作的提示性流媒体内容也数量有限，不会带来明显的附加工作量；制作的流媒体内容只需要放置在服务器的指定目录，更新工作简单。并且，运营商可以经常改变提示片断的内容、风格、提示画面的LOGO等，保持用户的新鲜感，提高用户的体验。本发明由运营商统一定义错误提示的流媒体内容，从而即使终端设备不同，用户只需要说明看到了什么样的流媒体内容，客服人员即可解答原因，减轻了客服人员的负担。

本发明还利用了RTSP协议规定的状态代码3xx代表的重定向命令使终端获得异常提示信息。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (13)

1、一种处理流媒体业务异常的方法，其特征在于，包括以下步骤：

服务器在与发送流媒体业务请求的终端设备进行连接的交互过程中发现异常时，继续与该终端设备建立流媒体连接；以及

所述服务器将关于所述异常的提示信息转换为流媒体形式，并通过所述流媒体连接发送给所述终端设备。

2、如权利要求1所述的处理流媒体业务异常的方法，其特征在于，所述服务器发现所述异常时仍然向所述终端设备返回成功命令。

3、如权利要求2所述的处理流媒体业务异常的方法，其特征在于，所述服务器在本地标记所述异常，在接收到播放Play请求消息并发现所述异常的标记后发送所述提示信息。

4、如权利要求1所述的处理流媒体业务异常的方法，其特征在于，所述服务器在本地标记所述异常，并在接收到播放Play请求消息以及发现所述异常的标记时向所述终端设备返回包括所述提示信息的地址的重定向命令；

所述终端设备根据所述提示信息地址再次向服务器发送请求所述提示信息的流媒体业务请求；所述服务器与所述终端设备建立所述流媒体连接并发送所述提示信息。

5、如权利要求4所述的处理流媒体业务异常的方法，其特征在于，所述重定向命令还包括标志位，相应的，所述请求提示信息的流媒体业务请求也包括所述标志位；所述服务器发现所述标志位时直接向所述终端设备返回成功命令。

6、如权利要求1所述的处理流媒体业务异常的方法，其特征在于，所述提示信息包括用于描述所述异常的信息，或者包括用于描述所述异常的信息和解决所述异常的方法。

7、如权利要求1所述的处理流媒体业务异常的方法，其特征在于，所述服务器发送所述提示信息完毕后断开所述流媒体连接；或者，所述终端设备接收所述提示信息完毕后向所述服务器请求断开所述流媒体连接。

8、如权利要求1至7中的任一项所述的处理流媒体业务异常的方法，其特征在于，所述服务器在发送所述提示信息时记录日志，记录本次发送的是提示信息。

9、一种流媒体服务器，其特征在于，包括：

接收单元，用于接收终端设备发送的流媒体业务请求；

处理单元，用于在与所述终端设备进行连接的交互过程中发现异常时，继续与该终端建立流媒体连接，以及将关于所述异常的提示信息转换为流媒体形式；

发送单元，用于通过所述流媒体连接将流媒体形式的所述提示信息发送给所述终端设备。

10、如权利要求9所述的流媒体服务器，其特征在于，所述服务器发现所述异常时仍然向所述终端设备返回成功命令。

11、一种通信系统，其特征在于，包括：

终端设备，用于向服务器发送请求并接收该服务器发送的响应消息和流媒体内容；

所述服务器，用于在与所述终端设备进行连接的交互过程中发现异常时，继续与该终端设备建立流媒体连接，以及将关于所述异常的提示信息转换为流媒体形式，并通过所述流媒体连接发送给所述终端设备。

12、如权利要求11所述的通信系统，其特征在于，所述服务器发现所述异常时仍然向所述终端设备返回成功命令。

13、如权利要求11所述的通信系统，其特征在于，所述服务器包括：

接收单元，用于接收终端设备发送的流媒体业务请求；

处理单元，用于在与所述终端设备进行连接的交互过程中发现异常时，继续与该终端建立流媒体连接，以及将关于所述异常的提示信息转换为流媒体形式；

发送单元，用于通过所述流媒体连接将流媒体形式的所述提示信息发送给所述终端设备。