WO2007121243A9 - System and method for traversing a firewall with multimedia communication - Google Patents

System and method for traversing a firewall with multimedia communication

Info

Publication number
WO2007121243A9
WO2007121243A9 PCT/US2007/066435 US2007066435W WO2007121243A9 WO 2007121243 A9 WO2007121243 A9 WO 2007121243A9 US 2007066435 W US2007066435 W US 2007066435W WO 2007121243 A9 WO2007121243 A9 WO 2007121243A9
Authority
WO
WIPO (PCT)
Prior art keywords
packets
port
protocol
network device
ports
Prior art date
Application number
PCT/US2007/066435
Other languages
French (fr)
Other versions
WO2007121243A3 (en
WO2007121243A2 (en
Inventor
Christopher S Signaoff
Tom W Opsahl
Edward M Riley
Justin S Signaoff
Original Assignee
Directpacket Res Inc
Christopher S Signaoff
Tom W Opsahl
Edward M Riley
Justin S Signaoff
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=38604796&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2007121243(A9) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Directpacket Res Inc, Christopher S Signaoff, Tom W Opsahl, Edward M Riley, Justin S Signaoff filed Critical Directpacket Res Inc
Publication of WO2007121243A2 publication Critical patent/WO2007121243A2/en
Publication of WO2007121243A9 publication Critical patent/WO2007121243A9/en
Publication of WO2007121243A3 publication Critical patent/WO2007121243A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • H04L69/085Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks

Definitions

  • the present invention relates, in general, to electronic communications, and, more specifically, to transmitting communication data within a multimedia communication system.
  • the Internet may be used for many forms of communication, including voice conversations, video conferencing, development collaboration, and the like, hi order for a manufacturers' programs, applications, equipment, and systems to be interoperable with each other, many protocols have been developed to standardize the communication between such systems. These protocols have grown increasingly complex to handle all the types of traffic generated to facilitate communication for video conferencing, voice over Internet Protocol (VoIP), and data over Internet Protocol applications.
  • Two such protocols are H.323 from the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) and the Session Initiation Protocol (SIP) from the Internet Engineering Task Force (IETF). Both H.323 and SIP typically allow for multimedia communication including voice, video, and data communications in real-time.
  • IP Internet Protocol
  • devices or endpoints on the network are identified by their respective EP address.
  • Applications and programs on the different devices further identify each other using port numbers.
  • a port number is a sixteen bit integer, the value of which falls into one of three ranges: the well- known ports, ranging from 0 through 1023; the registered ports, ranging from 1024 through 49151; and the dynamic and/or private ports, ranging from 49152 through 65535.
  • the well-known ports are reserved for assignment by the Internet Corporation for Assigned Names and Numbers (ICANN) for use by applications that communicate using the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) and generally can only be used by a system/root process or by a program run by a privileged user.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • the registered ports may be registered for use by companies or other individuals for use by applications that communicate using TCP or UDP.
  • the dynamic or private ports by definition, cannot be officially registered nor are they assigned. Both the H.323 and SIP standards use multiple, well-known, registered, and/or dynamic ports in order to facilitate such communication.
  • H.323 and SIP each rely on multiple other protocols, some of which may in turn rely on UDP for sending and receiving multimedia traffic.
  • UDP features minimal overhead compared to other transport protocols (most notably TCP) at the expense of having less reliability.
  • UDP does not provide for guaranteed packet delivery nor data integrity.
  • UDP does offer the highest possible throughput, thus, making it ideally suited for multimedia real-time communications.
  • Firewalls are used in modern networks to screen out unwanted or malicious traffic.
  • One of many techniques a firewall may use is packet filtering, wherein the firewall determines whether or not to allow individual packets by analyzing information in the packet header (such as the IP address and port of the source and destination). Thus, various ports or IP addresses may be blocked to minimize the risk of allowing malicious traffic into an important computer network or system.
  • Another more advanced technique is called stateful inspection, wherein in addition to analyzing header information, a firewall keeps track of the status of any connection opened by network devices behind the firewall.
  • firewalls especially those used by large corporations generally only allow traffic from the well-known ports, though such firewalls may be specially configured to allow traffic on any port.
  • firewalls For multimedia communication systems that use multiple registered and dynamic ports, firewalls (unless specially configured) will generally block the data traffic on these ports between multimedia systems, thus, preventing communication.
  • Video conferencing endpoints generally use multiple dynamic ports for the transmission of communication data packets and, as such, each port used necessitates opening that port on a firewall. Additionally, different endpoints participating in different conversations use different sets of ports, further increasing the number of ports to be opened on a firewall. Reconfiguring ports on a firewall is a time consuming task that introduces the risk of human error, which may defeat the purpose of the firewall by leaving a network vulnerable to malicious attacks. Furthermore, even though these dynamic ports should be closed after the communication ends, in practice, once a firewall port is open, it remains open because the firewall technicians typically do not expend the additional time resources to close the ports. [0007] Additionally, many video conferencing systems do not support encryption. In such cases the communication between endpoints is not secure and may be intercepted while being transmitted across the Internet.
  • TANDBERG's BORDER CONTROLLERTM a component of TANDBERG's EXPRESSWAYTM firewall traversal solution, requires the use of TANDBERG Gatekeepers or TANDBERG traversal enabled endpoints. While allowing firewall traversal, the EXPRESSWAYTM solution still requires user intervention to select and trust a range of ports on a firewall and requires the purchase of TANDBERG equipment to use existing legacy video conference endpoints that are not traversal-enabled.
  • the V2IUTM series of products from Polycom, Inc. are Application Level Gateways (ALG) that act as protocol-aware firewalls that automate the selection and trusting of ports, but as such, multiple ports are still used when sending traffic between endpoints with the risk of having such traffic being blocked by a non-protocol-aware firewall. Further, such an ALG does not provide for secure communication.
  • the PATHFINDERTM series of products from RadVision, Ltd. provides for firewall traversal via multiplexing to a single port, but still requires opening a port on a firewall. Multiplexing is implemented by taking sections of data from each of the data streams coming through the various ports and placing them alternately into a single stream. Thus, the resulting stream is simply a train of interleaved data bits that are not recognized as any particular communication protocol.
  • a packet constructor picks each data bit and places it in the appropriate stream on the appropriate port and rebuilds the original stream.
  • the present invention is directed to a system and method for transporting multiport protocol traffic using a single-port protocol that is known to be transmitted on a port that is typically open on standard firewalls.
  • Multiport protocol traffic from a first endpomt is converted in to a single-port protocol for transport across a network.
  • the traffic is then reconverted to the multiport protocol and directed to the appropriate ports at a targeted second endpoint.
  • the traffic may then traverse a firewall by using a well-known port, such that little or no reconfiguration of the firewall is required. In so doing, the risk of human error leaving a network vulnerable to malicious attacks is reduced.
  • the various embodiments of the present invention actually creates a known, single-port communication protocol.
  • FIGURE 1 is a diagram illustrating the flow of packets in a typical IP communication system
  • FIGURE 2 is a diagram illustrating an IP communication system configured according to one embodiment of the present invention.
  • FIGURE 3 is a diagram illustrating an IP communication system configured according to another embodiment of the present invention, which includes encryption;
  • FIGURE 4 is a diagram illustrating the handling of packets.
  • FIGURE 5 is a flowchart showing for an embodiment of the invention, example steps that may be employed to traverse a firewall.
  • a variety of protocols require the use of multiport traffic. Whether the traffic is data between applications, voice communications, or video conferencing, whenever multiport traffic is used there is a possibility of some or all of the traffic being blocked by a firewall between two devices that are attempting to communicate.
  • video conferencing systems whether they are based on H.323, SIP, or other similar multimedia communication protocols, use multiple ports and multiple protocols in order to enable two-way audio and video communication.
  • the communication protocols specify different types of traffic that may be sent between endpoints which include media traffic (voice, video, and the like) along with the control traffic (camera, connection control, and the like).
  • the media traffic is comprised of data for the images and sound being transmitted between endpoints with the control traffic comprising data used to control the connection between endpoints and the features of the endpoint (e.g., camera direction, zoom, and the like).
  • UDP may typically be utilized for the real-time communication traffic between endpoints.
  • TCP may be utilized for traffic requiring data integrity (e.g., control traffic).
  • video conferencing systems typically make use of both TCP and UDP to transport the multimedia data to enable communication.
  • the ports that are typically used to enable the two-way communication include various ports across the well-known ports, the registered ports, and the dynamic ports. Firewalls are usually set up to block unrequested traffic and/or traffic coming in on dynamic ports.
  • UDP does not provide a mechanism for identifying received traffic as requested traffic.
  • programs and endpoints that send traffic conforming to UDP are at risk of having that traffic blocked by the remote endpoint's firewall for both being unrequested and being sent on a blocked port.
  • video conference endpoint 10 attempts to send multimedia data to video conference endpoint 15.
  • Multiport packets 100 sent from well-known port 1010, registered port 7030, and dynamic ports 50148-50153 are being transmitted to video conference endpoint 15.
  • Firewall 12 passes all the outgoing traffic (packets 100) on all ports since this traffic has originated from the network inside of firewall 12. The traffic is transmitted across Internet 16 and is received by firewall 13, which is operating in a standard mode. In the standard mode, firewall 13 blocks dynamic ports and unrequested traffic (packets 101), such that only the TCP traffic (packets 102) on well-known port 1010 is received by endpoint 15. Thus, with each endpoint being behind their respective firewalls, neither two-way nor one-way communication can take place.
  • endpoint 10 again attempts to send multimedia data (packets 100) to video conference endpoint 15, this time with network devices 21 and 24 in the system, hi this embodiment, endpoint 10 is a video conference endpoint that uses a multiple port communication protocol in order to establish communication with endpoint 15.
  • endpoint 10 uses ports 1010, 7030, 50148-50153.
  • the data transmitted using ports 1010 and 50149-50150 utilize TCP as the transport protocol while the data transmitted using ports 7030, 50148, and 50151-50153 utilize UDP as the transport protocol. Packets from each of these ports conforming to these various protocols and sub-protocols are received by network device 21.
  • endpoints may use more or fewer ports of different numbers based in part on the applications or protocols used to facilitate multimedia communication.
  • the received packets are encapsulated to conform to a protocol used by devices 21 and 24 for transmitting data, which may include, but is not limited to: TCP, UDP, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), Real-time Transport Protocol (RTP), and the like.
  • Device 21 receives packets 100 from endpoint 10 that conform to both TCP and UDP, encapsulates each of multiport packets 100 into single-port packets 200 that conform to a single-port communication protocol used by devices 21 and 24, and sends packets 200 to device 24.
  • the method of encapsulation may comprise using some or all of the information (header and data) within each of packets 100 as the data section for encapsulated packets 200.
  • the encapsulated packets are sent to device 24 using any of the well-known or registered ports, which are the ports that are typically open in standard firewalls.
  • One such well-known port that could be chosen is port 443, which is commonly reserved for HTTPS traffic by ICANN and is commonly open by default on most firewalls.
  • the packets may be sent along any of the well-known, registered, or dynamic ports, the preferable port used may be a port that is commonly open on most firewalls in their standard configurations (e.g., the well-known ports, certain registered ports, and the like).
  • Firewall 12 inspects the traffic from device 21 before sending it out through Internet 16 to device 24. When the traffic arrives at firewall 13, it inspects the traffic, determines that it is valid traffic on a well-known port, and passes it along to device 24.
  • Device 24 receives encapsulated single-port packets 200 sent from device 21. Device 24 then reconstructs multiport packets 100 using packets 200. Reconstruction may be performed by any suitable method including hash-like functions or tables. As an example, header information within one of packets 200 may be an input to a hash-like function that returns the destination IP address and port numbers for a given packet. In the case of a hash-like table, device 21 may use a portion of the header or data in each of packets 100 as the index of a hash-like table and then convert packets 100 to packets 200.
  • Device 24 upon receiving packets 200, may use a portion of the header or data in each of packets 200 as the index of a hash-like table and then reconvert packets 200 back to packets 100, recovering the original IP addresses and ports based on information stored in the hash-like table.
  • device 24 determines for each packet that it is for delivery to endpoint 15.
  • Device 24 then sends the packets to endpoint 15 using each packet's destination port.
  • a port and protocol such as port 443 and Secure Sockets Layer (SSL)
  • SSL Secure Sockets Layer
  • Additional or alternative embodiments may use any of the well-known or registered ports that are typically or commonly open in standard firewalls to send packets between devices 21 and 24. While any of the well-known, registered, or dynamic ports may be used, it is preferable to select a port that is commonly open in firewalls.
  • network or other errors may occasionally lead to lost or corrupted packets and some protocols (such as TCP) specify that in such cases these lost or corrupted packets be resent, which is at odds with maintaining real-time communication. With real-time communication, current data takes precedence over lost previous data since resent packets of previously lost or corrupt data may arrive too late to be useful.
  • devices 21 and 24 may simply ignore the resend request or, alternatively, send a current data packet masquerading as the previously sent and subsequently lost packet, as alternate data.
  • real-time data e.g. data corresponding to the audio or video of the communication
  • device 31 adds encryption layer 311 to the data. Any method or algorithm of encryption may be used including, but not limited to: 128-bit Advanced Encryption Standard (AES); Triple Data Encryption Standard (TDES); Skipjack, or the like. Some or all of each packet received may be encrypted, including the header, which contains the source and destination port numbers associated with the packet. With all of the packets 100 from endpoint 10 having an added layer of encryption and becoming packets 300, the media traffic along with the control traffic between endpoints 10 and 15 are secured for transmission across Internet 16. Device 34 receives secure packets 300 and removes encryption layer 311 before reconstructing packets 100. The reconstructed packets 100 are then dispersed to endpoint 15 addressed to the appropriate ports expected by endpoint 15.
  • AES Advanced Encryption Standard
  • TDES Triple Data Encryption Standard
  • Skipjack or the like.
  • Some or all of each packet received may be encrypted, including the header, which contains the source and destination port numbers associated with the packet.
  • devices 21/31 and 24/34 may also qualify their incoming traffic in order to securely pass traffic associated with the connection between endpoints 10 and 15.
  • endpoint 10 upon being connected to device 21/31, may register itself with device 21/31 as a video conferencing endpoint.
  • device 21/31 may identify those ports as being used and, if appropriate, begin converting and encrypting the traffic associated with such ports.
  • This qualification and registration process my be performed by the use of a hash-like function, so that device 21/31 may efficiently perform the qualification.
  • endpoint 10 may register port 50152 and start sending packets.
  • the source IP address and port may be the inputs to a hash-like function that determines whether a received packet is qualified for further processing and transmission.
  • device 24 may use a portion of the header or data in each of packets 200 as the index of a hash-like table and then determine whether a packet is qualified based on information stored in the hash-like table.
  • each of devices 21 and 24 is depicted connected to a single video conferencing system, they may be connected to multiple and various video conference systems, H.323 gatekeepers, H.323 gateways, SIP proxies, SIP registrars, or the like.
  • a device such as device 21
  • any connections or calls that do not require traversing a firewall may accordingly not be converted into a single-port communication protocol.
  • two video conference endpoints are on the same network behind a firewall and are engaging in communications, this traffic does not pass through a firewall (the traffic is only transmitted on the internal network).
  • devices 21/31 may recognize this situation and, accordingly, not encapsulate nor encrypt the traffic between two such endpoints.
  • device 21 need not be a stand-alone device as its functionality may be integrated into any other network device including, but not limited to: video conference systems, firewalls, H.323 gateways, SIP proxies, SIP registrars or the like.
  • Alternative embodiments may also send traffic between endpoints 10 and 15 that conform to any number of standards or protocols for multimedia communication including, but not limited to the H.323 and SIP protocols by converting the multiport communication protocols into a single-port protocol that uses a port that is typically open on most firewalls.
  • FIGURE 4 is a diagram illustrating the handling of packets.
  • Devices implementing the various embodiments of the invention receive multiple IP data packets (400-403) from multiple ports (1010, 7040, 50148, ... , n).
  • Each packet has an IP header (4001/4011/4021/4031) and an IP data section (4002/4012/4022/4032).
  • the IP header contains information for properly delivering a packet to a destination including, among other things: a source IP address, a destination IP address, and the total length of the packet.
  • the EP data section contains the data being transmitted, which is usually another packet conforming to a different protocol such as TCP, UDP, or the like.
  • TCP and UDP packets found within IP packets 400-403, each also have a header (4004/4014/4024/4034) and data (4005/4015/4025/4035) sections.
  • Headers 4004/4014/4024/4034 of TCP and UDP packets 4003/4013/4023/4033 have the source and destination ports of a packet.
  • each packet received is treated the same regardless of the packet's source port or to which protocol the packet conforms.
  • each IP packet's data section (4042/4052/4062) may be encrypted and then become the data section of a new packet, which may conform to a different protocol for single-port communication.
  • packet 407 is the encrypted TCP packet 4063 of IP packet 406.
  • EP packet 420 contains TCP packet 4203, whose TCP data section 4205 is packet 407. This method allows the original source and destination ports identified in packet 406 's TCP header to be saved and also encrypted such that when packet 420 is transmitted across the Internet, it may not be identified as using a port associated with video conferencing, further increasing security.
  • the port address may effectively be changed.
  • a packet received from port 1010 could be sent out on port 443, with the original source port being saved in an encrypted form within packet 407.
  • TCP data section 4205 of packet 420 may also contain encrypted or non-encrypted UDP packets, RTP packets, or IP packets instead of the encrypted TCP packet portrayed.
  • EP packet 406 may be the TCP data 4205 of packet 420. Accordingly, additional or alternative embodiments may encrypt the entire IP packet (404-406) instead of or in addition to the IP data sections (4042/4052/4062).
  • FIGURE 5 is a flowchart that shows for an embodiment of the invention, example steps that may be employed by devices 31 and 34 to traverse a firewall.
  • An endpoint when connected to a network, first registers with device 31 by the endpoint identifying itself as a compliant endpoint (e.g., it is an endpoint that conforms to H.323, SIP, VoIP, or the like), as shown by step 501.
  • a compliant endpoint e.g., it is an endpoint that conforms to H.323, SIP, VoIP, or the like
  • device 31 may receive traffic from many devices within that network. Thus, device 31 qualifies the traffic it receives to ensure that the traffic sent to device 34 is appropriate traffic. This is shown in step 502 and may be accomplished by comparing a given packet's source IP and port addresses to those of endpoints that have registered with device 31. In step 503, device 31 encrypts the previously qualified traffic securing the communication between two endpoints using any suitable encryption method including, but limited to: AES 128-bit, TDES, Skipjack, or the like, hi step 504, the encrypted traffic is then encapsulated to conform to a single port protocol, such as SSL, by placing the previously encrypted packet into a new packet conforming to SSL protocol. As shown by step 505, the encapsulated traffic is then forwarded to device 34.
  • a single port protocol such as SSL
  • step 506 device 34 receives the single port traffic from device 31 and is diffused by step 507 by restoring the original IP addresses and port numbers to the individual packets.
  • step 508 this diffused traffic is then decrypted, thus, recovering the original multimedia and control communication information within the packets.
  • step 509 the packets are then restored to their original transport protocol, such as TCP, UDP, or the like. With the packets being fully restored, they are then forwarded to the destination endpoint by device 34, as shown by step 510.
  • endpoints 10 and 15 may be VoIP endpoints engaging in voice communication
  • the multiport VoIP protocol traffic from endpoint 10 may be received by device 21, converted to a single port protocol by device 21, encapsulated by device 21, transmitted to device 24, decapsulated by device 24, converted back to the original multiport protocol by device 24, transmitted to endpoint 15, and received by endpoint 15, as described in further detail above.
  • endpoints 10 and 15 may be VoIP endpoints engaging in voice communication
  • the multiport VoIP protocol traffic from endpoint 10 may be received by device 21, converted to a single port protocol by device 21, encapsulated by device 21, transmitted to device 24, decapsulated by device 24, converted back to the original multiport protocol by device 24, transmitted to endpoint 15, and received by endpoint 15, as described in further detail above.
  • endpoints 10 and 15 may be VoIP endpoints engaging in voice communication

Abstract

Systems and methods are disclosed for transporting multiport protocol traffic using a single-port protocol. Multiport protocol traffic from a first endpoint is converted into a single-port protocol for transport across a network. The traffic is sent over a commonly-open port and received at a second endpoint before being dispersed to the appropriate ports of the second endpoint. By converting the traffic to a single-port protocol and choosing which commonly open port to communicate the traffic through, firewalls between each endpoint may be traversed without changing any of their settings.

Description

SYSTEM AND METHOD FOR TRAVERSING A FIREWALL WITH MULTIMEDIA COMMUNICATION
TECHNICAL FIELD
[0001] The present invention relates, in general, to electronic communications, and, more specifically, to transmitting communication data within a multimedia communication system.
BACKGROUND OF THE INVENTION
[0002] The Internet may be used for many forms of communication, including voice conversations, video conferencing, development collaboration, and the like, hi order for a manufacturers' programs, applications, equipment, and systems to be interoperable with each other, many protocols have been developed to standardize the communication between such systems. These protocols have grown increasingly complex to handle all the types of traffic generated to facilitate communication for video conferencing, voice over Internet Protocol (VoIP), and data over Internet Protocol applications. Two such protocols are H.323 from the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) and the Session Initiation Protocol (SIP) from the Internet Engineering Task Force (IETF). Both H.323 and SIP typically allow for multimedia communication including voice, video, and data communications in real-time.
[0003] In Internet Protocol (IP) communication networks, devices or endpoints on the network are identified by their respective EP address. Applications and programs on the different devices further identify each other using port numbers. A port number is a sixteen bit integer, the value of which falls into one of three ranges: the well- known ports, ranging from 0 through 1023; the registered ports, ranging from 1024 through 49151; and the dynamic and/or private ports, ranging from 49152 through 65535. The well-known ports are reserved for assignment by the Internet Corporation for Assigned Names and Numbers (ICANN) for use by applications that communicate using the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) and generally can only be used by a system/root process or by a program run by a privileged user. The registered ports may be registered for use by companies or other individuals for use by applications that communicate using TCP or UDP. The dynamic or private ports, by definition, cannot be officially registered nor are they assigned. Both the H.323 and SIP standards use multiple, well-known, registered, and/or dynamic ports in order to facilitate such communication.
[0004] H.323 and SIP each rely on multiple other protocols, some of which may in turn rely on UDP for sending and receiving multimedia traffic. UDP features minimal overhead compared to other transport protocols (most notably TCP) at the expense of having less reliability. UDP does not provide for guaranteed packet delivery nor data integrity. UDP does offer the highest possible throughput, thus, making it ideally suited for multimedia real-time communications.
[0005] Multimedia communications traffic will most likely have to traverse a firewall at some point during transmission, especially over the Internet, regardless to which protocol the traffic conforms. Firewalls are used in modern networks to screen out unwanted or malicious traffic. One of many techniques a firewall may use is packet filtering, wherein the firewall determines whether or not to allow individual packets by analyzing information in the packet header (such as the IP address and port of the source and destination). Thus, various ports or IP addresses may be blocked to minimize the risk of allowing malicious traffic into an important computer network or system. Another more advanced technique is called stateful inspection, wherein in addition to analyzing header information, a firewall keeps track of the status of any connection opened by network devices behind the firewall. Deciding whether or not a packet is dropped in a stateful inspection is based on the tracked status of the connection and information from within the packet header. In practice, firewalls (especially those used by large corporations) generally only allow traffic from the well-known ports, though such firewalls may be specially configured to allow traffic on any port. For multimedia communication systems that use multiple registered and dynamic ports, firewalls (unless specially configured) will generally block the data traffic on these ports between multimedia systems, thus, preventing communication.
[0006] Video conferencing endpoints generally use multiple dynamic ports for the transmission of communication data packets and, as such, each port used necessitates opening that port on a firewall. Additionally, different endpoints participating in different conversations use different sets of ports, further increasing the number of ports to be opened on a firewall. Reconfiguring ports on a firewall is a time consuming task that introduces the risk of human error, which may defeat the purpose of the firewall by leaving a network vulnerable to malicious attacks. Furthermore, even though these dynamic ports should be closed after the communication ends, in practice, once a firewall port is open, it remains open because the firewall technicians typically do not expend the additional time resources to close the ports. [0007] Additionally, many video conferencing systems do not support encryption. In such cases the communication between endpoints is not secure and may be intercepted while being transmitted across the Internet.
[0008] Existing video conferencing systems such as TANDBERG's BORDER CONTROLLER™, a component of TANDBERG's EXPRESSWAY™ firewall traversal solution, requires the use of TANDBERG Gatekeepers or TANDBERG traversal enabled endpoints. While allowing firewall traversal, the EXPRESSWAY™ solution still requires user intervention to select and trust a range of ports on a firewall and requires the purchase of TANDBERG equipment to use existing legacy video conference endpoints that are not traversal-enabled. The V2IU™ series of products from Polycom, Inc., are Application Level Gateways (ALG) that act as protocol-aware firewalls that automate the selection and trusting of ports, but as such, multiple ports are still used when sending traffic between endpoints with the risk of having such traffic being blocked by a non-protocol-aware firewall. Further, such an ALG does not provide for secure communication. The PATHFINDER™ series of products from RadVision, Ltd., provides for firewall traversal via multiplexing to a single port, but still requires opening a port on a firewall. Multiplexing is implemented by taking sections of data from each of the data streams coming through the various ports and placing them alternately into a single stream. Thus, the resulting stream is simply a train of interleaved data bits that are not recognized as any particular communication protocol. At the destination end point, a packet constructor picks each data bit and places it in the appropriate stream on the appropriate port and rebuilds the original stream.
[0009] Similar systems have been implemented for voice, VoIP, and data over IP communication systems. Each either relies on a proprietary system or equipment or relies on actually selecting and opening multiple ports in a firewall that could leave the underlying network vulnerable to malicious electronic attacks. BRIEF SUMMARY OF THE INVENTION
[0010] The present invention is directed to a system and method for transporting multiport protocol traffic using a single-port protocol that is known to be transmitted on a port that is typically open on standard firewalls. Multiport protocol traffic from a first endpomt is converted in to a single-port protocol for transport across a network. The traffic is then reconverted to the multiport protocol and directed to the appropriate ports at a targeted second endpoint. In being converted into the single-port protocol, the traffic may then traverse a firewall by using a well-known port, such that little or no reconfiguration of the firewall is required. In so doing, the risk of human error leaving a network vulnerable to malicious attacks is reduced. Moreover, instead of creating an unrecognizable data stream, which may still be rejected by more-advanced firewalls, such as through multiplexing, the various embodiments of the present invention actually creates a known, single-port communication protocol.
[0011] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawing, in which:
[0013] FIGURE 1 is a diagram illustrating the flow of packets in a typical IP communication system;
[0014] FIGURE 2 is a diagram illustrating an IP communication system configured according to one embodiment of the present invention;
[0015] FIGURE 3 is a diagram illustrating an IP communication system configured according to another embodiment of the present invention, which includes encryption;
[0016] FIGURE 4 is a diagram illustrating the handling of packets; and
[0017] FIGURE 5 is a flowchart showing for an embodiment of the invention, example steps that may be employed to traverse a firewall.
DETAILED DESCRIPTION OF THE INVENTION
[0018] A variety of protocols require the use of multiport traffic. Whether the traffic is data between applications, voice communications, or video conferencing, whenever multiport traffic is used there is a possibility of some or all of the traffic being blocked by a firewall between two devices that are attempting to communicate. As an example, video conferencing systems, whether they are based on H.323, SIP, or other similar multimedia communication protocols, use multiple ports and multiple protocols in order to enable two-way audio and video communication. The communication protocols specify different types of traffic that may be sent between endpoints which include media traffic (voice, video, and the like) along with the control traffic (camera, connection control, and the like). The media traffic is comprised of data for the images and sound being transmitted between endpoints with the control traffic comprising data used to control the connection between endpoints and the features of the endpoint (e.g., camera direction, zoom, and the like). Due to its higher throughput rate, UDP may typically be utilized for the real-time communication traffic between endpoints. TCP may be utilized for traffic requiring data integrity (e.g., control traffic). As such, video conferencing systems typically make use of both TCP and UDP to transport the multimedia data to enable communication. The ports that are typically used to enable the two-way communication include various ports across the well-known ports, the registered ports, and the dynamic ports. Firewalls are usually set up to block unrequested traffic and/or traffic coming in on dynamic ports. Furthermore, UDP does not provide a mechanism for identifying received traffic as requested traffic. Thus, programs and endpoints that send traffic conforming to UDP are at risk of having that traffic blocked by the remote endpoint's firewall for both being unrequested and being sent on a blocked port.
[0019] Referring to FIGURE 1, video conference endpoint 10 attempts to send multimedia data to video conference endpoint 15. Multiport packets 100 sent from well-known port 1010, registered port 7030, and dynamic ports 50148-50153 are being transmitted to video conference endpoint 15. Firewall 12 passes all the outgoing traffic (packets 100) on all ports since this traffic has originated from the network inside of firewall 12. The traffic is transmitted across Internet 16 and is received by firewall 13, which is operating in a standard mode. In the standard mode, firewall 13 blocks dynamic ports and unrequested traffic (packets 101), such that only the TCP traffic (packets 102) on well-known port 1010 is received by endpoint 15. Thus, with each endpoint being behind their respective firewalls, neither two-way nor one-way communication can take place.
[0020] Referring to FIGURE 2, video conference endpoint 10 again attempts to send multimedia data (packets 100) to video conference endpoint 15, this time with network devices 21 and 24 in the system, hi this embodiment, endpoint 10 is a video conference endpoint that uses a multiple port communication protocol in order to establish communication with endpoint 15. For the purposes of this example, endpoint 10 uses ports 1010, 7030, 50148-50153. The data transmitted using ports 1010 and 50149-50150 utilize TCP as the transport protocol while the data transmitted using ports 7030, 50148, and 50151-50153 utilize UDP as the transport protocol. Packets from each of these ports conforming to these various protocols and sub-protocols are received by network device 21. It should be noted that additional or alternative examples of endpoints may use more or fewer ports of different numbers based in part on the applications or protocols used to facilitate multimedia communication.
[0021] The received packets are encapsulated to conform to a protocol used by devices 21 and 24 for transmitting data, which may include, but is not limited to: TCP, UDP, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), Real-time Transport Protocol (RTP), and the like. Device 21 receives packets 100 from endpoint 10 that conform to both TCP and UDP, encapsulates each of multiport packets 100 into single-port packets 200 that conform to a single-port communication protocol used by devices 21 and 24, and sends packets 200 to device 24. The method of encapsulation may comprise using some or all of the information (header and data) within each of packets 100 as the data section for encapsulated packets 200.
[0022] The encapsulated packets are sent to device 24 using any of the well-known or registered ports, which are the ports that are typically open in standard firewalls. One such well-known port that could be chosen is port 443, which is commonly reserved for HTTPS traffic by ICANN and is commonly open by default on most firewalls. While the packets may be sent along any of the well-known, registered, or dynamic ports, the preferable port used may be a port that is commonly open on most firewalls in their standard configurations (e.g., the well-known ports, certain registered ports, and the like).
[0023] Firewall 12 inspects the traffic from device 21 before sending it out through Internet 16 to device 24. When the traffic arrives at firewall 13, it inspects the traffic, determines that it is valid traffic on a well-known port, and passes it along to device 24.
[0024] Device 24 receives encapsulated single-port packets 200 sent from device 21. Device 24 then reconstructs multiport packets 100 using packets 200. Reconstruction may be performed by any suitable method including hash-like functions or tables. As an example, header information within one of packets 200 may be an input to a hash-like function that returns the destination IP address and port numbers for a given packet. In the case of a hash-like table, device 21 may use a portion of the header or data in each of packets 100 as the index of a hash-like table and then convert packets 100 to packets 200. Device 24 upon receiving packets 200, may use a portion of the header or data in each of packets 200 as the index of a hash-like table and then reconvert packets 200 back to packets 100, recovering the original IP addresses and ports based on information stored in the hash-like table.
[0025] From the original headers, device 24 determines for each packet that it is for delivery to endpoint 15. Device 24 then sends the packets to endpoint 15 using each packet's destination port. Thus, if a port and protocol are advantageously chosen (such as port 443 and Secure Sockets Layer (SSL)), communications traffic from endpoint 10 may be sent to endpoint 15 with no modification or user intervention to traverse firewalls 12 and 13. While one-way communication is described (from endpoint 10 to endpoint 15) it is noted that each of devices 21 and 24 may perform the steps of receiving multiple packets, encapsulation, port translation, decapsulation, and resending multiple packets in order to enable two-way communication between endpoints 10 and 15. Additional or alternative embodiments may use any of the well-known or registered ports that are typically or commonly open in standard firewalls to send packets between devices 21 and 24. While any of the well-known, registered, or dynamic ports may be used, it is preferable to select a port that is commonly open in firewalls. [0026] It should be noted that in additional or alternative embodiments of the present invention, network or other errors may occasionally lead to lost or corrupted packets and some protocols (such as TCP) specify that in such cases these lost or corrupted packets be resent, which is at odds with maintaining real-time communication. With real-time communication, current data takes precedence over lost previous data since resent packets of previously lost or corrupt data may arrive too late to be useful. As such, when receiving a request to resend a packet containing real-time data (e.g. data corresponding to the audio or video of the communication) devices 21 and 24 may simply ignore the resend request or, alternatively, send a current data packet masquerading as the previously sent and subsequently lost packet, as alternate data.
[0027] Referring to FIGURE 3, device 31 adds encryption layer 311 to the data. Any method or algorithm of encryption may be used including, but not limited to: 128-bit Advanced Encryption Standard (AES); Triple Data Encryption Standard (TDES); Skipjack, or the like. Some or all of each packet received may be encrypted, including the header, which contains the source and destination port numbers associated with the packet. With all of the packets 100 from endpoint 10 having an added layer of encryption and becoming packets 300, the media traffic along with the control traffic between endpoints 10 and 15 are secured for transmission across Internet 16. Device 34 receives secure packets 300 and removes encryption layer 311 before reconstructing packets 100. The reconstructed packets 100 are then dispersed to endpoint 15 addressed to the appropriate ports expected by endpoint 15.
[0028] hi alternative or additional embodiments, devices 21/31 and 24/34 may also qualify their incoming traffic in order to securely pass traffic associated with the connection between endpoints 10 and 15. As an example, endpoint 10, upon being connected to device 21/31, may register itself with device 21/31 as a video conferencing endpoint. When endpoint 10 begins using network ports for a conference call or other connection, device 21/31 may identify those ports as being used and, if appropriate, begin converting and encrypting the traffic associated with such ports. This qualification and registration process my be performed by the use of a hash-like function, so that device 21/31 may efficiently perform the qualification. As an example, endpoint 10 may register port 50152 and start sending packets. For every packet received, the source IP address and port may be the inputs to a hash-like function that determines whether a received packet is qualified for further processing and transmission. In the case of a hash-like table, device 24 may use a portion of the header or data in each of packets 200 as the index of a hash-like table and then determine whether a packet is qualified based on information stored in the hash-like table.
[0029] While each of devices 21 and 24 is depicted connected to a single video conferencing system, they may be connected to multiple and various video conference systems, H.323 gatekeepers, H.323 gateways, SIP proxies, SIP registrars, or the like. When multiple video conferencing systems are connected to a device, such as device 21, any connections or calls that do not require traversing a firewall may accordingly not be converted into a single-port communication protocol. As an example, if two video conference endpoints are on the same network behind a firewall and are engaging in communications, this traffic does not pass through a firewall (the traffic is only transmitted on the internal network). Thus, devices 21/31 may recognize this situation and, accordingly, not encapsulate nor encrypt the traffic between two such endpoints.
[0030] Additionally, device 21 need not be a stand-alone device as its functionality may be integrated into any other network device including, but not limited to: video conference systems, firewalls, H.323 gateways, SIP proxies, SIP registrars or the like. Alternative embodiments may also send traffic between endpoints 10 and 15 that conform to any number of standards or protocols for multimedia communication including, but not limited to the H.323 and SIP protocols by converting the multiport communication protocols into a single-port protocol that uses a port that is typically open on most firewalls.
[0031] FIGURE 4 is a diagram illustrating the handling of packets. Devices implementing the various embodiments of the invention receive multiple IP data packets (400-403) from multiple ports (1010, 7040, 50148, ... , n). Each packet has an IP header (4001/4011/4021/4031) and an IP data section (4002/4012/4022/4032). The IP header contains information for properly delivering a packet to a destination including, among other things: a source IP address, a destination IP address, and the total length of the packet. The EP data section contains the data being transmitted, which is usually another packet conforming to a different protocol such as TCP, UDP, or the like. The TCP and UDP packets (4003/4013/4023/4033) found within IP packets 400-403, each also have a header (4004/4014/4024/4034) and data (4005/4015/4025/4035) sections. Headers 4004/4014/4024/4034 of TCP and UDP packets 4003/4013/4023/4033 have the source and destination ports of a packet.
[0032] Each packet received is treated the same regardless of the packet's source port or to which protocol the packet conforms. After being received, each IP packet's data section (4042/4052/4062) may be encrypted and then become the data section of a new packet, which may conform to a different protocol for single-port communication. As an example, packet 407 is the encrypted TCP packet 4063 of IP packet 406. EP packet 420 contains TCP packet 4203, whose TCP data section 4205 is packet 407. This method allows the original source and destination ports identified in packet 406 's TCP header to be saved and also encrypted such that when packet 420 is transmitted across the Internet, it may not be identified as using a port associated with video conferencing, further increasing security. Additionally, in creating a new TCP packet, the port address may effectively be changed. As an example, a packet received from port 1010 could be sent out on port 443, with the original source port being saved in an encrypted form within packet 407. TCP data section 4205 of packet 420 may also contain encrypted or non-encrypted UDP packets, RTP packets, or IP packets instead of the encrypted TCP packet portrayed. As an example, EP packet 406 may be the TCP data 4205 of packet 420. Accordingly, additional or alternative embodiments may encrypt the entire IP packet (404-406) instead of or in addition to the IP data sections (4042/4052/4062).
[0033] FIGURE 5 is a flowchart that shows for an embodiment of the invention, example steps that may be employed by devices 31 and 34 to traverse a firewall. An endpoint, when connected to a network, first registers with device 31 by the endpoint identifying itself as a compliant endpoint (e.g., it is an endpoint that conforms to H.323, SIP, VoIP, or the like), as shown by step 501.
[0034] On a given network, multiple devices may be connected, as such, device 31 may receive traffic from many devices within that network. Thus, device 31 qualifies the traffic it receives to ensure that the traffic sent to device 34 is appropriate traffic. This is shown in step 502 and may be accomplished by comparing a given packet's source IP and port addresses to those of endpoints that have registered with device 31. In step 503, device 31 encrypts the previously qualified traffic securing the communication between two endpoints using any suitable encryption method including, but limited to: AES 128-bit, TDES, Skipjack, or the like, hi step 504, the encrypted traffic is then encapsulated to conform to a single port protocol, such as SSL, by placing the previously encrypted packet into a new packet conforming to SSL protocol. As shown by step 505, the encapsulated traffic is then forwarded to device 34.
[0035] In step 506, device 34 receives the single port traffic from device 31 and is diffused by step 507 by restoring the original IP addresses and port numbers to the individual packets. In step 508, this diffused traffic is then decrypted, thus, recovering the original multimedia and control communication information within the packets. In step 509, the packets are then restored to their original transport protocol, such as TCP, UDP, or the like. With the packets being fully restored, they are then forwarded to the destination endpoint by device 34, as shown by step 510.
[0036] It is noted that while the disclosure has used the communication between two video conference endpoints as an example, it is understood that the systems and methods described may be used by other programs, applications, communications systems, and the like, that use multiport protocols for communication. As such, embodiments of the invention may be used for audio systems VoIP systems, or any other system that uses a multiport protocol to transfer data between devices. Referring back to FIGURE 2 as an example, endpoints 10 and 15 may be VoIP endpoints engaging in voice communication, hi this embodiment the multiport VoIP protocol traffic from endpoint 10 may be received by device 21, converted to a single port protocol by device 21, encapsulated by device 21, transmitted to device 24, decapsulated by device 24, converted back to the original multiport protocol by device 24, transmitted to endpoint 15, and received by endpoint 15, as described in further detail above. The same holds true for other types of programs, equipment, or applications using a multiport protocol to transfer data across a network.
[0037] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

CLAIMSWhat is claimed is:
1. A method for communication between two or more endpoints, said method comprising: receiving a plurality of multiport packets of data in a multiport communication protocol; converting said plurality of multiport packets into a plurality of single-port packets in a single-port communication protocol; transmitting said plurality of single-port packets over a commonly-open port to one or more endpoints traversing one or more firewalls using said commonly- open port; receiving said plurality of single-port packets at said one or more endpoints; reconverting said plurality of single-port packets into said multiport communication protocol; and delivering said plurality of multiport packets using two or more ports associated with said multiport communication protocol.
2. The method of claim 1 , further comprising: encrypting said plurality of single-port packets in said single-port communication protocol prior to said transmitting.
3. The method of claim 2, further comprising: decrypting said encrypted plurality of single-port packets prior to said reconverting.
4. The method of claim 2, wherein said encrypting is according to one of: an Advanced Encryption Standard (AES) 128-bit algorithm; a Triple Data Encryption Standard (TDES) algorithm; or a Skipjack algorithm.
5. The method of claim 1 , wherein: said single-port communication protocol comprises: Secure Sockets Layer (SSL) protocol.
6. The metho d of claim 1 , wherein: a portion of said plurality of multiport packets conforms to a first transmission protocol of said multiport communication protocol; another portion of said plurality of multiport packets conforms to a second transmission protocol of said multiport communication protocol; and wherein said transmitting comprises transmitting said plurality of single-port packets using said first transmission protocol in said single-port communication protocol.
7. The method of claim 6, wherein said first transmission protocol comprises Transmission Control Protocol (TCP); and said second transmission protocol comprises User Datagram Protocol (UDP).
8. The method of claim 6, further comprising: sending alternate data instead of requested data in response to a resend request.
9. The method of claim 1 , further comprising: qualifying said plurality of multiport packets, wherein said qualifying comprises: registering a network device; using network ports by said registered network device; determining whether said plurality of multiport packets originated from a network port used by said registered network device; and allowing further transmission of said plurality of multiport packets based on said determining.
10. The method of claim 1 , wherein said commonly- open port is a well- known port.
11. The method of claim 1 , wherein said commonly-open port is port 443.
12. A system comprising: a first network device, comprising: an interface for receiving a plurality of packets of data from two or more ports; and a conversion table for said first network device to convert said plurality of packets into a single-port communication protocol, wherein said interface communicates said converted plurality of packets over a commonly-open port; and a second network device comprising: a second interface for receiving said converted plurality of packets from said commonly-open port; a second conversion table for reconverting said converted plurality of packets; and wherein said second interface distributes each of said plurality of packets to said two or more ports; and wherein one or more firewalls are traversed between said first and second network devices using said commonly-open port.
13. The system of claim 12, further comprising: an encryption application in said first network device for encrypting said plurality of packets in said single-port communication protocol; and a decryption application in said second network device for decrypting said encrypted plurality of packets prior to said reconverting.
14. The system of claim 13, wherein said encrypting is according to one of: an Advanced Encryption Standard (AES) 128-bit algorithm; a Triple Data Encryption Standard (TDES) algorithm; or a Skipjack algorithm.
15. The system of claim 12, wherein said single-port communication protocol is Secure Sockets Layer (SSL) protocol.
16. The system of claim 12, wherein: a portion of said plurality of packets from said two or more ports conform to Transmission Control Protocol (TCP); another portion of said plurality of packets from said two or more ports conform to User Datagram Protocol (UDP); and wherein said single-port communication protocol uses said TCP.
17. The system of claim 12, wherein said first and second network devices send alternate data instead of requested data in response to a resend request.
18. The system of claim 12, wherein said first network device qualifies said multimedia packets, wherein said qualifying comprises: registering a third network device with said first network device; using network ports by said third network device; ~ determining whether said plurality of packets originated from a network port used by said third network device; and allowing further transmission of said plurality of packets based on said determining.
19. The system of claim 12, wherein said commonly-open port is a well- known port.
20. The system of claim 12, wherein said commonly-open port is port 443.
21. A metho d comprising : receiving at a first network device a plurality of packets of data from two or more ports; converting said plurality of packets into a single-port communication protocol using a conversion table; transmitting from said first network device said converted plurality of packets over a commonly-open port; receiving on at a second network device said converted plurality of packets from said commonly-open port; reconverting said converted plurality of packets using a second conversion table; and distributing on from said second network device each of said plurality of packets to said two or more ports; wherein said converted plurality of packets traverse one or more firewalls between said first and second network devices using said commonly open port.
22. The method of claim 21 , further comprising: encrypting said plurality of packets in said single-port communication protocol; and decrypting said encrypted plurality of packets prior to said reconverting.
23. The method of claim 22, wherein said encrypting is according to one of: an Advanced Encryption Standard (AES) 128-bit algorithm; a Triple Data Encryption Standard (TDES) algorithm; or a Skipjack algorithm.
24. The method of claim 21 , wherein said single-port communication protocol is Secure Sockets Layer (SSL) protocol.
25. The method of claim 21 , wherein: a portion of said plurality of packets from said two or more ports conform to Transmission Control Protocol (TCP); another portion of said plurality of packets from said two or more ports conform to User Datagram Protocol (UDP); and wherein said single-port communication protocol uses said TCP.
26. The method of claim 21, wherein said first and second network devices send alternate data instead of requested data in response to a resend request.
27. The method of claim 21, further comprising qualifying said multimedia packets, wherein said qualifying comprises: registering a third network device with said first network device; determining whether said plurality of packets originated from said third network device; and allowing further transmission of said plurality of packets based on said determining.
28. The method of claim 21, wherein said commonly-open port is a well- known port.
29. The method of claim 21 , wherein said commonly-open port is port 443.
PCT/US2007/066435 2006-04-13 2007-04-11 System and method for traversing a firewall with multimedia communication WO2007121243A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/403,549 2006-04-13
US11/403,549 US7710978B2 (en) 2006-04-13 2006-04-13 System and method for traversing a firewall with multimedia communication

Publications (3)

Publication Number Publication Date
WO2007121243A2 WO2007121243A2 (en) 2007-10-25
WO2007121243A9 true WO2007121243A9 (en) 2008-02-21
WO2007121243A3 WO2007121243A3 (en) 2008-06-05

Family

ID=38604796

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/066435 WO2007121243A2 (en) 2006-04-13 2007-04-11 System and method for traversing a firewall with multimedia communication

Country Status (2)

Country Link
US (1) US7710978B2 (en)
WO (1) WO2007121243A2 (en)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7773588B2 (en) * 2006-04-13 2010-08-10 Directpacket Research, Inc. System and method for cross protocol communication
US8605730B2 (en) * 2006-04-13 2013-12-10 Directpacket Research, Inc. System and method for multimedia communication across disparate networks
US7710978B2 (en) 2006-04-13 2010-05-04 Directpacket Research, Inc. System and method for traversing a firewall with multimedia communication
US8555371B1 (en) 2009-07-17 2013-10-08 Directpacket Research, Inc. Systems and methods for management of nodes across disparate networks
US8560828B2 (en) * 2006-04-13 2013-10-15 Directpacket Research, Inc. System and method for a communication system
US9137212B2 (en) * 2006-12-04 2015-09-15 Oracle America, Inc. Communication method and apparatus using changing destination and return destination ID's
US7913529B2 (en) * 2007-08-28 2011-03-29 Cisco Technology, Inc. Centralized TCP termination with multi-service chaining
US7978731B2 (en) * 2007-09-19 2011-07-12 International Business Machines Corporation Method and system for consolidating TCP ports
US8644504B2 (en) * 2008-02-28 2014-02-04 Silicon Image, Inc. Method, apparatus, and system for deciphering media content stream
TW200943841A (en) * 2008-04-07 2009-10-16 Chunghwa Telecom Co Ltd System of integrating and transmitting internet phone signal and method thereof
KR101606142B1 (en) * 2008-11-28 2016-03-25 삼성전자주식회사 Apparatus and method for supporting nat traversal in voice over internet protocol system
US9253218B2 (en) * 2009-04-23 2016-02-02 International Business Machines Corporation Interface for connecting a network element to a session initiation protocol application server
US8411129B2 (en) * 2009-12-14 2013-04-02 At&T Intellectual Property I, L.P. Video conference system and method using multicast and unicast transmissions
US9215184B2 (en) * 2011-10-17 2015-12-15 Hewlett-Packard Development Company, L.P. Methods of and apparatus for managing non-congestion-controlled message traffic in a datacenter
EP2974294B1 (en) 2013-03-15 2021-04-21 Verizon Patent and Licensing Inc. Provision of video conferencing services using a micropop to extend media processing into enterprise networks
US11323660B2 (en) 2013-03-19 2022-05-03 Verizon Patent And Licensing Inc. Provision of video conferencing services using a micro pop to extend media processing into enterprise networks
US9584518B1 (en) * 2015-09-09 2017-02-28 Callware Technologies, Inc. Dynamic communications controller
US10339154B2 (en) * 2017-05-24 2019-07-02 Sap Se Decentralized image management
US11516230B2 (en) 2020-07-27 2022-11-29 International Business Machines Corporation Selective encryption of data in motion

Family Cites Families (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3609562B2 (en) 1996-11-15 2005-01-12 株式会社日立製作所 Network management system
US6735626B1 (en) 1996-11-15 2004-05-11 Hitachi, Ltd. Network managing method and system
US6266809B1 (en) 1997-08-15 2001-07-24 International Business Machines Corporation Methods, systems and computer program products for secure firmware updates
US6856618B2 (en) 1997-10-21 2005-02-15 Intel Corporation Apparatus and method for computer telephone integration in packet switched telephone networks
US6380968B1 (en) 1998-01-06 2002-04-30 Intel Corporation Method and apparatus for controlling a remote video camera in a video conferencing system
US6611503B1 (en) 1998-05-22 2003-08-26 Tandberg Telecom As Method and apparatus for multimedia conferencing with dynamic bandwidth allocation
US6434140B1 (en) 1998-12-04 2002-08-13 Nortel Networks Limited System and method for implementing XoIP over ANSI-136-A circuit/switched/packet-switched mobile communications networks
CN1250294A (en) * 1999-07-27 2000-04-12 邮电部武汉邮电科学研究院 Adaption method for fusion of Ethernet with synchronizing digital system or synchronizing optical network
US6795444B1 (en) 1999-10-26 2004-09-21 Telefonaktiebolaget L M Ericsson (Publ) System and method for providing wireless telephony over a packet-switched network
US6798782B1 (en) 1999-12-10 2004-09-28 Sun Microsystems, Inc. Truly anonymous communications using supernets, with the provision of topology hiding
EP1143350A1 (en) 2000-04-03 2001-10-10 Koninklijke KPN N.V. A method and a system for retrieving data of a data network
US7826384B2 (en) 2000-05-04 2010-11-02 Nortel Networks Limited Method and apparatus for negotiating bearer control parameters using property sets
CN1393083A (en) 2000-05-19 2003-01-22 索尼株式会社 Network conferencing system, equipment management method and data presentation method
US7441270B1 (en) * 2000-07-06 2008-10-21 Intel Corporation Connectivity in the presence of barriers
GB2365256A (en) 2000-07-28 2002-02-13 Ridgeway Systems & Software Lt Audio-video telephony with port address translation
US7194526B2 (en) 2000-09-22 2007-03-20 Kyocera Corporation Network device management method, and network devices
US6963583B1 (en) 2000-09-29 2005-11-08 Telefonaktiebolaget Lm Ericsson (Publ) Generic call server and method of converting signaling protocols
US7353380B2 (en) * 2001-02-12 2008-04-01 Aventail, Llc, A Subsidiary Of Sonicwall, Inc. Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols
US7181530B1 (en) 2001-07-27 2007-02-20 Cisco Technology, Inc. Rogue AP detection
US6633324B2 (en) 2001-07-31 2003-10-14 Forgent Networks, Inc. System and method for video call configuration and scheduling
US7206808B2 (en) 2001-07-31 2007-04-17 Tandberg Telecom As System and method for managing diverse video network devices via application and interface objects
US7023465B2 (en) 2001-07-31 2006-04-04 Tandberg Telecom As System and method for communication device configuration, scheduling and access control
US8020201B2 (en) * 2001-10-23 2011-09-13 Intel Corporation Selecting a security format conversion for wired and wireless devices
US7159036B2 (en) 2001-12-10 2007-01-02 Mcafee, Inc. Updating data from a source computer to groups of destination computers
US7385622B2 (en) 2002-01-31 2008-06-10 Tandberg Telecom As Method and system for presenting a video call management console
AU2003211053A1 (en) * 2002-02-11 2003-09-04 Polycom, Inc. System and method for videoconferencing across a firewall
US20030182451A1 (en) 2002-03-20 2003-09-25 Grass John B. Method and apparatus for converting voice over internet protocols
US7177929B2 (en) 2002-03-27 2007-02-13 International Business Machines Corporation Persisting node reputations in transient network communities
US7251689B2 (en) 2002-03-27 2007-07-31 International Business Machines Corporation Managing storage resources in decentralized networks
US7039701B2 (en) 2002-03-27 2006-05-02 International Business Machines Corporation Providing management functions in decentralized networks
US7346076B1 (en) 2002-05-07 2008-03-18 At&T Corp. Network controller and method to support format negotiation between interfaces of a network
US20030232648A1 (en) * 2002-06-14 2003-12-18 Prindle Joseph Charles Videophone and videoconferencing apparatus and method for a video game console
JP4151322B2 (en) 2002-06-26 2008-09-17 コニカミノルタビジネステクノロジーズ株式会社 Network management program and network management method
US7346912B2 (en) 2002-08-05 2008-03-18 Tandberg Telecom As Method and system for managing video devices
US7207024B2 (en) * 2002-09-13 2007-04-17 Cadence Design Sytems, Inc. Automatic insertion of clocked elements into an electronic design to improve system performance
DE10245562A1 (en) 2002-09-30 2004-04-15 Siemens Ag Data communication system, computer, and data communication method for the parallel operation of standard-based and proprietary resources
WO2004044710A2 (en) * 2002-11-11 2004-05-27 Supracomm, Inc. Multicast videoconferencing
US7372957B2 (en) 2002-12-24 2008-05-13 Intel Corporation Method and apparatus for implementing call processing in packet telephony networks
US7363381B2 (en) 2003-01-09 2008-04-22 Level 3 Communications, Llc Routing calls through a network
US20040158606A1 (en) 2003-02-10 2004-08-12 Mingtar Tsai Transmission method of multimedia data over a network
US7293169B1 (en) 2003-02-26 2007-11-06 American Megatrends, Inc. Methods and systems for remotely updating the firmware of multiple computers over a distributed network
US7020130B2 (en) * 2003-03-13 2006-03-28 Mci, Inc. Method and apparatus for providing integrated voice and data services over a common interface device
DE10329084A1 (en) 2003-06-27 2005-01-20 Siemens Ag A method and arrangement for accessing a first terminal of a first communication network by a communication node in a second communication network
US7715412B2 (en) 2003-12-09 2010-05-11 At&T Corp. Decomposed H.323 network border element for use in a voice-over-internet protocol network
NO322875B1 (en) 2004-04-23 2006-12-18 Tandberg Telecom As System and procedure for including participants in a conference call
US7889760B2 (en) 2004-04-30 2011-02-15 Microsoft Corporation Systems and methods for sending binary, file contents, and other information, across SIP info and text communication channels
US7328406B2 (en) 2004-04-30 2008-02-05 Tandberg Telecom As System, method and software for managing and publishing resource availability data
US7561520B2 (en) 2004-06-04 2009-07-14 Holloway J Michael Capacity limiting platform system and method
EP1771998B1 (en) * 2004-07-23 2015-04-15 Citrix Systems, Inc. Systems and methods for optimizing communications between network nodes
US7706401B2 (en) 2004-08-13 2010-04-27 Verizon Business Global Llc Method and system for providing interdomain traversal in support of packetized voice transmissions
US7392323B2 (en) * 2004-11-16 2008-06-24 Seiko Epson Corporation Method and apparatus for tunneling data using a single simulated stateful TCP connection
KR100600813B1 (en) 2004-11-19 2006-07-18 한국전자통신연구원 Apparatus and Method for Converting Megaco Protocol
NO322284B1 (en) 2004-12-14 2006-09-11 Tandberg Telecom As Conference resource booking system and procedure
GB0503437D0 (en) 2005-02-18 2005-03-30 Nokia Corp Video traffic in a communications system
US20060224883A1 (en) * 2005-03-30 2006-10-05 Intel Corporation Programming interface for configuring network services in a server
NO20053478A (en) 2005-07-15 2006-12-11 Tandberg Telecom As Procedure for immediate scheduling of conference calls.
US20070239841A1 (en) 2006-03-31 2007-10-11 Tandberg Television Americas Systems and methods for distributing software to a host device in a cable system
US7710978B2 (en) 2006-04-13 2010-05-04 Directpacket Research, Inc. System and method for traversing a firewall with multimedia communication
NO325064B1 (en) 2006-07-06 2008-01-28 Tandberg Telecom As communications Client
NO20071451L (en) 2007-03-19 2008-09-22 Tandberg Telecom As System and method for controlling conference equipment
US8253771B2 (en) 2007-07-31 2012-08-28 Cisco Technology, Inc. Video call management apparatus and associated methodology of controlling voice and video response

Also Published As

Publication number Publication date
US7710978B2 (en) 2010-05-04
WO2007121243A3 (en) 2008-06-05
WO2007121243A2 (en) 2007-10-25
US20070242696A1 (en) 2007-10-18

Similar Documents

Publication Publication Date Title
US7710978B2 (en) System and method for traversing a firewall with multimedia communication
US8605730B2 (en) System and method for multimedia communication across disparate networks
AU2005206976B2 (en) Method and apparatus for transporting encrypted media streams over a wide area network
Kuhn et al. Security considerations for voice over IP systems
US9742806B1 (en) Accessing SSL connection data by a third-party
US7979528B2 (en) System and method for traversing firewalls, NATs, and proxies with rich media communications and other application protocols
US7577156B2 (en) Highly adaptable proxy traversal and authentication
US7639668B2 (en) Method for securing RTS communications across middleboxes
US20060212933A1 (en) Surveillance implementation in a voice over packet network
US20050283536A1 (en) Real time streaming data communications through a security device
CN1633100A (en) Method of multimedia service NAT traversing and system thereof
JP4903780B2 (en) Protecting data delivered out of order
US20170237720A1 (en) System and method of encrypted media encapsulation
CN113904807B (en) Source address authentication method and device, electronic equipment and storage medium
US8560828B2 (en) System and method for a communication system
JP5151197B2 (en) COMMUNICATION SYSTEM, PACKET TRANSFER PROCESSING DEVICE, AND COMMUNICATION SESSION CONTROL METHOD USED FOR THEM
KR100603573B1 (en) Method and apparatus for processing voice data in encrypted packet network
Annoni et al. Security issues in the BRAHMS system
Seggelmann et al. Strategies to Secure End-to-End Communication–And Their Application to SCTP-Based Communication
Bhupathiraju Security aspects in voice over IP systems
Clayton et al. Securing Real-time multimedia: A brief survey
Kuhn et al. SP 800-58. Security Considerations for Voice Over IP Systems
Park et al. Implementation and perforinance evaluation of hardware accelerated IPSec VPN for the home gateway
JP2004166143A (en) Api and communication system using the same
Sweeney et al. Comparison of IPsec to TLS and SRTP for Securing VoIP.

Legal Events

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

Ref document number: 07760486

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

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

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC OF 170209

122 Ep: pct application non-entry in european phase

Ref document number: 07760486

Country of ref document: EP

Kind code of ref document: A2