Patent Publication Number: US-2012027008-A1

Title: Addressing Techniques For Voice Over Internet Protocol Router

Description:
RELATED APPLICATIONS 
     This application is a continuation-in-part of application Ser. No. 12/180,432 (attorney docket no. 14570), filed Jul. 25, 2008, from which priority is claimed under 35 U.S.C. §120. Application Ser. No. 12/180,432 is in turn a continuation of application Ser. No. 10/270,809 (attorney docket no. 06476, now U.S. Pat. No. 7,417,978), filed Oct. 14, 2002. Application Ser. No. 10/270,809 is in turn related to provisional application Ser. No. 60/338,077, filed Nov. 30, 2001, and provisional application Ser. No. 60/329,015, filed Oct. 12, 2001, from which it claims priority under 35 U.S.C. §119(e). Application Ser. Nos. 12/180,432, 10/270,809, 60/338,077, and 60/329,015 are hereby incorporated by reference. 
    
    
     BACKGROUND 
     A. Technical Field 
     The present invention relates generally to computer network protocols, and more particularly, to addressing and delivery of voice packets within a Voice over Internet Protocol (VoIP) connection. 
     B. Background of the Invention 
     The popularity of VoIP as a method for providing telephone service across networks is continually increasing. VoIP systems provide telephone connections by transmitting voice packets between two telephone devices via a packet-switched network (e.g., TCP/IP network). This increase in VoIP popularity is primarily due to two reasons: the relatively inexpensive cost of a VoIP telephone call and recent networking advancements causing an increase in the quality of VoIP communication. 
     VoIP lets service providers offer long-distance services to clients at much lower rates than traditional phone companies. VoIP also uses networks more efficiently than the traditional public switched telephone network used by the traditional phone companies. One reason for this increase in efficiency is the ability of VoIP to time-division multiplex voice data (i.e., telephone connections) together on a single line within a network. Thus, the bandwidth utilization increases within a packet switched network allowing more telephone connections to occur simultaneously. 
     A few years ago, the quality of a VoIP connection was lacking due primarily to packet delay occurring as voice packets traveled across these networks. This problem was primarily caused by the inefficiency of the Internet over which the VoIP connections occurred. Internet events such as bottlenecks, jitters and discarding packets reduced the quality of a VoIP telephone conversation occurring across the Internet. However, the increase of large private networks, more controlled Internet backbones, and more efficient routing protocols have greatly reduced these problems. Accordingly, the quality of a VoIP telephone conversation today has drastically improved. Some providers have also chosen to avoid the public Internet because of the difficulty in ensuring end-to-end control of service quality. These providers have created managed networks on which VoIP connections may be easily controlled and new VoIP technology may be more easily implemented. As the popularity of VoIP continues to grow, other issues need to be addressed, such as security, network interoperability and compatibility, to ensure the future success of VoIP. 
       FIG. 1  illustrates a traditional VoIP connection using the public Internet  130 . A first telephone  105  is coupled to a first gateway  110  via a first analog connection  107 . A second telephone  115  is coupled to a second gateway  120  via a second analog connection  117 . A computer or other computing device (not shown) may reside between the telephones  105 ,  115  and the gateways  110 ,  120 . Accordingly, the analog signal from the telephone  105 ,  115  is converted to a digital format by these computers (not shown). The first gateway  110  and the second gateway  120  are coupled to each other via the Internet  130 . Additionally, the telephones  105 ,  115  may be digital telephones, such as ISDN phones or VoIP phones, that convert an audible signal to a digital signal prior to transmission to a gateway. A gatekeeper  140  may be used to set up the telephone connection. 
     The telephone connection is established by the first gateway  110  receiving a connection request from the first telephone  105  that includes a destination telephone number. This destination telephone number may be a ten-digit telephone number similar to those used over traditional publicly switched telephone networks. In response, the first gateway  110  requests a destination network address from the gatekeeper  140  corresponding to the destination telephone number. This conversion allows the first gateway  110  to locate the second gateway  120  on the Internet  130 . Typically, this conversion results in a network address, such as an IP address that differentiates the second gateway  120  from other gateways on the Internet  130 . 
     A set-up procedure is initiated by the first gateway  110  in which the second gateway  120  is provided the address of the first gateway  110 . This set-up procedure results in a connection on which data, particularly voice packets and control data, are transmitted between the gateways  110 ,  120 . This data may travel through multiple networks and multiple routers/switches within these networks in order to reach the correct destination. As described above, oftentimes the quality of this connection is lacking due to the characteristics of the Internet  130 . Congestion and failures, within these networks, may drastically reduce the rate at which this data travels in an established connection and may increase the number of packets that are lost or discarded prior to reaching a particular destination address. 
     The established connection between the first gateway  110  and the second gateway  120  presents various security concerns. A large number of these issues are caused by the visibility of the gateways  110 ,  120  within the connection. Specifically, the IP addresses of the gateways  110 ,  120  are known by each other. This visibility compromises the security of all of the devices attached to a network having a visible gateway. Accordingly, a hacker may access devices on the network, other than the telephone or computer participating in the connection, through the gateways  110 ,  120 . For example, after gaining access to the network through a gateway  110 ,  120 , a hacker may access an unauthorized networked device through techniques such as IP spoofing or other commonly used hacking methods. Accordingly, network providers prefer to mask their gateway addresses from outside devices in order to further secure the network against hacking and other unauthorized access to their networks. 
       FIG. 2  illustrates the use of prior art proxies  235 ,  240  to mask gateway addresses within a VoIP connection. An example of these types of proxies would be a firewall such as the Cisco PIX firewall. Other network devices such as proxy servers and SOCK (TCP/IP Socket) servers may be used to build firewalls or other masking devices. Network security problems (e.g., hacking) are amplified when a publicly accessible or visible gateway is connected as part of a larger private network. The visibility of a gateway may allow individuals to hack into the large private network and cause a large amount of damage by accessing other devices connected to the network. Oftentimes, a device on a network, such as storage and computing devices, is not sufficiently protected from access within the network. Thus, if a hacker gains access to a network through a gateway, then other devices on that network may be extremely vulnerable and easily accessed by the hacker. Accordingly, private network operators prefer that internal gateway addresses be hidden from external network devices, such as external gateways. Proxies are used to accomplish this goal. 
     The first telephone  105  is connected to a first network gateway  212 ( a ) via first analog connection  107 . This first network gateway  212 ( a ) resides in a large private network  210  that contains multiple gateways  212 ( a )-( d ). The second telephone  115  is connected to a second network gateway  222 ( a ) via second analog connection  117 . This second network gateway  222 ( a ) resides in a second large private network  220  that also contains multiple gateways  222 ( a )-( d ). The first gateway  212 ( a ) is coupled to a first proxy  235  and the second gateway  222 ( a ) is coupled to a second proxy  240 . 
     The first and second proxies  235 ,  240  hide the addresses of the first and second gateways  212 ( a ),  222 ( a ) from each other. Specifically, the first proxy  235  is aware of the network addresses of the first gateway  212 ( a ) and the second proxy  240 , but not the second gateway  222 ( a ). The second proxy  240  is aware of the network addresses of the second gateway  222 ( a ) and the first proxy  235 , but not the first gateway  212 ( a ). Thus, communication between devices on the first network  210  and the second network  220  occur through the proxies  235 ,  240  while maintaining a level of privacy from each other. 
     The first and second proxies  235 ,  240  require that packets traveling through the VoIP connection may be modified multiple times. Specifically, in order for the first and second proxies  235 ,  240  to extract and analyze information from a packet header (e.g., port number). Once this information is extracted, a new header is usually put on the packet and it is compressed. Thereafter, the packet is transmitted from a proxy. Because voice packets travel through multiple proxies  235 ,  240 , the number of packet manipulation operations increases. Thus, there is a need to reduce the number of proxy devices within a VoIP connection. This need is further highlighted by the high cost of networking devices such as proxy devices. 
     Communication between the first proxy  235  and the second proxy  240  may occur using an IP suite protocol implementing either TCP or UDP depending on the type of data within packets. UDP is generally used for VoIP telephone connections due to the time sensitivity of the VoIP connection. Accordingly, sockets are established between the first and second proxies  235 ,  240 . A socket is a combination of an IP address and a port that creates a device-to-device path on which packets may be transmitted and received. Thus, a proxy or other networking device may have numerous ports that provide communication paths on which packets may travel. 
     Oftentimes, a simple packet translation method will not properly switch a voice packet along a VoIP connection. For example, this switching process may be complicated if the networks on which the first and second gateways  212 ( a ),  222 ( a ) are not directly compatible. Generally, voice traffic is transmitted according to the H.323 standard, an ITU real-time standard for transmission of voice over networks. However, there are variations in the implementation of the H.323 standard by network providers that may cause incompatibilities between networks. These variations often require packet modification operations to occur within a proxy to provide smooth voice traffic between the incompatible networks. 
     In order to perform packet translation and switching operations in connections between to directly incompatible networks, a proxy must be able to identify the type of network from which the packet was sent and to which the packet is destined. Also, the proxy must be able to identify the packet type (e.g., RTP) in order to perform packet translation and switching operations. Once this information is identified, the proxy may modify the packet so that it is able to effectively travel through a network to a destination gateway. 
     As previously described above, it is important to try and reduce the number of switches, routers and other networking devices within a VoIP connection for two primary reasons. First, networking devices are expensive and the initial cost as well as the management cost may be significant. Second, each networking device increases the possibility of errors such as packets being discarded or failure as well as causes an additional delay within a VoIP connection. As a result, researchers have been developing technology that reduces the number of networking devices within a network. 
     Accordingly it is desirable to provide network address translation within a network device that masks both ends of a VoIP connection from each other. Additionally, it is desirable to provide network address translation within a network device that facilitates VoIP connections between different types of networks and that processes different types of packets within a VoIP connection. Furthermore, it is desirable to provide network address translation within a network device that increases the number of VoIP connections that may be served by the network device. It is additionally desirable to allow the dynamic allocation of ranges of ports within the network device for use with a VoIP connection. It is still further desirable to allow components of the network device to learn gateway addresses in the presence of intervening firewalls. 
     SUMMARY OF THE INVENTION 
     The present invention overcomes the deficiencies and limitations of the prior art by providing a set of commands used by a voice connector for dynamically allocating port ranges within a voice switch. The present invention further accounts for network address translation performed by intermediary network devices such as firewalls by providing a Connect command used by the voice connector to inform the voice switch of possible addresses used by the intermediary network device. The voice switch then applies bitmasks specified by the Connect command to incoming voice packets from unknown addresses to determine whether the packets are being sent from known firewalls, in which case the packets are accepted and corresponding addresses learned. 
     In one embodiment, a voice router for dynamically allocating port ranges comprises a voice connector adapted to initiate a connection between a first network gateway and a second network gateway and a voice switch adapted to route voice data between the first network gateway and the second network gateway. The voice connector sends a request for a plurality of ports to the voice switch and, responsive to the request, the voice switch allocates a number of ports, creates a corresponding entry in a port range table, and provides to the voice connector a response comprising an identifier of the port range. 
     In another embodiment, a voice router for routing packets in the presence of a firewall comprises a voice connector adapted to initiate a voice connection between a first network gateway and a second network gateway and a voice switch adapted to route voice data between the first network gateway and the second network gateway. The voice connector sends a connect packet to the voice switch, the connect packet specifying the IP address of the first network gateway and an address bitmask. Responsive to the voice switch receiving from the first network gateway, via the firewall, a first voice packet having a first packet source IP address, the voice switch computes a first masked value resulting from a bitwise AND of the address bitmask and the first packet source IP address, and computes a second masked value resulting from a bitwise AND of the address bitmask and an IP address of the first network gateway. Responsive to the first masked value being equal to the second masked value, the voice switch stores the first packet source IP address in association with the IP address of the first network gateway and forwards the first voice packet to the second gateway. 
     The features and advantages described in this summary and the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is an illustration of a prior art VoIP connection using the Internet. 
         FIG. 2  is an illustration of a prior art VoIP connection using multiple proxies. 
         FIG. 3  is an illustration of communication ports between multiple proxies within a VoIP connection. 
         FIG. 4A  is an illustration of a VoIP connection using a voice router and the corresponding IP ports on the voice router according to the present invention. 
         FIG. 4B  is an illustration of an exemplary port allocation range used within a voice router during a VoIP connection. 
         FIG. 4C  is an illustration of a port grouping (tuple) used for port allocation. 
         FIG. 5A  is an illustration of a VoIP connection using a single voice router with a reduced number of IP ports. 
         FIG. 5B  is a block diagram of modules operating within a voice switch according to one embodiment of the present invention. 
         FIG. 5C  is a block diagram of modules operating within a voice connector used to set up a VoIP connection according to one embodiment of the present invention. 
         FIG. 5D  is an illustration of a VoIP connection using a single voice router between two networks. 
         FIG. 6A  is an illustration of network type identifiers within a port number field. 
         FIG. 6B  is an exemplary table of bits corresponding to network types. 
         FIG. 7A  is an illustration of an exemplary network pair table that may be used to identify network types of gateways in a VoIP connection. 
         FIG. 7B  is an illustration of an exemplary network type table for associating an IP address with a network type. 
         FIG. 7C  depicts a network pair table in which a voice connector ID field identifies a voice connector to which a port range has been allocated. 
         FIG. 7D   FIG. 7D  depicts the states through which a given port range may pass in an embodiment in which port ranges are dynamically allocated. 
         FIG. 8A  is a block diagram of a voice connector containing the network pair table. 
         FIG. 8B  is a block diagram of a voice switch containing the network pair table. 
         FIG. 9  is a block diagram of a packet direction identification module according to an embodiment of the present invention. 
         FIG. 10  is a flowchart of a network address translation operation according to an embodiment of the present invention. 
         FIG. 11  depicts a scenario in which a firewall is added between a network gateway and a voice router. 
         FIGS. 12A and 12B  illustrate steps performed as part of the sending and use of a Connect command used in the presence of the firewall of  FIG. 11 . 
     
    
    
     The figures depict a preferred embodiment of the present invention for purposes of illustration only. One skilled in the art will recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein. 
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The present invention describes a network router/bridging device that interfaces networks within a VoIP connection and masks the location of each network from the other. This device is able to interface networks implementing different H.323 protocols (or SIP protocol) and reduces the number of ports required for this connection. Specifically, the device provides a novel network address translation module and network-type identification module that facilitates a VoIP connection between these networks. The novel network address translation module increases the number of VoIP connections the networking device may route or switch by reducing the number of ports required for each individual connection. According to one embodiment of the invention, only one port on the networking device is required for each VoIP connection. This reduction in the number of required ports is provided by an address translation that is able to set-up a VoIP connection on a single port that determines the direction of a packet received at a single bi-directional port and able to identify the type of network to which the packet is destined. 
     A. VoIP Connection Using a Single Voice Router 
       FIG. 3  illustrates a first embodiment of proxies  335 ,  340  that connect two gateways  312 ,  322  within a VoIP connection. A first gateway  312  is coupled to a first proxy  335 . A second gateway  322  is coupled to a second proxy  340 . The first proxy  335  is coupled to the second proxy  340 . The proxies  335 ,  340  effectively mask the two IP addresses of the gateways  312 ,  322  from each other during both the set-up of the VoIP connection and after the VoIP connection has been established. 
     A first port configuration according to the present invention between the two proxies  335 ,  340  is shown. Audio communication between the two proxies  335 ,  340  occurs over 4 ports. A first port, port N  310 , receives Real-time Transport Protocol (RTP) packets at the first proxy  335  from the second proxy  340 . A second port, port M  315 , receives RTP packets at the second proxy  340  from the first proxy  335 . Ports N  310  and M  315  may also be assigned the same port number or different port numbers depending on the implementation of the connection. A third port, port R  330 , receives Real-time Transport Control Protocol (RTCP) packets at the first proxy  335  from the second proxy  340 . A fourth port, port S  325 , receives RTCP packets at the second proxy  340  from the first proxy  335 . Port R  330  and port S  325  may be assigned the same port number or different port numbers depending on the implementation of the connection. Each of these ports (i.e., N, M, R, and S) along with an IP address of a corresponding proxy (i.e.,  335  or  340 ) creates a socket on which packets flow. Thus, the proxies  335 ,  340  may identify the source of a packet by listening on the specific port number corresponding to the transmitting source. The proxies  335 ,  340  have a limited number of ports and addresses that they may use. Accordingly, as the number of ports that are used for each connection increases, the number of total connections that a proxy can serve decreases. 
     After one of the proxies  335 ,  340  receives a packet, it will forward the packet onto a corresponding gateway  312 ,  322  via an additional port. For example, a RTP voice packet received by the first proxy  335  on port N  310  is forwarded on to the first gateway  312  on port A  350 . Comparatively, an RTP voice packet received by the second proxy  340  on port M  315  is forwarded on to the second gateway  322  on port B  360 . A similar method is used for RTCP packets where packets transmitted onto port R  330  for the first proxy  335  and on port S  325  for the second proxy are forwarded onto a corresponding gateway via particular ports (not shown). The usage of ports by proxies and gateways can vary depending on the design of the private networks and network interconnectivity. 
       FIG. 4A  illustrates a VoIP connection that implements a single voice router  400  to mask the addresses of the first network gateway  212 ( a ) and the second network gateway  222 ( a ), and facilitate the connection between the two gateways  212 ( a ),  222 ( a ). The term “voice router” is not limited to a traditional definition of a router; rather, a bridge, router, switch or other network interfacing device may be included in the scope of voice router according to the present invention. As mentioned above, these gateways  212 ( a ),  222 ( a ) may reside in either a public or private network. This particular voice router  400  uses four ports to transmit and receive voice packets between the two gateways  212 ( a ),  222 ( a ). RTP packets arriving from the first network gateway  212 ( a ) are received on port N  405  of the voice router  400 . The voice router  400  then forwards these packets onto the corresponding port (port M  410 ) of the voice router  400 , then to the second network gateway  222 ( a ). RTP packets flowing in the opposite direction are received from the second network gateway  222 ( a ) on port M  410  of the voice router. The voice router  400  forwards these packets onto the corresponding port (port N  405 ) of the voice router then to the first network gateway  212 ( a ). 
     The voice router  400  also manages RTCP packet streams between the first and second network gateways  212 ( a ),  222 ( a ) in a similar manner. Specifically, RTCP packets from the first network gateway  212 ( a ) arrive on port R  425  at the voice router  400 . These packets are forwarded onto the corresponding port (port S  420 ) of the voice router  400  and then to the second network gateway  222 ( a ). RTCP packets from the second network gateway  222 ( a ) are received on port S  420  at the voice router  400 . These packets are then forwarded onto the corresponding port (port R  425 ) of the voice router  400  and then to the first network gateway  212 ( a ). 
     This embodiment of the present invention does not require the module responsible for the H.323 protocol (or SIP protocol), in particular the H.245 logical channel negotiation, to inform the voice router  400  of the IP addresses and ports used for both the gateways  212 ( a ),  222 ( a ). As a result, the information exchange between the H.323 protocol handling module and voice router  400  is reduced. 
     This four-port configuration allows the voice router  400  to identify the direction of the packet streams between the first network gateway  212 ( a ) and the second network gateway  222 ( a ) by the port on which a packet arrives. Packet direction is discovered by identifying the source of the packet and using the source identification to determine a destination corresponding to the source. Specifically, the voice router  400  is aware of the connections that it serves and may determine a destination of a packet by identifying the port on which the packet arrived. Additionally, the four-port configuration provides for communication between the two network gateways  212 ( a ),  222 ( a ) in two different protocols, namely RTP and RTCP. However, as described above, this high port count also limits the number of VoIP connections that the voice router  400  can support. 
       FIG. 4B  illustrates an example of a port configuration according to the present invention. A range of IP ports  450  is shown that may be assigned for different types of packet transmission. For example, ports may be assigned to a VoIP connection and divided into ports that service RTP packets and others that service RTCP packets. A first tuple  455  may be assigned port values  10000  to  10003 , a second tuple  1460  may be port values  10004  to  10007 , and a third tuple  465  maybe assigned port values  10008  to  10011 . These ports within the tuples  455 ,  460 ,  465  may be assigned to serve different types of data streams within the VoIP connection. Referring also to  FIG. 4C , for example, a tuple  470  assigned to a VoIP connection may have a first port (e.g., port N) assigned for an RTP stream  475  to or from a first gateway  212 ( a ) and a second port (e.g., port R) assigned for an RTCP stream to/from the first gateway  212 ( a ). A third port (e.g., port M) may be assigned for an RTP stream  485  to/from a second gateway  222 ( a ) and a fourth port (e.g., port S) may be assigned for an RTCP stream  490  to/from the second gateway  222 ( a ). As a result, the port tuple  470  may serve both RTP and RTCP within a VoIP connection. 
     According to one embodiment, the ports may be assigned according to the types of networks involved in the VoIP connection. For example, if the voice router  400  is positioned between a private network and the public Internet, then the port assignment may occur in the following manner. The first port is pre-assigned for the RTP stream originating from a gateway on the public Internet. The second port is pre-assigned for the RTCP stream originating from the gateway on the public Internet. The third port is pre-assigned for the RTP stream originating from a gateway in the private network. The fourth port is pre-assigned for the RTCP stream originating from the gateway in the private network. 
     Referring to the above described port configuration, when the voice router  400  receives a first UDP packet of the RTP stream from the private network, it reads the source IP address and port number within the UDP packet. This address is the transmitting gateway&#39;s IP address and the port number is the port on which the packet arrived. In this example, the packet originated at a private network, and therefore, the port number would be the third port number within the tuple, as described above. This private gateway address is stored with the voice router  400  and will be used to transmit packets from the public Internet to the correct destination private network within the particular VoIP connection. A similar method may be used when an RTP packet arrives from the public Internet destined to a particular private network. As a result of this process, the voice router  400  is able to help create and maintain a VoIP connection. 
     a) Port Reduction on the Single Voice Router 
       FIG. 5A  is an illustration of a voice router  500  having a voice switch  585  and a voice connector  570 . According to another embodiment (not shown) of the present invention, the voice switch  585  and voice connector  570  may be physically separate. The voice switch  585  requires only two ports for each VoIP connection after the voice connector  570  establishes the connection. This voice switch  585  switches RTP voice packets between the first gateway  212 ( a ) and the second gateway  222 ( a ) on a single port N  505 . However, those skilled in the art will recognize while only a single port is used, two sockets can be created. (The first socket is the IP address and port number of the first gateway  212 ( a ) and the second socket is the same port N and the IP address of the second gateway  222 ( a )). In order for the voice switch  585  to accurately forward packets on to the correct destination (i.e., the first network gateway  212 ( a ) or the second network gateway  222 ( a )) in the VoIP connection, the direction or source address of each packet must be identified. This identification requirement is complicated by the fact that the voice switch  585  is receiving data from both the first and second network gateways  212 ( a ),  222 ( a ) on the same port N  505 . A solution to this identification requirement is later described in detail. 
     The voice connector  570  is used to set-up a VoIP connection. The voice connector  570  may be integrated within the voice switch  585 , as shown in  FIG. 5A , or physically separate from the voice switch  585 . The voice connector  570  is connected to the first network gateway  212 ( a ). The voice connector  570  is also connected to the second gateway network  222 ( a ). A VoIP call set-up is initiated by either the first or second network gateways  212 ( a ),  222 ( a ) requesting a connection to the other network gateway. Typically, this request occurs on a particular port on the voice connector  570 . For example, the first network gateway  212 ( a ) may request a connection on port F  565 . The second network gateway  222 ( a ) may request a connection on port G  575 . Port F  565  and port G  575  may have the same port number or have different numbers depending on the design and type of the first and second networks  212 ( a ),  222 ( a ). The voice connector  570  listens on port F  565  for call set-up requests from the first network gateway  212 ( a ) and listens on port G  575  for call set-up requests from the second network gateway  222 ( a ). 
     A call set-up request contains information regarding the desired VoIP connection including destination information such as an address. An address, such as a ten-digit telephone number, within this request is translated by the voice connector  570  into a destination IP address. This translation may occur by accessing a gatekeeper that is either public or operating within a private network and is masked from the requesting gateway. Once this address translation occurs, the voice connector  570  creates a virtual connection between the two network gateways  212 ( a ),  222 ( a ) by assigning a port or ports on which this VoIP communication will occur. Once these ports are assigned, this information is transmitted to the voice switch  585  and to the network gateways  212 ( a ),  222 ( a ). Sockets, an IP address and port number, are established between the different networking devices and the voice switch  585 . Voice packets are then transmitted between the first and second gateways  212 ( a ),  222 ( a ) on these sockets. 
     The VoIP connection may also comprise networking devices that may adjust the connection configuration and port number assignments within the connection. For example, firewalls or other network servers having corresponding addresses and port numbers may be included to enhance security or add other functionality within the connection. Accordingly, the number of sockets may increase within the connection to facilitate the inclusion of these devices. 
     The voice switch  585  is able to identify these packets by extracting source information contained within the packet header. Specifically, the voice switch  585  extracts and analyzes the IP source address within the packet header in order to correctly switch the packet to the correct network gateway. This analysis may be done using a number of different methods. For example, the extracted IP source address may be compared to an IP address of either the first network gateway  212 ( a ) or the second network gateway  222 ( a ). If the extracted IP source address matches the compared network gateway address (address for gateway  212 ( a )), then the packet is forwarded accordingly (e.g., to gateway  222 ( a ) with a new header having a source IP address of the voice router  500  and a destination IP address of gateway  222 ( a )). However, if the two addresses do not match, then packet is forwarded to the other network gateway (e.g., to gateway  212 ( a )) by default because only two possible destination gateways exist within the VoIP connection. Specifically, a buffer may be maintained within the voice switch  585  that maintains these two addresses to which a source address in a packet header is compared. Thus, the voice switch  585  is able to reduce the number of ports required to maintain a RTP VoIP connection and still maintain correct packet flow within this connection with the implementation of this novel address translation. This packet direction identification is discussed in greater detail below with reference to  FIG. 9 . 
     The voice switch  585  also reduces the number of RTCP ports on the VoIP connection. Specifically, as with RTP port reduction, the number of required RTCP ports is reduced from two to one for each voice connection. The RTCP protocol is a companion protocol to RTP and is used to provide control and quality of service data to various devices within a connection. There are typically less RTCP packets transmitted by a gateway than RTP packets. The functionality provided by RTCP data may be compensated, at least to a particular level, internally within the voice switch  585 . Because so few RTCP packets are transmitted from a gateway and the lost functionality of discarded RTCP packets may be minimized by the voice switch  585 , discarded RTCP packets typically do not have a significant effect on the quality of a VoIP connection using the voice switch  585 . 
     The voice switch  585  discards RTCP packets after they are received on port M  510  in order to further reduce the port count of a VoIP connection. Because the number of RTCP connections is reduced from two to one for each voice connection, the number of available ports on the voice switch  585  drastically increases. It is important to note that the voice switch  585  needs to have at least one RTCP port  510  on which RTCP packets arrive. For example, if the voice switch  585  did not have the RTCP port  510 , then bounce-backs or acknowledgements would be transmitted from the voice switch  585  to a gateway transmitting RTCP packets. This bounce-back or acknowledgement would signal the transmitting gateway that there are no available RTCP ports on the voice switch  585 . This acknowledgement presents a security risk to the voice switch  585  and attached network because hackers would be able to listen to particular ports on the voice switch  585 . Thus, the single aggregating RTCP stops this acknowledgement and increases security on the voice switch  585 . 
       FIG. 5B  illustrates hardware or software modules operating within the voice switch  585 . These modules provide packet-forwarding functionalities to the voice switch  585  that reduce the number of ports required for a VoIP connection. According to this embodiment of the present invention, a packet is received on port N  505 . The packet is transmitted through the voice switch  585  to a packet translation module  580 . The packet translation module communicates with a network type identification module  550  and a packet direction identification module  560 . The packet direction identification module  560  identifies the direction of a packet traveling on the bi-directional port N  505 . One method for performing this direction identification is extracting the source address or destination port from a packet and comparing to the known source addresses or destination ports on the VoIP connection. These methods will be discussed in greater detail below. 
     The network type identification module  550  identifies a network type corresponding to a packet&#39;s destination gateway and source gateway. This identification also allows the voice switch  585  to ensure that the transmitted packet is compatible with the destination gateway (e.g., a packet is transmitted on the correct port number and to the correct destination port). There are multiple methods by which these gateways may be identified. First, this information may be embedded within header fields, such as port numbers, within the packet. Second, ports may be assigned according to the types of gateways in the VoIP connection. Both of these methods are described in greater detail below. 
     The packet translation module  580  receives information regarding the source and destination network types and the packet direction in order to correctly identify an appropriate packet translation operation(s). The packet translation module  580  ensures that the packet is transmitted on the correct port number so that it is compatible with the destination gateway. Specifically, the packet translation module  580  inserts the correct IP address of the destination gateway and the correct port number on the destination gateway within the packet header. The prior packet header may have been already discarded or be discarded by the packet translation module  580  prior to or after a new header is placed on the packet. These packet translation operations will be described in greater detail below. 
       FIG. 5C  is a block diagram of a voice connector  570  used to establish a VoIP connection. As previously described, the voice connector  570  establishes a connection after receiving a call set-up request from a gateway. The voice connector  570  receives these requests on particular ports (e.g., ports F and G). In response to this request, the voice connector  570  creates a virtual path between the two gateways corresponding to the IP addresses of the two gateways  221 ,  222  and an assigned port(s) given to devices within this connection. The voice connector  570  assigns this port or ports corresponding to the connection and notifies networking devices within this connection of this port(s). As a result, packets may be forwarded by these devices on correct VoIP connections that are identified by a corresponding port(s). 
     A network address translation module  598  is implemented within the voice connector  570  to provide translation of a call set-up request in order to properly establish a VoIP connection. This translation may require accessing an external gatekeeper or may be done internally within the voice connector  570 . As described above, the network address translation module  598  receives a request from a gateway  212  or  222  to make a connection. This request typically identifies the other side of the connection by a ten-digit telephone number or other identifying number. The network address translation module  598  uses a database to translate this ten-digit telephone number to an IP address. This translation may be done internally within the network address translation module  598  or may be done externally by addressing a public or private gatekeeper to translate the telephone number to an IP address. As a result of this process, the voice connector  570  will have identified the IP addresses of both the requesting gateway (i.e., from the call set-up request) and the destination gateway (i.e., from the above-described translation). 
     A port initialization module  595  within the voice connector  570  is used to assign ports to particular VoIP connections. The port initialization module  595  communicates with the network address translation module  598 . In response to a VoIP connection request, the port initialization module  595  assigns a port or ports on which packets will travel between the two gateways. This port information is then transmitted to both gateways, for example, using port G  565  and port F  575 , and the voice switch  585  via line  588 . Accordingly, the voice switch  585  will be able to identify a packet by listening on a particular port(s). For example, the first and second gateways  212 ( a ),  222 ( a ) are told to transmit voice packets on port N  505  to the voice switch  585 . This port information is also transmitted to the voice switch  585  along line  588 . As a result, the voice switch  585  is able to identify packets within this particular connection by listening on port N  505 . 
     The port initialization module  595  may assign these ports in relation to the gateway types of the gateways  212 ,  222 . The port initialization module  595  may access a network pair table  590  in order to assign ports from port ranges corresponding to the gateway type connections. For example, if the first gateway  212 ( a ) has a first gateway type (e.g., Cisco, Clarent, etc.) then the port initialization module  595  may select a port from a range of ports (e.g.,  3000 - 4000 ) corresponding to that first gateway type. Thereafter, when voice packets are actually transmitted on these ports within the connection, the voice switch  585  can identify the gateway type of the gateway/network that transmitted the packet. In one embodiment, the voice connector  570  does not rely on a static network pair table  590  to provide the port ranges, but instead uses a port allocation module  599  to establish the port ranges on demand, as further described below. 
     In another embodiment, the port initialization module  595  may assign these ports in relation to the physical locations of the gateways. For example, the network pair table  590  may contain ranges of port values corresponding to physical locations of gateways. Thus, if the first gateway  212 ( a ) is physically located in China, then the port initialization module  595  may select a port from a range of ports (e.g.,  5000 - 6000 ) corresponding to that physical location. Thereafter, when voice packets are actually transmitted on the ports within the connection, the voice switch  585  can identify the physical location of the gateway/network that transmitted the packet. 
     As described above, VoIP connections between multiple networks typically follow the H.323 standard. However, various interpretations of this standard by network service providers may present compatibility issues between two separate networks. For example, a Clarent H.323-based network may have difficulty directly mapping to a Cisco H.323-based network due to slight protocol variations between the two networks. For example, port assignment protocols between a Cisco H.323-based network and the voice switch  585  may differ from those between a Clarent H.323-based network and the voice switch  585 . In such an occurrence, the voice switch  585  may perform an additional step within the packet translation operation (e.g., compensate for differing port assignment protocols) between the two networks in order to ensure proper communication. In order to correctly perform this translation, the voice switch  585  should identify both the gateway type of the gateway from which the packet was sent and the gateway type of the gateway to which the packet is destined.  FIG. 5D  illustrates an example of this network incompatibility and corresponding packet translation required for proper communication. 
     The first network gateway  212 ( a ) resides on the first network  210  with corresponding first network type—e.g., a Clarent network. This first type of network requires that H.323 compatible packets be transmitted from a port X on the first gateway  212 ( a ) to a port N  505  of the voice switch  585  and for H.323 compatible packets to be transmitted from the port N  505  on the voice switch  585  to the a port X+2 on the first gateway  212 ( a ). In comparison, the second network gateway  222 ( a ) resides on the second network  220  with corresponding second network type—e.g., a Cisco network. This second type of network requires that H.323 compatible packets be transmitted from a port Y of the second gateway  222 ( a ) to port N  505  of the voice switch  585  and for H.323 compatible packets to be transmitted from port N of the voice switch  585  to the same port Y of the second gateway  222 ( a ). Thus, although both the first and second networks follow the H.323 standard, differing interpretations of this standard have led to different port assignment procedures between the two networks. In order to compensate for this difference, the voice switch  585  of the present invention is able to identify these slight variations between networks when both assigning port numbers during the call set-up procedure and packet switching as the telephone call is occurring. 
     The voice switch  585  is able to compensate for these variations between networks and properly translate packets between the two networks within the connection (e.g., transmit a packet on the appropriate port number to a network). First, the voice switch  585  identifies the direction of a packet within a connection (i.e., identifies a destination address for the packet). Second, the voice switch  585  identifies the type of network to which a packet is destined. This information allows the voice switch  585  to ensure that a packet transmitted from the voice switch  585  is compatible with the network to which the packet is destined. Moreover, the present invention also reduces the number of ports used from 4 to 2 as compared with the prior art. 
     b) Network Type Identification 
     As described above, the voice router  500  needs to be aware of the types of networks in this VoIP connection in order to ensure that proper packet translation occurs. Once the types of the two networks are identified, an appropriate packet translation may be retrieved and performed accordingly. 
     (i) Network Type Internal Table 
     A first method that may be used to identify network types is embedding a network type identifier within a port number found in the packet header.  FIG. 6A  shows one method for embedding a network type identifier. A sixteen-bit port number field  600  contained within a header is shown. This field  600  is segmented into three sub-fields: a first bit mask  610 , and second bit mask  620 , and a port value field  630 . The first and second bit masks  610 ,  620  are two-bit values. The port value field  630  is a twelve-bit field having a range of about 4000 values. 
     During the set-up of the VoIP connection, addressing information is gathered and the IP addresses and types of the first and second networks are determined. Thereafter, the two IP addresses are compared to identify the smaller IP address and the larger IP address. The comparison provides an order in which the network type identifiers corresponding to the two networks will be inserted within the port number  600 . A first bit mask is inserted in the first two-bit field  610 . The second bit mask is inserted in the second two-bit field  620 . Thus, when the voice switch  585  extracts these two bit masks; it will be able to associate each identifier to a particular network through the position (e.g., field  610  or  620 ) from which the identifier was taken. For example, the first bit mask  610  contains network type information for the smaller IP addressed network and the second bit mask  620  contains network type information for the larger IP addressed network. Thereafter, a port value is assigned and inserted within the port value field  630 . The port number  600  for the packet is the combination of these three fields. The port number  600  is inserted within the packet header and the packet is transmitted to the voice switch  585 . Although this process results in reducing the number of available ports per voice switch  585  on which packets may be transmitted (i.e., due to the allocation of four of the 16 bits to bit masks), the resulting reduction in the number of ports per connection on the voice switch  585  more than compensates for this reduction. 
     The voice switch  585  extracts this port number  600  from the packet header after receiving the packet on a corresponding port. From this port number  600 , the network type information within the first and second network type identifiers  610 ,  620  is removed and analyzed. From this information, the voice switch  585  is able to identify the network types of both networks within the VoIP connection. According to the example discussed above, the voice switch  585  extracts the network type information from the first network type identifier  610  and assigns this network type to the network with the smaller IP address. The information within the second network type identifier  620  is extracted and assigned to the network with the larger IP address. Thereafter, a corresponding packet translation operation is performed on the packet prior to transmission to the destination network gateway. For example, a destination IP address may be inserted into the header, the port number may be incremented by 2, and the packet is transmitted from the voice switch  585  to a destination gateway. As a result of this process, variations within H.323 networks are compensated for by the single voice switch  585  between the two networks. 
     The voice switch  585  requires some method of interpreting the information within the network type identifiers  610 ,  620  in order to properly translate addresses on the packets. According to one embodiment of the invention, a network type identifier table may be used. An example of a network type identifier table of network type identifiers is also shown in  FIG. 6B . This example describes a two-bit network type identifier that is limited to four network types that may be identified. This range may be increased by increasing the number of bits within one or both of the network type identifiers  610 ,  620 . However, as the number of bits within the network type identifiers  610 ,  620  increases, the range of available port numbers is reduced. The unavailable port numbers reserved for non-identified network types within this sixteen-bit port number cause this reduction. 
     (ii) Pre-Defined Port Range Representing a Network Type 
     A second method for identifying the network types within a VoIP connection provides that port numbers are assigned according to the two types of networks within the connection. This method begins at the call set-up stage during which the port numbers, on which packets will travel in a VoIP connection, are assigned. As with the first method, after both IP addresses of the two gateways are identified, they are compared and smaller and larger IP addresses are determined. A network pair table  700 A is maintained within the voice connector  570  that relates port ranges to VoIP connections between network types. The use of a table, as opposed to a static division of the port number space into equal sized port ranges, allows allocation of larger port ranges to more common network type pairs and smaller port ranges to less common network type pairs. An example of such a network pair table  700 A is illustrated in  FIG. 7A . This table  700 A provides a range of available port numbers according to a network type of the gateway having the smaller IP address and a network type of the gateway having the larger IP address. In one embodiment, the table includes four columns. A first column  710  identifies the gateway type of the smaller IP addressed gateway. A second column  720  identifies the gateway type of the larger IP addressed gateway. A third column  730  identifies a starting value of a port range corresponding to the gateway types identified in the first column  710  and the second column  720 . A fourth column  740  identifies either an ending value for this port range or a length for the port range. For example, a VoIP connection involving two gateways having the same network type could be assigned a port number within the range of 1000 to 2000. Comparatively, a VoIP connection involving a first gateway having a first network type and a second gateway having a second network type could be assigned a port number within a range of 3000 to 4000. 
     During the set-up of the VoIP connection, the types of the networks are identified and a port number is assigned by the voice connector  570  according to these ranges defined within the network pair table  700 A. This assigned port number is transmitted to the voice switch  585  and both gateways so that traffic between the two gateways may be forwarded correctly. 
     The network pair table  700 A is also transmitted to the voice switch  585  if the voice switch  585  does not have the table  700 A or the voice switch  585  has an old version of the table  700 A. It is important for the voice switch  585  to have a current version of the table so that both gateway types may be properly identified from the port on which a packet arrives. As a result of this network pair table  700 A, the voice switch  585  is able to identify the network types of both the larger and smaller IP addressed gateways by identifying the port range corresponding to the port used for packet transmission. For example, a VoIP connection is set-up between the first network gateway  212 ( a ) and the second network gateway  222 ( a ). Both gateways  212 ( a ),  222 ( a ) transmit packets to the same port, port N, of the voice switch  585 . The voice switch  585  is able to identify the type of both gateways  212 ( a ),  222 ( a ) by comparing the port on which a packet arrives to the network pair table  700 A shown in  FIG. 7A . The voice switch  585  identifies a port range within the table  700 A corresponding to the port number and identifies the gateway type of both gateways. Specifically, the network type of the gateway with the smaller IP address is extracted from column  710  and the network type for the gateway with the larger IP address is extracted from column  720 . 
     Note that the network pair table  700 A may be continually updated by the voice connector  570  simply through re-transmission to the voice switch  585 . Also, the size of the network pair table  700 A may be adjusted according to the number of different types of networks that use the voice switch  585  for VoIP connections. Also, the port ranges may be adjusted relative to the frequency of VoIP connections occurring between certain types of networks. For example, if VoIP connections between two types of networks occur very frequently, the port range corresponding to this connection may be increased to more efficiently accommodate these connections. 
     Adjustment of port ranges in the network pair table  700 A requires the ability to dynamically allocate the port ranges. In contrast, a fixed-size implementation of the network pair table  700 A does not allow for such adjustment, instead constraining the ranges of table  700 A to the sizes initially set, e.g. at system startup. Dynamic allocation of port ranges provides more efficient assignment of port numbers than does static allocation, where port needs must be guessed at and fixed ahead of time. Dynamic allocation further allows one voice switch  585  to be shared by multiple voice connectors  570 , or one voice connector  570  to use multiple voice switches  585 , since assignment of the port ranges to the various voice switches can then be performed at runtime rather than requiring an estimate ahead of time. For example,  FIG. 7C  depicts a network pair table  700 C in which a voice connector ID field  750  identifies the particular voice connector to which the port range has been allocated. 
     In one embodiment, such dynamic allocation is achieved by means of port range commands which one or more voice connectors  570  communicate to the port allocation module  599  of the voice switch  585  of  FIG. 5C . In this embodiment, the commands include a range allocation command and a range deallocation command, as well as a range renewal command. 
     The range allocation command takes as arguments a desired number of ports and a requested lease time, e.g. specified as an integer number of seconds, during which the resulting port range will be considered allocated. The port allocation module  599  then checks the request, denying it responsive to factors such as the requested number of ports being unavailable or too large for a single request, and otherwise allocating the requested ports and returning an identifier and size of the allocated ports. For example, the port allocation module  599  could return more or fewer ports than requested, e.g. rounding to a port range size that is a power of 2. The returned identifier can then be used to reference that port range when issuing further port range commands, such as renewing or deallocating the port range. In one embodiment, the gateway types for the two networks are specified at the time that the port range is requested as part of the range allocation command; in other embodiments, they can be specified later, e.g. using a separate command. 
     The range deallocation command takes as an argument the port range identifier returned when the port range was initially allocated. The range renewal command likewise takes as an argument the port range identifier previously returned, and additionally takes a lease renewal time, e.g. a number of seconds, for which the port range will be considered reallocated. 
     In one embodiment, the port range commands are implemented using a common message format containing a set of fields representing the union of all the arguments used by the various commands, with the particular command specified by a command identifier field in the message format and only the relevant fields provided with specified values for any given message. For example, the range deallocation command requires a port range identifier for a port range to deallocate, and the range renewal command additionally requires a lease renewal time for which to renew the port range. 
       FIG. 7D  depicts the states through which a given port range may pass in such an embodiment. The given port range is initially in an unallocated state  775 . If the voice switch  585  receives an allocation command from a voice connector  570 , then the port range enters an allocated state  780 . From allocated state  780 , the port range may be renewed via a renew command specifying a new lease period and thus remain in allocated state  780 , or it may be freed via a deallocation command and return to unallocated state  775 , or it may lapse into a released state  785  after the expiration of its lease time. From the released state  785 , the port range may be reallocated for some period via the port renew command, causing it to return to the allocated state  780 , or the period may elapse, in which case the port range is returned to the unallocated state  775 . 
       FIG. 7B  is an illustration of an exemplary network type table for associating an IP address with a network type. The network type table  700 B maintains state information about the network types with which the voice router is communicating. In the illustrated embodiment, a data record includes source IP address  760  and network type  762 . The source IP address  760  identifies the gateway on a particular network and the network type  762  identifies the type of network on which the gateway operates. For example, record  764  indicates that gateway ( 3 ) is network type ( 4 ). The network types can be predefined or dynamically assigned during operation. For example, the voice router  500  may use network type  4  to correspond to a Cisco-type network. One skilled in the art will recognize that the network pair table  700 A or the network type table  700 B may be used to identify a network type so that the voice router  500  can perform packet translation or provide other services. Therefore, reference numeral  700  as used herein refers to the network pair table  700 A or the network type table  700 B. 
       FIG. 8A  shows a block diagram of an embodiment of the voice connector  570  in which the network pair table  700  is used. Gateways, such as the first and second gateway  212 ( a ),  222 ( a ), may transmit call set-up requests on port F  575  or on port G  565 . According to this embodiment, the network type identification module  590  includes the network pair table  700 . The network type identification module  590  accesses this table  700  in order to identify the types of the gateways within a desired connection. This information is then transmitted to the port initialization module  595  whereupon ports for the connection are assigned and transmitted to the gateways and/or voice switch  585 . 
       FIG. 8B  shows a block diagram of an embodiment of the voice switch  585  in which the network pair table  700  is used. After the call set-up procedure is finished and a port is defined for a connection, voice packets between the first and second gateways  212 ( a ),  222 ( a ) may be transmitted. However, as described above, in order for proper translation to occur within the voice switch  585 , the destination gateway type should be identified. This identification allows the voice switch  585  to properly transmit the packet onto a correct port to a destination gateway. According to an embodiment of the present invention, the network type identification module  550  may implement the network pair table  700  to perform this gateway type identification. Specifically, the network type identification module  550  identifies the port on which a packet arrives. From this port number, a port range is identified within the table  700  and gateway types for both gateways are identified as previously described. However, in order to complete the translation and transmit the packet on to the correct destination, the direction of the packet needs to be identified because both gateways are transmitting on the same port. 
     c) Packet Direction Identification 
     In addition to identifying the network types of both the first and second gateway  212 ( a ),  222 ( a ), the voice switch  585  identifies the direction a packet is traveling. This direction information allows the voice switch  585  to properly switch a packet to a correct destination address because both the first and second gateways  212 ( a ),  222 ( a ) are transmitting packets to the voice switch  585  on the same port (e.g., port N). 
       FIG. 9  illustrates an embodiment of a packet direction identification module  560  according to the present invention. A source IP address is removed from an incoming packet and transferred to an address comparator  910  via line  905 . The address comparator  910  may be implemented in hardware, software, or firmware. The address comparator  910  is coupled to a buffer that stores the IP address of both gateways (e.g.,  212 ( a ),  222 ( a )) within a connection. One method for storing these IP addresses is to extract the source address from the first packet from each gateway. These two IP addresses are then stored within the buffer  920 . 
     The buffer  920  comprises a first storage element  925  and a second storage element  927 . The buffer  920  can implement a toggle for storing and for comparing the IP addresses. After receiving the source IP address from a packet that arrived on a particular port, the address comparator  910  compares this source address to the address within the first storage element  925 . If this source IP address matches the IP address within the first storage element  925 , the buffer  920  transmits the address in the second storage element  927  to the address comparator  910  via line  935 , without the need to update the buffer. This address from the second storage element  927  is the destination address for the gateway in the connection to which the packet should be forwarded. This address is inserted into the header of the packet so that it may be forwarded to the correct gateway in the connection. 
     Comparatively, if the source IP address from a packet does not match the address in the first storage element  925 , then the address in this first storage element  925  is transmitted back to the address comparator  910  via line  930 . This address from the first storage element  925  is the destination address for the gateway in the connection to which the packet should be forwarded. The source IP address from the packet is stored within the first element  925  and the IP address that had previously been stored in the first storage element is transferred and stored in the second storage element  927 . As a result, both IP addresses in the connection are continually stored within the buffer  920 . The buffer  920 , therefore, toggles the addresses when the source IP address does not match the address stored in the first storage element  925 . If the buffer  920  is implemented as a stack, then the source IP address can be pushed onto the stack when there is no match in with the first storage element  925  (i.e., the top of the stack). In one embodiment, if the source IP address from the packet does not match either the address in the first storage element  925  nor the address in the second storage element  927 , the address of the first storage element is moved to the second storage element and the source IP address is placed in the first storage element. 
     After a destination address is identified and a network type for both gateways has been determined, information is inserted into the packet header. For example, a new destination IP address and port number are inserted into the packet header. Thereafter, the packet is transmitted from voice switch  585  to a gateway (e.g.,  212 ( a ) or  222 ( a )) on a particular port. 
     d) Method for Translating a Network Address Within a Connection 
       FIG. 10  illustrates a general method for network address translation according to an embodiment of the present invention. A voice switch  585 , operating within an established network connection, receives  1005  a packet on a corresponding port. The voice switch  585  identifies  1010  a network type for both gateways within the connection. This identification may be done by numerous methods. For example, as described above, network type information may be integrated within the port number found in the packet header. Also, network type information may be identified by determining a port range in which the port falls, and from the port range, identify network type information corresponding to this particular port range. 
     The voice switch  585  identifies  1015  a direction of the packet or destination address to which the packet should be forwarded. This identification may be accomplished using numerous methods. For example, as described above, a buffer and comparator may be implemented whereby a destination address is determined using the source address within the packet header. Once both network type information and a packet direction have been determined, the voice switch  585  performs  1020  an appropriate address translation on the packet. Thereafter, the packet is transmitted  1025  to a correct gateway in the connection. 
     e) Gateway Behind Firewall 
       FIG. 11  depicts a scenario in which a firewall  1110  is added between the network gateway  212 ( a ) and voice router  500 , e.g. to provide additional security for the network gateway  212 ( a ). In such a scenario, the address information of voice packets sent from the network gateway  212 ( a ) to the voice router  500  is translated to that of the firewall  1110 . For example,  FIG. 11  depicts a voice packet sent from the network gateway  212 ( a ) having a source IP address A 1  and a source port number P 1 , which the firewall  1110  translates to source IP address A 5  and source port number P 5  when forwarding the voice packet to the voice router  500 . However, call setup information initially provided by the network gateway  212 ( a ) for initiating a VoIP connection with the network gateway  222 ( a ) is specified within the body of a packet and is therefore typically not modified by the firewall  1110 . Thus, when the network gateway  212 ( a ) wishes to initiate a VoIP connection with the network gateway  222 ( a ) and specifies its IP address and port number within the body of the packet as being source address and port number A 1  and P 1 , respectively, the voice connector  570  of the voice router  500  will receive A 1  and P 1  within the body of the packet unmodified by the firewall  1110 , and therefore will expect to receive voice packets for which the source address and port are A 1  and P 1 . =However, translation by the firewall  1110  of voice packets received from the network gateway  212 ( a ) will result in the voice packets having source addresses and ports A 5 /P 5 , leading the voice switch  585  of the voice router  500  to reject the voice packets, believing them to be from an unauthenticated source rather than from the expected A 1 /P 1 . 
     Thus, it is desirable for the voice switch  585  to acquire knowledge of the translated source address and port A 5 /P 5  produced by the firewall  1110  based on the original address and port number A 1 , P 1  of the network gateway  212 ( a ). A process for doing so is illustrated in  FIGS. 12A and 12B . Referring to  FIG. 12A , the voice connector  570  first receives a request for call initialization  1205  from the network gateway  212 ( a ). The voice connector  570  then extracts the source address and port number specified in the body of the packet as part of the VoIP connection request, and compares them to the source address and port number in the packet header. If they match, then no address translation has been performed by a firewall or other intermediary network device, and no further actions need be taken to account for address translation. If they do not match, however, then the voice connector  570  assumes that there is a firewall  1110  between it and the network gateway  212 ( a ), and proceeds to inform the voice switch  585  so that the voice switch can account for the firewall in future. 
     The voice connector  570  provides this information to the voice switch  585  by sending  1210  a Connect command to the voice switch, in which it specifies the source address and port number extracted from the body of the connection request, along with an address mask and a port mask. In one embodiment, the port number includes both a port number for RTP and a port number for RTCP, and each has an associated mask. The masks allow the voice switch  585  to determine whether a given packet came from the firewall  1110  and thus to deliver the packet rather than rejecting it, as described below. The voice switch then stores  1215  the connection information specified in the Connect command for use with future voice packets. 
       FIG. 12B  depicts steps taken by the voice switch  585  when processing a packet at some time after receipt of the Connect command. First, the voice switch receives  1220  a voice packet, such as a packet sent using RTP. In the case of a packet received from the network gateway  212 ( a ), the source address and RTP port number will be translated by the firewall  1110  from the A 1 /P 1  of the network gateway  212 ( a ) to the address and port A 5 /P 5  of the firewall, as discussed above. The voice switch  585  then performs validation  1225  of the packet. In one embodiment, the validation comprises checking the protocol, length, and checksum of the packet&#39;s IP header and UDP header, checking the UDP payload and length, and ensuring that the UDP destination port number is in a valid port range. In addition, the voice switch applies the masks previously received as part of the Connect command of step  1210  to translated address and port A 5 /P 5  and determines whether the translated address and port match those of the network gateway  212 ( a ). More specifically, the voice switch  585  computes the bitwise AND of the address mask with the IP address of the received voice packet, computes the bitwise AND of the address mask with the address of the network gateway  212 ( a ), and compares the two for equality. Likewise, the voice switch  585  computes the bitwise AND of the port mask with the port number of the received voice packet, computes the bitwise AND of the port mask with the port number of the network gateway  212 ( a ), and compares the two for equality. If both the address and the port number comparisons result in equality, then the voice packet is known to have arrived via the firewall  1110 , and the voice switch  585  therefore does not reject the packet, even though the address and port A 5 /P 5  are not yet known to it. Instead, the voice switch forwards  1230  the packet to the network gateway  222 ( a ), having earlier established a connection with the network gateway  222 ( a ) in response to the call setup request of the network gateway  212 ( a ). Additionally, the voice switch learns the source address information, storing the address A 5 /P 5  in its tables as the translated address of network gateway  212 ( a ) having address and port number A 1 /P 1 . Thus, when future voice packets arrive from network gateway  212 ( a ) with translated addresses A 5 /P 5 , the voice switch  585  will determine that A 5 /P 5  is already known to it as the translated address and port for network gateway  212 ( a ), and will therefore forward the packet rather than rejecting it. 
     When specifying the Connect command for delivery to the voice switch  585 , the voice connector  570  can set the address and port masks to reflect the level of knowledge that it has about the firewall  1110 . For example, if the voice connector  570  knows that there is no firewall  1110  between itself and the network gateway  212 ( a ) (e.g., due to a match between the address information in the packet header and the body of a VoIP call setup packet), then it sets all the bits of the masks to 1, meaning that it will accept only the gateway address and port number themselves, and no other related addresses/port numbers. Similarly, if the voice connector  570  has no information at all about the firewall  1110  and wishes to allow communications to proceed, it sets all the bits of the masks to 0, indicating that all addresses and port numbers will be accepted. The more bits of the mask that are set to 1, the narrower the range of acceptable addresses, and hence the greater the degree of security provided. In one embodiment, the voice connector  570  obtains the value for the masks to be used for a given network gateway and port number from a configuration file, in cases where information on the firewall  1110  is static and known, and sets the value of the masks to 0 otherwise. 
     f) Method of Port Multiplexing 
     The technique described above for accounting for the presence of firewalls can also be extended to support port multiplexing. Port multiplexing, in which a single port is shared for a plurality of distinct communications, allows a reduction in the number of ports on which a device listens, and is useful for reasons such as network security. To achieve port multiplexing, the sender, such as the network gateway  212 ( a ), replaces the original destination port number in a packet header, e.g. a UDP header, with a port number that the voice router  500  has designated as a multiplex port, and places the original destination port number at a known location in the body of the packet, e.g. as the last two bytes of the UDP payload. In one embodiment, the port number of the multiplex port is predefined; in another embodiment, the voice connector  570  sends a query to the voice switch  585  and in response receives a dynamically-allocated multiplex port number. When the voice switch  585  of the voice router  500  receives this packet, it examines the destination port number in the packet header, and if it is a port number known to represent a multiplex port, then the voice switch  585  extracts the original destination port number from the known location in the body of the packet and replaces the port number in the packet header with the original destination port number. The voice switch  585  then forwards the packet to the receiver, e.g., the network gateway  222 ( a ). In one embodiment, the voice switch  585  identifies which port ranges represent multiplex ports by reading a configuration file. 
     While the present invention has been described with reference to certain preferred embodiments, those skilled in the art will recognize that various modifications may be provided. Variations upon and modifications to the preferred embodiments are provided for by the present invention, which is limited only by the following claims.