WO2014187214A1 - 一种网页实时通信方法、系统及终端 - Google Patents

一种网页实时通信方法、系统及终端 Download PDF

Info

Publication number
WO2014187214A1
WO2014187214A1 PCT/CN2014/075902 CN2014075902W WO2014187214A1 WO 2014187214 A1 WO2014187214 A1 WO 2014187214A1 CN 2014075902 W CN2014075902 W CN 2014075902W WO 2014187214 A1 WO2014187214 A1 WO 2014187214A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
port
address
client
nat
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.)
Ceased
Application number
PCT/CN2014/075902
Other languages
English (en)
French (fr)
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.)
Huawei Device Co Ltd
Original Assignee
Huawei Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Device Co Ltd filed Critical Huawei Device Co Ltd
Priority to EP14801045.7A priority Critical patent/EP2905944A4/en
Publication of WO2014187214A1 publication Critical patent/WO2014187214A1/zh
Priority to US14/755,236 priority patent/US20150304364A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/046—Interoperability with other network applications or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2589—NAT traversal over a relay server, e.g. traversal using relay for network address translation [TURN]
    • 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/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a webpage real-time communication method, system, and terminal. Background technique
  • WebRTC Web Real-time Communication
  • WebRTC is a software architecture designed to support web browsers for real-time voice conversations or video conversations.
  • WebRTC can implement audio and video communication between browsers and browsers, or between browsers and traditional terminals, and multi-party conferencing. After the communication parties using WebRTC use the signaling channel to negotiate to establish a call, the media stream can be directly transmitted between the browsers.
  • terminals such as smartphones or tablets
  • WebRTC WebRTC
  • the WebRTC between the terminals may be interrupted.
  • a real-time communication method, system, and terminal for a webpage are provided.
  • the terminal on the interruption side can automatically initiate a process of restoring the establishment of the media channel, and realizing real-time communication of the webpage. Automatically reconnect to avoid affecting the user experience.
  • a method for real-time communication of a webpage including:
  • the first terminal and the second terminal perform real-time communication of the webpage, where the first terminal and the second terminal respectively store attribute information of the current media channel;
  • the recovering the process of establishing a media channel includes:
  • the first NAT client When the private IP address and port of the first network address translation NAT client on the first terminal are not changed, the first NAT client sends a first request message to the associated first NAT server, where The first request message is used to request the first NAT server to re-establish the original media channel;
  • the first NAT server receives the first request message, and re-establishes an original media channel according to attribute information of the original media channel.
  • the recovering the process of establishing a media channel further includes:
  • the STUN client sends a second request message to the associated STUN server.
  • the second request message carries the original public network IP address and port information of the STUN client;
  • the STUN server establishes a mapping relationship between the new IP address and the port of the STUN client and the original public network IP address and port information of the STUN client, and establishes a new media channel according to the mapping relationship.
  • the recovering the process of establishing a media channel is further Includes:
  • the TURN client sends a third request message to the TURN server to which it belongs.
  • the third request message carries the original public network IP address and port information of the TURN server;
  • the TURN server establishes a mapping relationship between the new IP address and the port of the TURN client and the original public network IP address and port information of the TURN server, and establishes a new media channel according to the mapping relationship.
  • the process of restoring the establishment of the media channel includes:
  • the NAT client on the terminal sends a UPnP port mapping request to the UPnP gateway device, and receives the UPnP gateway device.
  • the port information allocated by the port mapping request the previous media channel is re-established according to the original IP address and the allocated port.
  • a terminal including: [025] a webpage real-time communication module, configured to perform real-time webpage communication with the second terminal;
  • an information saving module configured to save attribute information of a current media channel
  • the network interrupt detection module is configured to detect whether an interruption occurs in the network, and when the network connection is resumed within a preset time threshold after a network interruption occurs, the channel recovery initiation module is triggered;
  • the channel recovery initiating module is configured to automatically initiate a process of restoring and establishing a media channel according to the attribute information
  • the webpage real-time communication module is further configured to continue to perform real-time webpage communication with the second terminal by restoring the established media channel.
  • the channel recovery initiating module includes: [031] a first request message sending submodule, configured to be private to a NAT client on the terminal When the IP address and the port are not changed, the NAT client sends a first request message to the associated first NAT server, where the first request message is used to request the first NAT server to re-restore the attribute information of the original media channel. Establish the original media channel.
  • the channel recovery initiating module further includes:
  • the second request message sending sub-module is configured to: when the NAT mode is that the user data packet protocol simply traverses the STUN mode, and the private IP address and port of the STUN client on the terminal change, the STUN client sends the STUN client to the STUN client.
  • the server sends a second request message, where the second request message carries the original public network IP address and port information of the STUN client, so that the STUN server establishes a new IP address and port of the STUN client and the STUN client.
  • a mapping relationship between the original public network IP address and the port information is established, and a new media channel is established according to the mapping relationship.
  • the channel recovery initiation module further includes :
  • a third request message sending submodule configured to: when the NAT mode is a TURN mode through a relay traversing network address, and the private IP address and port of the TURN client on the terminal change, the TURN client belongs to the TURN client
  • the TURN server sends a third request message, where the third request message carries the original public network IP address and port information of the TURN server, so that the TURN server establishes a new IP address and port of the TURN client and the TURN.
  • the packet includes:
  • a port allocation requesting sub-module configured to: when the terminal and the associated UPnP gateway device support the UPnP protocol, the NAT client on the terminal sends a UPnP port mapping request to the UPnP gateway device;
  • a port information receiving submodule configured to receive port information allocated by the UPnP gateway device according to the port mapping request
  • a channel recovery sub-module configured to re-establish the previous media channel by the NAT client according to the original IP address and the allocated port.
  • a webpage real-time communication system including: a first terminal and a second terminal that perform real-time communication of a webpage, where the first terminal and the second terminal each hold attribute information of a current media channel, when After the network interruption occurs in the first terminal, when the network connection is restored within the preset time threshold,
  • the first terminal is configured to automatically initiate a process of restoring the establishment of the media channel according to the attribute information, and continue to perform real-time communication with the second terminal by using the restored media channel.
  • the first terminal specifically includes: a first NAT client, where the first NAT client corresponds to a first NAT server;
  • the first NAT client is configured to send a first request message to the first NAT server when the private IP address and the port are not changed, where the first request message is used to request the first NAT server. Re-establishing the original media channel;
  • the first NAT server is configured to receive the first request message, and re-establish the original media channel according to the attribute information of the original media channel.
  • the first NAT client is a STUN client
  • the first NAT server is STUN server
  • the STUN client is configured to send a second request message to the STUN server when the private IP address and the port change, where the second request message carries the original public network IP address and port information.
  • the STUN server is configured to establish a mapping relationship between a new IP address and a port of the STUN client and an original public network IP address and port information of the STUN client, and establish a new media channel according to the mapping relationship. .
  • the TURN client is configured to send a third request message to the TURN server when the private IP address and the port are changed, where the request message carries the original public network IP address and port information of the TURN server;
  • the TURN server configured to establish a new IP address and port of the TURN client, and the TURN service A mapping relationship between the original public network IP address and port information of the server, and establishing a new media channel according to the mapping relationship.
  • the NAT client on the terminal is configured to send a UPnP port mapping request to the UPnP gateway device, and receive the port information allocated by the UPnP gateway device according to the port mapping request, according to the original IP address and the allocated The port re-establishes the previous media channel.
  • the first terminal on the interruption side can automatically initiate the process of restoring the establishment of the media channel. To resume the establishment of the media channel, and then continue real-time communication with the second terminal through the recovered media channel, thereby realizing automatic reconnection of the real-time communication between the two terminals, thereby avoiding communication interruption and bringing the user experience to the user. Impact.
  • FIG. 1 is a flow chart of an embodiment of a webpage real-time communication method according to the present invention.
  • FIG. 2 is a flowchart of an embodiment of a webpage real-time communication method in a first application scenario of the present invention
  • FIG. 3 is a flow chart of an embodiment of a webpage real-time communication method in a second application scenario of the present invention
  • FIG. 4 is a flowchart of a method for real-time communication of a webpage in a third application scenario according to the present invention.
  • FIG. 5 is a flowchart of an embodiment of a webpage real-time communication method in a fourth application scenario of the present invention.
  • FIG. 6 is a block diagram of a first embodiment of a terminal of the present invention.
  • FIG. 7 is a block diagram of an implementation of a channel recovery initiating module according to the present invention.
  • FIG. 8 is a block diagram of an implementation of another channel recovery initiating module according to the present invention. detailed description
  • FIG. 1 is a flow chart of an embodiment of a webpage real-time communication method according to the present invention. Specifically, the method can Includes the following steps:
  • Step 101 The first terminal and the second terminal perform a NAT (Network Address Translator), where the first terminal and the second terminal respectively store attribute information of the current media channel.
  • NAT Network Address Translator
  • the attribute information of the media channel refers to configuration information related to the current media channel recorded by the terminal when the media channel is connected normally.
  • Step 102 When the network connection is resumed within the preset time threshold after the network interruption occurs in the first terminal, the process of restoring the establishment of the media channel is automatically initiated according to the attribute information;
  • the process of restoring the establishment of the media channel is automatically initiated by the terminal on the network interruption side to implement automatic reconnection of the NAT.
  • a time threshold is preset on the terminal side for recording the time for resuming the network connection after the network interruption. It can be seen that, in this embodiment, when a sudden network interruption occurs suddenly, the terminal can automatically initiate a NAT reconnection, so that the end user does not feel the interruption of the communication at all.
  • the specific configuration value of the time threshold can be set according to the actual application scenario, and is not specifically limited here.
  • Step 103 The first terminal continues to perform real-time network communication with the second terminal by restoring the established media channel.
  • the interruption side A terminal can automatically initiate a process of restoring the establishment of the media channel, to restore the establishment of the media channel, and then continue real-time communication with the second terminal through the recovered media channel, thereby realizing automatic real-time communication between the two terminals. Even, to avoid the impact of communication disruption on the user experience.
  • IP address obtained by the mobile terminal is the intranet address of the operator. Therefore, the mobile terminal only has the private IP address of the local area network regardless of whether the Wi-Fi accesses the Internet or the 3G Internet access, and the external network. What is needed for terminal communication is to obtain public IP through NAT conversion, and there is a problem that communication traverses the NAT server.
  • the process of restoring the establishment of the media channel in the foregoing step 102 may specifically include the following implementation manners:
  • the first NAT client sends a first request message to the first NAT server that belongs to the first request.
  • the message is used to request the first NAT server to re-establish the original media channel; the first NAT server receives the first request message, and re-establishes the original media channel according to the attribute information of the original media channel.
  • the private IP address and port of the first NAT client on the first terminal are not changed, the attribute information of the related media channel does not change, and the current media is saved on the first NAT server.
  • the attribute information of the channel so that the first request message can be directly sent to the first NAT server by using the attribute information of the current media channel, so that the first NAT server re-establishes the original media channel according to the attribute information of the original media channel.
  • the second terminal When the first terminal performs NAT communication with the second terminal, the second terminal should simultaneously store related attribute information of the media channel. The reason is that, according to the attribute information, the second terminal may learn that the communication terminal that initiates the process of restoring the establishment of the media channel is the first terminal that communicated before, and therefore, the process does not need to be re-authenticated by the second terminal. , you can directly connect, further reducing the time for NAT reconnection.
  • the NAT server may include: a STUN server and a TURN server. The following two NAT traversal methods are briefly introduced.
  • the VOIP terminal in the private network obtains the external address on the egress NAT server in advance, and then directly fills in the address information in the payload on the external address on the egress NAT server instead of The private IP address of the terminal in the private network, so that the content in the payload does not need to be modified when passing through the NAT server. It only needs to convert the IP address of the packet header according to the normal NAT process, and the IP address information in the payload. The header address information is consistent.
  • the application on the V0IP terminal that is, the STUN CLIENT, sends a STUN message to the STUN server (STUN SERVER) through UDP, and the STUN SERVER receives the request message, and generates a response message, and the response message carries the request message.
  • the source port that is, the corresponding external port of the STUN client on the NAT server.
  • the response message is sent to the STUN client through the NAT.
  • the STUN client knows the external address on the NAT server by responding to the contents of the message body, and fills it into the UDP payload of the future call protocol, and informs the peer end that the local end RTP (Real-time Transport Protocol)
  • the receiving address and port number are the address and port number outside the NAT. Since the NAT mapping entry of the media stream is pre-established on the NAT through the STUN protocol, the media stream can successfully traverse the NAT.
  • the TURN mode is similar to STUN. It is also the V0IP terminal in the private network that obtains the service address of the TURN server (TURN Server) on the public network through some mechanism, and then directly fills in the TURN with the address information in the payload of the message. The public address of the server. The TURN assigns the public address and port of the TURN Server to the externally accepted address and port of the V0IP terminal in the private network. That is, the packets sent by the private network terminal are forwarded by the TURN Server.
  • TURN Server the service address of the TURN server
  • the STUN client sends a second request message to the associated STUN server, where the second request message carries the original of the STUN client.
  • Public network IP address and port information the STUN server establishes a mapping relationship between the new IP address and the port of the STUN client and the original public network IP address and port information of the STUN client, and establishes a new relationship according to the mapping relationship.
  • Media channel the mapping relationship between the new IP address and the port of the STUN client and the original public network IP address and port information of the STUN client.
  • the process of restoring the establishment of the media channel in the foregoing step 102 may specifically include the following implementation manners:
  • the TURN client sends a request for the third message to the TURN server to which the UTN server is located, where the third request message carries the original TURN server.
  • Public network IP address and port information the TURN server establishes a mapping relationship between the new IP address and port of the TURN client and the original public network IP address and port information of the TURN server, and establishes a new relationship according to the mapping relationship.
  • Media channel Media channel.
  • Step 0 A and B use the WebRTC App to establish a real-time audio and video call (in a specific application, the RTCPeerConnection object can be implemented), when the call is connected, both NAT clients (ie, Browser Browser) must be Stores attribute information of the current media channel.
  • NAT clients ie, Browser Browser
  • the information stored by the client can include:
  • Transaction ID Can be a 96-bit number used to uniquely identify a STUN transaction
  • a mapped IP address/port number Sends a binding to the STUN server on the STUN client When requested, the public network IP address and port number assigned to the STUN client by the outermost NAT, that is, the external address on the egress NAT;
  • Destination IP/Port IP address of the peer device with which to communicate And port number
  • Remote Description The far-end description information that was recently set, and the far-end candidate address that was provided.
  • Step 1 the terminal of A has a network interruption due to an accidental reason.
  • the browser of A knows that the network connection has been lost, and the WebRTC server knows that A has been dropped, and the browser of B no longer accepts.
  • the browsers of both parties can use the callback function RTCPeerConnectionErrorCal lback to inform the respective WebRTC App of the current network error type, BP: no network connection.
  • Step 2 Both WebRTC App respond to the "No Network Connection” error type: Start the timing event.
  • the App developer can set a time threshold T in advance. When there is no network connection beyond this time, the browser informs the App that the call is interrupted, and clears the attribute related information of the previously stored media channel. If the network is reconnected within less than T, perform the following steps.
  • Step 3 The browser of A sends a request message to the associated STUN server, requesting to restore the media channel between the browser with B.
  • the previous Transaction ID may be carried, and the purpose is to notify the STUN server to which the browser belongs to keep the session from continuing.
  • Step 4 The browser of A informs the owned WebRTC App network that the network has been reconnected, and the media channel is restored.
  • Step 5 The WebRTC App to which A belongs is clearing the timing event. B knows that after A goes online, the associated WebRTC App also clears the timing event.
  • Step 6 the browser of A resets the attribute information of the media channel Local Description and Remote Descriptior
  • Step 7 A still uses the original Reflexive IP/Port to transmit the media stream to B, and the two parties resume the call.
  • the STA traversal is still implemented by using the STUN mode.
  • the IP address and port of the A terminal are changed, as shown in FIG. 3 .
  • the following implementation steps are included:
  • Step 0 A and B use the WebRTC App to establish a real-time audio and video call.
  • both NAT clients ie, the Browser Browser
  • the attribute information of the media channel may include: a transaction identifier, a mapped IP address/port number, and a destination. IP address/port number, local description, and remote description.
  • Step 1 the terminal of A has a network interruption due to an accidental reason, the browser of A knows that the network connection has been lost, the WebRTC server knows that A has been dropped, and the browser of B no longer receives the media stream of A.
  • the browsers of both parties can use the callback function RTCPeerConnectionErrorCal lback to inform the respective WebRTC App of the current network error type, namely: no network connection.
  • Step 2 Both WebRTC App respond to the "No Network Connection" error type: Start the timing event.
  • Step 3 The browser of A sends a request message to the associated STUN server, requesting to restore the media channel between the browser with B.
  • the request message carries the original Reflexive IP/Port information, and the information may be carried by the X0R-MAPPED-ADDRESS or MAPPED-ADDRESS attribute of the enhanced message in the request message.
  • the MAPPED-ADDRESS attribute indicates a reflexive transmission address of the Client, including an 8-bit address family and a 16-bit port, and a fixed-length IP address, where the attribute directly represents the transmission address; and the X0R-MAPPED-ADDRESS attribute indicates the transmission address.
  • the method is processed by the X0R function.
  • Step 4 The STUN server to which A belongs belongs sends a response message to the browser, and informs the browser of the A that the NAT outgoing transmission address information is the original Reflexive IP/Port information.
  • the STUN server extracts the Reflexive IP/Port information from the X0R-MAPPED-ADDRESS or MAPPED-ADDRESS attributes, and uses it as the CLI export address of the client, and returns it to the client, X0R- in the response message.
  • the MAPPED-ADDRESS or MAPPED-ADDRESS attribute is also set to the Reflexive IP/Port.
  • Step 5 The WebRTC App to which A belongs is clearing the timing event. B knows that after A goes online, the associated WebRTC App also clears the timing event.
  • Step 6 the browser of A resets the attribute information of the media channel Local Description and Remote Descriptior
  • Step 7 A still uses the original Reflexive IP/Port to transmit the media stream to B, and the calls of both parties are restored.
  • the NAT traversal is implemented by using the TURN mode, and the IP address and port of the A terminal are not changed. As shown in FIG. 4, the following implementation steps are included:
  • Step 0 A and B use the WebRTC App to establish a real-time audio and video call (in a specific application, the RTCPeerConnection object can be implemented), when the call is connected, both NAT clients (ie, Browser Browser) must be The attribute information of the current media channel is stored, and the stored information may include: [0120] Relayed IP/Port Number: The TURN Server controls the public network address and port of the TURN server assigned to the TURN client;
  • mapped IP address/port number (Reflexive IP/Port): The public network IP address and port number assigned by the egress NAT to the TURN client;
  • destination IP address/port number (Destination IP/Port): the IP address and port number of the peer device with which it communicates;
  • Remote Description The far-end description information that has been recently set, and the far-end candidate address that is provided.
  • Step 1 The terminal of A has a network interruption due to an accident.
  • the browser of A knows that the network connection has been lost, and the WebRTC server knows that A has been dropped, and the browser of B no longer accepts.
  • the browsers of both parties can use the callback function RTCPeerConnectionErrorCal lback to inform the respective WebRTC App of the current network error type, BP: no network connection.
  • Step 2 Both WebRTC App respond to the "No Network Connection" error type: Start the timing event.
  • Step 3 The browser of A sends a request message to the TURN server, requesting to restore the media channel between the browser with B.
  • Step 4 The browser of A informs that the associated WebRTC App network has been reconnected, and the media channel is restored.
  • Step 5 The WebRTC App to which A belongs belongs to clear the timing event. B knows that after A goes online, the associated WebRTC App also clears the timing event.
  • Step 6 the browser of A resets the attribute information of the media channel Local Description and Remote Descriptior
  • Step 7 A's browser still sends the media stream data to the TURN server using the previous Reflexive IP/Port
  • Step 8 The TURN server still forwards the media stream data to B using the previous Relayed IP/Port, and the two-party call is restored.
  • Step 0 A and B use the WebRTC App to establish a real-time audio and video call (in a specific application, the RTCPeerConnection object can be implemented), when the call is connected, both NAT clients (ie, Browser Browser) must be The attribute information of the current media channel is stored, and the stored information may include: a relayed IP address/port number, a mapped IP address/port number, a destination IP address/port number, a local description, and a remote description.
  • Step 1 The terminal of A has a network interruption due to an accident.
  • the browser of A knows that the network connection has been lost, and the WebRTC server knows that A has been dropped, and the browser of B no longer accepts.
  • the browsers of both parties can use the callback function RTCPeerConnectionErrorCal lback to inform the respective WebRTC App of the current network error type, BP: no network connection.
  • Step 2 Both WebRTC App respond to the "No Network Connection" error type: Start the timing event.
  • Step 3 The browser of A sends a request message to the TURN server requesting to restore the media channel between the browser with B.
  • the request message carries the original Relayed IP/Port information, so that the TURN server establishes a NAT mapping relationship between the new IP address and the port and the original Relayed IP/Port information.
  • Step 4 The TURN server to which the A belongs establishes a NAT mapping relationship between the new IP address and the port and the original Relayed IP/Port information.
  • Step 5 The TURN server to which the A belongs sends a response message to the browser, and feeds back the NAT mapping relationship.
  • Step 6 the browser of A informs the owned WebRTC App network that the network has been reconnected, and the media channel is restored.
  • Step 7 The WebRTC App to which A belongs clears the timing event. B knows that after A goes online, the associated WebRTC App also clears the timing event.
  • Step 8 the browser of A resets the attribute information of the media channel Local Description and Remote Descriptior
  • Step 9 A's browser still sends the media stream data to the TURN server using the previous Reflexive IP/Port.
  • Step 10 The TURN server still forwards the media stream data to B by using the previous Relayed IP/Port, and the two parties resume the call.
  • the terminal when the first terminal and the associated UPnP (Universal Plug and Play) gateway device support the UPnP protocol, the terminal is configured on the terminal.
  • the NAT client sends a UPnP port mapping request to the UPnP gateway device, and receives the port information allocated by the UPnP gateway device according to the port mapping request, and re-establishes the previous media channel according to the original IP address and the allocated port.
  • the IP address and port information used by both parties of the call are unchanged, and therefore, the previous media channel can be re-established according to the original IP address and the allocated port.
  • the present invention also provides a terminal.
  • the terminal may include:
  • a webpage real-time communication module 601 configured to perform real-time webpage communication with the second terminal
  • the information saving module 602 is configured to save attribute information of the current media channel.
  • the network interrupt detection module 603 is configured to detect whether an interruption occurs in the network, and when the network connection is resumed within a preset time threshold after a network interruption occurs, the channel recovery initiation module 604 is triggered;
  • the channel recovery initiating module 604 is configured to automatically initiate a process of restoring and establishing a media channel according to the attribute information within a preset time threshold.
  • the webpage real-time communication module 601 is further configured to continue to perform real-time webpage communication with the second terminal by restoring the established media channel.
  • the terminal on the interruption side can automatically initiate a process of restoring the establishment of the media channel to resume the establishment.
  • the media channel, and then through the recovered media channel continues to perform real-time communication with the second terminal of the opposite end, thereby realizing automatic reconnection of the real-time communication between the two terminals, thereby avoiding the impact of the communication interruption on the user experience.
  • the channel recovery initiating module 604 may include:
  • the first request message sending sub-module 701 is configured to: when the private IP address and port of the NAT client on the terminal are not changed, the NAT client sends a first request message to the associated NAT server, where The first request message is used to request the first NAT server to re-establish the original media channel according to the attribute information of the original media channel.
  • the foregoing first request message sending submodule is adapted to implement NAT traversal in the STUN and TURN modes.
  • the channel recovery initiating module 604 may further include:
  • the second request message sending sub-module 702 is configured to: when the NAT mode is that the user data packet protocol simply traverses the STUN mode, and the private IP address and port of the STUN client on the terminal change, the STUN client belongs to the The STUN server sends a second request message, where the second request message carries the original public network IP address and port information of the STUN client, so that the STUN server establishes a new IP address and port of the STUN client and the STUN A mapping relationship between the original public network IP address and the port information of the client, and establishing a new media channel according to the mapping relationship.
  • the channel recovery initiating module 604 may further include:
  • the third request message sending sub-module 703 is configured to: when the NAT mode is traversing the network address through the relay In the TURN mode, when the private IP address and port of the TURN client on the terminal are changed, the TURN client sends a third request message to the TURN server to which the TURN server is located, where the third request message carries the original public network of the TURN server. IP address and port information; so that the TURN server establishes a mapping relationship between the new IP address and port of the TURN client and the original public network IP address and port information of the TURN server, and establishes new media according to the mapping relationship. channel.
  • the present invention further provides an implementation manner of a channel recovery initiating module.
  • the channel recovery initiating module may include:
  • a port allocation request sub-module 801 configured to: when the terminal and the associated UPnP gateway device support the UPnP protocol, the NAT client on the terminal sends a UPnP port mapping request to the UPnP gateway device;
  • the port information receiving submodule 802 is configured to receive port information that is allocated by the UPnP gateway device according to the port mapping request.
  • the channel recovery sub-module 803 is configured to re-establish the previous media channel by the NAT client according to the original IP address and the allocated port.
  • the IP address and port information used by the terminals on both sides of the call are unchanged, and therefore, the previous IP address and the assigned port may be re-established according to the original IP address and the assigned port.
  • Media channel
  • the present invention further provides a webpage real-time communication system, the system includes: a first terminal and a second terminal that perform real-time communication of a webpage, where the first terminal and the second terminal each have a current The attribute information of the media channel, wherein, when the network connection is re-established within the preset time threshold after the network interruption occurs in the first terminal, the first terminal is configured to be within the preset time threshold according to the attribute The information is automatically initiated to resume the process of establishing a media channel, and the real-time communication with the second terminal is continued by restoring the established media channel.
  • the first terminal specifically includes: a first NAT client, where the first NAT client corresponds to the first NAT server;
  • the first NAT client is configured to send a first request message to the first NAT server when the private IP address and the port are not changed, where the first request message is used to request the first NAT server. Re-establishing the original media channel;
  • the first NAT server is configured to receive the first request message, and re-establish the original media channel according to the attribute information of the original media channel.
  • the STUN client is used to change the private IP address and port to the STUN.
  • the server sends a second request message, where the second request message carries the original public network IP address and port information;
  • the STUN server is configured to establish a mapping relationship between a new IP address and a port of the STUN client and an original public network IP address and port information of the STUN client, and establish a new media channel according to the mapping relationship.
  • the TURN client is configured to change to a TURN when a private IP address and a port change.
  • the server sends a third request message, where the request message carries the original public network IP address and port information of the TURN server;
  • the TURN server is configured to establish a new IP address and port of the TURN client.
  • the mapping relationship between the original public network IP address and the port information of the TURN server is established, and a new media channel is established according to the mapping relationship.
  • the NAT client on the terminal is configured to send a UPnP port mapping request to the UPnP gateway device, and receive the UPnP gateway device.
  • the previous media channel is re-established according to the original IP address and the allocated port.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in electrical, mechanical or other form.
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the functions may be stored in a computer readable storage medium if implemented in the form of a software functional unit and sold or used as a standalone product.
  • the technical solution of the present invention which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including
  • the instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a U disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

Landscapes

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

Abstract

本发明实施例公开了一种网页实时通信方法、系统及终端。其中，所述方法包括：第一终端与第二终端进行网页实时通信，所述第一终端与第二终端各自保存有当前媒体信道的属性信息；当所述第一终端发生网络中断之后，在预置时间阈值内重新恢复网络连接时，根据所述属性信息，自动发起恢复建立媒体信道的流程；所述第一终端通过恢复建立的媒体信道，继续与所述第二终端进行网页实时通信。本发明实施例中，当发生短暂网络中断之后重新恢复网络连接时，中断侧的终端能够自动发起恢复建立媒体信道的流程，实现网页实时通信的自动重连，避免影响用户的使用体验。

Description

一种网页实时通信方法、 系统及终端
[01] 本申请要求于 2013年 5月 21 日提交中国专利局、 申请号为 201310189867. 1、 发 明名称为 "一种网页实时通信方法、 系统及终端" 的中国专利申请的优先权， 其全部内 容通过引用结合在本申请中。
技术领域
[02] 本发明涉及通信技术领域， 特别是涉及一种网页实时通信方法、 系统及终端。 背景技术
[03] WebRTC ( Web Real-time Communication , 网页实时通信） 是一项旨在支持网络 浏览器进行实时语音对话或视频对话的软件架构。 WebRTC可以实现浏览器与浏览器之间、 或浏览器与传统终端之间的音视频通信、 多方会议等功能。 使用 WebRTC的通信双方使用 信令通道进行协商建立通话之后， 浏览器之间可以直接传输媒体流。
[04] 基于便携性的优势， 终端 （例如： 智能手机或平板电脑等） 已成为 WebRTC 的重 要应用平台。
[05] 然而， 由于终端的移动性或者无线网络部署导致的网络信号不稳定甚至无信号等 原因， 例如： 终端用户进入信号盲区， 或者信号受到干扰， 终端之间的 WebRTC可能发生 中断。
[06] 当终端之间的 WebRTC 发生中断之后， 需要用户通过手动重拨的方式进行再次连 接， 以恢复 WebRTC, 影响用户体验。
发明内容
[07] 本发明实施例中提供了网页实时通信方法、 系统及终端， 当发生短暂网络中断之 后重新恢复网络连接时， 中断侧的终端能够自动发起恢复建立媒体信道的流程， 实现网 页实时通信的自动重连， 避免影响用户的使用体验。
[08] 为了解决上述技术问题， 本发明实施例公开了如下技术方案：
[09] 一方面， 提供一种网页实时通信方法， 包括：
[010] 第一终端与第二终端进行网页实时通信， 所述第一终端与第二终端各自保存有当 前媒体信道的属性信息；
[011] 当所述第一终端发生网络中断之后， 在预置时间阈值内重新恢复网络连接时， 根 据所述属性信息， 自动发起恢复建立媒体信道的流程； [012] 所述第一终端通过恢复建立的媒体信道， 继续与所述第二终端进行网页实时通 信。
[013] 结合上述一方面， 在第一种可能的实现方式中， 所述恢复建立媒体信道的流程， 包括：
[014] 当所述第一终端上第一网络地址转换 NAT客户端的私有 IP地址和端口未发生变 化时， 所述第一 NAT客户端向所属的第一 NAT服务器发送第一请求消息， 所述第一请求 消息用于请求所述第一 NAT服务器重新建立原媒体信道；
[015] 所述第一 NAT服务器接收所述第一请求消息， 根据原媒体信道的属性信息， 重新 建立原媒体信道。
[016] 结合上述一方面， 和 /或第一种可能的实现方式， 在第二种可能的实现方式中， 所述恢复建立媒体信道的流程， 还包括：
[017] 当 NAT方式为用户数据包协议简单穿越 STUN方式， 且所述第一终端上 STUN客户 端的私有 IP地址和端口发生变化时， STUN客户端向所属的 STUN服务器发送第二请求消 息， 所述第二请求消息中携带所述 STUN客户端的原公网 IP地址和端口信息；
[018] 所述 STUN服务器建立所述 STUN客户端的新 IP地址和端口与所述 STUN客户端的 原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
[019] 结合上述一方面， 和 /或第一种可能的实现方式， 和 /或第二种可能的实现方式， 在第三种可能的实现方式中， 所述恢复建立媒体信道的流程， 还包括：
[020] 当 NAT方式为通过中继穿越网络地址转换 TURN方式， 且所述第一终端上 TURN客 户端的私有 IP地址和端口发生变化时， TURN客户端向所属的 TURN服务器发送第三请求 消息， 所述第三请求消息中携带所述 TURN服务器的原公网 IP地址和端口信息；
[021] 所述 TURN服务器建立所述 TURN客户端的新 IP地址和端口与所述 TURN服务器的 原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
[022] 结合上述一方面， 和 /或第一种可能的实现方式， 和 /或第二种可能的实现方式， 和 /或第三种可能的实现方式， 在第四种可能的实现方式中， 所述恢复建立媒体信道的流 程， 包括：
[023] 当所述第一终端和所属通用即插即用 UPnP网关设备均支持 UPnP协议时， 所述终 端上 NAT客户端向所述 UPnP网关设备发送 UPnP端口映射请求，接收所述 UPnP网关设备 根据所述端口映射请求所分配的端口信息，根据原 IP地址和所分配的端口重新建立之前 的媒体信道。
[024] 另一方面， 提供一种终端， 包括： [025] 网页实时通信模块， 用于与第二终端进行网页实时通信；
[026] 信息保存模块， 用于保存当前媒体信道的属性信息；
[027] 网络中断检测模块， 用于检测网络是否发生中断， 当发生网络中断之后， 在预置 时间阈值内重新恢复网络连接时， 则触发信道恢复发起模块；
[028] 所述信道恢复发起模块， 用于根据所述属性信息， 自动发起恢复建立媒体信道的 流程；
[029] 则所述网页实时通信模块， 还用于通过恢复建立的媒体信道继续与所述第二终端 进行网页实时通信。
[030] 结合上述另一方面， 在第一种可能的实现方式中， 所述信道恢复发起模块， 包括： [031] 第一请求消息发送子模块， 用于当所述终端上 NAT客户端的私有 IP地址和端口 未发生变化时， 所述 NAT客户端向所属的第一 NAT服务器发送第一请求消息， 所述第一 请求消息用于请求所述第一 NAT 服务器根据原媒体信道的属性信息重新建立原媒体信 道。
[032] 结合上述另一方面， 和 /或第一种可能的实现方式， 在第二种可能的实现方式中， 所述信道恢复发起模块， 还包括：
[033] 第二请求消息发送子模块， 用于当 NAT方式为用户数据包协议简单穿越 STUN方 式， 且所述终端上 STUN客户端的私有 IP地址和端口发生变化时， STUN客户端向所属的 STUN服务器发送第二请求消息， 所述第二请求消息中携带所述 STUN客户端的原公网 IP 地址和端口信息； 以便所述 STUN服务器建立所述 STUN客户端的新 IP地址和端口与所述 STUN客户端的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒 体信道。
[034] 结合上述另一方面，和 /或第一种可能的实现方式，和 /或第二种可能的实现方式， 在第三种可能的实现方式中， 所述信道恢复发起模块， 还包括：
[035] 第三请求消息发送子模块， 用于当 NAT 方式为通过中继穿越网络地址转换 TURN 方式， 且所述终端上 TURN客户端的私有 IP地址和端口发生变化时， TURN客户端向所属 的 TURN服务器发送第三请求消息， 所述第三请求消息中携带所述 TURN服务器的原公网 IP地址和端口信息； 以便所述 TURN服务器建立所述 TURN客户端的新 IP地址和端口与 所述 TURN服务器的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新 的媒体信道。
[036] 结合上述另一方面，和 /或第一种可能的实现方式，和 /或第二种可能的实现方式， 和 /或第三种可能的实现方式， 在第四种可能的实现方式中， 所述信道恢复发起模块， 包 括：
[037] 端口分配请求子模块，用于当所述终端和所属 UPnP网关设备均支持 UPnP协议时， 所述终端上 NAT客户端向所述 UPnP网关设备发送 UPnP端口映射请求；
[038] 端口信息接收子模块， 用于接收所述 UPnP 网关设备根据所述端口映射请求所分 配的端口信息；
[039] 信道恢复子模块， 用于所述 NAT客户端根据原 IP地址和所分配的端口重新建立 之前的媒体信道。
[040] 再一方面， 提供一种网页实时通信系统， 包括： 进行网页实时通信的第一终端与 第二终端， 所述第一终端与第二终端各自保存有当前媒体信道的属性信息， 当所述第一 终端发生网络中断之后， 在预置时间阈值内重新恢复网络连接时，
[041] 所述第一终端， 用于根据所述属性信息， 自动发起恢复建立媒体信道的流程， 通 过恢复建立的媒体信道继续与所述第二终端进行网页实时通信。
[042] 结合上述再一方面， 在第一种可能的实现方式中， 所述第一终端具体包括： 第一 NAT客户端， 所述第一 NAT客户端对应第一 NAT服务器；
[043] 所述第一 NAT客户端， 用于当私有 IP地址和端口未发生变化时， 向第一 NAT服 务器发送第一请求消息， 所述第一请求消息用于请求所述第一 NAT服务器重新建立原媒 体信道；
[044] 则所述第一 NAT服务器， 用于接收所述第一请求消息， 根据原媒体信道的属性信 息， 重新建立原媒体信道。
[045] 结合上述再一方面， 和 /或第一种可能的实现方式， 在第二种可能的实现方式中， 当所述第一 NAT客户端为 STUN客户端， 所述第一 NAT服务器为 STUN服务器时，
[046] 所述 STUN客户端， 用于当私有 IP地址和端口发生变化时， 向 STUN服务器发送 第二请求消息， 所述第二请求消息中携带原公网 IP地址和端口信息；
[047] 所述 STUN服务器， 用于建立所述 STUN客户端的新 IP地址和端口与所述 STUN客 户端的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
[048] 结合上述再一方面，和 /或第一种可能的实现方式，和 /或第二种可能的实现方式， 在第三种可能的实现方式中， 当所述第一 NAT客户端为 TURN客户端， 所述第一 NAT服务 器为 TURN服务器时，
[049] 所述 TURN客户端， 用于当私有 IP地址和端口发生变化时， 向 TURN服务器发送 第三请求消息， 所述请求消息中携带所述 TURN服务器的原公网 IP地址和端口信息；
[050] 所述 TURN服务器， 用于建立所述 TURN客户端的新 IP地址和端口与所述 TURN服 务器的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
[051] 结合上述再一方面，和 /或第一种可能的实现方式，和 /或第二种可能的实现方式， 和 /或第三种可能的实现方式，在第四种可能的实现方式中， 当所述第一终端和所属 UPnP 网关设备均支持 UPnP协议时，
[052] 所述终端上 NAT客户端， 用于向所述 UPnP网关设备发送 UPnP端口映射请求， 接 收所述 UPnP网关设备根据所述端口映射请求所分配的端口信息， 根据原 IP地址和所分 配的端口重新建立之前的媒体信道。
[053] 本发明实施例中， 第一终端与第二终端在网页实时通信过程中， 当发生短暂网络 中断之后重新恢复网络连接时， 中断侧的第一终端能够自动发起恢复建立媒体信道的流 程， 以恢复建立媒体信道， 进而通过恢复的媒体信道， 继续与所述第二终端进行网页实 时通信， 从而， 实现双方终端之间网页实时通信的自动重连， 避免通信中断对用户使用 体验带来的影响。
附图说明
[054] 为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施例或现 有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 对于本领域普通技术人员 而言， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
[055] 图 1为本发明一种网页实时通信方法实施例流程图；
[056] 图 2为本发明第一种应用场景中的网页实时通信方法实施例流程图；
[057] 图 3为本发明第二种应用场景中的网页实时通信方法实施例流程图；
[058] 图 4为本发明第三种应用场景中的网页实时通信方法实施例流程图；
[059] 图 5为本发明第四种应用场景中的网页实时通信方法实施例流程图；
[060] 图 6为本发明终端的第一实施例框图；
[061] 图 7为本发明一种信道恢复发起模块的实现框图；
[062] 图 8为本发明又一种信道恢复发起模块的实现框图。 具体实施方式
[063] 为了使本技术领域的人员更好地理解本发明实施例中的技术方案， 并使本发明实 施例的上述目的、 特征和优点能够更加明显易懂， 下面结合附图对本发明实施例中技术 方案作进一步详细的说明。
[064] 参见图 1， 为本发明一种网页实时通信方法实施例流程图。 具体地， 该方法可以 包括以下步骤：
[065] 步骤 101、 第一终端与第二终端进行 NAT ( Network Address Translator, 网页 实时通信）， 所述第一终端与第二终端各自保存有当前媒体信道的属性信息；
[066] 该步骤中， 所述媒体信道的属性信息是指在媒体信道连接正常的情况下， 终端所 记录的当前媒体信道相关的配置信息。
[067] 步骤 102、 当所述第一终端发生网络中断之后， 在预置时间阈值内重新恢复网络 连接时， 根据所述属性信息， 自动发起恢复建立媒体信道的流程；
[068] 该实施例中，恢复建立媒体信道的流程由网络中断侧的终端自动发起，以实现 NAT 的自动重连。
[069] 通常， 终端内部会提供不同的网络接口应用程序， 用于检测网络连接的状态。 该 实施例中， 终端一侧预先设置一时间阈值， 用于记录网络中断后重新恢复网络连接的时 间。 可见， 该实施例实现的是， 当突然出现网络短暂中断时， 终端可以自动发起 NAT重 连， 使得终端用户根本感觉不到通信的中断。 该时间阈值的具体配置值可以根据实际应 用场景进行设定， 此处不做具体限定。
[070] 步骤 103、 所述第一终端通过恢复建立的媒体信道， 继续与所述第二终端进行网 页实时通信。
[071] 本发明实施例中， 第一终端与第二终端在网页实时通信过程中， 当所述第一终端 发生网络中断之后， 在预置时间阈值内重新恢复网络连接时， 中断侧的第一终端能够自 动发起恢复建立媒体信道的流程， 以恢复建立媒体信道， 进而通过恢复的媒体信道， 继 续与所述第二终端进行网页实时通信， 从而， 实现双方终端之间网页实时通信的自动重 连， 避免通信中断对用户使用体验带来的影响。
[072] 现在的终端通信网络， 一般都会存在 NAT转换的问题。 例如， 手机终端一般获得 的 IP地址是运营商的内网地址， 因此， 手机终端不管采用 Wi-Fi接入互联网， 还是通过 3G上网， 都仅仅拥有所在局域网络的私有 IP地址， 而和外网终端通信所需要的是经过 NAT转换获得公有 IP， 存在通信穿越 NAT服务器的问题。
[073] 由此，在本发明的一个实施例中，上述步骤 102中所述恢复建立媒体信道的流程， 具体可以包括以下实现方式：
[074] 当所述第一终端上第一 NAT客户端的私有 IP地址和端口未发生变化时， 所述第 一 NAT客户端向所属的第一 NAT服务器发送第一请求消息， 所述第一请求消息用于请求 所述第一 NAT服务器重新建立原媒体信道；所述第一 NAT服务器接收所述第一请求消息， 根据原媒体信道的属性信息， 重新建立原媒体信道。 [075] 上述实施例中， 所述第一终端上第一 NAT客户端的私有 IP地址和端口未发生变 化， 相关媒体信道的属性信息不会发生变化， 且由于第一 NAT服务器上保存有当前媒体 信道的属性信息， 因此， 可以直接利用该当前媒体信道的属性信息， 向第一 NAT服务器 发送第一请求消息， 以使得第一 NAT服务器根据原媒体信道的属性信息， 重新建立原媒 体信道。
[076] 在第一终端与第二终端进行 NAT通信时， 所述第二终端同时应存储媒体信道的相 关属性信息。 这是由于， 根据该属性信息， 所述第二终端可以获知发起恢复建立媒体信 道的流程的该通信终端为之前通信的第一终端， 因此， 该流程不需要经过所述第二终端 的重新认证， 可以直接进行连接， 进一步缩短了 NAT重连的时间。
[077] STUN ( Session Traversal Uti l ities for NAT , NAT 会话穿越效用） 禾 P TURN ( Traversal Using Relay NAT, 通过中继穿越 NAT ) 是目前 WebRTC通信最常用的两种 NAT穿越方式。 因此， 上述实施例中， NAT服务器可以包括： STUN服务器和 TURN服务器。 下面分别对该两种 NAT穿越方式做简单介绍。
[078] 首先介绍 STUN这种 NAT穿越方式。 以 VoIP ( Voice over Internet Protocol , 网络电话） 为例， 私网中的 VOIP终端预先得到出口 NAT服务器上的对外地址， 然后将净 载中的地址信息直接填写出口 NAT服务器上的对外地址，而不是私网内终端的私有 IP地 址， 这样净载中的内容在经过 NAT服务器时就无需被修改了， 只需按普通 NAT流程转换 报文头的 IP地址即可， 净载中的 IP地址信息和报文头地址信息是一致的。
[079] V0IP终端上的应用程序， 即 STUN客户端 （STUN CLIENT) , 向 STUN服务器 （ STUN SERVER) 通过 UDP发送请求 STUN 消息， STUN SERVER收到请求消息， 产生响应消息， 响 应消息中携带请求消息的源端口， 即 STUN客户端在 NAT服务器上对应的外部端口。 然后 响应消息通过 NAT发送给 STUN 客户端， STUN 客户端通过响应消息体中的内容得知其 NAT 服务器上的外部地址， 并将其填入以后呼叫协议的 UDP 负载中， 告知对端， 本端的 RTP ( Real-time Transport Protocol , 实时传送协议） 接收地址和端口号为 NAT 外部的地 址和端口号。 由于通过 STUN协议已在 NAT上预先建立媒体流的 NAT映射表项， 故媒体流 可顺利穿越 NAT。
[080] TURN方式与 STUN相似， 也是私网中的 V0IP终端通过某种机制预先得到 TURN服 务器 （TURN Server ) 在公网上的服务地址， 然后将报文净载中的地址信息就直接填写该 TURN服务器的公网地址。 TURN通过分配 TURN Server的公网地址和端口作为私网中 V0IP 终端对外的接受地址和端口， 即私网终端发出的报文都要经过 TURN Server进行转发。
[081] 对于 STUN方式， 上述步骤 102 中所述恢复建立媒体信道的流程， 具体还可以包 括以下实现方式：
[082] 当所述第一终端上 STUN客户端的私有 IP地址和端口发生变化时， STUN客户端向 所属的 STUN服务器发送第二请求消息， 所述第二请求消息中携带所述 STUN客户端的原 公网 IP地址和端口信息； 所述 STUN服务器建立所述 STUN客户端的新 IP地址和端口与 所述 STUN客户端的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新 的媒体信道。
[083] 对于 TURN方式， 上述步骤 102 中所述恢复建立媒体信道的流程， 具体还可以包 括以下实现方式：
[084] 当所述第一终端上 TURN客户端的私有 IP地址和端口发生变化时， TURN客户端向 所属的 TURN服务器发送请求第三消息， 所述第三请求消息中携带所述 TURN服务器的原 公网 IP地址和端口信息； 所述 TURN服务器建立所述 TURN客户端的新 IP地址和端口与 所述 TURN服务器的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新 的媒体信道。
[085] 上述两种实现方式中， 当第一终端上第一 NAT客户端的私有 IP地址和端口发生 变化时， 为了能够迅速恢复建立媒体信道， 通过建立第一 NAT客户端的新 IP地址和端口 与原公网 IP地址和端口信息的 NAT映射关系，第一终端仍利用第一 NAT客户端的原公网 IP地址和端口传输媒体流。
[086] 下面通过具体实施方式， 对本发明技术方案进行详细说明。
[087] 假定如下应用场景： 用户 A使用 WebRTC app与用户 B通话， 由于某些原因， A 突然出现网络中断。 如果此次建立通话的过程中， 使用 STUN方式实现 NAT穿越， 且 A终 端的 IP地址和端口未发生改变， 如图 2所示， 包括以下实现步骤：
[088] 步骤 0， A和 B使用 WebRTC App建立实时的音视频通话 （具体应用中， 可以通过 RTCPeerConnection对象来实现），当通话接通时，双方的 NAT客户端（即浏览器 Browser) 都要存储当前媒体信道的属性信息。
[089] 如果此次建立通话的过程中， RTCPeerConnection是使用 STUN方式实现 NAT穿越， 双方客户端存储的信息可以包括：
[090] 事务标识符 （Transaction ID) : 可以是 96bit数字， 用于唯一标识 STUN事务； [091] 映射的 IP地址 /端口号 （Reflexive IP/Port ): 在 STUN客户端向 STUN服务器发 送绑定请求时， 由最外面的 NAT分配给 STUN客户端的公网 IP地址和端口号， 即出口 NAT 上的外部地址；
[092] 目的 IP地址 /端口号 （Destination IP/Port ) : 与之通信的对端设备的 IP地址 和端口号；
[093] 本地描述（Local Descript ion ) :最近设置的本地描述信息和由 ICE ( Interactive Connect ivity Establ i shment , 交互式连接建立） 代理产生的本地候选地址；
[094] 远端描述 （Remote Description ) : 最近设置的远端描述信息， 以及被提供的远 端候选地址。
[095] 步骤 1， A的终端由于偶然原因出现网络中断， 通过现有技术， A的浏览器获知已 失去网络连接， WebRTC 服务器 （WebRTC server ) 获知 A已掉线， B的浏览器不再收到 A 的媒体流， 此时， 双方的浏览器可以通过 RTCPeerConnectionErrorCal lback这一回调函 数告知各自所属的 WebRTC App 当前网络错误类型， BP： 无网络连接。
[096] 步骤 2， 双方 WebRTC App对 "无网络连接"这个出错类型做出响应： 启动计时事 件。
[097] App 开发者可以预先设置一个时间阈值 T， 超出这个时间仍无网络连接时， 由浏 览器告知 App通话中断， 并清除之前存储的媒体信道的属性相关信息。 如果在小于 T的 时间内， 网络重新连接上， 则执行以下步骤。
[098] 步骤 3， A的浏览器向所属 STUN server发送请求消息， 请求恢复与 B的浏览器 之间的媒体信道。
[099] 该请求消息中， 可以携带之前的 Transaction ID， 目的是告知 A的浏览器所属的 STUN server需要保持该会话继续存在。
[0100] 步骤 4， A的浏览器告知所属的 WebRTC App网络已经重新连接， 媒体信道恢复建 立。
[0101] 步骤 5， A所属的 WebRTC App清除计时事件。 B获知 A重新上线之后，所属的 WebRTC App也清除计时事件。
[0102] 步骤 6， A的浏览器重新设置媒体信道的属性信息 Local Description和 Remote Descriptior
[0103] 步骤 7， A仍使用原来的 Reflexive IP/Port向 B传输媒体流， 双方通话恢复。
[0104] 下面第二种应用场景实施例中， 仍使用 STUN方式实现 NAT穿越， 但是， 由于终 端的漫游或 NAT动态分配策略等因素影响， A终端的 IP地址和端口发生了改变， 如图 3 所示， 包括以下实现步骤：
[0105] 步骤 0 : A和 B使用 WebRTC App建立实时的音视频通话， 当通话接通时， 双方的 NAT客户端 （即浏览器 Browser ) 都要存储当前媒体信道的属性信息。
[0106] 所述媒体信道的属性信息可以包括： 事务标识符、 映射的 IP地址 /端口号、 目的 IP地址 /端口号、 本地描述及远端描述等。
[0107] 步骤 1， A的终端由于偶然原因出现网络中断， A的浏览器获知已失去网络连接， WebRTC 服务器 （WebRTC server) 获知 A已掉线， B的浏览器不再收到 A的媒体流， 此 时，双方的浏览器可以通过 RTCPeerConnectionErrorCal lback这一回调函数告知各自所 属的 WebRTC App 当前网络错误类型， 即： 无网络连接。
[0108] 步骤 2， 双方 WebRTC App对 "无网络连接"这个出错类型做出响应： 启动计时事 件。
[0109] 步骤 3， A的浏览器向所属 STUN server发送请求消息， 请求恢复与 B的浏览器 之间的媒体信道。
[0110] 该请求消息中， 携带原 Reflexive IP/Port信息， 该信息可以通过请求消息中增 力卩的 X0R - MAPPED - ADDRESS或 MAPPED - ADDRESS属性来携带。
[0111] 其中， MAPPED-ADDRESS属性表明 cl ient的 reflexive传输地址， 包含 8bit地址 族和 16bit 端口以及固定长度的 IP 地址， 该属性是直接呈现传输地址； 而 X0R-MAPPED-ADDRESS属性表示传输地址的方法是经过 X0R函数处理。
[0112] 步骤 4， A所属的 STUN server向浏览器发送响应信息， 告知 A的浏览器 NAT出 口传输地址信息为原 Reflexive IP/Port信息。
[0113] 该步骤中， STUN server从 X0R-MAPPED-ADDRESS或 MAPPED-ADDRESS属性中提取 Reflexive IP/Port信息， 将其作为 cl ient的 NAT出口传输地址， 返回给 cl ient , 响应 消息中的 X0R-MAPPED-ADDRESS或 MAPPED-ADDRESS属性也设置为该 Reflexive IP/Port。
[0114] 通过上述方式， 令改变之后的私有 IP/Port与原来的 Reflexive IP/Port之间存 在 NAT映射关系， 从而， A可继续使用原来的 Reflexive IP/Port向 B传输媒体流。
[0115] 步骤 5， A所属的 WebRTC App清除计时事件。 B获知 A重新上线之后，所属的 WebRTC App也清除计时事件。
[0116] 步骤 6， A的浏览器重新设置媒体信道的属性信息 Local Description和 Remote Descriptior
[0117] 步骤 7， A仍使用原来的 Reflexive IP/Port向 B传输媒体流， 双方的通话恢复。
[0118] 下面第三种应用场景实施例中， 使用 TURN方式实现 NAT穿越， 且 A终端的 IP地 址和端口未发生改变， 如图 4所示， 包括以下实现步骤：
[0119] 步骤 0: A和 B使用 WebRTC App建立实时的音视频通话 （具体应用中， 可以通过 RTCPeerConnection对象来实现），当通话接通时，双方的 NAT客户端（即浏览器 Browser) 都要存储当前媒体信道的属性信息， 存储的信息可以包括： [0120] 中继的 IP地址 /端口号 （Relayed IP/Port ): TURN服务器 （TURN Server) 控制 分配给 TURN客户端的 TURN服务器的公网地址和端口；
[0121] 映射的 IP地址 /端口号 （Reflexive IP/Port ): 出口 NAT分配给 TURN客户端的 公网 IP地址和端口号；
[0122] 目的 IP地址 /端口号 （Destination IP/Port ) : 与之通信的对端设备的 IP地址 和端口号；
[0123] 本地描述 （Local Description): 最近设置的本地描述信息和由 ICE代理产生的 本地候选地址；
[0124] 远端描述 （Remote Description ) : 最近设置的远端描述信息， 以及被提供的远 端候选地址。
[0125] 步骤 1， A的终端由于偶然原因出现网络中断， 通过现有技术， A的浏览器获知已 失去网络连接， WebRTC 服务器 （WebRTC server) 获知 A已掉线， B的浏览器不再收到 A 的媒体流， 此时， 双方的浏览器可以通过 RTCPeerConnectionErrorCal lback这一回调函 数告知各自所属的 WebRTC App 当前网络错误类型， BP： 无网络连接。
[0126] 步骤 2， 双方 WebRTC App对 "无网络连接"这个出错类型做出响应： 启动计时事 件。
[0127] 步骤 3， A的浏览器向 TURN server发送请求消息， 请求恢复与 B的浏览器之间 的媒体信道。
[0128] 步骤 4， A的浏览器告知所属的 WebRTC App网络已经重新连接， 媒体信道恢复建 立。
[0129] 步骤 5， A所属的 WebRTC App清除计时事件。 B获知 A重新上线之后，所属的 WebRTC App也清除计时事件。
[0130] 步骤 6， A的浏览器重新设置媒体信道的属性信息 Local Description和 Remote Descriptior
[0131] 步骤 7: A 的浏览器仍使用之前的 Reflexive IP/Port 将媒体流数据发给 TURN server
[0132] 步骤 8: TURN server仍使用之前的 Relayed IP/Port将媒体流数据转发给 B， 双 方通话恢复。
[0133] 下面第四种应用场景实施例中， 仍使用 TURN方式实现 NAT穿越， 但是， 由于终 端的漫游或 NAT动态分配策略等因素影响， A终端的 IP地址和端口发生改变， 如图 5所 示， 包括以下实现步骤： [0134] 步骤 0: A和 B使用 WebRTC App建立实时的音视频通话 （具体应用中， 可以通过 RTCPeerConnection对象来实现），当通话接通时，双方的 NAT客户端（即浏览器 Browser) 都要存储当前媒体信道的属性信息， 存储的信息可以包括： 中继的 IP地址 /端口号、 映 射的 IP地址 /端口号、 目的 IP地址 /端口号、 本地描述及远端描述。
[0135] 步骤 1， A的终端由于偶然原因出现网络中断， 通过现有技术， A的浏览器获知已 失去网络连接， WebRTC 服务器 （WebRTC server) 获知 A已掉线， B的浏览器不再收到 A 的媒体流， 此时， 双方的浏览器可以通过 RTCPeerConnectionErrorCal lback这一回调函 数告知各自所属的 WebRTC App 当前网络错误类型， BP： 无网络连接。
[0136] 步骤 2， 双方 WebRTC App对 "无网络连接"这个出错类型做出响应： 启动计时事 件。
[0137] 步骤 3， A的浏览器向 TURN server发送请求消息， 请求恢复与 B的浏览器之间 的媒体信道。
[0138] 该步骤中， 请求消息携带原 Relayed IP/Port信息， 便于所属的 TURN server建 立新的 IP地址和端口与该原 Relayed IP/Port信息之间的 NAT映射关系。
[0139] 步骤 4， A所属的 TURN server建立新的 IP地址和端口与该原 Relayed IP/Port 信息之间的 NAT映射关系；
[0140] 步骤 5， A所属的 TURN server向浏览器发送响应信息， 反馈该 NAT映射关系； [0141] 步骤 6， A的浏览器告知所属的 WebRTC App网络已经重新连接， 媒体信道恢复建 [0142] 步骤 7， A所属的 WebRTC App清除计时事件。 B获知 A重新上线之后，所属的 WebRTC App也清除计时事件。
[0143] 步骤 8， A的浏览器重新设置媒体信道的属性信息 Local Description和 Remote Descriptior
[0144] 步骤 9， A 的浏览器仍使用之前的 Reflexive IP/Port 将媒体流数据发给 TURN server。
[0145] 步骤 10， TURN server仍使用之前的 Relayed IP/Port将媒体流数据转发给 B， 双方通话恢复。
[0146] 此外，需要说明的是，第五种应用场景中，当所述第一终端和所属 UPnP( Universal Plug and Play, 通用即插即用） 网关设备均支持 UPnP协议时， 所述终端上 NAT客户端 向所述 UPnP网关设备发送 UPnP端口映射请求，接收所述 UPnP网关设备根据所述端口映 射请求所分配的端口信息， 根据原 IP地址和所分配的端口重新建立之前的媒体信道。 [0147] 该实现方式下， 当网络出现短暂中断又重连之后， 通话双方所使用的 IP 地址和 端口信息不变， 因此， 可以根据原 IP地址和所分配的端口重新建立之前的媒体信道。
[0148] 与本发明的方法实施例相对应， 本发明还提供了一种终端。
[0149] 参见图 6， 为本发明终端的第一实施例框图， 该终端可以包括：
[0150] 网页实时通信模块 601， 用于与第二终端进行网页实时通信；
[0151] 信息保存模块 602， 用于保存当前媒体信道的属性信息；
[0152] 网络中断检测模块 603， 用于检测网络是否发生中断， 当发生网络中断之后， 在 预置时间阈值内重新恢复网络连接时， 则触发信道恢复发起模块 604 ;
[0153] 所述信道恢复发起模块 604， 用于在预置时间阈值内， 根据所述属性信息， 自动 发起恢复建立媒体信道的流程；
[0154] 则所述网页实时通信模块 601， 还用于通过恢复建立的媒体信道继续与所述第二 终端进行网页实时通信。
[0155] 由上述实施例可见， 终端与对端终端在网页实时通信过程中， 当发生短暂网络中 断之后重新恢复网络连接时， 中断侧的终端能够自动发起恢复建立媒体信道的流程， 以 恢复建立媒体信道， 进而通过恢复的媒体信道， 继续与对端第二终端进行网页实时通信， 从而， 实现双方终端之间网页实时通信的自动重连， 避免通信中断对用户使用体验带来 的影响。
[0156] 具体实施时， 如图 7所示， 所述信道恢复发起模块 604， 可以包括：
[0157] 第一请求消息发送子模块 701，用于当所述终端上 NAT客户端的私有 IP地址和端 口未发生变化时， 所述 NAT客户端向所属的 NAT服务器发送第一请求消息， 所述第一请 求消息用于请求所述第一 NAT服务器根据原媒体信道的属性信息重新建立原媒体信道。
[0158] 上述第一请求消息发送子模块适用于 STUN和 TURN方式实现 NAT穿越。
[0159] 所述信道恢复发起模块 604， 还可以包括：
[0160] 第二请求消息发送子模块 702， 用于当 NAT方式为用户数据包协议简单穿越 STUN 方式， 且所述终端上 STUN客户端的私有 IP地址和端口发生变化时， STUN客户端向所属 的 STUN服务器发送第二请求消息， 所述第二请求消息中携带所述 STUN客户端的原公网 IP地址和端口信息； 以便所述 STUN服务器建立所述 STUN客户端的新 IP地址和端口与 所述 STUN客户端的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新 的媒体信道。
[0161] 所述信道恢复发起模块 604， 还可以包括：
[0162] 第三请求消息发送子模块 703， 用于当 NAT 方式为通过中继穿越网络地址转换 TURN方式， 且所述终端上 TURN客户端的私有 IP地址和端口发生变化时， TURN客户端向 所属的 TURN服务器发送第三请求消息， 所述第三请求消息中携带所述 TURN服务器的原 公网 IP地址和端口信息； 以便所述 TURN服务器建立所述 TURN客户端的新 IP地址和端 口与所述 TURN服务器的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建 立新的媒体信道。
[0163] 通过上述第二和第三请求消息发送子模块， 当第一终端上第一 NAT客户端的私有 IP地址和端口发生变化时， 为了能够迅速恢复建立媒体信道， 通过建立第一 NAT客户端 的新 IP地址和端口与原公网 IP地址和端口信息的 NAT映射关系， 第一终端仍利用第一 NAT客户端的原公网 IP地址和端口传输媒体流。
[0164] 本发明还提供了又一种信道恢复发起模块的实现方式， 如图 8所示， 所述信道恢 复发起模块， 可以包括：
[0165] 端口分配请求子模块 801， 用于当所述终端和所属 UPnP网关设备均支持 UPnP协 议时， 所述终端上 NAT客户端向所述 UPnP网关设备发送 UPnP端口映射请求；
[0166] 端口信息接收子模块 802，用于接收所述 UPnP网关设备根据所述端口映射请求所 分配的端口信息；
[0167] 信道恢复子模块 803，用于所述 NAT客户端根据原 IP地址和所分配的端口重新建 立之前的媒体信道。
[0168] 该实施例中， 当网络出现短暂中断又重连之后， 通话两侧的终端所使用的 IP 地 址和端口信息不变，因此，可以根据原 IP地址和所分配的端口重新建立之前的媒体信道。
[0169] 对应前述实施例， 本发明还提供了一种网页实时通信系统， 该系统包括： 进行网 页实时通信的第一终端与第二终端， 所述第一终端与第二终端各自保存有当前媒体信道 的属性信息， 其中， 当所述第一终端发生网络中断之后， 在预置时间阈值内重新恢复网 络连接时， 所述第一终端， 用于在预置时间阈值内， 根据所述属性信息， 自动发起恢复 建立媒体信道的流程，通过恢复建立的媒体信道继续与所述第二终端进行网页实时通信。
[0170] 所述第一终端， 具体包括： 第一 NAT客户端， 所述第一 NAT客户端对应第一 NAT 服务器；
[0171] 所述第一 NAT客户端， 用于当私有 IP地址和端口未发生变化时， 向第一 NAT服 务器发送第一请求消息， 所述第一请求消息用于请求所述第一 NAT服务器重新建立原媒 体信道；
[0172] 则所述第一 NAT服务器， 用于接收所述第一请求消息， 根据原媒体信道的属性信 息， 重新建立原媒体信道。 [0173] 当所述第一 NAT客户端为 STUN客户端， 所述第一 NAT服务器为 STUN服务器时， [0174] 所述 STUN客户端， 用于当私有 IP地址和端口发生变化时， 向 STUN服务器发送 第二请求消息， 所述第二请求消息中携带原公网 IP地址和端口信息；
[0175] 所述 STUN服务器， 用于建立所述 STUN客户端的新 IP地址和端口与所述 STUN客 户端的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
[0176] 当所述第一 NAT客户端为 TURN客户端， 所述第一 NAT服务器为 TURN服务器时， [0177] 所述 TURN客户端， 用于当私有 IP地址和端口发生变化时， 向 TURN服务器发送 第三请求消息， 所述请求消息中携带所述 TURN服务器的原公网 IP地址和端口信息； [0178] 所述 TURN服务器， 用于建立所述 TURN客户端的新 IP地址和端口与所述 TURN服 务器的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
[0179] 此外，当所述第一终端和所属 UPnP网关设备均支持 UPnP协议时，所述终端上 NAT 客户端， 用于向所述 UPnP网关设备发送 UPnP端口映射请求， 接收所述 UPnP网关设备根 据所述端口映射请求所分配的端口信息，根据原 IP地址和所分配的端口重新建立之前的 媒体信道。
[0180] 本领域普通技术人员可以意识到， 结合本文中所公开的实施例描述的各示例的单 元及算法步骤， 能够以电子硬件、 或者计算机软件和电子硬件的结合来实现。 这些功能 究竟以硬件还是软件方式来执行， 取决于技术方案的特定应用和设计约束条件。 专业技 术人员可以对每个特定的应用来使用不同方法来实现所描述的功能， 但是这种实现不应 认为超出本发明的范围。
[0181] 所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、 装置和单元的具体工作过程， 可以参考前述方法实施例中的对应过程， 在此不再赘述。
[0182] 在本申请所提供的几个实施例中， 应该理解到， 所揭露的系统、 装置和方法， 可 以通过其它的方式实现。 例如， 以上所描述的装置实施例仅仅是示意性的， 例如， 所述 单元的划分， 仅仅为一种逻辑功能划分， 实际实现时可以有另外的划分方式， 例如多个 单元或组件可以结合或者可以集成到另一个系统， 或一些特征可以忽略， 或不执行。 另 一点， 所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口， 装 置或单元的间接耦合或通信连接， 可以是电性， 机械或其它的形式。
[0183] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的， 作为单元显 示的部件可以是或者也可以不是物理单元， 即可以位于一个地方， 或者也可以分布到多 个网络单元上。 可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案 的目的。 [0184] 另外， 在本发明各个实施例中的各功能单元可以集成在一个处理单元中， 也可以 是各个单元单独物理存在， 也可以两个或两个以上单元集成在一个单元中。
[0185] 所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时， 可以 存储在一个计算机可读取存储介质中。 基于这样的理解， 本发明的技术方案本质上或者 说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来， 该计算机软件产品存储在一个存储介质中， 包括若干指令用以使得一台计算机设备 （可 以是个人计算机， 服务器， 或者网络设备等） 或处理器 （processor ) 执行本发明各个实 施例所述方法的全部或部分步骤。 而前述的存储介质包括： U 盘、 移动硬盘、 只读存储 器 ( ROM, Read-Only Memory )、 随机存取存储器 ( RAM, Random Access Memory )、 磁碟 或者光盘等各种可以存储程序代码的介质。
[0186] 以上所述， 仅为本发明的具体实施方式， 但本发明的保护范围并不局限于此， 任 何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻易想到变化或替换， 都 应涵盖在本发明的保护范围之内。 因此， 本发明的保护范围应所述以权利要求的保护范 围为准。

Claims

权利 要 求
1、 一种网页实时通信方法， 其特征在于， 包括：
第一终端与第二终端进行网页实时通信， 所述第一终端与第二终端各自保存有当前 媒体信道的属性信息；
当所述第一终端发生网络中断之后， 在预置时间阈值内重新恢复网络连接时， 根据 所述属性信息， 自动发起恢复建立媒体信道的流程；
所述第一终端通过恢复建立的媒体信道， 继续与所述第二终端进行网页实时通信。
2、 根据权利要求 1所述的方法， 其特征在于， 所述恢复建立媒体信道的流程， 包括： 当所述第一终端上第一网络地址转换 NAT客户端的私有 IP地址和端口未发生变化 时， 所述第一 NAT客户端向所属的第一 NAT服务器发送第一请求消息， 所述第一请求消 息用于请求所述第一 NAT服务器重新建立原媒体信道；
所述第一 NAT服务器接收所述第一请求消息， 根据原媒体信道的属性信息， 重新建 立原媒体信道。
3、 根据权利要求 2所述的方法， 其特征在于， 所述恢复建立媒体信道的流程， 还包 括：
当 NAT方式为用户数据包协议简单穿越 STUN方式， 且所述第一终端上 STUN客户端 的私有 IP地址和端口发生变化时， STUN客户端向所属的 STUN服务器发送第二请求消息， 所述第二请求消息中携带所述 STUN客户端的原公网 IP地址和端口信息；
所述 STUN服务器建立所述 STUN客户端的新 IP地址和端口与所述 STUN客户端的原 公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
4、 根据权利要求 3所述的方法， 其特征在于， 所述恢复建立媒体信道的流程， 还包 括：
当 NAT方式为通过中继穿越网络地址转换 TURN方式， 且所述第一终端上 TURN客户 端的私有 IP地址和端口发生变化时， TURN客户端向所属的 TURN服务器发送第三请求消 息， 所述第三请求消息中携带所述 TURN服务器的原公网 IP地址和端口信息；
所述 TURN服务器建立所述 TURN客户端的新 IP地址和端口与所述 TURN服务器的原 公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
5、 根据权利要求 1所述的方法， 其特征在于， 所述恢复建立媒体信道的流程， 包括: 当所述第一终端和所属通用即插即用 UPnP网关设备均支持 UPnP协议时， 所述终端 上 NAT客户端向所述 UPnP网关设备发送 UPnP端口映射请求，接收所述 UPnP网关设备根 据所述端口映射请求所分配的端口信息，根据原 IP地址和所分配的端口重新建立之前的 媒体信道。
6、 一种终端， 其特征在于， 包括：
网页实时通信模块， 用于与第二终端进行网页实时通信；
信息保存模块， 用于保存当前媒体信道的属性信息；
网络中断检测模块， 用于检测网络是否发生中断， 当发生网络中断之后， 在预置时 间阈值内重新恢复网络连接时， 则触发信道恢复发起模块；
所述信道恢复发起模块， 用于根据所述属性信息， 自动发起恢复建立媒体信道的流 程；
则所述网页实时通信模块， 还用于通过恢复建立的媒体信道继续与所述第二终端进行 网页实时通信。
7、 根据权利要求 6所述的终端， 其特征在于， 所述信道恢复发起模块， 包括： 第一请求消息发送子模块， 用于当所述终端上 NAT客户端的私有 IP地址和端口未 发生变化时， 所述 NAT客户端向所属的第一 NAT服务器发送第一请求消息， 所述第一请 求消息用于请求所述第一 NAT服务器根据原媒体信道的属性信息重新建立原媒体信道。
8、 根据权利要求 7所述的终端， 其特征在于， 所述信道恢复发起模块， 还包括： 第二请求消息发送子模块， 用于当 NAT方式为用户数据包协议简单穿越 STUN方式， 且所述终端上 STUN客户端的私有 IP地址和端口发生变化时， STUN客户端向所属的 STUN 服务器发送第二请求消息， 所述第二请求消息中携带所述 STUN客户端的原公网 IP地址 和端口信息；以便所述 STUN服务器建立所述 STUN客户端的新 IP地址和端口与所述 STUN 客户端的原公网 IP地址和端口信息的映射关系，根据所述映射关系，建立新的媒体信道。
9、 根据权利要求 7所述的终端， 其特征在于， 所述信道恢复发起模块， 还包括： 第三请求消息发送子模块， 用于当 NAT方式为通过中继穿越网络地址转换 TURN方 式， 且所述终端上 TURN客户端的私有 IP地址和端口发生变化时， TURN客户端向所属的 TURN服务器发送第三请求消息， 所述第三请求消息中携带所述 TURN服务器的原公网 IP 地址和端口信息； 以便所述 TURN服务器建立所述 TURN客户端的新 IP地址和端口与所述 TURN服务器的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒 体信道。
10、 根据权利要求 6所述的终端， 其特征在于， 所述信道恢复发起模块， 包括： 端口分配请求子模块， 用于当所述终端和所属 UPnP网关设备均支持 UPnP协议时， 所述终端上 NAT客户端向所述 UPnP网关设备发送 UPnP端口映射请求；
端口信息接收子模块， 用于接收所述 UPnP 网关设备根据所述端口映射请求所分配 的端口信息；
信道恢复子模块， 用于所述 NAT客户端根据原 IP地址和所分配的端口重新建立之 前的媒体信道。
11、 一种网页实时通信系统， 其特征在于， 包括： 进行网页实时通信的第一终端与 第二终端， 所述第一终端与第二终端各自保存有当前媒体信道的属性信息， 当所述第一 终端发生网络中断之后， 在预置时间阈值内重新恢复网络连接时，
所述第一终端， 用于根据所述属性信息， 自动发起恢复建立媒体信道的流程， 通过 恢复建立的媒体信道继续与所述第二终端进行网页实时通信。
12、 根据权利要求 11所述的系统， 其特征在于， 所述第一终端具体包括： 第一 NAT 客户端， 所述第一 NAT客户端对应第一 NAT服务器；
所述第一 NAT客户端， 用于当私有 IP地址和端口未发生变化时， 向第一 NAT服务 器发送第一请求消息， 所述第一请求消息用于请求所述第一 NAT服务器重新建立原媒体 信道；
则所述第一 NAT服务器，用于接收所述第一请求消息，根据原媒体信道的属性信息， 重新建立原媒体信道。
13、 根据权利要求 12所述的系统， 其特征在于， 当所述第一 NAT客户端为 STUN客 户端， 所述第一 NAT服务器为 STUN服务器时，
所述 STUN客户端， 用于当私有 IP地址和端口发生变化时， 向 STUN服务器发送第 二请求消息， 所述第二请求消息中携带原公网 IP地址和端口信息；
所述 STUN服务器， 用于建立所述 STUN客户端的新 IP地址和端口与所述 STUN客户 端的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
14、 根据权利要求 12所述的系统， 其特征在于， 当所述第一 NAT客户端为 TURN客 户端， 所述第一 NAT服务器为 TURN服务器时，
所述 TURN客户端， 用于当私有 IP地址和端口发生变化时， 向 TURN服务器发送第 三请求消息， 所述请求消息中携带所述 TURN服务器的原公网 IP地址和端口信息；
所述 TURN服务器， 用于建立所述 TURN客户端的新 IP地址和端口与所述 TURN服务 器的原公网 IP地址和端口信息的映射关系， 根据所述映射关系， 建立新的媒体信道。
15、 根据权利要求 11所述的系统， 其特征在于， 当所述第一终端和所属 UPnP网关 设备均支持 UPnP协议时，
所述终端上 NAT客户端， 用于向所述 UPnP网关设备发送 UPnP端口映射请求， 接收 所述 UPnP网关设备根据所述端口映射请求所分配的端口信息， 根据原 IP地址和所分配 的端口重新建立之前的媒体信道。
PCT/CN2014/075902 2013-05-21 2014-04-22 一种网页实时通信方法、系统及终端 Ceased WO2014187214A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP14801045.7A EP2905944A4 (en) 2013-05-21 2014-04-22 REAL-TIME COMMUNICATION METHOD AND SYSTEM FOR WEBSITES AND TERMINALS
US14/755,236 US20150304364A1 (en) 2013-05-21 2015-06-30 Method, System, and Terminal for Web Real-Time Communication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310189867.1A CN104184755A (zh) 2013-05-21 2013-05-21 一种网页实时通信方法、系统及终端
CN201310189867.1 2013-05-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/755,236 Continuation US20150304364A1 (en) 2013-05-21 2015-06-30 Method, System, and Terminal for Web Real-Time Communication

Publications (1)

Publication Number Publication Date
WO2014187214A1 true WO2014187214A1 (zh) 2014-11-27

Family

ID=51932806

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/075902 Ceased WO2014187214A1 (zh) 2013-05-21 2014-04-22 一种网页实时通信方法、系统及终端

Country Status (4)

Country Link
US (1) US20150304364A1 (zh)
EP (1) EP2905944A4 (zh)
CN (1) CN104184755A (zh)
WO (1) WO2014187214A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112954823A (zh) * 2021-01-29 2021-06-11 Oppo广东移动通信有限公司 重建数据连接的方法、终端设备及存储介质

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3004047A1 (fr) * 2013-03-29 2014-10-03 France Telecom Technique de cooperation entre une pluralite d'entites clientes
US9282125B2 (en) 2013-07-30 2016-03-08 Unify Gmbh & Co. Kg Apparatus and method for communications involving a legacy device
US10263952B2 (en) 2013-10-31 2019-04-16 Avaya Inc. Providing origin insight for web applications via session traversal utilities for network address translation (STUN) messages, and related methods, systems, and computer-readable media
JP6415105B2 (ja) * 2014-05-16 2018-10-31 キヤノン株式会社 通信装置、制御方法およびプログラム
US20160191461A1 (en) * 2014-12-31 2016-06-30 Futurewei Technologies, Inc. TURN Relay Service Reuse For NAT Traversal During Media Session Resumption
CN106303702A (zh) * 2015-06-11 2017-01-04 阿里巴巴集团控股有限公司 连接状态检测方法、装置和智能电视系统
EP3379889B1 (en) * 2016-01-28 2019-11-27 Huawei Technologies Co., Ltd. Method and terminal for controlling service connection
US10033866B2 (en) 2016-02-19 2018-07-24 At&T Intellectual Property I, L.P. Facilitation of an internet protocol multimedia platform
CN106453567A (zh) * 2016-10-18 2017-02-22 合肥浮点信息科技有限公司 一种通信网络防中断保存处理系统
CN108259448B (zh) * 2016-12-30 2020-12-15 广州华多网络科技有限公司 一种防止连麦时异常断线的方法及装置
CN111083295B (zh) * 2019-12-31 2024-08-16 北京讯鸟软件有限公司 基于浏览器的电话通信方法和设备
CN112218388A (zh) * 2020-09-15 2021-01-12 贵阳朗玛信息技术股份有限公司 一种断网重连的方法及装置
CN112804213B (zh) * 2020-12-31 2023-05-12 Oppo广东移动通信有限公司 通信断线重连方法及装置、系统、可读介质和电子设备
CN114268599A (zh) * 2021-12-21 2022-04-01 北京青云科技股份有限公司 即时通信连接的建立与即时通信方法、装置、设备及介质
CN114598572A (zh) * 2022-03-28 2022-06-07 洛阳萃泽信息科技有限公司 一种用于机床联网的方法及工业网关
CN114710461B (zh) * 2022-03-31 2024-03-12 中煤科工集团重庆智慧城市科技研究院有限公司 多端音视频即时通讯方法及系统
CN114666317B (zh) * 2022-04-14 2023-07-18 广州公评科技有限公司 一种基于网页即时通信技术的外呼系统
US11979616B1 (en) 2023-01-27 2024-05-07 SimpliSafe, Inc. Managing remote access to image capture devices
US11908196B1 (en) 2023-01-30 2024-02-20 SimpliSafe, Inc. Security event processing
US11750514B1 (en) * 2023-02-24 2023-09-05 SimpliSafe, Inc. Connectivity candidate filtering
CN117411860B (zh) * 2023-10-31 2024-06-21 慧之安信息技术股份有限公司 基于WebRTC的可切换中继转发控制方法和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1501726A (zh) * 2002-11-18 2004-06-02 Lg电子株式会社 移动通信系统交换状态信息及其操作方法
CN1507176A (zh) * 2002-10-01 2004-06-23 ���ܿ���ϵͳ���޹�˾ 无线点到多点系统
CN102131152A (zh) * 2010-01-15 2011-07-20 中兴通讯股份有限公司 一种维持即时消息业务连续性的方法及系统

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010040887A1 (en) * 1997-10-09 2001-11-15 Yuri Shtivelman Apparatus and methods enhancing call routing to and within call-centers
US7647614B2 (en) * 2004-06-07 2010-01-12 Sling Media, Inc. Fast-start streaming and buffering of streaming content for personal media player
US8437307B2 (en) * 2007-09-03 2013-05-07 Damaka, Inc. Device and method for maintaining a communication session during a network transition
JP4266188B2 (ja) * 2004-06-30 2009-05-20 株式会社東芝 通信システム及びこの通信システムで使用される通信端末装置、及び通信システムで使用される通信方法
US8014915B2 (en) * 2006-06-21 2011-09-06 Sungkyunkwan University Foundation For Corporate Collaboration Vehicle management system and method using ECU
CN100502572C (zh) * 2006-11-30 2009-06-17 华为技术有限公司 增大多媒体消息业务系统容量的方法及系统
US8656017B2 (en) * 2007-05-16 2014-02-18 Microsoft Corporation Peer-to-peer collaboration system with edge routing
CN101557388B (zh) * 2008-04-11 2012-05-23 中国科学院声学研究所 一种基于UPnP和STUN技术相结合的NAT穿越方法
US8457557B2 (en) * 2009-04-24 2013-06-04 Skullcandy, Inc. Wireless synchronization mechanism
EP2486527A1 (en) * 2009-10-06 2012-08-15 Telefonaktiebolaget LM Ericsson (publ) User interest and identity control on internet
US8352563B2 (en) * 2010-04-29 2013-01-08 Damaka, Inc. System and method for peer-to-peer media routing using a third party instant messaging system for signaling
US9049122B2 (en) * 2012-09-11 2015-06-02 Cisco Technology, Inc. Bandwidth probing messages

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1507176A (zh) * 2002-10-01 2004-06-23 ���ܿ���ϵͳ���޹�˾ 无线点到多点系统
CN1501726A (zh) * 2002-11-18 2004-06-02 Lg电子株式会社 移动通信系统交换状态信息及其操作方法
CN102131152A (zh) * 2010-01-15 2011-07-20 中兴通讯股份有限公司 一种维持即时消息业务连续性的方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2905944A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112954823A (zh) * 2021-01-29 2021-06-11 Oppo广东移动通信有限公司 重建数据连接的方法、终端设备及存储介质
CN112954823B (zh) * 2021-01-29 2023-06-27 Oppo广东移动通信有限公司 重建数据连接的方法、终端设备及存储介质

Also Published As

Publication number Publication date
US20150304364A1 (en) 2015-10-22
CN104184755A (zh) 2014-12-03
EP2905944A1 (en) 2015-08-12
EP2905944A4 (en) 2016-06-15

Similar Documents

Publication Publication Date Title
WO2014187214A1 (zh) 一种网页实时通信方法、系统及终端
US11019117B2 (en) Conferencing server
CN111740990B (zh) 用于拦截和解密指纹保护的媒体流量的方法和系统
US10230771B2 (en) Media session
CN103188300B (zh) 云计算环境中实现voip通话的方法、装置和系统
US9497411B2 (en) Establishing a connection for a video call
US20160380966A1 (en) Media Relay Server
US20150229490A1 (en) Communication system for transmittingunder a tunnel protocol between at least two data computers via a wide area network and a method for running such a communication system
CN103718532A (zh) 一种数据传输方法、装置及终端设备
CA2793924C (en) System and method for peer-to-peer media routing using a third party instant messaging system for signaling
CN101895569B (zh) 视频浏览的实现方法、ims视频监控系统及监控前端
JPWO2006051594A1 (ja) 通信ネットワークにおけるｉｐパケット中継方法およびゲートウエイ装置
US20160380789A1 (en) Media Relay Server
WO2011100742A2 (en) System and method for signaling and data tunneling in a peer-to-peer environment
JP5707460B2 (ja) Ｉｐ間のハンドオーバーの方法
CN104660550B (zh) 一种在多服务器之间进行会话迁移的方法
CN102780675B (zh) 流媒体业务的传输方法、装置和系统
WO2015192682A1 (zh) 一种通信方法以及终端
US8233400B2 (en) Methods, systems, and computer readable media for verifying the availability of an internet protocol (IP) media router during a call setup
CN105978780B (zh) 一种端口切换方法及装置
CN102291415B (zh) 媒体流处理方法、系统及家庭网关
CN112653661B (zh) 一种VoIP网络限制下的媒体恢复方法和系统
CN105519049B (zh) 一种报文传输方法、装置及系统
CN110784943A (zh) 一种VoWiFi语音业务断网重连的处理方法和装置
CN104255014A (zh) 设置、处理交互式连接建立ice地址的方法、装置和服务器

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: 14801045

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2014801045

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE