On-demand fault processing method and device under coexistence of IPTV and OTT, electronic equipment and IPTV system

Abstract

The invention discloses an on-demand fault processing method and device under coexistence of IPTV and OTT, electronic equipment and an IPTV system, and belongs to the technical field of IPTV / OTT videos. The processing method comprises the following steps: receiving an on-demand fault request of a user, and distinguishing IPTV on-demand or OTT on-demand according to a service domain identifier; if the video-on-demand is IPTV video-on-demand, sequentially checking whether the states of one or more of the following components are normal: a video service controller (VSC), a service management system, a resource scheduling server (RRS) and a streaming media server (HMS); if the video-on-demand is the OTT video-on-demand, sequentially checking whether the states of one or more of the following components are normal: a VSC, a service management system, an RRS, an HMS and a play key acquisition link of a content provider CP; and repairing the corresponding fault of the component according to the check result. According to the method, the problems of high troubleshooting difficulty and low troubleshooting efficiency of the platform side under the coexistence of the IPTV and the OTT in the prior art can be solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of IPTV (Internet Protocol Television) / OTT (Over-The-Top) video, and particularly relates to a method and device for handling on-demand failures in the coexistence of IPTV and OTT, an electronic device, and an IPTV system. Background Art

[0002] Traditional IPTV systems provide on-demand services based on RTSP (Real Time Streaming Protocol) / RTP (Real-time Transport Protocol). However, their closed architecture makes it difficult to support Internet streaming media protocols such as HLS (HTTP Live Streaming), resulting in a single content resource, poor mobile device adaptability, and difficulty in meeting the diverse needs of users.

[0003]

[0004] If an OTT content provider is introduced into the IPTV system, due to the lack of a multi-protocol coordination mechanism, platform-side fault handling still relies on manual distinction between RTSP and HLS problems, resulting in low efficiency. In addition, new processes such as key authentication and fragmented transmission for OTT on-demand further increase the difficulty of fault troubleshooting. Therefore, there is an urgent need for an on-demand fault handling method that supports the coexistence of IPTV and OTT to improve operation and maintenance efficiency and ensure the user experience.

[0005] Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a method and device for handling on-demand failures in the coexistence of IPTV and OTT, an electronic device, and an IPTV system, which can quickly diagnose platform-side fault problems in the coexistence of IPTV and OTT and automatically repair the faults to ensure the user experience.

[0007] ​​In a first aspect, the present invention provides a method for handling on-demand failures in the coexistence of IPTV and OTT, which is applied to an IPTV system and includes: receiving a user's on-demand failure request, and distinguishing IPTV on-demand or OTT on-demand according to the service domain identifier, wherein the C2 work order when injecting IPTV on-demand content and OTT on-demand content in the IPTV system carries the corresponding service domain identifier; if it is IPTV on-demand, sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), and Streaming Media Server (HMS); if it is OTT on-demand, sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), and the playback key acquisition link of the Content Provider (CP); repair the corresponding failures of the components according to the inspection results.

[0008] In some embodiments, the sequentially checking whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), and Streaming Media Server (HMS) specifically includes: checking whether there are any alarms in the logs of the Video Service Controller (VSC), where the VSC logs include access logs, interface logs, and running logs; in response to there being no alarms in the VSC logs, checking whether the subscription of the Service Management System is normal; in response to the subscription being normal, checking whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal; in response to the HMS scheduling result being normal, checking whether the running status of the HMS is normal.

[0009] In some embodiments, the sequentially checking whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), and the playback key acquisition link of the Content Provider (CP) specifically includes: checking whether there are any alarms in the logs of the Video Service Controller (VSC), where the VSC logs include access logs, interface logs, and running logs; in response to there being no alarms in the VSC logs, checking whether the subscription of the Service Management System is normal; in response to the subscription being normal, checking whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal; in response to the HMS scheduling result being normal, checking whether the running status of the HMS is normal; in response to the HMS running status being normal, checking whether it is normal to obtain the playback key from the Content Provider (CP); in response to being unable to obtain the playback key, checking the link between the Reverse Proxy Server (RP) and the CP, and whether the server logs on the CP side are normal.

[0010] In some embodiments, the method for handling on-demand failures in the coexistence of IPTV and OTT further includes: real-time collecting and retrieving the log data of the VSC, RRS, and HMS.

[0011] In some embodiments, checking whether there is an alarm in the log of the check video service controller VSC specifically includes: locating the corresponding VSC according to the user IP address; retrieving whether there is an alarm in the log of the VSC.

[0012] Checking whether the subscription of the service management system is normal specifically includes: checking whether the subscription content of the user in the service management system matches the on-demand content.

[0013] Checking whether the streaming media server HMS scheduling result of the resource scheduling server RRS is normal specifically includes: checking whether RRS returns the HMS address to the user; if RRS does not return the HMS address, retrieving whether there is an alarm in the log of RRS.

[0014] Checking whether the running status of HMS is normal specifically includes: retrieving whether there are alarm logs for the CPU, memory, and hard disk of HMS.

[0015] In a second aspect, the present invention further provides a processing device for on-demand failure in the coexistence of IPTV and OTT, which is applied to an IPTV system and includes:

[0016] A distinguishing module, configured to receive a user on-demand failure request and distinguish IPTV on-demand or OTT on-demand according to the service domain identifier, wherein the C2 work order when injecting IPTV on-demand content and OTT on-demand content in the IPTV system carries the corresponding service domain identifier.

[0017] A processing module, connected to the distinguishing module. If it is IPTV on-demand, it is configured to sequentially check whether the status of one or more of the following components is normal: video service controller VSC, service management system, resource scheduling server RRS, streaming media server HMS, or, if it is OTT on-demand, it is configured to sequentially check whether the status of one or more of the following components is normal: video service controller VSC, service management system, resource scheduling server RRS, streaming media server HMS, the play key acquisition link of the content provider CP, and is configured to repair the corresponding failures of the components according to the check results.

[0018] In a third aspect, the present invention further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to implement the method for processing on-demand failures in the coexistence of IPTV and OTT as described in the first aspect.

[0019] In a fourth aspect, the present invention further provides an IPTV system with the coexistence of IPTV and OTT, including a content delivery network CDN platform, a broadcast control gateway, and the electronic device described in the third aspect.

[0020] A broadcast control gateway is used to receive C2 work orders and distribute them to the CDN platform to inject IPTV on-demand content and OTT on-demand content into the IPTV system. The C2 work order carries a service domain identifier, which is used to distinguish between IPTV on-demand and OTT on-demand.

[0021] The CDN platform includes at least two hierarchically deployed streaming media server clusters, and the CDN platform is used to store and transmit IPTV on-demand content and OTT on-demand content.

[0022] The CDN platform is connected to the electronic device described in the third aspect.

[0023] In some embodiments, the IPTV system with coexisting IPTV and OTT further includes an IPTV bearer network and a public network proxy.

[0024] The public network proxy is provided between the IPTV bearer network and the content provider and is used to connect the IPTV bearer network and the content provider.

[0025] The public network proxy includes two firewalls, two three-layer switches, and two public network proxy servers.

[0026] The IPTV bearer network is respectively connected to the two three-layer switches. The two public network proxy servers are dual-connected to the two three-layer switches. The two three-layer switches are respectively connected to the two firewalls, and the two firewalls are respectively connected to the public network.

[0027] The method and device for handling on-demand faults, the electronic device, and the IPTV system provided by the present invention under the coexistence of IPTV and OTT distinguish IPTV on-demand and OTT on-demand through the service domain identifier, and sequentially check whether the corresponding component status is normal. Among them, the C2 work order when injecting IPTV on-demand content and OTT on-demand content into the IPTV system carries the corresponding service domain identifier. The protocol is automatically distinguished through the service domain identifier, and an automated fault handling process covering the entire IPTV and OTT link is constructed, so as to quickly and automatically identify and repair platform-side fault problems under the coexistence of the two on-demand services, and ensure the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is a flowchart of a user watching IPTV on-demand in Embodiment 1 of the present invention;

[0029] Figure 2 It is a flowchart of a user watching OTT on-demand in Embodiment 1 of the present invention;

[0030] Figure 3 It is a flowchart of a method for handling on-demand faults under the coexistence of IPTV and OTT in Embodiment 1 of the present invention;

[0031] Figure 4Flow chart of another method for handling on-demand failures in the coexistence of IPTV and OTT according to Embodiment 1 of the present invention;

[0032] Figure 5 Schematic diagram of an OTT on-demand content injection IPTV system according to Embodiment 4 of the present invention;

[0033] Figure 6 Network access schematic diagram of introducing an OTT video source into an IPTV system according to Embodiment 4 of the present invention;

[0034] Figure 7 Network access schematic diagram of a public network proxy according to Embodiment 4 of the present invention. Detailed implementation manners

[0035] To enable those skilled in the art to better understand the technical solutions of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0036] It can be understood that the specific embodiments and the accompanying drawings described herein are only used to explain the present invention, rather than limiting the present invention.

[0037] It can be understood that, without conflict, the various embodiments and the various features in the embodiments of the present invention can be combined with each other.

[0038] It can be understood that, for the sake of convenience of description, only the parts related to the present invention are shown in the accompanying drawings of the present invention, and the parts unrelated to the present invention are not shown in the accompanying drawings.

[0039] It can be understood that each unit and module involved in the embodiments of the present invention may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple units and modules may also be integrated into one entity structure.

[0040] It can be understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of the present invention may occur in an order different from that marked in the accompanying drawings.

[0041] It can be understood that in the flowcharts and block diagrams of the present invention, the possible architectures, functions, and operations of the systems, devices, equipment, and methods according to the various embodiments of the present invention are shown. Among them, each block in the flowchart or block diagram may represent a unit, module, program segment, or code, which contains executable instructions for implementing the specified function. Moreover, each block or combination of blocks in the block diagram and flowchart can be implemented by a hardware-based system for implementing the specified function, or by a combination of hardware and computer instructions.

[0042] It is understandable that the units and modules involved in the embodiments of the present invention can be implemented in software or in hardware. For example, the units and modules can be located in a processor.

[0043] Embodiment 1:

[0044] In this embodiment, based on the IPTV system, IPTV on-demand and OTT on-demand services are provided for users to meet the diverse needs of users and improve the user experience. However, at the same time, it also brings new challenges to operation and maintenance, and requires the operator to conduct more refined management and optimization of the business process. Therefore, based on the on-demand process of providing IPTV on-demand and OTT on-demand services for users by the IPTV system, this embodiment provides a method for handling on-demand failures in the coexistence of IPTV and OTT.

[0045] Among them, as Figure 1 shown, the process for a user to watch IPTV on-demand on the IPTV system includes S11 - S19:

[0046] S11, the set-top box sends an IPTV on-demand play request to the VSC.

[0047] S12, the VSC performs service authentication with the service management system (abbreviated as service management).

[0048] S13, the service management system returns the authentication result.

[0049] S14, the VSC returns the play URL (Uniform Resource Locator) to the set-top box.

[0050] S15, the set-top box requests the media stream from the RRS according to the play URL.

[0051] S16, the RRS schedules to a healthy HMS according to the HMS health status.

[0052] S17, the set-top box requests the media stream from the HMS.

[0053] S18, the HMS returns the media stream to the set-top box.

[0054] S19, the set-top box plays the on-demand content.

[0055] As Figure 2 shown, the process for a user to watch OTT on-demand based on the IPTV system includes S21 - S35:

[0056] S21, the set-top box sends an HLS on-demand play request to the VSC.

[0057] S22, the VSC performs service authentication with the service management system.

[0058] S23, the service management system returns the authentication result.

[0059] S24, the VSC returns the playback URL to the set-top box.

[0060] S25, the set-top box requests the index.m3u8 file from the RRS according to the playback URL.

[0061] S26, the RRS schedules to a healthy HMS according to the HMS health status.

[0062] S27, the set-top box sends an HTTP GET request to the HMS to request the index.m3u8 file.

[0063] S28, the HMS returns the index.m3u8 file to the set-top box.

[0064] S29, the set-top box requests the shard list information of 01.m3u8 from the HMS.

[0065] S30, the HMS returns the 01.m3u8 shard list file.

[0066] S31, the set-top box requests the TS (Transport Stream) shard file from the HMS according to the shard information of 01.m3u8.

[0067] S32, the HMS returns the TS shard file to the set-top box.

[0068] S33, the set-top box requests the playback key from the content provider CP.

[0069] S34, the content provider returns the playback key.

[0070] S35, the set-top box decrypts and plays the on-demand content.

[0071] As Figure 3 shown, a method for handling on-demand failures in the coexistence of IPTV and OTT includes:

[0072] Step 101, receive the user's on-demand failure request, and distinguish between IPTV on-demand or OTT on-demand according to the service domain identifier. Among them, the C2 work order when injecting IPTV on-demand content and OTT on-demand content in the IPTV system carries the corresponding service domain identifier.

[0073] Among them, on-demand failures include failures such as on-demand black screen, playback stuttering, and inability to watch on-demand. The service domain identifier of IPTV on-demand content is the first service domain identifier (e.g., BizDomain = 0), and the service domain identifier of OTT on-demand content is the second service domain identifier (e.g., BizDomain = 2). The C2 work order refers to the content transmitted through the C2 interface in the IPTV system. Through network transformation, such as expanding the BizDomain field in the C2 interface, the C2 work order can carry the corresponding service domain identifier, realizing the coexistence of IPTV and OTT on-demand content and providing a basis for judging the fault type.

[0074] In this embodiment, the methods for obtaining the service domain identifier include: parsing the service domain identifier in the on-demand address (provided that the on-demand address includes the service domain identifier), or determining the transport protocol according to the on-demand address and obtaining the service domain identifier corresponding to the current on-demand failure according to the mapping relationship between the transport protocol and the service domain identifier. For example, for IPTV on-demand: BizDomain = 0, and the on-demand address format is rtsp: / / ... For OTT on-demand: BizDomain = 2, and the on-demand address format is http: / / ... / index.m3u8 .

[0075] Step 102: If it is IPTV on-demand, sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), and Streaming Media Server (HMS); if it is OTT on-demand, sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), and the playback key acquisition link of the Content Provider (CP).

[0076] Step 103: Repair the corresponding faults of the components according to the inspection results.

[0077] In this embodiment, as Figure 4 shown, first judge the fault type, that is, judge whether the current on-demand failure is IPTV on-demand or OTT on-demand, and then sequentially check whether the status of the components involved in the corresponding on-demand process is normal. If in the IPTV on-demand failure, only the VSC is abnormal and the problem is eliminated after repairing it, the process ends, that is, only check whether the status of the VSC is normal and repair the corresponding faults of the VSC according to the inspection results to end the process. If the fault still exists, further check the status of other components in sequence. In this embodiment, the protocol is automatically distinguished through the service domain identifier, and an automated fault handling process covering the entire IPTV and OTT links is constructed, so as to quickly and automatically identify and repair the platform-side fault problems under the coexistence of the two on-demand services and ensure the user experience.

[0078] In some embodiments, the status of one or more of the following components is sequentially checked for normality: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), and Streaming Media Server (HMS). Specifically, it includes: checking whether there are any alarms in the logs of the Video Service Controller (VSC), where the VSC logs include access logs, interface logs, and running logs; in response to there being no alarms in the VSC logs, checking whether the subscription of the Service Management System is normal; in response to the subscription being normal, checking whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal; in response to the HMS scheduling result being normal, checking whether the running status of the HMS is normal. This embodiment is applicable to troubleshooting IPTV on-demand failures.

[0079] In some embodiments, the status of one or more of the following components is sequentially checked for normality: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), and the play key acquisition link of the Content Provider (CP). Specifically, it includes: checking whether there are any alarms in the logs of the Video Service Controller (VSC), where the VSC logs include access logs, interface logs, and running logs; in response to there being no alarms in the VSC logs, checking whether the subscription of the Service Management System is normal; in response to the subscription being normal, checking whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal; in response to the HMS scheduling result being normal, checking whether the running status of the HMS is normal; in response to the HMS running status being normal, checking whether it is normal to obtain the play key from the Content Provider (CP); in response to being unable to obtain the play key, checking the link between the Reverse Proxy Server (RP) and the CP, and whether the server logs on the CP side are normal. This embodiment is applicable to troubleshooting OTT on-demand failures.

[0080] In some embodiments, the method for handling on-demand failures in the coexistence of IPTV and OTT further includes: real-time collecting and retrieving the log data of the VSC, RRS, and HMS.

[0081] Exemplarily, DigitalView is deployed in an IPTV system to collect and retrieve the log data of VSC, RRS, and HMS in real time. DigitalView is a centralized log collection and analysis system used to collect, store, and retrieve the log data of various components (such as VSC, RRS, HMS, etc.) in the IPTV system. It has functions of log aggregation, fault diagnosis, and alarm correlation. Among them, log aggregation refers to collecting operation logs, interface logs, alarm information, etc. from distributed devices (such as VSC, HMS); fault diagnosis refers to quickly locating abnormal logs through keywords (such as user IP, error code); alarm correlation refers to automatically correlating the logs of multiple components to assist in analyzing the root cause of the fault (for example, the HMS downtime causes the RRS scheduling failure). Collecting and retrieving the log data of VSC, RRS, and HMS in real time can replace the inefficient way of manually logging in to devices one by one to view logs in the traditional method, realize automated fault location, and is the key support for quickly handling faults.

[0082] In some embodiments, to check whether there is an alarm in the log of the video service controller VSC, it specifically includes: locating the corresponding VSC according to the user IP address; retrieving whether there is an alarm in the log of the VSC. For example, access logs are used to check whether user requests reach the VSC; interface logs are used to verify whether the authentication interaction between the VSC and the service management system is successful (such as authentication timeout or failure records); operation logs are used to view the service process status (such as crash restart records, thread block alarms). If an abnormality is found, restart the VSC service or switch to a standby node to repair the fault. If there is no alarm in the log of the VSC, proceed to the next step of checking the service management system.

[0083] Check whether the subscription in the service management system is normal, which specifically includes: checking whether the subscription content of the user in the service management system matches the on-demand content. For example, input the user ID and query whether the subscription record matches the on-demand content (such as the user has not subscribed to the movie or the package has expired). If an abnormality is found, correct the user subscription data or temporarily grant permissions to repair the fault. If the service management system is normal, proceed to the next step of checking the RRS.

[0084] Check whether the streaming media server HMS scheduling result of the resource scheduling server RRS is normal, specifically including: checking whether RRS returns the HMS address to the user; if RRS does not return the HMS address, retrieve whether there is an alarm in the RRS log. Example, input the user IP, query whether RRS returns the HMS server address, if the HMS address is not returned (scheduling exception), check the RRS log, such as checking the scheduling service log, whether there is a failure of the load balancing policy (such as all HMS nodes are marked as unavailable), if abnormal, adjust the RRS scheduling policy (such as reducing the HMS load threshold) to repair the fault. Such as checking the health check log, whether the HMS heartbeat detection times out, if abnormal, restart the RRS scheduling service to repair the fault. If there is no alarm in the RRS log, proceed to the next step of HMS inspection.

[0085] Check whether the HMS running status is normal, specifically including: retrieving whether there are alarm logs for the CPU, memory, and hard disk of HMS. Example, if there is an alarm for insufficient memory, release the memory or restart the HMS service, or switch to the standby HMS node to repair the fault. If the HMS running status is normal and it is OTT on-demand, proceed to the next step of key link inspection.

[0086] Example, checking whether it is normal to obtain the play key from the content provider CP includes: verifying whether the key request is successfully sent to the CP, checking whether the firewall intercepts the request. If the key acquisition fails, adjust the firewall policy (such as allowing the CP domain name / IP), or restart the public network proxy service to repair the fault.

[0087] Exemplarily, a specific method for handling on-demand failures in the coexistence of IPTV and OTT is provided, including:

[0088] Step 1: Receive a user's report of a fault that they cannot watch on-demand. First, determine whether the on-demand is IPTV on-demand or OTT on-demand.

[0089] IPTV content characteristics: BizDomain = 0, on-demand address is rtsp: / / .

[0090] OTT content characteristics: BizDomain = 2, on-demand address is http: / / ... / .m3u8 .

[0091] Step 2: If it is IPTV on-demand, enter the IPTV processing flow in Step 3; if it is OTT on-demand, enter the OTT processing flow in Step 4.

[0092] Step 3: DigitalView collects the logs of all components and saves them to the local database, then retrieves them locally. First, check whether the VSC is normal. According to the user's IP address, it can be known which VSC server the EDS (Edge Delivery Service) schedules the user to. Retrieve the alarm logs of this VSC through DigitalView, view the access logs, interface logs, running logs, etc. of the VSC server, and perform repairs; if the VSC is normal, check whether the subscription of the service management system is normal. If the service management system is abnormal, check whether the user's subscribed content is correct; if the service management system is normal, check whether the RRS is normal. Under normal circumstances, DigitalView can retrieve the logs of this user being scheduled to the HMS. If the RRS does not return the address of the HMS to the user, it means that the RRS scheduling is abnormal. Retrieve the alarm logs of this RRS through DigitalView, view the scheduling service logs of the RRS server, and repair the RRS server; if the RRS server is normal, check whether the HMS is normal. Retrieve the alarm logs of this HMS through DigitalView, view the CPU alarm, memory alarm, hard disk damage and other logs, and perform repairs.

[0093] Step 4: First, check whether the VSC is normal. According to the user's IP address, it can be known which VSC server the EDS schedules the user to. Retrieve the alarm logs of this VSC through DigitalView, view the access logs, interface logs, running logs, etc. of the VSC server, and perform repairs; if the VSC is normal, check whether the subscription of the service management system is normal. If the service management system is abnormal, check whether the user's subscribed content is correct; if the service management system is normal, check whether the RRS is normal. Under normal circumstances, DigitalView can retrieve the logs of this user being scheduled to the HMS. If the RRS does not return the address of the HMS to the user, it means that the RRS scheduling is abnormal. Retrieve the alarm logs of this RRS through DigitalView, view the scheduling service logs of the RRS server, and repair the RRS server; if the RRS server is normal, check whether the HMS is normal. Retrieve the alarm logs of this HMS through DigitalView, view the CPU alarm, memory alarm, hard disk damage and other logs, and perform repairs; if the HMS is normal, check whether it is normal to obtain the playback key from the CP. If the playback key cannot be obtained, check the RP and CP lines and the server logs on the CP side for repairs.

[0094] The method for handling on-demand failures in the coexistence of IPTV and OTT in this embodiment differentiates IPTV on-demand and OTT on-demand through service domain identifiers, and sequentially checks whether the status of the corresponding components is normal. Among them, the C2 work order when injecting IPTV on-demand content and OTT on-demand content into the IPTV system carries the corresponding service domain identifier. The protocol is automatically differentiated through the service domain identifier, and an automated fault handling process covering the entire IPTV and OTT links is constructed, so as to quickly and automatically identify and repair platform-side fault problems in the coexistence of the two on-demand services, and ensure the user experience. In addition, by collecting and retrieving the log data of VSC, RRS, and HMS in real time, it can replace the inefficient method of manually logging in to devices one by one to view logs in the traditional way, and realize automated fault location, which is the key support for quickly handling faults.

[0095] Embodiment 2:

[0096] This embodiment provides a device for handling on-demand failures in the coexistence of IPTV and OTT, which is applied to the IPTV system and includes:

[0097] A differentiation module, configured to receive a user on-demand failure request and differentiate IPTV on-demand or OTT on-demand according to a service domain identifier. Among them, the C2 work order when injecting IPTV on-demand content and OTT on-demand content into the IPTV system carries the corresponding service domain identifier.

[0098] A processing module, connected to the differentiation module. If it is IPTV on-demand, it is used to sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), and Streaming Media Server (HMS). Or, if it is OTT on-demand, it is used to sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), and the playback key acquisition link of the Content Provider (CP), and is used to repair the corresponding faults of the components according to the inspection results.

[0099] In some embodiments, the processing module is used to check whether there are any alarms in the logs of the Video Service Controller (VSC). The VSC logs include access logs, interface logs, and running logs. In response to there being no alarms in the VSC logs, it is further used to check whether the subscription of the Service Management System is normal. In response to the subscription being normal, it is further used to check whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal. In response to the HMS scheduling result being normal, it is further used to check whether the running status of HMS is normal.

[0100] In some embodiments, the processing module is further configured to, in response to the normal operation status of the HMS, check whether it is normal to obtain the play key from the content provider CP. In response to the inability to obtain the play key, it is further configured to check the link between the reverse proxy server RP and the CP, and whether the server log on the CP side is normal.

[0101] In some embodiments, the device for handling on-demand failures in the coexistence of IPTV and OTT further includes an acquisition module. The acquisition module is connected to the processing module and is configured to collect and retrieve the log data of the VSC, RRS, and HMS in real time.

[0102] In some embodiments, the processing module is configured to locate to the corresponding VSC according to the user IP address and retrieve whether there is an alarm in the log of the VSC. It is also configured to check whether the subscribed content of the user in the service management system matches the on-demand content. It is also configured to check whether the RRS returns the HMS address to the user. If the RRS does not return the HMS address, retrieve whether there is an alarm in the log of the RRS. It is also configured to retrieve whether there is an alarm log in the CPU, memory, and hard disk of the HMS.

[0103] Embodiment 3:

[0104] This embodiment provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to implement the method for handling on-demand failures in the coexistence of IPTV and OTT as described in Embodiment 1.

[0105] Embodiment 4:

[0106] This embodiment provides an IPTV system with the coexistence of IPTV and OTT, including a content delivery network CDN platform, a broadcast control gateway, and the electronic device of Embodiment 3.

[0107] The broadcast control gateway is configured to receive a C2 work order and distribute it to the CDN platform to inject IPTV on-demand content and OTT on-demand content into the IPTV system. The C2 work order carries a service domain identifier, and the service domain identifier is used to distinguish IPTV on-demand and OTT on-demand.

[0108] The CDN platform includes at least two hierarchically deployed streaming server clusters. The CDN platform is configured to store and transmit IPTV on-demand content and OTT on-demand content.

[0109] The CDN platform is connected to the electronic device of Embodiment 3.

[0110] Example: An IPTV system has two CDN platforms, namely CDN1 and CDN2. The CDN platform adopts a hierarchical networking and two-level architecture, and is a content delivery network constructed by hierarchically deploying streaming media servers. It is located between the video source system and the IPTV bearer network and completes functions such as video data import, storage, distribution, and service. To provide IPTV on-demand and OTT on-demand services in the IPTV system, the transformation content of the IPTV system in this embodiment is as follows: To support the injection of OTT on-demand content in the M3U8 format, the IPTV system is transformed. After the transformation, the original IPTV on-demand content and OTT on-demand content can be distinguished, and content injection is completed by transforming the C2 interface (adding a BizDomain field to the ADI (Application Delivery Infrastructure) of the C2 interface). The IPTV system supports injecting IPTV content and OTT content simultaneously.

[0111] As Figure 5 shown, injecting OTT on-demand content in the IPTV system includes: The CP uploads the content data to the FTP (File Transfer Protocol) server, issues it to the broadcast control gateway and CDN through a C2 work order, and distinguishes the work order by adding a BizDomain field to the ADI of the C2 interface. 0 represents IPTV content, and 2 represents OTT content. It is issued to the two platforms of CDN1 and CDN2 through the broadcast control gateway to complete content injection. This transformation solution realizes the integrated bearer of traditional IPTV services and OTT on-demand services through interface extension, ensuring the continuity of existing services and providing a standardized access solution for the newly added OTT content in the M3U8 format. The deployment mode of the dual CDN platform also ensures the high availability of content distribution. It should be noted that the IPTV system may also include a radio and television review module, and the radio and television review module is respectively connected to the content provider and the broadcast control gateway.

[0112] In some embodiments, the IPTV system further includes an IPTV bearer network and a public network proxy.

[0113] The public network proxy is provided between the IPTV bearer network and the content provider and is used to connect the IPTV bearer network and the content provider. The public network proxy includes two firewalls, two three-layer switches, and two public network proxy servers. The IPTV bearer network is respectively connected to the two three-layer switches, the two public network proxy servers are dual-connected to the two three-layer switches, the two three-layer switches are respectively connected to the two firewalls, and the two firewalls are respectively connected to the public network.

[0114] In this embodiment, to obtain the playback key of the OTT on-demand content in the M3U8 format, as Figure 6As shown, the IPTV bearer network is connected to the content provider, and a secure and reliable network access method is proposed. A firewall is set up between the public network and the IPTV bearer network to ensure the security of the IPTV system. Figure 6 and Figure 7 The IPTV network in refers to the IPTV bearer network. For each content provider introduced, a set of network user access to the content provider (CP - public network - firewall - public network proxy - IPTV bearer network) is built to obtain the playback key.

[0115] In addition, as Figure 7 shown, two RP (Reverse Proxy) devices of the IPTV bearer network are respectively connected to two three - layer switches of the public network proxy for load sharing; two public network proxy servers are dual - uplinked to two three - layer switches for load sharing; two three - layer switches are respectively uplinked to two firewalls for load sharing; two firewalls are respectively uplinked to the public network. In this embodiment, through multi - level network isolation and strict access control, the secure interconnection with the content provider is realized on the premise of ensuring the security of the IPTV system boundary.

[0116] It can be understood that the above embodiments are only exemplary embodiments adopted to illustrate the principle of the present invention. However, the present invention is not limited thereto. For those of ordinary skill in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also regarded as the protection scope of the present invention.

Claims

1. A method for handling on-demand failures in the coexistence of IPTV and OTT, which is applied to an IPTV system, characterized in that, Including: Receiving a user's on-demand fault request, and distinguishing IPTV on-demand or OTT on-demand according to the service domain identifier, wherein the C2 work order when injecting IPTV on-demand content and OTT on-demand content in the IPTV system carries the corresponding service domain identifier; If it is IPTV on-demand, sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS); If it is OTT on-demand, sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), and the playback key acquisition link of the Content Provider (CP); Repair the corresponding faults of the components according to the inspection results.

2. The method according to claim 1, wherein The sequentially checking whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS) specifically includes: Checking whether there are any alarms in the logs of the Video Service Controller (VSC), and the VSC logs include access logs, interface logs, and running logs; In response to there being no alarms in the logs of the VSC, checking whether the subscription of the Service Management System is normal; In response to the subscription being normal, checking whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal; In response to the HMS scheduling result being normal, checking whether the running status of the HMS is normal.

3. The method according to claim 1, characterized in that, The sequentially checking whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), and the playback key acquisition link of the Content Provider (CP) specifically includes: Checking whether there are any alarms in the logs of the Video Service Controller (VSC), and the VSC logs include access logs, interface logs, and running logs; In response to there being no alarms in the logs of the VSC, checking whether the subscription of the Service Management System is normal; In response to the subscription being normal, checking whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal; In response to the HMS scheduling result being normal, checking whether the running status of the HMS is normal; In response to the running status of the HMS being normal, checking whether it is normal to obtain the playback key from the Content Provider (CP); In response to being unable to obtain the playback key, checking the link between the Reverse Proxy Server (RP) and the CP, and whether the server logs on the CP side are normal.

4. The method according to claim 1, wherein Also including: Real-time collecting and retrieving the log data of the VSC, RRS, and HMS.

5. The method according to any one of claims 2 or 3, characterized in that, The specifically checking whether there are any alarms in the logs of the Video Service Controller (VSC) includes: Locating the corresponding VSC according to the user IP address; Retrieving whether there are any alarms in the logs of the VSC; The specifically checking whether the subscription of the Service Management System is normal includes: Checking whether the subscribed content of the user in the Service Management System matches the on-demand content; The specifically checking whether the scheduling result of the Streaming Media Server (HMS) by the Resource Scheduling Server (RRS) is normal includes: Checking whether the RRS returns the HMS address to the user; If the RRS does not return the HMS address, retrieving whether there are any alarms in the logs of the RRS; Checking whether the HMS is running normally specifically includes: Retrieving alarm logs of the CPU, memory, and hard disk of the HMS.

6. A processing device for on-demand failures in the coexistence of IPTV and OTT, applied to an IPTV system, characterized in that, Including: The distinguishing module is used to receive the user's on-demand failure request and distinguish IPTV on-demand or OTT on-demand according to the service domain identifier. Among them, the C2 work order when injecting IPTV on-demand content and OTT on-demand content into the IPTV system carries the corresponding service domain identifier. The processing module is connected to the distinguishing module. If it is IPTV on-demand, it is used to sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS); or, if it is OTT on-demand, it is used to sequentially check whether the status of one or more of the following components is normal: Video Service Controller (VSC), Service Management System, Resource Scheduling Server (RRS), Streaming Media Server (HMS), the playback key acquisition link of the Content Provider (CP), and is used to repair the corresponding faults of the components according to the inspection results.

7. An electronic device, characterized in that, It includes a memory and a processor. A computer program is stored in the memory, and the processor is set to run the computer program to implement the method for handling on-demand failures in the coexistence of IPTV and OTT as described in any one of claims 1 to 5.

8. An IPTV system with coexistence of IPTV and OTT, characterized in that, It includes a Content Delivery Network (CDN) platform, a broadcast control gateway, and the electronic device described in claim 7. The broadcast control gateway is used to receive the C2 work order and distribute it to the CDN platform to inject IPTV on-demand content and OTT on-demand content into the IPTV system. The C2 work order carries a service domain identifier, and the service domain identifier is used to distinguish IPTV on-demand and OTT on-demand. The CDN platform includes at least two hierarchically deployed streaming media server clusters, and the CDN platform is used to store and transmit IPTV on-demand content and OTT on-demand content. The CDN platform is connected to the electronic device described in claim 7.

9. The IPTV system according to claim 8, characterized in that, It further includes an IPTV bearer network and a public network proxy. The public network proxy is arranged between the IPTV bearer network and the content provider and is used to connect the IPTV bearer network and the content provider. The public network proxy includes two firewalls, two layer-3 switches, and two public network proxy servers. The IPTV bearer network is respectively connected to the two layer-3 switches. The two public network proxy servers are dual-connected to the two layer-3 switches. The two layer-3 switches are respectively connected to the two firewalls, and the two firewalls are respectively connected to the public network.

Images