WO2021047513A1 - 一种视频会议通信方法、装置以及计算机可读存储介质 - Google Patents

一种视频会议通信方法、装置以及计算机可读存储介质 Download PDF

Info

Publication number
WO2021047513A1
WO2021047513A1 PCT/CN2020/114051 CN2020114051W WO2021047513A1 WO 2021047513 A1 WO2021047513 A1 WO 2021047513A1 CN 2020114051 W CN2020114051 W CN 2020114051W WO 2021047513 A1 WO2021047513 A1 WO 2021047513A1
Authority
WO
WIPO (PCT)
Prior art keywords
mcu
sip
session
terminal
sip server
Prior art date
Application number
PCT/CN2020/114051
Other languages
English (en)
French (fr)
Inventor
姚刚
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2021047513A1 publication Critical patent/WO2021047513A1/zh

Links

Images

Classifications

    • 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/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences

Definitions

  • the embodiments of the present application relate to, but are not limited to, the field of multimedia video conferencing, and specifically, to, but are not limited to, a video conference communication method, device, and computer-readable storage medium.
  • MCU Multipoint Control Unit
  • MCU is a key component of the video conferencing system. It interacts with multiple terminals to maintain audio and video intercommunication. In order to provide reliable video conferencing services, MCU will design corresponding mechanisms to ensure the reliability of the system . For example, if some key modules in the MCU fail and cannot process messages normally or crash, the monitoring process will pull the module up again and restore the function in the shortest time.
  • restarting the module cannot solve all problems, such as the SIP (Session Initiation Protocol) protocol stack module.
  • SIP Session Initiation Protocol
  • the SIP protocol stack After the SIP protocol stack is restarted, it can only ensure that the subsequent functions are normal, such as a new terminal call, which has already been established. The call cannot be held. Since key information such as the session has been lost, such as call state machine, transaction layer data, etc., the restarted SIP protocol stack cannot normally respond to subsequent SIP messages, such as UPDATE session keep-alive messages, INFO VCU requests, abnormal UPDATE responses, etc.
  • the SIP server (SIP Server) network element hangs up the call, and the INFO VCU request cannot be requested normally, which will cause image decoding failure, etc.
  • the system is generally configured with two independent MCUs, which are mutually active and standby.
  • the main device fails, the entire MCU device is completely destroyed, and its shortcomings are also obvious:
  • the active and standby solution requires two sets of physical equipment, which increases the cost.
  • the solution is relatively complicated and requires a standby MCU to restore the entire business system from the database.
  • An embodiment of the application provides a video conference communication method and device.
  • the embodiment of the application provides a video conference communication method, including: after the MCU restarts, the SIP server receives the session keep-alive message sent by the terminal, and sends the session keep-alive message to the MCU, and the session keep-alive information is The terminal transmits according to the keep-alive period; the SIP server receives the first SIP session response message sent by the MCU, and sends a session keep-alive message response message to the terminal.
  • An embodiment of the application also provides a video conference communication method, including: the MCU monitoring process detects an abnormal SIP session and restarts it; the MCU receives a session keep-alive message sent by the SIP server, and the session keep-alive information is the terminal Send to the SIP server according to the keep-alive period; the MCU sends the first SIP session response message to the SIP server, and at the same time reports the session keep-alive message abnormal event to the application server; the MCU receives the terminal according to After the successful response to the normal business query conference status, the SIP session information corresponding to the terminal is constructed and saved.
  • An embodiment of the application also provides a video conference communication device, including: a first receiving module, configured to receive a session keep-alive message sent by a terminal and a first SIP session response message sent by an MCU; a first sending module, configured to send The session keep-alive message is sent to the MCU and the session keep-alive message response message is sent to the terminal.
  • the embodiment of the present application also provides a video conference communication device, including: a monitoring module, used to detect abnormal SIP session and restart the MCU; a second receiving module, used to receive the session keep-alive message sent by the SIP server and the receiving terminal according to A successful response to the normal business query meeting status; the second sending module, used to send the first SIP session response message to the SIP server, and at the same time, report the abnormal event of the session keep-alive message to the application server; the processing module, used to construct and And save the SIP session information corresponding to the terminal.
  • a monitoring module used to detect abnormal SIP session and restart the MCU
  • a second receiving module used to receive the session keep-alive message sent by the SIP server and the receiving terminal according to A successful response to the normal business query meeting status
  • the second sending module used to send the first SIP session response message to the SIP server, and at the same time, report the abnormal event of the session keep-alive message to the application server
  • the processing module used to construct and And save the SIP
  • the embodiment of the present application also provides a computer storage medium, the computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to realize the above The steps of the video conference communication method.
  • Figure 1 is a schematic diagram of the conventional flow of video conference communication
  • FIG. 2 is a schematic diagram of the basic flow diagram of restarting the MCU protocol stack module in the video conference according to the first embodiment of the application when a failure occurs;
  • FIG. 3 is a schematic diagram of a restart process of an MCU protocol stack module in a video conference according to the first embodiment of the application when a fault occurs;
  • FIG. 4 is a schematic diagram of the basic flow chart of the service request I frame after the MCU protocol stack restarts in the video conference according to the second embodiment of the application;
  • FIG. 5 is a schematic diagram of a service request I frame flow after the MCU protocol stack restarts in the video conference according to the second embodiment of the application;
  • FIG. 6 is a schematic diagram of the interaction process among the terminal, the SIP server, and the MCU involved in the service request I frame process in the embodiment of the application.
  • an embodiment of the present application provides a video conference communication method, which is determined by message detection by the SIP server The status of the MCU protocol stack is output, and corresponding policy processing is performed. At the same time, the MCU restores the corresponding SIP session information according to the request message of the SIP server, so as to maintain the conference terminal from being hung up and the conference control function is normal.
  • the terminal calls the MCU through the SIP server. After the SIP session connection is established, the media code stream is sent between the terminal and the MCU, and the terminal will succeed.
  • the terminal and the SIP server, SIP server and MCU will periodically send session keep-alive messages. If the session keep-alive message response message is not received, both the SIP server and terminal will hang up the SIP call.
  • the session keep-alive message is an UPDATE message
  • the session keep-alive message response message is an UPDATE 200 OK response message.
  • the monitoring process detects that the SIP protocol stack of the MCU is faulty and immediately restarts the SIP protocol stack.
  • the restarted SIP protocol stack has lost the key information of the SIP session and cannot normally correspond to subsequent SIP messages.
  • the embodiment of the present application Improved on the basis of the existing mechanism, a video conference communication method is proposed to ensure that the terminal will not be hung up when the MCU fails. Refer to Figure 2 for the specific process.
  • the SIP server receives the session keep-alive message sent by the terminal, and sends the session keep-alive message to the MCU.
  • the terminal and the SIP server, and the SIP server and the MCU will periodically send session keep-alive messages.
  • the premise for the terminal to periodically send session keep-alive messages is to ensure that the terminal will succeed.
  • the specific process of the terminal meeting is: the terminal sends an INVITE message to the SIP server, the SIP server receives the INVITE message and forwards it to the MCU, and the MCU sends it to the SIP
  • the server sends a 200 OK response message, and the SIP server receives the 200 OK response message and forwards it to the terminal.
  • the terminal sends an ACK confirmation message to the SIP server.
  • the SIP server receives the ACK confirmation message and sends it to the MCU. At this time, the terminal and MCU can send The media stream will be successful on the terminal.
  • the session keep-alive message is sent periodically, that is, sent periodically, and this period is the keep-alive period.
  • the session keep-alive message is an UPDATE message
  • the UPDATE message sent by the SIP server received by the MCU will carry key session information such as Request-Line, From, To, and Call-ID.
  • Request-Line From, To, and Call-ID.
  • Call-ID Call-ID
  • this information contains the request type, request address (Request-URI), and SIP version number.
  • this message contains SIP version number, transmission type UDP, call address, and branch random code.
  • From and To session messages indicate the sender and target of the request message. Since these two messages have user name tags, they are enclosed in angle brackets.
  • the tag contained in the From message is a random code.
  • call ID is a globally unique value, and it is the same for each call.
  • CSeq message is also called the command queue. Each time a new request is sent, the value is automatically increased by 1.
  • the From, To, and Call-ID in the same session must be exactly the same, and the URI of the Request-Line is also exactly the same. Except for the request type, the IP address in the contact is replaced with the local monitoring IP and port number of the MCU.
  • the MCU fails. Before the MCU restarts, the SIP protocol stack freezes and cannot process messages normally. At this time, the monitoring process has not detected the MCU failure, and the SIP protocol stack is not immediately restarted, and the MCU does not respond to the UPDATE message. The SIP server did not receive the response message from the MCU. At this time, the SIP server protocol stack did not receive a response from the MCU due to the timeout of the UPDATE request message. The SIP server judges that there may be network reasons or MCU failure at this time. In order to maintain the current SIP session, it does not hang up and sends an UPDATE response to the terminal. Message, it should be understood that in the implementation of this application, the UPDATE response message may specifically be an UPDATE 200 OK response message.
  • the UPDATE message is sent periodically to ensure the normality and reliability of the SIP session.
  • the terminal After the MCU restarts and reaches the keep-alive period, the terminal sends an UPDATE message to the SIP server, and the SIP server forwards the UPDATE message to the MCU.
  • the SIP server receives the first SIP session response message sent by the MCU, and sends a session keep-alive message response message to the terminal.
  • the MCU monitoring process detects that the SIP protocol stack process of the MCU is abnormal and restarts the SIP protocol stack. However, since the SIP protocol stack is restarted, there is no SIP session information corresponding to the terminal in the SIP protocol stack. According to the protocol specification, The corresponding first SIP session response message is sent to the SIP server, and the abnormal event of the session keep-alive message is reported to the application server while sending the first SIP session response message.
  • the SIP protocol stack restarts, and there is no key transaction layer data corresponding to the terminal in the SIP protocol stack. According to the protocol specification, it will respond to the 481 message, indicating that the SIP transaction layer data does not exist.
  • the SIP protocol stack The UPDATE abnormal event is reported to the application. It should be noted that the UPDATE abnormal event carries identification information such as the terminal number and the conference number.
  • the SIP server considers that the MCU or the network is faulty and has not recovered, and sends the request timeout message to the terminal, and the terminal performs abnormal hangup processing. Is 408 messages.
  • the SIP protocol stack reports the UPDATE abnormal event to the application.
  • the UPDATE abnormal event carries identification information such as the terminal number and the conference number.
  • the conference number is the user number and terminal number in the Request-Line. Take the user number in the From header field.
  • the MCU when the MCU receives the session keep-alive message in the next keep-alive period, it can respond normally to the session keep-alive message, so it sends a 200 OK response message to the SIP server, and the SIP server can confirm that the MCU has resumed the SIP session information. , The conference on the MCU side is normal, and the 200 OK response message is forwarded to the terminal.
  • the SIP call status is abnormal and the SIP protocol stack does not have SIP session information corresponding to the terminal
  • the corresponding first SIP session response message is sent to the SIP server according to the protocol specification, and the SIP server sends the first SIP session response message Forward to the terminal, and the terminal will hang up.
  • the SIP protocol stack does not have transaction layer data, it sends a 481 response message to the SIP server. If the SIP server’s two keep-alives fail, it is considered that the terminal SIP call is abnormal, and the 481 response message is forwarded to the terminal, and the terminal can hang up. Disconnect the call.
  • the terminal receives the 408 request timeout message or the 481 message sent by the SIP server, and can hang up.
  • the terminal sends a BYE request message to the SIP server to indicate to the SIP server that it wants to release the call.
  • the SIP server forwards the BYE request message to the MCU, the MCU responds with a timeout, and the SIP server sends a 408 request timeout message to the terminal, and the terminal hangs up the SIP call and releases the SIP session.
  • the SIP server performs message detection to determine the status of the MCU protocol stack and performs corresponding policy processing.
  • the MCU restores the corresponding SIP session information according to the request message of the SIP server, thereby ensuring The terminal at the conference is not hung up and the conference control function is normal, and the terminal user does not perceive the occurrence of MCU failure, which improves the reliability of the video conference and improves the user experience.
  • this embodiment provides further example description on the basis of the video conference communication method shown in the foregoing embodiment.
  • FIG. 3 is a specific process of the video conference communication method according to an embodiment of the application, and the process is as follows:
  • the SIP server receives the session keep-alive message sent by the terminal in the first keep-alive period, and sends the session keep-alive message to the MCU;
  • the terminal and the SIP server, the SIP server and the MCU will periodically send session keep-alive messages.
  • the session keep-alive messages are sent regularly, that is, periodically. Sending, it should be noted that the session keep-alive message is an UPDATE message, and the UPDATE message sent by the SIP server received by the MCU protocol stack will carry key session information such as Request-Line, From, To, and Call-ID.
  • S302 When the SIP server does not receive the response message from the MCU, it sends a session keep-alive message response message to the terminal;
  • the MCU fails, the SIP protocol stack freezes, and the message cannot be processed normally.
  • the monitoring process has not detected the MCU failure, and the SIP protocol stack is not immediately restarted, the MCU does not respond to the UPDATE request message, and the SIP server does not receive it. Response message to MCU.
  • the SIP server protocol stack did not receive a response from the MCU due to the timeout of the UPDATE request message.
  • the SIP server judges that there may be network reasons or MCU failure at this time. In order to maintain the current SIP session, it does not hang up and sends an UPDATE response to the terminal. Message, the UPDATE response message may specifically be an UPDATE200OK response message.
  • the SIP server receives the session keep-alive message sent by the terminal in the second keep-alive period, and sends the session keep-alive message to the MCU.
  • the UPDATE session keep-alive message is sent periodically to ensure the normality and reliability of the SIP session.
  • the SIP server receives the first SIP session response message sent by the MCU, and sends a session keep-alive message response message to the terminal.
  • the MCU monitoring process detects that the SIP protocol stack process of the MCU is abnormal and restarts the SIP protocol stack. However, since the SIP protocol stack is restarted, the SIP protocol There is no SIP session information corresponding to the terminal in the stack, the corresponding first SIP session response message is sent to the SIP server according to the protocol specification, and the session keep-alive message exception event is reported to the application server while sending the first SIP session response message.
  • the SIP protocol stack restarts, and there is no key transaction layer data corresponding to the terminal in the SIP protocol stack. According to the protocol specification, it will respond to the 481 message, indicating that the SIP transaction layer data does not exist.
  • the SIP protocol stack The UPDATE abnormal event is reported to the application. It should be noted that the UPDATE abnormal event carries identification information such as the terminal number and the conference number.
  • the SIP server considers that the MCU or the network is faulty and has not recovered, and sends a 408 request timeout message to the terminal, and the terminal performs abnormal hangup processing.
  • the SIP server receives the session keep-alive message sent by the terminal in the third keep-alive period, and sends the session keep-alive message to the MCU;
  • the SIP server receives the session keep-alive message response message sent by the MCU, and sends the session keep-alive message response message to the terminal.
  • the SIP protocol stack reports the UPDATE abnormal event to the application.
  • the UPDATE abnormal event carries identification information such as the terminal number and the conference number.
  • the conference number is the user number and terminal number in the Request-Line. Take the user number in the From header field.
  • the MCU when the MCU receives the session keep-alive message in the next keep-alive period, it can respond normally to the session keep-alive message, so it sends a 200 OK response message to the SIP server, and the SIP server can confirm that the MCU has resumed the SIP session information. , The conference on the MCU side is normal, and the 200 OK response message is forwarded to the terminal.
  • the SIP call status is abnormal and the SIP protocol stack does not have SIP session information corresponding to the terminal
  • the corresponding first SIP session response message is sent to the SIP server according to the protocol specification, and the SIP server sends the first SIP session response message Forward to the terminal, and the terminal will hang up.
  • the SIP protocol stack does not have transaction layer data, it sends a 481 response message to the SIP server. If the SIP server’s two keep-alives fail, it is considered that the terminal SIP call is abnormal, and the 481 response message is forwarded to the terminal, and the terminal can hang up. Disconnect the call.
  • the terminal receives the 408 request timeout message or the 481 message sent by the SIP server, and can hang up.
  • the terminal sends a BYE request message to the SIP server to indicate to the SIP server that it wants to release the call.
  • the SIP server forwards the BYE request message to the MCU, the MCU responds with a timeout, and the SIP server sends a 408 request timeout message to the terminal, and the terminal hangs up the SIP call and releases the SIP session.
  • the MCU protocol stack module fails and crashes, and the monitoring process restarts the MCU protocol stack to involve the interaction between the terminal, SIP server and MCU.
  • the SIP server receives the session keep-alive information sent by the terminal in the first keep-alive period, and sends the session keep-alive information to the MCU.
  • the MCU fails and does not respond to the session keep-alive information.
  • the SIP server does not receive the response message from the MCU.
  • the SIP server judges that the MCU may be faulty at this time, maintains the current SIP session, does not hang up, and sends a session keep-alive information response message to the terminal; the SIP server receives the terminal in the second keep-alive period
  • the session keep-alive information sent, and the session keep-alive information is sent to the MCU.
  • the MCU sends the first SIP session response message to the SIP server .
  • the SIP server receives the first SIP session response message sent by the MCU, at this time it can confirm that the MCU has restarted and the current SIP protocol stack has been restored, the current session is still maintained, and the session keep-alive information response is sent to the terminal without hanging up Message:
  • the SIP server receives the session keep-alive information sent by the terminal in the third keep-alive period, and sends the session keep-alive information to the MCU.
  • the MCU sends the session keep-alive information response message to the SIP server.
  • the SIP server can confirm the MCU side If the meeting is normal, the third session keep-alive information 200 OK response message is forwarded to the terminal; the SIP server performs message detection to determine the status of the MCU protocol stack, and performs corresponding policy processing, and the MCU restores the correspondence according to the request message of the SIP server SIP session information to ensure that the terminal at the conference will not be hung up and the conference control function is normal, and the terminal user will not perceive the occurrence of MCU failure, which improves the reliability of the video conference and enhances the user experience.
  • the SIP server receives the session keep-alive message sent by the terminal in the first keep-alive period, and sends the session keep-alive message to the MCU.
  • the terminal and the SIP server, the SIP server and the MCU will periodically send UPDATE session keepalive messages, which have been described in detail in the above embodiments , I won’t repeat it here.
  • S502 When the SIP server does not receive the response message from the MCU, it sends a session keep-alive message response message to the terminal.
  • the MCU fails, the SIP protocol stack freezes, and the message cannot be processed normally.
  • the monitoring process has not detected the MCU failure, and the SIP protocol stack is not immediately restarted, the MCU does not respond to the UPDATE request message, and the SIP server does not receive it. Response message to MCU.
  • the SIP server protocol stack will time out the UPDATE request message and does not receive a response from the MCU.
  • the SIP server judges that there may be a network cause or MCU failure at this time. In order to maintain the current SIP session, it does not hang up and sends an UPDATE response to the terminal.
  • the UPDATE response message may specifically be an UPDATE 200 OK response message.
  • S503 The monitoring process of the MCU detects that the SIP protocol stack process is abnormal and restarts the SIP protocol stack.
  • the MCU fails to send the INFO request message to the SIP server.
  • the SIP protocol stack is restarted, and an error occurs in MCU decoding.
  • the MCU sends an I frame request to the terminal, and the I frame request is sent in the form of an INFO request. Since the SIP protocol stack has been restarted, there is no SIP session information corresponding to the terminal in the SIP protocol stack, and the INFO request cannot be sent, resulting in a failure to send.
  • I Frame is also called Intra Picture.
  • I Frame is usually the first frame of each GOP (a video compression technology used by MPEG) and is appropriately compressed. As a reference point for random access, it can be used as an image.
  • the SIP server receives the session keep-alive message sent by the terminal in the second keep-alive period, and sends the session keep-alive message to the MCU.
  • the INFO request is sent between the first keep-alive period and the second keep-alive period.
  • the SIP server receives the first SIP session response message sent by the MCU, and sends a session keep-alive message response message to the terminal.
  • the monitoring process of the MCU detects that the SIP protocol stack process of the MCU is abnormal and restarts the SIP protocol stack. However, since the SIP protocol stack is restarted, there is no SIP session corresponding to the terminal in the SIP protocol stack. According to the protocol specification, the corresponding first SIP session response message is sent to the SIP server.
  • the SIP server receives the first SIP session response message sent by the MCU, it can confirm that the MCU has restarted and the current SIP protocol stack has been restored and is still maintained For the current session, the session keep-alive message response message is sent to the terminal without hanging up.
  • the first SIP session response message is a 481 response message
  • the session keep-alive message response message is a 200 OK response message.
  • the SIP server receives the INFO request message sent by the MCU, and forwards the INFO request message to the terminal.
  • the MCU protocol stack has resumed the SIP session according to the UPDATE message sent in the second keep-alive period, and at this time the MCU can send the INFO request normally. Since the last I frame request failed and the MCU image decoding was not restored, the MCU once again sends an I frame request to the terminal.
  • the terminal After receiving the INFO request message, the terminal sends an INFO response message to the SIP server, and at the same time notifies the encoder to compile an I frame.
  • the INFO response message is a 200 OK message.
  • the SIP server forwards the INFO response message to the MCU.
  • the MCU after the MCU receives the INFO response message, it indicates that the MCU image is decoded normally, and therefore the I frame request process ends.
  • the process of requesting the I frame for the service involves the interaction between the terminal, the SIP server and the MCU.
  • the process of requesting the I frame for the service involves the interaction between the terminal, the SIP server and the MCU.
  • the restarted protocol stack does not have the SIP session information of the corresponding terminal, and the INFO request fails to be sent before the second keep-alive period; the SIP server receives the terminal in the second The session keep-alive message sent in the keep-alive period, and the session keep-alive message is sent to the MCU, the MCU sends the first SIP session response message to the SIP server, and the SIP server receives the first SIP session response message sent by the MCU. It can be confirmed that the MCU has restarted and the current SIP protocol stack has been restored.
  • the current session is still maintained without hanging up, and the session keep-alive message response message is sent to the terminal.
  • the MCU resumes the SIP conversation according to the session keep-alive message, and the MCU can be normal Send an INFO request message; use the SIP server to perform message detection to determine the status of the MCU protocol stack and perform corresponding policy processing.
  • the MCU restores the corresponding SIP session information according to the SIP server's request message, so as to ensure that the terminal at the meeting is not Hang up and the conference control function is normal, the end user does not perceive the occurrence of MCU failure, which improves the reliability of the video conference and improves the user experience.
  • the embodiment of the present application also provides a video conference communication device, which is used to implement at least one step in the method in the above-mentioned embodiment.
  • the first receiving module is configured to receive the session keep-alive message sent by the terminal and the first SIP session response message sent by the MCU;
  • the first sending module is used to send the session keep-alive message to the MCU and send the session keep-alive message response message to the terminal.
  • the video conference communication device of the embodiment of the present application further includes a monitoring module, a second receiving module, a second sending module, and a processing module;
  • the monitoring module is used to detect an abnormal SIP session and restart the MCU;
  • the second receiving module is configured to receive the session keep-alive message sent by the SIP server and the successful response of the receiving terminal to query the normal state of the conference according to the business;
  • the second sending module is configured to send the first SIP session response message to the SIP server, and at the same time report the abnormal event of the session keep-alive message to the application server;
  • the processing module is used to construct and save SIP session information corresponding to the terminal.
  • the video conference communication device includes a first receiving module, a first sending module, a monitoring module, a second receiving module, a second sending module, and a processing module, which implements the methods in the above-mentioned embodiments 1 to 3 At least one step is to ensure that the terminal attending the conference is not hung up and the conference control function is normal, and the terminal user does not perceive the occurrence of MCU failure, which improves the reliability of the video conference and improves the user experience
  • This embodiment also provides a computer-readable storage medium, which is included in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules, or other data). Volatile or non-volatile, removable or non-removable media.
  • Computer-readable storage media include but are not limited to RAM (Random Access Memory), ROM (Read-Only Memory, read-only memory), EEPROM (Electrically Erasable Programmable read only memory, charged Erasable Programmable Read-Only Memory) ), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, Or any other medium that can be used to store desired information and that can be accessed by a computer.
  • the computer-readable storage medium in this embodiment can be used to store one or more computer programs, and the stored one or more computer programs can be executed by a processor to implement the video conference communication in the first embodiment and the third embodiment. At least one step of the method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供一种视频会议通信方法、装置以及计算机存储介质，通过SIP服务器进行消息探测来判断出MCU协议栈的状态，并进行相应的策略处理，同时MCU根据SIP服务器的请求消息恢复对应的SIP会话信息。

Description

一种视频会议通信方法、装置以及计算机可读存储介质
相关申请的交叉引用
本申请基于申请号为201910854628.0、申请日为2019年9月10日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此以引入方式并入本申请。
技术领域
本申请实施例涉及但不限于多媒体视频会议领域，具体而言，涉及但不限于一种视频会议通信方法、装置以及计算机可读存储介质。
背景技术
MCU(Multipoint Control Unit，多点控制单元)作为视频会议系统的关键组件，它与多个终端交互，保持音视频互通，为了提供可靠的视频会议服务，MCU会设计相应的机制保证系统的可靠性。比如MCU中某些关键模块发生了故障，不能正常处理消息或死机，监控进程会将该模块重新拉起来，最短时间内恢复功能。
但重启模块不能解决所有的问题，比如SIP(Session Initiation Protocol，会话初始协议)协议栈模块，SIP协议栈重新启动后，它只能保证后续功能正常，比如新的终端呼叫上，而已经建立的呼叫无法保持。由于会话等关键信息已经丢失，比如呼叫状态机、事务层数据等，重启后的SIP协议栈不能正常响应后续的SIP消息，比如UPDATE会话保活消息、INFO VCU请求，UPDATE不正常响应等会造成SIP服务器(SIP Server)网元挂断呼叫，INFO VCU请求不能正常请求会造成图像解码失败等。
而相关技术中，对于保障性要求比较高的场景，系统一般都是配置两台独立的MCU，它们互为主备，当主用设备出现故障时整倒整个MCU设备，它的缺点也比较明显：
1、采用主备MCU方案时，只要某个模块发生了异常，都可能会造成整个设备的倒换，对整个系统的稳定性有影响；
2、主备方案需要两套物理设备，增加了成本，另外方案也相对比较复杂，需要备用MCU从数据库中恢复整个业务系统。
综上所述，当MCU某些关键模块出现故障时，就会将已经上会的终端挂断，监控进程将该模块重新拉起后无法保持故障之前已经建立好的呼叫；当采用主备MCU方案，只要MCU某个模块发生了异常，就会影响视频会议中整个系统的稳定性。
发明内容
本申请实施例提供的一种视频会议通信方法和装置。
本申请实施例提供一种视频会议通信方法，包括：MCU重启后，SIP服务器接收终端发送的会话保活消息，并将所述会话保活消息发送给所述MCU，所述会话保活信息为所述终端按照保活周期进行发送；所述SIP服务器接收所述MCU发送的第一SIP会话响应消息，并向所述终端发送会话保活消息响应消息。
本申请实施例还提供一种视频会议通信方法，包括：MCU监控进程监测到SIP会话异常并进行重启；所述MCU接收SIP服务器发送的会话保活消息，所述会话保活信息为所述终端按照保活周期发送给所述SIP服务器；所述MCU将第一SIP会话响应消息发送给所述SIP服务器，同时将会话保活消息异常事件上报给应用服务器；所述MCU接收到所述终端根据业务查询会议状态正常的成功 响应后，构造与所述终端对应的SIP会话信息并保存。
本申请实施例还提供一种视频会议通信装置，包括：第一接收模块，用于接收终端发送的会话保活消息以及接收MCU发送的第一SIP会话响应消息；第一发送模块，用于将所述会话保活消息发送给MCU以及向所述终端发送会话保活消息响应消息。
本申请实施例还提供一种视频会议通信装置，包括：监控模块，用于监测到SIP会话异常并进行MCU重启；第二接收模块，用于接收SIP服务器发送的会话保活消息以及接收终端根据业务查询会议状态正常的成功响应；第二发送模块，用于将第一SIP会话响应消息发送给所述SIP服务器，同时将会话保活消息异常事件上报给应用服务器；处理模块，用于构造与所述终端对应的SIP会话信息并保存。
本申请实施例还提供一种计算机存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如上所述的视频会议通信方法的步骤。
本申请其他特征和相应的有益效果在说明书的后面部分进行阐述说明，且应当理解，至少部分有益效果从本申请说明书中的记载变的显而易见。
附图说明
图1为视频会议通信常规流程示意图；
图2为本申请实施例一的视频会议中MCU协议栈模块发生故障重启基本流程示意图；
图3为本申请实施例一的视频会议中MCU协议栈模块发生故障重启流程示意图；
图4为本申请实施例二的视频会议中MCU协议栈重启后业务请求I帧基本 流程示意图；
图5为本申请实施例二的视频会议中MCU协议栈重启后业务请求I帧流程示意图；
图6为本申请实施例的业务请求I帧过程中涉及的终端、SIP服务器与MCU三者之间的交互流程示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，下面通过具体实施方式结合附图对本申请实施例作进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
实施例一：
为了解决MCU设备中监控进程机制的不足，维持已经上会的终端不被挂断且会议控制功能正常的问题，本申请实施例提供了一种视频会议通信方法，通过SIP服务器进行消息探测来判断出MCU协议栈的状态，并进行相应的策略处理，同时MCU根据SIP服务器的请求消息恢复对应的SIP会话信息，从而维持上会的终端不被挂断且会控功能正常。
请参见图1，终端通过SIP服务器呼叫MCU，SIP会话连接建立之后，终端与MCU之间发送媒体码流，终端上会成功。
为了检测SIP会话是否一直存在，终端与SIP服务器，SIP服务器与MCU之间会定时发送会话保活消息，如果没有收到会话保活消息响应消息，SIP服务器和终端都会挂断SIP呼叫，需要说明的是，本申请实施例中，会话保活消息为UPDATE消息，相应的，会话保活消息响应消息为UPDATE 200OK响应消息。具体参见图1，当MCU的SIP协议栈发生故障，MCU无法对UPDATE保活消息进行响应，请求超时，SIP服务器就会向终端发送408请求超时消息，执行挂断操作。
监测进程检测到MCU的SIP协议栈发生故障就会立即重新启动SIP协议栈， 但是重新启动的SIP协议栈已经丢失SIP会话的关键信息，不能正常相应后续的SIP消息，对此，本申请实施例在现有机制的基础上进行改进，提出了一种视频会议通信方法，保证当MCU出现故障时终端不被挂断，具体流程参见图2。
S201、MCU重启后，SIP服务器接收终端发送的会话保活消息，并将会话保活消息发送给所述MCU。
本申请实施例中，终端上会成功后，为了检测SIP会话是否一直存在，终端与SIP服务器，SIP服务器与MCU之间会定时发送会话保活消息。也就是说，终端定时发送会话保活消息的前提是要保证终端上会成功，终端上会的具体过程为：终端向SIP服务器发送INVITE消息，SIP服务器接收到INVITE消息转发给MCU，MCU向SIP服务器发送200OK响应消息，SIP服务器接收到200OK响应消息后转发给终端，终端向SIP服务器发送ACK确认消息，SIP服务器接收到ACK确认消息后发送给MCU，此时，终端与MCU之间就可以发送媒体码流，终端上会成功。
本申请实施例中，会话保活消息为定时发送，即周期性发送，这个周期为保活周期。需要说明的是，会话保活消息为UPDATE消息，MCU接收到SIP服务器发送的UPDATE消息中会携带Request-Line、From、To、Call-ID等会话关键信息，下面以示例对这几种信息作进一步说明，具体如下：
UPDATE sip:+863213328433@mmconf100.ucs.com.cn SIP/2.0
需要说明的是，这条信息中包含请求类型、请求地址(Request-URI)以及SIP版本号。
Via:SIP/2.0/UDP 192.166.6.226:15123；branch＝z9hG4bK20939826222
需要说明的是，这条信息中包含SIP版本号、传输类型UDP、呼叫地址以及branch随机码。
From:<sip:26770010@ucs.com.cn>；tag＝8508.116826223
To:<tel:+8610001>；tag＝651375074.133.100.0.0.1182650445
需要说明的是，From和To会话消息表示请求消息的发送方和目标方，由 于这两个消息中有用户名标签，故用尖括号包起来，From信息中包含的tag为随机码。
Call-ID:2111976454j133.100.26330660@192.166.5.49
需要说明的是，呼叫ID为全局唯一值，每次呼叫都是一样的。
CSeq:100UPDATE
需要说明的是，CSeq消息又称命令队列，每发送一个新的请求，数值自动加1。
Contact:<sip:26770010@192.166.6.226:15123；transport＝UDP>
Session-Expires:120；refresher＝uac
根据协议规范，同一个会话内的From、To、Call-ID必须完全一样，Request-Line的URI也是完全一致的，除了请求类型，contact中的IP地址替换为MCU本地监听IP及端口号。
本申请实施例中，MCU发生故障，在MCU重启之前，SIP协议栈死机，不能正常处理消息，此时监测进程还未检测到MCU发生故障，未立即重启SIP协议栈，MCU不响应UPDATE消息，SIP服务器没有接收到MCU的响应消息。此时，SIP服务器协议栈由于UPDATE请求消息超时，没有收到MCU响应，SIP服务器则判断此时可能网络原因或者MCU发生故障，为了维持当前SIP会话，不做挂断处理，向终端发送UPDATE响应消息，需要理解的是，本申请实施中，UPDATE响应消息具体可以为UPDATE 200OK响应消息。
本申请实施例中，UPDATE消息是周期性发送的，目的是为了保证SIP会话的正常性和可靠性。MCU重启后，到达保活周期，终端向SIP服务器发送UPDATE消息，SIP服务器将UPDATE消息转发给MCU。
S202、SIP服务器接收MCU发送的第一SIP会话响应消息，并向终端发送会话保活消息响应消息。
MCU的监测进程监测到MCU的SIP协议栈进程异常，重新启动了SIP协议栈，但是，由于SIP协议栈是重新启动过的，SIP协议栈中没有与终端对应的SIP会话信息，根据协议规范将相应的第一SIP会话响应消息发送给SIP服务器， 在发送第一SIP会话响应消息的同时将会话保活消息异常事件上报给应用服务器。
具体的，SIP协议栈重新启动，SIP协议栈中没有与终端对应的事务层关键数据，根据协议规范会响应481消息，表示SIP事务层数据不存在，在发送481响应消息的同时，SIP协议栈将UPDATE异常事件上报给应用，需要说明的是，UPDATE异常事件中携带了终端号、会议号等标识信息。
需要说明的是，若MCU依旧响应超时，SIP服务器没有接收到MCU的响应消息，SIP服务器则认为MCU或者网络故障且未恢复，便将请求超时消息发送给终端，终端作异常挂断处理，具体的为408消息。
本申请实施例中，SIP协议栈将UPDATE异常事件上报给应用，UPDATE异常事件中携带了终端号、会议号等标识信息，需要说明的是，会议号取Request-Line中的用户号码、终端号取From头字段中的用户号码。业务查询对应终端的会议状态是否正常，若正常，SIP协议栈收到成功响应后，构造出对应终端的SIP会话信息保存到MCU的SIP协议栈事务层中，需要说明的是，SIP协议栈已经构建好SIP会话信息，因此，MCU在下一个保活周期接收到会话保活消息时，可以正常响应会话保活消息，于是向SIP服务器发送200OK响应消息，SIP服务器便可确认MCU已恢复SIP会话信息，MCU侧的会议正常，将200OK响应消息转发给终端。
需要说明的是，若SIP呼叫状态已异常，SIP协议栈没有与终端对应的SIP会话信息，根据协议规范将相应的第一SIP会话响应消息发送给SIP服务器，SIP服务器将第一SIP会话响应消息转发给终端，终端作挂断处理。具体的，SIP协议栈没有事务层数据，则向SIP服务器发送481响应消息，SIP服务器的两次保活均失败，则认为终端SIP呼叫异常，便将481响应消息转发给终端，终端便可挂断呼叫。
本申请实施例中，终端接收到SIP服务器发送的408请求超时消息或者481消息，便可作挂断处理，具体可以参见图1，终端向SIP服务器发送BYE请求消息，向SIP服务器表明想释放呼叫，SIP服务器将BYE请求消息转发给MCU， MCU响应超时，SIP服务器向终端发送408请求超时消息，则终端挂断SIP呼叫，释放SIP会话。
本申请实施例提供的视频会议通信方法，通过SIP服务器进行消息探测来判断出MCU协议栈的状态，并进行相应的策略处理，同时MCU根据SIP服务器的请求消息恢复对应的SIP会话信息，从而保证上会的终端不被挂断且会控功能正常，终端用户感知不到MCU故障的发生，提高了视频会议的可靠性，提升了用户体验。
实施例二：
为了便于理解，本实施例在上述实施例所示的视频会议通信方法基础上进行进一步的示例说明。
请参见图3所示，图3为本申请实施例的视频会议通信方法的具体流程，过程如下：
S301、SIP服务器接收终端在第一保活周期发送的会话保活消息，并将会话保活消息发送给MCU；
本申请实施例中，终端上会成功后，为了检测SIP会话是否一直存在，终端与SIP服务器，SIP服务器与MCU之间会定时发送会话保活消息，会话保活消息为定时发送，即周期性发送，需要说明的是，会话保活消息为UPDATE消息，MCU协议栈收到SIP服务器发送的UPDATE消息中会携带Request-Line、From、To、Call-ID等会话关键信息。
S302、当SIP服务器没有接收到MCU的响应消息时，向终端发送会话保活消息响应消息；
本申请实施例中，MCU发生故障，SIP协议栈死机，不能正常处理消息，此时监测进程还未检测到MCU发生故障，未立即重启SIP协议栈，MCU不响应UPDATE请求消息，SIP服务器没有接收到MCU的响应消息。此时，SIP服务器协议栈由于UPDATE请求消息超时，没有收到MCU响应，SIP服务器则判断此时可能网络原因或者MCU发生故障，为了维持当前SIP会话，不做挂断处 理，向终端发送UPDATE响应消息，UPDATE响应消息具体可以为UPDATE200OK响应消息。
S303、SIP服务器接收终端在第二保活周期发送的会话保活消息，并将会话保活消息发送给MCU；
本申请实施例中，UPDATE会话保活消息是周期性发送的，目的是为了保证SIP会话的正常性和可靠性。
S304、SIP服务器接收到MCU发送的第一SIP会话响应消息，向终端发送会话保活消息响应消息；
本申请实施例中，在第二保活周期到来之前，MCU的监测进程监测到MCU的SIP协议栈进程异常，重新启动了SIP协议栈，但是，由于SIP协议栈是重新启动过的，SIP协议栈中没有与终端对应的SIP会话信息，根据协议规范将相应的第一SIP会话响应消息发送给SIP服务器，在发送第一SIP会话响应消息的同时将会话保活消息异常事件上报给应用服务器。
具体的，SIP协议栈重新启动，SIP协议栈中没有与终端对应的事务层关键数据，根据协议规范会响应481消息，表示SIP事务层数据不存在，在发送481响应消息的同时，SIP协议栈将UPDATE异常事件上报给应用，需要说明的是，UPDATE异常事件中携带了终端号、会议号等标识信息。
需要说明的是，若在第二保活周期，MCU依旧响应超时，SIP服务器则认为MCU或者网络故障且未恢复，便将408请求超时消息发送给终端，终端作异常挂断处理。
S305、SIP服务器接收终端在第三保活周期发送的会话保活消息，并将会话保活消息发送给所述MCU；
S306、SIP服务器接收到MCU发送的会话保活消息响应消息，并将会话保活消息响应消息发送给终端。
本申请实施例中，SIP协议栈将UPDATE异常事件上报给应用，UPDATE异常事件中携带了终端号、会议号等标识信息，需要说明的是，会议号取Request-Line中的用户号码、终端号取From头字段中的用户号码。业务查询对 应终端的会议状态是否正常，若正常，SIP协议栈收到成功响应后，构造出对应终端的SIP会话信息保存到MCU的SIP协议栈事务层中，需要说明的是，SIP协议栈已经构建好SIP会话信息，因此，MCU在下一个保活周期接收到会话保活消息时，可以正常响应会话保活消息，于是向SIP服务器发送200OK响应消息，SIP服务器便可确认MCU已恢复SIP会话信息，MCU侧的会议正常，将200OK响应消息转发给终端。
需要说明的是，若SIP呼叫状态已异常，SIP协议栈没有与终端对应的SIP会话信息，根据协议规范将相应的第一SIP会话响应消息发送给SIP服务器，SIP服务器将第一SIP会话响应消息转发给终端，终端作挂断处理。具体的，SIP协议栈没有事务层数据，则向SIP服务器发送481响应消息，SIP服务器的两次保活均失败，则认为终端SIP呼叫异常，便将481响应消息转发给终端，终端便可挂断呼叫。
本申请实施例中，终端接收到SIP服务器发送的408请求超时消息或者481消息，便可作挂断处理，具体可以参见图1，终端向SIP服务器发送BYE请求消息，向SIP服务器表明想释放呼叫，SIP服务器将BYE请求消息转发给MCU，MCU响应超时，SIP服务器向终端发送408请求超时消息，则终端挂断SIP呼叫，释放SIP会话。
本申请实施例中，在终端成功加入会议后，MCU协议栈模块发生故障死机，监控进程重启MCU协议栈涉及到终端、SIP服务器与MCU三者之间的交互，更为直观具体的流程参见图4。
本申请实施例提供的视频会议通信方法，通过SIP服务器接收终端在第一保活周期发送的会话保活信息，并将会话保活信息发送给MCU，MCU发生故障，不响应会话保活信息，SIP服务器没有接收到MCU的响应消息，SIP服务器判断此时可能MCU故障，维持当前SIP会话，不做挂断处理，向终端发送会话保活信息响应消息；SIP服务器接收终端在第二保活周期发送的会话保活信息，并将会话保活信息发送给所述MCU，此时MCU的监控进程已经检测到SIP协议栈进程异常并重启SIP协议栈，MCU向SIP服务器发送第一SIP会话响应 消息，SIP服务器接收到MCU发送的第一SIP会话响应消息，此时可确认MCU发生了重启且当前SIP协议栈已恢复，仍旧维持当前会话，不做挂断处理，向终端发送会话保活信息响应消息；SIP服务器接收终端在第三保活周期发送的会话保活信息，并将会话保活信息发送给MCU，MCU向SIP服务器发送的会话保活信息响应消息，此时SIP服务器可以确认MCU侧的会议正常，将第三会话保活信息200OK响应消息转发给终端；通过SIP服务器进行消息探测来判断出MCU协议栈的状态，并进行相应的策略处理，同时MCU根据SIP服务器的请求消息恢复对应的SIP会话信息，从而保证上会的终端不被挂断且会控功能正常，终端用户感知不到MCU故障的发生，提高了视频会议的可靠性，提升了用户体验。
实施例三：
应当理解的是，视频会议中还存在图像的传输，UPDATE会话保活信息不正常响应会造成SIP服务器网元挂断呼叫，INFO请求不能正常请求会造成图像解码失败，因此本申请实施例在上述实施例基础上，提出了一种视频会议通信方法，应用在MCU发生故障，协议栈重启后，业务请求I帧时，具体流程请参见图5。
S501、SIP服务器接收终端在第一保活周期发送的会话保活消息，并将会话保活消息发送给MCU。
本申请实施例中，终端上会成功后，为了检测SIP会话是否一直存在，终端与SIP服务器，SIP服务器与MCU之间会定时发送UPDATE会话保活消息，在上述实施例中已经进行了详细说明，这里不再赘述。
S502、当SIP服务器没有接收到MCU的响应消息时，向终端发送会话保活消息响应消息。
本申请实施例中，MCU发生故障，SIP协议栈死机，不能正常处理消息，此时监测进程还未检测到MCU发生故障，未立即重启SIP协议栈，MCU不响应UPDATE请求消息，SIP服务器没有接收到MCU的响应消息。此时，SIP服 务器协议栈会UPDATE请求消息超时，没有收到MCU响应，SIP服务器则判断此时可能网络原因或者MCU发生故障，为了维持当前SIP会话，不做挂断处理，向终端发送UPDATE响应消息，UPDATE响应消息具体可以为UPDATE 200OK响应消息。
S503、MCU的监控进程检测到SIP协议栈进程异常并重启SIP协议栈。
S504、MCU向SIP服务器发送INFO请求消息失败。
本申请实施例中，SIP协议栈重新启动，MCU解码出现错误，此时，MCU向终端发送I帧请求，I帧请求以INFO请求的形式发出。由于SIP协议栈是重新启动过的，SIP协议栈中没有终端对应的SIP会话信息，无法发送INFO请求，导致发送失败。
需要说明的是，I帧(I Frame)又称为内部画面(Intra Picture)，I帧通常是每个GOP(MPEG所使用的一种视频压缩技术)的第一个帧，经过适度地压缩，作为随机访问的参考点，可以当成图像。
S505、SIP服务器接收终端在第二保活周期发送的会话保活消息，并将会话保活消息发送给MCU。
本申请实施例中，INFO请求是在第一保活周期和第二保活周期之间发送。
S506、SIP服务器接收到MCU发送的第一SIP会话响应消息，向终端发送会话保活消息响应消息。
本申请实施例中，MCU的监测进程监测到MCU的SIP协议栈进程异常，重新启动了SIP协议栈，但是，由于SIP协议栈是重新启动过的，SIP协议栈中没有与终端对应的SIP会话信息，根据协议规范将相应的第一SIP会话响应消息发送给SIP服务器，SIP服务器接收到MCU发送的第一SIP会话响应消息，则可以确认MCU发生了重启且当前SIP协议栈已恢复，仍旧维持当前会话，不做挂断处理，向终端发送会话保活消息响应消息。
应当理解的是，第一SIP会话响应消息为481响应消息，会话保活消息响应消息为200OK响应消息。
S507、SIP服务器接收到MCU发送的INFO请求消息，并将INFO请求消 息转发给终端。
应当理解的是，MCU协议栈已经根据第二保活周期发送的UPDATE消息恢复了SIP会话，此时MCU可以正常发送INFO请求。由于上一帧I帧请求失败，MCU图像解码未恢复，因此，MCU再一次向终端发送I帧请求。
S508、终端接收到INFO请求消息后，向SIP服务器发送INFO响应消息，同时通知编码器编I帧。
本申请实施例中，INFO响应消息为200OK消息。
S509、SIP服务器将INFO响应消息转发给MCU。
本申请实施例中，MCU接收到INFO响应消息后则说明MCU图像解码正常，因此I帧请求流程也就结束了。
本申请实施例中，MCU发生故障，监控进程重启MCU协议栈后，业务请求I帧的过程涉及到终端、SIP服务器与MCU三者之间的交互，更为直观具体的流程参见图6。
本申请实施例提供的视频会议通信方法，MCU发生故障重启后，重启的协议栈没有对应的终端的SIP会话信息，在第二保活周期到来之前发送INFO请求失败；SIP服务器接收终端在第二保活周期发送的会话保活消息，并将会话保活消息发送给所述MCU，MCU向SIP服务器发送第一SIP会话响应消息，SIP服务器接收到MCU发送的第一SIP会话响应消息，此时可确认MCU发生了重启且当前SIP协议栈已恢复，仍旧维持当前会话，不做挂断处理，向终端发送会话保活消息响应消息，同时MCU根据会话保活消息恢复SIP对话，MCU便可正常发送INFO请求消息；通过SIP服务器进行消息探测来判断出MCU协议栈的状态，并进行相应的策略处理，同时MCU根据SIP服务器的请求消息恢复对应的SIP会话信息，从而保证上会的终端不被挂断且会控功能正常，终端用户感知不到MCU故障的发生，提高了视频会议的可靠性，提升了用户体验。
实施例四：
本申请实施例还提供了一种视频会议通信装置，用来实现如上述实施例方 法中的至少一个步骤。
本申请实施例的视频会议通信装置包括第一接收模块、第一发送模块：
第一接收模块用于接收终端发送的会话保活消息以及接收MCU发送的第一SIP会话响应消息；
第一发送模块，用于将会话保活消息发送给MCU以及向终端发送会话保活消息响应消息。
本申请实施例的视频会议通信装置还包括监控模块、第二接收模块、第二发送模块以及处理模块；
监控模块用于监测到SIP会话异常并进行MCU重启；
第二接收模块用于接收SIP服务器发送的会话保活消息以及接收终端根据业务查询会议状态正常的成功响应；
第二发送模块用于将第一SIP会话响应消息发送给SIP服务器，同时将会话保活消息异常事件上报给应用服务器；
处理模块，用于构造与所述终端对应的SIP会话信息并保存。
本发明实施例提供的视频会议通信装置，该装置包括第一接收模块、第一发送模块、监控模块、第二接收模块、第二发送模块以及处理模块，实现如上述实施例一至三方法中的至少一个步骤，保证上会的终端不被挂断且会控功能正常，终端用户感知不到MCU故障的发生，提高了视频会议的可靠性，提升了用户体验
实施例五：
本实施例还提供了一种计算机可读存储介质，该计算机可读存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、计算机程序模块或其他数据)的任何方法或技术中实施的易失性或非易失性、可移除或不可移除的介质。计算机可读存储介质包括但不限于RAM(Random Access Memory，随机存取存储器),ROM(Read-Only Memory，只读存储器),EEPROM(Electrically Erasable  Programmable read only memory，带电可擦可编程只读存储器)、闪存或其他存储器技术、CD-ROM(Compact Disc Read-Only Memory，光盘只读存储器)，数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。
本实施例中的计算机可读存储介质可用于存储一个或者多个计算机程序，其存储的一个或者多个计算机程序可被处理器执行，以实现上述实施例一和实施例三中的视频会议通信方法的至少一个步骤。
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (12)

  1. 一种视频会议通信方法，包括：
    MCU重启后，SIP服务器接收终端发送的会话保活消息，并将所述会话保活消息发送给所述MCU，所述会话保活信息为所述终端按照保活周期进行发送；
    所述SIP服务器接收所述MCU发送的第一SIP会话响应消息，并向所述终端发送会话保活消息响应消息。
  2. 如权利要求1所述的视频会议通信方法，其中，所述MCU重启后，SIP服务器接收终端发送的会话保活消息之前包括：
    所述SIP服务器接收终端发送的会话保活消息，并将所述会话保活消息发送给MCU；
    所述SIP服务器没有接收到所述MCU的响应消息，向所述终端发送会话保活消息响应消息。
  3. 如权利要求1所述的视频会议通信方法，其中，所述SIP服务器接收终端发送的会话保活消息，并将所述会话保活消息发送给所述MCU之后还包括：
    所述SIP服务器没有接收到所述MCU的响应消息，向所述终端发送请求超时消息。
  4. 如权利要求1所述的视频会议通信方法，其中，所述SIP服务器接收到所述MCU发送的第一SIP会话响应消息，并向所述终端发送会话保活消息响应消息之后还包括：
    所述SIP服务器接收终端发送的会话保活消息，并将所述会话保活消息发送给所述MCU；
    所述SIP服务器接收到所述MCU发送的第一SIP会话响应消息，将所述第一SIP会话响应消息发送给所述终端。
  5. 如权利要求1所述的视频会议通信方法，其中，所述MCU重启后还包括：
    所述MCU向所述SIP服务器发送INFO请求消息失败。
  6. 如权利要求5所述的视频会议通信方法，其中，所述SIP服务器接收到所 述MCU发送的第一SIP会话响应消息，并向所述终端发送会话保活消息响应消息之后包括：
    所述SIP服务器接收到所述MCU发送的INFO请求消息，并将所述INFO请求消息转发给所述终端；
    所述SIP服务器接收到所述终端发送的所述INFO响应消息并转发给所述MCU。
  7. 一种视频会议通信方法，包括：
    MCU监控进程监测到SIP会话异常并进行重启；
    所述MCU接收SIP服务器发送的会话保活消息，所述会话保活信息为所述终端按照保活周期发送给所述SIP服务器；
    所述MCU将第一SIP会话响应消息发送给所述SIP服务器，同时将会话保活消息异常事件上报给应用服务器；
    所述MCU接收到所述终端根据业务查询会议状态正常的成功响应后，构造与所述终端对应的SIP会话信息并保存。
  8. 如权利要求7所述的视频会议通信方法，其中，所述MCU监控进程检测到SIP会话异常并进行重启之后包括：
    所述MCU向所述SIP服务器发送INFO请求消息失败。
  9. 如权利要求8所述的视频会议通信方法，其中，所述SIP服务器接收到所述MCU发送的第一SIP会话响应消息，并向所述终端发送会话保活消息响应消息之后包括：
    所述MCU向所述SIP服务器发送INFO请求消息；
    所述MCU接收所述SIP服务器发送的INFO响应消息，所述INFO响应消息为所述SIP服务器接收所述终端根据接收到的INFO请求消息后发送的响应消息。
  10. 一种视频会议通信装置，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现如权利要求1至6任一所述的视频会议通信方法。
  11. 一种视频会议通信装置，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现如权利要求7至9任一所述的视频会议通信方法。
  12. 一种计算机可读存储介质，其中，所述计算机可读存储介质存储有一个或者多个计算机程序，所述一个或者多个计算机程序可被一个或者多个处理器执行，以实现如权利要求1-9中任一项所述的视频会议通信方法的步骤。
PCT/CN2020/114051 2019-09-10 2020-09-08 一种视频会议通信方法、装置以及计算机可读存储介质 WO2021047513A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910854628.0 2019-09-10
CN201910854628.0A CN112565661A (zh) 2019-09-10 2019-09-10 一种视频会议通信方法、装置以及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2021047513A1 true WO2021047513A1 (zh) 2021-03-18

Family

ID=74867209

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/114051 WO2021047513A1 (zh) 2019-09-10 2020-09-08 一种视频会议通信方法、装置以及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN112565661A (zh)
WO (1) WO2021047513A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112995697B (zh) * 2021-04-30 2021-09-07 武汉斗鱼鱼乐网络科技有限公司 一种流数据恢复方法、服务器、存储介质及计算机设备
CN114679433B (zh) * 2022-05-27 2022-08-30 武汉中科通达高新技术股份有限公司 视频访问会话管理系统、方法、计算机设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101917586A (zh) * 2010-08-17 2010-12-15 杭州华三通信技术有限公司 一种会议的加入方法和设备
CN102316301A (zh) * 2010-06-29 2012-01-11 华为终端有限公司 会议切换的方法、系统及设备
US20130141517A1 (en) * 2011-12-06 2013-06-06 Aastra Technologies Limited Collaboration system & method
CN104660952A (zh) * 2015-03-04 2015-05-27 苏州科达科技股份有限公司 视频会议通信方法和系统
CN104796564A (zh) * 2013-10-23 2015-07-22 中兴通讯股份有限公司 基于ip电话的留言业务处理方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102316301A (zh) * 2010-06-29 2012-01-11 华为终端有限公司 会议切换的方法、系统及设备
CN101917586A (zh) * 2010-08-17 2010-12-15 杭州华三通信技术有限公司 一种会议的加入方法和设备
US20130141517A1 (en) * 2011-12-06 2013-06-06 Aastra Technologies Limited Collaboration system & method
CN104796564A (zh) * 2013-10-23 2015-07-22 中兴通讯股份有限公司 基于ip电话的留言业务处理方法及装置
CN104660952A (zh) * 2015-03-04 2015-05-27 苏州科达科技股份有限公司 视频会议通信方法和系统

Also Published As

Publication number Publication date
CN112565661A (zh) 2021-03-26

Similar Documents

Publication Publication Date Title
US8140895B2 (en) Method and system for recovering SIP transaction
US9201743B2 (en) Backup SIP server for the survivability of an enterprise network using SIP
US9319431B2 (en) Methods, systems, and computer readable media for providing sedation service in a telecommunications network
US20070041327A1 (en) Multicast heartbeat signaling
US7539127B1 (en) System and method for recovering from endpoint failure in a communication session
US20130297804A1 (en) Load Balancing for SIP Services
WO2021047513A1 (zh) 一种视频会议通信方法、装置以及计算机可读存储介质
US20100205263A1 (en) Sip server architecture for improving latency during message processing
US20140022889A1 (en) Transferring a conference session between conference servers due to failure
US20100074100A1 (en) Proxy server, communication system, communication method and program
US20050180317A1 (en) Server backup device
WO2011103837A2 (zh) 服务器故障时的报文处理方法及路由器
WO2016101457A1 (zh) 一种终端及终端呼叫软切换的方法
CN112564990B (zh) 一种用于音频管理服务器切换的管理方法
CN113489601A (zh) 基于视联网自治云网络架构的抗毁方法和装置
US20110286365A1 (en) Method for Connection Preservation
JP4883487B2 (ja) 中継装置、ネットワークシステム及び中継処理プログラム
US8675829B1 (en) Notify caller if low quality voicemail is being recorded
CN108337103B (zh) Sip服务器的备份方法、备用恢复方法和系统
JP6635525B1 (ja) 交換機、通信システム、登録方法及び登録プログラム
US8046656B2 (en) Rendering and correcting data
CN114679433B (zh) 视频访问会话管理系统、方法、计算机设备及存储介质
CN111385519B (zh) 实现视频会议恢复的方法、装置、终端及多点控制单元
WO2023246883A1 (zh) 视频会议方法、电子设备及计算机存储介质
JP5120677B2 (ja) 中継装置、ネットワークシステム及び中継処理プログラム

Legal Events

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

Ref document number: 20862610

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20862610

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 20862610

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 26-08-2022)

122 Ep: pct application non-entry in european phase

Ref document number: 20862610

Country of ref document: EP

Kind code of ref document: A1