WO2008071083A1 - Procédé et dispositif pour traiter une anomalie de service - Google Patents

Procédé et dispositif pour traiter une anomalie de service Download PDF

Info

Publication number
WO2008071083A1
WO2008071083A1 PCT/CN2007/003530 CN2007003530W WO2008071083A1 WO 2008071083 A1 WO2008071083 A1 WO 2008071083A1 CN 2007003530 W CN2007003530 W CN 2007003530W WO 2008071083 A1 WO2008071083 A1 WO 2008071083A1
Authority
WO
WIPO (PCT)
Prior art keywords
streaming media
terminal device
server
abnormality
media service
Prior art date
Application number
PCT/CN2007/003530
Other languages
English (en)
French (fr)
Inventor
Zhaohui Du
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2008071083A1 publication Critical patent/WO2008071083A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor

Definitions

  • the present invention relates to the field of communications, and more particularly to a method and apparatus for handling streaming media service anomalies in a process of requesting streaming media services. Background technique
  • Streaming media is a technology that provides video and audio information to be compressed by the media stream (not the entire file download). It provides real-time, continuous high-quality audio and video effects in a low-bandwidth environment.
  • Streaming media technologies include the collection, compression, storage, and transmission of media data.
  • operators can conduct a variety of streaming-based multimedia services, including mobile TV, mobile phone on demand, mobile web surfing, venue monitoring, mobile games, news, advertising, video. Conference, distance education and other services.
  • a typical streaming system consists of a user terminal (especially a mobile phone), an access network, and a streaming server, as shown in Figure 1.
  • the Real Time Streaming Protocol (RTSP) is used to perform the request or response signaling interaction between the terminal and the server.
  • the server In the normal process, the server generally uses the Real Time Transform Protocol (RTP) to send the media stream to the terminal. 2 is shown.
  • RTSP Real Time Streaming Protocol
  • the prior art requires three steps when the terminal requests the server to download the streaming media content: 1.
  • the terminal sends the information describing the access content and the response of the receiving server; 2.
  • the terminal negotiates the parameters with the server; 3.
  • the terminal requests the content to be played by the server and Receive the response from the server. If all three steps above are successful, the server starts sending media streams to the terminal. If an abnormality occurs in step 1 or step 2, the server sends the corresponding status code (Status-Code) and cause analysis specified by the real-time streaming protocol to the terminal according to the abnormal condition, and terminates the subsequent process.
  • the status code is 404, and the corresponding reason is analyzed as "Not Found", meaning that the content accessed does not exist.
  • the status code is an abstract value, which is only used for terminal identification and automatic operation.
  • the abstract values are only familiar to the program or familiar to the professional technicians. It is difficult for the average user to know from the status code. problem lies in.
  • the protocol pre-defines the textual description of the cause analysis, but it is all in English and the description is too simple and professional. Even if the user can see it, it may not understand the reason and deal with it accordingly.
  • the cause analysis is prepared for human users, the client does not need to check or display the cause analysis, and there is no need to give advice.
  • the cause analysis is uncertain and variability. The interpretation of the reason for the textuality of the RTSP protocol is only recommended and can be changed arbitrarily without affecting the agreement. Summary of the invention
  • the embodiment of the invention provides a method and a device for processing an abnormality of a streaming media service, so that the user can know the abnormal situation of the terminal or the server more clearly when requesting the streaming media content.
  • a method for handling anomalies in streaming media services includes the following steps:
  • the server continues to establish a streaming media connection with the terminal device when an abnormality is found during the interaction with the terminal device that sends the streaming media service request;
  • the server sends the prompt information about the abnormality to the terminal device through the streaming media connection in the form of streaming media.
  • a streaming media server comprising:
  • a receiving unit configured to receive a streaming media service request sent by the terminal device
  • a processing unit configured to establish a streaming media connection with the terminal, and obtain prompt information in the form of streaming media when an abnormality is found during an interaction process with the terminal device;
  • a sending unit configured to send the prompt information in the form of streaming media to the terminal device by using the streaming media connection.
  • a communication system comprising:
  • a terminal device configured to send a request to the server and receive a response message and a streaming media content sent by the server;
  • the server is configured to continue to establish a streaming media connection with the terminal device when an abnormality is found in the interaction process with the terminal device, and use the streaming media in the form of streaming media
  • the connection is sent to the terminal device.
  • the server and the terminal device continue to send a success command to the terminal device when the connection is abnormal, and the device establishes a streaming media connection with the terminal device, so as to send the prompt information about the abnormality to the terminal device through the streaming media, so that the user Clearly know the abnormal situation that occurred.
  • FIG. 1 is a network structure diagram of a streaming media system in the prior art
  • FIG. 2 is a schematic diagram of a network structure and a protocol application in the prior art
  • FIG. 3 is a structural diagram of a system in an embodiment of the present invention.
  • FIG. 4 is a structural diagram of a streaming media server according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of a method for processing an abnormal condition represented by 4xx and 5xx according to an embodiment of the present invention
  • FIG. 6 is a flowchart of a method for processing an abnormal condition by using a command represented by 3xx according to an embodiment of the present invention.
  • the server sends the prompting streaming media content to the terminal, and clearly describes the cause of the error and the processing opinion in the streaming media content.
  • the server still sends a successful command to the terminal when the abnormal condition is found.
  • RTSP Real-Time Transport Protocol
  • OTIONS Operation
  • SETUP Settings
  • Play PLAY
  • Pause PAUSE
  • Disconnect TEARDOW
  • the "Status-Line” is defined in the RTSP response message, which is the first line of the complete response message, followed by the protocol version (RTSP- Version), the status code in numeric form, and the corresponding word text ( Reason-Phrase Composition, each element is separated by a space (SP), except for the carriage return line feed (CRLF) at the end, a separate carriage return (CR) or line feed (LF) character is not allowed.
  • SP carriage return line feed
  • LF carriage return line feed
  • LF line feed
  • Reason-Phrase is a short text that describes the reason the status code is generated.
  • the status code is used to support automatic operation.
  • the cause analysis is prepared for human users. The client does not need to check or display the cause analysis.
  • the first digit of the status code defines the category of the response, and the last two digits are not specifically categorized. There are five possible values for the first digit:
  • Lxx means reserved and will be used in the future.
  • 3xx indicates success, and operations are received, understood, and accepted.
  • 3xx means redirect (Redirection), and further operations are required to complete the request.
  • 4xx indicates that the client has an error and the request has a syntax error or cannot be implemented.
  • 5xx indicates that the server is in error and the server cannot implement a legitimate request.
  • the network system in this embodiment includes a terminal 31, an access network 33, and a streaming media server 32.
  • the access network 33 provides information exchange for the terminal 31 and the streaming server 32.
  • the terminal 31 requests the streaming media content from the streaming media server 32 through the access network 33, and after receiving the correct response message returned by the streaming media server 32, continues to send the next message and receives the correct response, so that the message may exist in each message. Error; after establishing a play connection with the streaming server 32, receiving streaming media content.
  • the streaming media server 32 receives each request message sent by the terminal 31 through the access network 33, and returns a correct response message to the terminal 31 when the discovery message is abnormal, records an abnormal condition locally, and receives an exception according to the local record when receiving the play request message.
  • the streaming media content with the error prompt corresponding to the abnormality is sent to the terminal 31, the user is notified of the abnormality that has occurred, and a suggestion for solving the abnormality is provided.
  • the streaming media server 32 in this embodiment includes a receiving unit 401, a processing unit 402, a recording unit 403, and a transmitting unit 404.
  • the receiving unit 401 receives each request message sent by the terminal 31.
  • the processing unit 402 performs a correlation check on the information in the message, instructs the recording unit 403 to record the abnormality when an abnormality is found, generates a correct response message, and receives from the recording unit 403 when the play request message is received.
  • the abnormal record is acquired, and the streaming content with the error prompt is sent to the terminal 31.
  • the recording unit 4034 records an abnormal condition based on the inspection result of the processing unit 402.
  • the transmitting unit 404 sends a correct response message and streaming media content with an error message to the terminal 31.
  • Operators can plan the attributes of streaming prompt segments, such as tag (LOGO), encoding rate, audio/video (Audio/Video, A/V) combination, file format, based on network capabilities, server capabilities, and terminal types before deployment. , prompt content, metadata (META-DATA), etc. Then, the operator creates the prompting streaming media content corresponding to the 4xx/5xx status code through the encoding system, and names the streaming media content according to the naming rules required by the streaming media server 32, and uploads the content to the specified directory of the streaming media server 32 in batches.
  • the server 32 After uploading the streaming content, it can be applied in the event of an abnormal situation.
  • the following is an example of the application of the status code 4xx.
  • the implementation of the status code 5xx is the same as that of the 4xx.
  • This embodiment provides various implementations.
  • the server 32 sends a successful command to the terminal 31 when the abnormality is found, establishes a streaming media connection with the terminal 31, and sends the streaming media content with the error prompt information.
  • the redirecting command is used to cause the terminal 31 to send a request message requesting streaming media content with error prompt information and obtain the streaming media content.
  • Step 501 The terminal 31 sends a content message (Describe message) describing the content to be accessed to the streaming server 32.
  • Step 502 The streaming media server 32 checks the file system according to the received description message, and finds that the file does not exist, locally marks the current request as "content does not exist", or marks 404, and then returns a status line to the terminal 31: 200 OK, indicating acceptance of the access message.
  • Step 503 The terminal 31 sends a Setup message to the streaming server 32, where the message includes a terminal parameter, a uniform resource location (URL) parameter, and an authentication charging parameter.
  • the message includes a terminal parameter, a uniform resource location (URL) parameter, and an authentication charging parameter.
  • Step 504 The streaming media server 32 checks the format of each parameter described in the step 503 according to the received setting message, and finds that the current request is marked as "terminal error” when an abnormality is found, and then goes to the terminal 31. Return status line: 200 OKo
  • Step 505 The terminal 31 sends a play (Play) request message to the streaming server 32 to request to play the streaming media content.
  • Step 506 The streaming media server 32 checks the internal resources (including the storage space and the carrying capacity of the CPU, etc.) according to the received broadcast message, and when the internal resources are sufficient and the localized "content does not exist" and "terminal error" are found.
  • the adapted streaming media content with an abnormal error prompt is selected according to the terminal parameters and the abnormality type, and then the status line is returned to the terminal 31: 200 OK.
  • the streaming media server 32 records the log, and expands the log parameter in the service log and the Charging Data Recording (CDR), indicating whether the playback of the error-prompted streaming media content or the normal playing streaming media content is convenient. Play statistics and billing processing.
  • CDR Charging Data Recording
  • Step 507 The streaming media server 32 sends the streaming media content with the abnormal error prompt corresponding to the "content non-existent” and the "terminal error” to the terminal 31 by using the RTP protocol, and may further include a proposal for resolving the abnormality.
  • Step 508 The terminal 31 receives and plays the streaming media content with an abnormal error prompt.
  • Step 509 After the streaming media content is played, the terminal 31 sends a Teardown message to the streaming media server 32 to stop playing.
  • Step 510 The streaming server 32 ends the transmission of the streaming media content, and returns a 200 OK to the terminal 31.
  • Scheme 2 in this embodiment
  • the server 32 transmits the address of the streaming media content with the abnormal error prompt to the terminal 31 through the redirect command, and further transmits the streaming media content with the abnormal error prompt to the terminal.
  • the status code defined by the RTSP protocol 3 ⁇ represents redirection, and the following is a description of the status code 302.
  • Step 601 The terminal 31 sends a content message (Describe message) describing the content to be accessed to the streaming server 32.
  • Step 602 The streaming media server 32 checks the file system according to the received description message, and finds that the requested file does not exist, and locally marks the current request as "content does not exist", or marks 404. The status line is then returned to terminal 31: 200 OK, indicating acceptance of the access message.
  • Step 603 The terminal 31 sends a setting message to the streaming media server 32, where the message includes a terminal parameter, a uniform resource positioning parameter, and an authentication charging parameter.
  • Step 604 The streaming media server 32 checks each parameter described in step 603 according to the received setting message, and finds that the current request is marked as "terminal error when the format of each parameter is abnormal, and then returns the status line to the terminal 31. : 200 OK.
  • Step 605 The terminal 31 sends a play request message to the streaming media server 32, requesting to play the streaming media content, where the request message includes the address of the requested streaming media content, an example is as follows:
  • Step 606 The streaming media server 32 checks the mark of the local record according to the received play message, and returns the redirect code 302 and the URL to the terminal 31 when the mark "content does not exist" is found: RTSP://SERVER-IP/tip/ Notfound.3gp , the address provides prompt information corresponding to the above exception, and is saved in streaming form.
  • the prompt information also includes a solution to the abnormal situation.
  • Step 607 After receiving the response, the terminal 31 sends a streaming service request message requesting the prompt information to the streaming server 32 again according to the received U L .
  • the server 32 may have multiple processing modes, such as: the server 32 checks the request message, repeats step 602 to step 605, or adopts the method described in the first scheme. Methods. If the request message is found to be abnormal, the prompt information corresponding to the two discovered abnormalities is sent to the terminal 31 in streaming form. For example, the server 32 adds a flag bit in the redirect command. Correspondingly, the request message also includes the flag bit. When the server 32 finds the flag bit, the server does not need to check the request message and directly send the flag. Successful command, continue to step 608. This is a better implementation. The flag bit may be a special flag; or the number of requests sent by the recorded terminal 31. When the terminal error is found N consecutive times, the request message is not checked when the Nth time the request message is received, directly A successful command is returned to the terminal 31.
  • the server 32 checks the request message, repeats step 602 to step 605, or adopts the method described in the first scheme. Methods. If the request message is found to be abnormal, the prompt information corresponding to
  • Step 608 The streaming server 32 checks that the internal resource is sufficient to return the status line to the terminal 31: 200 ⁇ .
  • Step 610 The terminal 31 receives and plays the streaming media content with the abnormal error prompt corresponding to the status code 302.
  • Step 611 After the streaming media content is played, the terminal 31 sends a Teardown message to the streaming server 32 to stop playing, and then proceeds to step 612. Alternatively, the streaming server 32 actively disconnects the streaming media.
  • Step 612 The streaming server 32 ends the transmission of the streaming media content, and returns a status line to the terminal 31: 200 OK.
  • the streaming media server marks the abnormality locally when the abnormal condition is found, and sends a correct response message to the terminal, so that the terminal can normally receive the streaming media content with the abnormal error prompt, so that the user can clearly understand the abnormality. And get the solution.
  • the present invention can be used to improve the experience of the abnormal scene without any new development. Moreover, users no longer have experience differences due to differences in mobile phones.
  • the invention solves the uncertainty and flexibility of the protocol at the service layer.
  • the explanation and suggestion of various abnormal scenarios can be predefined by the operator in the experience.
  • the present invention prompts the user in the form of streaming media content, so regardless of the language supported by the terminal operating system, any language can be used in the streaming media content produced by the operator.
  • the present invention does not change the basic architecture and form of the streaming media service, and only occupies very little storage space of the server (usually only a few hundred MB). Due to the limited exception scenarios, the amount of prompt streaming media that needs to be produced is limited, and does not bring about a significant additional workload.
  • the produced streaming media content only needs to be placed in the specified directory of the server, and the update work is simple. Moreover, operators can often change the content, style, and LOGO of the prompts to keep the user's freshness and improve the user's experience.
  • the present invention uniformly defines the streaming media content of the error prompt by the operator, so that even if the terminal device is different, the user only needs to explain what kind of streaming media content is seen, and the customer service personnel can answer the reason and reduce the burden on the guest.
  • the invention also utilizes the redirection command represented by the status code 3xx specified by the RTSP protocol to enable the terminal to obtain Get an exception message.
  • the streaming media server 32 continues to send a success command to the terminal 31 when the abnormality is found during the connection and the terminal 31, and establishes a streaming media connection with the terminal 31 to implement the streaming media format to the terminal 31. Send a message about the exception so that the user knows clearly what is happening.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)

Description

一种处理流媒体业务异常的方法及装置
技术领域
本发明涉及通信领域， 特别是在请求流媒体业务过程中处理流媒体业务异 常的方法及装置。 背景技术
流媒体是一种把影像和声音信息进行压缩处理后， 以媒体流的方式（不是 整个文件下载的方式）提供给用户观赏的技术。 它实现了在低带宽环境下实时、 连续地提供高质量影音效果的功能。 流媒体技术包括媒体数据的采集、 压缩、 存储、 传输等多项技术。 流媒体部署到第二代 /第三代移动网络后， 运营商可以 开展各种基于流媒体的多媒体业务， 包括手机电视、 手机点播、 移动网络冲浪、 场所监控、 手机游戏、 新闻、 广告、 视频会议、 远程教育等业务。
一个典型的流某体系统由用户终端（特别是手机）、 接入网和流媒体服务器 构成， 参见图 1所示。 终端与服务器间使用实时流协议（Real Time Streaming Protocol, 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 )、 断连（TEARDOW )等。 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种取值可能：
lxx表示保留， 将来使用。
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发送带有错误提示的流媒体内容。
记录单元 4034艮据处理单元 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 OKo
步骤 505: 终端 31向流媒体服务器 32发送播放（Play )请求消息， 请求播 放流媒体内容。
步骤 506: 流媒体服务器 32根据接收到的播放消息检查内部资源 （包括存 储空间和 CPU 的承载能力等）， 并在内部资源足够和发现本地已经标记的 "内 容不存在" 和 "终端错误" 时， 根据终端参数和异常种类选择适配的带有异常 错误提示的流媒体内容， 然后向终端 31返回状态行： 200 OK。
流媒体服务器 32 记录日志， 在业务日志和计费数据记录（Charging Data Recording, CDR ) 中可扩展日志参数， 说明本次播放的是错误提示性的流媒体 内容还是正常播放的流媒体内容， 便于播放统计和计费处理等。
步骤 507: 流媒体服务器 32应用 RTP协议向终端 31发送与 "内容不存在" 和 "终端错误" 对应的带有异常错误提示的流媒体内容， 其中还可以包括解决 该异常的建议。
步骤 508: 终端 31接收并播放带有异常错误提示的流媒体内容。
步骤 509: 流媒体内容播放完毕， 终端 31 向流媒体服务器 32发送断连 ( Teardown ) 消息， 停止播放。
步骤 510:流媒体服务器 32结束流媒体内容的传输，向终端 31返回 200 OK。 本实施例中的方案二
本实施例中服务器 32通过重定向命令向终端 31发送带有异常错误提示的 流媒体内容的地址，并进一步向终端发送带有异常错误提示的流媒体内容。 RTSP 协议定义了的状态代码 3χχ代表重定向, 下面以状态代码 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收到响应后根据收到的 U L再次向流媒体服务器 32发 送请求提示信息的流媒体业务请求消息。
服务器 32在接收到请求提示信息的流媒体业务请求消息后可以有多种处理 方式， 如一种方式为： 服务器 32对该请求消息进行检查， 重复步骤 602到步骤 605, 或者采用方案一中所述的方法。 如果发现该请求消息也出现异常时， 将两 次发现的异常所对应的提示信息以流媒体形式发送到终端 31。如另一种方式为： 服务器 32在重定向命令中增加标志位，相应的，该请求消息中也包含该标志位； 服务器 32在发现该标志位时不需对该请求消息进行检查， 直接发送成功命令， 继续步骤 608。 这是一种较佳的实现方法。 标志位可以是一种特殊的标志； 或者 是记录的终端 31发送的请求次数， 当连续 N - 1次发现终端错误时， 在第 N次 接收到请求消息时不需对请求消息进行检查， 直接向终端 31返回成功命令。
步骤 608:流媒体服务器 32检查内部资源足够时向终端 31返回状态行： 200 οκ。 步骤 609: 流媒体服务器 32应用 RTP协议向终端 31发送带有异常错误提 示的流媒体内容。
步骤 610: 终端 31接收并播放与状态代码 302对应的带有异常错误提示的 流媒体内容。
步骤 611 : 流媒体内容播放完毕，终端 31向流媒体服务器 32发送 Teardown 消息， 停止播放， 继续步驟 612。 或者， 流媒体服务器 32主动断开流媒体连接。
步骤 612:流媒体服务器 32结束流媒体内容的传输，向终端 31返回状态行： 200 OK。
本实施例中流媒体良务器在发现异常状况时在本地标记异常， 并向终端发 送正确响应消息， 使终端可以正常接收到带有异常错误提示的流媒体内容， 以 使用户可以清楚的了解异常并获知解决办法。 终端只要能正常使用流媒体业务 就可利用本发明改善异常场景的体验， 不需任何新开发。 并且， 用户不再因为 手机的差别而有体验上的差异。
本发明在业务层解决了协议的不确定和灵活性， 对于一个完整的、 确定的 流媒体业务系统， 各种异常场景的原因解释和建议， 可以在体验上由运营商统 一预定义。 本发明采用流媒体内容的形式提示用户， 所以与终端操作系统支持 的语言无关， 运营商制作的流媒体内容中可使用任何语言。
同时， 本发明不改动流媒体业务的基本架构和形态， 仅占用服务器极少的 存储空间 （通常仅几百 MB )。 由于常见的异常场景有限， 所以需要制作的提示 性流媒体内容也数量有限， 不会带来明显的附加工作量； 制作的流媒体内容只 需要放置在服务器的指定目录， 更新工作简单。 并且， 运营商可以经常改变提 示片断的内容、 风格、 提示画面的 LOGO等， 保持用户的新鲜感， 提高用户的 体验。 本发明由运营商统一定义错误提示的流媒体内容， 从而即使终端设备不 同， 用户只需要说明看到了什么样的流媒体内容， 客服人员即可解答原因， 减 轻了客月 员的负担。
本发明还利用了 RTSP协议规定的状态代码 3xx代表的重定向命令使终端获 得异常提示信息。
综上所述， 本发明实施例中， 流媒体服务器 32与终端 31进行连接交互过 程中发现异常时继续向终端 31发送成功命令， 与终端 31建立流媒体连接， 实 现通过流媒体形式向终端 31发送关于异常的提示信息， 使用户清楚的知道发生 的异常状况。
显然， 本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发 明的精神和范围。 这样， 倘若对本发明的这些修改和变型属于本发明权利要求 及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权利要求
1、 一种处理流媒体业务异常的方法， 其特征在于， 包括以下步骤： 服务器在与发送流媒体业务请求的终端设备进行连接的交互过程中发现异 常时， 继续与该终端设备建立流媒体连接； 以及
所述服务器将关于所述异常的提示信息以流媒体形式通过所述流媒体连接 发送给所述终端设备。
2、 如权利要求 1所述的处理流媒体业务异常的方法， 其特征在于， 所述服
3、 如权利要求 2所述的处理流媒体业务异常的方法， 其特征在于， 所述服 务器在本地标记所述异常 , 在接收到播放 Play请求消息并发现所述异常的标记 后发送所述提示信息。
4、 如权利要求 1所述的处理流媒体业务异常的方法， 其特征在于， 所述服 务器在本地标记所述异常， 并在接收到播放 Play请求消息以及发现所述异常的 标记时向所述终端设备返回包括所述提示信息的地址的重定向命令； 并在接收 到所述终端设备根据所述提示信息地址向服务器发送的用于请求所述提示信息 的流媒体业务请求时， 与所述终端设备建立所述流媒体连接并发送所述提示信 it
5、 如权利要求 4所述的处理流媒体业务异常的方法， 其特征在于， 所述重 定向命令还包括标志位， 相应的， 所述请求提示信息的流媒体业务请求也包括 所述标志位； 所述服务器发现所述标志位时直接向所述终端设备返回成功命令。
6、 如权利要求 4所述的处理流媒体业务异常的方法， 其特征在于， 所述服 务器对所述流媒体业务请求进行检查， 并在确定该流媒体业务请求异常时， 将 对应的提示信息以流媒体形式发送到所述终端设备。
7、 如权利要求 6所述的处理流媒体业务异常的方法， 其特征在于， 所述服 务器对所述流媒体业务请求进行检查时, 记录该流媒体业务请求发生异常的次 数， 并在确定该次数达到设定阈值时， 直接向所述终端设备返回成功命令。
8、 如权利要求 1所述的处理流媒体业务异常的方法， 其特征在于， 所述提 示信息包括用于描述所述异常的信息， 或者包括用于描述所述异常的信息和解 决所述异常的方法。
9、 如权利要求 1至 8中的任一项所述的处理流媒体业务异常的方法， 其特 征在于， 所述服务器在发送所述提示信息时， 记录本次发送的流媒体为提示信 息。
10、 一种流媒体服务器， 其特征在于， 包括：
接收单元， 用于接收终端设备发送的流媒体业务请求；
处理单元， 用于在与所述终端设备进行连接的交互过程中发现异常时， 继 续与该终端建立流媒体连接， 以及获得流媒体形式的提示信息；
发送单元， 用于通过所述流媒体连接将流媒体形式的所述提示信息发送给 所述终端设备。
11、 如权利要求 10所述的流媒体服务器， 其特征在于， 所述处理单元发现 所述异常时仍然向所述终端设备返回成功命令。
12、 如权利要求 11所述的流媒体服务器， 其特征在于， 所述处理单元确定 终端设备发送的用于请求提示信息的流媒体业务请求包括预设的标志位时， 直
13、 如权利要求 11所述的流媒体服务器， 其特征在于， 还包括记录单元， 所述处理单元对终端设备发送的用于请求提示信息的流媒体业务请求进行检查 时， 由所述记录单元记录该流媒体业务请求发生异常的次数， 所述处理单元在 确定该次数达到设定阈值时， 直接生成向所述终端设备返回的成功命令。
14、 一种通信系统， 其特征在于， 包括：
终端设备， 用于向服务器发送请求并接收该服务器发送的响应消息和流媒 体内容；
所述服务器， 用于在与所述终端设备进行连接的交互过程中发现异常时， 继续与该终端设备建立流媒体连接， 以及将关于所述异常的提示信息以流媒体 形式通过所述流媒体连接发送给所述终端设备。
15、 如权利要求 14所述的通信系统， 其特征在于， 所述服务器发现所述异 常时仍然向所述终端设备返回成功命令。
16、 如权利要求 14所述的通信系统， 其特征在于， 所述服务器包括： 接收单元， 用于接收终端设备发送的流媒体业务请求；
处理单元， 用于在与所述终端设备进行连接的交互过程中发现异常时， 继 续与该终端建立流媒体连接， 以及获得流媒体形式的提示信息；
发送单元， 用于通过所述流媒体连接将流媒体形式的所述提示信息发送给 所述终端设备。
PCT/CN2007/003530 2006-12-14 2007-12-11 Procédé et dispositif pour traiter une anomalie de service WO2008071083A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN 200610165898 CN1996997B (zh) 2006-12-14 2006-12-14 一种处理流媒体业务异常的方法及装置
CN200610165898.3 2006-12-14

Publications (1)

Publication Number Publication Date
WO2008071083A1 true WO2008071083A1 (fr) 2008-06-19

Family

ID=38251928

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/003530 WO2008071083A1 (fr) 2006-12-14 2007-12-11 Procédé et dispositif pour traiter une anomalie de service

Country Status (2)

Country Link
CN (1) CN1996997B (zh)
WO (1) WO2008071083A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105721953A (zh) * 2016-04-28 2016-06-29 乐视控股（北京）有限公司 流媒体视频起播异常分析方法和系统
CN107294792A (zh) * 2017-07-25 2017-10-24 山东中创软件商用中间件股份有限公司 一种应用服务器的消息通知方法及装置
CN113938741A (zh) * 2021-12-08 2022-01-14 聚好看科技股份有限公司 服务器及媒资播放异常处理方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103391303B (zh) * 2012-05-09 2014-11-05 腾讯科技（深圳）有限公司 服务故障公告方法及使用该方法的服务器
CN111356017B (zh) * 2018-12-24 2022-05-13 浙江宇视科技有限公司 一种视频监控网络设备保活方法及装置
CN112020089B (zh) * 2020-08-18 2023-09-29 爱迪欧科技（深圳）有限公司 交互异常处理方法、终端及可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859266A (zh) * 2005-12-27 2006-11-08 华为技术有限公司 一种提供流媒体业务信息的方法及装置
CN1863206A (zh) * 2005-12-23 2006-11-15 华为技术有限公司 流媒体业务异常处理的方法、移动终端及系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100461757C (zh) * 2005-10-20 2009-02-11 华为技术有限公司 实时流媒体传输方法及系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1863206A (zh) * 2005-12-23 2006-11-15 华为技术有限公司 流媒体业务异常处理的方法、移动终端及系统
CN1859266A (zh) * 2005-12-27 2006-11-08 华为技术有限公司 一种提供流媒体业务信息的方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SCHULZRINNE ET AL.: "Real Time Streaming Protocol", RFC2326.TXT, 30 April 1998 (1998-04-30), pages 23 - 30 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105721953A (zh) * 2016-04-28 2016-06-29 乐视控股（北京）有限公司 流媒体视频起播异常分析方法和系统
CN107294792A (zh) * 2017-07-25 2017-10-24 山东中创软件商用中间件股份有限公司 一种应用服务器的消息通知方法及装置
CN113938741A (zh) * 2021-12-08 2022-01-14 聚好看科技股份有限公司 服务器及媒资播放异常处理方法
CN113938741B (zh) * 2021-12-08 2023-08-11 聚好看科技股份有限公司 服务器及媒资播放异常处理方法

Also Published As

Publication number Publication date
CN1996997B (zh) 2011-10-26
CN1996997A (zh) 2007-07-11

Similar Documents

Publication Publication Date Title
US10708351B1 (en) System and method for managing media content
US10116572B2 (en) Method, device, and system for acquiring streaming media data
US7752202B2 (en) Information processing and, content distribution apparatus method, and program with conversion identification information
KR101758613B1 (ko) 방송 컨텐츠 제공 방법 및 장치와 그 시스템
US7996538B2 (en) Information processing apparatus and content information processing method for transmitting content and event information to a client
US20090157753A1 (en) System for realistically reproducing multimedia content and method thereof
US20090254960A1 (en) Method for a clustered centralized streaming system
KR20120092622A (ko) 데이터 세그먼트의 선택적 방송전달을 가지는 스트리밍
CN102084661A (zh) 代理功能性
WO2008071083A1 (fr) Procédé et dispositif pour traiter une anomalie de service
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
JP5651558B2 (ja) 管理サーバ、映像配信制御システム及び映像配信制御方法
CN105812831B (zh) 网络节目的录制方法、装置、系统以及播放方法、装置
KR101496326B1 (ko) 복수의 서비스 제공자의 웹 기반 서비스를 제공/수신하기위한 방법 및 장치
JP2007524167A (ja) ストリーミングサービスにおけるアセット情報の送信
CN108810475A (zh) 一种基于Onvif标准及Sip协议的Android视频监控装置
KR100606800B1 (ko) 이동통신 단말기의 멀티미디어 스트리밍 서비스 제공방법및 스트리밍 서비스 시스템
WO2010057391A1 (zh) 一种流媒体播放控制方法、设备及系统
WO2007137500A1 (fr) Système vidéo public et son procédé de mise en oeuvre
US20160173551A1 (en) System and method for session mobility for adaptive bitrate streaming
WO2021178559A1 (en) Smart notification for over-the-top (ott) streaming among multiple devices
CN101088081A (zh) 在多媒体流中用于发信号报告客户机速率能力的方法
KR101745367B1 (ko) 하이퍼텍스트 전송 프로토콜을 이용한 멀티미디어 컨텐츠 스트리밍 시스템 및 방법
KR101527512B1 (ko) 이종의 매체 간 컨텐츠 연동 재생 방법
KR20090052033A (ko) 멀티미디어 컨텐츠 데이터 운용방법 및 시스템과 이를 위한기록매체

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07845886

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07845886

Country of ref document: EP

Kind code of ref document: A1