+

WO2002011389A2 - Echange de donnees par ordinateurs dans un reseau protege - Google Patents

Echange de donnees par ordinateurs dans un reseau protege Download PDF

Info

Publication number
WO2002011389A2
WO2002011389A2 PCT/US2001/022312 US0122312W WO0211389A2 WO 2002011389 A2 WO2002011389 A2 WO 2002011389A2 US 0122312 W US0122312 W US 0122312W WO 0211389 A2 WO0211389 A2 WO 0211389A2
Authority
WO
WIPO (PCT)
Prior art keywords
computer
protocol
data
rtp
reflector
Prior art date
Application number
PCT/US2001/022312
Other languages
English (en)
Other versions
WO2002011389A3 (fr
Inventor
Wongyu Cho
Hyungkeun Hong
Original Assignee
Dialpad Communications, Inc.
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 Dialpad Communications, Inc. filed Critical Dialpad Communications, Inc.
Priority to AU2001273489A priority Critical patent/AU2001273489A1/en
Publication of WO2002011389A2 publication Critical patent/WO2002011389A2/fr
Publication of WO2002011389A3 publication Critical patent/WO2002011389A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • 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/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • 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
    • H04L65/104—Signalling gateways in the network
    • 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/08—Protocols for interworking; Protocol conversion
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0078—Security; Fraud detection; Fraud prevention

Definitions

  • This invention generally relates to computer networks and more particularly to methods and associated apparatus for exchanging data with computers within a secure network .
  • VoIP Voice Over Internet Protocol
  • IP Internet Protocol
  • FIG. 1A shows a schematic diagram of an exemplary VoIP network.
  • a local user using a computer 11 equipped with a sound card and headset provides voice data to an Internet Telephone Service Provider (ITSP) gateway 12 over the Internet .
  • ITSP gateways are available from several network service providers including the IDT Corporation and Qwest Communications.
  • ITSP gateway 12 is coupled to a remote user who, in this example, uses a regular telephone 14 linked to a public switched telephone network (PSTN) 13.
  • PSTN 13 provides either wireline or wireless telephone service commonly known as "plain old telephone service" (POTS) .
  • POTS plain old telephone service
  • ITSP gateway 12 converts the voice data from computer 11 into corresponding voice signals for transmission to telephone 14 through PSTN 13.
  • POTS plain old telephone service
  • FIG. IB schematically illustrates a network wherein computer 11 is located behind a firewall 15.
  • Firewalls are well known network components for screening incoming data to a secure network. Data that use a connection created by computers behind firewall 15 are able to pass through firewall 15.
  • a connection is a communications link between two application programs (e.g., programs running on separate computers) on a network. The connection is identified by the IP addresses and port numbers of the two connected application programs. The IP address identifies the computer on which an application program runs while the port number identifies the application program in the computer.
  • ITSP gateway 12 can send data to computer 11 using the same connection (unless of course firewall 15 is specifically configured to block any data from ITSP gateway 12) .
  • computers outside firewall 15 cannot arbitrarily create a connection through firewall 15. Thus, unless ITSP gateway 12 uses a connection originated from behind firewall 15, voice signals from telephone 14 will not reach computer 11.
  • RTP Real-Time Transport Protocol
  • UDP User Datagram Protocol
  • the present invention relates to a method and associated apparatus for exchanging data with computers within a secure network.
  • a first computer transmits data to a second computer in accordance with a first protocol.
  • the second computer receives the data and transmits them to a third computer, which is within a secure network, using a second protocol that is different from the first protocol .
  • the data is transmitted to the third computer over a connection originated from within the secure network, thereby allowing the data to pass through network security devices such as firewalls.
  • the first protocol is the User Datagram Protocol (UDP) and the second protocol is the Transport Control Protocol (TCP) .
  • FIG. 1A shows a schematic diagram of a network in the prior art .
  • FIG. IB shows a schematic diagram of a network in the prior art which includes a firewall.
  • FIG. 2 shows a schematic diagram of a network in accordance with an embodiment of the invention.
  • FIG. 3 shows a method for transmitting data to a computer within a secure network in one embodiment .
  • FIG. 4 shows a method for transmitting data to a computer within a secure network in another embodiment .
  • FIGS. 5A, 5B, and 5C show schematic representations of TCP packets in one embodiment .
  • FIG..6 shows a flow diagram of a VoIP telephone call in one embodiment .
  • FIG. 7 shows a schematic representation of software processes for transmitting data to a computer within a secure network in one embodiment .
  • FIG. 2 shows a schematic diagram of a network 20 wherein a reflector 21 application program, running on a computer acting as a server, is utilized to allow data transmission through firewall 15. While reflector 21 can be resident on any computer in network 20 that is outside firewall 15, reflector 21 is preferably on a separate high performance computer located close to ITSP gateway 12 to minimize data transmission delay and possible data loss.
  • Network 20 includes a VoIP server 22 for setting up a VoIP telephone call between the user on computer 11 and the user on telephone 14.
  • Reflector 21 can be employed independent of VoIP server 22, and can be generally used to exchange data with computers behind firewalls.
  • VoIP telephone call and files containing information about network 20 can be downloaded from a web server 35 (e.g., a website) .
  • Web server 35 can be a conventional file server or any of the VoIP portals accessible over the Internet such as those from Dialpad.com, Inc. of Santa Clara,
  • Network 20 also includes a firewall-detect server 36 which, as discussed further below, enables a client program running on computer 11 to detect whether it is behind a firewall. It is to be noted that client- server architectures, in general, are well known.
  • VoIP server 22, ITSP gateway 12, web server 35, and the client program running on computer 11 can also be of the same type as the scaleable communications system disclosed in U.S. Patent Application No. 09/401,898, "Scaleable Communications System,” filed on September 24, 1999, incorporated herein by reference in its entirety.
  • Reflector 21 can also be used with VoIP systems and services accessible over the Internet such as those from Dialpad.Com, Inc.
  • FIG. 3 shows a method for transmitting data to a computer within a secure network in one embodiment .
  • multimedia data e.g., voice, video, still images, and/or fax
  • a source server such' as ITSP gateway 12
  • reflector 21 receives the first protocol packets from the source server (action 31) , extracts the multimedia data from the first protocol packets, and encapsulates the multimedia data in accordance with a second protocol (action 32) .
  • the multimedia data are formatted in accordance with RTP and the first protocol is UDP.
  • Reflector 21 transmits the second protocol packets to an application (e.g., client program) behind the firewall (action 33), where the multimedia data are extracted (action 34) .
  • the second protocol is the .Transport Control Protocol (TCP) .
  • TCP Transmissionport Control Protocol
  • TCP a connection-oriented protocol, transports data using a pre-established connection between two application programs.
  • reflector 21 can transmit data to an application program behind the firewall by utilizing a TCP connection originated from within the secure network.
  • TCP in general, is well known; e.g., see the incorporated reference "TCP/IP Illustrated Volume 1", W. R. Stevens, Addison Wesley 1994.
  • TCP/IP software commonly known as TCP/IP protocol stack, is also commercially available from several vendors including Sun Microsystems .
  • FIG. 4 shows a method for transmitting voice data from ITSP gateway 12 to computer 11 of network 20 (FIG. 2) in one embodiment.
  • a client program running on computer 11 transmits a UDP packet to firewall-detect server 36 located outside firewall 15.
  • Firewall-detect server 36 is a server that waits for a UDP packet from the client program and correspondingly replies with another UDP packet.
  • the UDP packets transmitted to and from firewall-detect server 36 are intended to determine whether the client program runs on a computer behind a firewall.
  • the client program waits for a reply from firewall-detect server 36.
  • the client program receives a reply from firewall-detect server 36, the client program is not behind a firewall and reflector 21 is therefore not required (action 41) . In this example, however, the client program is behind firewall 15, which blocks the reply from firewall-detect server 36. After failing to receive a reply from firewall-detect server 36 within a predetermined amount of time, the client program concludes that it must be behind a firewall and accordingly creates a conventional TCP connection to reflector 21 (action 42) . Any protocol suitable for transmission through a firewall, such as those that utilize a pre-established connection, can be used instead of TCP.
  • the IP address of reflector 21 can be hard-coded in the client program or downloaded from web server 35.
  • reflector 21 provides an RTP port number to the client program. This RTP port number along with reflector 21' s IP address, as explained below, will eventually be provided to ITSP gateway 12 so that RTP data can be transmitted from ITSP gateway 12 to reflector 21.
  • the IP address and RTP port number of reflector 21 for receiving RTP data from ITSP gateway 12 are collectively referred to as reflector 21' s RTP transport address.
  • the client program provides reflector 21' s RTP transport address to VoIP server 22, and obtains from VoIP server 22 the transport address of ITSP gateway 12.
  • the transport address of ITSP gateway 12 consists of the IP address and RTP port number that ITSP gateway uses to receive RTP data from reflector 21.
  • the client program provides reflector 21 the RTP transport address of ITSP gateway 12. This allows reflector 21 to transmit the RTP data it receives from the client program to ITSP gateway 12.
  • VoIP server 22 provides the RTP transport address of reflector 21 to ITSP gateway 12.
  • Action 46 typically occurs during the time the VoIP telephone call between computer 11 and telephone 14 is being setup by VoIP server 22 and ITSP gateway 12 in accordance with the International Telecommunication Union (ITU) H.323 standard and associated protocols.
  • ITU H.323 is well known; e.g., see ITU-T Recommendation Q.931, ITU-T Recommendation H.245, and ITU-T Recommendation H.323, all incorporated herein by reference .
  • ITSP gateway 12 creates RTP data channels to and from reflector 21 in accordance with ITU H.323. Note that both ITSP gateway 12 and reflector 21 know each other's RTP transport address and can thus exchange RTP data over the RTP data channels.
  • ITSP gateway 12 formats the voice signals from telephone 14 in accordance with RTP (hereinafter "RTP data"), encapsulates the RTP data in UDP packets, and transmits the UDP packets over the RTP data channel from ITSP gateway 12 to reflector 21 (action 48) .
  • RTP data The flow of RTP data between ITSP gateway 12 and reflector 21 over the RTP data channels is also known as an RTP data stream.
  • FIG. 5A shows a schematic representation of a TCP packet 61 suitable for transmission from reflector 21 to the client program in one example.
  • TCP packet 61 is a conventional TCP packet containing the ASCII characters "R", "T", "P”, “D”, "A", "T", and "A” in the first 7 bytes of its data section.
  • a byte 62 indicates the size of the following RTP data.
  • An ASCII character " ⁇ r" (backslash-r) follows byte 62.
  • the first 10 bytes of the data section of TCP packet 61 informs the client program that TCP packet 61 contains RTP data and that the bytes following ASCII character " ⁇ r" are RTP data having a size indicated in byte 62.
  • reflector 21 transmits the TCP packets containing RTP data to the client program in computer 11 over the TCP connection previously established in action 42. Because that TCP connection was created by the client program, which is in the secure network, reflector 21 is able to transmit the TCP packets through firewall 15.
  • the client program extracts the RTP data from the TCP packets. Thereafter, the client program processes the RTP data by playing the corresponding voice information from telephone 14 (action 52) .
  • the transmission of RTP data from computer 11 to telephone 14 is performed using a process similar to that shown in FIG. 4 except in the opposite direction.
  • the client program formats the voice of the local user in accordance with RTP and encapsulates the resulting RTP data in TCP packets, which are then transmitted to reflector 21 using the TCP connection previously established in action 42.
  • FIGS. 5B and 5C show a schematic representation of TCP packets 63 and 65 suitable for transmission from the client program to reflector 21 in one example.
  • TCP packet 63 is a conventional TCP packet with the ASCII characters "R”, “T”, “ P” , “D”, “A”, “T”, “A”, and "SPACE” (i.e., a space bar character) in the first 8 bytes of its data section.
  • TCP packet 63 informs reflector 21 that another TCP packet, TCP packet 65, containing the actual RTP data will be transmitted from the client program.
  • a byte 64 of TCP packet 63 indicates the size of the RTP data in TCP packet 65. In TCP packet 63, there are no relevant data following the " ⁇ r" character.
  • TCP packet 65 is transmitted from the client program in computer 11 to reflector 21 following the transmission of TCP packet 63.
  • Reflector 21 extracts the RTP data from received TCP packets 65 and encapsulates the RTP data in UDP packets for transmission over the RTP data channel from reflector 21 to ITSP gateway 12.
  • ITSP gateway 12 then extracts the RTP data from the UDP packets and relays the voice information to telephone 14.
  • Voice data from computer 11 can also be directly transmitted to ITSP gateway 12 because computer 11 is behind firewall 15, and thus can create another connection through firewall 15 onto ITSP gateway 12.
  • the client program formats the user' s voice in accordance with RTP and encapsulates the resulting RTP data in UDP packets.
  • the client program directly transmits the UDP packets to ITSP gateway 12 without going through reflector 21.
  • ITSP gateway 12 extracts the RTP data from the UDP packets and relays the voice information to telephone 14.
  • FIG. 6 shows a flow diagram of an exemplary VoIP telephone call between computer 11 and telephone 14 in network 20 (FIG. 2) .
  • the client program on computer 11 transmits a UDP packet to firewall-detect server 36 to determine if computer 11 is behind a firewall. All communications between the client program and firewall-detect server 36 are over an arbitrary UDP connection. Because computer 11 is behind firewall 15 in this example, the client program will not receive a response from firewall-detect server 36.
  • the client program thus makes a TCP connection, hereinafter referred to as TCP connection "A", to reflector 21. All communications between the client program and reflector 21 are over TCP connection "A" . Also during flow 70, reflector 21 provides its RTP transport address to the client program.
  • the client program makes a separate TCP connection, hereinafter referred to as TCP connection "B", to VoIP server 22 and informs VoIP server 22 that it wants to make a VoIP telephone call to telephone 14. All communications between the client program and VoIP server 22 are over TCP connection "B".
  • the client program also provides reflector 21' s RTP transport address to VoIP server 22.
  • VoIP server 22 informs the client program that the VoIP telephone call is proceeding.
  • VoIP server 22 setups the VoIP telephone call with ITSP gateway 12 in accordance with the ITU H.323 standard. All communications between VoIP server 22 and ITSP gateway 12 are over a separate TCP connection hereinafter referred to as TCP connection "C".
  • ITSP gateway 12 makes a call to telephone 14 via PSTN 13 (FIG. 2) and receives a ring signal.
  • ITSP gateway 12 informs VoIP server 22 that telephone 14 has been contacted.
  • VoIP server 22 receives the RTP transport address of ITSP gateway 12 at this time.
  • VoIP server 22 relays the information to the client program, which now knows that the telephone 14 is ringing and can be picked-up by the remote user at any time. Also in flow 76, the client program receives the RTP transport address of ITSP gateway 12 from VoIP server 22.
  • ITSP gateway 12 informs VoIP server 22 that telephone 14 has been picked-up by the remote user and that it will start transmitting RTP data to reflector 21 (using reflector 21' s RTP transport address) over an RTP data channel .
  • RTP data channels There are two RTP data channels in this example, which are an RTP data channel from ITSP gateway 12 to reflector 21 and another RTP data channel from reflector 21 to ITSP gateway 12.
  • VoIP server 22 informs the client program that telephone 14 has been picked up and that the client program can now send and receive RTP data via reflector 21.
  • the client program reports its status (including error conditions and whether it is still making the VoIP telephone call) to VoIP server 22.
  • Flow 79 is periodically performed while' the VoIP telephone call is in progress.
  • VoIP server 22 will terminate an in progress VoIP telephone call if VoIP server 22 ceases to receive a status from the client program.
  • the client program informs reflector 21 that the remote user has picked-up telephone 14 and that reflector 21 should expect to receive RTP data over the RTP data channel from ITSP gateway 12. Also in flow 80, reflector 21 receives the RTP transport address of ITSP gateway 12 from the client program. This allows reflector 21 to send RTP data over the RTP data channel to ITSP gateway 12.
  • RTP data representing voice information are transported between reflector 21 and ITSP gateway 12 using UDP packets over the RTP data channels.
  • the RTP data are transported between reflector 21 and the client program using TCP packets over TCP connection "A" .
  • DTMF touch tone signals if any, are transmitted from the client program to VoIP server 22.
  • the DTMF touch tone signals are then relayed by VoIP server 22 to ITSP gateway 12 over TCP connection "C" (not shown) .
  • the client program informs reflector 21 that the user on computer 11 decides to terminate the VoIP telephone call.
  • the client program also informs VoIP server 22 that the VoIP telephone call is being terminated.
  • VoIP server 22 accordingly informs ITSP gateway 12 to close the RTP data channels between ITSP gateway 12 and reflector 21.
  • ITSP gateway 12 informs VoIP server 22 that the RTP data channels have been closed.
  • VoIP server 22 informs the client program that the VoIP telephone call has been terminated.
  • the sequence of events in the flow diagram of FIG. 6 can be re-arranged without detracting from the merits of the invention.
  • the RTP transport address of ITSP gateway 12 can be provided to reflector 21 at any time before flow 82, and not necessarily during flow 80 when the client program provides its status to reflector 21.
  • reflector 21 is written in the "C" programming language and runs on a SPARCTM Station computer with the SolarisTM operating system, both of which are available from Sun Microsystems.
  • SPARCTM Station computer with the SolarisTM operating system, both of which are available from Sun Microsystems.
  • SolarisTM operating system both of which are available from Sun Microsystems.
  • other programming languages, computers, and operating systems can also be used.
  • FIG. 7 shows a schematic representation of the relevant reflector 21 processes and their relationship with ITSP gateway 12 and the client program on computer 11.
  • Tables 1 and 2 which show pseudo-codes FWMAIN.C and FWGATE.C, are discussed with reference to FIG. 7.
  • RunFWGServer ( ) Create socket pairs for communication between child and parent processes
  • ThreadProcToCli ( ) //Thread- 2 While ( ) ⁇ Receive UDP packets from the ITSP gateway; Extract the RTP data from the UDP packets received from the ITSP gateway; Encapsulate the RTP data in TCP packets; Send the TCP packets to the Client;
  • FWMAIN.C includes the pseudo-code for the parent process illustrated in FIG. 7. As shown in Table 1, the parent process creates multiple child processes, with each child process communicating with the parent process using a socket pair provided by the operating system via a system call. A socket pair is a communications link between two processes running on the same computer. In one example, the parent process creates ten child processes. The parent process then waits for the client program to establish a TCP connection to reflector 21. Once a TCP connection is established, the parent process assigns the processing of the connection to one of the child processes.
  • FWGATE.C includes the pseudo code for the child processes, thread-1, and thread-2 illustrated in FIG. 7. As shown in Table 2, each child process creates a thread pair, which are thread-1 and thread-2, upon notification from the parent process that a TCP connection from the client program has been established. A thread pair is created for each TCP connection between a client program and reflector 21. In one example, each child process supports up to 500 thread pairs. By allocating tasks to child processes and threads, reflector 21 can efficiently process multiple TCP connections.
  • ThreadProcR thread-1 allocates an RTP port number and sends it to the client program. Thread-1 then waits for the client program to provide the IP address and RTP port number of ITSP gateway 12, for the establishment of an RTP data channel between reflector 21 and ITSP gateway 12, and for notification that the client program is ready to accept RTP data.
  • Thread-1 receives TCP packets from the client program, extracts the RTP data from received TCP packets, encapsulates the RTP data in UDP packets, and transmits the UDP packets to ITSP gateway 12.
  • ThreadProcToCli receives UDP packets from ITSP gateway 12, extracts the RTP data from the received UDP packets, encapsulates the RTP data in TCP packets, and transmits the TCP packets to the client program.
  • TCP/IP operations are generally transparent to the applications programmer because the processing of packets (including data extraction, encapsulation, transmission, and reception) are performed by the TCP/IP protocol stack via library calls .
  • a method and apparatus for exchanging data with computers in a secure network have been disclosed. While specific embodiments of this invention have been described, it is to be understood that these embodiments are illustrative and not limiting. Many additional embodiments that are within the broad principles of this invention will be apparent to persons skilled in the art.
  • the invention can be used to transmit any type of data, not just voice data, to computers within a secure network. Further, the invention is applicable to any type of network, including those not linked to the Internet .

Landscapes

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

Abstract

Selon le procédé de l'invention, un premier ordinateur transmet des données à un deuxième ordinateur conformément à un premier protocole. Le deuxième ordinateur reçoit les données et les transmet à un troisième ordinateur intégré à un réseau protégé, au moyen d'un deuxième protocole différent du premier protocole. Les données sont transmises à un troisième ordinateur sur une connexion qui prend sa source dans le réseau protégé, ce qui permet aux données de passer par des dispositifs de sécurité de réseau, tels que des pares-feu.
PCT/US2001/022312 2000-07-28 2001-07-16 Echange de donnees par ordinateurs dans un reseau protege WO2002011389A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001273489A AU2001273489A1 (en) 2000-07-28 2001-07-16 Data exchange with computers within a secure network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US62772300A 2000-07-28 2000-07-28
US09/627,723 2000-07-28

Publications (2)

Publication Number Publication Date
WO2002011389A2 true WO2002011389A2 (fr) 2002-02-07
WO2002011389A3 WO2002011389A3 (fr) 2002-05-23

Family

ID=24515862

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/022312 WO2002011389A2 (fr) 2000-07-28 2001-07-16 Echange de donnees par ordinateurs dans un reseau protege

Country Status (3)

Country Link
AU (1) AU2001273489A1 (fr)
TW (1) TW573416B (fr)
WO (1) WO2002011389A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1482701A1 (fr) * 2003-05-27 2004-12-01 Siemens Aktiengesellschaft Procédé pour la transmission des données par paquets dans un réseau de télécommunication par la conversion dans un noeud mandataire d'un protocole de transport sans connection dans un protocole de transport orienté connection et vice-versa
EP1513315A1 (fr) 2003-09-05 2005-03-09 Paradial AS Communication en temps réel à travers des pare-feux
GB2371726B (en) * 2001-01-27 2005-08-17 Mitel Corp Transport protocols for application platforms over network portals

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5550984A (en) * 1994-12-07 1996-08-27 Matsushita Electric Corporation Of America Security system for preventing unauthorized communications between networks by translating communications received in ip protocol to non-ip protocol to remove address and routing services information
EP0858201A3 (fr) * 1997-02-06 1999-01-13 Sun Microsystems, Inc. Procédé et dispositif pour permetre des transactions sécurisées à travers un firewall
US6075796A (en) * 1997-03-17 2000-06-13 At&T Methods and apparatus for providing improved quality of packet transmission in applications such as internet telephony

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2371726B (en) * 2001-01-27 2005-08-17 Mitel Corp Transport protocols for application platforms over network portals
US7068670B2 (en) 2001-01-27 2006-06-27 Mitel Networks Corporation Transport protocols for application platforms over network portals
EP1482701A1 (fr) * 2003-05-27 2004-12-01 Siemens Aktiengesellschaft Procédé pour la transmission des données par paquets dans un réseau de télécommunication par la conversion dans un noeud mandataire d'un protocole de transport sans connection dans un protocole de transport orienté connection et vice-versa
US7646787B2 (en) 2003-05-27 2010-01-12 Siemens Aktiengesellschaft Method for the packet-oriented transmission of data, network intermediate nodes and telecommunications network
EP1513315A1 (fr) 2003-09-05 2005-03-09 Paradial AS Communication en temps réel à travers des pare-feux
US8230091B2 (en) 2003-09-05 2012-07-24 Lifesize Communications, Inc. System and method for real-time bidirectional communication through firewalls

Also Published As

Publication number Publication date
TW573416B (en) 2004-01-21
AU2001273489A1 (en) 2002-02-13
WO2002011389A3 (fr) 2002-05-23

Similar Documents

Publication Publication Date Title
US7173928B2 (en) System and method for establishing channels for a real time streaming media communication system
US6449269B1 (en) Packet voice telephony system and method
US8713302B1 (en) Firewall-tolerant voice-over-internet-protocol (VoIP) emulating SSL or HTTP sessions embedding voice data in cookies
US6928082B2 (en) System and method for determining a connectionless communication path for communicating audio data through an address and port translation device
US7230945B2 (en) Method for sending dual-tone multi-frequency signal using voice over internet protocol
US7836124B2 (en) RTP, UDP, IP header compression on the circuit switched type airlink access
EP1528745B1 (fr) Procédé et dispostif de communication
US20020095599A1 (en) VoIP call control proxy
US7778243B2 (en) Method for DTMF transfer by RTP
US20030210677A1 (en) Host-based device to terminate a modem relay channel directly to an IP network
US20110044453A1 (en) System and method of encrypted media encapsulation
WO2002011389A2 (fr) Echange de donnees par ordinateurs dans un reseau protege
US7543063B1 (en) Device to terminate a modem relay channel directly to an IP network
RU2423013C2 (ru) СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА
EP1568178B1 (fr) Desserveur de relais de modem
JP7359285B2 (ja) 衛星通信システム、地球局装置および回線交換制御方法
Cuervo et al. RFC3015: Megaco Protocol Version 1.0
KR100369809B1 (ko) 브이오아이피를 이용한 이중톤다중주파수 신호 전송방법
KR100957432B1 (ko) 미디어 전송 방법
AU2001100369A4 (en) Voice-on-demand communication system
KR100374035B1 (ko) 보이스 오버 인터넷 프로토콜 시스템에서 톤신호 전송방법
WO2004049657A1 (fr) Dispositif d'emission
Huitema et al. Network Working Group F. Cuervo Request for Comments: 3015 N. Greene Obsoletes: 2885, 2886 A. Rayhan Category: Standards Track Nortel Networks
JP2004511134A (ja) 音声パートとデータパートをもつ情報を伝送する方法および装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载