US7885278B2 - Method and system for connecting a media stream, and method and system for detecting a connectivity - Google Patents

Method and system for connecting a media stream, and method and system for detecting a connectivity Download PDF

Info

Publication number
US7885278B2
US7885278B2 US12/362,270 US36227009A US7885278B2 US 7885278 B2 US7885278 B2 US 7885278B2 US 36227009 A US36227009 A US 36227009A US 7885278 B2 US7885278 B2 US 7885278B2
Authority
US
United States
Prior art keywords
address
message
media
network
connecting message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US12/362,270
Other languages
English (en)
Other versions
US20090135842A1 (en
Inventor
Ning Zhu
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 Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Assigned to HUAWEI TECHNOLOGIES CO., LTD. reassignment HUAWEI TECHNOLOGIES CO., LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ZHU, NING
Publication of US20090135842A1 publication Critical patent/US20090135842A1/en
Application granted granted Critical
Publication of US7885278B2 publication Critical patent/US7885278B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • 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
    • 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/2517—Translation of Internet protocol [IP] addresses using port numbers
    • 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/255—Maintenance or indexing of mapping tables
    • H04L61/2553—Binding renewal aspects, e.g. using keep-alive messages
    • 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/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42017—Customized ring-back tones

Definitions

  • the present invention relates to the field of communication technologies, and in particular to a method and system for connecting a media stream, and a method and system for detecting connectivity.
  • the Next Generation Network indicates the coming of the age of new generation telecommunication networks.
  • the NGN emerges from the integration of a Time Division Multiplex (TDM) based Public Switched Telephone Network (PSTN) voice network and an Internet Protocol/Asynchronous Transfer Mode (IP/ATM) based packet network, and makes it possible to implement integrated services of audio, video, data and the like over the new generation network.
  • TDM Time Division Multiplex
  • PSTN Public Switched Telephone Network
  • IP/ATM Internet Protocol/Asynchronous Transfer Mode
  • a schematic structural diagram of the existing NGN network is as illustrated in FIG. 1 .
  • a Media Gateway (MG) is used to convert a media stream in a certain type of network to a format required in another type of network. For example, an E 1 timeslot in a circuit switched network is converted to a Real-time Transport Protocol (RTP) media stream in an IP network.
  • RTP Real-time Transport Protocol
  • a Media Gateway Controller (MGC) is used to manage call status and to control bearer resources of the media gateway.
  • a control signal is transmitted between the MGC and the MG, so that the MG can implement establishment, modification and release of a specific media stream, as well as resource management.
  • the same problem may also arise in a situation where only one of two ends of a media stream is a media gateway and another end is a Session Initiation Protocol (SIP) terminal or an H.323 terminal, is in a Circuit Switched (CS) domain or in a packet network and the like.
  • SIP Session Initiation Protocol
  • H.323 H.323 terminal
  • NA(P)T Network Address Translation
  • NAT Network Address Translation
  • NAPT Network Address Port Translation
  • NAT Network Address Translation
  • a local media address of a machine A in the private network is 192.168.0.1
  • an address of an NAT server is 210.21.12.140
  • a local media address of a machine B in the public network is 210.15.27.166
  • a local media address of a machine C in the public network is 210.15.27.140.
  • C cannot communicate with A because A has never communicated with C, and the NAT rejects any action of C of attempting to connect to A.
  • B can communicate with 192.168.0.4:5000 of A via 210.21.12.140:8000, and here B can communicate with A via any port. For example, 210.15.27.166:2001->210.21.12.140:8000, and the NAT will transmit it to the port 5000 of A.
  • Port Restricted Cone NAT For the type of Port Restricted Cone NAT, C cannot communicate with A because A has never communicated with C. Moreover, B can only communicate with 192.168.0.4:5000 of A via its 210.15.27.166:2000 because A has never communicated with other ports of B. This type of NAT is port-restricted.
  • Cone NAT translates all packets coming from the same internal address and port to the same external address and port.
  • Symmetric is slightly different. Specifically, the NAT translates packets coming from the same internal address and port and going to the same external destination address and port to the same external address and port.
  • the NAT translates packets coming from the same address and port and going to a different external destination address and port to a different address and port.
  • a packet can be transmitted only from an external address which has received a packet transmitted by an internal address to the internal address via an NAT mapped address.
  • Symmetric NAT will be described by way of another example. It is assumed that the machine A has connected to the machine B, and it is assumed that the connection is represented by A (192.168.0.4:5000)->NAT (translated to 210.21.12.140:8000)->B (210.15.27.166:2000). At this time, if the machine A (192.168.0.4:5000) also wants to connect to the machine C (210.15.27.140:2000), a new mapping is generated in the NAT with a corresponding translation possibly of A (192.168.0.4:5000)->NAT (translated to 210.21.12.140:8001)->C (210.15.27.140:2000).
  • B can communicate with 192.168.0.4:5000 of A only via 210.15.27.166:2000 of B through 210.21.12.140:8000 of the NAT
  • C can communicate with 192.168.0.4:5000 of A only via 210.15.27.140:2000 of C through 210.21.12.140:8001 of the NAT
  • other ports of B or C cannot communication with 192.168.0.4:5000 of A.
  • the NAT traversal technology refers to that a terminal with a private IP address in the private network accesses to the public network through a Network Address (Port) Translation/Fire Wall (NA(P)T/FW) at an exit. Audio and video applications based on the protocols such as H.323, SIP, Media Gateway Control Protocol (MGCP) and the like need to implement destination addressing by using IP address and port parameters in a signaling message. Therefore, an NAT traversal not only requires translation of port information of the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) layer as well as a source address and a destination address of the IP layer, but also requires translation related address information in an IP packet payload (i.e., signaling).
  • TCP/UDP Transmission Control Protocol/User Datagram Protocol
  • STUN and TURN are two kinds of NAT traversal approaches commonly used.
  • the STUN stands for Simple Traversal of UDP Through Network Address Translators, i.e., a simple UDP traversal approach for NAT.
  • An application i.e., an STUN client, transmits an STUN request message to an STUN server outside an NAT, and upon reception of the request message, the STUN server generates a response message carrying a source port of the request message, i.e., an external port corresponding to the STUN client in the NAT.
  • the response message is transmitted to the STUN client through the NAT, and the STUN client knows its external address in the NAT from contents in the message body of the response message, and puts the external address into a UDP load of a subsequent call protocol to notify the peer end that the local RTP receiving address and port number are the external address and port number in the NAT.
  • a media stream can successfully traverse the NAT because an NAT mapping table entry of the media stream has been created in advance in the NAT through the STUN protocol.
  • a major advantage of the STUN protocol lies in that no modification needs to be made to the existing NAT/FW device and the STUN approach can be used in a network environment with a plurality of NATs being connected in series.
  • the limitation of the STUN lies in that: the terminal in the private network has to support functions of an STUN client, traversal of the Symmetric NAT type is not supported but an exit NAT of the Symmetric NAT type is typically adopted in an intranet with a relatively high security requirement.
  • the TURN stands for Traversal Using Relay NAT, i.e., a traversal for NAT by a relay approach.
  • a TURN application model allocates an address and port of a TURN server as an external receiving address and port of a Voice Over IP (VOIP) terminal in the private network, i.e., messages transmitted from the terminal in the private network are all relayed by the TURN server.
  • VOIP Voice Over IP
  • this approach also overcomes the drawback of an STUN application being unable to traverse a Symmetric NAT or a similar firewall device, and the TURN also supports a TCP based application.
  • the TURN server controls address and port allocation, and can allocate a pair of RTP/RTCP addresses (an RTP port number plus 1 is an RTCP port number) as a receiving address of an end user in the private network, thereby avoiding arbitrary allocation of RTP/RTCP addresses and port numbers by the exit NAT as in the STUN approach, which leads to the client being unable to receive an RTCP message transmitted from the peer end (the RTCP message is transmitted from the peer end with a default destination port number being an RTP port number plus 1).
  • the TURN approach results in a public network address in the TURN server.
  • the limitation of the TURN lies in that: the VOIP terminal has to support a TURN client as in the STUN requiring a network terminal. Furthermore, the relay of a media stream via the TURN server may cause an increased delay of a packet and an increased possibility of losing packets.
  • the TURN approach is also referred to as a forward approach of the STUN approach.
  • the media gateway controller specifies that a CPE 2 carried in a far end Session Description Protocol (SDP) packet of a RTP endpoint RTP/2 is a private network address of the peer end of a media stream in the private network behind the NAT device.
  • SDP Session Description Protocol
  • the NAT When a media stream transmitted from the peer end in the private network, i.e., the endpoint with the private network address of the CPE 2 , passes the NAT, the NAT translates its address into a CPE 1 , but in the H.248 protocol, the endpoint RTP/2 will transmit the media stream to the private network address CPE 2 , and this is actually unreachable for the endpoint RTP/2. Consequently, an H.248 signal is added in the H.248.37, and the H.248 signal is issued to the endpoint RTP/2 as an instruction for an NAT traversal. At this time, the endpoint RTP/2 replaces the private network address CPE 2 in the far end SDP with the public network address CPE 1 of the actually received media stream.
  • the media stream transmitted from the endpoint RTP/2 is transmitted to the CPE 1 , and according to an address mapping relationship created in advance, the NAT transmits the media stream received by the CPE 1 to the address CPE 2 in the private network.
  • the endpoint in the private network transmits a media stream to the endpoint in the public network first, so that the NAT device is activated to generate address mapping, and according to the source address of the received media stream, the endpoint in the public network determines the destination address to which it transmits media stream.
  • a demand for unidirectional media may arise in a lot of situations. For example, a demand for a ring back tone, a color ring and the like to be played by the peer end, and at this time, for the reason that the called party is not off-hook, the calling party in the private network does not transmit any media stream, so that the calling party in the private network cannot receive a media stream. Furthermore, when a silence detection is activated, there is no media stream transmitted from the private network to the public network if the user in the private network is silent, and the public network cannot transmit a media stream to the private network.
  • the endpoint in the private network has to transmit a media stream to the endpoint in the media gateway of the public network first, otherwise the endpoint in the public network intended to transmit a media stream cannot transmit the media stream to the peer end due to the absence of a public network address to which the NA(P)T maps the private network address of the peer end.
  • FIG. 2 illustrates a schematic diagram of networking based on the NAT type of Restricted Cone in the prior art, where it is assumed that a local media address of a media gateway 1 is an address B which is mapped to an address A by an NAT, and a local media address of a media gateway 2 is an address X.
  • the NA(P)T has a lifecycle restriction for an address mapping, and the existing address mapping is deleted if it has never been used during the lifecycle.
  • a media stream cannot be transmitted from the outside of the NA(P)T to the inside of the NA(P)T, and even if a new media stream is transmitted out of the NA(P)T, the NA(P)T may likely map a new public network address for the media stream.
  • a problem may also arise if the peer end uses a previously stored old mapped public network address.
  • Forwarding a media stream through the TURN server may also encounter similar problems as through the STUN server.
  • a media device in the private network such as an MG and various types of terminals and the like, has to transmit a media stream to the peer end first even if the media device has been mapped to a public network address, otherwise a media stream transmitted from the peer end of the media device in the private network first cannot be ensured to arrive at the media device.
  • an address mapping in the NA(P)T may fail to remain alive in the event that no media stream has passed for a period of time.
  • the invention provides a method and system for connecting a media stream to solve the problem in the conventional systems where there is no path for a media stream transmitted from the peer end of a media device in a private network to arrive the media device in the private network due to the absence of an address mapping in an NA(P)T because the media device in the private network does not transmit any media stream to the peer end first, and the problem that an address mapping in the NA(P)T cannot be kept alive.
  • the invention provides a method for connecting a media stream, including (1) transmitting, by a media gateway in a private network, a connecting message to an external network device through a network address translation device; and (2) receiving, by the network address translation device, the connecting message, wherein the connecting message is used for generating a new address mapping, which is used for a subsequent media stream to pass through the network address translation device, in the network address translation device when there is no address mapping available in the network address translation device, and is used for keeping alive an address mapping when the address mapping is already available in the network address translation device.
  • the invention provides a method for detecting connectivity, including (1) transmitting, by a media device in a bearer network, a connecting message to another media device; (2) determining whether a response message for the connecting message is received within a predetermined period of time; and (3) determining bidirectional connectivity of a network path in the bearer network, where the two media devices are located, when the response message for the connecting message is received within the predetermined period of time.
  • the invention provides another method for detecting connectivity, namely detecting whether a media device in a bearer network has received a media stream and/or a connecting message transmitted from the peer end within a predetermined period of time, and if so, determining connectivity in a direction from the peer end to the media device, otherwise determining non-connectivity in the direction from the peer end to the media device.
  • the invention provides a system for connecting a media stream, including a device in a private network, a network address translation device and a peer end network device of the device in the private network, wherein the device in the private network includes (1) a message generating unit, adapted to generate a connecting message; and (2) a connecting unit, adapted to transmit the connecting message to the peer end network device through the network address translation device; and the network address translation device comprises (a) an address mapping unit, adapted to generate, according to the connecting message, a new address mapping, wherein: according to the connecting message, the new address mapping, which is used for a subsequent media stream to pass through the network address translation device, is generated in the network address translation device when there is no address mapping available in the network address translation device; and (b) a keeping-alive unit, adapted to keep alive, according to the transmitted connecting message, an address mapping, wherein: the address mapping is kept alive according to the connecting message when the address mapping is already available in the network address translation device.
  • the invention provides a system for detecting connectivity, including (1) a connectivity detecting unit, adapted to detect whether a bearer network where media devices are located has connectivity, wherein whether a first media device in the bearer network has received a media stream and/or a connecting message transmitted from a second peer end media device within a predetermined period of time is determined, and if so, connectivity in a direction from the peer end to the media device is determined, otherwise non-connectivity in the direction from the peer end to the media device is determined.
  • a connectivity detecting unit adapted to detect whether a bearer network where media devices are located has connectivity, wherein whether a first media device in the bearer network has received a media stream and/or a connecting message transmitted from a second peer end media device within a predetermined period of time is determined, and if so, connectivity in a direction from the peer end to the media device is determined, otherwise non-connectivity in the direction from the peer end to the media device is determined.
  • the invention further provides a media device, including (1) a message generating unit, adapted to generate a connecting message, wherein a type of the connecting message comprises a media message, a silence information description message, an RTP No-Op message, an RTP packet with an unknown payload type, a UDP packet of 0 byte, a message in a self-defined format, or an STUN binding request; and (2) a transmitting unit, adapted to transmit the connecting message to a peer end device through a network address translation device.
  • a message generating unit adapted to generate a connecting message, wherein a type of the connecting message comprises a media message, a silence information description message, an RTP No-Op message, an RTP packet with an unknown payload type, a UDP packet of 0 byte, a message in a self-defined format, or an STUN binding request
  • a transmitting unit adapted to transmit the connecting message to a peer end device through a network address translation device.
  • the invention further provides a network address translation device, including (1) a receiving unit, adapted to receive a connecting message; (2) an address mapping unit, adapted to generate, according to the connecting message, a new address mapping, wherein: according to the connecting message, the new address mapping, which is used for a subsequent media stream to pass through the network address translation device, is generated in the network address translation device when there is no address mapping available in the network address translation device; and (3) a keeping-alive unit, adapted to keep alive, according to the transmitted connecting message, an address mapping, wherein: the address mapping is kept alive according to the connecting message when the address mapping is already available in the network address translation device.
  • the method for connecting a media stream can be applied in a way that the device in the private network and the peer end device can unidirectionally or bidirectionally transmit a connecting message through the network address translation device, and the connecting message can generate an address mapping in the network address translation device, so that a media stream transmitted from the peer end of the device in the private network can be transmitted to the media device in the private network by using the address mapping as a transmitting path, thereby avoiding the limitation that the media device in the private network has to transmit a media stream to the peer end first, and address mappings in the NA(P)T and in the TURN server can be kept alive.
  • the method for detecting connectivity according to the embodiments of the invention can be applied to detect bidirectional connectivity of a bearer network in a way of determining whether a media device in the bearer network has received a response message for a connecting message transmitted from another media device within a predetermined period of time, and if so, it indicates bidirectional connectivity between the two media devices in the bearer network.
  • the method for detecting connectivity according to the embodiment of the invention can be applied to detect unidirectional connectivity of a bearer network in a way of determining whether a media device in the bearer network has received a media stream and/or a connecting message transmitted from the peer end within a predetermined period of time, and if so, it indicates connectivity in the direction from the peer end to the media device.
  • FIG. 1 illustrates a schematic structural diagram of an existing NGN network
  • FIG. 2 illustrates a schematic diagram of networking based on the NAT type of Restricted Cone
  • FIG. 3 illustrates a schematic diagram of a flow of the method for connecting a media stream according to an embodiment of the present invention
  • FIG. 4 illustrates a schematic diagram of a flow of the method for detecting connectivity according to a first embodiment of the invention
  • FIG. 5 illustrates a schematic diagram of a flow of the method for detecting connectivity according to a second embodiment of the invention.
  • a device in a private network transmits a connecting message to its peer end through a network address translation device, and a destination address of the connecting message may be a public network address of the peer end, or a public network address of the peer end mapped by the network address translation device.
  • a destination address of the connecting message may be a public network address of the peer end, or a public network address of the peer end mapped by the network address translation device.
  • an address mapping is generated in the network address translation device, and the address mapping is the public network address of the private network device for connecting a media stream.
  • the peer end can obtain from the connecting message the public network address of the private network device for connecting a media stream.
  • the connecting message establishes a media stream channel, and through the media stream channel established by the address mapping for the device in the private network and resulted from the connecting message, the network address translation device receives a media stream transmitted from the peer end and transmits it to the device in the private network to realize connecting the media stream.
  • the public network address, which is required for the peer end, mapped for the device in the local end private network can be obtained from the connecting message or in other approaches, for example, in the STUN/ICE approach (RFC 3489 and draft-ietf-mmusic-ice-09.txt).
  • the peer end can obtain the public network address in other approaches, for the NAT of a type other than Full Cone, the primary function of the connecting message is to provide a media path, thus the peer end can transmit a media stream to the device in the private network along a path reverse to the connecting message.
  • the peer end of the device in the private network can duly obtain a public network address in an NA(P)T mapped for a far end private network address, and takes it as a far end address, so that a media stream can be initiated from the peer end of the device in the private network and forwarded through the NA(P)T to the device in the private network, thereby obviating the limitation that the media stream has to be initiated from the device in the private network.
  • the embodiments of the invention can be applied to solve not only the problem in the H.248.37 scenario but also the problem in the situation that the device in the private network has obtained the public network address in the NA(P)T mapped for the local media address by some approaches, and the type of the NA(P)T is Restricted Cone, Port Restricted Cone or Symmetric.
  • the two ends of the media stream are located in different private networks, all the ends shall transmit a connecting message to the peer end from the NA(P)T.
  • Connectivity in this application refers to that due to an address mapping being exist in the NA(P)T or TURN, a connecting message shall be used to generate and keep the address mapping, or the peer end shall be enabled to transmit a media stream in a direction reverse to the direction of the connecting message, thereby connecting the media stream.
  • a connecting message in either direction can be used to keep the mapping, thereby keeping alive the NA(P)T address mapping.
  • the MG 1 After obtaining, through the STUN server, the public network address A mapped by the NA(P)T for the local address B, the MG 1 transmits a connecting message to the address X of the MG 2 , thus a media stream initially transmitted from the address X to arrive at the address A can be forwarded to the address B by the NA(P)T.
  • the address B can also initially transmit a media stream to the address X.
  • a public network address and a private network address described herein are both referred to with respect to an NA(P)T.
  • a network address internal to the NA(P)T is referred to as the private network address, and an address mapped by the NA(P)T for the private network address is referred to as the public network address.
  • each device transmits a connecting message to the peer end through a public network address mapped by an NAT, and if the type of the NAT is Restricted Cone, each device activates an address mapping in the NAT used by the local end, then each end can transmit a media stream to the peer end along the same path.
  • the above device in the private network may be an MG in the private network, or other media processing devices of various types in the private network, such as an H.323 terminal, an SIP terminal (including an SIP IAD, a user equipment supporting the SIP) and the like.
  • the above peer end of the device in the private network may be an MG or other media processing devices, such as an H.323 terminal, an SIP terminal (including an SIP IAD, a user equipment supporting the SIP) and the like.
  • the above peer end of the device in the private network may be located in the public network or in another private network, and the two private networks can be connected through an NA(P)T or through an NA(P)T connecting to a packet network.
  • the MG can initiate a connecting message on its own initiative or under the control of an MGC.
  • the type of the connecting message can be decided by an MG itself or can be specified by the MGC.
  • the MGC can audit the MG to obtain the types of a connecting message that the MG can support, and the support can be subdivided into a support for transmitting and a support for receiving and processing.
  • the types of a connecting message transmitted from the MG includes a media message, a Silence Information Description (SID) message, an RTP No-Op message and a message in another format as defined in the IETF draft-marjou-behave-app-rtp-keepalive-00.txt and subsequent revisions of this draft, or other connecting messages in a self-defined format.
  • the RTP message may be an RTP message with media being packaged and transmitted normally as if no VAD function is activated.
  • audio data are packaged according to a 20-millisecond time length into an RTP message with a coding method of G.729 and a packaging time length of 20 milliseconds.
  • a media stream in a format other than the RTP format can also use a “harmless” message, in the same format as that of the media stream but with null contents, as its connecting message, and it should be the precondition that normal service data processing is not influenced.
  • the MG is a gateway supporting the STUN
  • the MG can transmit an STUN binding request message as a connecting message in addition to the above types of connecting message.
  • the connecting message is used to generate an IP message from the inside of the NAT to the outside of the NAT, so that a real media stream from the outside of the NAT can be transmitted back along the original path.
  • the use of the STUN binding request as a connecting message has an advantage that a mapped address can be returned by the STUN binding request, and if an address mapping in the NAT is lost due to resetting of the NAT or other failure of the bearer channel, the mapped address carried in a response message for the connecting message may be changed, thus even if there is a response to the connecting message, it can be determined that the media stream cannot come back in a reverse direction due to the change of the address, thereby avoiding such a situation that a new public network address is re-mapped by the NA(P)T but the peer end still transmits a media message to a previously stored old mapped address, which leads to a media stream fails to be connected.
  • a mapped address mapped by the NAT is changed, a source address of a connecting message or a media stream received at the public network side is also changed, the MG can notify the change to the MGC, and the MGC can further instruct the public network side to modify a far end address so that a media stream can be bidirectionally connected.
  • a specific format of the connecting message mentioned above can be self-defined, or can be an existing format having not been listed here. In a practical application, the format is not limited to those having been listed.
  • the H.248 protocol and/or the MGCP protocol shall be extended.
  • the extending approaches of the two protocols are similar to each other in that a signal is issued to instruct the MG to transmit a connecting message.
  • the signal can specify those local media address being required to transmit a connecting message.
  • H.248 An embodiment of the H.248 will be described below, and an embodiment of the MGCP is similar to that of the H.248 and repeated descriptions are omitted here.
  • the H.248 is extended with an H.248 based media bearer connecting packet “traffct”.
  • a signal “scp” is defined for the MGC to instruct the MG to transmit a connecting message. This signal can generally ask the MG to transmit a connecting message in all media channels, or particularly specify some parameters of a connecting message.
  • Addresses in the local SDP are numbered, for example, with a format of ⁇ N, X, Y>, where N refers to a serial number and is arranged in sequence starting from 1, X refers to a group number, and Y refers to an address serial number in the group.
  • N refers to a serial number and is arranged in sequence starting from 1
  • X refers to a group number
  • Y refers to an address serial number in the group.
  • “ ⁇ 2, 2, 1>” represents that an address with the serial number of 2 is the first address in the second group of the local SDP.
  • each of the addresses in the local SDP can be provided with a unique serial number.
  • each item in the list can take the following values:
  • L “Local Address”, which indicates transmission from a local address.
  • N “No Request”, which indicates that a local address with the serial number is not required to transmit a connecting message.
  • a serial number of a character string in the list corresponds to the serial number of the numbered address in the above SDP.
  • a receiving address only corresponds to one source address, there is no need to distinguish different media streams and hence there is no need to carry media type information in a connecting message.
  • the message already carries media stream information. For example, if a media stream is of the G.711, the connecting message is also of the G.711.
  • the connecting message is in a self-defined format, there is also a need to carry information for distinguishing different media streams in the connecting message, for example, to carry a media attribute such as a payload type and the like.
  • an STUN binding request is used as the connecting message, there is also no need to carry information for distinguishing different media streams in the connecting message, because in the case of using the STUN protocol, the peer end of the device in the private network has already obtained a public network address mapped for a private network address, therefore the peer end represents which media stream in the SDP can be determined by analyzing a source address in the STUN request, so that there is no need to distinguish.
  • the connecting message without a response mechanism may be transmitted repeatedly so as to avoid a false determination resulting from the connecting message being lost on its way.
  • the peer end of the device in the private network can further make a response to the connecting message so as to not only avoid repeated transmission of the connecting message but also enable the sender to confirm that the path is connected.
  • This response can be made by the peer end device automatically or under control.
  • the peer end of the device in the private network may make a response directly, i.e., a default response, or may be instructed to support a response.
  • a specific responding approach can just be a simple response message. After successful mapping in the NAT and a media stream having been connected, either of interacting parties can initiate a connecting message on its own initiative.
  • the device in the private network can further make a response to the received response so as to implement a three hand-shaking mechanism.
  • the peer end of the device in the private network is an MG, whether to make a response automatically can be configured, or the protocol can be extended with a packet having a defined attribute “scprep”. If the value of the attribute is TRUE, it indicates that a local media address can make a response to a connecting message so as to avoid repeated retransmission of the connecting message. If the value of the attribute is FALSE, no response is made.
  • the above response may be a loop made by the receiving end which return the received connecting message, or may be a different message generated by the receiving end itself and used as a response message.
  • a connecting message can be transmitted from one end to another end, and the another end detects the connecting message and a media stream message. If the peer end can receive the messages, it indicates connectivity from the local end to the peer end. As can be defined flexibly for a practical application, the detector can detect either or both of the connecting message and the media stream message. On the contrary, a connecting message or a media stream message can be transmitted from the peer end and detected at the local end, so that connectivity from the peer end to the local end can be detected. Bidirectional connectivity can be obtained by combining the detection results in the two directions.
  • transmission of a connecting message can be stopped after confirming connectivity of a media stream.
  • transmission of a connecting message can be stopped upon reception of a response, or transmission of a connecting message can be stopped upon reception of a media stream or a connecting message transmitted from the peer end.
  • a device behind an NA(P)T transmitting a connecting message is a device A
  • the peer end is a device B which may be located in the public network or in the private network and the private address of the device B is mapped to a public network address by an NA(P)T.
  • the device A transmits a connecting message to the device B and receives a service data stream in the reverse direction, i.e., a media stream from the device B, it indicates that the purpose of transmitting the connecting message has been achieved and connectivity from the device B to the device A is accomplished, so that the device A can stop transmission of a connecting message.
  • a service data stream in the reverse direction i.e., a media stream from the device B
  • an address mapping in an NA(P)T has a lifecycle, i.e., a certain address mapping is deleted if the mapping has not been used for a long period of time.
  • Transmission of a connecting message in either of the two directions can achieve the purpose of keeping alive the address mapping in the NA(P)T.
  • a connecting message as described in the invention can also be used as a heartbeat mechanism.
  • the device behind the NA(P)T detects a transmitted or received media stream, if no transmission or reception of any media stream is performed for an address mapping during a predetermined period of time, the device transmit a connecting message in order to prevent the address mapping from being deleted due to time-out, thereby ensuring the existence of the address mapping.
  • transmission of the connecting message can be stopped temporarily in the case that there is a media stream, or the connecting message can be transmitted periodically without considering the status of a media stream so as to simplify the processing logic.
  • the H.248/MGCP protocol can be extended in a way that the MGC issues an attribute or a signal to instruct the media gateway to periodically transmit a connecting message traversing through the NA(P)T device to the peer end of a media stream, and the transmission period can be specified by the MGC.
  • a connecting message can be transmitted separately for each media stream path to ensure connectivity of each media stream. If the peer end has the function of making a response to a connecting message, this function can be further extended in a way that the end having not received a response reports abnormality.
  • the response mechanism is not compulsory in some case, for example, each of the two ends can periodically transmit a connecting message to the peer end and can detect a received connecting message and media stream message, and if the connecting message or the media stream message can be received, it indicates connectivity of a receiving path.
  • Bidirectional connectivity detection can be accomplished by both ends detecting connectivity of the receiving path.
  • the operation of reporting abnormality can be accomplished by adding an H.248/MGCP event “patherr” to report non-connectivity of a media stream path.
  • the operation of reporting abnormality can be accomplished by an approach of defining an event report. Similar to the H.248/MGCP, the SIP device can report the event by subscription or predetermination.
  • a local end address corresponds to a plurality of peer end address for transmission and reception of a media stream during media negotiation, and there may be one or more NA(P)Ts between the two ends, so that the same local address may correspond to a plurality of media streams.
  • the MGC shall specify a single media stream while issuing a signal to instruct transmitting a connecting message or reporting non-connectivity of a connecting message, therefore there is a need to add and modify description approaches.
  • An example of the SDP is as follows.
  • the above three lines mean that the media uses the type of audio, uses the IPV4, and a bearer of the media uses the RTP protocol (defined in the RFC3551).
  • a Codec uses the PCMU and the G.729 for coding and decoding.
  • the local media address in the private network “10.1.1.1:1000” is mapped to two public network addresses in the NAT. It is assumed that the addresses of the two media streams at the peer end are an address A and an address B respectively, and the address A and the address B are different (including different IP addresses or different ports).
  • the NAT type is Restricted Cone, although the local private network media address “10.1.1.1:1000” is only mapped to one public network address in the NAT, a media stream from the address B cannot be returned through the NAT to the private network address “10.1.1.1:1000” if there is no media message transmitted from “10.1.1.1:1000” to the address B even if there is a media stream interacting between the private network address “10.1.1.1:1000” and the address A. It is assumed that the addresses of the two media streams at the peer end are an address A and an address B respectively, and the address A and the address B are different IP addresses.
  • NAT type is Port Restricted Cone
  • the local private network media address “10.1.1.1:1000” is only mapped to one public network address in the NAT, a media stream from the address B cannot be returned through the NAT to the private network address “10.1.1.1:1000” if there is no media message transmitted from “10.1.1.1:1000” to the address B even if there is a media stream interacting between the private network address “10.1.1.1:1000” and the address A.
  • a parameter “faext” is defined for the signal “scp”, the type of the parameter “faext” is a list of character strings, and each line of the list is in the following format:
  • the payload type of RTP packet is listed, here i.e., two payload types 0 and 18 representing the G.711 (i.e., the PCMU) and the G.729.
  • Serial numbers of the media stream number are arranged in sequence starting from 1.
  • the media stream number is an optional item. If the media stream number is not contained, it is indicated that all media streams of the address serial number are enabled.
  • “1” indicates an address with the serial number of 1, i.e., a connecting message is transmitted from the address “10.1.1.1:1000”. If far end addresses of the PCMU and the G.729 are different and the NAT type is not Full Cone, it is required to transmit connecting messages for both different destination addresses. There is an exceptional case, for the NAT type of Port Restricted Cone, if two destination addresses have identical IP addresses and different ports, it is only required to transmit a connecting message to one of the addresses, and this is resulted from the characteristics of the Port Restricted type. If a connecting message is only transmitted for one of the media streams, “1, 2” can be used to indicate that a connecting message is transmitted from the private network address “10.1.1.1:1000” to the G.729 peer end address with the media stream number of 2.
  • the NAT type may not be considered, and it is specified to transmit connecting messages in part of or all of media stream paths.
  • a complex logic resulting from determining the NAT type can be avoided.
  • the NAT type is Full Cone, it is only required to transmit a connecting message in one media stream path (e.g., only in the G.711 media path but not in the G.729 media path) to ensure proper generation or keeping of an NAT mapping.
  • the MGC can ask connecting messages to be transmitted in both paths.
  • the NAT is only a part of the entire media channel, therefore it may be required to implement whole path detection for each media stream path.
  • an event “patherr” can be defined to report a parameter “ep” (error path) of the event, and the type of the parameter is a list of character strings.
  • Each character string in the list is in the following format:
  • “1, 2” indicates that no response can be obtained for a connecting message in a path through which a media stream with the address serial number of 1 and the media stream number of 2 passes.
  • the media stream number is still an optional item.
  • Attributes of an IP media stream typically include a 5-Tuples of a source IP address and a source port, a destination IP address and a destination port, and the type of a media transmission protocol of the path. Therefore, different media streams with the same source address and the same destination address can share the same connecting message and the same heartbeat detection so as to avoid repeated connectivity detection or repeated keeping of an NA(P)T address mapping for the same path.
  • the peer end device may be unable to make a response to a connecting message, or the format of a response message has not been defined for a connecting message itself, but the peer end device can also transmit a connecting message.
  • the MGC instructs two gateways at two ends of a media stream to both periodically transmit connecting messages to the peer end.
  • the two ends both detect reception of a connecting message or a media stream message, and reports an event to the MGC if no message is received within a predetermined period of time.
  • only one end makes detection, which results in unidirectional connectivity being detected.
  • a connecting message being an STUN binding request message
  • Connectivity Checks in the IETF draft of draft-ietf-mmusic.ice-09.txt if a mapped address carried in a response message for the STUN binding request is changed, it indicates that the NAT address may have been updated, and it is also required to report an event for notifying the MGC, so that the MGC can re-initiate an STUN process for re-exchanging media stream addresses between two ends of a call. If the reported event carries an updated mapped address, the MGC can transmit the address to the peer end to enable the peer end to update an address of the far end. Regardless of the format used by a connecting message, if the source address of the connecting message is changed, or if the source address of a response message for the connecting message is changed, the event can also be used to report.
  • an STUN connectivity packet “Stunct” is defined.
  • a signal “stunbr” is defined for transmitting an STUN binding request as a connecting message. This is equivalent to connectivity detection between operating candidates at two ends of a media stream selected in the ICE technology. In other words, connectivity detection is made along a path of the media stream.
  • the signal carries a parameter “fa” with the type of a list of character strings, and each item in the list can take the following values:
  • L “Local Address”, which indicate transmission from a local address.
  • N “No Request”, which indicates that a local address with the serial number is not required to transmit a connecting message.
  • a serial number of a character string in the list corresponds to the serial number of the numbered address in the above SDP.
  • the connecting message is also forwarded from the STUN as the media stream.
  • a signal “stunbrhb” is defined for periodically transmitting an STUN binding request as a connectivity detection heartbeat.
  • the signal carries a parameter “fa” with the same meaning as the definition of the parameter “fa” in the signal “stunbr”.
  • the signal carries a parameter “interval” with the type of integer, in milliseconds and indicating a heartbeat interval.
  • the heartbeat interval applies to all address serial numbers specified in the parameter “fa” and being required to transmit a heartbeat.
  • the gateway can transmit the respective connecting messages at an appropriate interval of, for example, 50 milliseconds, so as to avoid congestion due to the plurality of messages being transmitted simultaneously.
  • the parameter “fa” can be defined in a form of a list in which a heartbeat period is set separately for each heartbeat request.
  • the parameter “fa” can be replaced by the above-defined parameter “faext”.
  • This event is used to detect whether a connecting message is successful. If a response for the connecting message fails to be received, or if a mapped address carried in the response message is changed, the event is reported.
  • This event carries a parameter “timeout” for setting a predetermined period of time. After the connecting message is transmitted, if no response for the connecting message is received within the period of time, the event is reported.
  • This event further carries a parameter “fae” for setting addresses at which an STUN response message is detected.
  • the meaning of the parameter “fae” is the same as the definition of the parameter “fa” or “faext” of the signal “stunbr”.
  • a response message is detected at all addresses transmitting a connecting message and an abnormality is reported. If so, the parameter “fae” is unnecessary.
  • this event carries a parameter “ep” with the type of a list of character strings to report a list for a connecting message without a response message.
  • Each character string in the list is in the following format:
  • this event can further carry a parameter “ca” with the type of a list of character strings to report a changed mapped address in a response message of an STUN binding request or to report a changed source address of the connecting message.
  • the first two parameters have the same usage as that of the parameter “ep”, and the mapped address is a mapped address carried in the response message of the STUN binding request.
  • Connectivity detection in an RTCP path can be made by the MG by default and simultaneously with detection of a corresponding media stream, or related contents for connecting an RTCP path and connectivity detection can be added in the packet, based on the same principle and method as those for connecting other media streams and other connectivity detection.
  • An RTCP stream is also a component of media streams.
  • a signal “scp” is defined for transmitting a connecting message.
  • a connectivity detection is made along the source address and the destination address of a media stream.
  • a specific format of the connecting message is not defined here, and the RTP No-Op message can be used as a choice.
  • the signal carries a parameter “fa” with the type of a list of character strings, and each item in the list can take the following values:
  • L “Local Address”, which indicate transmission from a local address.
  • N “No Request”, which indicates that a local address with the serial number is not required to transmit a connecting message.
  • a serial number of a character string in the list corresponds to the serial number of the numbered address in the above SDP.
  • a signal “scphb” is defined for periodically transmitting a connecting message.
  • the signal carries a parameter “fa” with the same meaning as the definition of the parameter “fa” in the signal “scp”.
  • the signal carries a parameter “interval” with the type of integer, in milliseconds and indicating a heartbeat interval.
  • the heartbeat interval applies to all address serial numbers specified in the parameter “fa” and being required to transmit a heartbeat.
  • the gateway can transmit the respective connecting messages at an appropriate interval of, for example, 50 milliseconds, so as to avoid congestion due to the plurality of messages being transmitted simultaneously.
  • the parameter “fa” can be defined in a form of a list in which a heartbeat period is set separately for each heartbeat request.
  • a heartbeat timer is reset, and this can reduce a system burden resulting from heartbeat messages.
  • the parameter “fa” can be replaced by the above-defined parameter “faext”. It shall be noted that whether the parameter faext can be used is dependent on a format defined for a connecting message. If the connecting message itself carries no media stream information, the receiving end cannot distinguish which media stream is represented by the connecting message transmitted to the same destination address through different paths.
  • a signal “comht” is defined to instruct transmitting a connecting message.
  • detecting whether a bearer network has connectivity there is no need to detect connectivity for each media stream established for each call, and the detection can be made by selecting an address respectively from the two ends of the bearer network and transmitting a connecting message for the selected addresses.
  • Parameters can be defined for the signal to carry a source address and a source port, a destination address and a destination port, a transmission period of a connecting message, and the type of the connecting message.
  • This event is used to detect whether a connecting message is successful. If a response for the connecting message fails to be received within a predetermined period of time, or if the connecting message or a media stream message fails to be received, the event is reported. If the source address of the connecting message or its response message is changed, abnormality can also be reported by the event.
  • This event can further carry a parameter “timeout” for setting a predetermined period of time.
  • This event further carries a parameter “fae” for setting addresses at which an incoming media message is detected.
  • the meaning of the parameter “fae” is the same as the definition of the parameter “fa” of the signal “stunbr”.
  • this event carries a parameter “ep” with the type of a list of character strings to report a list for a connecting message without a response message.
  • Each character string in the list is in the following format;
  • the media gateway controller can further obtain types of connecting message supported by the media gateway.
  • the above newly added packets relate to a possible implementation scheme and can be adjusted in the condition of complying with the principle of this application.
  • the same instruction contents can alternatively be sent in an H.248 signal by an H3.248 attribute.
  • a connecting message according to the invention can be used to connect a media stream and to detect connectivity.
  • the same connecting message can be used to connect and to detect connectivity.
  • Connectivity detection in this application refers to detecting availability of a media stream path by transmitting a connecting message along the media stream path. Furthermore, the connectivity detection can also be used to detect bearer connectivity between two network nodes, which is independent of a specific service media stream.
  • a connecting message can be transmitted and received between two ends of a capability negotiated media stream, or between two ends of a configured or specified media stream.
  • an address for transmitting and receiving a connecting message can be configured between two MGs or other media devices such as SIP/H.323 terminals.
  • a connecting message is primarily used to detect connectivity of a bearer layer instead of being specified to a media stream channel of a call.
  • the address for transmitting and/or receiving a connecting message can alternatively be specified by the MGC, an SIP UA device and the like through signaling. This needs to extend the H.248/MGCP/SIP/H.323 protocol to issue these instructions.
  • a media stream When failure occurs in a bearer network, a media stream cannot be connected even if call signaling is established successfully.
  • connectivity failure is reported if it is detected that no media stream is received within a certain period of time.
  • there is no media stream sometimes may not be equivalent to non-connectivity of the media stream, because it is possible that there is indeed no media stream interacting between two ends within the period of time, for example, in the case that the VAD is activated.
  • FIG. 4 illustrates a schematic diagram of a flow of a first embodiment of the method for detecting connectivity according to the invention, and the idea of the method is: one of two media devices in a bearer network transmits a connecting message and determines whether a response message for the connecting message is received within a predetermined period of time, and if so, the bearer network where the two media devices are located has bidirectional connectivity, otherwise the bearer network where the two media devices are located has no connectivity.
  • the connecting message can be initiated from any party.
  • the above response may be a response transmitted from the party receiving a connecting message itself, or a loop of the received connecting message by the party receiving the connecting message.
  • the response can be made as in the event report approach defined above.
  • connecting messages can be transmitted in both directions, and receiving capabilities are detected at each end respectively.
  • FIG. 5 illustrates a schematic diagram of a flow of a second embodiment of the method for detecting connectivity according to the invention, and the idea of the method is: a media device in a bearer network determines whether a media stream and/or a connecting message transmitted from the peer end to the local end is received within a predetermined period of time, and if so, a bearer network where the peer end is located has unidirectional connectivity to the local end, otherwise the bearer network where the peer end is located has no unidirectional connectivity to the local end.
  • connectivity can be determined by only detecting a connecting message, or only detecting a media stream, or connectivity is determined if either of the connecting message and the media stream has been detected. Extremely, connectivity can only be determined if both of them have been detected.
  • FIG. 4 The primary difference between FIG. 4 and FIG. 5 lies in that the embodiment illustrated in FIG. 4 can be applied to detecting bidirectional connectivity, and the embodiment illustrated in FIG. 5 can be applied to detecting unidirectional connectivity, i.e., connectivity in the incoming direction.
  • unidirectional connectivity i.e., connectivity in the incoming direction.
  • FIG. 4 can be applied to FIG. 5 in this context, except for the difference between unidirectional detection and bidirectional detection.
  • a connecting message can be transmitted repeatedly, it can be used as a heartbeat mechanism for a long-term automatic connectivity detection of a media bearer network.
  • An interval of time between two heartbeats can be fixed or variable.
  • the heartbeat can be temporarily stopped while there is a media stream transmitted in the path.
  • the heartbeat mechanism can be initiated only if there is no media stream data transmitted for a period of time.
  • transmitting a connecting message successively is also possible.
  • the mechanisms for connecting a media stream and for detecting connectivity can also be applied to other media devices, for example, an SIP/H.323 device, and the SIP/H.323 protocol can be extended.
  • the SIP protocol can be extended to instruct an SIP device, including an SIP terminal, to transmit and receive a connecting message between two ends of some or all session media streams.
  • An event can be defined for a report when no response is received for a connecting message or when a mapped address is changed.
  • the SIP protocol can be further extended in a way that a heartbeat mechanism for a media bearer can be implemented by an approach of event subscription.
  • the functions for connecting a media stream and for detecting connectivity can be realized between the SIP/H.323 device and a media gateway.
  • a connecting message as referred to in this context can be an IP message or another type of message.
  • the packet “Stunct” and the packet “traffct” introduced above can also be used for detecting connectivity.
  • extended MGCP packets can be defined for connecting and for detecting connectivity.
  • two ends of a media stream are two different gateways each of which is controlled by an MGC respectively and the SIP protocol is applied between the two MGCs, it is required to extend the SIP protocol to support transmission and detection of a connecting message.
  • the media gateway at one end transmits connecting messages in some media stream paths, and instructs, through SIP signaling, the MGC at the peer end to detect the connecting messages at the peer end of the media streams.
  • an MGC can also act as an SIP Back-to-Back User Agent (B2BUA), which instructs, through an SIP message, an SIP terminal to transmit a connecting message and to detect connectivity.
  • B2BUA SIP Back-to-Back User Agent
  • an SIP terminal can also notify, through an SIP message, the peer end how the local end transmits a connecting message, and instruct the peer end to detect connectivity.
  • a header “x-ctreq” is added to instruct the peer end to transmit a connecting message and may also be used to further indicate media stream paths in which the connecting message is transmitted.
  • a connecting message path reference can be made to the definition of the parameter “fa” in the signal “scp” of the H.248 as mentioned above.
  • a period at which to a connecting message is transmitted can be set.
  • the header can also be used in an SIP message between two MGCs.
  • a header “x-ctsend” is added to notify the peer end that a connecting message has been transmitted by the local end and may also be used to further indicate media stream paths in which the connecting message is transmitted and the type of the transmitted connecting message.
  • a response for a received connecting message can also act as a connecting message.
  • a connecting message path reference can be made to the definition of the parameter “fa” in the signal “scp” of the H.248 as mentioned above.
  • information of a period at which a connecting message is transmitted can be carried. The peer end can know from the information that the connecting message is detect at which addresses.
  • the header can also be used for an SIP message between two MGCs.
  • An event subscription is added for an SIP terminal to detect connectivity and report a connectivity failure event.
  • Connectivity failure involves two cases: in one case, no IP connecting message, or a response for an IP connecting message, or media stream data and the like is received within a predetermined period of time, and non-connectivity of an incoming path is discovered and reported; and in another case, when an STUN binding request message is used as a connecting message, an event is required to be reported if a mapped address returned in a response message is changed. If the source address of a connecting message or the source address of a response message is changed, a report can also be defined.
  • H.323 An application scenario of the H.323 is similar to that of the SIP as described above, therefore the H.323 can also be similarly extended to implement the functions of transmitting a connecting message and detecting connectivity.
  • Embodiments of the invention further provide a system for connecting a media stream and a system for detecting connectivity, which will be detailed below.
  • An embodiment of the system for connecting a media stream according to the invention includes a device in a private network, a network address translation device and the peer end of the device in the private network. Specifically,
  • the device in the private network and the peer end device each include a connecting unit adapted to transmit a connecting message to the opposite party through the network address translation device;
  • the network address translation device further includes a keeping-alive unit adapted to keep alive, according to the transmitted connecting message, an address mapping;
  • the peer end device further includes a media stream transmitting unit adapted to transmit, according to a media stream path provided by the connecting message, a media stream to the device in the private network through the network address translation device.
  • the device in the private network may be a media gateway MG or an SIP device or an H.323 device
  • the peer end may be a media gateway MG or an SIP device or an H.323 device.
  • the type of the connecting message includes a media message, a Silence Information Description message, an RTP No-Op message, an RTP packet with an unknown payload type, a UDP packet of 0 byte, or a message in a self-defined format; if the MG supports the STUN protocol, the type of the connecting message includes a media message, a Silence Information Description message, an RTP No-Op message, an RTP packet with an unknown payload type, a UDP packet of 0 byte, a message in a self-defined format, or an STUN binding request.
  • the connecting message in the self-defined format contains information of the media type of the media stream path through which the connecting message passes.
  • the peer end device further includes a responding unit adapted to return a response message upon reception of the connecting message.
  • the peer end device and the device in the private network each further includes an abnormality report unit adapted to report abnormality when no response message for the transmitted connecting message is received within a predetermined period of time.
  • the peer end device and the device in the private network each further includes a bidirectional connectivity determining unit adapted to determine bidirectional connectivity between the device in the private network and a bearer network where the peer end is located after the response message for the connecting message is received within the predetermined period of time, otherwise determine non-bidirectional connectivity between the device in the private network and the bearer network where the peer end is located.
  • the peer end device and the device in the private network each further includes a unidirectional connectivity determining unit adapted to determine connectivity in the direction from the device at the transmitting end of the connecting message to the device at the receiving end of the connecting message after the device at the receiving end of the connecting message has received the connecting message and/or the media stream transmitted from the transmitting end of the connecting message, otherwise determine non-connectivity in the direction from the device at the transmitting end of the connecting message to the device at the receiving end of the connecting message.
  • the embodiment of the system for connecting a media stream according to the invention connects a media stream in an operating process similar to the above-described process of the method for connecting a media stream, and repeated descriptions are omitted here.
  • a first embodiment of the system for detecting connectivity according to the invention includes two media devices in a bearer network, each of which includes a bidirectional connectivity detecting unit adapted to determine bidirectional connectivity of the bearer network where the two media devices are located if a response message for a connecting message transmitted from one media device to another media device in the bearer network is received within a predetermined period of time, and to determine non-bidirectional connectivity of the bearer network where the media devices are located if no response message for the connecting message is received within the predetermined period of time.
  • the source address and the destination address of the connecting message are the source address and the destination address of the transmitted media stream.
  • the connectivity detecting unit is further adapted to determine bidirectional connectivity of a media path between the source address and the destination address if the media device at the transmitting end of the connecting message has received the response message for the connecting message within the predetermined period of time, otherwise determine non-bidirectional connectivity of the media path between the source address and the destination address.
  • the media devices each further includes an abnormality reporting unit adapted to report abnormality when no response message is received within the predetermined period of time.
  • the first embodiment of the system for detecting connectivity according to the invention detects in an operating process similar to the above-described process of the first embodiment of the method for detecting connectivity, and repeated descriptions are omitted here.
  • a second embodiment of the system for detecting connectivity includes a media device in a bearer network, which includes a unidirectional connectivity detecting unit adapted to determine connectivity in the direction from the peer end to the media device if the media device in the bearer network has received a media stream and/or a connecting message transmitted from the peer end within a predetermined period of time, otherwise determine non-connectivity in the direction from the peer end to the media device.
  • the source address and the destination address of the connecting message are the source address and the destination address of the transmitted media stream.
  • the connectivity detecting unit is further adapted to determine connectivity of a path between the source address and the destination address if the media stream and/or the connecting message transmitted from the destination address of the peer end are received within the predetermined period of time, otherwise determine non-connectivity of the path between the source address and the destination.
  • the media device further includes an abnormality reporting unit adapted to report abnormality when no response message is received within the predetermined period of time.
  • the second embodiment of the system for detecting connectivity according to the invention detects in an operating process similar to the above-described process of the second embodiment of the method for detecting connectivity, and repeated descriptions are omitted here.
  • the method for connecting a media stream can be applied in a way that the device in the private network and the peer end device can unidirectionally or bidirectionally transmit a connecting message through the network address translation device, and the connecting message can generate an address mapping in the network address translation device, so that a media stream transmitted from the peer end of the device in the private network can be transmitted to the media device in the private network by using the address mapping as a transmitting path, thereby avoiding the limitation that the media device in the private network has to initiate transmission of a media stream to the peer end, and address mappings in the NA(P)T and the TURN server can be kept alive.
  • the method for detecting connectivity according to the embodiment of the invention can be applied to detect bidirectional connectivity of a bearer network in a way that it is determined whether a media device in the bearer network has received a response message for a connecting message transmitted from another media device within a predetermined period of time, and if so, it indicates bidirectional connectivity between the two media devices in the bearer network.
  • the method for detecting connectivity according to the embodiment of the invention can be applied to detect unidirectional connectivity of a bearer network in a way that it can be determined whether a media device in the bearer network has received a media stream and/or a connecting message transmitted from the peer end within a predetermined period of time, and if so, it indicates connectivity in the direction from the peer end to the media device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
  • Flanged Joints, Insulating Joints, And Other Joints (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
US12/362,270 2006-08-02 2009-01-29 Method and system for connecting a media stream, and method and system for detecting a connectivity Active 2027-08-03 US7885278B2 (en)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
CN200610109508 2006-08-02
CN200610109508 2006-08-02
CN200610109508.0 2006-08-02
CNA200710000300XA CN101119299A (zh) 2006-08-02 2007-01-23 导通媒体流的方法、导通检测方法及其系统
CN200710000300.X 2007-01-23
CN200710000300 2007-01-23
PCT/CN2007/070372 WO2008017265A1 (en) 2006-08-02 2007-07-27 Method and system of conducting the media stream and method and system of conducting detection

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/070372 Continuation WO2008017265A1 (en) 2006-08-02 2007-07-27 Method and system of conducting the media stream and method and system of conducting detection

Publications (2)

Publication Number Publication Date
US20090135842A1 US20090135842A1 (en) 2009-05-28
US7885278B2 true US7885278B2 (en) 2011-02-08

Family

ID=39032642

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/362,270 Active 2027-08-03 US7885278B2 (en) 2006-08-02 2009-01-29 Method and system for connecting a media stream, and method and system for detecting a connectivity

Country Status (6)

Country Link
US (1) US7885278B2 (de)
EP (1) EP2048832B1 (de)
CN (1) CN101119299A (de)
AT (1) ATE502465T1 (de)
DE (1) DE602007013246D1 (de)
WO (1) WO2008017265A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090187644A1 (en) * 2008-01-22 2009-07-23 Fujitsu Limited Address distribution system and method and program for the same
US9596272B2 (en) 2014-09-25 2017-03-14 Microsoft Technology Licensing, Llc Media session between network endpoints
US10079863B2 (en) 2015-11-18 2018-09-18 Microsoft Technology Licensing, Llc Media session between network endpoints
US10158679B2 (en) 2015-11-18 2018-12-18 Microsoft Technology Licensing, Llc Media session between network endpoints
US10171511B2 (en) 2014-09-25 2019-01-01 Microsoft Technology Licensing, Llc Media session between network endpoints
US10244003B2 (en) 2014-09-25 2019-03-26 Microsoft Technology Licensing, Llc Media session between network endpoints

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080298237A1 (en) * 2006-08-03 2008-12-04 Latitude Broadband, Inc. Methods, Systems, and Apparatus of Providing QoS and Scalability in the Deployment of Real-Time Traffic Services in Packet-based Networks
CN101370310B (zh) * 2008-09-16 2011-09-14 华为终端有限公司 用户终端、应用服务器以及呼叫建立方法
CN101631084B (zh) * 2009-08-06 2012-05-09 中兴通讯股份有限公司 实现媒体控制流报文穿越网络地址转换器的方法及系统
JP2011055332A (ja) * 2009-09-03 2011-03-17 Nec Corp 通信中継システム
CN101883157A (zh) * 2010-06-28 2010-11-10 华为技术有限公司 一种实现网关接入的方法和相应装置
CN102457580B (zh) * 2010-10-18 2016-06-08 中兴通讯股份有限公司 Nat穿越方法及系统
CN102469172B (zh) * 2010-11-15 2015-08-19 华为终端有限公司 一种数据传输方法、相关装置及其系统
JP2012209880A (ja) * 2011-03-30 2012-10-25 Sony Corp 通信装置及び通信システム
US20120294159A1 (en) * 2011-05-17 2012-11-22 General Instrument Corporation Method of measuring activity over a voip call
CN103457663B (zh) * 2012-06-01 2018-08-28 中兴通讯股份有限公司 路径建立方法及装置
US20150281091A1 (en) * 2012-10-15 2015-10-01 Nec Corporation Control apparatus, node, communication system, communication method, and program
US8601144B1 (en) * 2012-11-27 2013-12-03 Sansay, Inc. Systems and methods for automatic ICE relay candidate creation
CN103906037A (zh) * 2012-12-25 2014-07-02 中兴通讯股份有限公司 采用端口控制协议完成网络地址转换保活的方法及设备
US9668166B2 (en) * 2013-02-05 2017-05-30 Qualcomm Incorporated Quality of service for web client based sessions
US9667595B2 (en) * 2013-07-24 2017-05-30 Cisco Technology, Inc. Selectively using network address translated mapped addresses based on their prior network reachability
CN104703049A (zh) * 2013-12-09 2015-06-10 中兴通讯股份有限公司 媒体流报文的nat穿越方法、mdu及iptv系统
EP3103236B1 (de) * 2014-02-04 2019-05-01 Sony Corporation Medien-stream von einem sender, der auf der empfängerseite vor der bestätigung des empfangs des medien-streams gesehen wird
CN106713063B (zh) * 2015-11-18 2019-09-06 德科仕通信(上海)有限公司 VoIP网络丢包故障检测的方法
CN107241453B (zh) * 2016-03-28 2020-07-24 华为技术有限公司 一种网络地址转换映射保活方法及装置
CN110858810B (zh) * 2018-08-24 2021-07-30 中国移动通信集团四川有限公司 网络链路状态监测方法、设备、系统及介质
US10805361B2 (en) 2018-12-21 2020-10-13 Sansay, Inc. Communication session preservation in geographically redundant cloud-based systems
CN116566858B (zh) * 2023-04-13 2025-10-03 杭州华橙软件技术有限公司 连通性检测方法及装置
CN118945146B (zh) * 2024-07-11 2025-11-18 中移（杭州）信息技术有限公司 呼叫方法、装置、设备、介质及产品

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998059504A1 (en) 1997-06-20 1998-12-30 Telefonaktiebolaget Lm Ericsson Method and apparatus for providing advice of charge parameters for mobile radio telephone calls
US20020023143A1 (en) * 2000-04-11 2002-02-21 Stephenson Mark M. System and method for projecting content beyond firewalls
US20020083175A1 (en) * 2000-10-17 2002-06-27 Wanwall, Inc. (A Delaware Corporation) Methods and apparatus for protecting against overload conditions on nodes of a distributed network
WO2002103981A2 (en) 2001-06-14 2002-12-27 Nortel Networks Limited Providing telephony services to terminals behind a firewall and/or network address translator
CN1474538A (zh) 2002-08-09 2004-02-11 华为技术有限公司 基于初始会话协议的网络终端实现计费通知的方法
CN1516409A (zh) 2003-08-26 2004-07-28 中兴通讯股份有限公司 一种使媒体流穿越网络地址转换器的方法
US20040246958A1 (en) 2003-06-05 2004-12-09 Samsung Electronics Co., Ltd. Apparatus and mehtod for selecting one among multiple internet service providers and routing using the selected one
CN1633102A (zh) 2003-12-24 2005-06-29 华为技术有限公司 实现网络地址转换穿越的方法及其系统
US20060146870A1 (en) * 2004-12-30 2006-07-06 Harvey George A Transparent communication with IPv4 private address spaces using IPv6
US7146410B1 (en) * 2000-06-07 2006-12-05 Nortel Networks Limited System and method for executing control protocols among nodes in separate IP networks
US20080022014A1 (en) * 2002-08-08 2008-01-24 Peters Robert Y Jr System and method for providing multi-media services to communication devices over a communications network
US20090129398A1 (en) * 2003-12-22 2009-05-21 Riegel Jane A Stackable routers employing a routing protocol

Patent Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1267432A (zh) 1997-06-20 2000-09-20 艾利森电话股份有限公司 提供移动无线电话呼叫计费通知参数的方法和设备
WO1998059504A1 (en) 1997-06-20 1998-12-30 Telefonaktiebolaget Lm Ericsson Method and apparatus for providing advice of charge parameters for mobile radio telephone calls
US20020023143A1 (en) * 2000-04-11 2002-02-21 Stephenson Mark M. System and method for projecting content beyond firewalls
US7146410B1 (en) * 2000-06-07 2006-12-05 Nortel Networks Limited System and method for executing control protocols among nodes in separate IP networks
US20020083175A1 (en) * 2000-10-17 2002-06-27 Wanwall, Inc. (A Delaware Corporation) Methods and apparatus for protecting against overload conditions on nodes of a distributed network
US20070094412A1 (en) 2001-06-14 2007-04-26 Nortel Networks Limited Providing telephony services to terminals behind a firewall and/or a network address translator
US20030009561A1 (en) 2001-06-14 2003-01-09 Sollee Patrick N. Providing telephony services to terminals behind a firewall and /or network address translator
WO2002103981A2 (en) 2001-06-14 2002-12-27 Nortel Networks Limited Providing telephony services to terminals behind a firewall and/or network address translator
US20070192508A1 (en) 2001-06-14 2007-08-16 Nortel Networks Limited Providing network address translation information
EP1921823A1 (de) 2001-06-14 2008-05-14 Nortel Networks Limited Einrichtung von Telefoniediensten für Endgeräte hinter einer Firewall und/oder einem Netzwerkadressenübersetzer
US20080022014A1 (en) * 2002-08-08 2008-01-24 Peters Robert Y Jr System and method for providing multi-media services to communication devices over a communications network
CN1474538A (zh) 2002-08-09 2004-02-11 华为技术有限公司 基于初始会话协议的网络终端实现计费通知的方法
US20040246958A1 (en) 2003-06-05 2004-12-09 Samsung Electronics Co., Ltd. Apparatus and mehtod for selecting one among multiple internet service providers and routing using the selected one
CN1516409A (zh) 2003-08-26 2004-07-28 中兴通讯股份有限公司 一种使媒体流穿越网络地址转换器的方法
US20090129398A1 (en) * 2003-12-22 2009-05-21 Riegel Jane A Stackable routers employing a routing protocol
CN1633102A (zh) 2003-12-24 2005-06-29 华为技术有限公司 实现网络地址转换穿越的方法及其系统
US20070217407A1 (en) 2003-12-24 2007-09-20 Huawei Technologies Co., Ltd. Method and System for Implementing Traversal Through Network Address Translation
US20060146870A1 (en) * 2004-12-30 2006-07-06 Harvey George A Transparent communication with IPv4 private address spaces using IPv6

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
"Gateway Control Protocol: IP NAPT traversal package-Series H Audiovisual and Multimedia Systems-Infrastructure of audiovisual services-Communication procedures," Sep. 2005, International Telecommunication Union, Geneva, Switzerland.
Office action in corresponding Russian Patent Application No. 2009107159/09(009574), dated Jun. 29, 2010, from the Russian Patent Office, Moscow.
Rosenberg et al., "SIP Traversal Through Residential and Enterprise NATs and Firewalls," Internet Engineering Task Force (IETF), Internet Draft: 1-22 (Mar. 2, 2001) http://draft-rosenberg-sip-entfw-01.txt.
State Intellectual Property Office of the People's Republic of China, Examination Report in Chinese Patent Application No. 200710000300X (Apr. 3, 2009).
State Intellectual Property Office of the People's Republic of China, Examination Report in Chinese Patent Application No. 200710000300X (Mar. 11, 2010).
State Intellectual Property Office of the People's Republic of China, International Preliminary Report on Patentability & Written Opinion of the International Searching Authority in International Patent Application No. PCT/CN2007/070372 (Feb. 3, 2009 and Nov. 1, 2007).
State Intellectual Property Office of the People'S Republic of China, Written Opinion of the International Searching Authority in Application No. PCT/CN2007/070331 (Oct. 19, 2007).

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090187644A1 (en) * 2008-01-22 2009-07-23 Fujitsu Limited Address distribution system and method and program for the same
US8335840B2 (en) * 2008-01-22 2012-12-18 Fujitsu Limited Address distribution system and method and program for the same
US9596272B2 (en) 2014-09-25 2017-03-14 Microsoft Technology Licensing, Llc Media session between network endpoints
US10171511B2 (en) 2014-09-25 2019-01-01 Microsoft Technology Licensing, Llc Media session between network endpoints
US10244003B2 (en) 2014-09-25 2019-03-26 Microsoft Technology Licensing, Llc Media session between network endpoints
US10079863B2 (en) 2015-11-18 2018-09-18 Microsoft Technology Licensing, Llc Media session between network endpoints
US10158679B2 (en) 2015-11-18 2018-12-18 Microsoft Technology Licensing, Llc Media session between network endpoints

Also Published As

Publication number Publication date
US20090135842A1 (en) 2009-05-28
EP2048832A1 (de) 2009-04-15
DE602007013246D1 (de) 2011-04-28
EP2048832B1 (de) 2011-03-16
CN101119299A (zh) 2008-02-06
ATE502465T1 (de) 2011-04-15
WO2008017265A1 (en) 2008-02-14
EP2048832A4 (de) 2010-03-03

Similar Documents

Publication Publication Date Title
EP2048832B1 (de) Verfahren und system zur verbindung eines medienstroms
EP2034666B1 (de) Verfahren und system zum realisieren von medienstrom-wechselwirkung und medien-gateway-steuerung und medien-gateway
EP2117190B1 (de) Verfahren, system und vorrichtung zur weiterleitung von netzwerkadressen-übersetzungen
US7406043B1 (en) Method for providing voice-over-IP service
AU2005201075B2 (en) Apparatus and method for voice processing of voice over internet protocol (VOIP)
CA2751605A1 (en) Scalable nat traversal
US20050286538A1 (en) Method and call server for establishing a bi-directional peer-to-peer communication link
CN100403729C (zh) Sip软交换系统中呼叫控制与媒体流穿越私网的方法
EP2391078B1 (de) Medien-Gateway und Paketfiltrierungsverfahren dafür
US8374178B2 (en) Apparatus and method for supporting NAT traversal in voice over internet protocol system
US8194686B2 (en) Communications relay device, program and method, and network system
US9906489B2 (en) Method, system and device for implementing interconnection between IP domains
CN101114985B (zh) 编解码转换系统及方法
CN101471965A (zh) 本地传输地址分配方法、媒体网关及媒体网关控制器
CN102325086A (zh) 导通媒体流的方法、导通检测方法及其系统
ES2976482T3 (es) Método para realizar sesiones de comunicación de voz sobre IP entre una parte llamante y una parte llamada, red de telecomunicaciones, entidad de red de ruta de reenvío de transporte o entidad o funcionalidad de función de control de estado de llamada proxy o entidad o funcionalidad de red definida por software, programa y medio legible por ordenador
US20080165782A1 (en) Method for Data Interchange Between Network Elements
CN100574254C (zh) 穿越网络地址转换装置的处理方法及通话启始协议服务器

Legal Events

Date Code Title Description
AS Assignment

Owner name: HUAWEI TECHNOLOGIES CO., LTD., CHINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZHU, NING;REEL/FRAME:022176/0072

Effective date: 20090109

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552)

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12