US20120216272A1 - Routing voip calls through multiple security zones - Google Patents
Routing voip calls through multiple security zones Download PDFInfo
- Publication number
- US20120216272A1 US20120216272A1 US13/460,417 US201213460417A US2012216272A1 US 20120216272 A1 US20120216272 A1 US 20120216272A1 US 201213460417 A US201213460417 A US 201213460417A US 2012216272 A1 US2012216272 A1 US 2012216272A1
- Authority
- US
- United States
- Prior art keywords
- message
- call
- gate
- header
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 230000011664 signaling Effects 0.000 claims abstract description 18
- 230000004044 response Effects 0.000 claims description 25
- 238000000034 method Methods 0.000 claims description 13
- 238000012545 processing Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 230000000977 initiatory effect Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- 238000013519 translation Methods 0.000 description 6
- 230000014616 translation Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 4
- 238000001914 filtration Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011330 nucleic acid test Methods 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1106—Call signalling protocols; H.323 and related
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1053—IP private branch exchange [PBX] functionality entities or arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1076—Screening of IP real time communications, e.g. spam over Internet telephony [SPIT]
-
- 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
- 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/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
Definitions
- the principles of the invention relate generally to packet transmission, and more particularly, to transmission of multimedia related packets across multiple security zones.
- VoIP voice over IP
- ITU-T International Telecommunication Union Telecommunication Standardization Sector
- IETF Internet Engineering Task Force
- SIP Session Initiation Protocol
- a session initiation message is initially routed between a calling party and a proxy server or gatekeeper (collectively, “proxy server”).
- proxy server performs call processing, number lookup, routing, and any other required processing of the session initiation message.
- the session initiation message also typically includes a session description portion that contains information about the media that the caller wishes to use for the session.
- the proxy server then forwards the session initiation message to the called party (sometimes via redirect servers or other intermediary entities).
- a response message having a similar session description portion may be returned to the calling party via the proxy server.
- the calling party receives the response message, it forwards an acknowledgement message to the called party. This completes call setup and enables subsequent exchange of real-time media directly between the calling and called parties.
- IP Internet Protocol
- URL Uniform Resource Locators
- URI Uniform Resource Identifiers
- UDP user datagram protocol
- FIG. 1 is a generalized block diagram illustrating the main components of a VoIP system 100 .
- network servers or gatekeepers 102 and user agents 104 and 106 .
- Each user agent or user device 104 , 106 is an end-user device or system that operates on someone's behalf to either place or receive a call.
- the caller is sometimes referred to as a user agent client (UAC) (i.e., the requesting party) and the recipient is sometimes referred to as a user agent server (UAS) (i.e., the responding party)
- UAC user agent client
- UAS user agent server
- proxy server which receives requests, determines which server to send it to, and then forwards the request
- redirect server which receives requests, but instead of forwarding them to the next hop server, tells the client to contact the next hop directly.
- user agent 104 initially sends an invitation request to network server 102 , which in this case is a proxy server. Proxy server 102 will look in its database to determine where to send the invitation request and forward the request to the appropriate next hop, which in this case is user agent 106 . It should be understood that, although FIG. 1 illustrates proxy server 102 connecting directly to user agent 106 , in practice there could be any number of hops between proxy server 102 and user agent 106 .
- user agent 106 may respond with an OK message, indicating that it has accepted the invitation to participate in the call. This OK message is then forwarded to user agent 104 via proxy server 102 .
- user agent 104 receives the OK message, user agent 104 responds with an acknowledgement message, which, when received, starts the session between the parties.
- firewalls constitute the main protection mechanism for keeping unwanted traffic away from a private network.
- a firewall is positioned between the private network and the public network such that all traffic passing between the two networks first passes through the firewall.
- the traffic may then be subjected to various filtering policies which identify the types and sources/destinations of traffic permitted to flow based upon information contained within the packet headers.
- One exemplary filtering policy may permit all outgoing traffic (e.g., to any destination address) from IP address 134.138.29.17 (the source address) on port 8080 (the source port).
- IP address 134.138.29.17
- port 8080 the source port
- incoming traffic to 134.138.29.17 on port 8080 may not be permitted unless initially requested by 134.138.29.17.
- firewall devices support only two distinct security zones, a public or UNTRUST zone and a private or TRUST zone
- several firewall providers offer three or more security zones, with a third zone sometimes referred to as a demilitarized zone or DMZ.
- DMZ demilitarized zone
- server type devices e.g., web servers, mail servers, etc.
- additional security zones may be established each having a unique security profile.
- addressing information relating to the media exchange between parties is typically contained with the session description portion of a VoIP packet's payload.
- SDP session description protocol
- This information is dynamically assigned upon generation of the each message and cannot be adequately predicted by the firewall. Accordingly, when media from either party is received at the firewall, its passage is denied because no enabling policy is identified.
- the alternative to blanket denial is to leave a wide range of ports unprotected to facilitate passage of the media. Clearly, this is untenable from a security standpoint.
- ACG Application Level Gateways
- NAT is a technology for enabling multiple devices on a private local area network (LAN) having private IP addresses to share a single, or pre-defined group of public IP addresses. Because the private IP addresses maintained by the devices are not routable from outside of the LAN, the NAT must perform translation between the private and public IP addresses at the point where the LAN connects to the Internet.
- LAN local area network
- the device In operation, when a device on the LAN wishes to initiate a connection with a device outside of the LAN, the device will send all traffic to the NAT first.
- the NAT examines the header of each outgoing packet and replaces the source or return address contained therein, which is the device's private address, with it's own public address before passing the traffic to its destination on the Internet.
- port translation is also provided, enabling the NAT to also modify the source and return ports on the traffic. These translations are stored in a table for use in identifying recipients for received traffic. When a response is received, the NAT queries the NAT table, identifies the proper recipient and passes the response to that device.
- addressing information for VoIP traffic may be contained within the payload information as well as the header of outgoing packets. Accordingly, conventional NATs fail to accurately translate all outgoing traffic, resulting in dropped or discarded failed connections.
- the ALGs described above may be configured to translate information contained within the payloads as well as the headers of VoIP messages. Unfortunately, current ALGs fail to support scenarios involving more than two distinct security zones where call messages are routed through multiple zones between calling parties.
- One aspect consistent with principles of the invention is directed to method for routing voice packets across multiple security zones.
- the method includes: performing call setup signaling across at least a first security zone, a second security zone, and a third security zone to set up a call; and establishing at least one gate between the first security zone and the third security zone to enable traffic flow for the call between the first security zone and the third security zone.
- a second aspect consistent with principles of the invention is directed toward a network device for routing voice over internet protocol (VoIP) call messages across multiple security zones.
- the network device may include at least one TRUST zone interface configured to receive a call invitation message from a first user device located in first security zone; at least one DMZ interface configured to communicate with at least one proxy server located in a second security zone; at least one UNTRUST zone interface configured to communicate with at least one second user device located in third security zone; and application level gateway (ALG) logic configured to dynamically route the call invitation between the first user device, the proxy server, and the second user device.
- TRUST zone interface configured to receive a call invitation message from a first user device located in first security zone
- at least one DMZ interface configured to communicate with at least one proxy server located in a second security zone
- at least one UNTRUST zone interface configured to communicate with at least one second user device located in third security zone
- ASG application level gateway
- a device may include means for receiving a call invitation message from a private user device located in first security zone; and means for dynamically routing call invitation related messages between the private user device, a proxy server, and a public user device in multiple security zones.
- FIG. 1 is a generalized block diagram illustrating the main components of a conventional VoIP system
- FIG. 2 illustrates an exemplary system in which systems and methods, consistent with the present invention, may be implemented
- FIG. 3 illustrates an exemplary configuration of a firewall in an implementation consistent with principles of the invention
- FIG. 4 is an exemplary flow diagram illustrating one implementation of processing for routing outgoing VoIP messages where the caller, the recipient, and the proxy server are in different security zones;
- FIGS. 5 a - c are exemplary flow diagrams illustrating one implementation of a method for routing SIP messages across multiple security zones.
- FIG. 6 is an exemplary call flow diagram illustrating the flow of call messages between a private user device, a firewall, a proxy server, and public user device in accordance with one implementation consistent with principles of the invention.
- a firewall or other interface device dynamically identifies VoIP messages passing through multiple security zones and modifies firewall pinholes so as to facilitate efficient exchange of messages between the parties.
- FIG. 2 illustrates an exemplary system 200 in which embodiments of systems and methods consistent with the principles of the invention may be implemented.
- system 200 may include three distinct security zones: a TRUST zone 202 , an UNTRUST zone 204 , and a demilitarized zone (DMZ) 206 .
- TRUST zone 202 may include three distinct security zones: a TRUST zone 202 , an UNTRUST zone 204 , and a demilitarized zone (DMZ) 206 .
- DMZ demilitarized zone
- system 200 may include a group of user devices 208 a , 208 b , and 208 n (collectively “user device 208 ”) connected to a private network 210 , a group of user devices 212 a , 212 b , and 212 m (collectively “user device 212 ”) connected to a public network 214 , a proxy server 216 , and a firewall 218 that provides an interface between private network 210 in TRUST zone 202 , the public network 214 in UNTRUST zone 204 , and proxy server 216 in DMZ 206 .
- Each security zone may provide a different level of network security based on policies applied by firewall 218 . Accordingly, exchanges between entities from within the different zones are treated differently.
- the number and type of user devices 208 and 212 illustrated in FIG. 2 are provided for simplicity. In practice, a typical system may include a number and type of user devices 208 and 212 .
- the present invention may also be implemented in a system having more than three distinct security zones, including multiple zones configured either physically or logically within the system.
- User devices 208 and 212 may include devices, such as personal computers, laptops, SIP telephone devices, H.323 telephone devices, analog telephone devices, or other devices capable of initiating, transmitting, and receiving voice and data communications to/from networks 210 and 214 .
- User devices 208 and 212 facilitate real-time audio or video communications across networks 210 and 214 via firewall 218 .
- firewall 218 may include any combination of hardware and software (e.g., a firewall, etc.) capable of applying security policies to network traffic between user devices 208 and 212 and proxy server 216 via any networks associated therewith.
- firewall 218 may be configured to include an application level gateway (ALG) 220 that performs advanced network address translation (NAT) services on network traffic leaving Trust zone 202 in order to secure user devices 208 from external traffic. More specifically, firewall 218 may initially modify or translate any IP address information contained within both the header and payload of outgoing call set-up messages received from user device 208 for calls to user devices outside of Trust zone 202 (e.g., one of user devices 212 ).
- AGG application level gateway
- NAT advanced network address translation
- firewall 218 may initially modify or translate any IP address information contained within both the header and payload of outgoing call set-up messages received from user device 208 for calls to user devices outside of Trust zone 202 (e.g., one of user devices 212 ).
- NAT helps protect the trusted network from exposure to unwanted
- a source or caller IP address and port information may be contained within the contact and via fields of the packet header. Additionally, caller IP address and port information relating to the expected media to be transmitted between the parties may be found in session description protocol (SDP) information contained in the packet payload.
- SDP session description protocol
- the contact field relates to the calling party's IP or SIP address regardless of route (i.e., a direct response address), whereas the via field relates to all addresses passed through during the route the message has taken to reach the firewall.
- SDP information may include session name and purpose, session time, type of media (e.g., voice or video), media format (e.g., MPEG), transport protocol (e.g., RTP) and port number, bandwidth requirements, and contact information.
- Networks 210 and 214 may include on or more networks, such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), or another type of network that is capable of transmitting voice and data communications from a source device to a destination device.
- Networks 210 and 214 may also include one or more public switched telephone networks (PSTNs) and associated gateway devices.
- PSTNs public switched telephone networks
- an additional network (not shown) may also be provided between proxy server 216 and firewall 218 . This additional network may connect various network devices within each of the three security zones.
- FIG. 3 illustrates an exemplary configuration of firewall 218 in an implementation consistent with principles of the invention.
- firewall 218 may include a TRUST zone link 300 , an UNTRUST zone link 302 , a DMZ zone link 304 and memory controller 306 coupled by a bus 308 .
- firewall 218 may be a gateway between three distinct networks, or distinct portions of a network. The gateway can bridge between trusted and untrusted portions of a network or provide a bridge between a public and private network.
- Each network link 300 , 302 , and 304 may be an Ethernet link that includes an Ethernet media access controller (MAC) and Ethernet physical layer (PHI) for allowing the communication system to receive/send packets from/to networks.
- MAC Ethernet media access controller
- PHI Ethernet physical layer
- a memory bus 310 couples a memory controller 306 to a dual-port memory 312 and an application specific integrated circuit (ASIC) 314 .
- Local bus 316 also links ASIC 314 to dual-port memory 312 .
- Dual-port memory 312 may be a random access memory (RAM) having two separate ports. Any memory location may be accessed from the two ports at the same time.
- RAM random access memory
- ASIC 314 may be an off-chip rule memory 318 for storing a portion of the software rules for screening packets.
- Local bus 316 couples rule memory 318 to ASIC 314 .
- off-chip rule memory 318 may be a static RAM and may be used to store policy data.
- a central processor (CPU) 320 may be coupled to memory controller 306 by CPU bus 322 . In operation, CPU 320 oversees the memory transfer operations on memory bus 310 and bus 308 .
- firewall 218 manages VoIP traffic between the TRUST, UNTRUST, and DMZ zones by dynamically identifying call traffic, thereby linking seeming unrelated call messages. Further, pinholes created for facilitating traffic flow through previously unknown IP addresses and ports may be dynamically altered to enable a more efficient flow of information between the parties. Additional details relating to these features will be set forth in additional detail below.
- FIG. 4 is an exemplary flow diagram illustrating one implementation of processing for routing outgoing VoIP messages (e.g., SIP INVITE messages) where the caller (e.g., user device 208 a ) is in TRUST zone 202 , the recipient (e.g., user device 212 a ) is in UNTRUST zone 204 , and a proxy server (e.g., proxy server 216 ) is in DMZ 206 . As shown in FIG. 4 , firewall 218 initially receives a VoIP message from user device 208 a (act 400 ).
- VoIP messages e.g., SIP INVITE messages
- each VoIP message may include private IP addresses and port designations in various portions of the message, including both header fields and the body or payload of the message. Accordingly, firewall 218 identifies the VoIP message (act 402 ) and performs NAT on any private addresses/ports contained therein (act 404 ).
- firewall 218 opens pinholes on the DMZ/TRUST interface for facilitating return messages and VoIP media (act 406 ). As discussed above, these pinholes enable subsequent traffic addressed to the addresses and ports described in the VoIP message to be transmitted through firewall 218 . In one implementation, discrete pinholes may be created for signaling packets and media packets, since each type of packet may be addressed to and received by different addresses and/or ports on firewall 218 .
- firewall 218 forwards the VoIP message to proxy server 216 for name resolution, recipient location and call routing (act 408 ).
- the VoIP message must again traverse firewall 218 prior to entering UNTRUST zone 204 . Accordingly, firewall 218 next receives the VoIP message from proxy server 216 (act 410 ).
- firewall 218 examines the VoIP message and determines whether the call to which the current VoIP message is associated matches any earlier handled call messages (act 412 ). In one implementation consistent with principles of the invention, this may be accomplished by examining a CALL-ID or similar field contained within the header of the VoIP message that uniquely identifies the call to firewall 218 . If the CALL-ID value in the VoIP message received from proxy server 216 in act 410 matches the CALL-ID value received from user device 208 a in act 400 , a link is created between the two calls (act 414 ).
- firewall 218 Once a link is established, new pinholes in firewall 218 are opened between user device 208 a and user device 212 a at the TRUST/UNTRUST and UNTRUST/TRUST interfaces to firewall 218 , respectively. These pinholes enable contact-related, call signaling, and media messages to be exchanged directly between user device 208 a and user device 212 a , without flowing through proxy server 216 (act 416 ). The pinholes created at the DMZ/TRUST interface are then torn down (act 418 ) and the VoIP message is forwarded to user device 212 a (act 420 ). In one implementation consistent with principles of the invention, signaling messages may continue to be directed through proxy server 216 .
- the signaling pinhole created at the firewall 218 's UNTRUST interface instead points to proxy server 216 at firewall 218 's DMZ interface. Further, the related pinhole at firewall 218 's DMZ/UNTRUST interface is maintained to enable signaling messages to flow from proxy server 216 to user device 208 a through firewall 218 .
- FIGS. 5 a - c are exemplary flow diagrams illustrating one implementation of a method for routing SIP messages across multiple security zones.
- firewall 218 receives an INVITE ( 1 ) message from user device 208 a (act 500 ).
- the INVITE ( 1 ) message includes private IP addresses and ports in at least the contact and via fields from the message header as well as the media addressing and other information from the message's payload.
- firewall 218 performs network address translation on the various IP addresses and ports contained within the INVITE ( 1 ) message to generate a modified INVITE ( 2 ) message (act 502 ).
- firewall 218 creates discrete pinholes through its DMZ interface for each of the translated (e.g., network address translated) address/port combinations (i.e., via, contact and SDP) (act 504 ).
- the modified INVITE ( 2 ) message is then forwarded to proxy server 216 (act 505 ).
- a Record-Route feature may be enabled by proxy server 216 .
- Record-Route enabled all signaling messages exchanged during the call session, including acknowledgement and bye messages, are passed through proxy server 216 .
- proxy server 216 This enables proxy server 216 to log the length of the call and other features implemented.
- enabling or disabling Record-Route is accomplished by inserting or removing proxy server 216 's IP address or URI into a Record-Route header field in the INVITE message. If Record-Route is not enabled, signaling messages following the 200 OK message are exchanged between the calling parties directly, excluding proxy server 216 from the remainder of the message exchanges.
- a 200 OK response is one of several suitable responses from user device 212 a and represents a successful reception and acceptance of the INVITE message.
- firewall 218 receives a processed INVITE ( 3 ) message at its DMZ interface (act 506 ). Initially, it is determined whether a policy exists which enables the INVITE ( 3 ) message to pass from the DMZ to UNTRUST zone 204 (act 507 ). If not, the message is dropped (act 508 ). However, if a policy enables the message to pass, similar to the discussion above, with respect to FIG. 4 , firewall 218 then determines whether the received INVITE ( 3 ) message corresponds to the INVITE ( 1 ) message received from user device 208 a (act 509 ). In one implementation, this may include determining whether CALL-ID values present in each messages' header match.
- firewall 218 determines whether a policy exists which enables the INVITE ( 3 ) message to pass directly between endpoints (e.g., user device 208 a and 212 a ) from UNTRUST zone 204 to TRUST zone 202 (act 512 ). If not, the message is dropped by firewall 218 and the call is canceled (act 514 ).
- endpoints e.g., user device 208 a and 212 a
- new pinholes relating to the top-most via address and port and the Record-Route address and port are created at firewall 218 's UNTRUST interface pointing to proxy server 216 , thereby enabling forwarding of via and record-route-related signaling messages to proxy server 216 (act 520 ).
- INVITE ( 3 ) message is then network address translated by firewall 218 in order to modify the addressing information relating to media exchange (i.e., SDP information) to provide the addressing information for firewall 218 's UNTRUST interface to generate an INVITE ( 4 ) message (act 522 ).
- the INVITE ( 4 ) message is then forwarded to user device 212 a (act 524 ).
- a 200 OK ( 1 ) response message may be received at firewall 218 from user device 212 a (act 526 ).
- a 200 OK response is one of several suitable responses from user device 212 a and represents a successful reception and acceptance of the INVITE message.
- Other responses may include informational or provisional responses (1xx), redirection messages (3xx), client error messages (4xx), and server error messages (5xx).
- messages other than a 200 OK message may result in retransmission of the INVITE ( 4 ) message or dropping of the call.
- the 200 OK ( 1 ) message is reverse network address translated to translate the public addresses and ports to their private counterparts (act 528 ). This generates a 200 OK ( 2 ) message that is then forwarded to proxy server 216 (act 530 ). Additionally, pinholes for contact and media are opened at firewall 218 ′s DMZ interface to enable flow of messages from proxy server 216 to user device 208 a through firewall 218 (act 532 ). Following processing (e.g., DNS resolution, etc.) by proxy server 216 , a 200 OK ( 3 ) message is forwarded through the created pinholes to firewall 218 (act 534 ).
- processing e.g., DNS resolution, etc.
- Firewall 218 determines whether the received 200 OK ( 3 ) message corresponds to the 200 OK ( 1 ) message received from user device 212 a (act 536 ). In one implementation, this may include determining whether CALL-ID values present in each messages' header match. If the CALL-ID values are found to match a link is created between the two messages thereby tying responses received to the 200 OK ( 3 ) message back to the original 200 OK ( 1 ) message (act 538 ).
- pinholes initially created at the UNTRUST/DMZ interface in act 532 relating to the contact and SDP information are deleted (act 540 ) and new pinholes for contact and SDP are created at firewall 218 's TRUST/UNTRUST interface (act 542 ). This enables media and contact-related messages to be received at firewall 218 's TRUST interface and forwarded directly to user device 212 a on the UNTRUST interface, rather then through proxy server 216 .
- the 200 OK ( 3 ) message is then reverse network address translated to identify user device 208 a 's private IP address and ports (act 544 ). This generates a 200 OK ( 4 ) message that is then forwarded to user device 208 a (act 546 ).
- user device 208 a may, in response to a received 200 OK message, generate and forward an ACK message that acknowledges receipt of the 200 OK message by user device 208 a and enables subsequent media transmission between the parties. Details regarding the transmission of the ACK message and subsequent messages (e.g., BYE, etc.) are performed in a manner substantially similar to that described above. It should be noted, that when Record-Route is enabled, the ACK and BYE messages traverse proxy server 216 on their way to user device 212 a . Conversely, with Record-Route disabled, these messages pass directly between user devices 208 a and 212 a.
- FIG. 6 is an exemplary call flow diagram illustrating the flow of call messages between user device 208 a , firewall 218 , proxy server 216 and user device 212 a in accordance with one implementation consistent with principles of the invention.
- an INVITE message 600 is sent from user device 208 a to firewall 218 .
- INVITE message 600 may be a SIP message having the form:
- firewall 218 performs NAT on the INVITE message 600 to generate an INVITE message 602 .
- NAT'ed INVITE message 602 may have the form:
- IP addressees designated in the from, via, and contact fields and the RTP port designated in the “m” field of the SDP information have all been translated to their publicly routable values.
- Firewall 218 next forwards INVITE message 602 through its TRUST/DMZ interface to proxy server 216 while simultaneously opening pinholes to facilitate return traffic from proxy server 216 . As discussed above, three distinct pinholes are opened for traffic related to each of contact, via, and SDP information. Once processed by proxy server 216 (e.g., name resolution, routing, etc.), firewall 218 receives the INVITE message 604 from proxy server 216 .
- firewall 218 determines whether a policy exists which enables the INVITE message 604 to pass from the DMZ 206 to UNTRUST zone 204 . If, so, firewall 218 then determines whether the received INVITE ( 3 ) message corresponds to the INVITE ( 1 ) message received from user device 208 a (act 509 ). In one implementation, this may include determining whether CALL-ID values present in each messages' header match. As discussed above, firewall 218 next analyzes INVITE message 604 and determines that it matches INVITE message 600 , e.g., the CALL-ID values match. These messages are then linked.
- the addressing information within INVITE message 600 relating to media exchange (i.e., SDP information) is again network address translated to provide the addressing information for firewall 218 's UNTRUST interface.
- the pinholes in the DMZ interface pointing to TRUST zone 202 are modified to reflect the specific needs of media traffic. That is, since only call signaling messages are exchanged through proxy server 216 , it is necessary to facilitate exchange of non-signaling messages directly between user devices 208 a and 212 a . Accordingly, the pinholes relating to contact and media traffic in firewall 218 's DMZ interface are deleted and new pinholes for contact and media traffic are created in firewall 218 's UNTRUST interface pointing directly to TRUST zone 204 . Additionally, a third pinhole in firewall 218 's UNTRUST interface is created for via messages and points to the DMZ interface and proxy server 216 . This enables call setup and other via messages to still be routed through proxy server 216 .
- firewall 218 sends INVITE message 606 to user device 212 a .
- additional entities may be positioned between firewall 218 and user device 212 a , for example, redirect servers, additional proxy servers, additional firewalls, etc.
- user device 212 a transmits a 200 OK message 608 indicating that they are available and ready to accept the call from user device 208 a . It should be understood that additional messages may be passed between the call participants and have been ignored for the purposes of brevity.
- Such additional messages may include a TRYING message indicating that proxy server 216 is forwarding the INVITE message to user device 212 a , a RINGING message indicating that the INVITE message was received by user device 212 a , but that it has not yet been accepted or denied, etc.
- 200 OK message 608 Upon receipt, 200 OK message 608 is reverse network address translated by firewall 218 to identify the private IP addresses and ports to which the message should be directed. This generates a 200 OK message 610 . Because 200 OK message 608 is a signaling message, the address and port indicated in its via field are used to identify the next destination for the message. In this instance, 200 OK message 610 is forwarded to proxy server 216 . Following proxy server processing/logging, a 200 OK message 612 is received by firewall 218 from proxy server 216 .
- firewall 218 next analyzes the received 200 OK message 612 and determines that it matches 200 OK message 608 . If so, these messages are then linked. At this point the pinholes for media and contact in DMZ interface pointing to UNTRUST zone 204 are deleted and replacement pinholes in the TRUST interface pointing to the UNTRUST zone 204 are added to facilitate exchange of contact and media message directly from user device 208 a to user device 212 a . 200 OK message 614 is then forwarded to user 208 a over firewall 218 's TRUST interface.
- firewall 218 Upon receipt of 200 OK message 614 , firewall 218 receives an ACK message 616 for user device 208 a . Firewall 218 then performs NAT on ACK message 616 to generate an ACK message 618 . ACK message 618 is then routed directly to user device 212 a . At this point, media 620 may pass between user 208 a and user 212 a directly.
- FIGS. 5-6 describe a VoIP message exchange system incorporating the SIP protocol, this should not be construed as a limitation of the invention. Rather, the methodologies and principles of the invention are equally applicable to systems implementing the H.323 protocol, the media gateway control protocol (MGCP), the skinny client control protocol, or mixed systems utilizing combinations of these protocols.
- MGCP media gateway control protocol
- MGCP media gateway control protocol
- the skinny client control protocol or mixed systems utilizing combinations of these protocols.
- Implementations consistent with principles of the invention provide for routing of VoIP call messages through more than two distinct security zones. More particularly, firewall pinholes may be dynamically altered in response to call needs so as to facilitate efficient communication between the call parties. As a result, benefits of implementing NAT and firewall DMZ's (or other types of distinct security zones) may be incorporated into a VoIP scheme.
- logic/engine may include hardware, such as an application specific integrated circuit (ASIC) or a field programmable gate array, software, or a combination of hardware and software. While aspects have been described in terms of processing messages or packets, these aspects may operate upon any type or form of data, including packet data and non-packet data.
- data unit may refer to packet or non-packet data.
Abstract
Call setup signaling is performed across at least a first security zone, a second security zone, and a third security zone to set up a call. At least one gate is then established between the first security zone and the third security zone to enable traffic flow for the call between the first security zone and the third security zone.
Description
- A. Field of the Invention
- The principles of the invention relate generally to packet transmission, and more particularly, to transmission of multimedia related packets across multiple security zones.
- B. Description of Related Art
- With the increasing ubiquity of the Internet and Internet availability, there has been an increasing desire to leverage its robust and inexpensive architecture for voice telephony services, commonly referred to as voice over IP (internet protocol), or VoIP. Toward this end, standards for internet telephony have been promulgated by the both the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) in the form of H.323 rev 5 (2003), “Packet based multimedia communications systems” as well as the Internet Engineering Task Force (IETF) in the form of RFC 3261 (2002), “Session Initiation Protocol (SIP)” to enable set-up and teardown of the media sessions.
- Under each of these standards, a session initiation message is initially routed between a calling party and a proxy server or gatekeeper (collectively, “proxy server”). The proxy server performs call processing, number lookup, routing, and any other required processing of the session initiation message. The session initiation message also typically includes a session description portion that contains information about the media that the caller wishes to use for the session. The proxy server then forwards the session initiation message to the called party (sometimes via redirect servers or other intermediary entities). In response to the received invitation message, a response message having a similar session description portion may be returned to the calling party via the proxy server. When the calling party receives the response message, it forwards an acknowledgement message to the called party. This completes call setup and enables subsequent exchange of real-time media directly between the calling and called parties.
- All of the messages exchanged are typically in the form of a packet of data having both header and payload information. Most forms of signaling information are contained in packet headers, while information relating to the media being exchanged between the parties is typically contained within the payload portion. In addition, addressing information, such as Internet Protocol (IP) addresses, Uniform Resource Locators (URL's), Uniform Resource Identifiers (URI's), or user datagram protocol (UDP) addresses, etc. for both the calling and called parties may be contained in both the header and payload. The existence of addressing information in packet payloads has caused difficulties with respect to both firewall and network address translation (NAT) implementation.
-
FIG. 1 is a generalized block diagram illustrating the main components of aVoIP system 100. Generally speaking, there are two main components in most VoIP networks: network servers orgatekeepers 102 anduser agents user device network servers 102 as well: a proxy server, which receives requests, determines which server to send it to, and then forwards the request; and a redirect server, which receives requests, but instead of forwarding them to the next hop server, tells the client to contact the next hop directly. - Using these main components, the steps in initiating a VoIP session are generally straightforward. As shown in
FIG. 1 user agent 104 initially sends an invitation request tonetwork server 102, which in this case is a proxy server.Proxy server 102 will look in its database to determine where to send the invitation request and forward the request to the appropriate next hop, which in this case isuser agent 106. It should be understood that, althoughFIG. 1 illustratesproxy server 102 connecting directly touser agent 106, in practice there could be any number of hops betweenproxy server 102 anduser agent 106. Once the invitation message reachesuser agent 106,user agent 106 may respond with an OK message, indicating that it has accepted the invitation to participate in the call. This OK message is then forwarded touser agent 104 viaproxy server 102. Whenuser agent 104 receives the OK message,user agent 104 responds with an acknowledgement message, which, when received, starts the session between the parties. - In most modern network environments, firewalls constitute the main protection mechanism for keeping unwanted traffic away from a private network. In general, a firewall is positioned between the private network and the public network such that all traffic passing between the two networks first passes through the firewall. The traffic may then be subjected to various filtering policies which identify the types and sources/destinations of traffic permitted to flow based upon information contained within the packet headers. One exemplary filtering policy may permit all outgoing traffic (e.g., to any destination address) from IP address 134.138.29.17 (the source address) on port 8080 (the source port). Conversely, incoming traffic to 134.138.29.17 on port 8080 may not be permitted unless initially requested by 134.138.29.17. By enabling the enforcement of these various policies, only known and identifiable types of network traffic may be allowed to enter or exit the private network, thereby providing security to the network.
- Although most firewall devices support only two distinct security zones, a public or UNTRUST zone and a private or TRUST zone, several firewall providers offer three or more security zones, with a third zone sometimes referred to as a demilitarized zone or DMZ. Often, firewall DMZ's will be implemented for server type devices (e.g., web servers, mail servers, etc.) which, by necessity, must be available to the public network. In addition, additional security zones may be established each having a unique security profile.
- Unfortunately, it is the rigorous and strict nature of most conventional firewalls themselves that typically prevents successful establishment of VoIP sessions. For example, addressing information relating to the media exchange between parties is typically contained with the session description portion of a VoIP packet's payload. For example, in a SIP session, addresses and related port(s) on which media is expected is included within the session description protocol (SDP) information found in the message's payload. This information is dynamically assigned upon generation of the each message and cannot be adequately predicted by the firewall. Accordingly, when media from either party is received at the firewall, its passage is denied because no enabling policy is identified. The alternative to blanket denial is to leave a wide range of ports unprotected to facilitate passage of the media. Clearly, this is untenable from a security standpoint. To remedy this issue, intelligent Application Level Gateways (ALG) may be implemented on the firewall which identify VoIP messages as they are received at the firewall. The VoIP messages are then parsed for information contained within their headers and payloads. This information may then be used to create gates or “pinholes” in the firewall interfaces which enable the media to be exchanged between the parties. A pinhole is typically defined to allow traffic based on source and destination addresses and ports.
- In addition to problems posed by the restrictive nature of firewalls alone, many firewalls also implement NAT. Generally speaking, NAT is a technology for enabling multiple devices on a private local area network (LAN) having private IP addresses to share a single, or pre-defined group of public IP addresses. Because the private IP addresses maintained by the devices are not routable from outside of the LAN, the NAT must perform translation between the private and public IP addresses at the point where the LAN connects to the Internet.
- In operation, when a device on the LAN wishes to initiate a connection with a device outside of the LAN, the device will send all traffic to the NAT first. The NAT examines the header of each outgoing packet and replaces the source or return address contained therein, which is the device's private address, with it's own public address before passing the traffic to its destination on the Internet. In some implementations, port translation is also provided, enabling the NAT to also modify the source and return ports on the traffic. These translations are stored in a table for use in identifying recipients for received traffic. When a response is received, the NAT queries the NAT table, identifies the proper recipient and passes the response to that device.
- Unfortunately, as discussed above, addressing information for VoIP traffic may be contained within the payload information as well as the header of outgoing packets. Accordingly, conventional NATs fail to accurately translate all outgoing traffic, resulting in dropped or discarded failed connections. To remedy this deficiency, the ALGs described above may be configured to translate information contained within the payloads as well as the headers of VoIP messages. Unfortunately, current ALGs fail to support scenarios involving more than two distinct security zones where call messages are routed through multiple zones between calling parties.
- Accordingly, there is a need for a VoIP routing solution that enables call setup and media exchange across multiple security zones.
- One aspect consistent with principles of the invention is directed to method for routing voice packets across multiple security zones. The method includes: performing call setup signaling across at least a first security zone, a second security zone, and a third security zone to set up a call; and establishing at least one gate between the first security zone and the third security zone to enable traffic flow for the call between the first security zone and the third security zone.
- A second aspect consistent with principles of the invention is directed toward a network device for routing voice over internet protocol (VoIP) call messages across multiple security zones. The network device may include at least one TRUST zone interface configured to receive a call invitation message from a first user device located in first security zone; at least one DMZ interface configured to communicate with at least one proxy server located in a second security zone; at least one UNTRUST zone interface configured to communicate with at least one second user device located in third security zone; and application level gateway (ALG) logic configured to dynamically route the call invitation between the first user device, the proxy server, and the second user device.
- In a third aspect consistent with principles of the invention, a device may include means for receiving a call invitation message from a private user device located in first security zone; and means for dynamically routing call invitation related messages between the private user device, a proxy server, and a public user device in multiple security zones.
- The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings,
-
FIG. 1 is a generalized block diagram illustrating the main components of a conventional VoIP system; -
FIG. 2 illustrates an exemplary system in which systems and methods, consistent with the present invention, may be implemented; -
FIG. 3 illustrates an exemplary configuration of a firewall in an implementation consistent with principles of the invention; -
FIG. 4 is an exemplary flow diagram illustrating one implementation of processing for routing outgoing VoIP messages where the caller, the recipient, and the proxy server are in different security zones; -
FIGS. 5 a-c are exemplary flow diagrams illustrating one implementation of a method for routing SIP messages across multiple security zones; and -
FIG. 6 is an exemplary call flow diagram illustrating the flow of call messages between a private user device, a firewall, a proxy server, and public user device in accordance with one implementation consistent with principles of the invention. - The following detailed description of embodiments of the principles of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents.
- As described herein, a firewall or other interface device dynamically identifies VoIP messages passing through multiple security zones and modifies firewall pinholes so as to facilitate efficient exchange of messages between the parties.
-
FIG. 2 illustrates anexemplary system 200 in which embodiments of systems and methods consistent with the principles of the invention may be implemented. As illustrated,system 200 may include three distinct security zones: aTRUST zone 202, anUNTRUST zone 204, and a demilitarized zone (DMZ) 206. Additionally,system 200 may include a group ofuser devices private network 210, a group ofuser devices public network 214, aproxy server 216, and afirewall 218 that provides an interface betweenprivate network 210 inTRUST zone 202, thepublic network 214 inUNTRUST zone 204, andproxy server 216 inDMZ 206. - Each security zone, consistent with the principles of the invention, may provide a different level of network security based on policies applied by
firewall 218. Accordingly, exchanges between entities from within the different zones are treated differently. It should be understood that the number and type of user devices 208 and 212 illustrated inFIG. 2 , are provided for simplicity. In practice, a typical system may include a number and type of user devices 208 and 212. In addition, although a three zone security system has been described, the present invention may also be implemented in a system having more than three distinct security zones, including multiple zones configured either physically or logically within the system. - User devices 208 and 212 may include devices, such as personal computers, laptops, SIP telephone devices, H.323 telephone devices, analog telephone devices, or other devices capable of initiating, transmitting, and receiving voice and data communications to/from
networks networks firewall 218. - In one implementation consistent with principles of the invention,
firewall 218 may include any combination of hardware and software (e.g., a firewall, etc.) capable of applying security policies to network traffic between user devices 208 and 212 andproxy server 216 via any networks associated therewith. As described in additional detail below, in one implementation consistent with principles of the invention,firewall 218 may be configured to include an application level gateway (ALG) 220 that performs advanced network address translation (NAT) services on network traffic leavingTrust zone 202 in order to secure user devices 208 from external traffic. More specifically,firewall 218 may initially modify or translate any IP address information contained within both the header and payload of outgoing call set-up messages received from user device 208 for calls to user devices outside of Trust zone 202 (e.g., one of user devices 212). As described above, NAT helps protect the trusted network from exposure to unwanted traffic by translating private IP addresses and ports into publicly routable IP addresses and ports, which are then used to identify the local user to remote users. - In the case of a SIP INVITE message, a source or caller IP address and port information may be contained within the contact and via fields of the packet header. Additionally, caller IP address and port information relating to the expected media to be transmitted between the parties may be found in session description protocol (SDP) information contained in the packet payload. The contact field relates to the calling party's IP or SIP address regardless of route (i.e., a direct response address), whereas the via field relates to all addresses passed through during the route the message has taken to reach the firewall. SDP information may include session name and purpose, session time, type of media (e.g., voice or video), media format (e.g., MPEG), transport protocol (e.g., RTP) and port number, bandwidth requirements, and contact information. By performing NAT on the above-identified address and port information,
firewall 218 secures user device 208 from unauthorized access and identification. -
Networks Networks proxy server 216 andfirewall 218. This additional network may connect various network devices within each of the three security zones. -
FIG. 3 illustrates an exemplary configuration offirewall 218 in an implementation consistent with principles of the invention. As illustrated,firewall 218 may include aTRUST zone link 300, anUNTRUST zone link 302, aDMZ zone link 304 andmemory controller 306 coupled by abus 308. In operation,firewall 218 may be a gateway between three distinct networks, or distinct portions of a network. The gateway can bridge between trusted and untrusted portions of a network or provide a bridge between a public and private network. Eachnetwork link memory bus 310 couples amemory controller 306 to a dual-port memory 312 and an application specific integrated circuit (ASIC) 314.Local bus 316 also linksASIC 314 to dual-port memory 312. Dual-port memory 312 may be a random access memory (RAM) having two separate ports. Any memory location may be accessed from the two ports at the same time. - Associated with
ASIC 314 may be an off-chip rule memory 318 for storing a portion of the software rules for screening packets.Local bus 316 couples rulememory 318 toASIC 314. In one implementation, off-chip rule memory 318 may be a static RAM and may be used to store policy data. A central processor (CPU) 320 may be coupled tomemory controller 306 byCPU bus 322. In operation,CPU 320 oversees the memory transfer operations onmemory bus 310 andbus 308. - In one implementation consistent with principles of the invention,
firewall 218 manages VoIP traffic between the TRUST, UNTRUST, and DMZ zones by dynamically identifying call traffic, thereby linking seeming unrelated call messages. Further, pinholes created for facilitating traffic flow through previously unknown IP addresses and ports may be dynamically altered to enable a more efficient flow of information between the parties. Additional details relating to these features will be set forth in additional detail below. - As described above,
firewall 218 enables exchange of VoIP call setup and media messages between parties located in multiple (e.g., more than two) security zones.FIG. 4 is an exemplary flow diagram illustrating one implementation of processing for routing outgoing VoIP messages (e.g., SIP INVITE messages) where the caller (e.g.,user device 208 a) is inTRUST zone 202, the recipient (e.g.,user device 212 a) is inUNTRUST zone 204, and a proxy server (e.g., proxy server 216) is inDMZ 206. As shown inFIG. 4 ,firewall 218 initially receives a VoIP message fromuser device 208 a (act 400). As mentioned above, each VoIP message may include private IP addresses and port designations in various portions of the message, including both header fields and the body or payload of the message. Accordingly,firewall 218 identifies the VoIP message (act 402) and performs NAT on any private addresses/ports contained therein (act 404). - Once NAT has been completed,
firewall 218 opens pinholes on the DMZ/TRUST interface for facilitating return messages and VoIP media (act 406). As discussed above, these pinholes enable subsequent traffic addressed to the addresses and ports described in the VoIP message to be transmitted throughfirewall 218. In one implementation, discrete pinholes may be created for signaling packets and media packets, since each type of packet may be addressed to and received by different addresses and/or ports onfirewall 218. - Following initial pinhole creation,
firewall 218 forwards the VoIP message toproxy server 216 for name resolution, recipient location and call routing (act 408). In one implementation consistent with principles of the invention, becauseuser device 212 a is inUNTRUST zone 204, the VoIP message must again traversefirewall 218 prior to enteringUNTRUST zone 204. Accordingly,firewall 218 next receives the VoIP message from proxy server 216 (act 410). - At this point,
firewall 218 examines the VoIP message and determines whether the call to which the current VoIP message is associated matches any earlier handled call messages (act 412). In one implementation consistent with principles of the invention, this may be accomplished by examining a CALL-ID or similar field contained within the header of the VoIP message that uniquely identifies the call tofirewall 218. If the CALL-ID value in the VoIP message received fromproxy server 216 inact 410 matches the CALL-ID value received fromuser device 208 a inact 400, a link is created between the two calls (act 414). Once a link is established, new pinholes infirewall 218 are opened betweenuser device 208 a anduser device 212 a at the TRUST/UNTRUST and UNTRUST/TRUST interfaces tofirewall 218, respectively. These pinholes enable contact-related, call signaling, and media messages to be exchanged directly betweenuser device 208 a anduser device 212 a, without flowing through proxy server 216 (act 416). The pinholes created at the DMZ/TRUST interface are then torn down (act 418) and the VoIP message is forwarded touser device 212 a (act 420). In one implementation consistent with principles of the invention, signaling messages may continue to be directed throughproxy server 216. In this implementation, the signaling pinhole created at thefirewall 218's UNTRUST interface instead points toproxy server 216 atfirewall 218's DMZ interface. Further, the related pinhole atfirewall 218's DMZ/UNTRUST interface is maintained to enable signaling messages to flow fromproxy server 216 touser device 208 a throughfirewall 218. -
FIGS. 5 a-c are exemplary flow diagrams illustrating one implementation of a method for routing SIP messages across multiple security zones. Initially,firewall 218 receives an INVITE (1) message fromuser device 208 a (act 500). The INVITE (1) message includes private IP addresses and ports in at least the contact and via fields from the message header as well as the media addressing and other information from the message's payload. In response,firewall 218 performs network address translation on the various IP addresses and ports contained within the INVITE (1) message to generate a modified INVITE (2) message (act 502). Next,firewall 218 creates discrete pinholes through its DMZ interface for each of the translated (e.g., network address translated) address/port combinations (i.e., via, contact and SDP) (act 504). The modified INVITE (2) message is then forwarded to proxy server 216 (act 505). - In one implementation consistent with principles of the invention, a Record-Route feature may be enabled by
proxy server 216. With Record-Route enabled, all signaling messages exchanged during the call session, including acknowledgement and bye messages, are passed throughproxy server 216. This enablesproxy server 216 to log the length of the call and other features implemented. In one embodiment, enabling or disabling Record-Route is accomplished by inserting or removingproxy server 216's IP address or URI into a Record-Route header field in the INVITE message. If Record-Route is not enabled, signaling messages following the 200 OK message are exchanged between the calling parties directly, excludingproxy server 216 from the remainder of the message exchanges. A 200 OK response is one of several suitable responses fromuser device 212 a and represents a successful reception and acceptance of the INVITE message. - Following called party location and call routing processing by
proxy server 216,firewall 218 receives a processed INVITE (3) message at its DMZ interface (act 506). Initially, it is determined whether a policy exists which enables the INVITE (3) message to pass from the DMZ to UNTRUST zone 204 (act 507). If not, the message is dropped (act 508). However, if a policy enables the message to pass, similar to the discussion above, with respect toFIG. 4 ,firewall 218 then determines whether the received INVITE (3) message corresponds to the INVITE (1) message received fromuser device 208 a (act 509). In one implementation, this may include determining whether CALL-ID values present in each messages' header match. - If the CALL-ID values are found to match a link is created between the two messages thereby tying responses received to the INVITE (3) message back to the original INVITE (1) message (act 510). Next the
firewall 218 determines whether a policy exists which enables the INVITE (3) message to pass directly between endpoints (e.g.,user device UNTRUST zone 204 to TRUST zone 202 (act 512). If not, the message is dropped byfirewall 218 and the call is canceled (act 514). - However, if a policy exists which enables message transfer from
DMZ 206 toUNTRUST zone 204, the pinholes initially created at the DMZ/TRUST interface inact 504 relating to the contact and SDP information are deleted (act 516) and new pinholes are created atfirewall 218's UNTRUST/TRUST interface (act 518). This enables responsive messages to be received atfirewall 218's UNTRUST interface and forwarded directly touser device 208 a inTRUST zone 202, rather then throughproxy server 216. Additionally, new pinholes relating to the top-most via address and port and the Record-Route address and port (if enabled) are created atfirewall 218's UNTRUST interface pointing toproxy server 216, thereby enabling forwarding of via and record-route-related signaling messages to proxy server 216 (act 520). - In one implementation consistent with principles of the invention, INVITE (3) message is then network address translated by
firewall 218 in order to modify the addressing information relating to media exchange (i.e., SDP information) to provide the addressing information forfirewall 218's UNTRUST interface to generate an INVITE (4) message (act 522). The INVITE (4) message is then forwarded touser device 212 a (act 524). - Assuming, for the purposes of simplicity, that
user device 212 a is available and elects to receive the INVITE (4) message, a 200 OK (1) response message may be received atfirewall 218 fromuser device 212 a (act 526). A 200 OK response is one of several suitable responses fromuser device 212 a and represents a successful reception and acceptance of the INVITE message. Other responses may include informational or provisional responses (1xx), redirection messages (3xx), client error messages (4xx), and server error messages (5xx). As is known in the art, messages other than a 200 OK message may result in retransmission of the INVITE (4) message or dropping of the call. - Once the 200 OK (1) message has been received, it is reverse network address translated to translate the public addresses and ports to their private counterparts (act 528). This generates a 200 OK (2) message that is then forwarded to proxy server 216 (act 530). Additionally, pinholes for contact and media are opened at
firewall 218′s DMZ interface to enable flow of messages fromproxy server 216 touser device 208 a through firewall 218 (act 532). Following processing (e.g., DNS resolution, etc.) byproxy server 216, a 200 OK (3) message is forwarded through the created pinholes to firewall 218 (act 534). -
Firewall 218 then determines whether the received 200 OK (3) message corresponds to the 200 OK (1) message received fromuser device 212 a (act 536). In one implementation, this may include determining whether CALL-ID values present in each messages' header match. If the CALL-ID values are found to match a link is created between the two messages thereby tying responses received to the 200 OK (3) message back to the original 200 OK (1) message (act 538). - Next, pinholes initially created at the UNTRUST/DMZ interface in
act 532 relating to the contact and SDP information are deleted (act 540) and new pinholes for contact and SDP are created atfirewall 218's TRUST/UNTRUST interface (act 542). This enables media and contact-related messages to be received atfirewall 218's TRUST interface and forwarded directly touser device 212 a on the UNTRUST interface, rather then throughproxy server 216. - The 200 OK (3) message is then reverse network address translated to identify
user device 208 a's private IP address and ports (act 544). This generates a 200 OK (4) message that is then forwarded touser device 208 a (act 546). - As is known in the art,
user device 208 a may, in response to a received 200 OK message, generate and forward an ACK message that acknowledges receipt of the 200 OK message byuser device 208 a and enables subsequent media transmission between the parties. Details regarding the transmission of the ACK message and subsequent messages (e.g., BYE, etc.) are performed in a manner substantially similar to that described above. It should be noted, that when Record-Route is enabled, the ACK and BYE messages traverseproxy server 216 on their way touser device 212 a. Conversely, with Record-Route disabled, these messages pass directly betweenuser devices -
FIG. 6 is an exemplary call flow diagram illustrating the flow of call messages betweenuser device 208 a,firewall 218,proxy server 216 anduser device 212 a in accordance with one implementation consistent with principles of the invention. Initially, anINVITE message 600 is sent fromuser device 208 a tofirewall 218. In one implementation consistent with principles of the invention,INVITE message 600 may be a SIP message having the form: - INVITE sip:bob@university.edu SIP/2.0
- CSeq: 1 INVITE
- To: sip:bob@university.edu
- From: alice<sip:alice@5.5.5.1>
- Call-ID: 1234567@5.5.5.1
- Via: SIP/2.0/UDP 5.5.5.1:5060
- Contact: <sip:alice@5.5.5.1>
- Subject: no subject
- Content-Type: application/sdp
- Content-Length: 123
- v=0
- o=982769551076 982769551076 IN IP4 5.5.5.1
- c=IN IP4 5.5.5.1
- m=audio 45002 RTP/AVP 0
- In the manner described in detail above,
firewall 218 performs NAT on theINVITE message 600 to generate anINVITE message 602. In one implementation,NAT'ed INVITE message 602 may have the form: - INVITE sip:bob@university.edu SIP/2.0
- CSeq: 1 INVITE
- To: sip:bob@university.edu
- From: alice<sip:alice@6.6.6.1>
- Call-ID: abcdefg@6.6.6.1
- Via: SIP/2.0/UDP 6.6.6.1:5060
- Contact: <sip:alice@6.6.6.1>
- Subject: no subject
- Content-Type: application/sdp
- Content-Length: 123
- v=0
- o=982769551076 982769551076 IN IP4 6.6.6.1
- c=IN IP4 6.6.6.1
- m=audio 52002 RTP/AVP 0
- where the IP addressees designated in the from, via, and contact fields and the RTP port designated in the “m” field of the SDP information have all been translated to their publicly routable values.
-
Firewall 218 next forwards INVITEmessage 602 through its TRUST/DMZ interface toproxy server 216 while simultaneously opening pinholes to facilitate return traffic fromproxy server 216. As discussed above, three distinct pinholes are opened for traffic related to each of contact, via, and SDP information. Once processed by proxy server 216 (e.g., name resolution, routing, etc.),firewall 218 receives theINVITE message 604 fromproxy server 216. - As discussed above, it is then determined whether a policy exists which enables the
INVITE message 604 to pass from theDMZ 206 toUNTRUST zone 204. If, so,firewall 218 then determines whether the received INVITE (3) message corresponds to the INVITE (1) message received fromuser device 208 a (act 509). In one implementation, this may include determining whether CALL-ID values present in each messages' header match. As discussed above,firewall 218 next analyzesINVITE message 604 and determines that it matchesINVITE message 600, e.g., the CALL-ID values match. These messages are then linked. Next, the addressing information withinINVITE message 600 relating to media exchange (i.e., SDP information) is again network address translated to provide the addressing information forfirewall 218's UNTRUST interface. At this point the pinholes in the DMZ interface pointing toTRUST zone 202 are modified to reflect the specific needs of media traffic. That is, since only call signaling messages are exchanged throughproxy server 216, it is necessary to facilitate exchange of non-signaling messages directly betweenuser devices firewall 218's DMZ interface are deleted and new pinholes for contact and media traffic are created infirewall 218's UNTRUST interface pointing directly toTRUST zone 204. Additionally, a third pinhole infirewall 218's UNTRUST interface is created for via messages and points to the DMZ interface andproxy server 216. This enables call setup and other via messages to still be routed throughproxy server 216. - Once the proper setup of pinholes has been created,
firewall 218 sendsINVITE message 606 touser device 212 a. Although not shown for reasons of simplicity, additional entities may be positioned betweenfirewall 218 anduser device 212 a, for example, redirect servers, additional proxy servers, additional firewalls, etc. In response to theINVITE message 606,user device 212 a transmits a 200OK message 608 indicating that they are available and ready to accept the call fromuser device 208 a. It should be understood that additional messages may be passed between the call participants and have been ignored for the purposes of brevity. Such additional messages may include a TRYING message indicating thatproxy server 216 is forwarding the INVITE message touser device 212 a, a RINGING message indicating that the INVITE message was received byuser device 212 a, but that it has not yet been accepted or denied, etc. - Upon receipt, 200
OK message 608 is reverse network address translated byfirewall 218 to identify the private IP addresses and ports to which the message should be directed. This generates a 200OK message 610. Because 200OK message 608 is a signaling message, the address and port indicated in its via field are used to identify the next destination for the message. In this instance, 200OK message 610 is forwarded toproxy server 216. Following proxy server processing/logging, a 200OK message 612 is received byfirewall 218 fromproxy server 216. - As discussed above,
firewall 218 next analyzes the received 200OK message 612 and determines that it matches 200OK message 608. If so, these messages are then linked. At this point the pinholes for media and contact in DMZ interface pointing toUNTRUST zone 204 are deleted and replacement pinholes in the TRUST interface pointing to theUNTRUST zone 204 are added to facilitate exchange of contact and media message directly fromuser device 208 a touser device 212 a. 200OK message 614 is then forwarded touser 208 a overfirewall 218's TRUST interface. - Upon receipt of 200
OK message 614,firewall 218 receives anACK message 616 foruser device 208 a.Firewall 218 then performs NAT onACK message 616 to generate anACK message 618.ACK message 618 is then routed directly touser device 212 a. At this point,media 620 may pass betweenuser 208 a anduser 212 a directly. - Although the above implementations referenced in
FIGS. 5-6 describe a VoIP message exchange system incorporating the SIP protocol, this should not be construed as a limitation of the invention. Rather, the methodologies and principles of the invention are equally applicable to systems implementing the H.323 protocol, the media gateway control protocol (MGCP), the skinny client control protocol, or mixed systems utilizing combinations of these protocols. - Implementations consistent with principles of the invention provide for routing of VoIP call messages through more than two distinct security zones. More particularly, firewall pinholes may be dynamically altered in response to call needs so as to facilitate efficient communication between the call parties. As a result, benefits of implementing NAT and firewall DMZ's (or other types of distinct security zones) may be incorporated into a VoIP scheme.
- The foregoing description of exemplary embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention.
- Moreover, while a series of acts has been disclosed with regard to
FIGS. 4-6 the order of the acts may be varied in other implementations consist with the present invention. Furthermore, non-dependent acts may be implemented in parallel. - It will also be apparent to one of ordinary skill in the art that aspects of the invention, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects consistent with the principles of the invention is not limiting of the present invention. Thus, the operation and behavior of the aspects of the invention were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein.
- Further, certain portions of the invention may be implemented as “logic” or be referred to as an “engine” that performs one or more functions. This logic/engine may include hardware, such as an application specific integrated circuit (ASIC) or a field programmable gate array, software, or a combination of hardware and software. While aspects have been described in terms of processing messages or packets, these aspects may operate upon any type or form of data, including packet data and non-packet data. The term “data unit” may refer to packet or non-packet data.
- No element, act, or instruction used in description of the present invention should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. The scope of the invention is defined by the claims and their equivalents.
Claims (21)
1-23. (canceled)
24. A non-transitory computer-readable medium storing instructions, the instructions comprising:
one or more instructions which, when executed by one or more processors of a first network device, cause the one or more processors to:
receive a call invitation message for establishing a call from a first user device included in a first security zone,
establish, based on the call invitation message and between the first security zone and a second security zone, a first discrete pinhole for signaling packets associated with the call and a second discrete pinhole for media packets associated with the call,
forward, based on establishing the first discrete pinhole and the second discrete pinhole, the call invitation message to a second network device in the second security zone,
receive, from the second network device, a processed call invitation message,
associate the processed call invitation message with the call invitation message,
close, based on associating the processed call invitation message with the call invitation message, the second discrete pinhole,
establish, based on closing the second discrete pinhole and between the first security zone and a third security zone, a third discrete pinhole and a fourth discrete pinhole,
the third discrete pinhole permitting media messages associated with the call to be transmitted, via the first network device, directly between the first security zone and the third security zone, and the fourth discrete pinhole pointing to the second network device to direct signaling messages associated with the call to the second network device, and
establish, based on creating the third discrete pinhole and the fourth discrete pinhole, the call between the first user device and a second user device included in the third security zone.
25. The non-transitory computer-readable medium of claim 24 , further comprising:
one or more instructions to:
identify, based on information included in a header of the processed call invitation message, an identifier associated with the processed call invitation message, and
determine whether to associate the processed call invitation message with the call invitation message based on the identifier associated with the processed call invitation message.
26. The non-transitory computer-readable medium of claim 25 , further comprising:
one or more instructions to determine whether the identifier associated with the processed call invitation message matches an identifier included in a header of the call invitation message.
27. The non-transitory computer-readable medium of claim 24 , where the one or more instructions to establish the call include:
one or more instructions to:
generate, based on address information included in the processed call invitation message, a modified message,
forward the modified message to the second user device,
receive, via the fourth discrete pinhole and based on forwarding the modified message, a response message from the second user device, and
direct, based on receiving the response via the fourth discrete pinhole, the response to the second network device via the first discrete pinhole.
28. The non-transitory computer-readable medium of claim 24 , where the one or more instructions to receive the processed call invitation include:
one or more instructions to receive the processed call invitation via the first discrete pinhole.
29. The non-transitory computer-readable medium of claim 24 , where the first security zone is associated with a trusted network and the second security zone is associated with an untrusted network.
30. The non-transitory computer-readable medium of claim 24 , where the call comprises a Voice over Internet Protocol session.
31. A network device comprising:
a processor to:
receive, from a first device included in a first security zone, a first message for establishing a voice over Internet Protocol (VoIP) session between the first device and a second device included in a second security zone,
open, based on the first message:
a first gate for transmitting a first type of data associated with the call between the first device and a third device included in a third security zone, and
a second gate for transmitting a second type of data associated with the call between the first device and the third device,
receive a second message from the third device,
determine that the second message is associated with the first message,
close, based on determining that the second message is associated with the first message, the second gate,
open, based on closing the second gate:
a third gate for transmitting the second type of data associated with the call between the first device and the second device, and
a fourth gate for transmitting the first type of data associated with the call between the second device and the third device, and
establish, based on opening the third gate and the fourth gate, the VoIP session between the first device and the second device.
32. The device of claim 31 , where the processor is further to:
identify a first address based on information included in a header of the first message, and
identify a second address based on information included in a non-header portion of the first message, where the first gate is opened based on identifying the first address and the second gate is opened based on identifying the second address.
33. The device of claim 31 , where the first type of data comprises data associated with signaling messages associated with the VoIP session and the second type of data comprises data associated with media transmitted between the first device and the second device during the VoIP session.
34. The device of claim 31 , where the processor is further to:
determine whether a particular value, included in a header of the second message, matches a corresponding particular value included in a header of the first message,
determine that the second message is associated with the first message when the particular value included in the header of the second message matches the corresponding particular value included in the header of the first message, and
drop the second message when the particular value included in the header of the second message does not match the corresponding particular value included in the header of the first message.
35. The device of claim 34 , where the particular value comprises a value included in a particular field of the second message.
36. The device of claim 31 , where the processor is further to:
modify, based on address information included in the second message, the second message,
forward the modified second message to the second device,
receive, via the fourth gate, a response from the second device, and
direct, based on receiving the response via the fourth gate, the response to the third device via the first gate.
37. The device of claim 31 , where the processor is further to:
identify first address information included in a header of the first message,
identify second address information included in a non-header portion of the first message,
modify the first address information and the second address information, and
forward the first message, including the modified first address information and the modified second address information, to the third device via the first gate.
38. A method comprising:
receiving, by a first device, a first message for establishing a call between a second device included in a first security zone and a third device included in a second security zone;
identifying, by the first device and based on information included in the first message, a first address associated with a first port of the first device and a second address associated with a second port of the first device;
opening, by the first device based on identifying the first address and the second address:
a first gate for transmitting a first type of data associated with the call between the second device and a fourth device included in a third security zone, and
a second gate for transmitting a second type of data associated with the call between the second device and the fourth device;
generating, by the first device, a second message based on the first address and the second address;
forwarding, by the first device, the second message to the fourth device;
receiving, by the first device, a third message from the fourth device based on forwarding the second message;
determining, by the first device, that the third message is associated with the first message;
closing, by the first device and based on determining that the third message is associated with the first message, the second gate;
opening, by the first device and based on closing the second gate:
a third gate for transmitting, via the first device, the second type of data associated with the call between the second device and the third device, and
a fourth gate for transmitting, via the first device, the first type of data associated with the call between the third device and the fourth device; and
establishing, based on opening the third gate and the fourth gate, the call between the second device and the third device.
39. The method of claim 38 , where the first type of data comprises data associated with signaling messages associated with a VoIP session associated with the call and the second type of data includes media transmitted during the VoIP session.
40. The method of claim 38 , further comprising:
comparing a first value, included in a header of the third message, with a corresponding first value, included in a header of the first message; and
determining that the third message is associated with the first message based on comparing the first value included in the header of the third message with the corresponding first value included in the header of the first message.
41. The method of claim 40 , further comprising:
determining, based on the comparing, whether the first value, included in the header of the third message, matches the corresponding first value included in the header of the first message; and
dropping the third message when the first value, included in the header of the third message, does not match the corresponding first value, included in the header of the first message.
42. The method of claim 38 , where generating the second message includes:
translating the first address to obtain a third address, and
translating the second address to obtain a fourth address.
43. The method of claim 38 , where the first security zone is associated with a private network and the second security zone is associated with a public network.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/460,417 US20120216272A1 (en) | 2004-10-25 | 2012-04-30 | Routing voip calls through multiple security zones |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/971,687 US8200827B1 (en) | 2004-10-25 | 2004-10-25 | Routing VoIP calls through multiple security zones |
US13/460,417 US20120216272A1 (en) | 2004-10-25 | 2012-04-30 | Routing voip calls through multiple security zones |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/971,687 Continuation US8200827B1 (en) | 2004-10-25 | 2004-10-25 | Routing VoIP calls through multiple security zones |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120216272A1 true US20120216272A1 (en) | 2012-08-23 |
Family
ID=46177912
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/971,687 Active 2029-09-25 US8200827B1 (en) | 2004-10-25 | 2004-10-25 | Routing VoIP calls through multiple security zones |
US13/460,417 Abandoned US20120216272A1 (en) | 2004-10-25 | 2012-04-30 | Routing voip calls through multiple security zones |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/971,687 Active 2029-09-25 US8200827B1 (en) | 2004-10-25 | 2004-10-25 | Routing VoIP calls through multiple security zones |
Country Status (1)
Country | Link |
---|---|
US (2) | US8200827B1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100235481A1 (en) * | 2007-10-24 | 2010-09-16 | Lantronix, Inc. | Various methods and apparatuses for accessing networked devices without accessible addresses via virtual ip addresses |
US20120008619A1 (en) * | 2010-07-09 | 2012-01-12 | Cisco Technology, Inc. | Differentiation of multiple media endpoints behind an address translation device |
US8615562B1 (en) * | 2006-12-29 | 2013-12-24 | Google Inc. | Proxy for tolerating faults in high-security systems |
US11271899B2 (en) * | 2020-08-09 | 2022-03-08 | Perimeter 81 Ltd | Implementing a multi-regional cloud based network using network address translation |
Families Citing this family (94)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6658091B1 (en) | 2002-02-01 | 2003-12-02 | @Security Broadband Corp. | LIfestyle multimedia security system |
US9531593B2 (en) | 2007-06-12 | 2016-12-27 | Icontrol Networks, Inc. | Takeover processes in security network integrated with premise security system |
US10444964B2 (en) | 2007-06-12 | 2019-10-15 | Icontrol Networks, Inc. | Control system user interface |
US7711796B2 (en) | 2006-06-12 | 2010-05-04 | Icontrol Networks, Inc. | Gateway registry methods and systems |
US10348575B2 (en) | 2013-06-27 | 2019-07-09 | Icontrol Networks, Inc. | Control system user interface |
US10062273B2 (en) | 2010-09-28 | 2018-08-28 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
US11582065B2 (en) | 2007-06-12 | 2023-02-14 | Icontrol Networks, Inc. | Systems and methods for device communication |
US9609003B1 (en) | 2007-06-12 | 2017-03-28 | Icontrol Networks, Inc. | Generating risk profile using data of home monitoring and security system |
US11244545B2 (en) | 2004-03-16 | 2022-02-08 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US11113950B2 (en) | 2005-03-16 | 2021-09-07 | Icontrol Networks, Inc. | Gateway integrated with premises security system |
US10522026B2 (en) | 2008-08-11 | 2019-12-31 | Icontrol Networks, Inc. | Automation system user interface with three-dimensional display |
US10142392B2 (en) | 2007-01-24 | 2018-11-27 | Icontrol Networks, Inc. | Methods and systems for improved system performance |
US8963713B2 (en) | 2005-03-16 | 2015-02-24 | Icontrol Networks, Inc. | Integrated security network with security alarm signaling system |
US11677577B2 (en) | 2004-03-16 | 2023-06-13 | Icontrol Networks, Inc. | Premises system management using status signal |
US11811845B2 (en) | 2004-03-16 | 2023-11-07 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11277465B2 (en) | 2004-03-16 | 2022-03-15 | Icontrol Networks, Inc. | Generating risk profile using data of home monitoring and security system |
US10200504B2 (en) | 2007-06-12 | 2019-02-05 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
GB2428821B (en) | 2004-03-16 | 2008-06-04 | Icontrol Networks Inc | Premises management system |
US10721087B2 (en) | 2005-03-16 | 2020-07-21 | Icontrol Networks, Inc. | Method for networked touchscreen with integrated interfaces |
US11201755B2 (en) | 2004-03-16 | 2021-12-14 | Icontrol Networks, Inc. | Premises system management using status signal |
US11368429B2 (en) | 2004-03-16 | 2022-06-21 | Icontrol Networks, Inc. | Premises management configuration and control |
US10375253B2 (en) | 2008-08-25 | 2019-08-06 | Icontrol Networks, Inc. | Security system with networked touchscreen and gateway |
US11159484B2 (en) | 2004-03-16 | 2021-10-26 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US10313303B2 (en) | 2007-06-12 | 2019-06-04 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US20090077623A1 (en) | 2005-03-16 | 2009-03-19 | Marc Baum | Security Network Integrating Security System and Network Devices |
US11368327B2 (en) | 2008-08-11 | 2022-06-21 | Icontrol Networks, Inc. | Integrated cloud system for premises automation |
US11489812B2 (en) | 2004-03-16 | 2022-11-01 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US10339791B2 (en) | 2007-06-12 | 2019-07-02 | Icontrol Networks, Inc. | Security network integrated with premise security system |
US11316958B2 (en) | 2008-08-11 | 2022-04-26 | Icontrol Networks, Inc. | Virtual device systems and methods |
US9729342B2 (en) | 2010-12-20 | 2017-08-08 | Icontrol Networks, Inc. | Defining and implementing sensor triggered response rules |
US10237237B2 (en) | 2007-06-12 | 2019-03-19 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US9141276B2 (en) | 2005-03-16 | 2015-09-22 | Icontrol Networks, Inc. | Integrated interface for mobile device |
US10382452B1 (en) | 2007-06-12 | 2019-08-13 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US8635350B2 (en) | 2006-06-12 | 2014-01-21 | Icontrol Networks, Inc. | IP device discovery systems and methods |
US11343380B2 (en) | 2004-03-16 | 2022-05-24 | Icontrol Networks, Inc. | Premises system automation |
US11916870B2 (en) | 2004-03-16 | 2024-02-27 | Icontrol Networks, Inc. | Gateway registry methods and systems |
US10156959B2 (en) | 2005-03-16 | 2018-12-18 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US9191228B2 (en) | 2005-03-16 | 2015-11-17 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US8988221B2 (en) | 2005-03-16 | 2015-03-24 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
US20170180198A1 (en) | 2008-08-11 | 2017-06-22 | Marc Baum | Forming a security network including integrated security system components |
US20110128378A1 (en) | 2005-03-16 | 2011-06-02 | Reza Raji | Modular Electronic Display Platform |
US11496568B2 (en) | 2005-03-16 | 2022-11-08 | Icontrol Networks, Inc. | Security system with networked touchscreen |
US9450776B2 (en) | 2005-03-16 | 2016-09-20 | Icontrol Networks, Inc. | Forming a security network including integrated security system components |
US11700142B2 (en) | 2005-03-16 | 2023-07-11 | Icontrol Networks, Inc. | Security network integrating security system and network devices |
US11615697B2 (en) | 2005-03-16 | 2023-03-28 | Icontrol Networks, Inc. | Premise management systems and methods |
US9306809B2 (en) | 2007-06-12 | 2016-04-05 | Icontrol Networks, Inc. | Security system with networked touchscreen |
US20120324566A1 (en) | 2005-03-16 | 2012-12-20 | Marc Baum | Takeover Processes In Security Network Integrated With Premise Security System |
US10999254B2 (en) | 2005-03-16 | 2021-05-04 | Icontrol Networks, Inc. | System for data routing in networks |
US10079839B1 (en) | 2007-06-12 | 2018-09-18 | Icontrol Networks, Inc. | Activation of gateway device |
US8929360B2 (en) * | 2006-12-07 | 2015-01-06 | Cisco Technology, Inc. | Systems, methods, media, and means for hiding network topology |
US11706279B2 (en) | 2007-01-24 | 2023-07-18 | Icontrol Networks, Inc. | Methods and systems for data communication |
US7633385B2 (en) | 2007-02-28 | 2009-12-15 | Ucontrol, Inc. | Method and system for communicating with and controlling an alarm system from a remote server |
US8451986B2 (en) | 2007-04-23 | 2013-05-28 | Icontrol Networks, Inc. | Method and system for automatically providing alternate network access for telecommunications |
US11089122B2 (en) | 2007-06-12 | 2021-08-10 | Icontrol Networks, Inc. | Controlling data routing among networks |
US11316753B2 (en) | 2007-06-12 | 2022-04-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10616075B2 (en) | 2007-06-12 | 2020-04-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11423756B2 (en) | 2007-06-12 | 2022-08-23 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11646907B2 (en) | 2007-06-12 | 2023-05-09 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11212192B2 (en) | 2007-06-12 | 2021-12-28 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10423309B2 (en) | 2007-06-12 | 2019-09-24 | Icontrol Networks, Inc. | Device integration framework |
US10051078B2 (en) | 2007-06-12 | 2018-08-14 | Icontrol Networks, Inc. | WiFi-to-serial encapsulation in systems |
US11601810B2 (en) | 2007-06-12 | 2023-03-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10523689B2 (en) | 2007-06-12 | 2019-12-31 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11237714B2 (en) | 2007-06-12 | 2022-02-01 | Control Networks, Inc. | Control system user interface |
US11218878B2 (en) | 2007-06-12 | 2022-01-04 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10389736B2 (en) | 2007-06-12 | 2019-08-20 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10498830B2 (en) | 2007-06-12 | 2019-12-03 | Icontrol Networks, Inc. | Wi-Fi-to-serial encapsulation in systems |
US10666523B2 (en) | 2007-06-12 | 2020-05-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11831462B2 (en) | 2007-08-24 | 2023-11-28 | Icontrol Networks, Inc. | Controlling data routing in premises management systems |
US11916928B2 (en) | 2008-01-24 | 2024-02-27 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US20170185278A1 (en) | 2008-08-11 | 2017-06-29 | Icontrol Networks, Inc. | Automation system user interface |
US10530839B2 (en) | 2008-08-11 | 2020-01-07 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
US11758026B2 (en) | 2008-08-11 | 2023-09-12 | Icontrol Networks, Inc. | Virtual device systems and methods |
US11258625B2 (en) | 2008-08-11 | 2022-02-22 | Icontrol Networks, Inc. | Mobile premises automation platform |
US11729255B2 (en) | 2008-08-11 | 2023-08-15 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
US11792036B2 (en) | 2008-08-11 | 2023-10-17 | Icontrol Networks, Inc. | Mobile premises automation platform |
US9628440B2 (en) | 2008-11-12 | 2017-04-18 | Icontrol Networks, Inc. | Takeover processes in security network integrated with premise security system |
US20120144475A1 (en) | 2009-02-06 | 2012-06-07 | Sagemcom Canada, Inc. | Scalable nat traversal |
US8638211B2 (en) | 2009-04-30 | 2014-01-28 | Icontrol Networks, Inc. | Configurable controller and interface for home SMA, phone and multimedia |
US10200325B2 (en) * | 2010-04-30 | 2019-02-05 | Shazzle Llc | System and method of delivering confidential electronic files |
EP2569712B1 (en) | 2010-05-10 | 2021-10-13 | Icontrol Networks, Inc. | Control system user interface |
US8836467B1 (en) | 2010-09-28 | 2014-09-16 | Icontrol Networks, Inc. | Method, system and apparatus for automated reporting of account and sensor zone information to a central station |
US11750414B2 (en) | 2010-12-16 | 2023-09-05 | Icontrol Networks, Inc. | Bidirectional security sensor communication for a premises security system |
US9147337B2 (en) | 2010-12-17 | 2015-09-29 | Icontrol Networks, Inc. | Method and system for logging security event data |
US8872880B1 (en) * | 2011-12-30 | 2014-10-28 | Juniper Networks, Inc. | Video conference service with multiple service tiers |
US9928975B1 (en) | 2013-03-14 | 2018-03-27 | Icontrol Networks, Inc. | Three-way switch |
US9867143B1 (en) | 2013-03-15 | 2018-01-09 | Icontrol Networks, Inc. | Adaptive Power Modulation |
US9287727B1 (en) | 2013-03-15 | 2016-03-15 | Icontrol Networks, Inc. | Temporal voltage adaptive lithium battery charger |
US10841668B2 (en) | 2013-08-09 | 2020-11-17 | Icn Acquisition, Llc | System, method and apparatus for remote monitoring |
US11405463B2 (en) | 2014-03-03 | 2022-08-02 | Icontrol Networks, Inc. | Media content management |
US11146637B2 (en) | 2014-03-03 | 2021-10-12 | Icontrol Networks, Inc. | Media content management |
US9667665B1 (en) | 2015-02-25 | 2017-05-30 | Spring Communications Company L.P. | Session initiation protocol (SIP) communications over trusted hardware |
US9648617B2 (en) | 2015-08-24 | 2017-05-09 | Sprint Communications Company L.P. | Hardware-trusted orthogonal frequency division multiplex (OFDM) access to a shared common public radio interface (CPRI) |
US10972437B2 (en) * | 2016-08-08 | 2021-04-06 | Talari Networks Incorporated | Applications and integrated firewall design in an adaptive private network (APN) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5999525A (en) * | 1996-11-18 | 1999-12-07 | Mci Communications Corporation | Method for video telephony over a hybrid network |
US20020029350A1 (en) * | 2000-02-11 | 2002-03-07 | Cooper Robin Ross | Web based human services conferencing network |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6701432B1 (en) | 1999-04-01 | 2004-03-02 | Netscreen Technologies, Inc. | Firewall including local bus |
US6615236B2 (en) | 1999-11-08 | 2003-09-02 | Worldcom, Inc. | SIP-based feature control |
GB0107638D0 (en) * | 2001-03-27 | 2001-05-16 | Marconi Comm Ltd | Access networks |
US7072332B2 (en) * | 2001-09-27 | 2006-07-04 | Samsung Electronics Co., Ltd. | Soft switch using distributed firewalls for load sharing voice-over-IP traffic in an IP network |
US7274684B2 (en) * | 2001-10-10 | 2007-09-25 | Bruce Fitzgerald Young | Method and system for implementing and managing a multimedia access network device |
US6674758B2 (en) | 2002-06-06 | 2004-01-06 | Clinton Watson | Mechanism for implementing voice over IP telephony behind network firewalls |
US9497168B2 (en) * | 2002-07-30 | 2016-11-15 | Avaya Inc. | Method and apparatus for supporting communications between a computing device within a network and an external computing device |
US8166533B2 (en) | 2002-08-17 | 2012-04-24 | Rockstar Bidco Lp | Method for providing media communication across firewalls |
US7716725B2 (en) | 2002-09-20 | 2010-05-11 | Fortinet, Inc. | Firewall interface configuration and processes to enable bi-directional VoIP traversal communications |
KR100511479B1 (en) | 2002-12-27 | 2005-08-31 | 엘지전자 주식회사 | SIP service method in network with NAT |
TW200420021A (en) * | 2003-03-19 | 2004-10-01 | Etrunk Technologies Inc | Network packet routing control device |
US20040228291A1 (en) * | 2003-05-15 | 2004-11-18 | Huslak Nicolas Steven | Videoconferencing using managed quality of service and/or bandwidth allocation in a regional/access network (RAN) |
US7493393B2 (en) * | 2003-06-23 | 2009-02-17 | Nokia Corporation | Apparatus and method for security management in wireless IP networks |
US7694127B2 (en) * | 2003-12-11 | 2010-04-06 | Tandberg Telecom As | Communication systems for traversing firewalls and network address translation (NAT) installations |
US7620033B2 (en) * | 2004-05-21 | 2009-11-17 | Alcatel-Lucent Usa Inc. | Method for optimal path selection in traversal of packets through network address translators |
US20060026629A1 (en) * | 2004-07-30 | 2006-02-02 | Harris John C | Method for advertising via IP video telephone |
US7602748B2 (en) * | 2004-08-13 | 2009-10-13 | Verizon Business Global Llc | Fixed-mobile communications with mid-session mode switching |
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 |
US7319857B2 (en) * | 2004-09-13 | 2008-01-15 | Tekelec | Methods, systems, and computer program products for delivering messaging service messages |
-
2004
- 2004-10-25 US US10/971,687 patent/US8200827B1/en active Active
-
2012
- 2012-04-30 US US13/460,417 patent/US20120216272A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5999525A (en) * | 1996-11-18 | 1999-12-07 | Mci Communications Corporation | Method for video telephony over a hybrid network |
US20020029350A1 (en) * | 2000-02-11 | 2002-03-07 | Cooper Robin Ross | Web based human services conferencing network |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8615562B1 (en) * | 2006-12-29 | 2013-12-24 | Google Inc. | Proxy for tolerating faults in high-security systems |
US8959180B1 (en) | 2006-12-29 | 2015-02-17 | Google Inc. | Proxy for tolerating faults in high-security systems |
US20100235481A1 (en) * | 2007-10-24 | 2010-09-16 | Lantronix, Inc. | Various methods and apparatuses for accessing networked devices without accessible addresses via virtual ip addresses |
US20110246630A1 (en) * | 2007-10-24 | 2011-10-06 | Lantronix, Inc. | Various methods and apparatuses for accessing networked devices without accessible addresses via virtual ip addresses |
US20120008619A1 (en) * | 2010-07-09 | 2012-01-12 | Cisco Technology, Inc. | Differentiation of multiple media endpoints behind an address translation device |
US9178854B2 (en) * | 2010-07-09 | 2015-11-03 | Cisco Technology, Inc. | Differentiation of multiple media endpoints behind an address translation device |
US11271899B2 (en) * | 2020-08-09 | 2022-03-08 | Perimeter 81 Ltd | Implementing a multi-regional cloud based network using network address translation |
Also Published As
Publication number | Publication date |
---|---|
US8200827B1 (en) | 2012-06-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8200827B1 (en) | Routing VoIP calls through multiple security zones | |
US7826602B1 (en) | Enabling incoming VoIP calls behind a network firewall | |
US8825822B2 (en) | Scalable NAT traversal | |
US9860215B2 (en) | Firewall interface configuration to enable bi-directional VoIP traversal communications | |
US7509425B1 (en) | Establishing and modifying network signaling protocols | |
US8166533B2 (en) | Method for providing media communication across firewalls | |
US7830886B2 (en) | Router and SIP server | |
US8208412B2 (en) | Method and system for network address translation (NAT) traversal of real time protocol (RTP) media | |
US20050286538A1 (en) | Method and call server for establishing a bi-directional peer-to-peer communication link | |
US9723031B2 (en) | Connection control with B2BUA located behind NAT gateway | |
US8649372B2 (en) | Call set-up systems | |
US8374178B2 (en) | Apparatus and method for supporting NAT traversal in voice over internet protocol system | |
Guang et al. | Research and Implementation of NAT Traversal for SIP in Softswitch | |
Παπουτσή | VOIP (Voice Over IP)-transportation and signalling of voice communications over ip networks-implementation using Asterisk |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |