CN112202826B - Video networking cross-domain communication method, device, equipment and medium supporting sub-control - Google Patents

Video networking cross-domain communication method, device, equipment and medium supporting sub-control Download PDF

Info

Publication number
CN112202826B
CN112202826B CN202011429968.8A CN202011429968A CN112202826B CN 112202826 B CN112202826 B CN 112202826B CN 202011429968 A CN202011429968 A CN 202011429968A CN 112202826 B CN112202826 B CN 112202826B
Authority
CN
China
Prior art keywords
domain
autonomous
cross
server
audio
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN202011429968.8A
Other languages
Chinese (zh)
Other versions
CN112202826A (en
Inventor
杨春晖
王艳辉
韩杰
郭霄峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hainan Shilian Communication Technology Co ltd
Original Assignee
Visionvera Information Technology 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 Visionvera Information Technology Co Ltd filed Critical Visionvera Information Technology Co Ltd
Priority to CN202011429968.8A priority Critical patent/CN112202826B/en
Publication of CN112202826A publication Critical patent/CN112202826A/en
Application granted granted Critical
Publication of CN112202826B publication Critical patent/CN112202826B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The embodiment of the application provides a video networking cross-domain communication method, device, equipment and medium supporting sub-control, belongs to the technical field of communication, and aims to improve the security of video networking cross-domain communication, wherein the video networking comprises a plurality of autonomous domains, each autonomous domain comprises at least one autonomous server and a plurality of terminals, and the method comprises the following steps: when data is transmitted across domains, data transmitted in the autonomous domain is encrypted and transmitted by using an intra-domain unicast key of the autonomous domain; carrying out data encryption transmission on non-audio and video data transmitted between autonomous domains by using a cross-domain unicast key, wherein the cross-domain unicast key is generated by negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission; and carrying out data encryption transmission on the audio and video data transmitted between autonomous domains by using a cross-domain multicast key, wherein the cross-domain multicast key is generated by a terminal requesting to create a cross-domain transmission video networking service.

Description

Video networking cross-domain communication method, device, equipment and medium supporting sub-control
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, a device, and a medium for supporting cross-domain communication of a video networking.
Background
The video networking adopts the most advanced worldwide Vision Vera real-time high-definition video exchange technology, realizes the real-time transmission of the whole-network high-definition video which cannot be realized by the current Internet, integrates dozens of services such as high-definition video conferences, video monitoring, remote training, intelligent monitoring analysis, emergency command, video telephone, live broadcast, television mails, information distribution and the like into a system platform, and realizes the real-time interconnection and intercommunication of high-definition quality video communication through various devices.
At present, the video network comprises a plurality of autonomous video networks in different domains, and in practice, some video network services, such as video network conference services, call services of monitoring videos, and the like, often need to be held between the autonomous video networks in the different domains, but in the existing cross-area video network services, the security of the video network services cannot be guaranteed.
Disclosure of Invention
In view of the above problems, embodiments of the present application have been proposed to provide a method, an apparatus, a device and a medium for cross-domain communication of video networking supporting sub-control, so as to overcome the above problems or at least partially solve the above problems.
In a first aspect of an embodiment of the present application, a cross-domain communication method of a video networking supporting sub-control is disclosed, where the video networking includes multiple autonomous domains, and each autonomous domain includes at least one autonomous server and multiple terminals, and the method includes:
when data is transmitted across domains, data transmitted in the autonomous domain is encrypted and transmitted by using an intra-domain unicast key of the autonomous domain;
carrying out data encryption transmission on non-audio and video data transmitted between autonomous domains by using a cross-domain unicast key, wherein the cross-domain unicast key is generated by negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission;
and carrying out data encryption transmission on the audio and video data transmitted between autonomous domains by using a cross-domain multicast key, wherein the cross-domain multicast key is generated by a terminal requesting to create a cross-domain transmission video networking service.
Optionally, the non-audio/video data includes the cross-domain multicast key and/or signaling;
the signaling is used for cross-domain service control between different autonomous domains.
Optionally, the performing data encryption transmission on the non-audio/video data transmitted between the autonomous domains by using a cross-domain unicast key includes:
a first autonomous server in one autonomous domain participating in cross-domain transmission encrypts non-audio and video data to be transmitted by using the cross-domain unicast key;
and the first autonomous server transmits the encrypted non-audio and video data to a second autonomous server in another autonomous domain participating in cross-domain transmission.
Optionally, the non-audio/video data includes a signaling, where the signaling at least includes service configuration information of a cross-domain transmission video networking service; the method for carrying out data encryption transmission on the non-audio and video data transmitted between the autonomous domains by using the cross-domain unicast key comprises the following steps:
the first autonomous server receives the service configuration information sent by the terminal, and creates a video networking service according to the service configuration information;
and the first autonomous server encrypts the service configuration information by using the cross-domain unicast key and transmits the encrypted service configuration information to the second autonomous server so as to request the second autonomous server to participate in the video networking service together.
Optionally, the non-audio/video data includes the cross-domain multicast key, and the data encryption transmission of the non-audio/video data transmitted between autonomous domains by using the cross-domain unicast key includes:
after receiving an instruction that the terminal indicates a video networking service to start, the first autonomous server encrypts the cross-domain multicast key by using the cross-domain unicast key;
and the first autonomous server sends the encrypted cross-domain multicast key to the second autonomous server.
Optionally, each autonomous domain further includes at least one core server, where the autonomous server is connected to the terminal through the core server, and the performing data encryption transmission on the audio and video data transmitted between autonomous domains by using a cross-domain multicast key includes:
when a terminal in one autonomous domain participating in cross-domain transmission requests cross-domain transmission of audio and video data, the cross-domain multicast key is adopted to encrypt the audio and video data, the encrypted audio and video data are uploaded to a first core server in the autonomous domain, and the first core server forwards the encrypted audio and video data to a second core server in another autonomous domain participating in cross-domain transmission.
Optionally, the method further comprises:
the first core server receives the cross-domain multicast key and a terminal list corresponding to the video networking service, wherein the cross-domain multicast key and the terminal list are sent by an autonomous server in the autonomous domain by utilizing an intra-domain unicast key in the autonomous domain for encryption;
and the first core server polls each terminal in the terminal list and located in the autonomous domain, pulls the polled online terminal into the video network service, and encrypts and sends the cross-domain multicast key to the online terminal by using an intra-domain unicast key of the autonomous domain.
In a second aspect of the embodiments of the present application, there is provided a video networking cross-domain communication device supporting sub-control, where the video networking includes multiple autonomous domains, each autonomous domain includes at least one autonomous server and multiple terminals, and the device is located in each autonomous domain, and includes:
the first encryption transmission module is used for carrying out data encryption transmission on data transmitted in the autonomous domain by using an intra-domain unicast key of the autonomous domain when the data are transmitted in a cross-domain manner;
the second encryption transmission module is used for carrying out data encryption transmission on non-audio and video data transmitted between autonomous domains by using a cross-domain unicast key, wherein the cross-domain unicast key is generated by negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission;
and the third encryption transmission module is used for carrying out data encryption transmission on the audio and video data transmitted between the autonomous domains by using a cross-domain multicast key, wherein the cross-domain multicast key is generated by a terminal requesting to create a cross-domain transmission video networking service.
The embodiment of the application also discloses an electronic device, which comprises: one or more processors; and
one or more machine-readable media having instructions stored thereon, which when executed by the one or more processors, cause the apparatus to perform a method of inter-view networking cross-domain communication supporting decentralized control as described in the first aspect of embodiments of the present application.
The embodiment of the present application further discloses a computer-readable storage medium, which stores a computer program to enable a processor to execute the method for supporting cross-domain communication of video networking according to the first aspect of the embodiment of the present application.
The embodiment of the application has the following advantages:
in the embodiment of the application, for each autonomous domain, the intra-domain unicast key of the autonomous domain is used for carrying out data encryption transmission on the data transmitted in the autonomous domain; the method comprises the steps of carrying out data encryption transmission on non-audio and video data transmitted across different autonomous domains by using a cross-domain unicast key, and carrying out data encryption transmission on the audio and video data transmitted across different autonomous domains by using a cross-domain multicast key, wherein the cross-domain multicast key is generated by a terminal requesting to create a video networking service for cross-domain transmission, and the cross-domain unicast key is generated by the autonomous server and an autonomous server in an opposite autonomous domain for cross-domain transmission in a negotiation manner.
On one hand, in the video networking service of cross-domain transmission, when data is transmitted in a cross-domain manner, corresponding keys can be used for encryption and transmission according to the type of the transmitted data, for example, non-audio and video data is transmitted by using a cross-domain unicast key when the data is transmitted in the cross-domain manner, and audio and video data is transmitted by using a cross-domain multicast key when the data is transmitted in the cross-domain manner, so different keys are used for different types of data transmission, and the transmission safety of different types of data can be improved. On the other hand, the data can be sent by using a corresponding key according to the autonomous domain in which the data transmitted across domains is located in the transmission process, for example, the data is sent by using an intra-domain unicast key in the autonomous domain, and the data is sent by using a cross-domain unicast key or a cross-domain multicast key in the inter-domain encryption mode, so that different unicast keys can be used in the whole cross-domain transmission process in the video networking service of the cross-domain transmission, and the communication security of the video networking can be improved.
In conclusion, by adopting the technical scheme of the embodiment of the application, the security of data transmission in the video network can be improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments of the present application will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive exercise.
FIG. 1 is a networking schematic of a video network of the present application;
FIG. 2 is a schematic diagram of a hardware architecture of a node server according to the present application;
fig. 3 is a schematic diagram of a hardware architecture of an access switch of the present application;
fig. 4 is a schematic diagram of a hardware structure of an ethernet protocol conversion gateway according to the present application;
FIG. 5 is a communication architecture diagram of a cross-domain communication method of video networking supporting sub-control according to an embodiment of the present application;
FIG. 6 is a flowchart illustrating steps of a cross-domain communication method for supporting sub-control in a video networking according to an embodiment of the present application;
fig. 7 is an overall flowchart of a cross-domain communication method of video networking supporting sub-control according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of a video networking cross-domain communication device supporting sub-control according to an embodiment of the present application.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present application more comprehensible, the present application is described in further detail with reference to the accompanying drawings and the detailed description.
The video network is an important milestone for network development, is a real-time network, can realize high-definition video real-time transmission, and pushes a plurality of internet applications to high-definition video, and high-definition faces.
The video networking adopts a real-time high-definition video exchange technology, can integrate required services such as dozens of services of video, voice, pictures, characters, communication, data and the like on a system platform on a network platform, such as high-definition video conference, video monitoring, intelligent monitoring analysis, emergency command, digital broadcast television, delayed television, network teaching, live broadcast, VOD on demand, television mail, Personal Video Recorder (PVR), intranet (self-office) channels, intelligent video broadcast control, information distribution and the like, and realizes high-definition quality video broadcast through a television or a computer.
To better understand the embodiments of the present application, the following description refers to the internet of view:
some of the technologies applied in the video networking are as follows:
network Technology (Network Technology)
Network technology innovation in video networking has improved the traditional Ethernet (Ethernet) to face the potentially huge first video traffic on the network. Unlike pure network Packet Switching (Packet Switching) or network Circuit Switching (Circuit Switching), the Packet Switching is adopted by the technology of the video networking to meet the Streaming requirement. The video networking technology has the advantages of flexibility, simplicity and low price of packet switching, and simultaneously has the quality and safety guarantee of circuit switching, thereby realizing the seamless connection of the whole network switching type virtual circuit and the data format.
Switching Technology (Switching Technology)
The video network adopts two advantages of asynchronism and packet switching of the Ethernet, eliminates the defects of the Ethernet on the premise of full compatibility, has end-to-end seamless connection of the whole network, is directly communicated with a user terminal, and directly bears an IP data packet. The user data does not require any format conversion across the entire network. The video networking is a higher-level form of the Ethernet, is a real-time exchange platform, can realize the real-time transmission of the whole-network large-scale high-definition video which cannot be realized by the existing Internet, and pushes a plurality of network video applications to high-definition and unification.
Server Technology (Server Technology)
The server technology on the video networking and unified video platform is different from the traditional server, the streaming media transmission of the video networking and unified video platform is established on the basis of connection orientation, the data processing capacity of the video networking and unified video platform is independent of flow and communication time, and a single network layer can contain signaling and data transmission. For voice and video services, the complexity of video networking and unified video platform streaming media processing is much simpler than that of data processing, and the efficiency is greatly improved by more than one hundred times compared with that of a traditional server.
Storage Technology (Storage Technology)
The super-high speed storage technology of the unified video platform adopts the most advanced real-time operating system in order to adapt to the media content with super-large capacity and super-large flow, the program information in the server instruction is mapped to the specific hard disk space, the media content is not passed through the server any more, and is directly sent to the user terminal instantly, and the general waiting time of the user is less than 0.2 second. The optimized sector distribution greatly reduces the mechanical motion of the magnetic head track seeking of the hard disk, the resource consumption only accounts for 20% of that of the IP internet of the same grade, but concurrent flow which is 3 times larger than that of the traditional hard disk array is generated, and the comprehensive efficiency is improved by more than 10 times.
Network Security Technology (Network Security Technology)
The structural design of the video network completely eliminates the network security problem troubling the internet structurally by the modes of independent service permission control each time, complete isolation of equipment and user data and the like, generally does not need antivirus programs and firewalls, avoids the attack of hackers and viruses, and provides a structural carefree security network for users.
Service Innovation Technology (Service Innovation Technology)
The unified video platform integrates services and transmission, and is not only automatically connected once whether a single user, a private network user or a network aggregate. The user terminal, the set-top box or the PC are directly connected to the unified video platform to obtain various multimedia video services in various forms. The unified video platform adopts a menu type configuration table mode to replace the traditional complex application programming, can realize complex application by using very few codes, and realizes infinite new service innovation.
Networking of the video network is as follows:
the video network is a centralized control network structure, and the network can be a tree network, a star network, a ring network and the like, but on the basis of the centralized control node, the whole network is controlled by the centralized control node in the network.
As shown in fig. 1, the video network is divided into an access network and a metropolitan network.
The devices of the access network part can be mainly classified into 3 types: node server, access switch, terminal (including various set-top boxes, coding boards, memories, etc.). The node server is connected to an access switch, which may be connected to a plurality of terminals and may be connected to an ethernet network.
The node server is a node which plays a centralized control function in the access network and can control the access switch and the terminal. The node server can be directly connected with the access switch or directly connected with the terminal.
Similarly, devices of the metropolitan network portion may also be classified into 3 types: a metropolitan area server, a node switch and a node server. The metro server is connected to a node switch, which may be connected to a plurality of node servers.
The node server is a node server of the access network part, namely the node server belongs to both the access network part and the metropolitan area network part.
The metropolitan area server is a node which plays a centralized control function in the metropolitan area network and can control a node switch and a node server. The metropolitan area server can be directly connected with the node switch or directly connected with the node server.
Therefore, the whole video network is a network structure with layered centralized control, and the network controlled by the node server and the metropolitan area server can be in various structures such as tree, star and ring.
The access network part can form a unified video platform (the part in the dotted circle), and a plurality of unified video platforms can form a video network; each unified video platform may be interconnected via metropolitan area and wide area video networking.
Video networking device classification
1.1 devices in the video network of the embodiment of the present application can be mainly classified into 3 types: server, exchanger (including Ethernet protocol conversion gateway), terminal (including various set-top boxes, code board, memory, etc.). The video network as a whole can be divided into a metropolitan area network (or national network, global network, etc.) and an access network.
1.2 wherein the devices of the access network part can be mainly classified into 3 types: node server, access exchanger (including Ethernet protocol conversion gateway), terminal (including various set-top boxes, coding board, memory, etc.).
The specific hardware structure of each access network device is as follows:
a node server:
as shown in fig. 2, the system mainly includes a network interface module 201, a switching engine module 202, a CPU module 203, and a disk array module 204;
the network interface module 201, the CPU module 203, and the disk array module 204 all enter the switching engine module 202; the switching engine module 202 performs an operation of looking up the address table 205 on the incoming packet, thereby obtaining the direction information of the packet; and stores the packet in a queue of the corresponding packet buffer 206 based on the packet's steering information; if the queue of the packet buffer 206 is nearly full, it is discarded; the switching engine module 202 polls all packet buffer queues for forwarding if the following conditions are met: 1) the port send buffer is not full; 2) the queue packet counter is greater than zero. The disk array module 204 mainly implements control over the hard disk, including initialization, read-write, and other operations on the hard disk; the CPU module 203 is mainly responsible for protocol processing with an access switch and a terminal (not shown in the figure), configuring an address table 205 (including a downlink protocol packet address table, an uplink protocol packet address table, and a data packet address table), and configuring the disk array module 204.
The access switch:
as shown in fig. 3, the network interface module mainly includes a network interface module (a downlink network interface module 301 and an uplink network interface module 302), a switching engine module 303 and a CPU module 304;
wherein, the packet (uplink data) coming from the downlink network interface module 301 enters the packet detection module 305; the packet detection module 305 detects whether the Destination Address (DA), the Source Address (SA), the packet type, and the packet length of the packet meet the requirements, and if so, allocates a corresponding stream identifier (stream-id) and enters the switching engine module 303, otherwise, discards the stream identifier; the packet (downstream data) coming from the upstream network interface module 302 enters the switching engine module 303; the incoming data packet of the CPU module 304 enters the switching engine module 303; the switching engine module 303 performs an operation of looking up the address table 306 on the incoming packet, thereby obtaining the direction information of the packet; if the packet entering the switching engine module 303 is from the downstream network interface to the upstream network interface, the packet is stored in the queue of the corresponding packet buffer 307 in association with the stream-id; if the queue of the packet buffer 307 is nearly full, it is discarded; if the packet entering the switching engine module 303 is not from the downlink network interface to the uplink network interface, the data packet is stored in the queue of the corresponding packet buffer 307 according to the guiding information of the packet; if the queue of the packet buffer 307 is nearly full, it is discarded.
The switching engine module 303 polls all packet buffer queues and may include two cases:
if the queue is from the downlink network interface to the uplink network interface, the following conditions are met for forwarding: 1) the port send buffer is not full; 2) the queued packet counter is greater than zero; 3) obtaining a token generated by a code rate control module;
if the queue is not from the downlink network interface to the uplink network interface, the following conditions are met for forwarding: 1) the port send buffer is not full; 2) the queue packet counter is greater than zero.
The rate control module 308 is configured by the CPU module 304, and generates tokens for packet buffer queues from all downstream network interfaces to upstream network interfaces at programmable intervals to control the rate of upstream forwarding.
The CPU module 304 is mainly responsible for protocol processing with the node server, configuration of the address table 306, and configuration of the code rate control module 308.
Ethernet protocol conversion gateway：
As shown in fig. 4, the apparatus mainly includes a network interface module (a downlink network interface module 401 and an uplink network interface module 402), a switching engine module 403, a CPU module 404, a packet detection module 405, a rate control module 408, an address table 406, a packet buffer 407, a MAC adding module 409, and a MAC deleting module 410.
Wherein, the data packet coming from the downlink network interface module 401 enters the packet detection module 405; the packet detection module 405 detects whether the ethernet MAC DA, the ethernet MAC SA, the ethernet length or frame type, the video network destination address DA, the video network source address SA, the video network packet type, and the packet length of the packet meet the requirements, and if so, allocates a corresponding stream identifier (stream-id); then, the MAC deletion module 410 subtracts MAC DA, MAC SA, length or frame type (2 byte) and enters the corresponding receiving buffer, otherwise, discards it;
the downlink network interface module 401 detects the sending buffer of the port, and if there is a packet, obtains the ethernet MAC DA of the corresponding terminal according to the destination address DA of the packet, adds the ethernet MAC DA of the terminal, the MAC SA of the ethernet protocol gateway, and the ethernet length or frame type, and sends the packet.
The other modules in the ethernet protocol gateway function similarly to the access switch.
A terminal:
the system mainly comprises a network interface module, a service processing module and a CPU module; for example, the set-top box mainly comprises a network interface module, a video and audio coding and decoding engine module and a CPU module; the coding board mainly comprises a network interface module, a video and audio coding engine module and a CPU module; the memory mainly comprises a network interface module, a CPU module and a disk array module.
1.3 devices of the metropolitan area network part can be mainly classified into 2 types: node server, node exchanger, metropolitan area server. The node switch mainly comprises a network interface module, a switching engine module and a CPU module; the metropolitan area server mainly comprises a network interface module, a switching engine module and a CPU module.
2. Video networking packet definition
2.1 Access network packet definition
The data packet of the access network mainly comprises the following parts: destination Address (DA), Source Address (SA), reserved bytes, payload (pdu), CRC.
As shown in the following table, the data packet of the access network mainly includes the following parts:
DA SA Reserved Payload CRC
wherein:
the Destination Address (DA) is composed of 8 bytes (byte), the first byte represents the type of the data packet (such as various protocol packets, multicast data packets, unicast data packets, etc.), there are 256 possibilities at most, the second byte to the sixth byte are metropolitan area network addresses, and the seventh byte and the eighth byte are access network addresses;
the Source Address (SA) is also composed of 8 bytes (byte), defined as the same as the Destination Address (DA);
the reserved byte consists of 2 bytes;
the payload part has different lengths according to the types of different datagrams, and is 64 bytes if the datagram is various protocols, and is 32 + 1024 = 1056 bytes if the datagram is a unicast datagram, and is of course not limited to the above 2 types;
the CRC consists of 4 bytes and is calculated in accordance with the standard ethernet CRC algorithm.
2.2 metropolitan area network packet definition
The topology of a metropolitan area network is a graph and there may be 2, or even more than 2, connections between two devices, i.e., there may be more than 2 connections between a node switch and a node server, a node switch and a node switch, and a node switch and a node server. However, the metro network address of the metro network device is unique, and in order to accurately describe the connection relationship between the metro network devices, parameters are introduced in the embodiment of the present application: a label to uniquely describe a metropolitan area network device.
In this specification, the definition of the Label is similar to that of the Label of MPLS (Multi-Protocol Label Switch), and assuming that there are two connections between the device a and the device B, there are 2 labels for the packet from the device a to the device B, and 2 labels for the packet from the device B to the device a. The label is classified into an incoming label and an outgoing label, and assuming that the label (incoming label) of the packet entering the device a is 0x0000, the label (outgoing label) of the packet leaving the device a may become 0x 0001. The network access process of the metro network is a network access process under centralized control, that is, address allocation and label allocation of the metro network are both dominated by the metro server, and the node switch and the node server are both passively executed, which is different from label allocation of MPLS, and label allocation of MPLS is a result of mutual negotiation between the switch and the server.
As shown in the following table, the data packet of the metro network mainly includes the following parts:
DA SA Reserved label (R) Payload CRC
Namely Destination Address (DA), Source Address (SA), Reserved byte (Reserved), tag, payload (pdu), CRC. The format of the tag may be defined by reference to the following: the tag is 32 bits with the upper 16 bits reserved and only the lower 16 bits used, and its position is between the reserved bytes and payload of the packet.
As described above, the network of views is a distributed centralized control network, and the network of views includes a plurality of autonomous domains distributed in layers, and the whole network structure is formed by connecting a plurality of structural units called autonomous domains, and the structural units of each autonomous domain form an independent network structure, so that a plurality of different autonomous domains exist in the network of views. Each autonomous domain can be used as an independent autonomous video network, and devices in the autonomous domain can communicate with each other in the autonomous domain to complete data interaction and service development. Therefore, the video network has a plurality of autonomous domains, and the insides of the respective autonomous domains can independently complete data interaction, so that each autonomous domain is equivalent to a sub-control, and thus the video network of the embodiment is also called as a video network supporting the sub-control.
In the related art, the video networking service performed between a plurality of different autonomous domains is called a cross-domain video networking service, and for the cross-domain video networking service, because data in one autonomous domain needs to be transmitted to another autonomous domain, the risk of stealing the data is increased. According to the current networking architecture of the video network, for the data security in a single autonomous domain, the data security is generally maintained by a key management server in the single autonomous domain, that is, the key management server maintains the encryption key required by the domain. When cross-region service is involved, because the key management server cannot manage keys required by other autonomous domains, the key management servers in different autonomous domains are not allowed to communicate with each other, and therefore, an effective cross-region key management protection mechanism is lacked. Therefore, when cross-region service is performed, encrypted transmission of data cannot be achieved, and the risk of stealing data always exists.
In view of this, the applicant proposes the following technical idea based on the characteristics of the video network: when cross-region service is carried out, the autonomous servers in two autonomous domains can negotiate a cross-domain unicast key, so that data transmitted in the autonomous domains can be transmitted by using the intra-domain unicast key, non-audio and video data between the autonomous domains can be transmitted by using the cross-domain unicast key, and audio and video data between the autonomous domains can be transmitted by using a cross-domain multicast key, so that the safety of data transmission can be ensured under the conditions of transmitting different types of data and different autonomous domains for data transmission.
Referring to fig. 5, a communication architecture diagram of a video network cross-domain communication method supporting sub-control according to an embodiment of the present application is shown, and as shown in fig. 5, a video network may include a plurality of different autonomous domains, which may be divided by the governed region, for example, one autonomous domain is omitted, or one autonomous domain is a city. Each autonomous domain comprises at least one autonomous server and a plurality of terminals.
In one embodiment, each autonomous domain may further include at least one core server, and the autonomous servers are communicatively connected to the plurality of terminals in the autonomous video network through the core server. One core server can be in communication connection with one or more terminals, so that the terminals can communicate with the autonomous servers through the core servers, wherein one autonomous server can be in charge of management of all the core servers in the autonomous domain, and the terminals in the autonomous domain are distributed to the corresponding core servers for communication, namely, a plurality of terminals are added into the autonomous domain through the respectively connected core servers, so that network resources in the video network are used.
When a terminal joins the autonomous video network, the autonomous server can distribute the corresponding core server for the terminal, and the autonomous server and the core server can provide corresponding forwarding service for the terminal to transmit data in the video network.
First, how to realize secure transmission of data in the present application will be described.
Referring to fig. 5, a detailed description is given of a video networking cross-domain communication method supporting sub-control according to an embodiment of the present invention, in this embodiment, the method may be mainly applied to a video networking service performed across domains, in such a video networking service, a terminal participating in the video networking service often needs to transmit data related to the video networking service across autonomous domains, so that, in order to ensure security of the video networking service, in a process of transmitting data required by the video networking service, each autonomous domain may perform corresponding following processing when transmitting data across domains:
5.1: when data is transmitted across domains, the data transmitted in the autonomous domain is encrypted and transmitted by using the intra-domain unicast key of the autonomous domain.
In this embodiment, the data transmitted in the autonomous domain may refer to that a current transmission network segment of the data transmitted across domains is in the autonomous domain. The content of the data can be encrypted by using the intra-domain unicast key, so that the secure transmission of the data in the autonomous domain is realized. The intra-domain unicast key may be generated by an autonomous server in the autonomous domain, or may be generated from a domain identifier of the autonomous domain, where the domain identifier may be understood as an identifier uniquely characterizing the autonomous domain, and may be, for example, an administrative division code, a name, an ID number, or the like of an area in which the autonomous domain is located. Thus, for an autonomous domain, the intra-domain unicast key may be associated with the autonomous domain, so that data transmitted within the autonomous domain, no matter what kind of video networking service is generated, can be encrypted and transmitted by using the unicast key corresponding to the autonomous domain. When the method is adopted, each independent autonomous domain has an independent intra-domain unicast key, and the method is used for ensuring the safety of data transmitted in the autonomous domain.
Of course, in yet another example, the intra-domain unicast key may also be generated by the autonomous server according to the current cross-domain video networking service, wherein different video networking services may generate different intra-domain unicast keys. Therefore, for the same autonomous domain, data generated by different video networking services can be encrypted by using unicast keys in different domains, so that the different video networking services have independent unicast keys in the domains, and the transmission safety of the data of each video networking service in the autonomous domain is ensured.
In the same autonomous domain, the autonomous server in the autonomous domain can distribute the intra-domain unicast key to the terminals participating in the cross-domain transmission video networking service in the autonomous domain, so that when each terminal in the autonomous domain transmits data, the source terminal can encrypt the data by using the intra-domain unicast key when transmitting the data, and further the encrypted data can be transmitted in the autonomous domain. In this way, for an independent autonomous domain, data of different cross-domain video networking services transmitted in the domain can be encrypted by using unicast keys in different domains.
5.2: and carrying out data encryption transmission on non-audio and video data transmitted between autonomous domains by using a cross-domain unicast key, wherein the cross-domain unicast key is generated by negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission.
In this embodiment, the cross-domain unicast key may be generated by negotiation between an autonomous server in the local domain and an autonomous server in an autonomous domain of an opposite end across which the video networking service is in the video networking service of cross-domain transmission, that is, the cross-domain unicast key in the present application may be associated with the video networking service performed across domains, and different video networking services across domains may have different cross-domain unicast keys. The cross-domain video networking service can be a video conference service, a monitoring and calling service, a live broadcast service, a video telephone service or a data synchronization service.
The non-audio and video data may refer to non-audio and video type data, for example, both text data and image data may be referred to as non-audio and video data. The non-audio and video data can be generated by a source terminal of the autonomous domain participating in the video networking service, and specifically, the non-audio and video data transmitted between autonomous domains can mean that the next transmission network segment of the non-audio and video data is located between network boundary nodes of different autonomous domains. In one example, the non-audio/video data may carry an address of a source terminal and an address of a destination terminal, and in this case, the autonomous domain may determine whether the non-audio/video data needs to be transmitted across domains according to the address of the source terminal and the address of the destination terminal carried by the non-audio/video data and a transmission network segment for the next transmission of the non-audio/video data.
When the autonomous domain detects that the non-audio and video data needs cross-domain transmission, the characterization needs to cross-domain transmit the non-audio and video data among different autonomous domains, and under the condition, the data content of the non-audio and video data can be encrypted by using a cross-domain unicast key and then transmitted to the autonomous domain of the opposite end.
Of course, when the non-audio/video data is transmitted across domains, three transmission sections may be included: a first transmission section from a source terminal to a network boundary of the autonomous domain, a second transmission section from the network boundary of the autonomous domain to a network boundary of an opposite autonomous domain, and a third transmission section from the network boundary of the opposite autonomous domain to a destination terminal. A network boundary of an autonomous domain may be understood as a node where an autonomous server of the autonomous domain is located or a node where a core server of the autonomous domain is located.
In practice, when the non-audio/video data is transmitted across domains, in the process of encrypting and transmitting the data of the non-audio/video data, the corresponding key may be used for encryption transmission according to the transmission section of the non-audio/video data in the transmission process, and specifically the following may be used:
in the first transmission section from the source terminal to the network boundary of the autonomous domain, the intra-domain unicast key of the autonomous domain may be used for encrypted transmission, that is, as described in section 5.1, the source terminal encrypts and sends data to the autonomous server of the autonomous domain by using the intra-domain unicast key.
And a second transmission section between the network boundary of the autonomous domain and the network boundary of the opposite autonomous domain, namely a transmission network section between network boundary nodes of different autonomous domains, performs encrypted transmission on the non-audio/video data by using a cross-domain unicast key so as to realize the safe transmission of the non-audio/video data from the autonomous server of the autonomous domain to the autonomous server in the opposite autonomous domain.
And at a third transmission road section from the network boundary in the opposite-end autonomous domain to the destination terminal, carrying out encryption transmission on the non-audio and video data by using an intra-domain unicast key in the opposite-end autonomous domain.
It can be understood that the intra-domain unicast key, the cross-domain unicast key of the autonomous domain and the intra-domain unicast key of the opposite-end autonomous domain are different from each other.
Through the mode, the transmission safety of the non-audio and video data needing to be transmitted across the autonomous domain in the whole process of transmitting the non-audio and video data from the autonomous domain to the terminal in the opposite autonomous domain is realized, and different encryption keys are adopted for encryption transmission in different transmission road sections, so that the keys of the non-audio and video data are timely replaced in the transmission process, and the transmission safety of the non-audio and video data on a transmission path is ensured.
5.3: and carrying out data encryption transmission on the audio and video data transmitted between autonomous domains by using a cross-domain multicast key, wherein the cross-domain multicast key is generated by a terminal requesting to create a cross-domain transmission video networking service.
In this embodiment, the terminal that requests to create the cross-domain transmitted video networking service may refer to an originating terminal of the cross-domain video networking service or a host terminal of the cross-domain video networking service, for example, when the video networking service is a conference service, the host terminal may be a chairman terminal of the conference, and the originating terminal may be a speaking terminal in the conference.
The cross-domain multicast key in the application can be uniquely associated with the video networking service performed in a cross-domain mode and the terminal requesting to create the video networking service transmitted in the cross-domain mode, different cross-domain video networking services of the same terminal can have different cross-domain multicast keys, and different terminals can also have different cross-domain multicast keys for the same video networking service. The cross-domain video networking service can be a video conference service, a monitoring and calling service, a live broadcast service, a video telephone service or a data synchronization service, and the cross-domain video networking service can refer to that some terminals are located in one autonomous domain and the other terminals are located in the other autonomous domain in terminals participating in the video networking service.
After the cross-domain multicast key is generated, the cross-domain multicast key can be held by all terminals participating in the video networking service, that is, the terminals participating in the video networking service in different autonomous domains can hold the cross-domain multicast key.
In this embodiment, the audio/video data may be audio/video data acquired by a terminal participating in the video networking service in real time, or audio/video data pre-stored by the terminal participating in the service. After the video networking service is started, each terminal participating in the video networking service can establish communication connection with other terminals participating in the video networking service in advance, under the condition, when the terminal sends audio and video data, audio and video data corresponding to other terminals can be generated according to the communication connection between the terminal and the other terminals, and terminal addresses of the other terminals are taken as destination addresses to be carried in data packet headers of the audio and video data.
Further, in the video networking service performed across domains, when a terminal sends audio and video data, whether other terminals are in the autonomous domain or not can be determined according to a destination address, and when the other terminals are not in the autonomous domain, the audio and video data are encrypted by using a cross-domain multicast key. Therefore, when the terminal determines that the target terminal of the audio and video data to be sent is located in an autonomous domain different from the autonomous domain, the terminal represents that the audio and video data needs to be transmitted across domains between different autonomous domains, and the audio and video data can be encrypted and transmitted to the target terminal in the opposite autonomous domain by using a cross-domain multicast key.
By adopting the technical scheme of the embodiment of the application, on one hand, when data are transmitted in a cross-domain mode in the video networking service of cross-domain transmission, corresponding keys can be used for encryption and transmission according to the type of the transmitted data, for example, cross-domain transmission non-audio and video data are transmitted by using a cross-domain unicast key, and cross-domain transmission audio and video data are transmitted by using a cross-domain multicast key, so that different keys are used for different types of data transmission, and the transmission safety of different types of data can be improved. On the other hand, the data can be sent by adopting a corresponding key according to the autonomous domain in which the cross-domain transmitted data is located in the transmission process, for example, the data is sent by using an intra-domain unicast key in the transmission of the autonomous domain, and the data is sent by using a cross-domain unicast key or a cross-domain multicast key in the encryption mode between domains, so that in the video networking service of the cross-domain transmission, the data can use different unicast keys in the whole cross-domain transmission process, and the safety in the data transmission process can be improved.
In one embodiment, for the non-audio/video data transmitted across the domain, the transmission is encrypted by using a cross-domain unicast key, and for the audio/video data transmitted across the domain, the transmission can be encrypted by using a cross-domain multicast key. On the basis, in the video network, in order to meet the requirement of high-definition real-time transmission of audio and video data among autonomous domains and quickly respond to control over video network services, different types of cross-domain transmitted data can reach an opposite autonomous domain through different transmission paths, so that reasonable distribution and utilization of network transmission resources (including bandwidth and equipment resources) are realized. Specifically, the non-audio/video data transmitted across the domains can be encrypted and transmitted to the autonomous domain of the opposite end through a transmission path where the autonomous server is located by using a cross-domain unicast key, and the audio/video data transmitted across the domains can be encrypted and transmitted to the autonomous domain of the opposite end through a transmission path of the core server directly by using a cross-domain multicast key.
Therefore, in the implementation process after the service is started, in the transmission path of the audio and video data, the transmission path cannot be occupied by the non-audio and video type data to achieve the purpose of high-definition real-time transmission, and the core server does not need to process signaling type data, so that the load of the core server is reduced, and the data forwarding efficiency of the core server is improved. In the transmission path of the non-audio and video data, the transmission path can not occupy more bandwidth by the audio and video data, so that the aims of quick transmission and quick response of the non-audio and video data are fulfilled.
Specifically, in this embodiment, when data is transmitted across domains between different autonomous domains, an autonomous server in an autonomous domain may serve as a forwarding node for transmitting non-audio/video data between different autonomous domains, and send the non-audio/video data to an autonomous server in an opposite autonomous domain using a cross-domain unicast key. And the core server in the autonomous domain can be used as a forwarding node for transmitting the audio and video data among different autonomous domains, and the cross-domain multicast key is used for sending the audio and video data to the core server in the opposite autonomous domain.
The specific non-audio and video data transmission process is as follows:
when cross-domain transmission of non-audio and video data is carried out between different autonomous domains and cross-domain transmission is carried out, a first autonomous server in one autonomous domain participating in cross-domain transmission uses a cross-domain unicast key to encrypt the non-audio and video data to be transmitted; and the first autonomous server transmits the encrypted non-audio and video data to a second autonomous server in another autonomous domain participating in cross-domain transmission.
In this example, the autonomous server in each autonomous domain may take the function of encrypting and transmitting non-audio/video data, where the non-audio/video data sent by the source terminal to the first autonomous server may be encrypted by intra-domain unicast in the local domain, and the first autonomous server may encrypt the non-audio/video data by using a cross-domain unicast key according to a destination terminal of the non-audio/video data and send the encrypted non-audio/video data to a second autonomous server in an opposite autonomous domain. Correspondingly, the second autonomous server can decrypt the non-audio and video data by using the cross-domain unicast key, encrypt the non-audio and video data by using the intra-domain unicast key held by the second autonomous server, and send the encrypted non-audio and video data to the destination terminal.
In one example, in 5.2, the non-audio/video data may include the cross-domain multicast key and/or signaling, and the signaling is used for cross-domain service control between different autonomous domains. Of course, the non-audio-video data may also include other types of data, such as terminal information, configuration information, and the like.
The signaling can include service request signaling of the video networking service, and various control signaling generated in the video networking service proceeding process. The service request signaling is used for requesting to create a cross-domain video networking service, and the service request signaling may include configuration information of the video networking service, where the configuration information may include information of the video networking service, such as the holding time, the service identifier, the required bandwidth, and a list of terminals participating in the video networking service.
Various control signaling generated during the ongoing process of the video networking service may include: service start signaling, speaker switching signaling, monitoring angle control signaling, mute control signaling, etc. Generally, the signaling transmitted across domains is used to control the terminal in the opposite-end autonomous domain to execute corresponding operations, for example, when the signaling is a camera adjustment signaling, the terminal in the opposite-end autonomous domain for conference control may adjust the camera of the terminal a. Of course, the signaling may not be limited to the signaling in the above example, and may be other signaling in practice, which is not limited in this application.
The signaling can be encrypted by using a cross-domain unicast key to ensure the transmission security of the signaling, so as to ensure the security of cross-domain control of the video networking service, for example, the video networking video conference service cannot be attacked by an attacker to hinder the normal operation of a video conference, or the attacker tampers with the conference flow of the video conference.
No matter the signaling or the cross-domain multicast key is adopted, the transmission mode of the non-audio and video data can be adopted, and the cross-domain transmission can be realized among the autonomous domains.
In the following, two non-audio/video data are taken as examples to explain a specific process of how to transmit the non-audio/video data:
in one example, the signaling at least includes service configuration information of a cross-domain transmission video networking service, where the configuration information is mainly used to create the video networking service, and in this case, after receiving the service configuration information sent by the terminal, the first autonomous server creates the cross-domain video networking service according to the service configuration information, encrypts the service configuration information using the cross-domain unicast key, and transmits the encrypted service configuration information to the second autonomous server, so as to request the second autonomous server to participate in the video networking service together.
The service configuration information may be generated according to a service creation operation performed by a user, and specifically, the user may select a terminal participating in the video networking service, so that a terminal list may be generated according to the selection of the user, where the terminal list may include an identifier of the terminal participating in the video networking service.
In this way, the first autonomous server and the second autonomous server may retain service configuration information of the video networking service, such as start time of the video networking service, network bandwidth allocation, and a terminal list participating in the service, so as to facilitate subsequent development of the video networking service.
Therefore, after the service configuration information of the video networking service is encrypted by the cross-domain unicast key and sent to the second autonomous server, the second autonomous server and the first autonomous server can participate in the video networking service together, so that the second autonomous server and the first autonomous server can form a service group to realize subsequent service of the cross-domain video networking service.
As described in the foregoing example, the non-audio/video data may include a cross-domain multicast key, and accordingly, in the video networking service, the cross-domain multicast key generated by the terminal needs to be transmitted to other terminals participating in the video networking service, and when other terminals are located in different autonomous domains, autonomous inter-domain transmission of the cross-domain multicast key is involved.
Of course, the signaling for creating the video networking service is taken as an example to illustrate how to transmit the signaling and perform the signaling, and in practice, other types of signaling, for example, signaling for controlling the rotation of the camera, may also be transmitted in the above manner.
After the service is created and before the service is started to be executed, a cross-domain multicast key generated by a terminal requesting cross-domain transmission needs to be transmitted to a target terminal in an opposite autonomous domain. Specifically, referring to fig. 6, the sending process of the cross-domain multicast key may be as follows:
step S601: and after receiving an instruction indicating the start of the video networking service by the terminal, the first autonomous server encrypts the cross-domain multicast key by using the cross-domain unicast key.
In this embodiment, a terminal requesting a cross-domain transmission video networking service may start operating according to a service performed by a user, and send an instruction indicating the start of a service request to a first autonomous server in the autonomous domain, where the instruction may carry a cross-domain multicast key generated by the terminal itself. Of course, in one example to ensure the security of the transmission of data within the domain, the instructions may be encrypted by a domain unicast key held by the first autonomous server, as shown in 5.1 above.
After receiving the instruction indicating the start of the video networking service, the first autonomous server can decrypt the instruction by using the self-owned intra-domain unicast key so as to extract the cross-domain multicast key, and encrypt the cross-domain multicast key and the stored terminal list of the cross-domain video networking service by using the cross-domain unicast key.
Step S602: and the first autonomous server sends the encrypted cross-domain multicast key to the second autonomous server.
In this embodiment, the first autonomous server may send the encrypted cross-domain multicast key to the second autonomous server. The second autonomous server may be configured to decrypt the cross-domain multicast key using the cross-domain unicast key.
As described in the above section 5.2, different keys may also be used for encryption at different transmission segments during the transmission of the cross-domain multicast key: in a first transmission section from a source terminal (a terminal requesting cross-domain transmission) to a first autonomous server, encryption transmission can be performed by using an intra-domain unicast key of the autonomous domain, in a second transmission section from the first autonomous server to a second autonomous server, encryption transmission is performed on the cross-domain multicast key by using the cross-domain unicast key, so that safe transmission of the cross-domain multicast key between different domains is realized, and correspondingly, in a third transmission section from the second autonomous server to a destination terminal, encryption transmission is performed on the cross-domain multicast key by using the intra-domain unicast key of the second autonomous server.
In practice, for terminals participating in video networking services in different autonomous domains, the cross-domain multicast key needs to be obtained before the services are really implemented, and when the cross-domain multicast key is transmitted in the autonomous domains, each autonomous domain comprises a core server, and the autonomous servers are connected with the terminals through the core servers, so that the transfer of the core servers can be performed when the cross-domain multicast key is transmitted inside the autonomous domains before the services are really implemented, and after the services are really implemented, non-audio and video data can be transferred between the autonomous servers to reach the autonomous opposite-end domain without the transfer of the core servers. Specifically, the following transmission steps of the cross-domain multicast key may be referred to:
step S603: and the first core server receives the cross-domain multicast key and a terminal list corresponding to the video networking service, which are sent by an autonomous server in the autonomous domain, wherein the cross-domain multicast key and the terminal list are sent by the autonomous server in the autonomous domain in an encrypted manner by using an intra-domain unicast key in the autonomous domain. As described in the above example, the terminal list is carried in the configuration information when the video networking service is created, and the terminal list is already held by the autonomous server when the cross-domain video networking service is created.
For the same autonomous domain, the first core server in the autonomous domain may receive a cross-domain multicast key and a terminal list, which are encrypted and sent by the autonomous server in the autonomous domain by using an intra-domain unicast key in the autonomous domain. The autonomous server in the autonomous domain referred to in this example may refer to a first autonomous server or a second autonomous server, and therefore, both the first autonomous server and the second autonomous server need to send the cross-domain multicast key to the terminal participating in the video networking service in the local domain.
Step S604: and the first core server polls each terminal in the terminal list and located in the autonomous domain, pulls the polled online terminal into the video network service, and encrypts and sends the cross-domain multicast key to the online terminal by using an intra-domain unicast key of the autonomous domain.
In this embodiment, the first core server may decrypt, using the intra-domain unicast key of the autonomous domain, to obtain the terminal list, so as to poll each terminal in the terminal list, so as to determine whether each terminal in the terminal list is online. When the terminal is on line, the first core server can pull the on-line terminal into the video network service, and encrypt the cross-domain multicast key by using the intra-domain unicast key and then send the cross-domain multicast key to the on-line terminal.
In another example, in 5.3, when audio and video data is transmitted across domains between different autonomous domains, and data encryption transmission is performed using a cross-domain multicast key, a transit device in the autonomous domain that implements the cross-domain transmission of the audio and video data may be a core server in the autonomous domain. Therefore, for the terminals in the autonomous domain, when a terminal in one autonomous domain participating in cross-domain transmission requests cross-domain transmission of audio and video data, the cross-domain multicast key can be used for encrypting the audio and video data, the encrypted audio and video data is uploaded to a first core server in the autonomous domain, and the first core server forwards the encrypted audio and video data to a second core server in another autonomous domain participating in cross-domain transmission.
In this embodiment, as for the content described in the above 5.3, when the source terminal in the autonomous domain sends the audio and video data, the source terminal may encrypt the content of the audio and video data using the cross-domain multicast key, and then transmit the encrypted audio and video data to the second core server in the autonomous domain of the opposite terminal via the first core server in the autonomous domain, and accordingly, the process of sending the audio and video data across domains may be as follows:
firstly, a terminal participating in cross-domain transmission encrypts cross-domain transmission audio and video data by using a cross-domain multicast key and then sends the encrypted cross-domain transmission audio and video data to a first core server in the autonomous domain. Then, the first core server may forward the encrypted audio/video data to a second core server in another autonomous domain participating in cross-domain transmission according to a communication path configured by the source terminal in the video networking service. And then, the second core server sends the encrypted audio and video data to a target terminal in the autonomous domain where the second core server is located. Therefore, cross-domain encryption transmission of audio and video data is realized among different autonomous domains.
In practice, some terminals participating in the cross-domain transmission video networking service may be located in the same autonomous domain, and in this case, in the cross-domain video networking service, when data needs to be transmitted between terminals in the same autonomous domain, the data does not need to be transmitted in a cross-domain manner. For example, taking fig. 5 as an example, terminal 1, terminal 2, terminal 10, and terminal 11 all participate in the same cross-domain video networking service, so that data transmission between terminal 1 and terminal 2 is performed in autonomous domain a, and data transmission between terminal 10 and terminal 11 is performed in autonomous domain B.
Correspondingly, for non-audio and video data which are only transmitted in the autonomous domain in the cross-domain video networking service, encryption transmission can be carried out through the intra-domain unicast key, specifically, a source terminal sending the non-audio and video data can encrypt the non-audio and video data by using the distributed intra-domain unicast key, then send the non-audio and video data to the autonomous server in the autonomous domain, and the autonomous server in the autonomous domain forwards the non-audio and video data to a target terminal in the autonomous domain.
And for the audio and video data transmitted in the autonomous domain in the cross-domain video networking service, the encryption transmission can be performed through the intra-domain multicast key, specifically, the source terminal sending the audio and video data can encrypt the audio and video data by using the generated intra-domain multicast key and then send the audio and video data to the first core server in the autonomous domain, and the audio and video data are forwarded to the target terminal in the autonomous domain by the first core server in the autonomous domain.
The intra-domain multicast key can be generated by a terminal generating the cross-domain multicast key or a terminal participating in the video networking service. That is, in this embodiment of the present application, a terminal participating in a video networking service may hold three keys, which are: the system comprises an intra-domain unicast key, an intra-domain multicast key and a cross-domain multicast key, wherein the intra-domain unicast key is used for helping a terminal to transmit non-audio and video data in the intra-domain in a cross-domain video networking service, the intra-domain multicast key is used for helping the terminal to transmit audio and video data in the intra-domain in the cross-domain video networking service, and the cross-domain multicast key is used for helping the terminal to transmit the audio and video data in the cross-domain video networking service.
To facilitate understanding of the technical solution of the foregoing embodiment of the present application, the following introduces, from an autonomous domain side of a sending end that sends data, the steps of the video networking cross-domain communication method supporting sub-control described in the foregoing embodiment, and an application scenario of this example may be a video networking service developed across domains, and may completely include the following steps:
step S701: the first autonomous server negotiates with a second autonomous server in an opposite autonomous domain to generate a cross-domain unicast key in response to video networking services created between different autonomous domains.
Specifically, the negotiation process of the cross-domain unicast key is described in the subsequent section 5.4.
Step S702: after receiving service configuration information used for requesting to create the cross-domain transmission video networking service by a terminal in the autonomous domain, the first autonomous server creates the video networking service and sends the service configuration information to the second autonomous server by using a cross-domain unicast key, and the first autonomous server and the second autonomous server create the video networking service based on the service configuration information and store a terminal list participating in the video networking service.
Step S703: after receiving an instruction of a terminal indicating service request starting requesting cross-domain transmission in the autonomous domain, the first autonomous server acquires a cross-domain multicast key sent by the terminal.
The cross-domain unicast key is used for encrypting and transmitting non-audio and video data which are transmitted between autonomous domains and in a cross-domain mode, wherein the non-audio and video data can comprise the cross-domain multicast key and a signaling.
Step S704: and the first autonomous server encrypts the cross-domain multicast key and the terminal list corresponding to the service by using the cross-domain unicast key, and sends the encrypted cross-domain multicast key to the second autonomous server.
Step S705: and the second core server receives the cross-domain multicast key and the terminal list which are sent by the second autonomous server through the intra-domain unicast key in the autonomous domain.
Step S706: and the first core server polls each terminal in the terminal list in the autonomous domain, pulls the polled online terminal into the service, and encrypts and sends the cross-domain multicast key to the online terminal by using an intra-domain unicast key of the autonomous domain. And the second core server polls each terminal in the terminal list in the autonomous domain, pulls the polled online terminal into the service, and encrypts and sends the cross-domain multicast key to the online terminal by using an intra-domain unicast key of the autonomous domain.
After the service is actually carried out, the following steps are executed:
step S707: when a terminal in one autonomous domain participating in cross-domain transmission requests cross-domain transmission of audio and video data, encrypting the audio and video data by using the cross-domain multicast key, and uploading the encrypted audio and video data to a first core server in the autonomous domain;
step S708: and the first core server forwards the audio and video data to a second core server participating in cross-domain transmission in another autonomous domain, so that the second core server forwards the audio and video data to a target terminal participating in video networking service.
Step S709: when a terminal in one autonomous domain participating in cross-domain transmission requests cross-domain transmission of non-audio and video data, an intra-domain unicast key is adopted to encrypt the non-audio and video data, the encrypted non-audio and video data are uploaded to a first autonomous server in the autonomous domain, and the first autonomous server encrypts the non-audio and video data to be transmitted by using the cross-domain unicast key.
Step S710: the first autonomous server transmits the non-audio and video data encrypted by the cross-domain unicast key to a second autonomous server in another autonomous domain participating in cross-domain transmission, and the second autonomous server encrypts the non-audio and video data by using the intra-domain unicast key and transmits the non-audio and video data to a target terminal of the autonomous domain where the second autonomous server is located.
5.4, a description is given of how to negotiate cross-domain unicast keys.
Specifically, data in the unicast key agreement process of the autonomous servers in different autonomous domains transmitted across domains may be encrypted by using a certificate private key; and when the negotiation is finished and the cross-domain unicast key is generated, encrypting and transmitting the cross-domain unicast key between the autonomous servers in different autonomous domains of the cross-domain transmission by using the certificate private key.
Specifically, the autonomous server in the autonomous domain may start a process of negotiating a cross-region unicast key with the autonomous server in an opposite autonomous domain in response to creation of a cross-domain video networking service, where the negotiation process may include the following negotiation stages:
the method comprises the steps of sending a negotiation request to an autonomous server of an opposite-end autonomous domain, returning an identity verification reply to the autonomous server of the opposite-end autonomous domain, and sending a cross-domain unicast key to the autonomous server of the opposite-end autonomous domain by the autonomous server of the local-end autonomous domain.
And the data in each negotiation stage can be encrypted and transmitted by adopting a certificate private key.
Specifically, in a stage when a first autonomous server of the home autonomous domain sends a negotiation request to a second autonomous server of the peer autonomous domain, the negotiation request sent by the first autonomous server may carry a certificate private key and identity information of the first autonomous server, so as to ensure security of key negotiation. The certificate private key may assist the second autonomous server in confirming whether the identity of the first autonomous server is legitimate. In specific implementation, the second autonomous server may verify the certificate private key by using the certificate private key held by the second autonomous server, and after the verification is passed, if the identity of the first autonomous server is represented to be legal, a confirmation signaling may be generated.
In a phase when the second autonomous server returns a reply of the authentication, the content of the reply is the generated confirmation signaling, wherein the confirmation signaling may also include a certificate private key held by the second autonomous server, and the certificate private key may help the first autonomous server to confirm whether the identity of the second autonomous server is legal.
When the first autonomous server confirms that the identity of the second autonomous server is legal, the stage that the first autonomous server sends the cross-domain unicast key to the second autonomous server is entered, at this moment, the first autonomous server can utilize the cross-domain unicast key generated by the encryption of the certificate private key, and the second autonomous server can utilize the self-held certificate private key to decrypt to obtain the cross-region unicast key and store the cross-region unicast key.
The second autonomous server can associate the cross-region unicast key with the first autonomous server when storing the cross-region unicast key, so that the associated cross-region unicast key can be used for decryption when receiving the non-audio/video data sent by the local autonomous domain.
In yet another embodiment, in order to increase the security of the negotiation process and ensure that the negotiation process is not attacked and stolen, the data in the negotiation process with the unicast key may be encrypted by using a random number, wherein the random number used in the next negotiation stage in the negotiation process is generated according to the random number used in the previous negotiation stage.
Specifically, in a stage of sending a negotiation request to the second autonomous server, the negotiation request may carry a random number generated by the first autonomous server for the first time, and the random number may be used for generating a new random number according to the random number after the second autonomous server passes the authentication of the first autonomous server.
In the stage that the second autonomous server returns the reply of the authentication, the new random number may be carried in the acknowledgement signaling generated by the second autonomous server, and the new random number may be used to help the first autonomous server to authenticate the new random number according to the random number generated for the first time, so as to determine that the negotiation process is not stolen or attacked.
When the first autonomous server receives a reply returned by the second autonomous server, when the verification of the carried new random number is passed and the first autonomous server confirms that the identity of the second autonomous server is legal, the stage that the first autonomous server sends a cross-domain unicast key to the second autonomous server is entered, and in the stage, when the cross-domain unicast key generated by the certificate private key is encrypted, the cross-domain unicast key can be encrypted by using another random number generated according to the new random number, so that the double-layer encryption is obtained by the cross-domain unicast key. The second autonomous server verifies the random number according to the new random number, and after the verification is passed, the second autonomous server can decrypt the random number by using a certificate private key to obtain a cross-domain unicast key.
When the method is adopted, the safety of cross-domain negotiation cross-domain unicast keys is ensured, and thus, the cross-domain unicast keys are prevented from being stolen in the negotiation process.
Referring to fig. 7, a schematic overall flow chart of a video networking cross-domain communication method supporting sub-control according to an embodiment of the present application is shown, where the embodiment takes the communication architecture shown in fig. 5 as an example, and performs simple combing on the entire data transmission process of the present application from a sending-end autonomous domain and a receiving-end autonomous domain, where the entire data transmission process includes two autonomous domains, that is, an autonomous domain a and an autonomous domain B, where the autonomous domain a is an autonomous server M1, and the autonomous domain B includes an autonomous server M2, and specifically may include the following processes:
and (I) negotiating the cross-domain unicast key.
As shown in fig. 5.4, in the negotiation process, the data in the unicast key negotiation process is encrypted by using the certificate private key and the random number, and the process is specifically realized by the following steps:
step S801: the local autonomous server M1 sends a cross-domain unicast key request to negotiate with the neighboring autonomous server M2 to generate a cross-domain unicast key, wherein the cross-domain unicast key request is created by the autonomous server M1, is protected by a certificate private key negotiated by the two autonomous servers, is sent to the autonomous server M2 and carries a random number RM1For verifying the identity of the sender and the recipient.
Step S802: the neighbor autonomous server M2 receives the cross-domain unicast key request, and encrypts R by the certificate private key of the autonomous server M2M1And returns the request of the local area with the random number of the adjacent area.
Step S803: after the local autonomous server M1 verifies the identity of the neighboring autonomous server M2, a cross-domain unicast key UK _ M1M2 is generated, the key UK _ M1M2 is a temporary key of the conference service, one key is used for a conference at a time, different conference keys are different, the keys are encrypted by a certificate private key of the autonomous server M1 and carry random numbers at the same time, and a signature is sent to the neighboring autonomous server M2.
Step S804: after receiving the ciphertext, the neighbor autonomous server M2 decrypts the information, completes the verification, obtains the cross-domain unicast key UK _ M1M2, and feeds back key confirmation information to the local autonomous server M1, where the fed-back key confirmation information may be encrypted by UK _ M1M 2.
Through the steps, cross-domain unicast keys can be obtained through negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission
And (II) a business creation process.
Step S805: when the local autonomous server M1 receives the service configuration information for creating the cross-domain conference service sent by the terminal 1, a video networking conference is created, a terminal list is stored, and the service configuration information is encrypted by using UK _ M1M2, as shown in fig. 7, the service configuration information is carried in the neighboring service autonomous request and sent to the neighboring autonomous server M2, the autonomous server M2 participates in the conference service after storing the terminal list, and can feed back the autonomous service request to the local autonomous server M1, and the autonomous server M1 feeds back the autonomous service request to the terminal 1 to inform the terminal 1 that the conference service creation is completed.
And thirdly, negotiating the process of the cross-domain multicast key when the service request starts.
In this flow, the cross-domain multicast key needs to be distributed to each of the participating terminals participating in the conference. Specifically, the flow can be implemented as the above step S601 to step S604, and the following details are described as follows:
step S806: the local autonomous server M1 receives a control instruction for starting a request of the terminal 1 for a conference service, where the control instruction carries a cross-domain multicast key MK _ GK generated by the terminal. The MK _ GK is encrypted by the intra-domain unicast key of the local domain a.
Step S807: the local autonomous server M1 uses the negotiated cross-domain unicast key UK _ M1M2 to complete the encrypted transmission of the cross-domain multicast key MK _ GK, and sends it to the neighboring autonomous server M2, so that the neighboring autonomous server M2 notifies the terminal in the autonomous domain B to participate in the conference service. Meanwhile, as shown in fig. 7, the local autonomous server M1 encrypts the cross-domain multicast key MK _ GK and the terminal list with the intra-domain unicast key UK _ M1 of the local domain, and transmits the encrypted cross-domain multicast key MK _ GK and the terminal list to the core server 1 of the local domain.
The process of sending the cross-domain multicast key MK _ GK to the terminal participating in the conference in the local area by the local autonomous server M1 may refer to the above step S603 and step S604, that is, as shown in fig. 7, the core server 1 polls the terminal 1 and the terminal 2 in the local area according to the terminal list, and after joining the online terminal 1 and the online terminal 2 to the conference, encrypts the cross-domain multicast key by using the intra-domain unicast key UK _ M1, and sends the cross-domain multicast key to the terminal 1 and the terminal 2. The core server 4 polls the terminal 6 and the terminal 10 in the local domain according to the terminal list and the cross-domain multicast key MK _ GK sent by the neighbor autonomous server M2, adds the online terminal 6 and the online terminal 10 to the conference, and then encrypts the cross-domain multicast key MK _ GK by using the intra-domain unicast key UK _ M2 and sends the cross-domain multicast key MK _ GK to the terminal 6 and the terminal 10.
Through the above-mentioned flow, the terminals 1, 2, 6 and 10 participating in the conference can be pulled into the conference, and each of the terminals 1, 2, 6 and 10 has the cross-domain multicast key MK _ GK of the terminal 2.
Subsequently, the MK _ GK can be used for encrypting and sending the cross-domain audio and video data after the service is really implemented.
Through the steps, the cross-domain service and the interaction negotiation of the cross-domain unicast key and the cross-domain multicast key are completed.
And (IV) transmitting data flow while the service is in progress.
Since the terminal 1, the terminal 2, the terminal 6 and the terminal 10 have joined the conference, so that a normal conference can be performed among the four, in this case, during the conference, the secure transmission of the data transmitted across the domain can be performed, and specifically, the processes of the above step S707 to step S710 can be performed, which is described as follows with reference to fig. 7:
step S808: when the terminal 1 in the autonomous domain a sends the cross-domain audio/video data, the multicast key MK _ GK is responsible for encrypting and then sends the encrypted audio/video data to the core server 1, the core server 1 sends the audio/video data encrypted by the multicast key MK _ GK to the core server 4 in the autonomous domain B, and the audio/video data is forwarded to the terminal 6 and the terminal 10 by the core server 4 in the autonomous domain B, so that the terminal 6 and the terminal 10 decrypt the audio/video data by using the multicast key MK _ GK obtained in advance.
Step S809: when the terminal 1 in the autonomous domain a sends the cross-domain signaling, the intra-domain unicast key UK _ M1 is responsible for encrypting and then sending the encrypted signaling to the autonomous server M1, and the autonomous server M1 decrypts the signaling by using the intra-domain unicast key UK _ M1, encrypts the signaling by using the cross-domain unicast key UK _ M1M2 and then sends the encrypted signaling to the neighbor autonomous server M2.
Step S810: the neighboring autonomous server M2 may decrypt the signaling using the cross-domain unicast key UK _ M1M2 and then execute the corresponding operation of the signaling, or encrypt the signaling using the intra-domain unicast key UK _ M2 in the autonomous domain B and then send the encrypted signaling to the corresponding execution terminal 10, so that the execution terminal 10 executes the corresponding operation according to the signaling.
The signaling in this example may be various control signaling in the above embodiment, and specifically may include: service start signaling, speaker switching signaling, monitoring angle control signaling, mute control signaling, etc.
Fig. 7 is merely an exemplary illustration, and in practice, the executing terminal may be the core server 4 in the autonomous domain B, or may be another terminal participating in the conference service in the autonomous domain B.
As can be seen from fig. 7, according to the technical solution of the embodiment of the present application, in the video networking service developed across domains, an autonomous server may negotiate with an autonomous server in an autonomous domain of an opposite terminal to generate a cross-domain unicast key, and simultaneously generate an intra-domain unicast key transmitted within the autonomous domain, and a terminal participating in the video networking service may generate a cross-domain multicast key and an intra-domain multicast key, so that when non-audio/video data is transmitted within the domain, intra-domain unicast key may be used for encryption transmission, and when audio/video data is transmitted within the domain, intra-domain multicast key may be used for transmission. When the non-audio and video data are transmitted in a cross-domain mode, the cross-domain unicast key can be used for encryption transmission, and when the audio and video data are transmitted in the cross-domain mode, the cross-domain multicast key can be used for transmission.
For the same non-audio and video data, in a transmission path for transmitting the non-audio and video data to the opposite-end autonomous domain, the intra-domain unicast key of the autonomous domain, the cross-domain unicast key and the intra-domain unicast key of the opposite-end autonomous domain are sequentially used for encrypted transmission, so that the keys on the whole transmission path are timely replaced, and the transmission safety is ensured.
For the same audio and video data, in the transmission path for transmitting the same audio and video data to the opposite-end autonomous domain, the same audio and video data is only forwarded by the core servers in the autonomous domain and the opposite-end autonomous domain, and the core servers generally do not process the encrypted and transmitted audio and video data and directly forward the encrypted and transmitted audio and video data, so that the safety of the audio and video data transmitted across domains is improved.
In addition, in the embodiment of the application, the transmission paths of the non-audio and video data and the audio and video data are different, the non-audio and video data and the audio and video data are transferred through the autonomous server, and the non-audio and video data and the audio and video data are transferred through the core server, so that the non-audio and video data and the audio and video data have mutually independent transmission paths, and the real-time transmission efficiency of the non-audio and video data.
It should be noted that, for simplicity of description, the method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the embodiments are not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the embodiments. Further, those skilled in the art will also appreciate that the embodiments described in the specification are presently preferred and that no particular act is required of the embodiments of the application.
Referring to fig. 8, a block diagram of a cross-domain communication device of a video network supporting sub-control is shown, where the video network includes a plurality of autonomous domains, each autonomous domain includes at least one autonomous server and a plurality of terminals, and the device is located in each autonomous domain, and may specifically include the following modules:
the first encryption transmission module 801 is configured to perform data encryption transmission on data transmitted in an autonomous domain by using an intra-domain unicast key of the autonomous domain when the data is transmitted across domains;
a second encryption transmission module 802, configured to perform data encryption transmission on non-audio/video data transmitted between autonomous domains by using a cross-domain unicast key, where the cross-domain unicast key is generated by negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission;
a third encryption transmission module 803, configured to perform data encryption transmission on the audio and video data transmitted between autonomous domains by using a cross-domain multicast key, where the cross-domain multicast key is generated by a terminal that requests to create a cross-domain transmission video networking service.
Optionally, the non-audio/video data includes the cross-domain multicast key and/or signaling; the signaling is used for cross-domain service control between different autonomous domains.
Optionally, the second encryption transmission module 802 is located in an autonomous server in each autonomous domain, and specifically includes:
the encryption unit is used for encrypting the non-audio and video data to be transmitted by using the cross-domain unicast key;
and the sending unit is used for transmitting the encrypted non-audio and video data to a second autonomous server in another autonomous domain participating in cross-domain transmission.
Optionally, the non-audio/video data includes a signaling, where the signaling at least includes service configuration information of a cross-domain transmission video networking service; the second encryption transmission module 802 is located at an autonomous server in each autonomous domain, and may further include the following units:
the service creating unit is used for creating a video networking service according to the service configuration information after receiving the service configuration information sent by the terminal;
and the encryption sending unit is used for encrypting the service configuration information by using the cross-domain unicast key and then transmitting the encrypted service configuration information to the second autonomous server.
Optionally, the non-audio/video data includes the cross-domain multicast key, and the second encryption transmission module 802 is located in an autonomous server in each autonomous domain, and may further include the following units:
a key receiving unit, configured to encrypt the cross-domain multicast key using the cross-domain unicast key after receiving an instruction that the terminal indicates a start of a video networking service;
and the key sending unit is used for sending the encrypted cross-domain multicast key to the second autonomous server.
Optionally, each autonomous domain further includes at least one core server, where the autonomous server is connected to the terminal through the core server, and the apparatus further includes the following modules located at the terminal:
and the data sending module is used for encrypting the audio and video data by adopting the cross-domain multicast key when the cross-domain transmission of the audio and video data is requested, uploading the encrypted audio and video data to a first core server in the autonomous domain, and forwarding the encrypted audio and video data to a second core server in another autonomous domain participating in the cross-domain transmission by the first core server.
Optionally, the apparatus further comprises the following modules at the core server:
the receiving module is used for receiving the cross-domain multicast key and a terminal list corresponding to the video networking service, which are sent by an autonomous server in the autonomous domain, wherein the cross-domain multicast key and the terminal list are sent by the autonomous server in the autonomous domain in an encrypted manner by using an intra-domain unicast key in the autonomous domain;
the polling module is used for polling all terminals in the terminal list and pulling the polled online terminals into the video network service;
and the encryption sending module is used for encrypting and sending the cross-domain multicast key to the online terminal by utilizing the intra-domain unicast key of the autonomous domain.
An embodiment of the present application further provides an electronic device, including:
one or more processors; and
one or more machine-readable media having instructions stored thereon, which when executed by the one or more processors, cause the apparatus to perform a method of video networking cross-domain communication supporting decentralized control as described in embodiments of the present application.
Embodiments of the present application further provide a computer-readable storage medium, which stores a computer program to enable a processor to execute the method for cross-domain communication of video networking supporting separate control according to the embodiments of the present application.
The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.
As will be appreciated by one of skill in the art, embodiments of the present application may be provided as a method, apparatus, or computer program product. Accordingly, embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present application have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including the preferred embodiment and all such alterations and modifications as fall within the true scope of the embodiments of the application.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The foregoing detailed description is directed to a method, an apparatus, a device, and a medium for video networking cross-domain communication supporting sub-control, which are provided by the present application, and a specific example is applied in the present application to explain the principle and the implementation of the present application, and the description of the foregoing embodiment is only used to help understand the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims (10)

1. A cross-domain communication method of a video network supporting sub-control, wherein the video network comprises a plurality of autonomous domains, each autonomous domain comprises at least one autonomous server and a plurality of terminals, and the method comprises the following steps:
when data is transmitted across domains, non-audio and video data transmitted in the autonomous domain are encrypted and transmitted by using an intra-domain unicast key of the autonomous domain;
carrying out data encryption transmission on non-audio and video data transmitted between autonomous domains by using a cross-domain unicast key, wherein the cross-domain unicast key is generated by negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission;
and carrying out data encryption transmission on the audio and video data transmitted between autonomous domains by using a cross-domain multicast key, wherein the cross-domain multicast key is generated by a terminal requesting to create a cross-domain transmission video networking service.
2. The method according to claim 1, wherein the non-audio/video data comprises the cross-domain multicast key and/or signaling, and wherein the signaling is used for cross-domain service control between different autonomous inter-domains.
3. The method according to claim 1 or 2, wherein the performing data encryption transmission on the non-audio/video data transmitted between the autonomous domains by using a cross-domain unicast key comprises:
a first autonomous server in one autonomous domain participating in cross-domain transmission encrypts non-audio and video data to be transmitted by using the cross-domain unicast key;
and the first autonomous server transmits the encrypted non-audio and video data to a second autonomous server in another autonomous domain participating in cross-domain transmission.
4. The method according to claim 3, wherein the non-audio/video data comprises signaling, and the signaling at least comprises service configuration information of a cross-domain transmission video networking service; the method for carrying out data encryption transmission on the non-audio and video data transmitted between the autonomous domains by using the cross-domain unicast key comprises the following steps:
the first autonomous server receives the service configuration information sent by the terminal, and creates the video networking service according to the service configuration information;
and the first autonomous server encrypts the service configuration information by using the cross-domain unicast key and transmits the encrypted service configuration information to the second autonomous server so as to request the second autonomous server to participate in the video networking service together.
5. The method according to claim 3, wherein the non-audio/video data includes the cross-domain multicast key, and the performing data encryption transmission on the non-audio/video data transmitted between the autonomous domains by using a cross-domain unicast key includes:
after receiving an instruction that the terminal indicates a video networking service to start, the first autonomous server encrypts the cross-domain multicast key by using the cross-domain unicast key;
and the first autonomous server sends the encrypted cross-domain multicast key to the second autonomous server.
6. The method according to claim 1 or 2, wherein each autonomous domain further comprises at least one core server, the autonomous server is connected to the terminal through the core server, and the performing data encryption transmission on the audio and video data transmitted between the autonomous domains by using a cross-domain multicast key comprises:
when a terminal in one autonomous domain participating in cross-domain transmission requests cross-domain transmission of audio and video data, the cross-domain multicast key is adopted to encrypt the audio and video data, the encrypted audio and video data are uploaded to a first core server in the autonomous domain, and the first core server forwards the encrypted audio and video data to a second core server in another autonomous domain participating in cross-domain transmission.
7. The method of claim 6, further comprising:
the first core server receives the cross-domain multicast key and a terminal list corresponding to the video networking service, wherein the cross-domain multicast key and the terminal list are sent by an autonomous server in the autonomous domain by utilizing an intra-domain unicast key in the autonomous domain for encryption;
and the first core server polls each terminal in the terminal list and located in the autonomous domain, pulls the polled online terminal into the video network service, and encrypts and sends the cross-domain multicast key to the online terminal by using an intra-domain unicast key of the autonomous domain.
8. A device for supporting cross-domain communication of a video network with sub-control, wherein the video network comprises a plurality of autonomous domains, each autonomous domain comprises at least one autonomous server and a plurality of terminals, the device comprises:
the first encryption transmission module is used for carrying out data encryption transmission on non-audio and video data transmitted in the autonomous domain by using an intra-domain unicast key of the autonomous domain when the data are transmitted in a cross-domain manner;
the second encryption transmission module is used for carrying out data encryption transmission on non-audio and video data transmitted between autonomous domains by using a cross-domain unicast key, wherein the cross-domain unicast key is generated by negotiation of autonomous servers in different autonomous domains participating in cross-domain transmission;
and the third encryption transmission module is used for carrying out data encryption transmission on the audio and video data transmitted between the autonomous domains by using a cross-domain multicast key, wherein the cross-domain multicast key is generated by a terminal requesting to create a cross-domain transmission video networking service.
9. An electronic device, comprising: one or more processors; and one or more machine readable media having instructions stored thereon that, when executed by the one or more processors, cause the apparatus to perform the method of supporting cross-domain communication of the partially controlled video networking of any of claims 1-7.
10. A computer-readable storage medium storing a computer program for causing a processor to execute the method for supporting cross-domain communication of the separate control in the internet of view according to any one of claims 1 to 7.
CN202011429968.8A 2020-12-09 2020-12-09 Video networking cross-domain communication method, device, equipment and medium supporting sub-control Active CN112202826B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011429968.8A CN112202826B (en) 2020-12-09 2020-12-09 Video networking cross-domain communication method, device, equipment and medium supporting sub-control

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011429968.8A CN112202826B (en) 2020-12-09 2020-12-09 Video networking cross-domain communication method, device, equipment and medium supporting sub-control

Publications (2)

Publication Number Publication Date
CN112202826A CN112202826A (en) 2021-01-08
CN112202826B true CN112202826B (en) 2021-03-05

Family

ID=74033190

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011429968.8A Active CN112202826B (en) 2020-12-09 2020-12-09 Video networking cross-domain communication method, device, equipment and medium supporting sub-control

Country Status (1)

Country Link
CN (1) CN112202826B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114679429B (en) * 2022-03-29 2023-02-03 深圳信息职业技术学院 Service cross-region response method based on multi-cloud container platform
WO2024103597A1 (en) * 2022-11-14 2024-05-23 华为技术有限公司 Video-audio stream transmission method, apparatus and system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2426873A1 (en) * 2009-06-01 2012-03-07 ZTE Corporation Method for implementing the real time data service and real time data service system
CN110086750A (en) * 2018-01-26 2019-08-02 北京数盾信息科技有限公司 A kind of encryption system based on optical fiber data link road network and satellite communication network

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8458753B2 (en) * 2006-02-27 2013-06-04 Time Warner Cable Enterprises Llc Methods and apparatus for device capabilities discovery and utilization within a content-based network
US9106800B2 (en) * 2007-08-31 2015-08-11 At&T Intellectual Property I, L.P. System and method of monitoring video data packet delivery

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2426873A1 (en) * 2009-06-01 2012-03-07 ZTE Corporation Method for implementing the real time data service and real time data service system
CN110086750A (en) * 2018-01-26 2019-08-02 北京数盾信息科技有限公司 A kind of encryption system based on optical fiber data link road network and satellite communication network

Also Published As

Publication number Publication date
CN112202826A (en) 2021-01-08

Similar Documents

Publication Publication Date Title
CN110430043B (en) Authentication method, system and device and storage medium
CN109120879B (en) Video conference processing method and system
CN110475090B (en) Conference control method and system
CN112333210B (en) Method and equipment for realizing data communication function of video network
CN112202826B (en) Video networking cross-domain communication method, device, equipment and medium supporting sub-control
CN111786778A (en) Method and device for updating key
CN109347844B (en) Method and device for accessing equipment to Internet
CN112291072B (en) Secure video communication method, device, equipment and medium based on management plane protocol
CN108881134B (en) Communication method and system based on video conference
CN111556376B (en) Digital certificate signing and issuing method and device and computer readable storage medium
CN110535856B (en) User authentication method, device and storage medium
CN110266577B (en) Tunnel establishment method and video networking system
CN110072154B (en) Video networking-based clustering method and transfer server
CN109889516B (en) Method and device for establishing session channel
CN109376507B (en) Data security management method and system
CN110392289B (en) Account processing method and system
CN112291592B (en) Control plane protocol-based secure video communication method, device, equipment and medium
CN110049007B (en) Video networking transmission method and device
CN110445806B (en) Method and device for calling internet terminal and protocol conversion server
CN110808896B (en) Data transmission method and device, electronic equipment and storage medium
CN109561080B (en) Dynamic network access communication method and device
CN109617858B (en) Encryption method and device for streaming media link
CN109639627B (en) Encryption mode switching method and device
CN112165416A (en) Networking and communication method and device
CN111787261A (en) Audio and video data sending method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20220926

Address after: 571924 building C07, Zone C, Hainan Ecological Software Park, hi tech Industrial Demonstration Zone, old town, Haikou City, Hainan Province

Patentee after: Hainan Shilian Communication Technology Co.,Ltd.

Address before: 100000 Beijing Dongcheng District Qinglong Hutong 1 Song Hua Building A1103-1113

Patentee before: VISIONVERA INFORMATION TECHNOLOGY Co.,Ltd.