Telecom Made Simple

Internet-Supported PSTN Services

noreply@blogger.com (JohnJenin) — Wed, 18 Nov 2009 10:42:00 +0000

Last year a colleague of ours was called by a reporter from a well-known technical publication and asked to describe the effort of the PSTN/Internet Internetworking (pint) working group in the Internet Engineering Task Force (IETF). Our cautious colleague wisely decided that the best he could do under the circumstances was to read out to the reporter a few selected sentences from the working group charter published by the IETF on its Web page. Specifically, he stressed—prompted by the pint Web page—that the purpose of pint was to “address connection arrangements through which Internet applications can request and enrich PSTN . . . telephony services.” The reporter wrote down what she heard. Later, in accordance with her agreement with our colleague, she sent to him the draft of the article. The article was accurate except for one word: enrich had turned into unleash—this is what the reporter heard over the telephone line (an atypically imperfect telephone line, we presume). When the amazed author called the reporter with the correction, she seemed to be disappointed. (And so are we. We wish the pint charter really did talk about unleashing the telephone services, because this is precisely what the Internet-supported PSTN services are all about!)

In his recent article on Intelligent Network, Scott Bradner correctly observes that the intelligence of IN is strictly in the network, not on its edges. This lack of edge intelligence is precisely what the interworking of the Internet and IN is to change—once and forever!

The basic goal of the IN technology is to allow the user of an Internet host to create, access, and control the PSTN services. A simple example of what the technology can do is the click-to-dial-back service, where you click on an icon displayed on a Web page and the PSTN call is established as the result.

As simple as it sounds (and a crude implementation of this service is just as simple), the unleashing quality of this service alone should not be underestimated. The competition among the long-distance service providers is such that they would do almost anything to get a call flowing through their networks. With Web-based access, their customers are around the world! There are still countries that protect their networks by forbidding the call-back service; people may get angry about such backward and anticompetitive practices, but click-to-dial-back, which technically is not a call-back service, is a way to get even.

Once you start thinking about the possibilities of tweaking this basic concept, you will find that the possibilities for creating new services are virtually unlimited. We will demonstrate a straightforward extension of click-to-dial-back to drastically improve on a PSTN-only service.

The service in question, interestingly enough, came to life as an application of the Web business model (but not the Web technology) to the PSTN. Telephony service providers in Europe started to market free telephone calls to those who would agree to listen to several minutes of audio advertising. The advertisers have so far found the approach ineffective—pure audio is hardly the best means of delivering advertising today. This already bad effect is further worsened by the “push” nature of audio advertising.

Now, with the technology just described, the prospective caller can access the service provider’s page on the Web, where he or she can also subscribe to the service and register a profile stating the preference for the types of products he or she wishes to learn about. Every time a call is to be made, the caller can then be walked through a video presentation of the advertisement on his or her Internet appliance—possibly accompanied by the audio portion over the PSTN line. The caller can control the pace of the advertisement; when it is finished, the caller will be prompted for the number he or she wishes to call and then connected to that number.

There are several early developments in this area (Hubaux et al., 1998). In the relevant architecture, the SCPs and SNs are connected to the Internet (which is fairly easy to achieve because they are almost invariably implemented on the Unix system platform).

Figure 1: The architecture for Internet-supported PSTN service delivery.

It is important to repeat that with this arrangement only SCPs and SNs—but by no means the switches—are connected to the Internet and thus can communicate with other IP hosts.

The service control function can be distributed to Internet hosts as much as the PSTN service provider allows and the owner of a particular IP host (who may be the same PSTN service provider) wishes to handle. In the WebIN, the IP host is actually a Web server, and part of the service control function (called WebSCP) is moved into the Internet (Low, 1997; Low et al., 1996). This arrangement can be used to provide the main features of the PSTN VPN service—the private numbering plan and closed user group in particular (Hubaux et al., 1998). The translation map of the enterprise-significant numbers to the PSTN-significant ones, as well as the specification of the closed groups (including the calling privileges of each group member), are kept in the databases accessible through the Internet. Part of the SCP service logic is executed by the WebSCP. While there is very little interoperability among the legacy IN implementations, integrating them with the Internet immediately establishes a common language for interworking. Even more significant is that the service creation and service management are also moved (via the Internet) to the edge of the network.

As exciting as the opening of PSTN call control to the Internet hosts may be, there is a serious and not completely solved problem associated with it. This problem is security, and it is ubiquitous in the Internet. While trusted relations between the PSTN and IP entities can be established between the enterprise networks, opening IN control fully to anyone on the Internet remains problematic. There may be no need for IN control to be fully opened, except in the cases of some well-understood services.

Potential security issues also prevent (at least for the time being) direct connection of the switching offices to the Internet. If that were done, the SCP itself could be placed on the Internet, and subsequently anything that IN does presently could be done in the Internet. Although there is a single ITU-T standard, it specifies different options. These options reflect implementations that differ not only between different continents (that is, Europe and North America) but also among the network operators in the United States. (Bell Operating Companies use the option corresponding to the Bellcore AIN; some IXCs use proprietary or European versions of IN.) Thus, direct interconnection of the PSTN switches and Internet SCPs, even if secure, would not provide global interoperability. Only interworking of the PSTN service control with the Internet hosts holds the promise (on which it has already started to deliver) of universal, global access to service control of the PSTN.

To conclude this section, we would like to repeat that so far we have taken an intentionally one-sided approach to the role of IN in the integration of PSTN and the Internet. Our only goal was to demonstrate how IN can be used to give more control in creating and executing services to the edge of the network. At this point, it is important to observe an interesting duality: While the PSTN benefits from Internet-based service creation and control, the IP networks greatly benefit from the existing PSTN-based service control for at least three different reasons: (1) efficiency of the access to IP networks; (2) provision of certain combined PSTN-Internet services; and (3) support of the existing PSTN services in the IP telephony environment.

The PSTN Access to IP Networks

noreply@blogger.com (JohnJenin) — Sun, 15 Nov 2009 09:35:00 +0000

Most of the technologies in the area of PSTN access to IP networks have been relatively well understood—that is, supported by the standards and widely implemented in products. For this reason, much material on this subject resides in the next two parts (which cover available standards and products, respectively). The technologies we describe here relate to physical access to the network. We have already described the ISDN; with the growing demand for the Internet access, residential subscription to the ISDN has grown (although not necessarily for the purposes for which the ISDN was invented). Typically, users bundle the B and D channels to get one big data pipe, and use this pipe for Internet access. Other types of access technologies are described in the following section.

An important problem facing the PSTN today is the data traffic that it carries to IP networks; the PSTN was not designed for data traffic and therefore needs to offload this traffic as soon as possible. We describe the problem and the way it is tackled by the industry in a separate section, which, to make the overall picture more complete, we tie in with the technique of tunneling as the paradigm for designing IP VPNs. Both technologies have been developed independently and for different purposes; both, however, work together to resolve the access issues.

Physical Access

In much of this book, we talk about approaches to integration of the Internet with telephony in which the action occurs at the network layer or higher—things like carrying voice over IP or using control signals originating within the Internet to cause connections to appear and disappear within the telephony network. However, integration at the lowest level—the physical level—is also of great practical importance, and nowhere more so than in the access portion of the network. Here, advances in digital signaling processing techniques and in high-speed electronics have resulted in remarkable progress in just the last few years, allowing access media originally deployed more than a century ago for telephony to also support access to the Internet at previously unimagined speeds. In our brief survey of these new access technologies, we will first provide an overview of the access environment, and then go on to describe both the 56-kbps PCM modem and the xDSL class of high-speed digital lines.

The Access Environment

Today it is quite possible, and not at all uncommon, for business users to obtain direct high-speed optical fiber access to telephony and data networks, including the Internet. For smaller locations, such as individual homes and small business sites, despite experiments in the 1980s with fiber to the home and in the early 1990s with hybrid fiber coax, physical access choices mostly come down to twisted pair telephone line and cable TV coax. We will not cover business fiber access or the cable modem story here, on the grounds that the former is a relatively well understood if impressively capable technology and that the latter is somewhat outside the scope of our Internet/ telephony focus. Instead, we will look at recent developments in greatly speeding up access over ordinary telephone lines.

The twisted pair telephone line was developed in the 1880s as an improvement over earlier single-wire and parallel-wire designs. The single-wire lines, which used earth return, were noisy and subject to the variable quality of grounding connections, while the parallel-wire lines were subject to cross talk from one line to another. The twists in a twisted pair set up a self-canceling effect that reduces electromagnetic radiation from the line and thus mitigates cross talk. This simple design creates a very effective transmission medium that has found many uses in data communication (think of 10BaseT LANs and their even higher-speed successors) as well as in telephony. Two-wire telephone access lines are also called loops, as the metallic forward and return paths are viewed as constituting a loop for the current that passes through the telephone set.

In modern telephone networks, homes that are close enough to the central office are directly connected to it by an individual twisted pair (which may be spliced and cross-connected a number of times along the way). The twisted pair from a home farther away is connected instead to the remote terminal of a digital loop carrier (DLC) system. The DLC system then multiplexes together the signals from many telephone lines and sends them over a fiber-optic line (or perhaps over a copper line using an older digital technology like T1) to the central office. In the United States, close enough for a direct twisted pair line generally means less than 18,000 feet (18 kft). For a variety of reasons (including installation prior to the invention of DLCs), there are a fair number of twisted pair lines more than 18 kft in length. These use heavy-gauge wire, loading coils, or even amplifiers to achieve the necessary range. The statistics of loop length and the incidence of DLC use vary greatly among countries depending on demographic factors. In densely populated countries, loops tend to be short and DLCs may be rare. Another loop design practice that varies from country to country is the use of bridged taps. These unterminated twisted pair stubs are often found in the United States, but rarely in Europe and elsewhere.

From the point of view of data communication, the intriguing thing about this access environment is that in general it is less band-limited than an end-to-end telephone network connection, which of course is classically limited to a 4-kHz bandwidth. While there is indeed a steady falloff in the ease with which signals may be transmitted as their frequency increases, on most metallic loops (the exceptions are loops with loading coils and, more rarely, loops with active elements such as amplifiers) there is no sharp bandwidth cutoff. Thus, the bandwidth of a twisted pair loop is somewhat undefined and subject to being extended by ingenious signal processing techniques.

For decades, the standard way of pumping data signals over the telephone network was to use voiceband modems. Depending on their vintage, readers may remember when the data rate achievable by such devices was limited to 2400, 4800, or 9600 bps. This technology finally reached its limit a few years ago at around 33.6 kbps. By exploiting the extra bandwidth available in the loop plant, xDSL systems are able to reach much higher access speeds. We will describe these systems shortly, but first will take a small detour to talk about another intriguing recent advance in access that exploits a somewhat more subtle reservoir of extra bandwidth in the telephone network: the 56-kbps PCM modem.

The PCM Modem

Conventional voiceband modems are designed under the assumption that the end-to-end switched or private line connection through the telephone network is an analog connection with a bandwidth of just under 4 kHz, subject to the distortion of additive white Gaussian noise (AWGN). When the first practical voiceband modems were designed about 40 years ago, this was literally true. The path seen by a signal traveling from one telephone line to another over a long-distance switched network connection might be something like this: First over an analog twisted-pair loop to an electromechanical step-by-step switch, then over a metallic baseband or wireline analog carrier system to an electromechanical crossbar toll switch, then over a long-haul analog carrier system physically implemented as multiple microwave shots from hill to hill across a thousand miles, to another electromechanical crossbar toll switch, and back down through another analog carrier system to a local crossbar switch to the terminating analog loop. Private line connections were the same, except that permanently soldered jumper wires on cross-connect fields substituted for the electromechanical switches. Noise, of course, was added at every analog amplifier along the way for both the switched and private line cases.

A remarkable fact is that although when modeled as a black box the modern telephone network at the turn of the twenty-first century looks exactly the same as it did 40 years ago (a band-limited analog channel with some noise added to it), the interior of the network has been completely transformed to a concatenation of digital systems—mostly fiber-optic transmission systems and digital switches. Voice is carried through this network interior as sequences of 8-bit binary numbers produced by pulse-code modulation (PCM) encoders. Only the analog loops on both ends remain as a physical legacy of the old network.

By the way, what is it that makes these loops analog? After all, they are only long thin strands of copper metal—the most passive sort of electrical system imaginable. How does the loop know whether a signal impressed upon it is analog or digital? The answer is that it doesn’t know! In fact, in addition to the smoothly alternating electrical currents of analog voice, loops can carry all sorts of digital signals produced by modems and by all the varieties of digital subscriber line (DSL) systems. Ironically, the analog quality of the loop really derives from the properties of the analog telephone at the premises end of the loop and of the PCM encoder/decoder at the central office end—or, more precisely, from the assumption that the job of the PCM encoder is to sample a general band-limited analog waveform and produce a digital approximation of it, distorted by quantization noise—inevitable because the finite-length 8-bit word can only encode the signal level with finite precision.

It is this quantization noise, which averages about 33 to 39 dB, in combination with the bandwidth limitation of approximately 3 to 3.5 kHz, that limits conventionally designed modems to just over 33 kbps as calculated using the standard Shannon channel capacity formula (Ayanoglu et al., 1998).

Enter the PCM modem. Quoting Ayanoglu et al., who developed this technology at Bell Labs in the early 1990s: “The central idea behind the PCM modem is to avoid the effects of quantization distortion by utilizing the PCM quantization levels themselves as the channel symbol alphabet.” In other words, rather than designing the modem output signals without reference to the operation of the PCM encoder and then letting them fall subject to the distortion of randomly introduced quantization noise, the idea is to design the modem output so that “the analog voltage sampled by the codec passes through the desired quantization levels precisely at its 8-kHz sampling instants.” In theory, then, a pair of PCM modems attached to the two analog loops in an end-to-end telephone connection could commandeer the quantization levels of the PCM codecs at the central office ends of the loops and use them to signal across the network at something approaching the 64-kbps output rate of the voice coders. Actually, filters in the central office equipment limit the loop bandwidth to 3.5 kHz, and this in turn means that no more than 56 kbps can be achieved. Also, it turns out that there are serious engineering difficulties with attempting to manipulate the output of the codecs by impressing voltage levels on the analog side.

Fortunately, there is an easier case that is also of great practical importance to the business of access to data networks—including the Internet. Most ISPs and corporate remote access networks employ a system of strategically deployed points of presence at which dial-up modem calls from subscribers to their services are concentrated. At these points, the calls are typically delivered from the telephone company over a multiplexed digital transmission system, such as a T1 line. The ISP or corporate network can then be provided with a special form of PCM modem at the POP site that writes or reads 8-bit binary numbers directly to or from the T1 line (or other digital line), thus permitting the modem on the network side to directly drive the output of the codec on the analog line side as well as to directly observe the PCM samples it produces in the other direction. The result is that, in the direction from the network toward the consumer (the direction in which heavy downloads of things like Web pages occur), a rate approaching 56 kbps can be achieved. The upstream signal, originating in an analog domain where direct access to the PCM words is not possible, remains limited to somewhat lower speeds.

So hungry are residential and business users for bandwidth that 56-kbps modems became almost universally available on new PCs and laptops shortly after the technology was reduced to silicon—and even before the last wrinkles of standards compatibility were ironed out. The standards issues have since been worked through by ITU-T study group (SG) 16, and the 56-kbps modem is now the benchmark for dial-up access over the telephony network to the Internet.

Digital Subscriber Lines

Digital subscriber line (DSL) is the name given to a broad family of technologies that use clever signal design and signal processing to exploit the extra bandwidth of the loop plant and deliver speeds well in excess of those achievable by conventional voiceband modems. The term is often given as xDSL, where x stands for any of many adjectives used to describe different types of DSL. In fact, so many variations of DSL have been proposed and/or hyped, with so many corresponding values of x, that it can be downright confusing—too bad, really, since DSL technology has so much to offer. We will attempt to limit the confusion in this book by describing the types of DSL that appear to be of most practical importance in the near term, with a few words about promising new developments.

The term DSL first appeared in the context of ISDN—which struggled with low acceptance rates and slow deployment until it enjoyed a mini-Renaissance in the mid-1990s, buoyed by the unrelenting demand for higher-speed access to the Internet. The ISDN DSL sends 160 kbps in both directions at once over a single twisted pair. The total bit rate accommodates two 64-kbps B channels, one 16-kbps D channel, and 16 kbps for framing and line control. Bidirectional transmission is achieved using an echo-canceled hybrid technology in most of the world. In Japan, bidirectionality is achieved using Ping Pong, called time compression multiplexing by the more serious-minded, in which transmission is performed at twice the nominal rate in one direction for a while, and then, after a guard time, the line is turned around and the other direction gets to transmit. ISDN DSLs can extend up to 18 kft, so they can serve most loops that go directly to the central office or to a DLC remote terminal. Special techniques may be used to extend the range in some cases, at a cost in equipment and special engineering. ISDN DSL was a marvel of its day, but is relatively primitive in comparison to more recently developed varieties of DSL.

HDSL

The next major type of DSL to be developed was the high-bit-rate digital subscriber line (HDSL). The need for HDSL arose when demand accelerated for direct T1 line interconnection to business customer locations providing for 1.544-Mbps access. T1 was a technology for digital transmission over twisted pairs that was originally developed quite a long time ago (the early 1960s, in fact) with application to metropolitan area telephone trunking in mind. With its 1.544-Mbps rate, a T1 line could carry twenty-four 64-kbps digital voice signals over two twisted pairs (one for each transmission direction). In this application, T1 was wildly successful, and by the late 1970s it had largely displaced baseband metallic lines and older analog carrier systems for carrying trunks between telephone central offices within metropolitan regions—distances up to 50 miles or so. However, applying T1 transmission technology directly to twisted pairs going to customer premises presented several difficulties. A basic one was that T1 required a repeater every 3000 to 5000 feet. This represented a major departure from practice in the loop plant, which was engineered around the assumption that each subscriber line was connected to the central office by a simple wire pair with no electronics along the way—or at least for up to 18 kft or so when a DLC system might be encountered. Also, T1 systems employ high signal levels that present problems of cross talk and difficulties for loop plant technicians not used to dealing with signals more powerful than those produced by human speech impinging on carbon microphones.

A major requirement for the HDSL system was therefore to provide for direct access to customer sites over the loop plant without the use of repeaters. The version of HDSL standardized by the ITU-T as G.991.1 in 1998 achieves repeaterless transmission over loops up to 12 kft long at both the North American T1 rate of 1.544 Mbps and the E1 rate of 2.048 Mbps used in Europe and some other places. Repeaters can be used to serve longer loops if necessary. When employed, they can be spaced at intervals of 12 kft or so, rather than the 3 to 5 kft required in T1. The repeaterless (or few-repeater) feature greatly reduces line conditioning expenses for deployment in the loop plant compared to traditional T1. In addition, HDSL can tolerate (within limits) the presence of bridged taps, avoiding the expense of sending out technicians to remove these taps.

HDSL systems typically use two twisted pairs, just as does T1. However, rather than simply using one pair for transmitting from east to west and the other for west to east, HDSL reduces signal power at high frequencies by sending in both directions at once on each pair, but at only half the total information rate. The two transmission directions are separated electronically by using echo-canceled hybrids, just as in ISDN DSL.

Overall, HDSL provides a much more satisfactory solution for T1/E1 rate customer access than the traditional T1-type transmission system. Work is currently under way in the standards bodies on a second-generation system, called SDSL (for “symmetric” or “single-pair” DSL) or sometimes HDSL2, which will achieve the same bit rates over a single wire pair. To do this without recreating the cross talk problems inherent in T1 requires much more sophisticated signal designs borrowed from the most advanced modem technology, which in turn requires much more powerful processors at each end of the loop for implementation. By now the pattern should be familiar—to mine the extra bandwidth hidden in the humble loop plant, we apply high-speed computation capabilities that were quite undreamed of when Alexander Graham Bell began twisting pairs of insulated wire together and observing what a nice clean medium they produced for the transmission of telephone speech!

ADSL

The second major type of DSL of current practical significance is asymmetric digital subscriber line (ADSL). Compared to HDSL, ADSL achieves much higher transmission speeds (up to 10 Mbps) in the downstream direction (from the central office toward the customer) and does this over a single wire pair. The major trade-off is that speeds in the upstream direction (from the customer toward the central office) are reduced, being limited to 1 Mbps at most. ADSL is also capable of simultaneously supporting analog voice transmission.

Considering these basic characteristics, it is clear that ADSL is particularly suited to residential service in that it can support:

High-speed downloading in applications like Web surfing
Rather lower speeds from the consumer toward the ISP
Ordinary voice service on the same line

On the other hand, these characteristics also meet the needs of certain small business (or remote business site) applications as well. The basic business proposition of ADSL is that these asymmetric characteristics, which are the key to achieving the high downstream rate, represent a significant market segment. Time will tell how ADSL fares against other access options such as cable modems and fixed wireless technologies, but the proposition seems to be a plausible one.

The way ADSL exploits asymmetry to achieve higher transmission rates has to do with the nature of cross talk and with the frequency-dependent transmission characteristics of telephone lines. Earlier we noted that there is not a sharp frequency cutoff on unloaded loops, but there is a steady decline in received signal power with increasing frequency. If a powerful high-frequency (high-bit-rate) transmitter is located near a receiver trying to pick up a weak incoming high-frequency signal, the receiver will be overwhelmed by near-end cross talk. The solution is to transmit the high-frequency (high-bit-rate) signal in only one direction. A basic ADSL system is thus an application of classic frequency division multiplexing, in which a wide, high-frequency band is used for the high-bit-rate downstream channel, a narrower and lower-frequency channel is used for the moderate-bit-rate upstream transmission, and the baseband region is left clear for ordinary analog voice (see Figure 1).

Figure 1: A basic ADSL system.

The basic concept of ADSL is thus rather simple. However, implementations utilize some very advanced coding, signal processing, and error control techniques in order to achieve the desired performance. Also, a wide variety of systems using differing techniques have been produced by various manufacturers, making standardization something of a challenge. Key ITU-T standards are G.992.1 and G.992.2. The latter provides for splitterless ADSL, which deserves some additional description.

ADSL Lite

In the original ADSL concept, a low-pass filter is installed at the customer end of the line to separate the baseband analog voice signal from the high-speed data signals (see Figure 2). In most cases, this filter requires the trouble and expense of an inside wiring job at the customer premises. To avoid this expense, splitterless ADSL, also known more memorably as ADSL Lite, eliminates the filter at the customer end. This lack of a filter can create some problems, such as error bursts in the data transmission when the phone rings or is taken off hook, or hissing sounds in some telephone receivers. However, the greatly simplified installation was viewed as well worth the possible small impairments by most telephone companies, and they pushed hard for the adoption of splitterless ADSL in standards.

Figure 2: The original ADSL concept.

Factors Affecting Achieved Bit Rate

Like ISDN DSL and HDSL, a basic objective of ADSL is to operate over a large fraction of the loops that are up to 18 kft long. However, the actual bit rate delivered to the customer may vary depending on the total loss and noise characteristics of the loop. The ANSI standard for ADSL (T1.413) provides for rate-adaptive operation much like that employed by high-speed modems. The downstream rate can be as high as 10 Mbps on shorter, less noisy loops, but may go down to 512 kbps on very long or noisy loops. Upstream rates may be as high as 900 kbps or as low as 128 kbps.

Future DSL Developments

We have already mentioned that work is under way on an improved version of HDSL, called HDSL2. Another name for this sometimes seen in the literature is symmetric DSL or single-pair DSL (SDSL).

Another new system, called very-high-rate DSL (VDSL), is under discussion in standards bodies. It will provide for very high downstream rates of up to 52 Mbps. VDSL would work in combination with optical transmission into the neighborhood of the customer. High-speed transmission over the copper loop would only be used for the last kilometer or so.

Applicability

We’ve described a number of advanced access technologies that can support remarkably high-data-rate access to data networks (including the Internet) over the existing telephone plant. How do you decide which ones, if any, to use?

In the case of the 56-kbps PCM modem, the decision will likely be made for you by the manufacturer of your PC or laptop. It’s simply the latest in modems and is often supplied as a standard feature.

For xDSL, the situation is a bit more complex. In most cases, you obtain a service from a telephone company or other network provider that uses HDSL or ADSL as an underlying transmission technology. The technology may or may not be highlighted in the service provider’s description of the offering. Essentially, the decision comes down to weighing the price of the service against how well it satisfies the needs of the application, including speed but also such factors as guarantees of reliability, speed of installation, whether an analog voice channel is included or needed, and so on. If you are more adventurous, you may try obtaining raw copper pairs from a service provider and applying your own xDSL boxes. If you contemplate going this route, you really need to learn a lot more about the transmission characteristics of these systems than we’ve covered here, and you should perhaps start by consulting some of the references listed in our bibliography.

Internet Offload and Tunneling

Internet traffic has challenged the foundation of the PSTN—the way it has been engineered. Contrary to the widespread view (based on the perceived high quality that users of telephony have enjoyed for many years), which holds that the telephone networks can take any calls of any duration, the PSTN has actually been rather tightly engineered to use its resources so as to adapt to the patterns of voice calls. Typical Internet access calls last 20 minutes, while typical voice calls last between 3 and 5 minutes (Atai and Gordon, 1997). The probability of the duration of a voice call exceeding one hour is 1 percent, versus 10 percent for Internet access calls. As the result, the access calls tie up the resources of local switches and interoffice trunks, which in turn increases the number of uncompleted calls on the PSTN. (As we mentioned in the section on network traffic management, the PSTN can block calls to a switch with a high number of busy trunks or lines. The caller typically receives a fast busy signal in this case.) In today’s PSTN, the call blocking rate is the principal indicator of the quality of service. The actual bandwidth of voice circuits is grossly wasted—Internet users consume only about 20 percent of the circuit bandwidth. The situation is only further complicated by flat-rate pricing of online services—believed to encourage Internet callers to stay on line twice as long as they would with a metered-rate plan.

The three problem areas identified in Atai and Gordon (1997) are (1) the local (ingress) switch from which the call has originated; (2) the tandem switch and interoffice trunks; and (3) the local (egress) switch that terminates calls at the ISP modem pool (Atai and Gordon, 1997). (The cited document does not take into account the IXC issues, but it is easy to see they are very similar to the second problem area.) The third problem area is the most serious because it can cause focused overload. Presently, such egress switches make up roughly a third of all local switches. The acuteness of the problem has been forcing the carriers to segregate the integrated traffic and offload it to a packet network as soon as possible.

The two options for carrying out the offloading are (1) to allow the Internet traffic to pass through the ingress switch, where it would be identified, and (2) to intercept the Internet traffic on the line side of the ingress switch. In all cases, however, the Internet traffic must first be identified. Identifying Internet traffic is best done by IN means. One way (which is unlikely to be implemented) is to collect all the ISP and enterprise modem pool access numbers and trigger on them—not a small feat, even if a feasible one. This triggering would slow down all local switches to a great extent. The other solution is to use local number portability queries; to implement the solution, all modem pool numbers would have to be configured as ported numbers. The third, and much better, way to carry out the offloading is for ISPs and enterprise modem pools to use a single-number service (an example is an 800 number in the United States) and let the IN route the call. The external service logic would inform the switch about the nature of the call (this information would naturally be stored). Many large enterprises already use 800 numbers for their modem pools. The fourth solution is to assign a special prefix to the modem pool number; then the switch would know right away, even before all the digits had been dialed, that it was dealing with an Internet dial-up. (Presently, however, switches often identify an Internet call by detecting the modem signals on the line.)

Two post-switch offloading solutions are gaining momentum. The first is terminating all calls in a special multiservice module—effectively a part of the local switch—in the PSTN. The multiservice module would then send the data traffic (over an ATM, frame relay, or IP network) to the ISP or enterprise access server (which would no longer need to be involved with the modems). The other solution is to terminate all calls at network access servers that would act as switches in that they would establish a trunk with the ingress switch. The access servers would then communicate with the ISP or enterprise over the Internet. One problem with this solution is that access servers would have to be connected to the SS No. 7 network, which is expensive and, so far, hardly justified. To correct this situation, a new SS No. 7 network element, the SS7 gateway, acts as a proxy on behalf of several access servers (thus significantly cutting the cost). The access servers communicate with the SS7 gateway via an enhanced (that is, modified) ISDN access protocol, as depicted in Figure 3.

Figure 3: Internet offload with the SS7 gateway.

At this point you may ask: How are the network access servers connected to the rest of the ISP or enterprise network? Until relatively recently, this was done by means of leased telephone lines (permanent circuits) or private lines, both of which were (and still are) quite expensive. Another way to connect the islands of a network is by using tunneling, that is, sending the packets whose addresses are significant only to a particular network. These packets are encapsulated (as a payload) into the packets whose addresses are significant to the whole of the Internet, and they travel between the two border points of the network through what is metaphorically called a tunnel. Again, the packets themselves are not looked at by the intermediate nodes, because to nodes the packets are nothing but the payload encapsulated in outer packets. Only the endpoints of a tunnel are aware of the payload, which is extracted by and acted on by the destination endpoint. Tunnels are essential for an application called the virtual private network (VPN).With tunneling, for example, the two nodes of a private network that have no direct link between them may use the Internet or another IP network as a link.We will address tunneling systematically as far as security and the use of the existing protocols is concerned. Another essential aspect of tunneling is quality of service (QoS), so we address that issue again when reviewing the multiprotocol label switching (MPLS) technology. As you have probably noticed, we have already ventured into a purely IP area. This is one example where it is virtually impossible to describe a PSTN solution without invoking its IP counterpart.

Going back to the employment of the SS7 gateway, we should note one important technological development: With the SS7 gateway, an ISP can be connected to a LEC as a CLEC

Evolution of Operation, Administration, and Maintenance (OA&M)

noreply@blogger.com (JohnJenin) — Thu, 29 Oct 2009 09:08:00 +0000

There are several functions performed in the PSTN under the common name OA&M. These functions include provisioning (that is, distributing all the necessary software to make systems available for delivering services), billing, maintenance, and ensuring the expected level of quality of service. The scope of the OA&M field is enormous—it deals with transmission facilities, switches, network databases, common channel signaling network elements, and so on. Because of its scope, referring to OA&M as a single task would be as much a generalization as referring to a universal computer application. As we show later in this section, the development of the PSTN OA&M has been evolutionary; as new pieces of equipment and new functions were added to the PSTN, new OA&M functions (and often new pieces of equipment) were created to deal with the administration of these new pieces of equipment and new functions. This development has been posing tremendous administrative problems for network operators. Many hope that as the PSTN and Internet ultimately converge into one network, the operations of the new network will be simpler than they are today.

Initially, all OA&M functions were performed by humans, but they have been progressively becoming automated. In the 1970s, each task associated with a piece of transmission or switching equipment was run by a task-specific application developed only for this task’s purpose. As a result, all applications were developed separately from one another. They had a simple text-based user interface—administrators used teletype terminals connected directly to the entities they administered.

In the 1980s, many tasks previously performed by humans had become fully automated. The applications were developed to emulate humans (up to the point of the programs exchanging text messages as they would appear on the screen of a teletype terminal). These applications, called operations support systems (OSSs), have been developed for the myriad OA&M functions. In most cases, a computer executing a particular OSS was connected to several systems (such as switches or pieces of transmission equipment) by RS-232 lines, and a crude ad hoc protocol was developed for the purpose of this OSS. Later, these computers served as concentrators, and they were in turn connected to the mainframes executing the OSSs. Often, introduction of a new OSS meant that more computers and more lines to connect the computers to the managed elements were needed.

You may ask why the common channel signaling network was not used for interconnection to operations systems. The answer is that this network was designed only for signaling and could not bear any additional—and unpredictable—load. As a matter of fact, a common network for interconnecting OSSs and managed elements has never been developed, although in the late 1980s and early 1990s there was a plan to develop such a network based on the OSI model. In some cases, X.25 was used; in others proprietary data networks developed by the manufacturers of computer equipment were used by telephone companies. A serious industry attempt to create a common mechanism to be used by all OA&M applications has resulted in a standard called Telecommunications Management Network (TMN) and, specifically, its part known as the Common Management Identification Protocol (CMIP), developed jointly by the International Organization for Standardization (ISO) and ITU-T.

In the space allotted to the subject in this book, we could not possibly even list all existing OA&M tasks. Instead we review one specific task called network traffic management (NTM). This task is important to the subject of this book for the following three reasons. First, the very problem this task deals with is a good illustration of the vulnerability of the PSTN to events it has not been engineered to handle. (One such event—overload of PSTN circuits because of Internet traffic—has resulted in significant reengineering of the access to the Internet.) Second, the problems of switch overload and network overload are not peculiar to the PSTN—they exist (and are dealt with) today in data networks. Yet, the very characteristics of voice traffic are likely to create in the Internet and IP networks exactly the same problems once IP telephony takes off. Similar problems have similar solutions, so we expect the network traffic management applications to be useful in IP telephony. Third, IN and NTM often work on the same problems; it has been long recognized that they need to be integrated. The integration has not taken place in the PSTN yet, so it remains among the most important design tasks for the next-generation network.

NTM was developed to ensure quality of service (QoS) for PSTN voice calls. Traditionally, quality of service in the PSTN has been defined by factors like postdial delay or the fraction of calls blocked by one of the network switches. The QoS problem exists because it would be prohibitively expensive to build switches and networks that would allow us to interconnect all telephone users all the time. On the other hand, it is not necessary to do so, because not all people are using their telephones all the time. Studies have determined the proportion of users making their calls at any given time of the day and day of the week in a given time zone, and the PSTN has consequently been engineered to handle just as much traffic as needed. (Actually, the PSTN has been slightly overengineered to make up for potential fluctuations in traffic.) If a particular local switch is overloaded (that is, if all its trunks or interconnection facilities are busy), it is designed to block (that is, reject) calls.

Initially, the switches were designed to block calls only when they could not handle them independently. By the end of the 1970s, however, the understanding of a peculiar phenomenon observed in the Bell Telephone System—called the Mother’s Day phenomenon—resulted in a significant change in the way calls were blocked (as well as other aspects of the network operation).

Figure 1 demonstrates what happens with the toll network in peak circumstances. The network, engineered at the time to handle a maximum load of 1800 erlangs (an erlang is a unit measuring the load of the network: 1 erlang = 3600 calls x sec), was supposed to behave in response to ever increasing load just as depicted in the top line in the graph—to approach the maximum load and more or less stay there. In reality, however, the network experienced inexplicably decreasing performance way below the engineered level as the load increased. What was especially puzzling was that only a small portion of switches were overloaded at any time. Similar problems occurred during natural disasters—earthquakes and floods. (Fortunately, disasters have not occurred with great frequency.) Detailed studies produced an explanation: As the network attempted to build circuits to the switches that were overloaded, these circuits could not be used by other callers—even those whose calls would pass through or terminate at the underutilized switches. Thus, the root of the problem was that ineffective call attempts had been made that tied up the usable resources.

Figure 1: The Mother’s Day phenomenon.

The only solution was to block the ineffective call attempts. In order to determine such attempts, the network needed to collect in one place much information about the whole network. For this purpose, an NTM system was developed. The system polled the switches every now and then to determine their states; in addition, switches could themselves report certain extraordinary events (called alarms) asynchronously with polling. For example, every five minutes the NTM collects the values of attempts per circuit per hour (ACH) and connections per circuit per hour (CCH) from all switches in the network. If ACH is much higher than CCH, it is clear that ineffective attempts are being made. The NTM applications have been using artificial intelligence technology to develop the inference engines that would pinpoint network problems and suggest the necessary corrective actions, although they still rely on a human’s ability to infer the cause of any problem.

Overall, the problems may arise because of transmission facilities malfunction (as in cases when rats or moles chew up a fiber link—sharks have been known to do the same at the bottom of the ocean) or a breakdown of the common channel signaling system. In a physically healthy network, however, the problems are caused by use above the engineered level (for example, on holidays) or what is called focused overload, in which many calls are directed into the same geographical area. Not only natural disasters can cause overload. A PSTN service called televoting has been expected to do just that, and so is—for obvious reasons—the freephone service, such as 800 numbers in the United States. (Televoting has typically been used by TV and radio stations to gauge the number of viewers or listeners who are asked a question and invited to call either of the two given numbers free of charge. One of the numbers corresponds to a “yes” answer; the other to “no.” Fortunately, IN has built-in mechanisms for blocking such calls to prevent overload.)

Once the cause of the congestion in the network is detected, the NTM OSS deals with the problem by applying controls, that is, sending to switches and IN SCPs the commands that affect their operation. Such controls can be restrictive (for example, directionalization of trunks, making them available only in the direction leading from the congested switch; cancellation of alternative routes through congested switches; or blocking calls that are directed to congested areas) or expansive (for example, overflowing traffic to unusual routes in order to bypass congested areas). Although the idea of an expansive control appears strange at first glance, this type of control has been used systematically in the United States to fix congestion in the Northeast Corridor between Washington, D.C., and Boston, which often takes place between 9 and 11 o’clock in the morning. Since during this period most offices are still closed in California (which is three hours behind), it is not unusual for a call from Philadelphia to Boston to be routed through a toll switch in Oakland.

Overall, the applications of global network management (as opposed to specific protocols) have been at the center of attention in the PSTN industry. This trend continues today. The initial agent/manager paradigm on which both the Open Systems Interconnection (OSI) and Internet models are based has evolved into an agent-based approach, as described by Bieszad et al. (1999). In that paper, an (intelligent) agent is defined as computational entity “which acts on behalf of others, is autonomous, . . . and exhibits a certain degree of capabilities to learn, cooperate and move.” Most of the research on this subject comes in the form of application of artificial intelligence to network management problems. Agents communicate with each other using specially designed languages [such as Agent Communication Language (ACL)]; they also use specialized protocols [such as Contract-Net Protocol (CNP)]. As the result of the intensive research, two agent systems—Foundation for Intelligent Physical Agents (FIPA) and Mobile Agent System Interoperability Facilities (MASIF)—have been proposed. These specifications, however, are not applicable to the products and services described in this book, for which reason they are not addressed here. Consider them, though, as an important reference to a technology in the making.

Intelligent Network (IN)

noreply@blogger.com (JohnJenin) — Mon, 26 Oct 2009 07:46:00 +0000

The first service introduced in the PSTN with the help of network databases in 1980 was calling card service; soon after that, a series of value-added services for businesses called inward wide area telecommunications service (INWATS) were introduced. When the U.S. Federal Communications Commission (FCC) approved a tariff for expanded 800 service in 1982, the Bell system was ready to support it with many new features due to the distributed nature of the implementation. For example, a customer dialing an 800 number of a corporation could be connected to a particular office depending on the time of day or day of week. As the development of such features progressed, it became clear that in many cases it would be more efficient to decide how to route a customer’s call after prompting the customer with a message that provided several options, and instructions on how to select them by pushing dial buttons on the customer’s telephone. For the purpose of customer interaction, new devices that could maintain both the circuit connections to customers (in order to play announcements and collect digits) and connections to the SS No. 7 network (to receive instructions and report results to the databases) were invented and deployed. The network database ceased to be just a database—its role was not simply to return responses to the switch queries but also to instruct the switches and other devices as to how to proceed with the call. Computers previously employed only for storing the databases were programmed with the so-called service logic, which consisted of scripts describing the service. This was the historical point at which the service logic started to migrate from the switches.

After the 1984 court decree broke up the Bell System, the newly created Regional Bell Operating Companies (RBOCs) ordered their R&D arm, Bell Communications Research, to develop a general architecture and specific requirements for central, network-based support of services. An urgent need for such an architecture was dictated by the necessity of buying the equipment from multiple vendors. This development resulted in two business tasks that Bellcore was to tackle while developing the new architecture: (1) The result had to be equipment-independent and (2) as many service functional capabilities as possible were to move out of the switches (to make them cheaper). The tasks were to be accomplished by developing the requirements and getting the vendors to agree to them. As Bellcore researchers and engineers were developing the new architecture, they promoted it under the name of Intelligent Network. The main result of the Bellcore work was a set of specifications called Advanced Intelligent Network (AIN), which went through several releases.

AT&T, meanwhile, continued to develop its existing architecture, and its manufacturing arm, AT&T Network Systems, built products for the AT&T network and RBOCs. Only the latter market, however, required adherence to the AIN specifications. In the second half of the 1980s, similar developments took place around the world—in Europe, Japan, and Australia. In 1989, a standards project was initiated in ITU to develop recommendations for the interfaces and protocols in support of Intelligent Network (IN).

To conclude the historical review of IN, we give you some numbers: Today, in the United States, at least half of all interexchange carrier voice calls are IN supported. This generates on the order of $20 billion in revenue for IXCs. LECs use IN to implement local number portability (LNP), calling name and message delivery, flexible call waiting, 800 service carrier selection, and a variety of other services (Kozik et al., 1998). The IN technology also blends wireless networks and the PSTN, and, as we demonstrate further in this chapter, is being used strategically in the PSTN-Internet convergence.

We are ready now to formulate a general definition of IN: IN is an architectural concept for the real-time execution of network services and customer applications. The architecture is based on two main principles: network independence and service independence. Network independence means that the IN function is separated from the basic switching functions as well as the means of interconnection of the switches and other network components. Service independence means that the IN is to support a wide variety of services by using common building blocks.

The IN execution environment includes the switches, computers, and specialized devices, which, at the minimum, can communicate with the telephone user by playing announcements and recognizing dial tones. (More sophisticated versions of such devices can also convert text to voice and even vice versa, send and receive faxes, and bridge teleconferences). All these components are interconnected by means of a data communications network. The network can be as small as the local area network (LAN), in which case the computers and devices serve one switch (typically a PBX), or it can span most switches in an IXC or LEC. In the latter case, the data network is SS No. 7, and usually the term IN means this particular network-wide arrangement. [In the case of a single switch, the technology is called computer-telephony integration (CTI).]

The overall IN architecture also includes the so-called service creation and service management systems used to program the services and distribute these programs and other data necessary for their execution among the involved entities.

Figure 1 depicts the network-wide IN execution environment. We will need to introduce more jargon now. The service logic is executed by a service control point (SCP), which is queried—using the SS No. 7 transaction mechanism—by the switches. The switches issue such queries when their internal logic detects triggers (such as a telephone number that cannot be translated locally, a need to authorize a call, an event on the line—such as called party being busy, etc.). The SCP typically responds to the queries, but it can also start services (such as wake-up call) on its own by issuing an instruction to a switch to start a call.

Figure 1: The IN architecture.

As we noted before, to support certain service features (such as 800 number translation), the SCP may need to employ special devices (in order to play announcements and collect digits or establish a conference bridge). This job is performed by the intelligent peripheral (IP). The IP is connected to the telephone network via a line or trunk, which enables it to communicate with a human via a voice circuit. The IP may be also connected to the SS No. 7 network, which allows it to receive instructions from the SCP and respond to them. (Alternatively, the SCP instructions can be relayed to the IP through the switch to which it is connected.) As SCPs have become executors of services (rather than just the databases they used to be), the function of the databases has been moved to devices called service data points (SDPs).

Finally, there is another device, called a service node (SN), which is a hybrid of the IP, the SCP, and a rather small switch. Similar to the SCP, the SN is a general-purpose computer, but unlike the SCP it is equipped with exotic devices such as switching fabric and other things typically associated with an IP. The SN connects to the network via the ISDN access mechanism, and it runs its own service logic, which is typically engaged when a switch routes a call to it. An example of its typical use is in voice-mail service. When a switch detects that the called party is busy, it forwards the call to the SN, which plays the announcement, interacts with the caller, stores voice messages and reads them back, and so on. The protocols used for the switch-to-SCP, SCP-to-SDP, and SCP-to-IP communications are known as Intelligent Network Application Part (INAP), which is the umbrella name. INAP, has evolved from the CCS switch-to-database transaction interactions; it is presently based on the Transaction Capabilities (TC) protocol of Signalling System No. 7.

We conclude this brief discussion of the IN technology by making a point on which we systematically elaborate in the rest of this book: Because the SCP and SN are general-purpose computers, they can be easily connected to the Internet and thus engage the Internet endpoints in the PSTN services. This observation was made as early as 1995, and it has already had far-reaching consequences, as will be seen in the material that follows.

Integrated Services Digital Network (ISDN)

noreply@blogger.com (JohnJenin) — Fri, 23 Oct 2009 11:44:00 +0000

The need for data communications services grew throughout the 1970s. These services were provided (mostly to the companies rather than individuals) by the X.25-based packet switched data networks (PSDNs). By the early 1980s it was clear to the industry that there was a market and technological feasibility for integrating data communications and voice in a single digital pipe and opening such pipes for businesses (as the means of PBX access) and households. The envisioned applications included video telephony, online directories, synchronization of a customer’s call with bringing the customer’s data to the computer screen of the answering agent, telemetrics (that is, monitoring devices—such as plant controls or smoke alarms—and automatic reporting of associated events via telephone calls), and a number of purely voice services. In addition, since the access was supposed to be digital, the voice channels could be used for data connections that would provide a much higher rate than had ever been possible with the analog line and modems.

The ISDN telephone (often called the ISDN terminal) is effectively a computer that runs a specialized application. The ISDN telephone always has a display; in some cases it even looks like a computer terminal, with a screen and keyboard in addition to the receiver and speaker. Several such terminals could be connected to the network terminator (NT) device, which can be placed in the home or office and which has a direct connection to the ISDN switch. Non-ISDN terminals (telephones) can also be connected to the ISDN via a terminal adapter. As far as the enterprise goes, a digital PBX connects to the NT1, and all other enterprise devices (including ISDN and non-ISDN terminals and enterprise data network gateways) terminate in the PBX.

These arrangements are depicted on the left side of Figure 1. The right side of the figure shows the partial structure of the PSTN, which does not seem different at this level from the pre-ISDN PSTN structure. This similarity is no surprise, since the PSTN had already gone digital prior to the introduction of the ISDN. In addition, bringing the ISDN to either the residential or enterprise market did not require much rewiring because the original twisted pair of copper wires could be used in about 70 percent of subscriber lines (Werbach, 1997). What has changed is that codecs moved at the ultimate point of the end-to-end architecture—to the ISDN terminals—and the local offices did need to change somewhat to support the ISDN access signaling standardized by ITU-T. Again, common channel signaling predated the ISDN, and its SS No. 7 version could easily perform all the functions needed for the intra-ISDN network signaling.

Figure 1: The ISDN architecture.

As for the digital pipe between the network and the user, it consists of channels of different capacities. Some of these channels are defined for carrying voice or data; others (actually, there is only one in this category) are used for out-of-band signaling. (There is no in-band signaling even between the user and the network with the ISDN.) The following channels have been standardized for user access:

A. 4-kHz analog telephone channel.
B. 64-kbps digital channel (for voice or data).
C. 8- or 16-kbps digital channel (for data, to be used in combination with channel A).
D. 16- or 64-kbps digital channel (for out-of-band signaling).
H. 384-, 1536-, or 1920-kbps digital channel (which could be used for anything, except that it is not part of any standard combination of channels).

The major regional agreements support two combinations:

Basic rate interface. Includes two B channels and one D channel of 16 kbps. (This combination is usually expressed as 2B+D.)
Primary rate interface. Includes 23 B channels and 1 D channel of 64 kbps. (This combination is accordingly expressed as 23B+D, and it actually represents the primary rate in the United States and Japan. In Europe, it is 30B+D.)

The ISDN has been deployed throughout mostly for enterprise use. The residential market has never really picked up, although there has been a turnaround because of the demand for fast Internet access (it is possible to use the 2B+D combination as a single 144-kbps digital pipe) and because ISDN connections are becoming less expensive.

Even before the ISDN standardization was finished, the ISDN was renamed narrowband ISDN (N-ISDN), and work began on broadband ISDN (B-ISDN). B-ISDN will offer an end-to-end data rate of 155 Mbps, and it is based on the asynchronous transfer mode (ATM) technology. B-ISDN is to support services like video on demand—predicted to be a killer application; however, full deployment of B-ISDN means complete rewiring of houses and considerable change in the PSTN infrastructure.

Although the ISDN has recently enjoyed considerable growth owing to Internet access demand, its introduction has been slow. The United States until recently trailed Europe and Japan as far as deployment of the ISDN is concerned, particularly for consumers. This lag can in part be explained by the ever complex system of telephone tariffs, which seemed to benefit the development of the business use in the United States. Another explanation often brought up by industry analysts is leapfrogging: by the time Europe and Japan developed the infrastructure for total residential telephone service provision, the ISDN technology was available, while in the United States almost every household already had at least one telephone line long before the ISDN concept (not to mention ISDN equipment) existed

Evolution of Signaling

noreply@blogger.com (JohnJenin) — Tue, 20 Oct 2009 09:52:00 +0000

Now that we know what the voice circuit between the switches is, we can talk about how it is established. In the so-called plain old telephone service (POTS), establishing a call is routing, for once the call (for example, an end-to-end virtual circuit) is established, no routing decisions are to be made by the switches. There are three aspects to call establishment: First, a switch must understand the telephone number it receives in order to terminate the call on a line or route the call to the next switch in the chain; second, a switch must choose the appropriate circuit and let the next switch in the chain know what it is; third, the switches must test the circuit, monitor it, and finally release it at the end of the call. We will address the (quite important) concept of understanding the telephone number later. The other two circuit-related steps require that the switches exchange information. In the PSTN, this exchange is called signaling.

Initially, the signaling procedure was much closer to the original meaning of the word—the pieces of electric machinery involved were exchanging electrical signals. The human end user was (and still is) signaled with audio tones of different frequencies and durations.

As far as the switches are concerned, in the past, signaling was not unlike what our telephones do when we push the buttons to dial: switches exchanged audio signals using the very circuit (that is, trunk) over which the parties to the call were to speak. This type of signaling is called in-band signaling, and quite appropriately so, because it uses the voice band. There are quite a few problems with in-band signaling. Not only is it slow and quite annoying to the people who have to listen to meaningless tones, but also telephone users can produce the same tones the switches use and thereby deceive the network provider or disrupt the network.

To prevent fraud and also to improve efficiency, another form of signaling that would not use the voice band was needed. This could be achieved by using for signaling the frequencies that were out of the voice band (thus called out-of-band frequencies). Nevertheless, a channel in the telephone network is limited to the voice band, so there is no physical way to send frequencies beyond the voice band on such a channel. This limitation necessitated out-of-channel rather than out-of-band signaling. It was also obvious that much more information (concerning the characteristics of the circuits to be established, calling and called parties’ numbers, billing information, and so on) was required, and that this information could be stored and passed in the same form that was used for data processing. Hence (1) the information had to be encoded into a set of data structures and (2) these data structures had to be transformed over a separate data communications network. Thus, the concept of common channel signaling was born. Common channel signaling is signaling that is common to all voice channels but carried over none of them. Although it is clearly a misnomer, this type of signaling is often still called out-of-band signaling.

Let’s get back to the question of the switch understanding the telephone number. First of all, there are two types of numbers: those that actually correspond to the telephones that can be called and those that must be translated to the numbers of the first type. An example of the first type is a U.S. number +1-732-555-0137, which translates to a particular line in a particular central office (in New Jersey). An example of the second type is any U.S. number that starts with 1-800. The 800 prefix signals to the switch that the number by itself does not identify a particular switch or line (there is no 800 area code in the United States). Such a number designates a service (called toll-free in the United States or freephone in Europe) that is free to the caller but paid by the organization or person who receives calls.

Handling numbers of the first type is relatively straightforward—they end up in a switch’s routing table, where they are associated with the trunks or lines to be used in the act of establishing a call. The other (toll-free) numbers need translation. Naturally, a switch could translate the toll-free number, too, but such a solution would require tens of thousands of switches to be loaded with this information. The only feasible solution is to let a central database do the translation. The switch then needs to communicate with the database. [Note: The solution was figured out as early as 1979—see Faynberg et al. (1997) for the history.]

Another example where a database lookup is needed is implementation of local number portability (LNP). In the United States, the Telecommunications Act passed by the U.S. Congress in 1996 mandates the right of telephony service subscribers to keep their telephone numbers even when they change service providers. With that, subscribers can keep not only the numbers but also the features (such as call waiting) originally associated with the numbers. In the United States, the solutions are based on switches’ capabilities to query databases so as to locate the terminating switch when they encounter numbers marked as ported. (To be precise, this process requires two database dips—one to determine whether a dialed number is portable and the other to find the terminating switch.)

For both types of communications—out-of-band signaling among the switches and querying the database—the Bell Telephone System has designed a special data network called a common channel interoffice signaling (CCIS) network. When this network was introduced—in 1976—it was used only for out-of band signaling (hence interoffice). Thus the network served as a medium for communicating information about any trunk (channel) without being associated with that particular trunk. In other words, it was a medium common to all trunks, hence the term common channel. In the early 1980s, the network databases were connected to the network; thus signaling ceased to be strictly interoffice, and the I was taken away from the CCIS. Both the network and the concept became known as common channel signaling (CCS).

The architecture of the CCS network is depicted in Figure 1. The endpoints of the system are switches and network databases. The CCS routers are called signaling transfer points (STPs). Since all signaling has been outsourced to it, the CCS network must be as fast and as reliable as the network of the telephone switches. The reliability has been achieved through high redundancy: All STPs within the network are fully interconnected. Furthermore, each STP has a mated STP, with which it is connected through a high-speed link (C-link). Interconnection with other STPs is achieved through a backbone link (B-link). Finally, switches and databases are connected to STPs by A-links.

Figure 1: The common channel signaling (CCS) architecture.

Historically, there are two distinct types of protocols within common channel signaling: (1) interactions between the switches and databases that started as simple query/response messages for number translation and have evolved into service-independent protocols that support multiple services for IN technology, described later in this chapter; and (2) the protocols by means of which the switches exchange information necessary to establish, maintain, and tear down calls.

The CCS network has evolved through several releases and enhancements in the Bell System, and subsequently other telephone companies, which eventually resulted in multiple CCS networks. To ensure the interoperability of these networks as well as multivendor equipment interoperability in each of them, ITU-T has developed an international standard for common channel signaling. The latest release of this standard is called Signalling System No. 7 (SS No. 7).

Note that the official ITU-T abbreviation of this term is SS No. 7; however, the unofficial (but much easier to write and pronounce) term SS7 is used throughout the industry. In this book, we use the official term whenever we refer to the standard or its implementation in the network; we use SS7 when we refer to new classes of products (such as the SS7 gateway).

Evolution of Switching

noreply@blogger.com (JohnJenin) — Sat, 17 Oct 2009 09:49:00 +0000

As noted, the first switch was a switching matrix (board) operated by a human. The 1890s saw the introduction of the first automatic step-by-step systems, which responded to rotary dial pulses from 1 to 10 (that is, digits 1 through 9 to 0). Cross-bar switches, which could set up a connection within a second, appeared in late 1930s. Step-by-step and cross-bar switches are examples of space-division switches; later, this technology evolved into that of time-division. A large step in switching development was made in the late 1960s as a consequence of the computer revolution. At that time computers were used for address translation and line selection. By 1980, stored program control as a real-time application running on a general-purpose computer coupled with a switch had become a norm.

At about the same time, a revolution in switching took place. Owing to the availability of digital transmission, it became possible to transmit voice in digital format. As the consequence, the switches went digital. For the detailed treatment of the subject, we recommend Bellamy (2000), but we are going to discuss it here because it is at the heart of the matter as far as the IP telephony is concerned. In a nutshell, the switching processes end-to-end voice in these four steps:

A device scans in a round-robin fashion all active incoming trunks and samples the analog signal at a rate of 8000 times a second. The sampled signal is passed to the coder part of the coder/decoder device called a pulse-code modulation (PCM) codec, which outputs an 8-bit string encoding the value of the electric amplitude at the moment of the sample
Output strings are fed into a frame whose length equals 8 times the number of active input lines. This frame is then passed to the time slot interchanger, which builds the output frame by reordering the original frame according to the connection table. For example, if input trunk number 3 is connected to output trunk number 5, then the contents of the 3rd byte of the input frame are inserted into the 5th byte of the output frame. (There is a limitation on the number of lines a time slot interchanger can support, which is determined solely by the speed at which it can perform, so the state of the art of computer architecture and microelectronics is constantly applied to building time slot interchangers. The line limitation is otherwise dealt with by cascading the devices into multistage units.)
On outgoing digital trunk groups, the 8-bit slots are multiplexed into a transmission carrier according to its respective standard. (We will address transmission carriers in a moment.) Conversely, a digital switch accepts the incoming transmission frames from a transmission carrier and switches them as described in the previous step.
At the destination switch, the decoder part of the codec translates the 8-bit strings coming on the input trunk back into electrical signals.

Note that we assumed that digital switches were toll offices (we called both incoming and outgoing circuits trunks). Indeed, initially only the toll switches on the top of the hierarchy went digital, but then digital telephony moved quickly down the hierarchy, and in the 1980s it migrated to the central offices and even PBXs. Furthermore, it has been moving to the local loop by means of the ISDN and digital subscriber line (DSL) technologies addressed further in this part.

The availability of digital transmission and switching has immediately resulted in much higher quality of voice, especially in cases where the parties to a call are separated by a long distance (information loss requires the presence of multiple regenerators, whose cumulative effect is significant distortion of analog signal, but the digital signals are fairly easy to restore—0s and 1s are typically represented by a continuum of analog values, so a relatively small change has no immediate, and therefore no cumulative, effect).

We conclude this section by listing the transmission carriers and formats. The T1 carrier multiplexes 24-voice channels represented by 8-bit samples into a 193-bit frame. (The extra bit is used as a framing code by alternating between 0 and 1.) With data rates of 8000 bits per second, the T1 frames are issued every 125 ms. The T1 data rate in the United States is thus 1.544 Mbps. (Incidentally, another carrier, called E1, which is used predominantly outside of the United States, carries thirty-two 8-bit samples in its frame.)

T1 carriers can be further multiplexed bit by bit into higher-order carriers, with extra bits added each time for synchronization:

Four T1 frames are multiplexed into a T2 frame (rate: 6.312 Mbps)
Six T2 frames are multiplexed into a T3 frame (rate: 44.736 Mbps)
Six T3 frames are multiplexed into a T4 frame (rate: 274.176 Mbps)

The ever increasing power of resulting pipes is depicted in Figure 1

Figure 1: The T-carrier multiplexing nomenclature.

Structure of the PSTN

noreply@blogger.com (JohnJenin) — Tue, 13 Oct 2009 09:45:00 +0000

At the very beginning of the telephony age, telephones were sold in pairs; for a call to be made, the two telephones involved had to be connected directly. So, in addition to the grounding wire, if there were 20 telephones you wanted to call (or that might call you), each would be connected to your telephone by a separate wire. At certain point, it was clear that a better long-term solution was needed, and such a solution came in the form of the first Bell Company switching office in New Haven, Connecticut. The office had a switching board, operated by human operators, to which the telephones were connected. An operator’s job was to answer the call of a calling party, inquire as to the name of the called party, and then establish the call by connecting with a wire two sockets that belonged to the calling and called party, respectively. After the call was completed, the operator would disconnect the circuit by pulling the wire from the sockets. Note that no telephone numbers were involved (or needed). Telephone numbers became a necessity later, when the first automatic switch was built. The automaton was purely mechanical—it could find necessary sockets only by counting; thus, the telephones (and their respective sockets in the switch) were identified by these telephone numbers. Later, the switches had to be interconnected with other switches, and the first telephone network—the Bell System in the United States—came to life. Other telephone networks were built in pretty much the same way.

Many things have happened since the first network appeared—and we are going to address these things—but the structure of the PSTN in terms of its main components remained unchanged as far as the establishment of the end-to-end voice path is concerned. The components are:

Station equipment [or customer premises equipment (CPE)]. Located on the customer’s premises, its primary functions are to transmit and receive signals between the customer and the network. These types of equipment range from residential telephones to sophisticated enterprise private branch exchange systems (PBXs).
Transmission facilities. These provide the communications paths, which consist of transmission media (atmosphere, paired cable, coaxial cable, light guide cable, and so on) and various types of equipment to amplify or regenerate signals.
Switching systems. These interconnect the transmission facilities at various key locations and route traffic through the network. (They have been called switching offices since the times of the first Connecticut office.)
Operations, administration, and management (OA&M) systems. These provide administration, maintenance, and network management functions to the network.

Until relatively recent times, switching boards remained in use in relatively small organizations (such as hotels, hospitals, or companies of several dozen employees), but finally were replaced by customer premises switches called private branch exchanges (PBXs). The PBX, then, is a nontrivial, most sophisticated example of station equipment. On the other end of the spectrum is the ordinary single-line telephone set. In addition to transmitting and receiving the user information (such as conversation), the station equipment is responsible for addressing (that is, the task of specifying to the network the destination of the call) as well as carrying other forms of signaling [idle or busy status, alerting (that is, ringing), and so on].

As Figure 1demonstrates, the station equipment is connected to switches. The telephones are connected to local switches (also interchangeably called local offices, central offices, end offices, or Class 5 switches)by means of local loop circuits or channels carried over local loop transmission facilities. The circuits that interconnect switches are called trunks. Trunks are carried over interoffice transmission facilities. The local offices are, in turn, interconnected to toll offices (called tandem offices in this case). Finally, we should note that in all this terminology the word office is interchangeable with exchange, and, of course, switch. It is very difficult to say which word is more widely used.

Figure 1: Local and tandem offices.

The trunks are grouped; it is often convenient to refer to trunk groups, which are assigned specific identifiers, rather than individual trunks. Grouping is especially convenient for the purposes of network management or assignment to transmission facilities. (A trunk is a logical abstraction rather than a physical medium; a trunk leaving a switch can be mapped to a fiber-optic cable on the first part of its way to the next switch, microwave for the second part, and four copper wires for the third part.)

In the original Bell System, there were five levels in the switching hierarchy; this number has dropped to three due to technological development of nonhierarchical routing (NHR) in the long-distance network. NHR was not adopted by the local carriers, however, so they retained the two levels—local and tandem—of switching hierarchy.

Local switches in the United States are grouped into local access and transport areas (LATAs). You can find a current map of LATAs at www.611.net/NETWORKTELECOM/lata_map/index.htm. A LATA may have many offices (on the order of 100), including tandem offices. Service within LATAs is typically provided by local exchange carriers (LECs). Some LECs have existed for a considerable time (such as original Bell Operating Companies, created in 1984 as a result of breakup of the Bell system), and so are called incumbent LECs (ILECs); others appeared fairly recently, and are called competitive LECs (CLECs). Inter-LATA traffic is carried by inter-exchange carriers (IXCs). The IXCs are connected to central or tandem offices by means of points of presence (POPs).

Figure 1 depicts an interconnection of an IXC with one particular LATA. The IXC switches form the IXC network, in which routing is typically nonhierarchical. Presently, IXCs are providing local service, too; however, since their early days IXCs have had direct trunks to PBXs of large companies to whom they provided services like virtual private networks (VPNs).^[3] We should mention that IXCs in the United States can (and do) interconnect with the overseas long-distance service providers by means of complex gateways that perform call signaling translations, but the IXCs in the United States are typically not directly interconnected with each other.

Figure 2: The interconnection of LATAs and IXCs.

Configuring H.323 Gatekeeper

noreply@blogger.com (JohnJenin) — Sat, 19 Sep 2009 07:27:00 +0000

Setting up a Cisco router as a gatekeeper requires registering a zone of influence, stating other gatekeepers for other zones, and registering any zone prefixes, technology prefixes, and E.164 addresses with the gatekeeper.

H.323 ID Addresses

Interzone communications are handled via domain name registration (in DNS). H.323 interzone communications work very much like any DNS registration. Every gatekeeper is responsible for its own zone. The zone is registered as an H.323 domain, and each domain has a domain name. For example, to resolve an address gateway1@zonE-1.com, the end station's gatekeeper will find a gatekeeper that has the zonE-1.com domain registered. It will then send a request for an IP address resolution to that gatekeeper in the form of an LRQ request to resolve the gateway1 entity.

Zone Prefixes

Zone prefixes perform the same functionality as domain names, but in a different numeric fashion. A good example of zone prefixes is an area code on the PSTN. When placing a local call, you do not have to include the area code with the telephone number if the destination is within the same area (zone). To get to a number outside your area code, you need to dial the destination area code first so that the telephone company can route the call properly. Zone prefixes are the internal functions that handle this problem.

Consider this example: The local gatekeeper knows that if it receives a telephone call with a zone prefix of 404xxxxxxx (the area code of 404 followed by seven arbitrary digits), the call is to be forwarded to the gatekeeper registered with that zone (atlgk in the following example). This command is issued on the local gatekeeper using the following syntax:

Atlanta(config-gk)# zone prefix atlgk 404. . . . . . .

In this case, the zone remote command will also be specified to indicate that the zone is not handled by the local gatekeeper. This helps the gateway to handle the transmission more efficiently by sending a LRQ to the remote gatekeeper for resolution. If this command is not used, the local gatekeeper is queried first. It will have to perform general broadcasts for resolution to other gatekeepers. With the zone remote command, this process is streamlined and performance is improved. In conjunction with the zone remote command, the zone local command identifies a zone as belonging to the local gatekeeper. The resolution process is again streamlined by pre-qualifying the zone as local.

The zone remote command sends the call from the Atlanta gatekeeper to the gatekeeper in Orlando. The call is received by the Orlando gatekeeper and is routed out to its final destination zone. If the E.164 address for the destination is registered with the gatekeeper, it will route the call to the H.323-enabled device. Usually, the device is not an H.323-enabled device and is not registered with the gatekeeper. The call is most likely going to a standard telephone that is not registered directly with the gatekeeper and needs to be forwarded to a gateway for processing. The gatekeeper looks at zone prefixes or technology prefixes to determine the proper gateway. Figure 1 illustrates the local and remote zone concepts.

Figure 1: Gatekeeper Zone Prefix

Let's discuss the steps to configure a gatekeeper based on the example scenario in Figure 1.

The steps to take to configure a Cisco router to act as an H.323 gatekeeper are:

Enter Global Configuration mode:
```
router# configure terminal
```
Activate the gatekeeper functionality on the router:
```
router(config)# gatekeeper
```

Specify a zone controlled by a gatekeeper:

router(config-gk)# zone local gatekeeper-name domain-name [ ras-IP-address]

Set a static entry for another zone's gatekeeper address so that information for that zone can be forwarded:

router(config-gk)# zone remote other-gatekeeper-name other-domain-name other-
gatekeeper-ipaddress [port number]

Configures the gatekeeper to acknowledge its own or remote prefixes:
```
router(config-gk)# zone prefix gatekeeper-name e.164-prefix 
```
Configure a technology prefix for the various types of service in the zone. The hopoff command tells to which gatekeeper to pass off the tech prefix, if appropriate. Configure the gatekeeper to acknowledge its own or remote prefixes:
```
router(config-gk)# gw-type-prefix type-prefix [hopoff gkid] [default-technology]
[[gw ipaddr ipaddr [port]]…]
```

The following is a partial configuration clip from the Atlanta gatekeeper router:

gatekeeper
zone local Atlgk1 cisco.com
zone remote Orlgk1 cisco.com 192.168.2.1 1719
zone prefix Atlgk1 404.......
gw?type?prefix 404#*
no shutdown

Enter the following command to verify gateway and gatekeeper configuration from the Atlanta gateway:

Atlgw1# show gateway
Gateway Atlgw1@cisco.com is registered to Gatekeeper Atlgk1
Alias list (CLI configured)
H323-ID Atlgw1@cisco.com
Alias list (last RCF)
H323-ID Atlgw1@cisco.com

Configuring H.323 Gateway

noreply@blogger.com (JohnJenin) — Wed, 16 Sep 2009 12:16:00 +0000

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

Enter Global Configuration mode:
```
router# configure terminal
```
Enable the VoIP gateway:
```
router(config)# gateway 
```
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:

Enter Interface Configuration mode:
```
router(config)# interface ethernet 1/0
```
Configure an IP address for this interface with subnet mask:
```
router(config-if)# ip address 192.168.1.1 255.255.255.0
```
Designate this interface as being the H.323 gateway interface:
```
router(config-if)# h323-gateway voip interface
```
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
```
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
```
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
```
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#
```

Configuring T-CCS

noreply@blogger.com (JohnJenin) — Mon, 14 Sep 2009 11:45:00 +0000

T-CCS uses a dedicated channel for signaling. There are three modes for configuring T-CCS: cross-connect, clear-channel CODEC, and frame forwarding.

T-CCS is supported with VoATM, VoFR, and VoIP. An example using T-CCS is illustrated in Figure 1, with two sites connected via IP and their respective telephone extensions per PBX.

Figure 1: T-CCS Example

Based on the example in Figure1, the following steps are needed to complete a basic T-CCS configuration to the router at the Atlanta location. The Orlando configuration would be very similar and have mirrored dial-peer statements:

Configure the T-1 controller:
```
router(config)# controller T-1 1/0
```
Set the T-1 channels that are used and the signaling associated with each channel:
```
router(config-controller)# ds0-group 0 timeslots 1-24 type ext-sig
```
Enable the T-1 controller:
```
router(config-controller)# no shutdown
```
Exit from Controller Configuration mode:
```
router(config-controller)# exit
```
Set up the local dial peer for the connection to the PBX:
```
router(config)# dial-peer voice 4000 pots
```
Set up the local destination pattern for the connection to the PBX:
```
router(config-dialpeer)# destination-pattern 4…
```
Associate the T-1 ds0-group to the dial peer:
```
router(config-dialpeer)# port 1/0:0
```
Exit dial-peer configuration mode:
```
router(config-dialpeer)# exit
```
Set up the dial peer for the connection to the remote PBX:
```
router(config)# dial-peer voice 5000 voip
```

Set the CODEC complexity to clear channel:

router(config-dialpeer)# CODEC clear-channel

Set up the destination-pattern for the connection the remote PBX:
```
router(config-dialpeer)# destination-pattern 5…
```
Configure the IP session target for the dial peer pointing to the remote router:
```
router(config-dialpeer)# session target ipv4:192.168.254.2
```

Configuring Q.931 Support

noreply@blogger.com (JohnJenin) — Fri, 11 Sep 2009 08:14:00 +0000

Q.931 establishes and terminates ISDN circuits. This occurs at the network layer in the protocol stack. The basic steps to configure ISDN PRI with Q.931 are as follows:

Select the service provider ISDN PRI switch type:
```
router(config)# isdn switch-type primary-net5 
```
Configure the ISDN T-1/E-1 controller by setting the time slots, which are used for a T-1. The range is 1–23:
```
router(config)# controller {T-1 | E-1} slot/port
router(config-controller)# pri-group timeslots range
```
Exit from the T-1/E-1 controller configuration mode:
```
router(config-controller)# exit
```
Configure the ISDN D channel interface:
```
router(config)# interface serial0/0:n
```
Configure the ISDN protocol as primary slave or the primary master:
```
router(config)# isdn protocol-emulate {network | user}
```
Enable or disable power supplied from an NT configured port:
```
router(config-if)# [no] line-power
```

Allow incoming voice calls:

router(config-if)# isdn incoming-voice voice

Configuring CAS

Configuring ISDN PRI Voice Ports

noreply@blogger.com (JohnJenin) — Tue, 08 Sep 2009 07:13:00 +0000

Earlier in the chapter, we discussed the analog VICs modules such as the E&M, FXO, and FXS, but larger organizations that need higher-density interfaces to the PSTN or PBX typically use digital T-1/E-1 modules. The following is a list of digital voice interfaces and supported platforms:

Digital T-1/E-1 Packet Voice Trunk Network Module, NM-HDV (VWIC-1MFT and VWIC-2MFT) Cisco 2600 and 3600 series.
Digital voice interface card (DVM) Cisco MC3810.
Octal or Quad T-1/E-1/PRI feature card Cisco AS5300 universal access server.
Channelized trunk card and voice feature card Cisco AS5800 universal access server.
T-1/E-1 high-capacity digital voice port adapter Cisco 7200 and 7500 series.

As with analog, the VICs are inserted into the VNMs to create the digital T-1 voice module for the Cisco 2600 and 3600 series routers. The Cisco 1760 router can use the individual VWIC-2MFT-T-1 card as an interface to a PBX or PSTN for digital connectivity. The card uses a RJ-48 crossover cable for connection to a PBX. The pinouts are listed below:

Pin 1 RX ring
Pin 2 RX tip
Pin 4 TX ring
Pin 5 TX tip

The items needed for configuration of the controller settings are the following:

Line interface T-1 or E-1
Signaling interface FXO, FXS, or E&M and ISDN PRI or BRI—Q.SIG or CCS
Line coding AMI or B8ZS for T-1, and AMI or HDB3 for E-1
Framing format SF (D4) or ESF for T-1, and CRC4 or no-CRC4 for E-1
Number of channels

The controller configuration steps for an ISDN PRI connection to a PBX follow:

router# config terminal
router(config)# isdn switch-type basic-ni1
router(config)# controller T-1 1/0
router(config-controller)# framing esf
router(config-controller)# clock source internal
router(config-controller)# linecode b8zs
router(config-controller)# pri-group timeslots 1-24

This produces the following configuration:

(Partial Router configuration)
!
hostname router
!
memory-size iomem 15
voice-card 1
!
isdn switch-type ni1
!
controller T-1 1/0
framing esf
clock source line
linecode b8zs
pri-group timeslots 1-24
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni1
isdn incoming-voice voice
isdn T310 60000
no cdp enable
!
voice-port 1/0:23
!

Configuring ISDN BRI Voice Ports

noreply@blogger.com (JohnJenin) — Sat, 05 Sep 2009 10:11:00 +0000

Cisco routers support several types of ISDN voice interface cards such as VIC-2BRI-S/T-TE and VIC-2BRI-NT/TE, which can provide connectivity to a PBX or PSTN. A benefit of using the ISDN BRI VIC rather than the analog VIC modules is the additional calling information that is passed.

Up to four calls are supported when the VIC-2BRI is installed in the NM-2V module. The BRI VIC needs to be installed in Slot 0 of the NM-2V for both ports to be active. If an additional VIC is installed in the second slot of the NM-2V, the second port on the first VIC will be disabled. This is based on the two ports of the BRI VIC requiring four DSPs. The VIC interface modules support both ISDN network and user-side configurations. The following are the steps necessary to configure ISDN BRI to a PBX:

Enter global configuration mode:
```
router# configure terminal
```
Set the global ISDN switch type. The only NT supported type is basic-net or basic-qsig:
```
router(config)# isdn switch-type switch-type
```
Set the ISDN BRI interface slot and port:
```
router(config)# interface bri slot|port
```
Ensure that no IP address is configured for the ISDN interface (voice only):
```
router(config-if)# no ip address
```

Specify incoming voice calls over ISDN:

router(config-if)# isdn incoming-voice voice

Shut down the interface. Configure the physical layer type. Enable interface with no shutdown:
- Enter user to configure the port as TE and to function as a clock slave. This is the default.
- Enter network to configure the port as NT and to function as a clock master.
```
router(config-if)# shutdown
router(config-if)# isdn layer1-emulate {user | network}
router(config-if)# no shutdown
```
Turn on or off the power supplied from an NT-configured port to a TE device:
```
router(config-if)# [no] line-power
```

Configure the Layer 2 and Layer 3 port protocol:

router(config-if)# isdn protocol-emulate {user | network}

Exit global configuration mode:
```
router(config)# end
```

Figure 1 illustrates a scenario with ISDN BRI connectivity to a PBX and PSTN. A partial configuration lists the commands pertaining to the PSTN and PBX interfaces.

Figure 1: ISDN BRI PBX and PBX Scenario

(Partial Cisco 1760 configuration)
!
hostname 1760
!
 isdn switch-type basic-net3
!
interface BRI 1/0
no shutdown
description connected to PBX
no ip address
 isdn switch-type basic-net3
 isdn incoming-voice voice
shutdown
isdn layer1-emulate user
no shutdown
isdn protocol-emulate user
!
interface BRI 2/0
no shutdown
description connected to PSTN
no ip address
 isdn switch-type basic-net3
 isdn incoming-voice voice
 isdn overlap-receiving
shutdown
isdn layer1-emulate network
no shutdown
isdn protocol-emulate network

Voice Port-Tuning Commands

noreply@blogger.com (JohnJenin) — Sat, 29 Aug 2009 11:22:00 +0000

Voice port fine-tuning commands adjust timing, delay, impedance parameters, input gain, and output attenuation. Once these adjustments are made, you can fine-tune volume control, how the number pads are dialed, and how long a voice port will wait before hanging up a signal.

Concepts of Delay and Echo

The most challenging part of designing a VoIP network is the transmission of real-time traffic. Voice communication is sensitive to delays and echo. Speech patterns become awkward and indistinguishable if there is too much delay in the voice traffic. Minimize delay as much as you can to get the voice traffic as close to real time as possible. In today's voice trafficking, two different kinds of delay must be handled: fixed delay and variable delay. The various delay points are illustrated in Figure 1.

Figure 1: Voice Packet Delay

Echo is the reflection of voice traffic back to the source of that traffic. A certain amount of echo is acceptable and desirable because it assures the source that voice traffic has been generated and sent. Too much echo is disruptive because the speaker will not be able to discern between his voice and the echo.

Fixed delay is the amount of time the signal needs to transverse the medium, such as copper, fiber, or microwave. This time is fixed because the laws of physics dictate how fast the data signals will go on particular media. Acceptable levels for most users are below 150ms one-way per ITU G.114. Fixed delays are composed of CODEC delays, packetization delays, and serialization.

CODEC induced delay Compression/decompression of a voice packet from analog to digital format and vice versa. It ranges from 0.75ms to 30ms, depending on the CODEC used.
Packetization delay Time it takes the equipment to actually produce a data packet. Should be under 30ms.
Serialization Time it takes to clock a voice or data frame onto a network interface. Affected by the frame size and line speed.

Variable delays are synonymous with jitter and are caused by queuing variances during the transmission of a packet through the network. As the packets are transferred out of the queue, there can be a delay between voice packets that sounds like stuttering speech. QoS features can be used to alleviate the effects of jitter by prioritizing the voice traffic over other traffic. You can curb delay using several methods.

Queuing Time it takes for a packet to exit the output queue of the device that is routing the data. Measured from the time the data is generated into the input queue to when it is released by the output queue.
Network switching Delay across the public network such as a Frame Relay or ATM network.
De-jitter Voice traffic works best if there is a constant flow of packets. Jitter must be minimized to improve the quality of the conversation. De-jitter buffers are utilized on the receiving end to adjust the variable delays into a fixed delay.

The command that adjusts the Cisco de-jitter buffering is playout-delay. The playout-delay command was configured under the voice-port configuration mode before IOS release 12.1(5)T. Release 12.1(5)T and later implement the command under the dial-peer configuration mode. The following steps are used to configure playout delay:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port (Cisco 175x/1760 and MC3810)

Determine the mode in which the jitter buffer will operate for calls on this voice port.
- Adaptive Adjusts the jitter buffer size and amount of playout delay based on current network conditions. This is the default setting.
- Fixed Defines the jitter buffer size as fixed so that the playout delay does not adjust. A constant playout delay is added.
```
router(config-voiceport)# playout-delay mode {adaptive| fixed]
```

Tune the playout buffer to accommodate packet jitter caused by switches in the WAN:

router(config-voiceport)# playout-delay {nominal value| maximum value 
    | minimum {default | low | high}}

Fine-Tuning FXS/FXO Ports

Special parameters can be adjusted to fine-tune the ports, minimizing issues of delay and echo. In most cases, the default parameters for FXO/FXS ports will be sufficient, but special values can be set for the following parameters:

Input gain
Output attenuation
Echo-cancel coverage
Nonlinear processing
Initial digit timeouts
Interdigit timeouts
Timing other than timeouts

To change any of these parameters, follow these steps:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure:

router# (config)voice-port nm-module/vic-module/port-number

Specify the amount of receiver gain on the interface in decibels. Value can be (–6) to 14:
```
router(config-voiceport)# input gain value
```
Specify the amount of transmit attenuation on the interface in decibels. Value can be 0 to 14:
```
router(config-voiceport)# output attenuation value
```
Enable echo-cancellation for voice signals sent out of the interface and received back on the same interface. Excessive echo can cause disruption to normal conversation patterns.
```
router(config-voiceport)# echo-cancel enable
```
Adjust the size of the echo-cancel coverage time in milliseconds. Values are 16, 24, or 32:
```
router(config-voiceport)# echo-cancel coverage value
```
Enable "nonlinear" processing, which shuts off any signal if no speech is detected on the near end. This is used in conjunction with echo cancellation:
```
router(config-voiceport)# non-linear
```
Configure how long the system will wait for the first digit to be input by the user after an off-hook state is detected. This value can be anywhere between 0 and 120 seconds:
```
router(config-voiceport)# timeouts initial seconds
```
Configure how long the system will wait for subsequent digits after the initial digit is received. This value can be anywhere between 0 and 120 seconds:
```
router(config-voiceport)# timeouts interdigit seconds
```
Specify how long the digital signal lasts for DTMF digit signals. The range is from 50 to 100 milliseconds, with a default of 100 milliseconds:
```
router(config-voiceport)# timing digit milliseconds
```
Specify the delay between digit signals for DTMF digit signals. Range is from 50 to 100 milliseconds, the default being 100 milliseconds:
```
router(config-voiceport)# timing inter-digit milliseconds
```
Configure the length of pulse signal. This command is for FXO ports only using pulse signals. The range is 10 to 20 milliseconds and the default is 20 milliseconds:
```
router(config-voiceport)# timing pulse-digit milliseconds
```
Configure length of delay between digit signals. This command is for FXO ports only using pulse signals. The range is from 100 to 1000 milliseconds and the default is 500 milliseconds:
```
router(config-voiceport)# timing pulse-inter-digit milliseconds
```

Fine-Tuning E&M Ports

E&M ports may require fine-tuning. The following steps are used to fine-tune E&M ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure:

router# (config)voice-port nm-module/vic-module/port-number

Specify the amount of receiver gain on the interface in decibels. Value can be (–6) to 14:
```
router# (config-voiceport)input gain value
```
Specify the amount of transmit attenuation on the interface in decibels. Value can be 0 to 14:
```
router# (config-voiceport)output attenuation value
```
Enable echo-cancellation for voice signals sent out of the interface and received back on the same interface.
```
router# (config-voiceport)echo-cancel enable
```
Adjust the size of the echo-cancel coverage in milliseconds. Values are 16, 24, or 32:
```
router# (config-voiceport)echo-cancel coverage value
```
Enable nonlinear processing, which shuts off any signal if no speech is detected on the near end. This is used in conjunction with echo cancellation:
```
router# (config-voiceport)non-linear
```
Configure how long the system will wait for the first digit to be input by the user after an off-hook state is detected. This value can be anywhere between 0 and 120 seconds:
```
router# (config-voiceport)timeouts initial seconds
```
Configure how long the system will wait for subsequent digits after the initial digit is received. This value can be anywhere between 0 and 120 seconds:
```
router# (config-voiceport)timeouts interdigit seconds
```
Specify how long the digit signal will last for DTMF digit signals. The range is from 50 to 100 milliseconds:
```
router# (config-voiceport)timing digit milliseconds
```
Specify the delay between digit signals for DTMF digit signals. The range is from 50 to 500 milliseconds:
```
router#(config-voiceport)timing inter-digit milliseconds
```
Specify the pulse-dialing rate. This is used for pulse dialing only. The range is from 10 to 20 pulses per second:
```
router# (config-voiceport)timing pulse pulse-per-second
```
Configure the delay between digit signals. This is used for pulse dialing only. The range is from 100 to 1000 milliseconds:
```
router# (config-voiceport)timing pulse-inter-digit milliseconds
```
Configure the delay signal time for delay dial signaling. The range is from 100 to 5000 milliseconds:
```
router#(config-voiceport)timing delay-duration milliseconds
```
Configure the minimum time for outgoing seizure to out-dial address. The range is from 20 to 2000 milliseconds:
```
router# (config-voiceport)timing delay-duration milliseconds
```
Specify the time between generations of "wink-like" pulses. The range is from 0 to 5000 milliseconds:
```
router# (config-voiceport)timing delay-pulse min-delay milliseconds
```
Specify the minimum amount of time between the off-hook signal and the call being completely cleared. The range is from 200 to 2000 milliseconds:
```
router# (config-voiceport)timing clear-wait milliseconds
```
Specify the delay signal time for delay dial signaling. The range is from 100 to 5000 milliseconds:
```
router(config-voiceport)timing delay-duration milliseconds
```
Configure the maximum wink-wait duration. The range is from 100 to 400 milliseconds:
```
router(config-voiceport)# timing wink-duration milliseconds
```
Configure the maximum wink-wait duration for wink-start signal. The range is from 100 to 5000 milliseconds:
```
router(config-voiceport)# timing wink-wait milliseconds
```

Some added features always need to be adjusted for the DID ports. Contrary to the default settings of the FXO/FXS ports, in most cases DID ports require fine-tuning adjustments. Follow these steps to fine-tune DID ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify the port to configure:

router(config)# voice-port nm-module/vic-module/port-number

This command sets the maximum time to wait for wink signaling after an outgoing seizure is sent. This is optional for wink-start ports only:
```
router(config-voiceport)# timing wait-wink milliseconds
```
This command sets the maximum time to wait before sending wink signals after an incoming seizure is detected. This is optional for wink-start ports only:
```
router(config-voiceport)# timing wink-wait milliseconds
```
This command sets the duration of a wink-start signal. This is optional for wink-start ports only:
```
router(config-voiceport)# timing wink-duration milliseconds
```
This command sets the duration of the delay signal. This is optional for delay dial ports only:
```
router(config-voiceport)# timing delay-duration milliseconds
```
This command sets the delay interval after an incoming seizure is detected. This is optional for delay dial ports only:
```
router(config-voiceport)# timing delay-start milliseconds
```

Configuring Voice Ports

noreply@blogger.com (JohnJenin) — Wed, 26 Aug 2009 08:20:00 +0000

We have now discussed the basic hardware installation for VNMs and VICs. The next step is to configure the cards on the Cisco router IOS. Voice card configuration is covered in the following sections. Some basic configuration parameters must be set in order for a voice port to operate. To configure a voice port, complete the following steps.

Enter Privileged Exec mode:
```
router> enable
```
Check the DSP voice channel activity with the following command:
```
router# show voice dsp
```
Enter Global Configuration mode:
```
router# configure terminal
```
Enter Voice Card Configuration mode. On the router, the slot must be 0:
```
router(config)# voice-card slot
```

Enter the CODEC type for the voice card:

router(config-voicecard)# CODEC {med | high}

This series of steps sets the CODEC compression technique, which is either high or medium complexity. High complexity can handle fewer calls per DSP. This is due to the higher CPU utilization required for high CODEC complexity operation. High and medium complexity CODECs:

High complexity Specifies two voice channels encoded in any of the following formats: G.711ulaw, G.711alaw, G.723.1 (r5.3), G.723.1 Annex A (r5.3), G.723.1 (r6.3), G.723.1 Annex A (r6.3), G.726 (r16), G.726 (r24), G.726 (r32), G.728, G.729, G.729 Annex B, and fax relay.
Medium (default) complexity Specifies four voice channels encoded in any of the following formats: G.711ulaw, G.711alaw, G.726 (r16), G.726 (r24), G.726 (r32), G.729 Annex A, G.729 Annex B with Annex A, and fax relay.

Configuring FXO or FXS Voice Ports

All these parameters have default settings, and FXS and FXO port default configuration values are adequate for most situations. Therefore, user intervention is rarely needed. The following settings are mandatory to any FXS/FXO port configuration:

Signal type
Call progress tone
Ring frequency
Ring number
Dial type (FXO only)
PLAR connection mode
Music threshold
Description
Voice activity detection (VAD)
Comfort noise

Follow these steps to complete a basic setup for all FXS/FXO voice ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global configuration mode:
```
router# configure terminal
```

Identify which port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port   (Cisco 175x/1760 and MC3810)

Select the appropriate signaling for the start of a call:

router(config-voiceport)# signal [loop-start|ground-start]

Select the appropriate country codes for call progression signaling. The default is northamerica:
```
router(config-voiceport)# cptone country-code
```
Configure the voice port connection mode type. If the connection will be to a PBX, use the tie-line option. If the connection will be for private line automatic ringdown (PLAR), use the plar option. If the connection will be for PLAR off-premises extension (OPX), use the plar-opx option.
```
router(config-voiceport)# connection {tie-line | plar | plar-opx} string
```
Assign the appropriate out-dialing dial type (FXO only):
```
router(config-voiceport# dial-type{dtmf | pulse}
```
Configure the frequency in Hertz of ringing for the system that is attached on a Cisco 1750, 2600, and 3600 series router (FXS only):
```
router(config-voiceport)# ring frequency [25| 50]
router(config-voiceport)# ring frequency [20| 30] 
```
Configure the maximum number of rings allowed before answering a call (FXO only):
```
router(config-voiceport)# ring number number
```
Specify an existing pattern for ring tone or define a new one (FXS only). Each pattern specifies a ring-pulse time and a ring-interval time:
```
router(config-voiceport)# ring cadence {[pattern01 | pattern02 … pattern12]
[define pulse interval]}
```
Specify the termination impedance, which needs to match the specifications of the PBX it is attaching to:
```
router(config-voiceport)# impedance [600c|600r|900c|complex1|complex2]
```
Configure the threshold in decibels for hold music:
```
router(config-voiceport)# music-threshold number
```
(Optional) Configure a text string to the configuration that describes the connection for this voice port:
```
router(config-voiceport)# description string
```
Configure background noise generation for the comfort of a user when there is no noise:
```
router(config-voiceport)# comfort-noise
```
(Optional) Enable voice activity detection:
```
router(config-voiceport)# vad
```

Configuring E&M Ports

E&M default settings are usually not sufficient to enable voice transmissions over IP. This is because E&M ports are designed to connect directly to a PBX and therefore must match the particular PBX's specifications. The following settings are mandatory to implement an E&M port:

Signal type
Call progress tone
Operation
Type
Impedance

The following commands complete a basic setup for all E&M voice ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify which port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port (Cisco 175x/1760 and MC3810)

Select the appropriate signaling for the interface:

router(config-voiceport)# signal [wink-start|immediate|delay-dial]

Select the appropriate country codes for call progression signaling. The default is us. The northamerica keyword is for the Cisco MC3810 multiservice concentrator for versions prior to Cisco IOS Release 12.0(4)T and for ISDN PRI:
```
router(config-voiceport)# cptone country code
```

Define cabling scheme operation:

router(config-voiceport)# operation [2-wire|4-wire]

Select the appropriate E&M interface type:

router(config-voiceport)# type [1|2|3|5]

Specify the termination impedance, which needs to match the specifications of the PBX the port is attaching to:
```
router(config-voiceport)# impedance [600c|600r|900c|complex1|complex2]
```

Some optional configurations for the E&M port are not required for operation. As with the FXS/FXO ports, the following configurations are used for optimization and usability:

Connection mode
Music threshold
Description
Comfort tone (VAD-activated only)

Use the following commands to adjust any of these optional configuration parameters for E&M ports:

Enter Privileged Exec mode:
```
router> enable
```
Enter Global Configuration mode:
```
router# configure terminal
```

Identify which port to configure on a 2600 and 3600 series router:

router(config)# voice-port nm-module/vic-module/port-number
router(config)# voice-port slot/port (Cisco 175x/1760 and MC3810)

Specify that the port configured for PLAR (which we discuss in more detail later in this chapter):
```
router(config-voiceport)# connection plar string
```

Define the threshold in decibels for hold music:

router(config-voiceport)# music-threshold number

Specify a description field for port:

router(config-voiceport)# description string

Set comfort noise to generate background noise for the user when there is no sound on the line:
```
router(config-voiceport)# comfort-noise
```

Quality of Service

noreply@blogger.com (JohnJenin) — Sun, 23 Aug 2009 10:18:00 +0000

Voice traffic and data traffic have different characteristics. Unlike data traffic, voice traffic occurs in real time and is delay-sensitive. Voice packets tend to be smaller than data packets. When voice and data networks are merged, it is important to deliver an acceptable QoS for the voice traffic.

Voice traffic must be prioritized to minimize delay and jitter. Delay is the amount of time between the original transmission of the voice information and the final processing by the receiving station. Jitter is the variation in the delay between successive voice packets. Packet loss due to network errors or congestion will impact jitter. QoS depends on the ability to control these two factors that impact voice quality.

QoS tools can be divided into three categories:

Classification Voice packets can be classified or marked with a specific priority to enhance QoS.
Queuing Use separate queues for voice and date to ensure consistency and QoS for voice.
Provisioning Circuits carrying voice traffic should be provisioned with enough bandwidth or capacity to minimize delay and jitter.

The increasing deployment of VoIP can be attributed to the improvements made in QoS. QoS is a set of ideas, procedures, practices, and numerous protocols that provide for reliable and efficient transportation across data networks.

What Is Quality of Service?

QoS is simply a set of tools to ensure that a minimum level of service will be provided to certain traffic. Many protocols and applications are not critically sensitive to network congestion. File Transfer Protocol (FTP), for example, has a rather large tolerance for network delay or bandwidth limitation.

Applications such as voice and video are particularly sensitive to network delay. If voice packets take too long to reach their destination, the resulting speech sounds choppy or distorted. QoS can be used to assure services to these applications. Critical business applications can also use QoS.

Applications for Quality of Service

When would a network engineer consider designing QoS into a network? Here are a few reasons to deploy QoS in a network topology:

To prioritize certain mission-critical applications in the network.
To maximize the use of the current network investment in infrastructure.
To provide better performance for delay-sensitive applications such as voice and video.
To respond to changes in network traffic flows.

When deploying QoS, analyze the traffic flowing through the bottleneck, determine the importance of each protocol and application, and determine a strategy to prioritize the access to the bandwidth. QoS allows control over bandwidth, latency, and jitter and minimizes packet loss within the network by prioritizing. Bandwidth is the measure of capacity on the network or a specific link. Latency is the delay of a packet traversing the network, and jitter is the change of latency over a given period of time.

Deploying certain types of QoS techniques can control these three parameters. QoS is not widely deployed within many networks. With the push for applications such as multicast, streaming multimedia, and VoIP, the need for QoS is more apparent, especially since these applications are susceptible to jitter and delay. Poor performance is immediately noticed by the end-user. However, QoS is not the magic solution to every congestion problem; it may very well be that upgrading the bandwidth of a congested link is the proper solution to the problem.

Levels of QoS

QoS can be divided into three different levels, also referred to as service models. These service models describe a set of end-to-end QoS capabilities. End-to-end QoS is the network's ability to provide a specific level of service to network traffic from one end of the network to the other. The three service levels are best-effort service, integrated service, and differentiated service.

Best-Effort Service

Best-effort service is when the network will make every possible attempt to deliver a packet to its destination. With best-effort service, there are no guarantees that the packet will ever reach its intended destination. An application can send data in any amount, whenever it needs to, without requesting permission or notifying the network.

Integrated Service

The integrated service model provides applications with a guaranteed level of service by negotiating network parameters end to end. Applications request the level of service necessary for them to operate properly and rely on the QoS mechanism to reserve the necessary network resources prior to the beginning of transmission. The application will not send traffic until it receives confirmation that the network can handle the load and provide the requested QoS end to end. To accomplish this task, the network uses a process called admission control.

Cisco IOS uses RSVP and intelligent queuing. RSVP is currently in the process of being standardized by the IETF in one of its working groups. Intelligent queuing includes technologies such as Weighted Fair Queuing and Weighted Random Early Detection (WRED).

RSVP works in conjunction with the routing protocols to determine the best path through the network that will provide the QoS required. RSVP routers create dynamic access lists to provide the QoS requested to ensure that packets are delivered at the prescribed minimum quality parameters.

Differentiated Service

Differentiated service includes a set of classification tools and queuing mechanisms to provide certain protocols or applications with a certain priority over other network traffic. Differentiated services rely on edge routers to perform the classification of the types of packets traversing a network. Network traffic can be classified by network address, protocols and ports, ingress interfaces, or whatever classification that can be accomplished through the use of a standard or extended access list.

Why QoS Is Essential in VOIP Networks

The challenge facing a converged infrastructure is to provide the efficiency of a packet-switched network with the reliability of a legacy network. This is the role that QoS fills.

QoS, through a variety of methods, gives reliability and availability to a converged infrastructure and still affords it the same benefits of efficient utilization of resources by providing the following:

Managed response times
Jitter (variation in delay) control
Prioritization of delay-sensitive traffic
Congestion management
Congestion avoidance
Support and enforcement of dedicated bandwidth requirements
Management and recovery of packet loss

With QoS, converged infrastructures can provide end users with a convenient, low-cost, scalable, and above all, reliable solution for the majority of their communications. Without QoS, a converged infrastructure would be comparable to anarchy, with little to no reliability, convenience, or scalability—to a level where a single FTP session could shut down your entire VoIP infrastructure.

Installing VNMs and VICs

noreply@blogger.com (JohnJenin) — Thu, 20 Aug 2009 07:31:00 +0000

The types of router chassis described in this section demonstrate how VNMs, VICs, and additional voice port adapters are installed on the various platforms. We chose a sampling of Cisco routers to structure our discussion, but the concepts and processes are similar for all Cisco routers, with a few minor adjustments.

E-1/T-1 Voice Connectivity

Digital E-1 and T-1 connectivity allows Cisco series routers and switches to provide E-1 or T-1 voice connectivity to PBXs or to a CO. T-1 voice connections are available for various routers and switches, including, but not limited to Cisco 1700, 2600, 3600, 3700, MC3810, 7200, 7500, AS5300, AS5800, and Catalyst 4000 and 6000 series equipment.

The 1700, 2600, 3600, 7200, and 7500 series routers are capable of VoFR and VoIP. The MC3810 (now end of sale) supports VoFR, VoATM, and VoIP. The AS5300 is able to perform VoIP, VoHDLC, or VoFR functions.

The 7200, 7500 series, and AS5300 series are primarily used as tandem switch points from T-1 tie lines to PBXs and the PSTN to the internal IP network. An example of the use of tandem switch points is receiving a voice call on one VoIP interface and switching it back out another VoIP interface to its final destination. The 1700, 2600, and 3600 routers series can perform this function because support for voice T-1/E-1 interfaces with up to two T-1/E-1 circuits per card has been added. The T-1/E-1 enhanced voice port adapter is used in the 7200 and 7500 series routers and can support up to two T-1s per card. The AS5300 series access switch uses the T-1 carrier card that can support up to four T-1s.

The 7200, 7500, and AS5850 can terminate T-1s for voice traffic into the WAN and forward the signals and transmissions to the 1700, 2600, 3600, and AS5300 series routers for complete processing. The 7200 Series offers a four- or six-slot configuration, with interfaces including ATM, Synchronous Optical Network Technologies (SONET), ISDN BRI, ISDN PRI, T-1, E-1, T3, and E3. Its multi-service interchange (MIX) allows the 7200 to support digital voice as well as gateway functionality through the use of two different trunk interfaces, the high-capacity and medium-capacity T-1/E-1 trunk interface cards. The primary difference between the two cards is that the high-capacity card includes an on-board DSP card for compression. The 7200 Series can support up to 120 voice calls, depending on the module configuration used. This router also supports analog voice applications through the use of voice interface cards (VICs).

1700 Series Router Configurations

The 1700 series modular access routers are designed for small- to medium-sized businesses. The 1700 family has several chassis for different applications, but the two that were designed specifically for voice applications are the 1751 and the 1760. These two modular chassis use the Cisco IOS along with various VICs to support analog and digital voice traffic over the IP network.

Cisco 1751 Modular Access Router

The Cisco 1751 is a standalone chassis that can support up to three voice interface slots. It comes in two models: a base model suited primarily for data, but with an easy upgrade path to voice, and a multiservice model (identified with a V) that includes all features for immediate integration of data and voice. Both models include three slots for data/voice interface cards as well as a 10/100 Ethernet port, a console port, and an auxiliary port. The 1700 series VICs are interchangeable with the Cisco 2600 and 3600 series routers.

The Cisco 1751 includes one PVDM-256K-4 (one DSP) that supports one analog VIC. If two analog VICs or one or more digital ISDN VICs are used, additional DSPs are required. The Cisco 1751 has two DSP slots to support additional voice channels. A PVDM is required to support VICs on the Cisco 1750 and 1760 routers. These two chassis require PVDMs to be placed on the motherboard, unlike the Cisco 2600, 3600, and 3700 routers, which have DSP support on the VNMs.

The Cisco 1760 Modular Access Router

The Cisco 1760 has four slots for VICs, and is available in two models. The base model is suited for data networking, but can be upgraded to support voice. The multi-service model (identified with a V) includes all features for immediate integration of data and voice. Both models include four slots for data/voice interface cards and a 10/100 Ethernet port.

The Cisco 1760 includes one PVDM-256K-4 (one DSP) that supports one analog VIC. If two analog VICs or one or more digital ISDN VICs are used, additional DSPs are required. The Cisco 1760 has two DSP slots to support additional voice channels.

3600 and 3700 Series Router Configurations

Cisco's 3600 and 3700 series routers come in a variety of base configurations that differ in the amount and/or type of standard network interfaces (RJ-45 ports, serial ports, and ISDN ports) that are available. The Cisco3600 and 3700 are designed primarily for traditional and power branch office solutions.

The 3600 series router comes in three varieties: the 3620, which has two network module slots; the 3640, which has four network module slots; and the 3660, which is equipped with six network module slots. The 3640 is end of sale as of this writing.

The 3700 series router comes in two varieties: the 3725, which has three integrated WIC slots and two network module slots, and the 3745, which has three integrated WIC slots and four network module slots. Currently, the built-in WICs do not support VICs.

Most Cisco 1700 VICs can be used for the 3600 and 3700 series except that a VNM is required in these higher-end routers. Installation of these VNMs is covered later in this chapter.

Note

For 3700 platforms, the minimum IOS release is IOS 12.2(8) T for all network modules and VICs.

7500 Series Router Configurations

The 7500 series high-end routers support voice, video, and data. The Cisco 7500 series includes the Cisco 7505, the Cisco 7507, and the Cisco 7513 with 5, 7, and 13 slots, respectively. Cisco 7500 adapters include the two-port T-1 and E-1 high-capacity enhanced digital voice port adapter, the two-port T-1 and E-1 moderate-capacity enhanced digital voice port adapter, and the one-port T-1 and E-1 enhanced digital voice port adapters.

AS5350 and 5850 Universal Gateway Configuration

The Cisco AS5350 and AS5850 universal gateways provide from 2 to 96 T-1s or E-1s to support data, voice, wireless, and fax services on any port. The AS5350 is only one rack unit high and supports 216 voice, dial, or universal ports. The AS5350 is mainly intended for ISPs and enterprises, whereas the Cisco AS5850 was designed for large service providers. The AS5850 is 14 rack units high and supports 2688 voice or universal ports. Both chassis support hot-swappable cards and fans to minimize service interruption. The AS5350 supports two-, four-, or eight-T-1/E-1 configurations; the AS5850 supports up to four 24-port T-1 cards for a total of 96 T-1s.

Note

The minimum IOS release for the Cisco AS5850 platform is IOS 12.2(1)XB for the 24-channel T-1 card.

Cisco VoIP Hardware and Software

noreply@blogger.com (JohnJenin) — Mon, 17 Aug 2009 09:25:00 +0000

Up to this point, this chapter has been focused on the underlying technologies and concepts that are integral to VoIP. We will now turn our attention to Cisco-specific information. Cisco offers a variety of hardware and software solutions for implementing VoIP. Its routers and switches can be adapted to support voice communications, usually with the addition of voice modules and software in many cases.

Voice Modules and Cards

Routers and switches use voice modules to transform and transport voice traffic across the IP network. They use Voice Interface Cards (VICs) to provide connectivity to telephone equipment. Voice Network Modules (VNMs) and VICs are configured using Cisco IOS VoIP commands. Digital signal processors are used in various Cisco voice-enabled routers in order to convert analog voice signals to digital for transmission across an IP network and to convert back to analog once the packet has arrived at the destination router. DSPs can be found as modules inserted onto the motherboard, as on the 1700 series routers, or as slots built onto a VNM that is placed in the router.

Voice Network Modules

VNMs convert analog voice into a digital form for transmission over the IP network. At least one VNM is needed to enable the router to handle voice traffic. VNMs come in several different models for the 2600/3600 series routers. Figure 1 shows several models of VNMs available for the 26XX and 36XX routers.

Figure 1: Voice Network Modules

Only VICs are supported in the carriers with a V in the name. The NM-1V is a one-slot VNM. You can install one VIC in the NM-1V to gain up to two voice ports. The NM-1V/2V does not support WAN interface cards (WICs). The NM-2V is a two-slot version of the VNM. You can install up to two VICs in the NM-2V, providing up to four voice ports. The NM-HDV high-density VNM. This network module consists of five slots, one for the voice WIC (VWIC) and four for the packet voice DSP modules (PVDM). You can install one VWIC in the NM-HDV, providing up to two voice ports. The VNMs are the housings for the actual voice interface cards that provide the necessary functionality and connectivity to achieve voice communications.

Voice Interface Cards

Voice Interface Cards (VICs) are inserted in the VNM to provide the necessary interface and support for the desired type of voice configuration (FXS, FXO, or E&M). Figure 2 shows several VICs to give you an idea of what is available; this is not an exhaustive list, as Cisco continues to expand in this area.

Figure 2: Voice Interface Cards

One thing we would caution you about is that physically and outwardly, there is no difference between the FXS and FXO connectors; it can be easy to plug a telephone into what you think is an FXS port, but is actually an FXO port. Ensure that you are using the proper port type by checking the color and labels before attempting to connect.

VIC-2E/M The two-port E&M module VIC-2E/M connects an IP network directly to a PBX system. It can be configured for special settings associated with tie-line ports on most PBXs. E&M ports are color-coded brown.
VIC-2FXS The two-port FXS module VIC-2FXS connects to endpoint equipment such as a telephone, keypad, or fax. These ports provide ringing voltage, dial tone, and other endpoint specific functionality. FXS ports are color-coded gray.
VIC-2FXO The two-port FXO module VIC-2FXO connects to a PBX or PSTN. FXO ports are color-coded pink. Other types of FXO cards for use outside North America are capable of providing switching and signaling techniques used in other geographic regions such as VIC-2FXO-EU for use in Europe.
VWIC-2MFT-T-1 The two-port VWIC multiflex trunk interface card is a two-port card that can be used for voice, data, and integrated voice/data applications. The multiflex VWIC can support data-only applications as a WAN interface on the Cisco 1700, 2600, or 3600. It can also integrate voice and data with the Drop and Insert multiplexer functionality and/or configured to support packetized voice (VoIP) when in the digital T-1/E-1 network module.
Two-Port ISDN BRI Card Two two-port ISDN BRI VICs are available for the Cisco 1700, 2600, and Cisco 3600 series routers. These cards are available as ISDN BRI S/T or NT interfaces for terminating to an ISDN network.
Four-Port Analog DID/FXS VICs Two direct inward dial interface cards are available. One card is a two-port RJ-11 that supports DID only. These cards are used for providing DID service to extensions on a PBX so that users may transparently dial directly to extensions.

Skinny Station Protocol

noreply@blogger.com (JohnJenin) — Sat, 15 Aug 2009 09:48:00 +0000

Skinny Station Protocol SSP is a Cisco proprietary communications protocol based on the industry standard Simple Gateway Control Protocol. Skinny Station Protocol enables communication between first generation IP telephone handsets/Gateways and CallManager servers. Products that support Skinny Station Protocol include the DT-24 and DE-30 gateways, the Catalyst 6000 8-Port T-1/E-1 voice service modules, as well as the Catalyst 6000 24 port FXS module. Skinny Station Protocol relies on the CallManager server to relay configuration and control information. It is built on TCP/IP and utilizes TCP ports 2000-2002.

Media Gateway Control Protocol

noreply@blogger.com (JohnJenin) — Thu, 13 Aug 2009 07:07:00 +0000

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

Session Initiation Protocol

noreply@blogger.com (JohnJenin) — Mon, 10 Aug 2009 09:03:00 +0000

SIP (RFC2543) is a simple signaling protocol for Internet conferencing and telephony. Based on Simple Mail Transfer Protocol (SMTP) and HyperText Transfer Protocol (HTTP), SIP was developed by the Internet Engineering Task Force's (IETF's) Multiparty Multimedia Session Control (MMUSIC) working group. SIP specifies procedures for telephony and multimedia conferencing over the Internet. SIP is an application-layer protocol independent of lower layer protocols (TCP, UDP, ATM, X.25).

SIP is based on a client/server architecture in which the client initiates the calls. By conforming to these existing text-based Internet standards (SMTP and HTTP), troubleshooting and network debugging are facilitated. The protocol can be read without decoding the binary ASN.1 payload required in non-text-based protocols, such as H.323. SIP is widely supported and is not dependent on a single vendor's equipment or implementation.

SIP is a newer protocol than H.323 and does not have maturity and industry support at this time. However, because of its simplicity, scalability, modularity, and ease with which it integrates with other applications, this protocol is attractive for use in packetized voice architectures. Some of the key features that SIP offers are:

Address resolution, name mapping, and call redirection
Dynamic discovery of endpoint media capabilities using the Session Description Protocol (SDP)
Dynamic discovery of endpoint availability
Session origination and management between host and endpoints

Session Initiation Protocol Components

The SIP system contains two components: user agents and network servers. A user agent (UA) is an endpoint, which makes and receives SIP calls.

User agent client (UAC) Initiates SIP requests.
User agent server (UAS) Receives the requests from the UAC and returns responses for the user.

SIP clients can include:

IP telephones (UACs or UASs)
Gateways to provide conferencing and translation

There are three kinds of SIP servers:

Proxy server Determines the server to which the request should be forwarded. Request can actually transit many SIP servers to its destination. Responses return in reverse order.
Redirect server Notifies the calling party of the actual location of destination.
Registrar server Provides registration services for UACs at their current locations. Often deployed with proxy and redirect servers.

Figure 1 illustrates the interaction between SIP components.

Figure 1: SIP Components

Session Initiation Protocol Messages

SIP works on a simple premise of client/server operation. Clients or endpoints are identified by unique addresses. These addresses come in a format very similar to that of an e-mail address: user@domain.com.

SIP addresses are URLs: user@host
User: name, telephone (E-164 address), number
Host: domain, numeric network (IP) address

The users or clients register with SIP servers to provide location contact information.

SIP uses messages for call connection and control. There are two types of SIP messages: requests and responses. SIP messages are defined as follows:

Invite Used to invite a user to a call. Header fields contain:
- Addresses of the caller and the person being called
- Subject of the call
- Call priority
- Call routing requests
- Caller preferences for the user location
- Desired features of the response
Bye Used to terminate a connection between two users.
Register Conveys location information to a SIP server, allowing a user to tell the server how to map an incoming address into an outgoing address that will reach the user.
ACK Confirms reliable message exchanges.
Cancel Cancels impending requests.
Options Solicits information about the capabilities of the end being called, such as the difference between a plain old telephone handset and a fully-featured multimedia phone.

H.323 Call Setup

noreply@blogger.com (JohnJenin) — Sat, 08 Aug 2009 13:16:00 +0000

After discovery, registration, and call placement are complete, the H.323 call moves into the call setup stage. At this stage, the gateways are communicating directly to set up the connection. An alternative is gatekeeper-routed call signaling, where all call setup messages traverse the gatekeeper. Figure 1 helps us conceptualize this process.

Figure 1: H.323 Call Setup

The call setup is based on the ITU-Q.931 (H.225 is a subset of Q.931), which provides a means to establish, maintain, and terminate network connections across an ISDN. This process comprises six distinct phases, as shown in Figure 1.

Gateway X sends an H.225 call-signaling setup message to Gateway Y to request a connection.
Gateway Y sends an H.225 message back to Gateway X, advising that it may proceed with the call.
Gateway Y sends an RAS message (ARQ) on the RAS channel to the gatekeeper to request permission to accept the call.
Gatekeeper confirms that the call can be accepted by sending a message (ACF) back to Gateway Y.
Gateway Y sends an H.225 message to Gateway X, alerting that the connection has been established.
Gateway Y sends an H.225 message to Gateway X, confirming call connection to establish the call.

Logical Channel Setup

After call setup, all communications travel over logical channels. The H.245 manages these logical channels. Multiple logical channels of varying types (video, audio, and data) are allowed for a single call.

The H.245 Logical Channel Signaling Entity (LCSE) opens a logical channel for each media stream. Channels may be unidirectional or bi-directional. Figure 2 helps us visualize how the H.323 utilizes virtual channels.

Figure 2: Media Channel Setup

The H.245 control channel is established between Gateway X and Gateway Y. Gateway X uses H.245 to identify its capabilities via a Terminal Capability Set (TCS) message to Gateway Y. The media channel setup flow is as follows:

Gateway X exchanges its capabilities with Gateway Y by sending an H.245 TCS message.
Gateway Y acknowledges Gateway X's capabilities by sending an H.245 TCS Acknowledge message.
Gateway Y exchanges its capabilities with Gateway X by sending an H.245 TCS message.
Gateway X acknowledges Gateway Y's capabilities by sending an H.245 TCS Acknowledge message.
Gateway X opens a media channel with Gateway Y by sending an H.245 Open Logical Channel (OLC) message and includes the transport address of the RTCP channel.
Gateway Y acknowledges the establishment of the logical channel with Gateway X by sending an H.245 OLC Acknowledge message, including:
- RTP transport addresses (used to send the RTP media stream) allocated by Gateway Y
- RTCP address previously received from Gateway X
Gateway Y opens a media channel with Gateway X by sending an H.245 OLC message and includes the transport address of the RTCP channel.
Gateway X acknowledges the establishment of the logical channel with Gateway Y by sending an H.245 OLC Acknowledge message and includes:
- RTP transport addresses (used to send the RTP media stream) allocated by Gateway X
- RTCP address previously received from Gateway Y

Figure 3 highlights this process:

Figure 3: Media Channel Setup Call Flow

Media Stream and Media Control Flows

RTP media streams are transported over UDP ports 16384 through 16384 + 4x (where x is the number of voice ports on the gateways). For example, a Cisco 3620 router with four E&M ports would use UDP ports 16384–16400 for RTP flows.

RTCP manages media streams in the H.323 call flow by supporting QoS feedback from receivers. The source may use this information to adapt encoding or buffering schemes. RTCP uses a dedicated logical channel for each RTP media stream. Figure 4 illustrates the steps in this stage of the H.323 call flow.

In the example shown in Figure 9.34, four actions are occurring:

Gateway X sends the RTP encapsulated media stream to Gateway Y.
Gateway Y sends the RTP encapsulated media stream back to Gateway X.
Gateway X sends the RTCP messages to Gateway Y.
Gateway Y sends the RTCP messages back to Gateway X.

Endpoints may seek changes in the amount of bandwidth initially requested and confirmed. The gatekeeper must be asked for bandwidth increases or decreases. Endpoints must comply with gatekeeper responses and requests. The bandwidth change flow is diagramed in Figure 5. This process consists of six stages:

Figure 5: Bandwidth Change Request.

The initiating gateway sends a bandwidth request (BRQ) to the gatekeeper to request the desired bandwidth.
The gatekeeper responds with a bandwidth confirmation (BCF) message for the requested bandwidth.
A logical channel is established between the two gateways with the specified bandwidth.
A BRQ is sent from the remote router to the gatekeeper to change the bandwidth of the connection.
The gatekeeper responds to the gateway with a BCF to confirm the new bandwidth.
The logical channel is re-established with the new bandwidth.

Call Termination

Call termination stops the media streams and closes the logical channels, and may be requested by any endpoint or gatekeeper. It ends the H.245 session, releases H.225/Q.931 connections, and provides disconnect confirmation to the gatekeeper via RAS. Figure 6 shows call termination flow and is described as follows:

Figure 6: Call Termination (H.245/H.225/Q.931/RAS)

Gateway Y initiates call termination by sending an H.245 End Session Command (ESC) message to Gateway X.
Gateway X releases the call endpoint and confirms with an H.245 ESC message to Gateway Y.
Gateway Y completes the call release by sending an H.245 Release Complete message to Gateway X.
Gateway X and Gateway Y disengage with the gatekeeper by sending a RAS DRQ message.
Gatekeeper disengages and confirms by sending DCF messages to both Gateway X and Gateway Y.

H.323 Endpoint-to-Endpoint Signaling

Assuming that endpoints (clients) know each other's IP addresses, the H.323 signaling is shown in Figure 7.

Figure 8: H.323 Endpoint-to-Endpoint Signaling

H.323 Discovery and Registration | Cisco VOIP

noreply@blogger.com (JohnJenin) — Thu, 06 Aug 2009 08:10:00 +0000

The five stages of an H.323 call and details of each of these connections are listed.

Discovery and registration
Call setup
Call-signaling flows
Media stream and media control flows
Call termination

A lot happens within each of these stages; from the time the call is requested to the time it is terminated.

Device Discovery and Registration

The gatekeeper initiates a "discovery" process to determine the gatekeeper with which the endpoint must communicate, as shown in Figure 1. This discovery can be either a statically configured address or through multicast traffic. Once this is determined, the endpoint or gateway registers with the discovered gatekeeper.

Figure 1: H.323 Gatekeeper Call Control/Signaling: Discovery and Registration

Registration is used by the endpoints to identify a zone with which they can be associated (a zone is a collection of H.323 components managed by a single gatekeeper). H.323 can then inform the gatekeeper of the zones' transport address and alias address.

In Figure 1:

A H.323 gateway (or terminal) sends a request to register (RRQ) message using H.225 RAS on the RAS channel to the gatekeeper.
The gatekeeper confirms or denies the registration by sending a registration confirmation (RCF) or a "Reject registration" message back to the gateway.

Intra-zone Call Placement

Once the registration and discovery process is complete, we can place a call. Figure 2 shows Gateway X placing a intra-zone call to a terminal connected to Gateway Y, Gateway X sends an admission request (ARQ) message to the gatekeeper requesting permission to place a call to a phone number serviced by Gateway Y.

Figure 2: H.323 Gatekeeper Call Control/Signaling: Call Placement (Intra-zone)

In Figure 2:

Gateway X sends an ARQ message using H.225 RAS to the gatekeeper.
Gatekeeper requests direct call signaling by sending an admission confirmation (ACF) to Gateway X.
H.323 call setup is initiated.

Inter-zone Call Placement

The process of placing an inter-zone call is somewhat more complicated and resource–intensive, as the network is larger and divided into multiple zones. In Figure 3, Gatekeeper A controls Zone A, and Gatekeeper B controls Zone B. Gateway X (or Terminal X) is registered with Gatekeeper A, and Gateway Y is registered with Gatekeeper B.

Figure 3: H.323 Gatekeeper Call Control/Signaling: Call Placement (Inter-zone)

To place a call to Gateway Y terminal, Gateway X first sends an ARQ message to the gatekeeper requesting permission to make the call. Since Gateway Y is not registered with the gatekeeper in Zone A, we assume that the gateways (terminals) are already registered.

Figure 3 shows five distinct phases in an inter-zone call placement.

ARQ Gateway X requests a connection to Gateway Y from its local gatekeeper.
Location request (LRQ) Local gatekeeper for Gateway X does not know the IP address of Gateway Y and is requesting the address from Gateway Y's local gatekeeper.
Location confirm (LCF) Gateway Y's local gatekeeper responds to Gateway X's local gatekeeper with the IP address of Gateway Y.
ACF The local gatekeeper responds to Gateway X's request and provides the remote IP address of Gateway Y.
Call established The H.323 call is established between Gateway X and Gateway Y.

Cisco IP Telephony Applications

noreply@blogger.com (JohnJenin) — Mon, 27 Jul 2009 13:20:00 +0000

Cisco has developed software solutions to enhance their IP telephony solutions. IP telephony applications allow Cisco to augment their IP telephony hardware with features and services to provide an even more viable solution.

Cisco Web Attendant

Cisco WebAttendant is Windows Web-based TAPI software that allows the user to receive and dispatch calls from any IP telephone on the network. WebAttendant allows the IP phone to interface directly with the CallManager to direct calls and to monitor the status of lines, much like a traditional receptionist console. WebAttendant offers many of the same features of traditional PBX systems such as hunt groups and multiple attendant consoles.

WebAttendant is included in the basic CallManager package. It can scale to meet the size of almost any IP telephony infrastructure. A single WebAttendant console can monitor up to 26 calls at a time. A single CallManager cluster utilizing WebAttendant can support up 32 hunt groups with 16 members per hunt group. Also, a cluster can support up to 96 WebAttendant consoles, which means support for up to 512 (96 consoles x 26 calls) calls at one time.

Internet Communications Software

Internet Communications Software (ICS) is a suite of five tools for service and application providers to further gain the benefits of IP telephony.

Network Applications Manager (NAM) A management console that enables utilization of Automatic Call Distribution (ACD), Intelligent Contact Mangement (ICM), CIS, and IP Contact Center (IPCC).
Automatic Call Distribution Part of NAM, it reroute calls to different customers serviced via the same CO.
Cisco IP Contact Center Allows call centers using IP telephony to receive regular POTS calls as well as IP telephony calls.
Intelligent Contact Management Directs and relays customer contact information between resources such as Web, voice, and e-mail.
Customer Interaction Suite Allows corporations and service providers to interact with their customers on the Internet or network in real-time. Four components: Cisco Media Manager, Cisco Media Blender, Cisco E-Mail Manager, and Cisco Collaboration Server: