WO2006044685A2 - Apparatus and method for firewall traversal - Google Patents
Apparatus and method for firewall traversal Download PDFInfo
- Publication number
- WO2006044685A2 WO2006044685A2 PCT/US2005/037055 US2005037055W WO2006044685A2 WO 2006044685 A2 WO2006044685 A2 WO 2006044685A2 US 2005037055 W US2005037055 W US 2005037055W WO 2006044685 A2 WO2006044685 A2 WO 2006044685A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- firewall
- message
- registration
- timeout period
- phone
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
Definitions
- Firewall, network address translation (NAT), and network address port translation (NAPT) devices are generally based on a data security model that blocks requests from external sources. More specifically, data requests received from the network protected by the device (e.g., from the private side of the device) are generally serviced, but requests external to the protected network (e.g., from the public side of the device) are blocked. As valid data requests are assumed to be initiated from within the protected network and contain readily available address information, this is not a problem.
- Firewall and NAT/NAPT devices may not only block VoIP connections and similar services, but may also deny service providers the ability to distribute VoIP end-to-end and prevent service providers from monitoring, upgrading, or reconfiguring equipment (e.g., IP telephones) that is positioned on the private side of such devices.
- VoIP Voice over Internet Protocol
- Fig. 1 is a flowchart of one embodiment of a method for traversing a firewall device.
- Fig. 2 is a diagram of one embodiment of a network architecture within which the method of Fig. 1 may be implemented.
- Fig. 3 is a sequence diagram of one embodiment of a data flow that may occur within the network architecture of Fig. 2.
- Fig. 4 is a sequence diagram of another embodiment of a data flow that may occur within the network architecture of Fig. 2.
- the present disclosure relates to communications and, more particularly, to an apparatus and method for traversing a firewall.
- the following disclosure provides many different embodiments or examples. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting.
- the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.
- a method 100 may be used for traversing a firewall device to maintain a registration between two devices (e.g., an IP telephone and a registrar) that are separated by the firewall device.
- firewall device is used herein to include devices providing firewall functionality, as well as devices having network address translation (NAT) and/or network address port translation (NAPT) functionality.
- NAT network address translation
- NAPT network address port translation
- the method 100 may be executed by hardware and/or software contained within the firewall device, within a separate device, or distributed across multiple devices.
- SMS session initiation protocol
- MEGACO H.323, and MGCP
- media types including audio, video, and fax.
- the IP phone has previously registered with the registrar and that the registration message (e.g., one or more packets or datagrams) is to renew or maintain an existing registration, rather than to obtain an initial registration.
- the registration message e.g., one or more packets or datagrams
- the IP phone's registration will expire.
- the firewall device may use a different timeout period than the registrar (e.g., 30 seconds), and may close the connection between the IP phone and registrar if the IP phone bases the frequency of its registration requests on the registrar's timeout period. This would prevent outside calls from reaching the IP phone, as no open connection would exist through which the call could pass through the firewall device.
- the method 100 may be used to keep the firewall device from timing out the connection and to maintain the registration of the IP phone with the registrar without flooding the registrar with registration request messages.
- a registration message sent from the IP phone to the registrar is intercepted before it is received by the registrar.
- the registration message may be any message used by one device to notify another device that it is still active. It is understood that the term "intercepted" simply indicates that the message is stopped prior to reaching the registrar, and that any number of devices (including the intercepting device) may be positioned between the IP phone and registrar. As such, the intercepting device may legitimately receive the message as part of the path between the IP phone and registrar.
- a determination is made as to whether it is time to renew the registration based on the timeout period established by the registrar.
- step 106 forwards the registration message to the registrar.
- the method may continue to step 106 but may forward the message without making any determination as to whether it is time to renew).
- various modifications may also be made to the source and/or destination addresses as the message passes from the IP phone to the registrar.
- the registrar's response message to the registration request is intercepted and an expiration time in the response message (e.g., an expiration field) is modified from the timeout period defined by the registrar to a substitute timeout period (e.g., a timeout period less than the timeout period of the firewall device).
- the modified message is forwarded to the IP phone.
- step 114 a substitute response message that includes the substitute timeout period is sent to the IP phone.
- the IP phone assumes that the substitute response message is a valid message from the registrar.
- one or more peer-to-peer or multimedia traffic channels may be kept open while minimizing the number of messages that need to be handled by a network.
- the method 100 may be implemented without requiring alterations to a customer's network equipment.
- a network architecture 200 illustrates one embodiment of an environment within which the method 100 of Fig. 1 may be implemented.
- a firewall device 202 separates a private network, such as a home network, from a public network 204.
- the firewall device 202 may be an edge device such as a cable or digital subscriber line (DSL) router having firewall, NAT, and/or NAPT capabilities.
- DSL digital subscriber line
- Such a router may be installed by the owner of the home network between the private and public networks to provide access to the public network 204 for various devices, such as an IP phone 206, an analog phone 207 coupled to the firewall device 202 via an analog telephone adapter (TA) 208, and a computer 209.
- the public network 204 may be coupled to various components, including a registrar 210 and an IP phone 212.
- the firewall device 202 is typically configured for request/response traffic originating from the private network, but presents problems for peer-to-peer traffic such as VoIP.
- the firewall device 202 includes NAPT functionality
- one problem involves NAPT table entries when an incoming voice call from a phone on the public side of the firewall device, such as a VoIP call from IP phone 212, is placed to the IP phone 206 on the private side of the firewall device.
- a table entry is created to track the source address after the firewall device 202 receives a request that originates from the private network, and the entry allows the response to the request to come back to the user.
- the firewall device 202 In VoIP, when the firewall device 202 receives a message from the public side of the network and compares the destination address where the request packet needs to go to against the table, there is no entry and the message will be dropped. Inbound media traffic will have the same problem. Another problem arises with private addresses present in signaling packets, such as those used in session initiation protocol (SIP) messaging.
- a signaling packet that originates within the private network contains a private IP address. Routers on the public IP network are not responsible for routing packets destined for the private IP addresses of private IP networks. Additionally, the addresses for a real-time transport protocol (RTP) media stream are buried in the payload of the signaling packet. The firewall device 202 is unable to see these addresses and cannot provision itself to allow traffic from the outside phone 212. The RTP streams necessary to carry the voice call will, therefore, not be allowed through the firewall device 202.
- RTP real-time transport protocol
- a session controller 214 is positioned on the public side of the firewall device 202 and serves as a proxy for outbound traffic from the private network.
- One example of the session controller 214 is described in greater detail in previously incorporated U.S. Patent Application Serial No. 10/657,813.
- functionality provided by the session controller 214 may be distributed among multiple components, and that the session controller may be removed entirely in some embodiments.
- the session controller 214 maintains an open channel to enable messages originating from the public network 204 to reach devices within the private network. For example, a call initiated by the IP phone 212 that may otherwise be blocked by the firewall device 202 may pass through the firewall device and reach the IP phone
- IP phone 206 and/or TA 208 are generally used in the following examples for purposes of illustration, it is understood that the present disclosure applies equally to other types of communication and media sessions and may include the computer 209 in addition to or instead of the IP phone 206 and TA 208.
- the IP phone 206 and TA 208 may include similar functionality in terms of interaction with the firewall device 202, session controller 214, and registrar 210, and examples using one of the IP phone and TA may be equally applied to the other.
- a sequence diagram 300 provides one embodiment of a call flow between various components of the network architecture 200 of Fig. 2.
- the IP phone 206 may perform a boot sequence during initialization and the boot sequence may assign the IP phone its IP address and notify the IP phone of other information, such as the IP address of the session controller 214 for use as an outbound proxy.
- the components involved in the call flow include the firewall device 202, IP phone 206, registrar 210, and session controller 214.
- the sequence diagram 300 is illustrated using SIP, which relies on the session description protocol (SDP) for session description and RTP for transport.
- SDP session description protocol
- both a signaling channel and a media transport channel are used, with the IP phone 206 and session controller 214 each having one port assigned to the signaling channel and another port assigned to the media channel.
- the IP phone 206 has an internal (e.g., within the private network) IP address of 10.1.1.10, a port 8766 assigned for media, and a port 5060 assigned for signaling.
- the firewall device 202 has an internal IP address of 10.1.1.1 (and associated ports) and an external (e.g., outside of the private network) IP address of 65.119.52.2, an external port 9101 (which will be assigned to a media channel in the present example), and another external port 9500 (for a signaling channel).
- the port 9500 represents any port that may be assigned by the firewall device 202 to the signaling channel.
- the session controller 214 includes an IP address (accessible to the firewall device 202) of 216.206.79.2 with an internal port 10000 for media and an internal port 5060 for signaling, as well as an external port 10002 for media and an external port 5000 for signaling.
- the IP phone 206 sends a registration message (e.g., a SIP REGISTER message) to the session controller 214 via the firewall device 202.
- a registration message e.g., a SIP REGISTER message
- the message includes the internal address of the IP phone as the source address and the address of the session controller 214 as the destination address (Dst: 216.206.79.2:5060; Src: 10.1.1.10:5060).
- the firewall device 202 receives the message from the IP phone 206, assigns a public IP address and port, and modifies the source information to that of the assigned public IP address and port before passing the message on to the session controller 214 (Dst:
- the session controller 206 learns the public IP address and port assigned by the firewall device 202, and forwards the message to the registrar 210 in step 306, using itself as the source address.
- the registrar 210 responds to the session controller 214 with an acceptance message (e.g., a 200 OK message) in step 308.
- the acceptance message is returned to the IP phone 206 via the firewall device 202, with the destination addresses being modified as the message passes through the session controller 214 and firewall device 202. More specifically, the destination address is modified by the session controller 214 from the session controller's external signaling address/port (Dst: 216.206.79.2:5000) to the firewall device's external signaling address/port (Dst:
- the session controller 214 also changes the source address from that of the registrar 210 to that of the session controller (Src: registrar address:port to Src: 216.206.79.2:5060).
- the registrar 210 is aware of the IP phone 206 (which has a current registration to an address and port on the session controller) using the established signaling channel and can direct a phone call from an external phone (e.g., the IP phone 212) to the IP phone 206.
- both the firewall device 202 and the registrar 210 are configured to timeout after a certain period of time has elapsed. For purposes of illustration, if the firewall device 202 does not detect activity within thirty seconds, it will close the connection. However, the registrar is configured to timeout the IP phone's registration after not receiving a registration message or another renewal message within 3600 seconds.
- the firewall device 202 will timeout before the registrar 210, but using the firewall device's timeout period of thirty seconds may inundate the registrar with traffic, particularly if multiple devices are repeatedly registering based on the thirty second interval.
- the session controller 214 may execute a method, such as the method 100 of Fig. 1, to control the timeout period used in messages sent to the IP phone 206 as follows. This may occur, for example, while repeating some or all of the steps 302-312 of Fig. 3.
- step 102 a registration message sent from the IP phone 206 to the registrar is intercepted before it is received by the registrar.
- step 104 a determination is made as to whether it is time to renew the registration based on the 3600 second timeout period established by the registrar. For example, the session controller 214 may calculate whether it will receive another registration message from the IP phone 206 prior to the expiration of the 3600 seconds set by the registrar 210. If it is time to renew the registration, the method 100 continues to step 106 and forwards the registration message to the registrar.
- the registrar's response message to the registration request is received by the session controller 214 and the expiration time in the response message (e.g., an expiration field) is modified from the 3600 second timeout period defined by the registrar to a timeout period based on the thirty second timeout period defined by the firewall.
- the modified timeout period may be equal to the firewall device's timeout period, or may be shorter than the firewall device's timeout period.
- the modified message is forwarded to the IP phone via the firewall device 202.
- the IP phone 206 assumes that the registrar 210 wants the IP phone to renew its registration every thirty seconds and will send out registration requests accordingly.
- step 114 if it is not time to renew the registration, the method continues to step 114 (and skips steps 306 and 308 of Fig. 3), where a substitute response message that includes the substitute thirty second timeout period is sent to the IP phone.
- the IP phone assumes that the substitute response message is a valid message from the registrar.
- the session controller 214 may control the timeout period used by the IP phone 212 to prevent the firewall device 202 from timing out the connection, and may also minimize the number of registration messages received by the registrar 210. This enables the bindings between the IP phone 206 and the registrar 210 to be kept alive indefinitely. Referring again to Fig.
- an incoming call (e.g., an INVITE message) requesting the establishment of a media channel may be received by the session controller 214 in step 314 from an external source, such as the IP phone 212.
- the session controller forwards the message to firewall device 202 in step 316 (Dst: 65.1 19.52.2:9500; Src: 216.206.79.2:5060), and the message reaches the IP phone 206 in step 318 from the firewall device 202 (Dst: 10.1.1.10:5060;
- a response message such as a 200 OK message, may be returned from the IP phone 206 to the IP phone 212 in steps 320, 322, and 324.
- the firewall device 202 may then assign a port (e.g., port 9101) for the media channel, which is learned by the session controller 214 and used to maintain the established session.
- the IP phone 206 may then use the established media channel to send voice data via RTP as shown in steps 326, 328, and 330, and may receive voice data as shown in steps 332, 334, and 336.
- the session controller 214 may close the media channel.
- an end of call terminator e.g., a BYE message
- the session controller 214 may close the media channel.
- the firewall device 202 times out, it will then close the pinhole.
- a new media channel may then be established if the IP phone sends out a request message (e.g., an INVITE) or another request message is received by the session controller 214. It is understood that the previously established signaling channel may remain open as described above.
- the IP phone call is established using symmetric RTP.
- a dynamically assigned user datagram protocol (UDP) port and address is used to send outbound packets, and the outbound packets contain address information needed for inbound packets to locate the IP phone.
- the session controller 214 first learns the signaling channel information (e.g., address and port) and then learns the media channel information when a call is established.
- the session controller 214 is aware of the public IP address and signaling port assigned to the IP phone 206 by the firewall device 202, it can forward incoming signal messages to the proper IP address and port.
- a session controller 214 is aware of the public IP address and media port assigned to the IP phone 206 by the firewall device 202, it can forward incoming media messages to the proper IP address and port. Although the firewall device 202 may keep the signaling channel open indefinitely, the session controller 214 provides a layer of security by not publicizing the firewall's address or open ports (and instead sending the session controller's address/ports to the IP phone 212).
- a sequence diagram 400 provides another embodiment of a call flow between various components of the network architecture 200 of Fig. 2. Prior to the sequence shown, it is understood that certain actions may occur.
- the IP phone 206 may perform a boot sequence during initialization and the boot sequence may assign the IP phone its IP address and inform the IP phone of other information, such as the IP address of the session controller 214.
- the present example may be used with asymmetric RTP (e.g., using different sending and receiving ports).
- the components include the firewall device 202, IP phone 206, registrar 210, and session controller 214.
- both a signaling channel and a media transport channel are used, with the IP phone 206 and session controller 214 each having one port assigned to the signaling channel and another port assigned to the media channel.
- the IP phone 206 has an internal (e.g., within the private network) IP address of 10.1.1.10, a port 8766 assigned for media, and a port 5060 assigned for signaling.
- the firewall device 202 has an internal IP address of 10.1.1.1 (and associated ports) and an external (e.g., outside of the private network) IP address of 65.119.52.2, an external port 9101
- the session controller 214 includes an IP address (accessible to the firewall device 202) of 216.206.79.2 with an internal port 10000 for media and an internal port 5060 for signaling, as well as an external port 10002 for media and an external port 5000 for signaling.
- the IP phone 206 sends a registration message (e.g., a SIP REGISTER message) to the session controller 214 via the firewall device 202.
- a registration message e.g., a SIP REGISTER message
- the message includes the internal address of the IP phone as the source address and the address of the session controller 214 as the destination address (Dst: 216.206.79.2:5060; Src: 10.1.1.10:5060).
- the firewall device 202 receives the message from the IP phone 206, assigns a public IP address and port, and modifies the source address to that of the assigned public IP address and port before passing the message on to the session controller 214 (Dst: 216.206.79.2:5060; Src: 65.119.52.2:9500) in step 404.
- the session controller 206 learns the public IP address and port assigned by the firewall device 202, and forwards the message to the registrar 210 in step 406, using itself as the source address.
- the registrar 210 responds to the session controller 214 with an acceptance message (e.g., a 200 OK message) in step 408.
- the acceptance message is returned to the IP phone 206 via the firewall device 202, with the destination addresses being modified as the message passes from the session controller 214 and firewall device 202. More specifically, the destination address is modified by the session controller 214 from the session controller's external signaling address/port (Dst: 216.206.79.2:5000) to the firewall device's external signaling address/port (Dst:
- the session controller 214 also changes the source address from that of the registrar 210 to that of the session controller (Src: registrar address:port to Src: 216.206.79.2:5060).
- the registrar 210 is aware of the IP phone 206 (which has a current registration) and can direct a phone call from an external phone (e.g., the IP phone 212) to the session controller 214 on behalf of the IP phone 206.
- the firewall device 202 and the registrar 210 are configured to timeout after a certain period of time has elapsed (e.g., 30 and 3600 seconds, respectively). Accordingly, a process such as the method 100 of Fig. 1 may be used as previously described to maintain the bindings between the IP phone 206 and the registrar 210.
- An incoming call (e.g., an INVITE message) may be received by the session controller 214 from an external source, such as the IP phone 212, in step 414.
- the session controller forwards the message to firewall device 202 in step 416, and the message reaches the IP phone
- a response message such as a 200 OK message
- the session controller 214 sends an anchor request message to the IP phone in steps 424 and 426.
- the anchor request may be an encapsulated request sent over the signaling channel to open a communication channel from the private network side of the firewall device 202.
- the IP phone 206 decapsulates the request and sends it back as an anchor response in steps 428 and 430.
- the request asks the firewall device 202 to open a media channel between the IP phone 206 and the session controller 214.
- the request is received from the private side of the firewall device 202 (even though it was initiated by the session controller 214). Accordingly, the firewall device will assign a port for the media channel as though the request was actually initiated by the IP phone 206. In some embodiments, the IP phone 206 may need additional instructions (such as a software client) in order to handle the anchor request.
- the session controller forwards the 200 OK message (received in step 422) to the IP phone 212 in step 432. Because of the anchor, an RTP packet can be sent. to the IP phone 206 (in steps 434, 436, and 438) asymmetrically without requiring the IP phone 206 to send the first RTP packet. In steps 440, 442, and 444, respectively, an RTP packet sent by the IP phone 206 is sent to the firewall device 202, session controller 214, and IP phone 212. In another embodiment, a SIP NOTIFY request may be used to keep a channel alive
- the session controller 214 may receive a REGISTER request from the IP phone 206 via the firewall device 202. As previously described, the session controller 214 will learn the firewall device's binding for the signaling channel established over UDP. The session controller 214 then sends the NOTIFY request to the IP phone 206 via the address/port learned during the REGISTER request.
- the NOTIFY request will be sent after a predefined period of time elapses (e.g., a period of time less than the timeout period of the firewall device 202) and the IP phone 206 will respond to the NOTIFY request with a "200 OK" response.
- the current method does not require the IP phone 206 to repeatedly REGISTER in order to prevent the firewall device 202 from timing out the signaling channel. Instead, the session controller 214 takes an active role in keeping the signaling channel alive by generating each NOTIFY request and sending it to the IP phone 206.
- discovery of the timeout period may be achieved as follows using a device such as the TA 208 connected to the analog phone 207.
- the TA may send a register request to the session controller 214, which learns the firewall device's address/port from the request, and then waits for a predefined period of time (T seconds). After the period expires, the TA sends a binding request (e.g., a SIP OPTIONS message) to the session controller 214 from a different socket (e.g., address and/or port).
- the session controller 214 is configured to send a response to the binding request back to the address learned from the original register request.
- T T IO seconds
- a device such as the TA 208 may handle voice activation detection (VAD) and silence suppression as follows to prevent a connection from being terminated due to lack of traffic (e.g., if someone is listening to a conference call but not speaking).
- VAD voice activation detection
- the TA may send a synthetic periodic packet (e.g., an RTP or RTCP packet) over an RTP/RTCP channel based on the previously described binding discovery lifetime of the firewall device 202.
- the session controller 214 Upon receiving the packet, the session controller 214 would filter the packet based on, for example, a proprietary string in the packet. This enables the connection to stay alive without letting unnecessary packets past the session controller 214.
- a service provider or other external user outside the private network delineated by the firewall device 202 may perform monitoring, reconfiguration, upgrades, quality of service checking, and similar functions within the private network.
- the firewall device would generally reject packets originating from the public network 204, the existing communication channel established between the IP phone 206 and session controller 214 enables the service provider to utilize the session controller for externally originated requests.
- status and alarm information may be sent using a supporting protocol such as the simple network management protocol (SNMP).
- SNMP message may be encapsulated in a SIP message body and sent to the IP phone 206 or TA 208 using the existing call channel between the IP phone 206/TA 208 and the session controller 214.
- endpoint identifiers e.g., a TA serial number and/or a media access control (MAC) address
- MAC media access control
- the present disclosure may provide an external user such as a service provider with ping capability of a device in the private network.
- the existing communication channel between the session controller 214 and one or more of the devices 206, 208, and 209 may be used to receive and transmit ping requests.
- the ping requests may be encapsulated, for example, in SIP messages.
- the present disclosure may provide quality of service (QoS) functionality.
- QoS quality of service
- an RTCP packet may be sent via an established RTCP channel as follows.
- a QoS packet may be time stamped and sent over the RTCP channel.
- the endpoint e.g., one of the devices 206, 208, 209
- the session controller 214 may receive the packet and forward it back to the session controller 214, which calculates the delay based on the difference between the time the packet was received and the timestamp value included in the packet.
- Additional QoS functions include the detection of out of sync packets using sequence numbers, and the recordation of minimum, maximum, and average inter-arrival times for inclusion in a session detail record (SDR).
- SDR session detail record
- various functions described above may be scaled, filtered, or adjusted using predefined or dynamically calculated thresholds.
- alarms provided by SNMP may be used to monitor large numbers of users and devices, with alarms being filtered as desired.
- various QoS parameters may be compared to thresholds, with alarms occurring if the parameters indicate that a certain loss of QoS is occurring.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP05807472A EP1803278A2 (en) | 2004-10-18 | 2005-10-17 | Apparatus and method for firewall traversal |
JP2007537937A JP2008517556A (en) | 2004-10-18 | 2005-10-17 | Apparatus and method for firewall traversal |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/967,470 US8090845B2 (en) | 2004-10-18 | 2004-10-18 | Apparatus and method for firewall traversal |
US10/967,470 | 2004-10-18 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2006044685A2 true WO2006044685A2 (en) | 2006-04-27 |
WO2006044685A3 WO2006044685A3 (en) | 2006-06-08 |
Family
ID=35744781
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2005/037055 WO2006044685A2 (en) | 2004-10-18 | 2005-10-17 | Apparatus and method for firewall traversal |
Country Status (6)
Country | Link |
---|---|
US (1) | US8090845B2 (en) |
EP (1) | EP1803278A2 (en) |
JP (1) | JP2008517556A (en) |
KR (1) | KR20070094735A (en) |
CN (1) | CN101103607A (en) |
WO (1) | WO2006044685A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9277016B2 (en) | 2012-03-02 | 2016-03-01 | Canon Kabushiki Kaisha | Communication system, client apparatus, server apparatus, communication method, and program |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7594259B1 (en) * | 2004-09-15 | 2009-09-22 | Nortel Networks Limited | Method and system for enabling firewall traversal |
US7826602B1 (en) * | 2004-10-22 | 2010-11-02 | Juniper Networks, Inc. | Enabling incoming VoIP calls behind a network firewall |
KR20060059292A (en) * | 2004-11-26 | 2006-06-01 | 한국전자통신연구원 | Network management method in interactive satellite communication system |
US20060123103A1 (en) * | 2004-12-08 | 2006-06-08 | Cisco Technology, Inc. | Communicating network management information using session initiation protocol architecture |
SE528220C2 (en) * | 2004-12-22 | 2006-09-26 | B2 Bredband Ab | Device and method for seamless transition from telephony via the public telephone network to telephony via the Internet |
US20070043876A1 (en) * | 2005-08-19 | 2007-02-22 | Nokia Corporation | Stimulation traffic for binding refreshment |
US7903672B1 (en) * | 2005-08-30 | 2011-03-08 | Juniper Networks, Inc. | Signaling protocol registration load reduction |
US7532581B1 (en) * | 2005-10-28 | 2009-05-12 | Mindspeed Technologies, Inc. | Voice quality monitoring and reporting |
KR100656481B1 (en) * | 2006-02-03 | 2006-12-11 | 삼성전자주식회사 | System and method for dynamic network security |
US7752658B2 (en) * | 2006-06-30 | 2010-07-06 | Microsoft Corporation | Multi-session connection across a trust boundary |
US8213295B2 (en) * | 2006-09-12 | 2012-07-03 | Qualcomm Incorporated | Transaction timeout handling in communication session management |
JP2010514290A (en) * | 2006-12-21 | 2010-04-30 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Network device and method for translating media access control address |
US7693084B2 (en) * | 2007-02-28 | 2010-04-06 | Microsoft Corporation | Concurrent connection testing for computation of NAT timeout period |
US7881318B2 (en) * | 2007-02-28 | 2011-02-01 | Microsoft Corporation | Out-of-band keep-alive mechanism for clients associated with network address translation systems |
US20080279177A1 (en) * | 2007-05-09 | 2008-11-13 | Eyal Shlomot | Conjoined Telephony Communication System |
US7707294B2 (en) * | 2007-06-26 | 2010-04-27 | Microsoft Corporation | Edge traversal service dormancy |
US8370919B2 (en) * | 2007-06-26 | 2013-02-05 | Microsoft Corporation | Host firewall integration with edge traversal technology |
WO2009030869A2 (en) * | 2007-09-07 | 2009-03-12 | France Telecom | Method and device for managing the deregistration of a terminal from an entity in a telecommunication network |
US7945680B2 (en) * | 2007-10-30 | 2011-05-17 | Motorola Solutions, Inc. | Method and apparatus for peer to peer link establishment over a network |
US8522317B2 (en) * | 2007-11-30 | 2013-08-27 | France Telecom | Method and a device for maintaining an address translation table |
KR100932570B1 (en) * | 2008-01-28 | 2009-12-17 | 울산대학교 산학협력단 | Method for maintaining large session information between application server and client in NAT equipment without burdening server and server side network |
US7856506B2 (en) * | 2008-03-05 | 2010-12-21 | Sony Computer Entertainment Inc. | Traversal of symmetric network address translator for multiple simultaneous connections |
JP4569649B2 (en) * | 2008-03-19 | 2010-10-27 | ソニー株式会社 | Information processing apparatus, information reproducing apparatus, information processing method, information reproducing method, information processing system, and program |
US9160794B2 (en) * | 2008-12-04 | 2015-10-13 | Microsoft Technology Licensing, Llc | Network address translators (NAT) type detection techniques |
US8090850B2 (en) * | 2008-12-12 | 2012-01-03 | Tekelec | Methods, systems, and computer readable media for regulating network address translator (NAT) and firewall pinhole preservation traffic in a session initiation protocol (SIP) network |
US8363836B2 (en) * | 2009-01-16 | 2013-01-29 | Cisco Technology, Inc. | Using authentication tokens to authorize a firewall to open a pinhole |
EP2394414B1 (en) * | 2009-02-06 | 2018-10-17 | XMedius Solutions Inc. | Nat traversal using hole punching |
US8713664B2 (en) * | 2009-02-23 | 2014-04-29 | Xcast Labs, Inc. | Detecting the type of NAT firewall using messages |
US9515990B1 (en) * | 2011-01-03 | 2016-12-06 | Sprint Communications Company L.P. | Communicating reregistration information based on the lifetime of a communication session |
JP5602689B2 (en) * | 2011-07-04 | 2014-10-08 | 日本電信電話株式会社 | SIP terminal management system, SIP server, and SIP terminal management method |
EP2903209B1 (en) | 2014-01-30 | 2018-11-14 | Siemens Aktiengesellschaft | Method for updating message filter rules of a network access control unit of an industrial communication network, address management unit and converter unit |
CN105553678A (en) * | 2014-11-04 | 2016-05-04 | 阿尔卡特朗讯 | Method, equipment and system for conference routing |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040034793A1 (en) * | 2002-08-17 | 2004-02-19 | Wei Yuan | Method for providing media communication across firewalls |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7436848B1 (en) * | 2002-07-17 | 2008-10-14 | Sprint Spectrum L.P. | Method for mobile node registration management |
US7162740B2 (en) * | 2002-07-22 | 2007-01-09 | General Instrument Corporation | Denial of service defense by proxy |
US7487199B2 (en) * | 2002-09-24 | 2009-02-03 | Motorola, Inc. | Method and apparatus for maintaining SIP contact addresses |
US7814228B2 (en) * | 2003-02-13 | 2010-10-12 | Oracle America, Inc. | System and method for using data encapsulation in a virtual network |
US7979694B2 (en) * | 2003-03-03 | 2011-07-12 | Cisco Technology, Inc. | Using TCP to authenticate IP source addresses |
US20040205212A1 (en) * | 2003-03-31 | 2004-10-14 | Nokia Corporation | Method and system for forwarding a service-related information to a network user |
US7440442B2 (en) * | 2003-10-21 | 2008-10-21 | 3Com Corporation | IP-based enhanced emergency services using intelligent client devices |
US7483437B1 (en) * | 2003-11-20 | 2009-01-27 | Juniper Networks, Inc. | Method of communicating packet multimedia to restricted endpoints |
US7694127B2 (en) * | 2003-12-11 | 2010-04-06 | Tandberg Telecom As | Communication systems for traversing firewalls and network address translation (NAT) installations |
US7493394B2 (en) * | 2003-12-31 | 2009-02-17 | Cisco Technology, Inc. | Dynamic timeout in a client-server system |
US8090858B2 (en) * | 2004-07-23 | 2012-01-03 | Nokia Siemens Networks Oy | Systems and methods for encapsulation based session initiation protocol through network address translation |
US7333492B2 (en) * | 2004-08-31 | 2008-02-19 | Innomedia Pte Ltd | Firewall proxy system and method |
GB2418037B (en) * | 2004-09-09 | 2007-02-28 | Surfcontrol Plc | System, method and apparatus for use in monitoring or controlling internet access |
-
2004
- 2004-10-18 US US10/967,470 patent/US8090845B2/en not_active Expired - Fee Related
-
2005
- 2005-10-17 JP JP2007537937A patent/JP2008517556A/en active Pending
- 2005-10-17 WO PCT/US2005/037055 patent/WO2006044685A2/en active Application Filing
- 2005-10-17 KR KR1020077011121A patent/KR20070094735A/en not_active Application Discontinuation
- 2005-10-17 EP EP05807472A patent/EP1803278A2/en not_active Withdrawn
- 2005-10-17 CN CNA2005800420399A patent/CN101103607A/en active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040034793A1 (en) * | 2002-08-17 | 2004-02-19 | Wei Yuan | Method for providing media communication across firewalls |
Non-Patent Citations (2)
Title |
---|
DONOVAN J ROSENBERG DYNAMICSOFT S: "Session Timers in the Session Initiation Protocol (SIP)" IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. sip, no. 15, 18 July 2004 (2004-07-18), XP015028094 ISSN: 0000-0004 * |
ROACH DYNAMICSOFT A B: "Session Initiation Protocol (SIP)-Specific Event Notification; rfc3265.txt" IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, June 2002 (2002-06), XP015009043 ISSN: 0000-0003 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9277016B2 (en) | 2012-03-02 | 2016-03-01 | Canon Kabushiki Kaisha | Communication system, client apparatus, server apparatus, communication method, and program |
Also Published As
Publication number | Publication date |
---|---|
WO2006044685A3 (en) | 2006-06-08 |
US20060085548A1 (en) | 2006-04-20 |
EP1803278A2 (en) | 2007-07-04 |
JP2008517556A (en) | 2008-05-22 |
US8090845B2 (en) | 2012-01-03 |
KR20070094735A (en) | 2007-09-21 |
CN101103607A (en) | 2008-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8090845B2 (en) | Apparatus and method for firewall traversal | |
US9392437B2 (en) | Method and system for IP multimedia bearer path optimization through a succession of border gateways | |
JP5972398B2 (en) | ICE-based NAT traversal | |
EP1693998B1 (en) | Method and system for a proxy-based network translation | |
US8949391B2 (en) | Network management across a NAT or firewall | |
JP4777999B2 (en) | Session controller and operation method thereof | |
WO2003105410A1 (en) | Mechanism for implementing voice over ip telephony behind network firewalls | |
JP2007511971A (en) | Method and system for filtering multimedia traffic based on IP address binding | |
EP2410713B1 (en) | Adaptive media handling | |
JP5210509B2 (en) | Intelligent boundary element | |
WO2003077522A1 (en) | Apparatus and method for computer telephone integration in packet switched telephone networks | |
WO2006082576A2 (en) | A method and apparatus for server-side nat detection | |
WO2008052427A1 (en) | A method and network communication system for redirecting network communication port | |
US8374178B2 (en) | Apparatus and method for supporting NAT traversal in voice over internet protocol system | |
US20120127991A1 (en) | method of selecting a network resource | |
US20150004965A1 (en) | System and method for separation of call origination and call delivery techniques | |
KR101330246B1 (en) | VoIP terminal, Method for transferring media data in VoIP terminal, and Session Border Controller for VoIP terminal | |
Talwar | Transition of VoIP system from IPv4 to IPv6 | |
KR100606895B1 (en) | A telecommunication method via VoIP system in Network Address Port Translation | |
Evers et al. | Handover-aware SIP-based VoIP provided by a Roaming-Enabled Architecture (REACH) | |
EP2059001A1 (en) | Multitype SIP processing element | |
Tabassum et al. | An Experimental Study to Analyze SIP Traffic over LAN |
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 BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2005807472 Country of ref document: EP Ref document number: 2007537937 Country of ref document: JP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020077011121 Country of ref document: KR |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200580042039.9 Country of ref document: CN |
|
WWP | Wipo information: published in national office |
Ref document number: 2005807472 Country of ref document: EP |