VoIP Gateways

The range of products in the VoIP gateway area starts with small PC-compatible boards with a few ports, which accommodate one to four analog telephone lines, and extends to large carrier-grade devices that can be used by both telephone companies and Internet service providers. Toward the high end of such products, the functions of a gateway per se are often integrated with gatekeepers into standalone products (IP telephony servers) that have many additional functions, as described in the next section.

At the heart of any gateway is the capability of converting a stream of voice-carrying signals (either analog or digital) from a telephone line or trunk into a stream of RTP packets (transmitted over a shared channel, which in general should be expected to have a much lower bandwidth). Part of such a conversion involves compression, which compensates for bandwidth reduction. Conversely, every gateway has the capability of converting a stream of RTP packets (and possibly decompressing the data) into a stream of signals acceptable by existing traditional telephony systems. The conversion is performed by coder/decoder modules, or codecs, which can be purchased separately and subsequently integrated into gateways. The role of codecs is central to the basic function of any gateway, because their performance affects crispness and clarity of sound. Other important gateway capabilities that affect the quality of sound are echo cancellation and compression. Overall, it is a legitimate requirement in today’s market that the audio capabilities of gateways enable full-duplex conversations. Another important requirement is that gateways used by the switches (for example, PBXs) for toll saving monitor the quality of IP-transmitted sound (by employing RTCP, for example) and generate an appropriate signal to the switches when sound quality falls below a customer-set threshold. Upon reception of a poor-quality signal, the switches can automatically select a PSTN trunk to continue the call.

We have not addressed codec standards in detail because much literature on the subject is available (see Minoli and Minoli, 1998b) and such a treatment is beyond the scope. We will provide recommendations on what to expect (and request) of vendors. The role of codec standards is hard to overestimate because, in principle, gateways cannot interoperate if they do not support the same sets of codecs. Thus, compliance with codec standards is an essential factor when evaluating gateways purchased from different manufacturers.

As we have said before, major codec standards are produced by ITU-T in its G Series of Recommendations. First of all, the G.711 standard (for ISDN voice channels; yields 64 kbps of digital audio) must be supported by any gateway. In connection with regional standards, all gateways that interoperate with the North American telephone system must support the A-law scheme; all gateways that interoperate with the European telephone system must support the A-law scheme. In addition, advanced gateways may support low-bandwidth connections with G.723.1 or G.729A codecs. In that case, the support of transporting DTMF tones using a non-RTP path is important because the low-bandwidth codecs are not designed to reliably pass DTMF tones as part of a compressed voice stream. This feature allows the regeneration of the DTMF tones at the receiving gateway and improves overall call performance, in particular for applications (for example, voice mail) that require correct detection of DTMF tones.

Voice compression makes it difficult, if not impossible, to transcode (that is, translate from one encoding scheme to another). Transcoding is well understood for the compression schemes defined in the G.729 and G.729A standards. Thus, if compression is supported, it should adhere to these standards. Some gateway products attempt to realize much-needed bandwidth savings by monitoring sound activity. When silence is detected by the transmitting gateway, it stops the sound transmission and informs the receiving gateway about the background noise. Then the receiving gateway emits comfort noise to create the perception of uninterrupted transmission. Unfortunately, this feature always seems to affect voice quality negatively—much more research is needed to develop the necessary heuristics. G.729 and G.729A are two codec standards that support some degree of implementation of this feature, but there are so many incompatible solutions among current products that it is essential to require any products that support this feature to provide a means to turn it off. Finally, when this feature is implemented for G.729 or G.729A, the G.729B standard should be complied with.

Another essential aspect of all gateway products is their ability to use signaling (for call establishment rather than voice transport) at the appropriate level of interconnection. For example, a two-stage gateway that provides a toll bypass (or trunk replacement) service must support call establishment signaling (in most cases, SS No. 7 ISUP) with the access switch. Similarly, a one-stage enterprise gateway that connects to a PBX must support access (typically Q.931) signaling. Even the lowest-end gateway products—one-port residential gateways that interconnect analog telephones with the Internet—must still comply with the standard in-band signaling (that is, provision of dial tone, acceptance of dialed tones, and recognition of on-hook/off-hook events) in order to work with the telephone. Thus, on the traditional telephony side, gateway products destined for a particular function must support appropriate in-band signaling. On the IP side, gateway products should support (and all advertised products invariably do support) the H.323 family of standards. In particular, at the time of this writing, H.323 version 2 is supported by leading products. In addition, some products also support the SIP protocol as an add-on, since several providers—especially those integrating cable networks—require SIP compliance. To this end, industry attention to SIP is growing steadily at the moment of this writing.

One function present in several products, is gateway self-discovery. This is a novel feature particularly relevant to the gateways at the edge of the PSTN. For a phone-to-phone toll bypass service, calling party access to a (local) gateway is achieved through a local telephone call. For the service to be cost effective, the called party must also be dialed from its local exchange, so the local terminating gateway must be the endpoint for the IP-carried part of the call. The IP addresses of the gateways (relative to the local PSTN numbers they serve best) are currently hard-coded, but products that support dynamic discovery of the gateway are emerging. (Note that, as an alternative, gatekeepers could perform self-discovery.) To handle the case in which a local terminating gateway cannot be reached (because of network congestion, gateway overload, or network server failure), advanced gateways often support PSTN fallback. This feature allows a phone-to-phone toll bypass call that otherwise cannot be completed to be completed entirely over the PSTN.

Gateway products fall into three general categories:

• Small (branch office or residential) gateway products. One- to four-port interfaces to which POTS telephones are connected.

• Enterprise-grade (access gateway) gateway products. Support up to a thousand ports. On the traditional telephony side, enterprise-grade gateway products typically interface with a PBX (and employ Q.931 signaling) and are usually located on the enterprise premises. As an exception, they can be located at an ISP or LEC, but with the sole purpose of providing PBX-emulating Centrex services to a particular enterprise that does not own a PBX. Enterprise gateways support one-stage dialing: PBXs divert voice-over-IP traffic based on either a specific number or an algorithm computed by the PBX.

• Carrier-grade (trunking gateway) gateway products. Support up to 10,000 ports located on the premises of IP telephony providers (for example, ISPs, IXCs, and LECs). The connection (and, therefore, the signaling arrangements with the PSTN) requires the use of Signalling System No. 7 (SS No. 7) ISUP. If the SS No. 7 transaction capabilities (TC) are supported, then the VoIP gateways equipped with the application supporting the Intelligent Network Application Protocol (INAP) can also benefit from using Intelligent Network. To get the SS No. 7 support, the VoIP gateways can be paired with the SS7 gateways.

The rest of this section deals with carrier- and enterprise-grade gateway products.

The gateway hardware invariably consists of line modules (cards) mounted on a rack and a management board that is responsible for the control of line modules. Communications among the line modules and the management card are carried through fast-switching fabric, such as an asynchronous transfer mode (ATM) cell backplane, at a high rate (100 to 200 Mbps in the case of the ATM fabric). Switching fabric components are augmented by Ethernet cards and ports (and necessary wiring) as well as the cooling system (typically fans). Cooling is important because of the highly CPU-bound nature of codec software, which necessitates the employment of multiple digital signal processors (DSPs). In fact, the two major limitation factors for scalability of gateways are heat and space. The system is administered via the operator console, which may (but does not have to) be part of a particular offering; however, console ports are provided on the gateway chassis. In high-end products, the line modules are hot-swappable: Any line card can be replaced by another one without the need for reconfiguration—it will automatically load its configuration from the management board once it is in the slot.

As you may recall, the ISDN primary rate interface (PRI) service provides bandwidths of 1.544 Mbps for T1 lines in the United States and 2.048 Mbps over E1 lines in Europe. This translates to twenty-three and thirty 64-kbps bearer (B) channels, respectively, augmented by a 64-kbps data (D) channel. In high-end gateway products, the capacity is measured in quad-T1 and tri-E1, corresponding to four T1 and three E1 circuits, respectively—the capacity of one card. Cards can be added to a system, and systems can be stacked on top of each other.

In addition to PRI, a number of other trunking services (which we do not cover) are supported by the high-end products. Note that ISDN is a typical and widely deployed use of trunking services; while a T1 line is normally associated with a single telephone number, when it is set up for ISDN B channels, each can be assigned a separate number. The lines can be configured for both inbound and combined inbound and outbound calling. Another configuration option is alternating circuit-switched voice and data, which permits modem calls.

As far as software is concerned, each line module’s central processing unit (CPU) executes the gateway operating system independently. The operating systems themselves are often proprietary. High-end products provide both command-line and graphical user interfaces for monitoring, maintenance, and operations of the gateway via the console or telnet connection. In addition, most systems support Simple Network Management Protocol (SNMP) for the same purposes. To this end, an important feature of a gateway is provision of SNMP alarms for a number of causes, including power failure and overheating. Another important feature is automatic turn-off of the overheated or otherwise problematic line modules by the management board.

An important function of gateway software is billing. Gateways should generate call detail records, whose attributes are described in more detail in the next section, and then pass them to the gatekeeper responsible for billing. Part of the software is libraries that provide the application programmer’s interface (API) that allows the use of third-party billing software in support of various paying methods, such as prepaid calling cards or credit cards. (A key feature of a prepaid billing system is to send a call drop request to the originating gateway when the caller runs out of prepaid funds.) Billing is of course inseparable from authentication. In two-stage calling, the user is identified by a personal identification number (PIN); the Automatic Number Identification (ANI) parameter passed from the PSTN is also used for authentication. Again, the authentication may be performed by gatekeepers.

Proprietary coding and compression techniques often make gateways from different vendors noninteroperable. While enterprise network managers can solve this problem by purchasing a matching set of gateways from a single vendor or ensuring that the gateways from selected vendors do interoperate, neither ISPs nor telephone companies can presently ensure that calls originating or terminating in another ISP’s or telephone company’s network can be successfully handled by the receiving gateway. This interoperability issue is one reason (QoS is the second) why the quality of voice-over-IP calls has been reported to be high in the enterprise networks, but remains problematic over the Internet.

Finally, it is important to note that distributed implementations of VoIP gateways are emerging. These implementations are generally associated with so-called soft switches and media gateways. Soft switches provide call control and signaling interworking, while media gateways handle the transcoding of voice streams tailored for different networks. The aim is to make distributed VoIP gateways more scalable and programmable than their monolithic cousins and ultimately to ease the introduction of new services.

Gateway Location

What we have touched on so far are the core gateway functions—signaling and media conversion. Yet, to support an IP telephony call end to end, other things need to be taken care of. One such thing is gateway location.

Suppose a call originated in (or was passed on to) an IP network, and the call needs to be terminated in the PSTN. There are many gateways that could do the job, but only a few may be suitable for a particular call. For instance, the gateway definitely should be chosen so as to terminate the call at the point in the PSTN as close to the called party as possible. In this case, terminating at the gateway that is connected to the called party’s end office is clearly the optimal solution if other factors are not involved.

But other factors are typically involved, such as the load and capability of gateways in question, the IP network provider’s and the end user’s preferences, agreements with the PSTN service providers, and—to top it all—the costs to be incurred.

Thus, gateway location is an important activity that is bound to become more complex as more telephony gateways are built and deployed. A considerable amount of research on the subject has been done (Schulzrinne and Rosenberg, 1999) and more or less detailed proposals on that matter have been submitted to both ITU and the IETF [specifically, the IP Telephony (iptel) working group].

As it happens, the Internet has had a similar problem with interdomain routing, which has been solved. It should come as no surprise, then, that many ideas of a specialized routing protocol [called Border Gateway Protocol (BGP)] have been used to develop the gateway location technology.

In the tradition of IP routing, the process is dynamic and the knowledge is built using distributed computation performed by the gateways. Before the decision can be made regarding which gateway to choose, the database of eligible cooperating gateways has to exist. This database is built in the act of gateway discovery. Figure 1 shows a representative architecture that spans several administrative domains. Each domain, which contains several gateways and some number of endpoints (for example, PCs), has at least a logical entity, called a location server. The main job of the location server is to learn about the gateways in its own administrative domain as well as in other domains and to construct the database of the gateways. In the intradomain case, this is usually achieved in a registration process. Each gateway signs on with the location server when started up and updates its availability status whenever necessary. The information is propagated by means of an intradomain protocol, such as the Service Location Protocol.^[7]

Figure 1: Architecture for gateway discovery.

In comparison to the intradomain case, discovery of gateways in other domains is not as straightforward a process. Complicating the process is the need for a business agreement between the administrative domains for any exchange of gateway information or any use of the gateways by users in a different domain. A location server can only propagate to another location server the gateway information that is permitted by the agreement between the administrative domains to which they each belong. Similarly, synchronization of the database in one domain with that of another and selection of the route of a call are subject to the intradomain agreement and policy. As a result, there cannot be a single global database of gateways where a user can look up and select a gateway as desired. Instead, different databases may be available in different domains based on the respective business agreements and associated policies. The database contains the IP address of a gateway and a range of telephone numbers that the gateway can terminate. In addition, it contains the attributes of the gateway, such as signaling protocols (for example, SIP and H.323), usage cost, and the provider’s identification number, which we have mentioned before. A location server uses the attributes to decide which gateways are to be used for terminating a call to a particular number or to be further advertised to other location servers.

Interdomain gateway discovery is carried out through an interdomain protocol, such as the Telephony Routing Information Protocol (TRIP), which is under development in the IETF. As mentioned before, an inter-domain gateway discovery protocol resembles a routing protocol. It also shows significant differences, however. The most important are that the inter-domain gateway discovery protocol runs at the application level and runs between location servers, which may not be adjacent and, unlike routers, do not forward IP packets.

As far as access to the gateway database is concerned, it is an activity that is independent of gateway discovery. There are several possible approaches for such database access using different protocols. One protocol is Lightweight Directory Access Protocol (LDAP), which, as its name suggests, is for access to any directory organized in a special tree structure. When LDAP is used, the gateway database is organized based on the LDAP data model. Another protocol is Service Location Protocol, which has been designed for locating a networked service based on service attributes rather than the name (or location) of the network host providing the service. Logically, it can be used to find gateways given a set of user preferences. Yet another protocol is HTTP, the communications enabler of the World Wide Web. In this case, the gateway database has a Web front end, which allows a user to query it through Web-based forms. We should note that an inter-domain gateway discovery protocol is actually another possible candidate. Nothing prevents it from being used for retrieving information in the gateway database.

Gateway Decomposition

The different types of gateways described iare specific instances of a generic gateway notion. It is useful to decompose the generic gateway into several functional components. Figure 1 depicts a common view of such a decomposed gateway. Three components are identified: (1) the media gateway (MG) function, (2) the signaling gateway (SG) function, and (3) the media gateway control (MGC) function. We describe these functions next.

Figure 1: Components of a decomposed PSTN-Internet gateway.

Physically, the media gateway function terminates PSTN circuits and connections to IP routers (in relation to which it is a host). It also performs all the necessary transformation to convert bit streams received from the sending network into bit streams particular to the receiving network. The transformation occurs at two levels: transmission and application.

At the transmission level, the MG function converts the bit streams between two different framing schemes. This usually involves multiplexing of bit streams of distinct communication sessions and the reverse operation—demultiplexing. In the PSTN, fixed-size digital channels (each typically carrying a voice conversation) are multiplexed based on the time division multiplexing (TDM) scheme at various hierarchical levels (for example, T1 and E3) and packed into frames for transmission over high-capacity facilities. In the IP networks, bits representing a voice conversation are packetized according to the Real-time Transport Protocol (RTP) profile for audio and video payloads (RFC 1890).

At the application level, the transformation takes place between different media-encoding schemes (see the section on codecs for more information) and is commonly known as transcoding. In IP telephony, two prevalent speech encoding schemes are G.711 and G.729. Operating at a bit rate of 64 kbps, G.711 is used ubiquitously in the digital backbone of the PSTN and sets what is known as the toll-quality voice standard. G.729 operates at a much lower bit rate of 8 kbps but still supports near-toll-quality voice service. For this reason, it is widely used in IP networks where bandwidth is constrained. Note that transcoding is computationally intensive and thus causes delays. In addition, transcoding results in degradation of voice fidelity, in particular when a speech coder uses compression.

Another important task of the MG function is to support the use of the QoS facilities of the IP network. Other tasks include echo cancellation (if required), event detection, signaling generation, usage recording, and support of specialized resources such as conference bridges, fax machines, modem pools, and interactive voice response units.

The SG function receives and sends PSTN signaling (such as SS No. 7 or ISDN access) messages. Depending on the arrangement, it may relay, translate, or terminate the PSTN signaling. It exchanges signaling information with the MGC function over IP, and with the PSTN using the SS No. 7.

The MGC function provides control of the media gateway function, including call and connection control and resource management. To this end, it terminates and originates all the relevant signaling. In addition, the MGC function keeps an inventory of the MG resources (for example, bearer circuits and RTP streams) and instructs the MG to reserve or release resources as required. (Naturally, some sort of local policy will govern the use of resources.) With its central role in call and connection control, the MG function logically also provides support for Internet offloading or advanced services and features (such as freephone or call-forwarding). It has the ability to detect data calls from the PSTN and to direct the data traffic straight to a network access server as well as to launch queries to SCPs for instructions for further call processing.

Configuring H.323 Gateway

To configure a basic H.323 gateway, enable VoIP gateway functionality using the gateway command.

1. Enter Global Configuration mode:

   router# configure terminal
   

2. Enable the VoIP gateway:

   router(config)# gateway 

3. Exit Gateway Configuration mode:

   router(config-gateway)# exit 

Next, configure the gateway interface parameters. Define which interface will be the gateway's H.323 interface to the VoIP network. Only one interface is allowed to be the gateway interface. You can select either the interface connected to the gatekeeper or a loopback interface.

After you define the gateway interface, you configure the gateway to discover the gatekeeper (multicasting or a specific host). Finally, configure the gateway's H.323 identification number and any technology prefixes that this gateway should register with the gatekeeper.

Use the next set of commands to define the Ethernet 1/0 interface to be used as the H.323 gateway interface and configure the H.323 gateway interface parameters, beginning in Global Configuration mode. For this example, assume that the gateway and gatekeeper's IP addresses are 192.168.1.1 and 192.168.1.254, respectively:

1. Enter Interface Configuration mode:

   router(config)# interface ethernet 1/0
   

2. Configure an IP address for this interface with subnet mask:

   router(config-if)# ip address 192.168.1.1 255.255.255.0
   

3. Designate this interface as being the H.323 gateway interface:

   router(config-if)# h323-gateway voip interface
   

4. Specify an H.323 name (ID) for the gateway associated with this interface. The gateway uses this ID when it communicates with the gatekeeper. Usually, the H.323 ID is the name given to the gateway, with the gatekeeper domain name appended to the end:

   router(config-if)# h323-gateway voip h323-id interface-id
   

5. Specify the name (ID) of the gatekeeper associated with this gateway and how the gateway finds it. The gatekeeper ID configured here must exactly match the gatekeeper ID in the gatekeeper configuration. The gateway determines the location of the gateway in one of three ways: by a defined IP address, through multicast, or via RAS.

   router(config-if)# h323-gateway voip id atl2600gk 192.168.1.254 1719
   

6. Define the H.323 name of the gateway, identifying this gateway to its associated gatekeeper:

   router(config-if)# h323-gateway voip h323-id atl2600gw1@cisco.com
   

7. Specify a technology prefix. A technology prefix is used to identify a type of service that this gateway is capable of providing. This is an optional configuration.

   router(config-if)# h323-gateway voip tech-prefix 9#
   
   

Media Gateway Control Protocol

MGCP (RFC 2705) is a relatively new protocol and as such, it is not as widely deployed as its H.323 and SIP predecessors. MGCP offers many key benefits and is growing in popularity, especially in Cisco CallManager deployments.

MGCP is a merger of the Simple Gateway Control Protocol (SGCP) and the Internet Protocol Device Control (IPDC). SGCP calls for a simplified design and a centralized intelligent call control. IPDC was designed to provide a medium to bridge VoIP networks and traditional telephony networks. MGCP is a media control protocol, suited for large-scale IP telephony deployment, and supports VoIP only.

MGCP incorporates media gateway controllers (MGCs) or call agents to perform all call connection and call control within an MGCP network. These MGCs signal to, and control, media gateways (MGs) to connect and control VoIP calls. All the information for making and completing a VoIP call is held in the MG.

MGs have very little intelligence and receive all their marching orders from the MGC; they cannot function without a controlling MGC. In a Cisco CallManager deployment, the MGC is often a CallManager server and the media gateway is a router used to connect to a dissimilar network. Examples of gateway applications are:

• Trunking gateways Interfaces between the telephone network and a VoIP network. Manage a large number of digital circuits.

• Voice over ATM gateways Interface to an ATM network.

• Residential gateways Provide a traditional analog (RJ11) interface to a VoIP network. Examples of residential gateways include cable modem/cable set-top boxes, and broadband wireless devices.

• Access gateways Provide a traditional analog (RJ11) or digital PBX interface to a VoIP network. Examples of access gateways include small-scale VoIP gateways.

• Business gateways Provide a traditional digital PBX interface or an integrated "soft PBX" interface to a VoIP network.

• Network access servers Can attach a modem to a telephone circuit and provide data access to the Internet. We expect that in the future, the same gateways will combine VoIP services and network access services.

When a gateway device detects that an end-user phone connection goes off-hook, it is directed by the MGC to provide a dial tone to the phone and receives the dialed digits and forwards them to the MGC for call processing.

MGCP Connections

In an MGCP connection, there are two basic types of logical devices: endpoints and connections. Endpoints are the physical, or logical interfaces that either initiate or terminate a VoIP connection. Endpoints are most often analog or digital ports in routers acting as gateway devices or digital interfaces into a PBX system.

Connections are temporary logical flows that are created to establish, maintain, and terminate a VoIP call. Once the call is complete, the connection is torn down and the resources that were allocated for that connection can be reused to support another connection. A one-to-one connection is really a point-to-point connection; a single endpoint signals to another single endpoint for the purposes of completing a single VoIP connection. Multipoint calls are used for conferencing and broadcast to multiple endpoints simultaneously.

MGCs manage connections in an MGCP network using the Session Description Protocol. SDP uses ASCII commands over IP/UDP to perform all call management functions. A series of eight connection messages is used by the MGC in order to control endpoints.

• CreateConnection

• ModifyConnection

• DeleteConnection

• NotificationRequest

• Notify

• AuditEndpoint

• AuditConnection

• RestartInProgress

Technologies: Routers, Gateways, Firewall

Routers
A router is a device that directs (routes) data from one path to another in a network. Routers base their switching information on one or more information parameters of the data messages. These parameters may include availability of a transmission path or communications channel, destination address contained within a packet, maximum allowable amount of transmission delay a packet can accept, along with other key parameters. Routers that connect data paths between different types of networks are sometimes called gateways.

Routers provide some of the same functionality as network switches. Their primary function is to provide a path for each routable packet to its destination. When a router is initially installed into a network, it begins its life by requesting a data network address. Using this data network address, it sends messages to nearby routers and begins to store address connections of routers that are located around it. Routers regularly exchange their connection information (lists of devices it is connected to) with nearby routers to help them keep the latest packet routing information.

A router can make decisions on where to forward packets dependent on a variety of factors including the maximum distance or packet priority. Distance vector routing and link state routing allow the router to select paths that match the needs of the data that is being sent through it.

Routers may also have fixed routing tables that are manually programmed by the network administrator. These static routing tables may be inflexible, however the use of static routing ensures other router’s that may have corrupt routing tables does not change the table.

Figure 1 shows a how a router can dynamically forward packets toward their destination. This diagram shows that a router contains a routing table (database) that dynamically changes. This diagram shows a router with address 100 is connected to two other routers with addresses 800 and 900. Each of these routers periodically exchanges information allowing them to build routing tables that allow them to forward packets they receive. This diagram shows that when router 100 receives a packet for a device number 952, it will forward the packet to router 900. Router 900 will then receive that packet and forward it on to another router that will help that packet reach its destination.


Figure 9.11: Router

Gateways
Gateways are devices that enable information to be exchanged between two dissimilar computer systems or data networks. A gateway reformats data and protocols in such a way that the two systems or networks can communicate. Gateways can convert packets between dissimilar networks.

Figure 2 shows how a gateway can convert large packets from a FDDI into very small packets in an ATM network. Not only does the gateway have to divide the packets, it must also convert the addresses and control messages into formats that can be understood on both networks.


Figure 2: Gateway

Firewall
A firewall is a device or software program that runs on a computer that provides protection from external network intruders by inhibiting the transfer of unauthorized packets and by allowing through packets that meet safe criteria. There are various processes that can be used by firewalls to determine which packets are authorized and packets that should be rejected (not forwarded).

Because firewalls can use many different types of analysis to determine packets that will be rejected, they can be complicated to setup. If a firewall is not setup correctly, it can cause problems for users that are sending and expected return packets that may be blocked by the firewall. Because firewalls process and analyze information, this process requires additional time and this can slow down network data transfer and response time.

Figure 3 shows how a firewall works. This diagram shows that a user with address 201 is communicating through a firewall with address 301 to an external computer that is connected to the Internet with address 401. When user 201 sends a packet to the Internet requesting a communications session with computer 401, the packet first passes through the firewall and the firewall notes that computer 201 has requested a communication session, what the port number is, and sequence number of the packet. When packets are received back from computer 401, they are actually addressed to the firewall 301. Firewall 301 analyzes the address and other information in the data packet and determines that it is an expected response to the session computer 201 has initiated. Other packets that are received by the firewall that do not contain the correct session and sequence number will be rejected.


Figure 3: Firewall

Firewalls are also appropriate for small office and home office (SOHO) applications. There are low-cost software packages and hardware equipment that offer a moderate level of increased security. They cannot stop all hackers, but they will stop some of them.