VOIP. Configuring Cisco Voice over IP

Table of Contents Configuring Cisco Voice Over IP Copyright 2000 by Syngress Media, all rights reserved Table of Conte...

71 downloads 1298 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Table of Contents

Configuring Cisco Voice Over IP Copyright 2000 by Syngress Media, all rights reserved

Table of Contents CHAPTER 1: Cisco Voice Solutions and Business Justification Introduction to Voice Over IP Concepts General Overview of Voice Technologies Juicy Possibilities A Little Dreaming Back to Reality What Can you do Now? Basic Toll-Bypass Designs Tie Line Replacement Where The Money Is What About Data Combining Networks

file:///H:/edonkey/docs/programming/SYNGRESS_Configuring_Cisco_Voice_OverIP.JanezSlovenec/setup.htm (1 of 14) [13/12/02 18:18:19]

Table of Contents

Using Frame Relay for Toll-Bypass Using Point-to-Point T1 For Toll-Bypass Looking at Return On Investment Reviewing Current Expenses Designing the Solution Building the Return On Investmentand Payback Period The Network PBX Replacing the Traditional PBX Call Routing Dial Plan Interactive Voice Response Unified Messaging and the Amteva System Savings Analysis Example Advanced Features and Integration Possibilities TAPI Integration Web Click-to-Talk Transfer, Forward and Conference Capabilities Faxing Call Detail Recording and Data-Mining Voice Over Frame Relay Where To Use It?


Table of Contents

Growth Curve Of Frame Relay When Does VoFR Make More Sense Than VoIP? Toll-Bypass Opportunities Voice Over ATM Where To Use It? QOS vs. Availability Summary FAQs

CHAPTER 2: Introduction to Telephony Introduction Analog Signals and Systems Basic System Operation Dial Pulse Signaling Dual-Tone Multi-Frequency Analog Network Components Loop and Ground Start Voice Encoding: Standards and Techniques Waveform Encoding Source Encoding Analog Signal Composition Cabling


Table of Contents

Analog Signaling Analog-To-Digital Conversion Modems Summary FAQs

CHAPTER 3: IOS Voice Protocols Overview of IP Networks Voice over IP Signaling, Addressing, and Routing H.323 Family of Standards Introduction to H.323 H.323 Components H.323 Terminals (Endpoints) H.323 Gateways H.323 Gatekeepers Multipoint Control Units (MCUs) H.323 Protocol Stack H.323 Call Stages H.323 Discovery and Registration Call Placement (Intra-Zone) Call Placement (Inter-Zone) H.323 Call Setup


Table of Contents

Logical Channel Setup Media Stream and Media Control Flows Call Termination H.323 Endpoint-to-Endpoint Signaling Session Initiation Protocol (SIP) Key Benefits of Session Initiation Protocol Session Initiation Protocol Components Session Initiation Protocol Messages Media Gateway Control Point (MGCP) Summary FAQs

CHAPTER 4: Basic Voice Over IP Configuration Different Types of Voice ports Foreign Exchange Station Interface (FXS) Foreign Exchange Office Interface (FXO) Ear and Mouth Interface (E&M) T1 Voice Connectivity (2600/3600/7200/AS5300) Voice Network Modules and Voice port Modules Voice Network Modules (VNMs) Different Types of Voice Interface Cards (VIC) VIC-2E/M


Table of Contents

VIC-2FXS VIC-2FXO Connecting VNMs and VICs to the Router 2600 Series Router Configurations 3600 Series Router Configurations Voice Port Cabling and Configuration Voice Numbering on the 2600 and 3600 series LED Status Configuring Voice Ports on the 2600/3600 Configuring FXO or FXS Voice Ports Configuring E&M Voice Ports Voice Port Tuning Commands Concepts of Delay and Echo Fine Tuning FXS/FXO Ports Fine Tuning of E&M Ports The Connection Command Direct Voice Trunking vs. Dial – Digit Interpretation Standard Dialing Analysis—Digit Interpretation Supervisory Disconnect Wink Start Signaling vs. Immediate Start Signaling Dial Plans and Dial Peers


Table of Contents

Dial Peers Call Legs POTS vs. Voice Network Dial Peers Creating and Implementing Dial Plans Number Expansion Basic Syntax of the Dial-Peer Command for POTS Basic Syntax of the Dial-Peer Command for VoIP Direct Inward Dialing (DID) VoIP QOS over Leased Lines IP Precedence Data Network Queuing Algorithms Queuing on Voice/Data Networks and Real-Time Transmissions Class Based Weighted-Fair Queuing (CBWFQ) IP RTP Priority Resource Reservation Protocol (RSVP) RSVP Configuration IP Precedence vs. RSVP Multilink PPP (MLPPP) and Interleaving Compressed Real-Time Protocol (CRTP) CODEC and Voice Activity Detection (VAD) VoIP QoS over Frame Relay


Table of Contents

Configuration of FRF.12 Fragmentation Frame Relay Traffic Shaping VoIP Troubleshooting Case Study 1 Case Study 2 Summary FAQs

CHAPTER 5: H.323 Configuration: Gateways and Gatekeepers Introduction H.323 Version 1 vs. Version 2 Lightweight Registration Improved Gateway Selection Processes H.323 RAS and Gatekeepers Gatekeepers Zone Management Gatekeeper Functionality on Cisco Platforms Configuration of a Cisco Gatekeeper Configuring an H.322 Gatekeeper on Cisco Platforms Directory Gatekeepers and Location Requests Gateways RAS: Registration, Admissions, and Status


Table of Contents

Gateway Discovery Configuring an H.322 Gateway on Cisco Platforms Configure Gateway Interface Parameters AAA and Call Detail Records Acct-Session-Id Field NTP Time Format Interactive Voice Response IVR Scripts Fax Hop On/Off Procedure for Creating Audio (AU) Files Store-and-Forward Fax On-Ramp and Off-Ramp Gateway Concepts Configuration of Store-and-Forward Faxing Redialer vs. Direct Inward Dialing Configuring the On-Ramp Gateway Configuring the Called Subscriber Number Configuring the Sending Mail Transport Agent Configuring the On-Ramp POTS Dial Peer Configuring the On-Ramp MMoIP Dial Peer Configuring the Off-Ramp Gateway Configuring the Transmitted Subscriber Number


Table of Contents

Configuring the FAX Transmission Speed Configuring the Receiving Mail Transport Agent Configuring the Off-Ramp POTS Dial Peer Configuring the Faxed Header Information Configuring the Fax Cover Page Information Advanced Troubleshooting Show Gateway debug ras debug h225 Show Call Application Voice Summary FAQs

CHAPTER 6: AVVID (Architecture for Voice, Video and Integrated Data) Introduction Introduction AVVID IP Phones Phone Features Cisco Call Manager Call Manager Features Access Devices Analog Gateway Analog Station file:///H:/edonkey/docs/programming/SYNGRESS_Con...uring_Cisco_Voice_OverIP.JanezSlovenec/setup.htm (10 of 14) [13/12/02 18:18:19]

Table of Contents

Digital Gateway AVVID Equipment Initialization and Registration Phone Initialization and Configuration How AVVID Works Placing an IP-to-IP Phone Call Placing an IP-to-PSTN Call Placing an IP-to-IP Call over the Wide Area Network Plug-in Applications Directory Services Virtual Phone CiscoValet Manual Attendant Conference Bridge Media Termination Point SUMI TAPI Interface Web Help The Future is Near… Summary

APPENDIX A: IPv6 Addressing Introduction

file:///H:/edonkey/docs/programming/SYNGRESS_Con...uring_Cisco_Voice_OverIP.JanezSlovenec/setup.htm (11 of 14) [13/12/02 18:18:19]

Table of Contents

IPv6 Addressing Basics IPv6 Addressing Scheme Characteristics Version Traffic Class Flow Label Payload Length Next Header Hop-by-Hop Options Header Destination Options Header I Routing Header Fragment Header Authentication Header Encrypted Security Payload Header Destination Options Header II Hop Limit Source Address Destination Address More Bits! A More Flexible Hierarchical Organization of Addresses FP: Format Prefix TLA ID


Table of Contents

RES NLA ID SLA ID Interface ID Minimizing the Size of Routing Tables Global Addresses for the Internet and Local Addresses for Intranet IPv6 Benefits Increased IP Address Size Increased Addressing Hierarchy Support Simplified Host Addressing Simpler Autoconfiguration of Addresses Improved Scalability of Multicast Routing The Anycast Address The Need for Further Development The Multihoming Problem The 6Bone Summary FAQ

APPENDIX B: The IPv6 Header Introduction Expanded Addressing


Table of Contents

Simplified Header Improved Support for Extensionand Option Flow and Flow Labeling Authentication and Privacy IPv6 Header IPv4 Header Extension Headers Hop-by-Hop Option Header Routing Header Fragment Header Authentication Header Encapsulating Security Payload Destination Options Header Upper-Layer Protocol Issues Summary FAQs References


Chapter 1: Cisco Voice Solutions and Business Justification

Return to Table of Contents

Chapter 1 Cisco Voice Solutions and Business Justification Introduction to Voice Over IP Concepts General Overview of Voice Technologies Juicy Possibilities A Little Dreaming Back to Reality What can you do now? Basic Toll-Bypass Designs Tie Line Replacement Where The Money Is What About Data Combining Networks Using Frame relay for Toll-Bypass Using Point-to-Point T1 For Toll-Bypass Looking at Return On Investment Reviewing Current Expenses Designing the solution Building the Return On Investment and Payback Period The Network PBX Replacing the traditional PBX Call routing Dial Plan Interactive Voice Response Unified Messaging and the Amteva System Savings Analysis Example Advanced Features and Integration Possibilities TAPI Integration Web Click-to-Talk Transfer, Forward and Conference Capabilities Faxing Call Detail Recording and Data-Mining Voice Over Frame Relay Where To Use It Growth Curve Of Frame Relay

file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (1 of 33) [13/12/02 18:18:28]


When Does VoFR Make More Sense Than VoIP? Toll-Bypass Opportunities Voice Over ATM Where To Use It QOS vs. Availability Summary FAQs

Introduction to Voice Over IP Concepts Welcome to the brave new world of packetized voice! Although the idea of packetized voice may not be new, we are finally getting the tools to make it happen. This text will provide you with a thorough understanding of Cisco's current voice solutions, with an emphasis on current! The VoIP industry is a rapidly evolving one, perhaps even faster than the Internet. Keep this guide as a reference for voice integration possibilities but always keep abreast of the latest technologies. What is hot today is commonplace tomorrow.The objectives for this chapter are: •

Establish the basic differences between circuit switched and packet switched networks.

•

Build a needs and cost justification for toll-bypass solutions.

•

Explore the opportunities for replacing or enhancing the traditional PBX with a networked PBX.

•

Review software integration possibilities such as TAPI integration.

•

Understand the alternatives to VoIP such as VoFR and VoATM

Scattered throughout this chapter are several diagrams of network design concepts. Later in this book we will delve into much greater detail regarding specific equipment and configuration issues. This first chapter will focus on the opportunities that arise from moving to a packetized voice architecture. Along with management and maintenance enhancements we will also look at the allimportant dollar. Most companies have spent exorbitant amounts of money to install and maintain their PBXs. Packetizing voice allows for tremendous cost savings now and in the future. As more standards are ratified, the cost of setting up a VoIP network continues to drop. This is quite a different model from the traditional PBX cost trends of the last few decades. We will explore how to go about building a Return On Investment (ROI) proposal that in most cases will justify a conversion to packetized voice. Although this is a VoIP manual there is still room in the network for Voice over Frame Relay (VoFR) and Voice over ATM (VoATM). In some cases, these two alternatives may be the desired combination. This is just the tip of the iceberg. As VoIP becomes more widespread and ubiquitous we will begin to see applications that we can't even imagine yet. Moving voice from a closed proprietary system to an open standards-based architecture will revolutionize the phone industry and the world as much as the Internet has.

General Overview of Voice Technologies There is a difference between dreaming about something and actually seeing it happen. That difference is the passage of time. What we dream now creates the inspiration for future discoveries.



Today’s reality is the inspiration for our dreams. As we learn about new technologies we must consider where we are today in a realistic sense but also keep thinking about where we will be tomorrow.

Juicy Possibilities For this revolution to occur we need people to come up with ideas that capitalize on new technologies. Consider the following scenario. A Little Dreaming Imagine a sunny day sometime in the near future. You wake up, roll out of bed, get dressed and stroll into the kitchen for some coffee. While you sit there sipping your coffee you see the "Messages" icon blinking on your kitchen Internet terminal so you reach over and tap it. Up pops a list of all of your emails, voice mails and daily news info. You see at the top of the list a voice mail from mom who happens to live on the other side of the world. It looks like the message came in around 1AM. Apparently mom didn't realize that all calls after 10PM automatically get diverted to voice mail. You tap on her message and hear her carry on for 15 minutes about the weather as you silently curse the day "long distance" calls became a thing of the past. But that's okay because you want to talk to her about visiting anyway. So you tap "Reply" and you immediately hear a ringing tone from your kitchen terminal. Mom picks up on the other end and gives you a hard time about interrupting dinner. You talk to her for another hour while her dinner gets cold. You're not concerned though because there's no extra charge on your network bill no matter how long you talk. You also left your house 45 minutes ago! While you were talking to mom you grabbed your mobile phone on the way out. Once it notified your service that it was the primary phone your call to mom was rerouted to it. So you hopped into your car and popped the phone into the cradle to talk to your mom on the speakerphone. Halfway to the office your phone service, by using GPS to track you, goes into business mode. Mom keeps talking but now all of your business calls are being forwarded to you instead of going into your voice mail. You hear a chime and see that your boss is calling so you need answer. You tell mom to hang on a second and pick up your boss’s call. He just wanted to remind you of the 9AM meeting. You arrive at the office, grab your mobile phone and wrap up with mom as your walking in. At your desk your PC phone senses the proximity of your mobile phone and takes over as your primary phone. For the rest of the day, as you move about the office, your mobile phone and your PC phone continue to trade roles. This is just the tip of the iceberg when it comes to the possibilities that VoIP presents when combined with other transport and service options. As wireless technology becomes cheaper and more mainstream these ideas are bound to be implemented. By studying VoIP now and understanding the concepts, you place yourself in an ideal position to benefit from the next huge shift of the information age. VoIP may not appear as exciting as the Internet is to the public, but it will be the driving force behind more technology jobs than even the Internet has provided. This may seem like a bold statement but think about how many people are on the Internet compared to how many people have phones. Everyone has a phone! Back to Reality Hopefully you're excited about these new possibilities, but let's take a step back and look at what makes this better than the current voice network and why it is easy to implement these new ideas. We will start by looking at how the current circuit switched voice network operates.



Figure 1.1 Simple circuit switched call. When you place a call, the circuit switched network essentially dedicates a 64 Kbps circuit for the duration of your call. This means if you are calling from New York to Los Angeles, a dedicated circuit is set up from one end to the other (see Figure 1.1). When you talk, it is 64 Kbps, and when you are silent it is still 64 Kbps. No matter what you do, you are tying up 64 Kbps as long as you’re on the line. If a switch goes down or someone cuts a fiber your call ends. The phone companies have gone a long way towards providing services such as call waiting, call back and voice mail systems. But if you ask how to integrate those services into your home or business network, you can’t. Those services are stuck on their switches. Here's where VoIP comes in. VoIP provides open standards. If you wanted to you could write your own application for handling voice calls in a particular way. This would not be possible on your home phone or on a PBX at work. The traditional phone systems are closed systems which do not allow for easy programming of third party applications. Open standards reduce costs. Ask any CFO what their company spends on the PBX and be prepared for the groaning. PBXs are the gifts that keep taking with high maintenance fees, lack of interoperability, expensive adds/moves and closed APIs (Application Programming Interface). Do you have a great idea for an application that you would like to see in a call center? With VoIP it is easier and cheaper. You have access to documentation on open standards so you can write code safely. On a PBX and you're looking at steep fees for becoming an application partner as well as having to code to their proprietary APIs (i.e. no portability for your application, you're stuck with that PBX). Do you want to move the accounting department to a new floor? How about a new building? How about a new city? With VoIP you simply move the phones and watch as they join the network and register with the Call Manager. All of the voice mail services as well as phone templates stay in a central location, resulting in zero effort moves. The same activities with a PBX would result in a substantial amount of time removing and then adding users to the new location. Voice mail service would also have to be migrated. Once again, with VoIP, moves are completely transparent. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (4 of 33) [13/12/02 18:18:28]


Figure 1.2 Simple VoIP call. What can you do now? You're probably thinking "This is incredible! Where do I buy this?" Right now much of it is in an evolving stage, including the Cisco Call Manager. It is possible to replace the PBX right now. In fact, Cisco is in the process of switching several of their locations to multi-service networks utilizing Cisco Call Manager as well as IP phones. Within six months a sizable amount will be very possible in a corporate environment. The pace that this technology is moving rivals the Internet industry! What can you implement right now? Toll-bypass is a good way to start. Later in this chapter we will look at the basic toll-bypass setup and discuss how it can be an effective introduction to VoIP, and how attractive it is from a Return On Investment (ROI) standpoint. Ultimately though, toll-bypass is a foot in the door. The real excitement is in replacing the PBX. We will see how Cisco Call Manager can help with this as well as with using the Amteva unified messaging system to enhance the voice mail system.

Basic Toll-Bypass Designs One of the most attractive ways to get into a packetized voice solution is the lowering of long distance phone costs. Lets explore the different methods of doing this.

Tie Line Replacement Many multi-site businesses have a PBX at each office. Quite often there is a connection between these PBXs in order to allow people in both locations to use intercom dialing. These tie lines require dedicated connections that must always be available. Even though there may be no one speaking the lines are still unavailable for any other use. This situation presents an opportunity for packetizing voice. Where The Money Is Until now companies have had two choices for linking voice calls among offices. The first option was to simply call long distance. Discounted calling plans from the long distance carriers can reduce



this cost. Regardless, it can still be a high expense if there is any substantial amount of traffic between offices. Not only does the business incur an expense for every long distance call but it also gets charged for every call that goes to the Public Switched Telephone Network (PSTN). Unlike your home phone , businesses must pay for every call they make. Obviously this can add up quickly if the call volume increases. Later in this section we will look at some sample ROIs.

Figure 1.3 Example of tie lines between multiple offices. The other option was to set up a dedicated connection among PBX sites. This is typically done with a tie line. A tie line is used for signaling among PBXs as well as transferring calls between them. Many companies already use this method. Tie lines are a fairly simple method for avoiding the percall charges you run into when using the PSTN or long distance carriers. They allow you to make as many calls as you like, provided the capacity is available on the tie line, without incurring any added expenses. Tie lines are typically implemented over T1s. If the T1 is local the cost is probably going to be fairly reasonable. If the T1 has to go through a long distance carrier or Inter-Exchange Carrier (IXC) the costs can be quite high. In addition, every two offices that you want to have connected must have a tie line running between them (see Figure 1.3). There may be ways around this if you have PBXs that are capable of handling advanced dial-plans. In Figure 1.3 you can see that calls between Baltimore and Los Angeles could pass through Denver but you would be tying up two circuits for every coast-to-coast call. The alternative is to run a dedicated tie line between Baltimore and Los Angeles. What About Data At some point you might hear the term “Voice rides for free.” Well nothing rides for free but it sure can ride cheap. When someone says this, they are referring to the fact that many companies already have data lines running in parallel to the voice lines. As shown in Figure 1.4, this national network also has T1s supporting data running between them. Now we are paying for two very expensive networks.



Figure 1.4 National network with separate voice and data networks running between all offices. The data network can support many functions such as email, Internet and file sharing. With proper monitoring any Network Administrator should know what the load is on these data circuits. Depending on the applications there is a good chance that there is room to spare. This isn’t always the case so good monitoring and tracking tools will help make the case for packetized voice. Combining Networks Imagine the cost savings from turning off the tie lines. Even if data circuits need to be increased, the incremental cost of the bandwidth increase is going to be less than installing an entirely separate circuit. This would also allow calls to be made directly from Baltimore to Los Angeles through Denver (Figure 1.5). After all, at this point we are only dealing with data. Let’s look at some of the different ways we can do this.

Figure 1.5 A combined network.



Using Frame relay for Toll-Bypass Voice over Frame Relay (VoFR) has actually been around for several years, so the standards are more mature and the interoperability is a little more stable then VoIP. For simple toll-bypass networks VoFR can be a very attractive alternative. VoFR allows voice to be compressed and transferred across a frame relay Permanent Virtual Circuit (PVC). Take a look at our example network (Figure 1.5). For the traffic between Baltimore and Denver we have a 768 Kbps Committed Information Rate (CIR) frame relay circuit. As you will see in Chapter 6, Configuring Voice over Frame Relay, choosing the proper CIR on frame circuits is of critical importance. At each site you have a data network as well as a PBX which already has a digital T1 port for implementing the tie line. In our example we might use a Cisco 3810 or 2600/3600 series router at each location. All of these routers support VoFR and can interoperate with each other. The 3810 has the capability of interfacing directly with the PBX via the digital T1 card that is available for it. The 3810 can also connect directly to the frame circuit through either the Multi-Flex Trunk (MFT) or through a DSU attached to its serial interface. At this point there are a number of options available. With our example network you will most likely forward calls to the far side PBX. In this situation you will have the PBXs manage call routing while the 3810s compress and transfer the calls. Using the compression algorithm G729A you can squeeze voice calls down to about 8 Kbps. With overhead they end up taking up about 10.13 Kbps. Although this is not a lot of bandwidth it can add up if you have multiple calls active at the same time. Furthermore, with the 768 Kbps circuit and G729A encoding you could theoretically support 70 concurrent calls. There are a few problems with that number; first of all the 3810 can support encoding on a maximum of 24 calls at any one time. This is because each compressed call utilizes half of a Digital Signal Processor (DSP). Also, if you are connecting the 3810 to a PBX it is likely that the connection will be with a digital T1 thereby limiting you to 24 channels. The realistic number of calls that could potentially be supported is 24. This is just as well because the typical deployment will require saving some bandwidth for data. Most typical installations will require that data run over the same PVC as the voice traffic. If the maximum number of voice calls are active they will take up 24 times 10.8 Kbps which is approximately 260 Kbps. On our example network we have a 768 Kbps CIR PVC. Frame Relay works on the principle of having a CIR that is guaranteed and a port speed that you can burst to. Different Frame Relay providers are different when it comes to the relationship between the CIR and port speed. The important thing to remember is that any frames that stray into the burst area are tagged and could be dropped. That leaves 508 Kbps of bandwidth before we exceed the committed rate. What happens if the data traffic starts pushing the bandwidth into the burst area? The voice traffic will mix in with the data traffic and it could be tagged for discard. Imagine how a conversation might sound if every other second was dropped. Quality Of Service (QOS) issues are of critical importance when it comes to packetizing voice. Implementing QOS on VoFR is easier than with VoIP. However, if it is not done right you could end up with a very expensive project as everyone starts calling long distance just to have a coherent conversation. Using Point-to-Point T1 For Toll-Bypass If the implementation calls for using a point-to-point T1 then there are two choices. The first option would be to use Voice over HDLC (VoHDLC). HDLC is Cisco’s proprietary layer two protocol typically used for point-to-point T1s. VoHDLC is similar to VoFR in that it allows for multiple calls to be placed over the T1 using compression. Since is Cisco proprietary there are no standards. In the file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (8 of 33) [13/12/02 18:18:28]


instance of tie line replacement using a T1 and Cisco equipment it can be an attractive alternative. One of the major drawbacks to VoHDLC is that it has very limited scalability. It is designed strictly to be used for a point-to-point connection between Cisco routers (Figure 1.6). Chapter 3 will cover this in greater detail.

Figure 1.6 VoHDLC configuration. The second option is to use VoIP, because where VoHDLC and VoFR fail is in their scalability, resulting in encoding and then decoding voice calls multiple times. VoIP can scale with the network; anywhere IP can reach is a possible destination for a voice call. Obviously there are serious QOS issues. In theory and in practice VoIP will work across the Internet, only at best it will sound like you are talking on a CB radio. In the private network where QOS can be closely monitored and controlled VoIP can have a far reaching impact. In our simple example network (Figure 1.1) let’s start by looking at the connection between Baltimore and Denver. If the connection is a point-topoint T1, Cisco’s AS5300 could be used at either end for providing a digital T1 trunk to the PBXs. However, if only a few calls will be active at any time it may be prudent to look at a 2600 or 3600 series router. A simple 2600 series router can support up to two voice slots. Moving up to the 3640 and 3660 allows for much greater growth and expandability. The 3640 can support up to 12 analog voice calls and the 3660 can support up to five T1s for digital connectivity to a PBX. Each slot can hold two FXO, FXS or E&M ports. Each port can support a call. Specific details about what these ports are used for will be addressed in Chapter 2. A 2600 can support four analog voice calls at a time, which may be enough for a remote office. Keep in mind that the number of users in the remote office might be more than four, the question is how many concurrent calls will they make to the central office. Predicting call volumes is a magical art and is done using something known as Erlangs’ calculations. An Erlang is simply a representation of a continuous one-hour voice call. Hardly anyone makes a one-hour call; it is just a method for estimating the appropriate number of ports to have available. For a software based Erlang calculator visit www.erlang.com. For the Baltimore to Denver connection, using VoIP from the outset could make it easier to expand the voice network later. When Los Angeles is included in the network the benefit becomes apparent.



When users in Baltimore wish to make a call to Los Angeles it is ideal for the packetized voice to travel from one location to another along the most direct path possible. The traditional method would be to have a tie line between the two cities or a tandem PBX performing the call switching in Denver. As was discussed earlier this would lead to multiple encodes and decodes thereby degrading call quality. If we look at the data network though, it can travel through Denver first before getting routed to Los Angeles. Because VoIP is carried over IP it follows the same path as any other data going between two locations. Calls can be placed between Baltimore and Los Angeles and get routed through Denver just like any other data (Figure 1.7). The call is only encoded and decoded once and QOS measures can be managed easily because of the internal network. This eliminates the need for the tie line between the two cities. It also allows for future expansion into other cities. As you will see later in this chapter, VoIP can also be used for expanded functionality. Combined with the signaling protocol H.323, VoIP can assist in building a solution to replace the traditional PBX.

Figure 1.7 VoIP call routing between Baltimore and Los Angeles.

Looking at Return On Investment Nothing can help sell a solution more than a good Return On Investment (ROI). Creating an ROI can also help you make sure that you have covered all of the possible issues. Reviewing Current Expenses Building an ROI model is the best place to start when trying to decide if packetized voice makes financial sense. One of the best things about packetized voice is that it sells itself with a rapid ROI. No matter who you are you will most likely be trying to sell this solution to someone else. If they are the CEO/CFO of your company or a manager of a customers company they will want to see how this is going to save them money. In some rare cases, most of which will involve call centers, packetized voice can offer a different and more effective means of doing business. In most cases, the decisionmakers will be more interested in the bottom line. In that situation an ROI will be the best way of selling the idea. Showing the manager how quickly it pays for itself in raw numbers as opposed to talking about features will allow you to make use of the rest of this book. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (10 of 33) [13/12/02 18:18:28]


When building an ROI the first thing to look at are the current phone bills (Table 1.1). Most phone bills contain a wealth of information, but they can be quite long and will take a fair amount of time to get through. This section primarily covers justifying tie line replacement. Building an ROI for other services such as PBX replacement will be dealt with later in the chapter. One of the things to look for on the phone bills are calls that are placed between offices. This might seem obvious but it is important to make sure you get all of them. The next thing to look for is calls that are placed to locations that are local to the remote office. Taking our example network again we will look at calls from Baltimore to Denver (Figure 1.8). While many calls may be placed to the Denver office there may be a high number of calls that are placed to the Denver area. In our example network we can see that the Denver office is making local calls to customers in the Denver area. At a later time the Baltimore office calls the same customers in Denver over long distance circuits. These calls are expensive and are very important to building the ROI report. Check to see if there are any 800 service lines. Perhaps the customers in Denver are calling the Baltimore office through an 800 number in order to avoid paying long distance charges. Having these calls placed through Denver and then routed to Baltimore could allow for significant reductions in the number of calls to the 800 lines. These are all important items when building an ROI for tie line replacement. For IT Managers Only Key points on phone bills •

Get organized first.

•

Separate calls going to: o

Remote offices.

o

Local calling areas around remote offices.

o

800 service line.

o

Random and disbursed.

o

Understand the business model.

o

Quantify the impact of losing discounts for bulk calling plans.

There are a few things to be careful of when looking over the phone bill. First of all, don’t get overwhelmed. Try to arrange the bill into a simpler format by sorting different parts of the bill into separate sections. Incidentally, this is another selling point to keep in mind. Wouldn’t it be nice to have a short understandable phone bill? Random dispersed calls are items to quickly scan past. There will always be a number of long distance calls that go to uncommon areas. By uncommon I simply mean uncommon to the particular business. There is not much that can be done with those calls at this time. It is important to understand what those calls are for. If the business model is that all calls are geographically uncommon then building an ROI will be more difficult but not impossible. There may be a way to change the business model in order to lower costs. As packetized voice becomes more pervasive there will be no uncommon geography. However, for now it is difficult to find a method for lowering those costs. Depending on the total number of long distance calls the customer may be taking advantage of a



bulk discount pricing plan. As we will see later it can affect the ROI significantly if the remaining long distance calls are priced much higher due to the loss of the discount. Typically this will not be significant enough to overturn the justification for packetizing voice but it may have enough of an impact to extend the ROI quite a bit.

Figure 1.8 Long distance calling patterns. Table 1.1 Analyzing current phone costs. Calls from Calls to Denver Calls to local Baltimore Denver area Dollars Minutes

$713 10182@ $.07/minute

$1691 15376@ $.11/minute

Calls to 800 line Total per month from local Denver cost of area replaceable calls $1963 $4367 12268@ $.16/minute

Designing the solution Understanding the current calling patterns and bills will help to build an effective solution. Since we are only looking at tie line replacement at this point the configuration would probably be relatively simple; perhaps a 2600 series router with a digital T1 card to interface with the PBX. Whether using VoFR, VoHDLC or VoIP between routers it is still a simplistic configuration. Later chapters will delve into much greater detail regarding planning of capacity and equipment issues properly. The key issue now is determining the bandwidth needed to support the predicted call volume. Although up-front costs for equipment may be high, the long-term impact of circuit costs is what will matter the most. Accurately predicting bandwidth can be the key in making sure the recurring costs are low enough to pay for the new equipment in a short period of time. There are many tools for predicting call volumes and the necessary number of phone lines or trunks to support them. A popular tool is an Erlang table. Entire books have been written on this topic and the phone industry has perfected the process over the decades. For more detailed information as well as software based Erlang calculators please refer to www.erlang.com. The important thing is to determine how much equipment will be needed to support the predicted call volumes. It is also the key in deciding what type of circuit to price out. Particularly when dealing with Frame Relay there is a fair amount of customizing that can be done in regards to the



speed of the circuit. In order to build an effective ROI, real world pricing for circuits must be included (Table 1.2). Notice how the pricing on the 800 line has increased. This is due to losing the discount from the greater number of calls. Table 1.2 New solution pricing Calls from Off-net calls to Off-net calls to Calls to 800 Cost of new Baltimore Denver local Denver line from local frame circuit area Denver area $0 $0 $226 $1637 Dollars 0 0 1256@ Minutes $.18/minute

Total per month cost after upgrade $1863

Building the Return On Investment and Payback Period There are three steps to building the ROI and payback period. The first step is reviewing current expenses. The second step is detailing the costs involved in a new solution including the new circuit costs. The third step is combining the two and showing the time-frame for the payback period. Always include business reasons as well as the numbers in the justification. Usually the numbers will speak for themselves but it doesn’t hurt to throw in some good ideas about how packetized voice can help to move the organization forward. Don’t forget to include hardware costs (Table 1.3). Table 1.3 Building the complete ROI Item Cost Current monthly phone calls $4367 Recurring costs after upgrade $1863 Total monthly savings Cost of 2 new 2610s w/voice Labor for installation Installation costs for frame circuit Total upgrade costs Payback Period

Total cost

$2504

$22390 $1200 $1000 $24590 9.82 months

In the example the payback period is only 9.82 months with an ROI of 122%. Of course every network will be different but this is a great example of what makes packetized voice so attractive. In nearly all situations where there is a high volume of calls to a single office or area a short payback period will be common. Keep in mind that geographic proximity makes a difference. This model quickly falls apart when the calls are widely disbursed. What makes this work is the ability to eliminate a large number of public calls and place them on the private network.

The Network PBX Tie line replacement is often a good way to begin introducing packetized voice into an organization. The ultimate goal however, is to replace the traditional PBX altogether. The comforting thing about



tie line replacement is that it is fairly straightforward.

Replacing the traditional PBX When looking towards replacing the PBX there are many more factors that need to be considered. Instead of calls only passing across a single WAN link they may be traveling all over the network. This can have an impact on bandwidth although it would probably be a minor problem on a LAN. However, there are several other issues that can have an impact on the design. For instance is the current IP allocation clean and are there available IP ranges? Every new phone, unless it is a PC based phone, will require its own IP address. That would probably mean the need for twice as many IPs available to a network. That could be a problem for a large organization. Where should the Call Manager servers be placed in order to perform the best? Where will Public Switched Telephone Network (PSTN) connections be made for outbound calls? What third-party services will be implemented on the phone system? As you can see there are many questions that can arise when replacing the PBX. Call routing When you begin talking about placing the PBX on the network you need to look at how calls will transit the network. The calls will be from one IP host to another so it is critical that the routing on the network is stable. It is also important to make sure that a sufficient number of IP addresses are available. Network Address Translation (NAT) may not help in this situation for adding IP addresses later. Currently NAT is supported in H.323 but the implementation requires use of a Proxy and Gatekeeper. It is functional but can be difficult to setup. However, NAT is not supported when using Cisco’s Skinny protocol. The Skinny protocol is used by Cisco’s IP phones. For IT Professionals Only H.323 H.323 is a standard that defines how voice and video devices can communicate. It specifies both signaling characteristics and host-to-host communication protocols. H.323 has rapidly become the protocol of choice for call setup on voice communications. Several Cisco products implement H.323 Gateways for connecting to the PSTN as well as other features such as their IP phones. Microsoft’s NetMeeting is an H.323 compliant program that uses not only voice but video as well. There may not be a problem with using a separate private range of IP addresses for the VoIP system as long as the entire range is in the same IP range. This may cause a problem if you decide to use PC based virtual phones. The virtual phone resides on the PC and inherits the IP address of the PC. If the PC is on a real Internet IP and the rest of the phone system is on private IPs then you might think about using NAT. Once again, this can work but it complicates the design (Figure 1.9). It is important to note, once again, that the Cisco IP phones use the Skinny protocol and do not support NAT implementations. The phones can communicate with H.323 devices such as NetMeeting through a gateway such as Call Manager. For more details of the AVVID system see Chapter 8.



Figure 1.9 Call failure through a router performing NAT. As you will see the Cisco Call Manager (CM) combined with the Cisco Multimedia Conference Manager (MCM) provide much of the functionality of a traditional PBX. The purpose of the CM is to provide registration of IP phones as well as directory services for them. It is also a point where Telephony Application Programmers Interface (TAPI) programs can interface to the network. We will discuss TAPI applications shortly. It is important to place any CMs in the right locations on the network. The CMs should be placed in a location that can provide a high level of QOS as well as easy access for repairs and upgrades. Ask yourself how often does the PBX fail? The CMs must maintain that level of performance through diligent monitoring and appropriate backup systems such as redundant servers. Call Manager 2.2 provides for a primary and backup CM. Calls that are in-progress will continue. Any transfers, conferences or calls on hold will fail because the CM is actively managing them. Any idle phones will find the fail-over CM. Version 3.0 of CCM will support redundant load-sharing servers. Cisco’s MCM provides for management of H.323 conferencing as well as controlling bandwidth for those applications. These may not be considered typical PBX functions but it is part of the expanded functionality of a network-based PBX. MCM is a software enhancement for the 2500, 2600, 3600 and 3810 series of routers. It has the ability to require a log-in for H.323 conferencing using Radius or TACACS+ accounts. MCM can provide Call Detail Recording (CDR) for tracking usage and possibly for billing purposes. For call routing MCM can act as an H.323 Gatekeeper. Dial Plan Taking the time to devise the right dial plan is the key to allowing for growth and ease of manageability. In many cases the current dial plan can be transitioned to the new system. If the old plan is used, then it should be reviewed for growth potential as well as the ability to meet the unique requirements of VoIP. There are a number of extra items that should be accounted for: •

Voice mail extensions.

•

Call parking.

•

Reserved or pre-planned voice conferencing.

•

Special outbound gateways.

•

Third-party TAPI applications that may require dialing numbers.

These numbers may not be accounted for with an existing PBX system. If this system is being added to a new WAN that is covering many remote sites a new dial plan may be needed. The gateways and CM have the capability of forwarding calls based on wildcard digits. When placing a call to a remote office the digits can be forwarded to the gateway once a wildcard for that site has been reached. In our example network the central site is Baltimore with a CM. All local inside calls have 2 as the first file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (15 of 33) [13/12/02 18:18:28]


digit. In Denver local inside calls start with 3. The CM in Baltimore knows that if it sees a call that starts with 3 it will forward it to Denver. There are a few numbers that should be reserved for other uses such as 0 and 9. If you have more than eight sites you would need to move to a two digit prefix plan instead of one. The total number of digits in an extension also depends on how many people there is the potential for at each office. If that number will never go over 100 at any office then a 3 digit plan would work. In order to avoid headaches down the road make sure that the company will not grow beyond 100 people in each site. In other words, plan for more. Using a four digit plan to start with is not too taxing on the users and will solve many potential headaches down the road (Figure 1.10).

Figure 1.10 A simple dialing plan between Baltimore and Denver. Interactive Voice Response At some point or even on a daily basis a call to a business that uses Interactive Voice Response (IVR) systems will be required. We have all had the painful experience of pressing our way through ten menus before the finally system hangs up, our call unresolved. Obviously there is a right way to set up an IVR, but as we have all experienced, there is definitely a wrong way. In most typical situations there is an IVR on any public incoming lines. IVRs are useful for routing calls to the appropriate person or department, and are less expensive than having an individual do it. Many of Cisco’s products now support IVR internally, including the 2600, 3600 and AS5300. This is done with Tool Command Language (TCL) scripts and voice files which are referenced in the configuration on the router. When a call comes into the router and matches a set of criteria the script is queried. The script resides on the routers flash. The script runs and depending on the digits it captures plays an audio file. This audio file is also stored on the routers flash and is loaded into memory. Cisco provides several standard audio files but it is recommended that you create your own. The audio files use the standard au format. The scripts also have the capability of rerouting a call. Unified Messaging and the Amteva System Unified messaging is an excellent example of how two typically diverse networks, the phone network and the data network, can come together and provide a better solution. Voice mail and email have always been separate entities. With unified messaging both systems can fall under one interface. The benefits of this union can be bi-directional. Cisco acquired a small company called Amteva, which produces the Amteva Unified Messaging System (UMS). The UMS runs on Windows NT and Solaris platforms. It provides a range of features such as:



• Configuration parameters are stored in LDAP, a standards-based directory structure for organizing information. • Voice mail and faxes can be accessed through an IMAP email client. IMAP is a common standard for email retrieval. •

Email can be retrieved through any phone.

•

Supports numerous types of notification for incoming email, voice mail and faxes.

•

Fax headers can be retrieved through any phone.

•

Faxes can be delivered directly to an email inbox, viewed from there and transferred as email.

•

Single number reachability.

•

Web-based management interface.

•

Excellent scalability.

Configuration parameters are stored in Lightweight Directory Access Protocol (LDAP). LDAP is a standards-based architecture that has excellent scalability characteristics. It is rapidly growing in popularity due to its capabilities and open standards-based architecture. Using LDAP will also allow other applications to have access to some configuration parameters, opening the door even more for third party programmers. Voice mail and faxes can be accessed through any IMAP compliant email system. UMS uses these open standards protocols to convert voice mail and faxes to an SMTP/MIME email format. Voice mail recordings are stored as wav files and faxes are stored as tiffs. With Internet connected machines popping up everywhere this literally allows anyone to access their voice mail and faxes without having to make a long distance call to the PBX. You could sit down at any multimedia Internet terminal and listen to your voice mail. You could also check to see if your customer faxed back the signed contract. Once you have looked over your email and faxes you can send them back out just like email. Consider how many keys it takes to send a voice mail to someone else with a traditional PBX system. Then consider how easy it is to forward an email. Instead of having paper copies of faxes floating around you could just forward them to the appropriate people. And there is no reason the email can’t be forwarded to any email address. Using standard file formats the emails can be read by anyone. Email can be retrieved from any phone. Let’s say you are in the airport and you want to check your email before getting on the plane. You can call into the UMS and have your email read back to you. You can even listen to the headers of any faxes you have received. UMS can be configured to send a notification when a new email, voice mail or fax is received. These notifications are configurable for the different types of incoming messages. Notifications can be sent to a pager or to a phones message indicator light. Because the system is based on IP, a web interface has been designed to allow for remotely managing all configuration parameters. Even voice mails can be accessed directly from the system using the web interface. Configuration parameters for how the mailbox behaves can be setup there as well. Perhaps one of the most exciting features is single number reachability or “find-me, follow-me service.” Many people now carry a cell phone in addition to having a business phone and a home



phone. It could be argued that being reachable at all times may not be the best thing but there is no doubt that more and more people need that kind of access. The problem is that you have to give all of your numbers out to everyone and they have to try each number when they call you. UMS allows you to configure a list of numbers and the times to try them. When a caller calls your office number and you are not there they get message. The message states that you did not answer your phone and that they have the option of waiting while the system tries to locate you. They can also decide to go directly to voice mail at this time. If they decide to wait, the system starts down the list you have established. If it can’t reach you it still puts them into voice mail. If you are at one of the numbers on your list the call is patched through. This means only one number needs to be given out and phone numbers like your home number remain private. Driving the growth of many of these systems is the promise of relatively inexpensive scalability. As we will see in the ROI example, upgrading PBXs can be very costly. IP based PBXs and voice mail systems such as Amteva’s bring the exciting opportunity for rapid inexpensive growth. Through its use of distributed systems and architectures it can support from 50 to 5000 users and beyond. In today’s market of rapid growth this can be a key factor in deciding between upgrading/replacing PBXs and installing a packetized voice system Savings Analysis Example Working out a Savings Analysis for PBX replacement is often easy to do. The problem lies in the timing. After looking at the numbers it is often very cost effective to go with an IP PBX alternative. Many CFOs are unwilling to replace a PBX system if it is working even if they are paying more for it. However, there may be a rush of upgrades before Y2K hits. This is because many voice mail systems are not Y2K compliant. This presents an excellent opportunity to propose an IP PBX. Otherwise, if you are reading this book after January 1, 2000 it may be more of a waiting game. As the world moves towards packetized voice more companies will want to convert. Much like the adoption of the Internet in the business world, common use in the market place will start driving more companies towards packetized voice. In the mean time there is still one key area where opportunity exists. Many lower end PBXs are supplied with a fixed number of ports. This is especially true for small offices that are just getting started. They may purchase a 48 port PBX and outgrow it. Nearly all of these systems have fixed port sizes. When the company expands to the 49th person they have a problem. They can either not give that person a phone, which is unlikely, or they can do a forklift upgrade. In a forklift upgrade the old PBX comes out and a new one goes in. Although many PBX vendors have trade-up programs this can still be very expensive. What is worse is that they may need just a few more ports. The next size PBX might have 250 ports as a minimum. The cost would be outrageous for the benefit of getting a few more people phones. Another large source of cost is the maintenance fees. PBX vendors typically charge hefty maintenance fees that are proportional to the size of the PBX. Now a company that just wanted to add a few more people is paying maintenance fees on a PBX that has far more capacity than they will use. This is a prime opportunity to replace the system with an IP PBX. The advantage is that they can keep the existing system and gradually migrate in an IP based unified messaging system. This solves the short-term concerns of getting phone service to the few extra people they have, and allows them to start growing towards the future. Within a few months they can have everyone on the new system and can get rid of the old PBX. This is one of the great advantages to IP based PBXs. Moves, adds and changes are inexpensive. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (18 of 33) [13/12/02 18:18:28]


Using truly IP based phones the user simply takes their phone with them when they move offices. Configuration is done through a central configuration point for new users, and users can facilitate administration of their own phones through a web interface. This user administration will be much simpler than trying to read through the thick manuals provided by traditional PBX vendors. Table 1.4 A sample Savings Analysis for PBX replacement Item Cost Total costs Cost of upgrading to new PBX $75,000 Rebate on old PBX -$5000 $70,000 Call Manager $14,000 Difference $56,000 Annual maintenance fee on new PBX Software upgrades for CM Difference

$15,000 $2000 $13,000

The last thing that sets IP PBXs apart from traditional PBXs is open standards. As IP telephony becomes more prevalent the costs associated with equipment and software will continue to drop. This is completely opposite from the traditional solution. PBX prices have hardly dropped at all over the last decade. With open standards anyone can go down to their local computer store and purchase a $100 USB camera and not only can they talk across the Internet, they can videoconference. The quality across the Internet can vary but performing this across a private network is not a problem. For example; I had a videoconference with a gentleman in The United Arab Emirates; the speech and video were a little stuttered but it was nothing less than I would have expected from a satellite phone. The best part was that it was free using a low-end eyeball type camera and the sound card in my laptop. This rapid level of growth is sure to make packetized voice incredibly inexpensive over the coming years.

Advanced Features and Integration Possibilities What makes the transition to packetized voice so revolutionary is its openness. With the growth and adoption of open standards new possibilities become available. Instead of paying exorbitant fees to a single PBX manufacturer in order to create a value added service, programmers can create applications based on these open standards with confidence that their program will work with many different systems. This simple concept will open the floodgates to applications and services that haven’t even been considered yet. It will also make higher end features more affordable to the small business.

TAPI Integration One of the key enablers for this rapid growth of open standards applications will be through the functionality of TAPI. TAPI is a standards-based programming interface for telephony applications. It allows programmers to access telephony specific information being supplied by other TAPI



applications on the system. This interface has benefits on the workstation and server platforms for different types of applications. On the server the benefits include diverse types of value added services allowing them to integrate with each other. Different applications such as voice mail, IVR and call detail recording information can be enabled through TAPI. TAPI facilitates new applications to be designed that could not have been dreamed of with the traditional proprietary PBX programming interfaces. As the standards grow and systems become more robust TAPI can grow with them. The other place where TAPI will have an impact is at the workstation. Some of the TAPI applications that exist now are as simple as phone dialers. Some of the more advanced applications use TAPI for enabling screen pop-ups. As a call comes into the workstation it registers certain items like the calling number. With an application that is TAPI enabled these dialing numbers could be passed through. This is a good application for a call center environment where an operator can get information about the caller before answering the phone. With a well thought out application a sales call center could instantly have information about the name of the person calling, their buying habits, the last time they purchased something, what kind of shipping they prefer and if they prefer blue over yellow. In a help desk environment the operator could instantly have information regarding the nature of past problems, the level of the service contract and even the typical demeanor and knowledge level of the person calling. Then, as they pass the call to the next level of support the next person gets a pop-up with the same information as well as new information about the particular case. It is quite obvious that the sky is the limit for creative programmers. As the market continues to grow new ideas will come out of the availability of the open standard TAPI.

Web Click-to-Talk You’ve seen the commercials. A mom is looking at some clothes on the web and she gets her son to come over and take a look at them. He isn’t happy about wasting his time shopping. She sees a shirt she likes and wonders if it is available in other colors, so she clicks on the link to customer support. A window pops up with a videoconference to a lady who can help. Until the entire phone system is packetized and IP based this may seem like a remote dream. For home consumers it will be a dream, but for business this could happen now. Imagine a large corporation with an entire department dedicated to human resources. An employee decides to take a look at some 401k options so she pulls up the company Intranet on her browser. She clicks over to the 401k section and starts reading. She gets about halfway through and realizes she has more questions than answers. What does she do now? In the traditional sense she would pull out the company phone list and search for someone in HR. She finds a number and calls and no one answers, so she calls another. That person doesn’t handle the 401k, so she calls another. This person doesn’t even work in HR anymore. Now imagine a different ending where she clicks on a link at the top of the page. This link automatically dials her phone. She picks up the phone and waits for the other end to start ringing. At the other end is the exact person she needs to talk to. The applications are limitless and the kinds of ideas that have been tossed around regarding web click-through have just scratched the surface. Once a phone is IP enabled it is simply a destination address on the IP network. Web click-through is one exciting use for this feature. The hyperlink is configured in a such way that a TAPI application is activated. This application rings the local phone. Once the user has picked up the phone it begins ringing the destination. Once the destination has picked up the conversation continues just like any other call (Figure 1.11).



Figure 1.11 Web click-through call process.

Transfer, Forward and Conference Capabilities Transfer, forward and conference calls are all features found on a typical PBX. Due to the direct point-to-point nature of IP calls a software solution needs to be implemented. When calls are placed from one IP phone to another using the CM, the CM is only used for call control purposes. Once the addressing has been established the phones communicate directly between each other using Real Time Protocol (RTP). The phones themselves are not particularly smart. They have the ability to encode and decode calls and they can establish a call to a remote phone using the addressing that has been provided to them. They can also store templates for autodialing numbers. That is about all they can do right now. As the technology matures they may be able to do more. Presently, in order to have those three services a software based server must be implemented. This is the conference bridge software which works with CCM, and it serves two purposes. The first purpose is for impromptu conferencing; the call has to go through the conference bridge at that point and the voice traffic is redistributed to all of the endpoints. The second function is meet-me conferencing which is for establishing a prearranged conference call. This might be used for a weekly meeting in which all of the managers around the country dial in. There are many uses of this type of functionality. As for the transferring and forwarding of calls, the CM has the ability to handle these features but the phones have to signal back to the CM to make this happen. Refer to the Appendix for a more detailed description of the Cisco AVVID system.

Faxing Faxing can experience the benefits of packet telephony in a number of different ways, such as integration with email. The Amteva UMS can provide a conduit for an incoming fax to be placed into an email box. This can then enable the fax to be transported anywhere email travels as a tiff file. With this type of technology there is no need to be at the fax machine in order to receive a fax. Typical paper faxes also degrade in quality after getting faxed multiple times. Once a fax is in email it can be forwarded to as many people, as many times as is necessary with no degradation. The other faxing benefit is from store and forward faxing capabilities. This feature can be enabled on the AS5300. It allows incoming faxes to be converted to email and sent to a Simple Mail Transfer Protocol (SMTP) server for redistribution. It can also work in the opposite direction.; an email can be sent directly to the AS5300 with a tiff file attachment. This feature conforms to the RFC 2305 standard established by the IETF. In a simple configuration this can be used for sending faxes to a remote site over a private network.



Call Detail Recording and Data-Mining Even with the lowered costs associated with using IP based telephony systems there exists a desire to have complete accounting records. This is true for the business user, as in the smaller company that wants to track where calls are being placed. This is a proactive strategy that emphasizes managed growth. Without understanding where calls are being placed it is impossible to determine where bandwidth may need to be increased. Accounting records are also a major part of business for companies reselling phone services. A good accounting strategy involves Call Detail Recording (CDR) as well as bandwidth analysis obtained from the network. Without both there is no way to determine if bottlenecks are being caused by voice calls or data traffic. Many of the various pieces of the Cisco voice solution include the ability to capture call detail records. The Multimedia Conference Manager software can track a number of details and report them to a Radius or TACACS+ server. Those details include: •

Calling number

•

Called number

•

Call start time

•

Call end time

•

Bandwidth utilized

Cisco Call Manager also supports output of its CDR to either a Microsoft Access database or an ODBC database such as SQL (Figure 1.12).

Figure 1.12 Call detail from Cisco Call Manager. Once the data has been compiled to a database, a front-end interface can be designed to format the data in a useful way. In a simple business environment, graphing of the call trends over a one-month time period could prove very valuable. This would allow you to determine such things as whether or not the circuits that are available are being utilized. It could show what departments are making more calls than others, even down to the individual. A trend analysis could be set up to show the duration of calls during a certain time of day. If the CM is being used in a call center environment then the records could show average hold times, dropped calls, and duration of completed calls among other things. No doubt, if there is not an application that is currently using the call record data from CM, then there soon will be. Taking the reporting to the next level would be those companies that need to build billing records of the call logs. Because CM logs the calls directly into a database format the front-end interface can pull details from these records and compile them into an automated billing system.



Voice Over Frame Relay Frame Relay (FR), at least in the eastern part of the United States, is becoming a very commonplace circuit. This makes it a good candidate for replacing traditional voice circuits.

Where To Use It Earlier in this chapter we looked at the advantages of implementing a toll-bypass solution. Voice over Frame Relay is probably the single best way to implement this simple task. FR networks are growing at an increasing rate and are quickly becoming the circuit of choice for most interoffice connections. As was shown earlier, the cost of long distance frame circuits continues to drop, and unlike VoIP, there have been standards for VoFR in place for several years. As always, open standards allow for vendor interoperability and usually a better-tested product. Growth Curve Of Frame Relay Frame Relay has been growing at an incredible rate, and if we look at the benefits it is easy to see why. •

Costs related to FR are relatively low compared to other types of circuits.

• Once a port is purchased, adding PVCs (Permanent Virtual Circuits or the virtual connection between two FR ports) is simple and usually inexpensive. • FR can be oversubscribed. This allows more bandwidth to be mapped to a port than it would theoretically allow. The principal being that the remote sites would not all be sending at the same time. Although this is a great feature for data traffic it can have a severe impact on voice traffic. •

It is available just about everywhere.

•

It can support a wide range of bandwidth from 56K on up.

There is no question that FR will be the circuit of choice for wide area networks at least for the foreseeable future. This makes it an excellent transport for voice applications.

When Does VoFR Make More Sense Than VoIP? The single most useful aspect of VoFR is taking advantage of existing or low cost circuits to provide tie line functionality between PBXs. Where it can exceed VoIP is in minimizing bandwidth usage on the WAN connections. The header for FR takes up only a little more bandwidth. A call that has been compressed using G.729A uses about 8 Kbps. FR overhead bumps that to about 10.8 Kbps. With a typical tie line replacement this level of compression and bandwidth savings provides much more room for data to travel over the same circuit (Figure 1.13).



Figure 1.13 Bandwidth savings with VoFR.

Toll-Bypass Opportunities One of the most important things to avoid when packetizing voice is compressing and decompressing a call multiple times. Every time the call goes through a CODEC there is a delay as the call is encoded or decoded. Multiple conversions can result in a degradation of quality. If we look at our example network again we can see how this affects where VoFR can be used. In this sample configuration Denver will be the headquarters. Using FR to connect Denver to Baltimore and Los Angeles is a cost-effective solution for providing data and voice. For example let’s say that Donna picks up the phone in Denver and wants to call Bob in Baltimore. As her call is placed across the frame network it goes through several processes. The first process is the receiving and then passing of any digits. The second process is encoding. Donna’s voice is broken down from an analog waveform into bits (1’s and 0’s). This is the coding or compression process. These can include the algorithms for G.711, G.729A or G.723.1. Each algorithm processes the waveform differently but they all convert into bits. Once the call is in a packetized form it is sent across the FR circuit. In Baltimore the router receives the bits and processes them through its decoder. Importantly, the CODEC used at each end must match. Once the router has converted the bits into an analog waveform it sends the call out of the appropriate phone port (Figure 1.14). file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (24 of 33) [13/12/02 18:18:29]


Figure 1.14 Encoding and decoding of a voice call. This is great news for the CFO because of the savings earned from avoiding long distance calls. Refer to the Payback Period analysis that was detailed if Table 1.3 for information on just how happy the CFO will be. Because Denver is the central site, the same scenario can be illustrated between Donna in Denver and Lewis in Los Angeles. Hopefully most of the calls are between the remote sites and the central office. What happens when there are calls between remote sites? Let’s say Bob in Baltimore wants to call Lewis in Los Angeles. While it may be possible to configure the router in Denver to forward the calls back out to Los Angeles there are still several problems that would make this unfeasible, and this is where VoFR starts to fall apart. To begin with you would be encoding and decoding the calls twice. As the call leaves Baltimore it gets encoded and when it arrives in Denver it gets decoded. Once again it gets encoded as it leaves Denver and gets decoded as it enters Los Angeles. This introduces all sorts of problems as far as quality and delay are concerned. The call would also occupy two CODECs on the Denver router. That alone is an inefficient usage of hardware. The exception would be if you were using Cisco Switched VoFR, which would allow the call to be passed through without multiple codings. FRF.11 would require multiple codings.

Figure 1.15 Encoding and Decoding of a call between Baltimore and Los Angeles. When end-to-end calls are needed across multiple locations it becomes a better opportunity for VoIP. VoFR has the edge from an ease of implementation and management standpoint as well as long-term cost savings for point-to-point calls only.

Voice Over ATM ATM has the unique ability to provide multiple levels of QOS. While the engineers work frantically trying to implement some QOS measures in IP, ATM has had these features all along. One of the big drawbacks to ATM is availability.

Where To Use It Although ATM has had great success in penetrating the large WAN backbone market it still has difficulty moving beyond that. As gigabit Ethernet begins to grow in popularity ATM will have a more difficult time justifying itself in the corporate backbone. However, ATM can still provide true quality of service measures for applications that need it such as voice and video. These inherent



QOS capabilities will allow ATM to outperform IP solutions in many bandwidth intensive, timesensitive applications such as voice and video. ATM will always have a speed advantage over Ethernet and Fast Ethernet. The obvious place to use VoATM is where you have ATM networks already installed. If you are lucky enough to have ATM to the closet then VoATM becomes an excellent means of transporting voice. Or perhaps you are carrying ATM service to a remote office. In order to transport voice to the desktop it helps to have the ATM network as close to the desktop as possible. A prime example of where it doesn’t work is where ATM is used only in a backbone in a headquarters. If ATM is not extended to the remote offices in this situation, it cannot carry the voice to them. Let’s look at our example network again. With a Cisco 3810 in each office we can terminate ATM circuits as well as peel off voice calls. Using ATM also has the advantage of to providing end-to-end calls (Figure 1.17).

Figure 1.16 ATM network providing end-to-end calls. Now that the network can be end-to-end ATM calls can originate in Baltimore, pass through Denver and end in Los Angeles without having to encode or decode the call multiple times. Because of ATMs ability to perform QOS the voice calls can be placed into their own QOS queues. The result is that calls from coast-to-coast can be without any degradation in quality while still ensuring their timely arrival. The various classes of service will be discussed in more detail in a later in this book. In essence, data and voice are placed in queues that are treated differently throughout the ATM network (Figure 1.17).



Figure 1.17 QOS queuing with voice and data traffic. Many IP QOS measures that are currently being implemented are router specific. This is one of the major hurdles that IP engineers face. The current IP packet does not include detailed information about QOS other than the IP Precedence bits. Some headway is being made with enhancing these QOS tags but this is still one of the major drawbacks to using VoIP in congested networks. When utilizing ATMs’ QOS measures the tagging information is carried for the life of the cell. A cell is ATMs equivalent of a frame. We will discuss the advantages and disadvantages of this in a moment. As long as the voice call is carried through the ATM network it can keep the higher QOS tag. This is also true for video as videos’ needs on a network are very similar to those of voice, the significant difference being the bandwidth needed. The bandwidth requirements for video are significantly higher. However, managing the efficient transport of video by using QOS measures is very similar to that of voice. ATM is a completely different method of handling data flow. One of the major differences between ATM and other frame based networks is that ATM breaks data into cells. A cell is 53 bytes long and contains a 5 byte header. This header contains all of the ATM specific information regarding source and destination address. This is one way that ATM can potentially gain a speed advantage. In a frame based network such as Ethernet the frame size can vary. This causes the switches to have to either wait for the entire frame (also called store and forward) or take a chance and start sending the frame out the destination port as soon as it receives it. Because ATM cells are always 53 bytes, the ATM switches know when the end of the cell has been received without an of end of frame identifier. This allows ATM switches to switch cells very rapidly. A problem arises with the fixed length of cells. Frames have the ability to match their size to the particular data that is being sent. ATM places as much data as possible in a cell and if there is any space left over it pads it. Padding is adding blank space to a cell in order to reach the 48 byte payload requirement. Imagine how much space this potentially wastes. The same voice call that was discussed in the VoFR section using G.729 for compression now takes up 14.13 Kbps of bandwidth. Using G729 results in voice being segmented into 30 byte payloads. This results in 23 bytes of overhead, almost as much as the payload itself (Figure 1.18). This can chew up a lot of bandwidth on slower connections so it is important to understand the ramifications of using ATM on anything under T1 speeds. We will go into much more detail configuring VoATM later in this book.



Figure 1.18 ATM cell and potential overhead.

QOS vs. Availability As we’ve discussed the main advantage to using ATM is its built in QOS measures. The ability to classify a voice call from end-to-end is a great advantage. In a campus-wide environment, using ATM is as simple as running fiber between buildings. This scenario allows ATM to be extended as close to the desktop as the budget allows and would be an ideal solution for a school that has buildings spread over a large campus area. A single set of fibers can connect each building in order to enable data and voice across an ATM network (Figure 1.19). This allows for growth in data speeds and the ability to provide a level of QOS to voice traffic.

Figure 1.19 Campus ATM network utilizing voice and data. If we look at our example network again we see that we must turn to an ATM network provider which presents a potential problem. In the cities we have talked about so far it is likely that there is someone providing ATM service. What if there is a remote office in Billings, Montana that needs to be connected as well (Figure 1.20)? Although it is possible that ATM service is available, it is much more likely that FR would be the circuit of choice. As we travel down the road of technology growth this argument may disappear.



Figure 1.20 Adding a remote site can be a problem with ATM. Using FR to get to a location like Billings may not be so far fetched. One of the nice things about using ATM in part of the network is that it has some similarities to FR and converting from ATM to FR and back again is not too complicated. Although QOS tagging would not carry through the FR network it could be a means of extending voice to those remote sites. ATM may become available everywhere at some point in the near future. When this happens there may still be one drawback. The costs associated with ATM are still somewhat higher than FR. Equipment costs have come down quite a bit and in a campus environment ATM can be a very attractive solution. However, ATM service provider circuits are typically more expensive than FR circuits. This may make it difficult to justify ATM as opposed to FR. Keep in mind the following advantages that VoATM has over VoFR: •

Complete and detailed QOS measures.

•

End-to-end call routing without multiple encoding and decoding.

•

ATM popularity is still growing and services will be available everywhere in the near future.

•

ATM in the backbone as well as the WAN means one network topology throughout.

Summary The packetized voice market has many avenues of growth available to it. In this chapter we have looked at some of the basic design considerations for many of them. Although this technology can lead to much excitement about its possibilities, we must keep in mind our current limitations. A good starting point for packetized voice is simple tie line replacement. Don’t get over ambitious and file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (29 of 33) [13/12/02 18:18:29]


try a forklift upgrade to the entire PBX system when the situation doesn’t warrant it. When the next phone bill comes out, you might want to take a look at it. Start building an ROI for replacing a tie line or two. It can be approached as a trial run. You might be using some Cisco 2500s for WAN routers already. Figure out how much it would cost to replace them with Cisco 2600s or 3600s and then build the justification off of the savings from sending voice over the frame relay or HDLC circuit. Do some homework and make sure there is bandwidth available if you will be using preexisting circuits. If the circuits aren’t there maybe it is time to enable some file sharing between offices as well as the voice. The added benefit of adding data sharing might help in getting the sale. Once you have determined that this will happen, plan the migration carefully. Make sure everything goes off without a hitch and there won’t be any problems adding more sites. Once everything is up as tie line replacements you can start talking about PBX replacement. PBX replacement can involve many stages. The first stage is coexistence. It is unlikely, unless it is a completely new location, that an office won’t have a PBX already. It is important to evaluate and understand how the two different PBXs can coexist. This is often the means to getting in the door. You should look at things like: •

Available capacity.

•

Growth of the company.

•

Cost of additional phone sets.

•

Costs involved in upgrading.

•

Annual maintenance costs.

All of these items can incur cost savings when moving to a network PBX. Make sure existing IVR devices are accounted for when moving. Try to have a test line where an IVR can be set up and tested before going into the production environment. Because the IVR is the first point of contact for incoming calls it is absolutely critical that it set up right. You may want to look at the opportunity to introduce a unified messaging solution. Once a few people are online with this the news of its features will spread rapidly. Be prepared for an onslaught of users asking for the same functionality. Either during the implementation phase or after everything is up and running the time will come to look at other value added services. What kinds of third party software have become available that can enhance the functionality of the system? One of the first things to consider is faxing. Look at the call records associated with the fax machine. Of particular interest are the faxes that are being sent to remote offices. Depending on the call traffic, a solution that implements store and forward faxing may be appropriate. If data is already being carried over a WAN to the remote office then it should be relatively easy to devise a faxing alternative. If the organization is a large one or one that has a sales call-center, web click-to-call could enhance the business. By using the power of the web, things such as HR queries could be made easier. From a sales perspective web click-to-call allows the customers to interact on a more personal note than the sometimes sterile web interface. Until voice over the Internet is widely available that may be difficult. But why not implement it at kiosks. Large department stores could have catalog ordering kiosks that are completely automated until the customer has a question. At that point they could use the web click-to-call. When will voice over the Internet be viable? Who’s to say? It will probably be sooner rather than later though. Until then it may be a good alternative to overseas communications provided the user is prepared for delays and jitter. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (30 of 33) [13/12/02 18:18:29]


Once everything is in place and running smoothly don’t forget the monitoring and maintenance. Part of this task involves looking at the Call Detail Records. Much information can be gleaned from this database. Calling patterns, peak hours, duration of calls and a laundry list of other things can be determined. You can use this to see where you are saving money and where you may be wasting it. Combining the CDR reports with the corresponding bandwidth utilization on circuit can be quite powerful. Maybe you can determine that the 768 Kbps CIR FR circuit never gets above 256 Kbps. Or you might see that the reason the users in Denver are complaining of poor performance is because their circuit is over utilized. Without the details there is no way of knowing. Despite the fact that many people believe network maintenance is a secret art, if you have good accurate measures of the performance it almost becomes easy. Don’t forget about VoFR and VoATM. These technologies can be very useful in certain circumstances. VoFR can be quite useful when it is designed as a tie line replacement. It is simple to implement, takes up very little bandwidth and requires almost no maintenance. The cost savings can be tremendous for such a simple alternative. VoATM is a great alternative when there is an ATM network in place or going to be installed. The closer that ATM gets to the desktop the better. Also, VoATM is manageable over smaller circuits but keep in mind it may not be the best solution. This chapter should have prepared you with general design concepts and solutions that utilize packetized voice. The market is growing so rapidly that new products are introduced all of the time. Within a few months or a year some of the concepts in this chapter will be much more widespread and easier to implement. It is important to start laying the foundation now. The following chapters will address the technical issues involved in making these concepts work. As always the best place to keep on top of new technologies that Cisco is offering is on their web site. You can be sure that the details in this book will only be supplemented over the coming years and not replaced.

FAQs Q: What types of technologies are available to me today? What will be available tomorrow? A: Actually, quite a bit is available today. Tie line replacement is typically the simplest way to start. There is no reason you can’t replace the entire PBX right now. Some of the more advanced integration tasks may be difficult to implement today but should be easier in the near future. Q: Will I be able to sell this to my boss/customer? A: Absolutely! The costs associated with packetized voice are small compared to those with traditional voice solutions. The Return On Investment usually has a pretty quick turn around. Q: How do I build an ROI? A: The first and most important step is to gather as much information as possible and organize it. Q: When can I yank out my old PBX? A: Although you could do it today that’s not necessarily the recommended way to go. It is a better idea to migrate from the old to the new. Once the migration is complete then remove the old PBX.



Q: What can I do about the voice menu system? A: Interactive Voice Response is available on several different Cisco platforms. Not only does it allow you to redirect calls it can capture digits for things like PIN numbers. Q: I’m not going to lose voice mail, am I? A: Of course not! Cisco’s acquisition of Amteva gives them a complete unified messaging system. Q: What is unified messaging? A: Unified messaging is the integration of email, voice mail and faxing. It allows all of these services to be accessed through an email client or through a phone. Q: If my voice mail is treated like an email can I forward it to someone? A: Yes. You can even forward it to individuals who are not on the Amteva system. The voice is treated as a wav file attachment. Any multimedia computer should be able to play it. Q: How can I get my email through a phone? A: Amteva’s UMS will read it to you. Q: Will this work across the Internet? A: The best answer is maybe. The Internet is an unpredictable environment and without control you have no way of guaranteeing timely arrival of the voice packets. It will work but it may not work well. Q: My current PBX has another application that tracks usage, and bills my customers automatically. Is there anything that can do the same thing? A: If the application can use a Microsoft Access or other ODBC compliant database then the same application will work. It may need some reconfiguring. Q: The application XYZ that I’m running on my PBX was written by the manufacturer. Will it work on the new system? A: Probably not. That’s one of the major drawbacks to traditional PBXs. Nearly all of them have closed proprietary systems. Q: What about 911 calls? A: If the phone system goes down that’s a problem. There must be what’s called a lifeline phone circuit that can be used in case of an emergency no matter what happens. It is a good idea to have an analog line with a simple phone attached just for emergency purposes. Q: How can I have music on hold? A: It is coming but is not available yet. Q: How committed is Cisco when it comes to voice? Will they still be making solutions in a few years? A: Cisco is very committed! Voice solutions are one of their greatest focuses right now if not the primary focus. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_01.htm (32 of 33) [13/12/02 18:18:29]


Q: Is packetized voice really going to be that big of a deal? A: If a company like Cisco is focusing a great deal of their efforts on it, it must be. With open standards and lower costs it will do what email has done in becoming ubiquitous across all businesses.


Chapter 2: Introduction to Analog Telphony


Chapter 2 Introduction to Analog Telephony Introduction Analog Signals & Systems Analog Network Components Analog Signaling Analog-To-Digital Conversion Summary FAQs This chapter introduces the information systems professional to analog telephone system terminology, technology, and operational concepts. Specifically this chapter will discuss: •

Analog Signals and Systems

•

Analog Network Components

•

Analog Signaling

•

Analog to Digital Conversion

Introduction Alexander Graham Bell, a native of Scotland, developed the first practical analog telephone in 1876. Mr. Graham’s now famous outburst “Mr. Watson, come here, I want you!” brought his assistant Thomas Watson running. Mr. Bell’s outburst was the result of spilling acid, a component of the very first impractical telephone, on his pants. Mr. Watson’s urgency wasn’t so much in response to Mr. Bell’s distressful outburst, but more because Mr. Bell’s voice had been clearly transmitted and reproduced on a crude yet functional telephone



receiver in Mr. Watson’s office. That’s right, the first telephone call was a call for help. This fledgling technology not only spawned one of the largest companies on earth, American Telephone & Telegraph Company (AT&T), but also MCI, LCI, Sprint, GTE, Bell South, and all of the other U.S. based and international telephone companies. AT&T alone, grew into a huge multi-billion dollar company providing well over one million telephones and employing over one million people. There is now another tremendous change taking place in the telecommunications industry with the integration of voice and data. This chapter details the principles and concepts of analog signals and basic telephone system operation as a prelude to understanding and implementing Voice over IP (VoIP) using Cisco’s core VoIP products: 2600, 3600, AS5300, AccessPath-TS3, and 7200VXR. Take special note of the 7200VXR Cisco router model. These routers are the newest, multi-service, Cisco 7200 series routers designed to support gigabit network capabilities and improve integration of data, voice, and video via an integrated Multi-service Interchange (MIX) that provides the ability to switch DS-0 timeslots between multi-channel T1 or E1 interfaces. In today’s business environment approximately 80% of communication is by voice and 20% by electronic data (for example: email, database updates, file transfers, web page displays, telnets). However, as we near the millennium you can depend on the world of electronic telephony, to change. Voice and data transmission, their technologies, and the departments responsible for them are merging. Before we discuss why these changes are occurring, and how to help your customers benefit from this technological innovation, let's firmly ground your understanding of VoIP by exploring analog transmission, signaling, and telephone systems operation.

Analog Signals & Systems Analog refers to transmission of electronic information achieved by adding signals of varying frequency or amplitude to a carrier wave of a given frequency. Traditional broadcast mediums like radio, television, and public switched telephone networks (PSTN) use analog technology that is typically represented as a series of varying sine waves. The term “analog” can be traced to the similarity between the actual fluctuations of the human voice and the “analogous” or comparable modulation of a carrier wave. The human voice occupies the 20Hz to 20KHz range, with most energy in the 300-3300Hz range. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (2 of 34) [13/12/02 18:18:37]


Viewed graphically (Figure 2.1) both the human voice and a modulated carrier wave display periods of little or no activity followed by periods of activity.

Figure 2.1 Analog sine waves. Basic System Operation Analog signals are continuous waves that are capable of representing an unlimited number of values. Telephone systems use analog-switched lines to provide voice communications by converting sound waves, vibrations that move in the air, into electrical signals. Each telephone handset contains a transmitter covered by a diaphragm and a receiver composed of a coil attached to a speaker cone that vibrates producing sound waves. When a person lifts the telephone handset to make a call, switchhook contacts are closed, energizing a relay which prompts a device called a line searcher to find an open line. Then a connection from customer to telephone central office is established and a dial tone is generated. The line finder then prepares the telephone company switching equipment to receive a telephone number. When a person speaks into a telephone handset, acoustical energy vibrations caused by their voice applies varying amounts of pressure to the diaphragm. In response to the natural rise and fall of human speech the diaphragm in turn converts this pressure into different amounts of current or electrical energy. This variation in the current is in effect an electrical representation of the human voice. The resulting output of this



process is an analog electrical signal. The transmitted signal then flows through the voice coil in the handset of the person receiving the call. The coil attached to the speaker cone in the receiver vibrates in response to the signal to re-produce sound waves, and the person listening to the telephone hears the other persons reproduced voice. To allow the person speaking into the telephone to hear his or her own voice a small amount of current called a side-tone is applied to the transmitting station’s receiver; this also helps control the loudness of a person’s voice. In the early days telephone sets had a hook to hold the receiver, and although today’s phones no longer have an actual hook to hang the receiver on, the term “switchhook” remains. Standard telephone cabling is a single pair of twisted pair copper wiring. The telephone network termination point is an RJ-11 jack. The two-wire connection has two pins designated “tip” and “ring”. In the early days of the old manual plug type switchboard, “tip” was the tip of the manually inserted plug connector, and “ring” was actually the other half of the circuit just behind the tip of the connector. Lets do a quick review and break the preceding process down into some simple steps for an analog phone call via a single CO switch: •

Step 1: Both telephone sets are on-hook and circuits open.

• Step 2: A handset is lifted the switch is closed and current begins to flow. The telephone is then considered to be “off hook.” This sends a signal to the telephone company’s Central Office (CO) and their system generates a dial tone. • Step 3: The customer dials a destination telephone number and the resulting signals are received “in-band” by the CO switch. • Step 4: The CO that handles the destination phone sends a ringing signal to the destination receiver and a ringing signal to the sender to let him or her know that the call request has been completed and the call is going through. The time it takes for the CO to complete the connection between the person calling and the person called is referred to as “call setup time”. • Step 5: When the call is answered another signal is sent to the CO to stop ringing and begin the accounting process.



• Step 6: When the telephone is put back onto the cradle the switch is again opened, current flows and the dial tone stops. When this occurs the telephone is considered to be “on-hook”. The telephone company’s CO uses “on-hook/offhook” information in addition to “called-from” and “called-to” numbers, length of call, and charge per minute or partial minute to generate billing data. Offices containing more than a few users often make use of specialized switches designed to share trunk lines to a PSTN. These specialized switches include private branch eXchange (PBX) and key systems. Both of these switch types will be covered later in the chapter. Dial Pulse Signaling The telephone network is a system of computerized switching nodes. These nodes communicate with each other in order to coordinate customer call connection, tear down, and accounting/billing functions. This process is called signaling. There are basically two methods of signaling used to place a telephone call: older and fast-fading dial pulse (DP), and the more popular dual-tone multifrequency (DTMF). When you use DP, a circuit opens and closes the exact number of times as the number of the digit dialed (with just one exception as we will note later). For example if someone dials 1-919-555-1212 the switch opens and closes one complete cycle or about every 100 milliseconds as follows: once, nine times, once, nine times, five times, five times, five times, once, twice, once, twice. Pretty straight forward so far, but as mentioned earlier, there is one exception to the circuit open, circuit closed rule; when dialing the number 0 up to ten pulses may be sent to represent the dialed digit. Each open switch period is called a break interval and each closed switch period is called a make interval. Telephone company equipment senses and decodes the number of pulses between numbers dialed based on an incredibly small timed delay between each number dialed. The timed interval between dialed numbers is approximately 700 milliseconds. As a comparison 1 second is equal to 1000 milliseconds, so the delay between dialed numbers is calculated at 7/10 of a second. Each time a DP contact interrupts the flow of loop current, a voltage spike occurs. These voltage spikes may cause the telephone bell ringer to ring very softly or “tinkle.” “Anti-tinkle” circuits are integrated into the circuitry of a DP system and designed to close when the dial is operated. Often used with a speech file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (5 of 34) [13/12/02 18:18:37]


muting circuit designed to eliminate dial-induced clicking on the receiver, an antitinkle circuit shunts a 340 ohm resistor across the ringer coil to prevent dialproduced current from reaching the bell. Originally conceived and developed to operate electromechanical switches, dial pulses are limited by the mechanical speed of the switch; a very slow operational rate of 8 to 10 dial pulses per second. I can easily recall my Grandmothers’ large black WWII style DP phone and the slow yet sure speed of the rotary dial as it returned to its original location after letting your fingers do the numeric walking. In today’s fast paced telecommunications environment where faster equates to better, this method of signaling and outdated telephone equipment became far too slow. Dual-Tone Multi-Frequency DP and its associated technology has been almost entirely replaced by DTMF. DTMF uses an audible two-tone signal to indicate a single number. Two audible tones are placed on the line to indicate the number dialed; one higher frequency tone and one lower frequency tone (Table 2.1). Table 2.1 DTMF Tones High Frequency Tone In Hertz 1209 1336 1477 1633 Low 697 1 2 3 A Frequency 770 4 5 6 B Tone In 852 7 8 9 C Hertz 941 * 0 # D Telephone company computers decode the signals and make the desired connection, resulting in higher number-dialed to number-connected accuracy with much quicker call setup and connection time. Additionally, DTMF is humanly faster to dial than DP. Using DTMF, a telephone system can recognize a single digit tone in 50 milliseconds or less with a typical between-digit wait time of another 50 milliseconds or less. The maximum time needed to process a single DTMF digit is 100 milliseconds or approximately 1/10 of a second. For a DP call the pulse requires a 60-millisecond break and a 40 millisecond make for each dial pulse, or a total of 100 milliseconds per dial pulse. This becomes significant for high digits in a telephone number such as the extreme example of 999-999-9999. Nine pulses for every digit and a 700 millisecond wait time file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (6 of 34) [13/12/02 18:18:37]


between digits would result in a significantly longer dial time. For example: Dial Pulse Calculation (9 Pulses Per Digit) X (100 Millisecond Per Pulse) X (10 Digit Number) = 9 Seconds (700 Millisecond Inter-digit Wait Time) X (10 Digit Number – 1) = 6.3 Seconds Total Dial Pulse Time = 9 + 6.3 = 15.3 Seconds DTMF Calculation (10 Digit Number X 100 Milliseconds Per Number) = 1 Second Total DTMF Time = 1 Second, or less with improvements in computer processing.

Analog Network Components Let's take a high-level view of a few telephone company components needed to make a connection. We will take a more detailed look at analog components later in this text. It is best to start with the end-user instrument, the telephone. Telephone models comes in all shapes, sizes, colors, and prices and may be a basic push button wall unit or an integrated system complete with answering machine, stored number dial, speaker phone, and 900 MHz cordless operation. In some countries the telephone may be leased, but in the United States it is usually purchased by the consumer. Some U.S. based companies will even give away telephones in exchange for a fixed length service contract. The next component we need to examine is the connection from the end-user telephone to the telephone pole. This wire or underground cable running from the house to the telephone pole is called a “drop wire.” In a commercial business, there may also be a demarcation point, or point where personal responsibility for the telephone, line, and equipment ends, and the telephone company’s’ responsibility begins. The drop wire coming from the house may then be combined into several distribution cables called “feeder cables” for transmission, and then connected to the CO. Transmission mediums to the CO may be guided via either twisted-pair, coaxial cable, or fibre, or it may be unguided directional via microwave or satellite, or unguided omni-directional via broadcast or cellular radio. If guided transmission is used via twisted-pair the feeder cable will typically consist of from 4 to 3000 copper wire pairs varying in size from 16



American Wire Gauge (AWG) with a wire diameter of .05082 inches to 26 AWG with a diameter of .01594 inches. Each individual wire is wrapped in its own polyethylene or polyvinyl insulation. The CO is the building or buildings containing computerized telephone switching equipment for a predesignated geographical area of responsibility within the greater telephone network. A typical telephone network consists of a multitude of cross-linked and redundantly switched CO’s, sometimes referred to as nodes. Depending on your location in the world a telephone system node may contain one or more of the following telephone switching systems as shown in Table 2.2. Table 2.2 Telephone System Switches Switch Description Basic-NET3 Basic rate switches for United Kingdom and Europe Basic-5ESS

AT&T basic rate switches

Basic DMS100

NT DMS-100 basic rate switches

VN2

French VN2 ISDN switches

VN3

French VN3 ISDN switches

NTT

Japanese NTT ISDN switches

Basic-1TR6

German 1TR6 ISDN switches

Basic-NI1

National ISDN-1 switches

Basic-TS013 Australian TS013 switches If a site has more than a few centrally located users, they may make use of a specialized on-site switch called a PBX. A PBX is capable of connecting telephone sets to each other and to a PSTN. Telephones connected to the PBX have a unique extension number enabling intra-switch phone calls, bypassing the file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (8 of 34) [13/12/02 18:18:37]


need for an external telephone line. Incoming calls may be sent to an onsite operator or automatically routed using dialed number information provided by the CO switch. PBXs may also be connected to other PBXs over dedicated trunk lines. An alternative to the PBX is another specialized switch called a “key system”. Key systems are small telephone switches that allow multiple phone sets to share a number of external phone lines. Each line connected to a key system has its’ own unique number and can be dialed directly from an outside line. Key systems typically connect to standard phone lines from the local CO and provide the same service a standard telephone provides. Additional features are available depending on the sophistication of the key system controller. Individual telephone sets connect to the key system and have a key (button) for each external phone line. Customers desiring an outside line press the corresponding key to make the connection and receive a dial tone. Incoming calls are typically sent to all phones having a button for that external line, but may be directed to a single phone or group of phones. Multi-featured key systems often include transfer, speed-dial, memory-dial, park, hold, and paging features. Let’s recall our earlier discussion; for each node to successfully connect and terminate calls, they must communicate with each other and with customer equipment. We defined this communication process as "signaling." Signaling between and among switches can take place in-band through the same talk channel, or out-of-band through some communication path other than the talk channel. In today's telephone network, terminal equipment signaling is generally in-band, while signaling between telephone switches is often out-of-band for security and performance reasons. Each CO is responsible for managing all telephone calls within its’ area, either switching the call to the called party within the same exchange, or switching the call to a trunk and into another CO’s area. The side of the CO closest to the local subscriber is called the line-side interface or local loop. The side of the CO connecting to another CO is called the trunk-side interface. Loop-side interfaces are primarily responsible for battery feed, over-voltage protection, telephone set ringing, call supervision, signal coding, hybrid two-four wire conversion, and circuit testing. The battery feed, typically 48 volts DC, coming from the local loop provides power to the customer telephone set, telephone signaling, high AC impedance, and low DC resistance. Most US based telephone sets require from 10 to 23 file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (9 of 34) [13/12/02 18:18:37]


milliamps for operation with 400 ohms of resistance. However, resistance in overseas telephones can and often does vary considerably, ranging from 380 to 800 ohms. Higher or lower resistance demands higher or lower voltages for proper telephone transmitter operation. Over-voltage protection protects the people using the telephone as well as the equipment, from transient voltages due to short circuits, lightning surges, and electrical power lines. In addition to over-voltage protection the CO provides the ringing signal to the subscribers’ telephone as an alert for incoming calls. The ringing signal, typically 90 volts rms at 20Hz, is provided after switching completes the connection. Should the connection not go through, the telephone goes off-hook, or if the call goes through but the called party hangs up, the CO must sense the absence or presence of current flow and take the appropriate supervisory action. Loop & Ground Start There are two basic methods for detecting subscriber off-hook and initiating a series called “busy notification” or billing tasks, they are “loop start” lines and “ground start” lines. Loop start lines signal off-hook by completing a circuit at the telephone. When the subscriber lifts the handset, current flows from the loopside battery through the closed switchhook, contacts and energizes the line relay. A set of line relay contacts close to signal that the subscriber desires service. A CO switch called a “line-finder” provides dial tone and connects the subscriber into CO switching equipment and onto an available circuit. Used on local loops to connect PBXs to the CO, ground start lines are in effect partially operational at all times. Current flows through one-half of the line relay as a result of grounding the ring-side path. When a PBX needs connectivity the CO line-finder provides dial tone and connectivity to CO switching equipment. When a dial tone is detected the ground start contact is opened and the remainder of the line is instantly activated. Dialing supervision is accomplished through the use of three relays; one fast acting and two slower acting relays. When dial pulse signaling is used, it can be very hard to distinguish a dial pulse signal break and an on-hook situation. To overcome this challenge, the fast acting relay, which we will call Alpha, energizes when the circuit is closed by the receiver going off-hook. Alpha then mimics each dial pulse by opening or closing as the dial pulse contacts open and close the circuit. The second relay, which we will call Bravo, energizes when file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (10 of 34) [13/12/02 18:18:37]


Alpha energizes but is slow to release after the pulse. In fact the Bravo relay does not release unless the telephone goes on-hook and the Alpha relay has been released for 200 milliseconds. This is how the CO knows when a conversation has ended and the receiver has been placed into the cradle. The last relay, which we will call Charlie, energizes when Alpha and Bravo energize and remains energized as dial pulses are generated. The Charlie relay is used to detect the end of a dial pulse train and releases only when Alpha remains energized for 200 milliseconds. When dialing is finished the Alpha relay remains energized for 200 milliseconds. The Charlie relay then releases, indicating that the pulse dial for a single digit is complete. When the call goes through, call answer supervision disconnects the tip ring current (ringing current) and reverses polarity of the wire pair. Call billing typically begins at call “cut through “ or connection to the called party. Because a large portion of the telephone network remains an analog system some signals must be converted from analog to digital for digital transmission. Voice signals may be coded into serial digital codes for digital transmission then decoded on the distant end. This function is performed by something called a “codec.” To convert an analog code into a digital code a range of analog voltage levels is divided into individually discrete signal levels. Each level is represented by a unique 8 bit binary code. The original analog signal is sampled for signal levels at precise, regular intervals. The code produced comes out of the codec in parallel each time the input analog signal is sampled. Each signal sample is then converted to its’ corresponding 8 bit code. Parallel codes are converted into serial form and then transmitted to the distant end. The receiving converter outputs a voltage level for each code received. The voltage level remains constant for each sample period and the resulting stepped digital square wave is passed through an amplifier and filter to reproduce the original analog signal. Voice Encoding Standards & Techniques Speech codecs, sometimes called voice encoders or vocoders if source codecs are used, can be divided into three basic classes: waveform, source, and hybrid. Waveform codecs are older, operationally used high bit rates and provide very good quality speech reproduction. Source codecs operate at very low bit rates but tend to produce speech that sounds artificial or tinny. Hybrid codecs use techniques from both source and waveform coding, operate at intermediate bit rates, and provide good quality speech. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (11 of 34) [13/12/02 18:18:37]


Codecs operate by modeling a segment of the speech waveform on the order of 20 ms. Speech model parameters are then estimated, quantized, coded, and transmitted over a communications channel. The receiver then decodes the transmitted values and reconstructs synthesized speech. Waveform Encoding Pulse Code Modulation (PCM) codecs are the simplest form of waveform codecs. This approach to voice encoding simply samples and quantizes the input waveform. Narrowband speech is typically sampled 8000 (8KHz) times per second and each speech sample is quantized. If linear quantization is used then about 12 bits per sample are needed, giving a bit rate of about 96 kbps. However, this can be easily reduced by using non-linear quantization. For coding speech it was found that with non-linear quantization at 8 bits per sample was sufficient for resulting speech quality nearly indistinguishable from the original signal. That is to say the typical human ear could not distinguish a noticeable difference. The preceding example results in a bit rate of 64 kbps. Two non-linear PCM codecs were standardized in the 1960s: u-law used in the United States, and A-law used in Europe. Because of their simplicity, excellent quality, and low delay, codecs using these algorithms are still widely used today. One example of PCM use is the “.au” audio file format used to transport sounds via the Web. These audio files are PCM encoded files. PCM codecs are simple, introduce very little delay, and reproduce high quality speech. The only drawback to PCM codecs is that they require a relatively high bit rate and are highly susceptible to channel or line errors. Other waveform approaches to speech coding predict the value of the next sample from previous samples. This approach works as a result of repeated vocal patterns present in each speech sample. If predictions are correct then error signals between predicted and actual samples will have lower variance than the original speech samples and the error signal may be quantized with fewer bits than the original speech signal. Differential Pulse Code Modulation (DPCM) uses this technique to quantize the difference between original and predicted signals. Improvements to the preceding codec technique can be made if the algorithm can adapt to match the characteristics of the coded speech. Adaptive Differential PCM (ADPCM) codecs use this approach resulting in a 32 kbps transmission rate and providing speech quality very near the 64 kbps PCM codecs. ADPCM file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (12 of 34) [13/12/02 18:18:37]


codecs operating at 16,24 and 40 kbps are also now in use. Source Encoding Source codecs operate using a model of source signal generation extracting the model parameters from the signal being coded. Model parameters are then transmitted to the decoder on the receiving end. Sometimes called vocoders, source codecs represent the vocal tract as a time-varying filter excited with white noise source for unvoiced speech segments, or a series of pulses separated by the pitch period for vocalized speech. Information sent to the decoder includes filter specification, a voiced/unvoiced flag, the necessary variance of the excitation signal, and the pitch period for voiced speech. This information is continually updated every 10-20 ms following the non-stationary nature of speech. Vocoders operate at 2.4 kbps or below, and produce acceptable but far from natural speech. Increasing the bit rate much beyond 2.4 kbps is not possible due to limitations in the coder's performance and the simplified source signal model. Vocoders are typically found in military applications where a very low bit rate is needed to support signal encryption. The quality of speech generated using analog to digital encoding is subjective. Which means that the reaction you get will vary depending on individual likes, dislikes, and what a person considers to be normal. To help quantify the quality of a given technique, the Mean Opinion Score (MOS) scale was developed. To compile the MOS numbers, listeners listen to various speech patterns sent through each compression technique. The test listeners then rate the quality of the sound on a scale of 1 to 5, with 5 being the best. The results are averaged to produce the Mean Opinion Score. The Table 2.3 includes the current ITU encoding standard compression techniques and each techniques’ bit rate, MOS, coding delay and the processing power required for compression. Table 2.3 Voice Encoding Coding ITU-T Bit Rate OS Standard ACELP MP-MLQ CSACELP

G.723.1 G.723.1 G.729a

5.3 kbps 3.65 6.3 kbps 3.9 8 kbps 3.7

MIPS

16 16 10.5

Frame Coding size Delay (msec) (msec) 30 30 30 30 10 10



CSG.729 8 kbps 3.92 20 10 10 ACELP LD-CELP G.728 16 kbps 3.61 33 .625 3-5 ADPCM G.726 32 kbps 3.85 14 .125 1 PCM G.711 64 kbps 4.1 .34 .125 .75 Cisco’s voice enabled routers currently support G.711, G.729, and G.729a coding schemes. G.723.1 support is planned. PCM uses the most bandwidth; yet receives the best MOS rating, uses the least amount of processing power, and introduces the least amount of latency. This has made PCM inexpensive to deploy and highly effective in transporting voice traffic over long distance. By contrast, CS-ACELP provides significant bandwidth savings at the expense of increased processing requirements, increased latency, and a lower MOS rating. Conventionally the local CO is a two-wire switch permitting conversations in both directions over the same pair of wires. When a signal needs to be transmitted over long distances the signal must be amplified and transmitted over a four-wire configuration. Two to four-wire conversion is performed by a hybrid transformer designed to permit full-duplex operation. Four-wire circuits have two pairs of wires for simultaneous conversations in both directions. Physical separation of transmitter and receiver are needed to process digital and voice, and to permit amplifiers to increase signal level. In addition to two-to-four wire conversion the CO must conduct loop-side testing. Loop-side testing requires access from the local loop to the CO switch to enable fault detection and permit corrective and preventative system maintenance. Designed to handle 10,000 telephones or more, a CO is typically identified by the first three numbers of a 7 digit United States telephone number. For example 365-XXXX might indicate a CO in Wake County, North Carolina. Should the call require switching between two COs it would use a line called a toll trunk line. The CO is actually designed to handle only a portion of the calls it receives. The design of a CO is typically based on the amount of projected or measured traffic received at peak hours from 10:00AM to 11:00AM and 2:00PM to 3:00PM. Multiple COs are connected to provide redundancy and reliability. When all of an individual COs' facilities are in use, the CO is said to be processing a block of calls or “blocking.” The grade of service provided by the CO is the proportion of blocked calls to attempted calls expressed as a percentage. Most telephone switching equipment is designed to handle file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (14 of 34) [13/12/02 18:18:37]


individual telephone calls lasting approximately 3 minutes. (Dial-up Internet access really puts a heavy load on telephone company switches as a result of extended connectivity.) Typical days set aside for blocking are Christmas, Thanksgiving, Fathers Day, and Mothers Day.

Figure 2.2 Telephone system components. As viewed in Figure 2.2 the typical analog telephone network consists of the following components: •

Telephone handsets

•

Drop wires

•

Local loops

• Central Office consisting of electronic switch system (ESS), analog and digital carrier system, dc voltage generation units, and billing, monitoring and line maintenance computer systems. •

Toll Trunks



Each telephone CO in North America is described according to an office class and name. Table 2.4 describes a common telephone network hierarchy: Table 2.4 Telephone Network Exchange Class Hierarchy Class Name Regional Center Sectional Center 3 Primary Center 4C Toll Center 4P Toll Point 4X Intermediate Point End Office End Office With Remote Switching Remote Switching Unit Long distance switching is normally performed by class 1, 2, 3, and 4 with class 1 holding the top most position of the telephone switching tree. A mixture of class 2,3,4, and 5 may occupy layer 2 of the hierarchy with class 5 and class 5 variations on the bottom of the tree. Analog Signal Composition Analog signals are continuous varying electrical waves having amplitude, frequency, bandwidth, phase, and period as characteristics. Amplitude measures the loudness of the signal in decibels. It may also be thought of as the level of the signal. Signal level is usually expressed in terms of the power the signal delivers to the data load. For example, the power delivered to a balanced pair transmission line could be expressed in the following equation: Pload = es^2/Z Where Pload = Es = Z =

Power in watts Signal level in volts Independence in ohms

Each household telephone in the United States requires the use of a single pair of copper wires. A single pair of copper telephone wires has an impedance of 400 ohms. Impedance in an alternating current (AC) circuit is similar to resistance in a direct current (DC) circuit. Signal level in telephone circuits is measured in file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (16 of 34) [13/12/02 18:18:37]


terms of 1 milliwatt of power to the load. If Pload = 1 milliwatt (0.001 watt) and Z = 400 ohms then: 1mW = es^2/400 ohms 400 X 1 X 10^-3 = es^2 0.4 = es^2 0.633 = es A signal level of .633 volts applied across 400 ohms of resistance will produce 1 milliwatt of power. Too much power on the line can cause a single voice signal to interfere with other conversations traveling on the same wire, or wires in close proximity. This type of interference is called “crosstalk.” The reverse of this problem or loss of power on a line during a call is called “attenuation.” Frequency is essentially the number of vibrations per second. Typically diagrammed as a sine wave, each complete wave is called a cycle. Frequencies are measured in hertz. The human ear can hear frequencies ranging from 20Hz to 15,000Hz. Speech has a frequency ranging from 300Hz to 15,000Hz. The PSTN supporting voice transmission operates in the 300 to 3300Hz frequency range. Bandwidth is the difference between the upper level and lower level frequencies. All transmission mediums have limited frequency bandwidth. These limitations are due to the physical properties of the medium, or artificial limitations placed on the medium to prevent crosstalk or interference from other signal sources. Telephone signal bandwidth may be calculated by taking the upper frequency range then subtracting the lower frequency range. The result will be typical telephone bandwidth. For example to calculate telephone bandwidth: 3300Hz – 300Hz = 3000Hz A gentleman by the name of Claude Shannon developed a formula we can use to calculate the maximum capacity of a transmission channel, limited by bandwidth and random noise: C = W x Log2[1 + (S/N)]bits per second Where: C = Capacity S = Power of the signal in watts through the channel N = Power of the noise in watts out of the channel file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (17 of 34) [13/12/02 18:18:37]


W = Bandwidth of the channel in Hertz Using this formula one can calculate the “theoretical” limit to binary transmission on a single channel. This is thought of as a theoretical limit due to the formulas’ inability to incorporate other significant real-world variables like transmission medium characteristics, distance, and software and hardware enhancements. This formula should be used only as a rough estimate of the capacity of the designated channel due to the variables not taken into account by Shannon’s formula. Let’s take a look at an example: Given: P = .0001 Watts W = 3000 Hertz N = .0000004 Watts 3000 x Log2[1 + (.0001/.0000004) = 24,000 Bits Per Second The PSTN is designed to use frequencies as high as 4000Hz but only uses up to 3000Hz to provide a buffer or guard band to help eliminate interference from other signals. Signal phase is the relative position of the sine wave measured in degrees. A phase shift occurs when a sine wave breaks in the middle of its phase and starts its cycle again. Phase shifts are used more frequently in data encoding algorithms for data transmission than for voice transmission. A period is the time a signal takes to complete one cycle. PSTNs use analog-switched lines to provide voice communications. Data communication over analog lines has limited transmission speed because of the narrow bandwidth of voice lines. A modem is required to convert digital data signals generated by the computer into analog signals when transmitting data over telephone lines. Analog signals transmitted over long distances are amplified, often distorting and introducing errors into the original data value. When analog data is converted into digital data it can be transmitted with the use of digital signals faster and without distortion. Discreet and precise samples of binary data make up the content of the payload. Digital data is precise, but does not have the informational range available in analog transmission. During transmission of data or voice signals across hard-wired copper telephone wires, the transmission may become corrupted by “noise,” like unwanted electrical or electromagnetic energy that degrades the quality of signal and interleaved data. External noise may be picked up from household or industrial



electrical appliances in close proximity to the circuit, from high voltage electrical transformers, from the atmosphere, and even from outer space where noise may be generated by solar storms or other magnetic phenomena. Normally this noise is of little or no consequence and the system must adjust. However, during severe thunderstorms, or in locations where many electrical appliances are in use, external noise can adversely affect communications to the point of making a copper circuit unmanageable. Internet data transfers can be considerably slowed by noise and numerous data retransmissions. The system must also adjust the data transfer rate to compensate for line errors and cyclic redundancy check (CRC) mismatches introduced by external noise. Noise normally has very little impact on voice conversations often resulting in a rushing or air-like hissing sound before, during, and after the conversation. Noise is a more significant problem in wireless systems than in hard-wired systems. In general, noise originating from outside the system is inversely proportional to the frequency, and directly proportional to the wavelength. In other words, at a low frequency such as 300KHz, atmospheric and electrical noise are much more severe than at a high frequency like 700MHz. Noise generated inside wireless receivers, known as internal noise, is less dependent on frequency. Engineers are more concerned about internal noise at high frequencies than at low frequencies because the less external noise there is, the more significant the internal noise becomes. Telecommunications engineers implement innovative improvements to the voice and data to noise ratio, by constantly developing new materials, components, and designs to keep pace with the explosion in household, consumer, and commercial automation. The traditional, straightforward method to reduce transmission noise has been to minimize signal bandwidth. The less bandwidth a signal occupies the less noise is passed. The obvious downside of this approach is that reducing the bandwidth limits the maximum speed at which data can be delivered, and as we know, consumers are demanding faster transmissions not slower ones. A better approach for minimizing noise is to make use of digital signal processing (DSP), a topic for later discussion. Cabling Let’s consider this scenario: It’s time to upgrade your current analog voice system, or you’ve been handed a major project involving voice transmission that involves a state of the art automated assembly plant. A major question to ask file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (19 of 34) [13/12/02 18:18:37]


yourself is: “What medium should I use: shielded or unshielded coaxial cable, twisted-pair copper, or fibre optic?” Lets look at copper cable. The efficiency of copper has a great deal to do with the length of the cable run. The longer the cable run, the more likely signal distortion will occur. The shorter the cable run the better the signal quality. Signal distortion across copper cabling may be caused by: •

attenuation - loss of amplitude or signal strength

•

capacitance - the variation in the amount of energy stored in the wire

•

delay distortion - resistance, which may cause frame sequencing problems

•

noise - external sounds and/or transmissions on adjacent lines

Unshielded twisted pair (UTP) copper wiring is by far the most popular and least expensive copper cabling option. Copper UTP wiring contains eight color-coded conductors (four twisted pairs of copper wires). It offers greatly increased bandwidth compared with outdated quad wiring often found in old installations. UTP cable is roughly 3/16 inch in diameter, inexpensive, easily pulled through conduit and overhead trays. Category 5 (Cat 5) is the current standard, but will soon be supplanted by even higher-speed versions, known as Category 5E and Category 6. Cat 5 has an approved bandwidth of 100MHz and Cat 6 will likely accommodate approximately 250MHz. Remember, increased bandwidth equates to increased speed. Cat 6 wiring, with encoding, will be able to carry at least 1 gigabit per second or roughly 50,000 text pages per second. When installing Cat 5 wiring use these general guidelines: •

Apply 25 to 40 pounds of pull when installing in conduit or plenum.

• Separate data and power cables by at least 6 inches. When it’s necessary to cross data and power cables cross them at 90-degree angles. •

Strip cable sheathing no further than needed or a maximum of 1 ¼ inches.

•

Untwist wire a maximum of ½ inch.



•

Bend wiring a maximum radius of 1 inch.

These guidelines are just general guidelines. If you need additional information surf the web using www.hotbot.com or www.lycos.com for information on EIA/TIA 568A cabling installation standards. Cable pathways including underground routes, conduits and tray ways, access flooring and equipment closets are covered in EIA/TIA 569. If your project calls for installation of telecommunications cabling in areas with close proximity to electro-mechanical or high voltage interference, similar to those normally found on the floor of a factory or assembly plant, fibre optic transmission medium may be used to overcome interference from this type of noise. Fibre optic cabling uses a light-emitting diode (LED) or laser-generated light for voice and data transmission. Fibre optic medium is an excellent highspeed medium choice, and the installation cost per foot continues to drop. Fibre optic cabling also has very low signal loss compared to conventional twisted pair or coaxial cabling. Low signal loss permits greater separation between signal repeaters resulting in lower equipment cost. Optical fibre does not radiate electrical energy, is non-inductive, and does not conduct electricity. Fibre is also free from crosstalk, which may plague twisted-pair installations, and is far more secure since it is not easily tapped without a noticeable drop in signal. In a local area fibre installation multimode (62.5/125 um) fibre optic cable could be used with SC duplex. Beyond 200m, a mixture of single mode (9/125 um) and multimode should be considered. Have you ever seen the popular “Hear a pin drop…” commercial and wondered how that works? Let’s take a quick look. Optical fibres guide light rays through the plastic or glass fibre optic material. The speed at which light is propagated through a fibre is dependent on the type of material used. The more pure and exact the material the faster the propagation. This is called refraction. Refraction can be measured using Snell’s Law which states: “The ratio of the sine of the angle of incidence to the sine of refraction is equal to the ratio of the propagation velocities of the wave, in the two respective media.” This is equal to a constant which is the ratio of the refractive index of the second medium to that of the first: sin A1/sin A2 = V1/V2 = K = n2/n1



Where: A1 and A2 are the angles of incidence and refraction, respectively; V1 and V2 are the velocities of propagation of the wave in the two media; and n1 and n2 are the indices of refraction of the two media. Let’s put this law in more simple and usable terms; light introduced into a fibre optic cable will be totally contained within the core of the cable when the angle of incidence is greater than the critical angle. An optical fibre is a di-electric wave-guide consisting of core, cladding, and sheath. A light source (usually a light emitting diode or laser) emits light at multiple angles relative to the core of the fibre. The angle at which light enters an optical fibre is called its mode of propagation. Therefore the size of the fibre optic core has direct correlation to whether light rays (voice or data signals) are reflected back at an angle necessary to permit the rays to remain within the fibre and bounce toward their destination, or in some cases be absorbed by the cladding. For fibre designed to carry light in several modes of propagation (multimode) the diameter of the core must be several times the wavelength of the light to be carried and the cladding thickness greater than the radius of the core. A typical multi-mode fibre will be 50 to 100 lm in diameter. Rays traveling in a multi-mode fibre bounce at different angles and arrive at the end of the fibre at different times. An effect called “modal display spreading” may occur as light rays leaving the fibre cross or cancel each other out. Alternatively a single-mode fibre will contain a core only a few times the wavelength of the transmitted light waves. Only one light ray will be carried at a time with none of the previously defined modal display spreading. In addition to this difference, single-mode fibres are prone to permit a large fraction (20%) of the light to travel in the cladding near the core while multi-mode fibres have most of the light travel in the core of the fibre. This is worth mentioning because a significant increase (doubling) in light traveling in a single-mode cable also significantly increases the percentage (50%) of light traveling in the cladding. A PSTN will use a combination of twisted pair and fibre optic cabling within its system to transmit voice signals. For IT Professionals Only Cabling Standards and References The PC revolution put a computer, and sometimes two, on every desk turning each node into a sender and receiver of digitized information. Corporate



productivity, and in some cases survivability, is forever tied to the efficiency of this information flow. As you’ve seen, some of the limitations found in our current analog telephone system are a direct result of the cabling found there. Demand for greater bandwidth and higher speeds that support delay-sensitive traffic (like voice) has also never been greater. Requests for 100 and 155 Mbps to the desktop are commonplace, however, because of out-dated technology the consumers don’t always get what they ask for. Selecting the proper transmission medium is imperative today. To do that you will need access to the following cabling standards and references: • ANSI/EIA/TIA 568 A: Commercial building telecommunication wiring standard for building and campus applications up to 10 million square feet and up to 50,000 users. USA only. •

IS 11801: Generic customer premise cabling, internationally.

• ANSI/TIA/EIA 569: Commercial building standard for telecommunication pathways and spaces • ANSI/TIA/EIA 606: Administration standard for commercial buildings telecommunication infrastructure. • ANSI/TIA/EIA 607: Commercial building grounding and bonding requirements for telecommunication. •

BICSI (Building Industry Consulting Service International).

Analog Signaling Signaling refers to the specific signals transmitted over telephone circuits that are used to pass line control information, user data, and voice conversations. In this section we will discuss three different types of signaling: Direct Current (DC) Signaling, Tone Signaling, and Common Channel Interoffice Signaling. DC signaling uses an existing voltage, a drop in voltage or no voltage condition, or change in voltage polarity (+ or -) to indicate telephone on-hook, off-hook, dial pulse, or some other connection status. DC circuits typically have one of two states, on or off.



On the PSTN local loop, recall that an open circuit with no current flowing indicates an on-hook condition (telephone handset placed in the cradle). Offhook (telephone receiver off the cradle) is indicated by a closed circuit with current continuously flowing. Early telephone systems using dial pulse technology periodically encountered problems distinguishing off-hook conditions from delayed dial pulses. COs use reverse battery DC signaling among local and remote CO exchanges to indicate switched circuit status. The area CO closest to the party requesting the call selects an idle toll trunk circuit. A polarity change on the trunk indicates to the local CO originating the connection that the called phone is on-hook and ringing, or is off-hook and busy. The distant end CO completes the operation by reversing the voltage polarity to indicate the called party has answered. For twoway switch-to-switch or switch-to-network connections across long inter-CO and short-haul toll trunks a similar signaling method is used called E&M. E&M uses an extra pair of wires in the local and distant end trunk lines with one designated as “E lead” and one designated as “M lead.” The E lead receives signals and the M lead transmits signals. DC and E&M signaling are not as prevalent in carrier networks as they once were but can still be found on inter-PBX tie-trunks. E&M signaling is commonly called "Ear & Mouth" or more correctly “Earth and Magnet.” The earth portion of this moniker represents electrical ground and the magnet portion represents the electromagnet used to generate tone in the telephone handset. E&M signaling provides signaling states indicating on-hook and off-hook conditions, decreasing the likelihood a two-way trunk is seized simultaneously at both ends. The telephony term for this condition is “glare.” There are five different types of E&M signaling each using a different method of indicating on-hook and off-hook conditions between the PBX and CO switch (Table 2.2). E&M signaling is supported in both two and four wire implementations. Cisco currently supports all five E&M signaling types in its VoIP products. E&M signaling defines a signaling side and a trunking side for each connection. The PBX is the signaling side, while the trunking side is the telco, channel bank or voice enabled router. The signaling side sends its on-hook/off-hook indicators over the M lead and the trunking side sends its on-hook/off-hook indicators over the E lead. This provides each side of the link with a dedicated signaling path. E&M uses 6 to 8 pins on an RJ-48 jack depending on the type of E&M signaling file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (24 of 34) [13/12/02 18:18:37]


used. Off-hook and incoming calls are signaled using one of the five types of E&M signaling. E&M interfaces typically don’t use a dial tone but instead use immediate start, wink start, and delay start signaling to indicate off-hook or incoming calls. Table 2.5 Five Different Types of E&M Signaling Type 1: E&M type I signaling is popular in the United States. During inactivity, the E lead should be open and the M lead should be connected to ground. A PBX indicates an off-hook condition by connecting the M lead to the battery. The router or CO side indicates an offhook condition by connecting the E lead to ground. Type 2: E&M type II signaling is also used in the United States. During inactivity, both the E and M lead should be open. A PBX indicates an off-hook condition by connecting the M lead to the SB lead which is connected to the battery at the CO side. The router or CO side indicates an off-hook condition by connecting the E lead to SG, which is connected ground at the PBX side. Type II signaling is symmetrical and allows for signaling nodes to be connected back-to-back using a crossover cable.



Type 3:

E&M type III signaling is not commonly used in modern systems. During inactivity, the E lead is open and the M lead is set to ground by connecting it to the SG lead from the CO. A PBX indicates an off-hook condition by disconnecting the M lead from the SG lead and connecting it to the SB lead from the CO. The router or CO side indicates an off-hook condition by connecting the E-lead to ground. Type 4: E&M type IV signaling is not currently supported by Cisco’s VoIP router interfaces. Type 5: E&M type V signaling is used in the United States and is common in Europe. During inactivity, both the E and M lead should be open. A PBX indicates an off-hook condition by connecting the M lead to ground. The router or CO side indicates an off-hook condition by connecting the E lead to ground. Type V signaling is symmetrical and allows for back-to-back connections using a crossover cable. Use of the extra wire pair enables both local and distant ends to signal on and offhook conditions. With this approach, control signals may be sent in both directions without interfering with control signals going in the opposite direction. Noise problems with common ground may also be avoided by use of two wires for each single signal. E&M signaling states are displayed in Table 2.6. Table 2.6 E&M Signaling State E Lead: Inbound On-Hook Open Off-Hook Ground

M Lead: Outbound Ground Battery Voltage



Signaling rate is the number of times per second a signal on a circuit changes amplitude, frequency, or phase. Tone signaling uses single frequency or multiple frequency tones to indicate control and line status. The CO sends a continuous or intermittent tone or tones to the calling telephone to indicate call status. To indicate a functioning line in the US the CO sends a continuous tone called a dial tone by combining a 350Hz tone with a 440Hz tone. To indicate a busy signal or off-hook condition the CO sends a 480Hz tone combined with a 620Hz tone in intermittent ½ second increments. If the receiver remains off-hook for more than a few minutes the busy signal changes to a much louder 400HZ, 2060Hz, 2450Hz, and 2600Hz combination tone. Table 2.7 shows Call Progress Tones. Table 2.7 Call Progress Tones TONE FREQUENCY Dial 350 + 440 Busy 480 + 620 Normal Ringback 440 + 480 PBX Ringback 440 + 480 Toll Congestion 480 + 620 Local Call Reorder 480 + 620 Receiver Off-Hook 1400 + 2060 + 2450 + 2600 Number Doesn’t 200 to 400 Exist

ON TIME Continuous .5 Seconds 2 Seconds 1 Seconds .2 Seconds .3 Seconds .1 Seconds

OFF TIME .5 Seconds 4 Seconds 3 Seconds .3 Seconds .2 Seconds .1 Seconds

Continuous Frequency Modulated at 1Hz. COs commonly use either in-band or out-of-band tone signaling to indicate signal status. In-band signaling most commonly uses a 2600Hz tone and out-ofband signaling uses a 3700Hz tone. E&M signals use a single frequency tone for transmission on carrier based systems. A tone would indicate on-hook and a lack of tone would indicate off-hook. If multi-frequency tone signaling is used frequencies are used in pairs between toll facilities to indicate numbers 0 through 9 and additional control functions. Multi-Frequency tones include 700Hz, 900Hz, 1100Hz, 1300Hz, 1500Hz, and 1700Hz. This type of signaling is rapidly being replaced due to its susceptibility to misuse by hackers, crackers, and phone “phreaks.” Perhaps the most famous case of telephone system misuse can be attributed to a gentleman by the code name of “Captain Crunch.”



AT&T formerly used a 2600 hertz (cycles per second) steady signal to indicate a telephone line was not currently in use. No signal on a line could be interpreted to indicate a pause in a voice conversation or a line not in use, so AT&T elected to use a steady 2600Hz signal on all its free lines. It didn’t take long for this information to make its way to people determined to circumvent AT&T call charges. People soon developed a way to use a whistle or other device to generate a 2600Hz tone on a line that was already in use, making it possible to call anywhere in the world on the line without ever being charged. Cracking the phone system became a hobby for some in the mostly under-20 set who came to be known as phreaks. In the 1960s Captain Crunch breakfast cereal included a small whistle as a freebie for kids buying the cereal. By coincidence the whistle was capable of generating a 2600Hz signal. By dialing a number and then blowing the whistle you could fool the phone company into thinking the line was not being used while you made a free call to any destination in the world. Long-distance companies today use Signaling System 7 (SS7) putting all signals about channels on a separate (out of band) signaling channel making it more difficult to break into the phone system. Common channel interoffice signaling (CCIS) performs call control and switching on lines independent of voice lines. Operating on these independent channels, CCIS consists of a terminal access circuit or TAC, signaling terminal, modem, and one or more signal transfer points (STP) dedicated to a signal switching control computer. CCIS has several distinct advantages over older same voice channel call control: •

Higher signaling speed.

•

Full duplex control even while conversations are in progress.

• Protection from accidental call termination as a result of misinterpreted control tones. • Increased security by eliminating the possibility of an unauthorized in-band control signaling.

Analog-To-Digital Conversion file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (28 of 34) [13/12/02 18:18:37]


Why can’t a digital signal from a computer be transmitted over a telephone line without turning it into an analog signal? As stated earlier in this section, voice channel bandwidth ranges from 300Hz to 3400Hz. Digital signals generated by computers are uni-polar, that is they have a range of 0 to 1; either on or off, 0 or 1. Also, the change from 0 to 1 and back again is very fast, resulting in high frequency signals. As a result, computers generate both very low frequencies, below 300Hz, and very high frequencies, above 3300Hz. The typical voice channel will simply not handle the frequency range needed to transmit digitized computer data. To overcome this problem the digital signal must be transformed into a signal compatible with the channel capacity (bandwidth) of a voice circuit. The methodology used to transform the signal from digital to analog is called “modulation.” Modulation is the process of changing the carrier wave in response to a change in the modulating signal within the 300Hz to 3400Hz voice circuit frequency range. There are three common methods used by modems to modulate a digital signal: amplitude, frequency, and phase modulation. The word MODEM is an acronym for MOdulator-DEModulator. Modems accept digital data from a computer and convert it to a modulated analog waveform for transmission over a normal analog phone line. The flip-side of this operation is the modem accepts the modulated analog wave from the telephone line, converts it into a digital form then passes it to a computer. Amplitude modulation uses a full sine wave or signal peak to a pre-designated high to indicate a 1, and a drop in the sine wave or return in the wave to a flat or null signal to indicate a 0. Amplitude modulation is actually seldom used by itself for data transfers due to amplitude transmission sensitivity to electrical noise and interference. Frequency modulation uses a change in the frequency with which the signal is repeated (measured in cycles per second) to indicate a 0 or 1. A separate lower frequency value might indicate a 0 and another higher frequency would indicate a 1. This technique is called Frequency Shift Keying (FSK), or if used in the voice band, it is called Audio Frequency Shift Keying (AFSK). The last modulation technique, phase modulation, uses a shift in phase of the signal in reference to another wave of the same frequency, either rising or falling, to indicate a 1. The phase of the signal, however, is not shifted for 0. The phase of the wave is measured relative to the phase of the wave during the previous signal registering a 1. Since most circuits available today are voice grade, considerable time, effort, and file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (29 of 34) [13/12/02 18:18:37]


money has gone into developing modems, units designed to modulate digital signals into analog signals and demodulate analog signals into digital signals, at ever increasing rates. The 1s and 0s in a computer’s data stream coming from the data terminal equipment (DTE) are converted to analog sine waveforms with frequencies between 300Hz and 3000Hz. As stated earlier, voice grade circuits are limited in range from 300Hz to 3000Hz. The maximum signaling rate is fixed by the channel bandwidth and the signal to noise ratio. This means a voice grade signal will have a maximum baud rate of approximately 2400 baud. To speed things up we need to stuff more bits into a single signal or, to state this another way, “transmit multiple bits per baud.” Modems Most of the modems in use today run at 28,800 or 33,600 bits per second (bps) (V.34) speeds. Under ideal conditions these modems will transmit and receive data at about 28,800 or 33,600 bps. The newer 56K modems (X2, K56, or V.90) transmit data at approximately 33,600 bps, and receive data at approximately 50,000 bps. Finalized in the spring of 1995, the original V.34 standard provided guidelines for transmission speeds up to 28,000 bps. An improved version of the V.34 appeared in the fall of 1996 and added 31,200 bps and 33,600 bps speeds. The speeds are negotiated and enabled at the beginning of a call. Paradyne, AT&T, 3Com, Penril, and Motorola were among the first selling 33.6 modems, but US Robotics got the jump on the other manufacturers by adding 33.6 capability to their V.34 Courier and Sportster modem lines. Because these modems make extensive use of data compression, they achieve throughputs of 2 or more times those rates on compressible files. A 28,800 or 33,600 bits per second (bps) modem can send data over a phone line up to fourteen times faster than a 2400 bps modem, and a 56K modem sends over twenty times faster. Coupled with built-in data compression, high-speed modems can compress ordinary text data by a ratio of 2:1, and some types of data by a ratio of up to 4:1. The result is throughput 25 to 50 times greater than a 2400 bps modem. What do the terms baud, bps, bytes, and characters per second (cps) really mean? Named after a 19th century French inventor by the name of Baudot, baud rate originally referred to the speed a telegrapher could send Morse Code. This meaning changed over time. Baud rate is the number of high/low wave shifts made on a line per second. A bit is a single piece of binary data represented by a 0 or a 1, a nibble is the lower four bits of an 8 bit byte, and a byte (the number of file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (30 of 34) [13/12/02 18:18:37]


bits needed to represent one written character) is a full 8 bits. Incorrectly referred to as 28,800 baud modems, V.34 modems transmit coded symbols in addition to high low wave patterns to represent transmitted data bit patterns. V.34 modems use symbols which convey approximately 9 bits each, achieving a data transfer rate of approximately 28,800 bps. All of this using a symbol transfer rate of about 3200 symbols per second. The proper term to use when discussing modem speeds is bps. As previously stated a normal byte contains 8 bits, however start and stop bits required for an asynchronous data stream are added by the sending serial port's Universal Asynchronous Receiver- Transmitter (UART), and removed by the receiving UART. Newer modems improved on this transmission method with the appearance of V.42. Using V.42 error control the start and stop bits are stripped away and the data is transmitted synchronously. However, V.42 also adds on transmission and strips out on receipt error control check bytes for each block of characters sent. Your actual throughput can be calculated by taking the transmission rate and dividing it by the number of bits per character. The resulting output will be reflected in cps. The following example calculates throughput given a 28,800 bps transmission rate: 28,800 bps / 8 bits per character = 3600 cps Actually this calculation is a rough estimate. Overhead caused by HDLC packet framing used in V.42 reduces the transmission rate by approximately 5%. Under ideal conditions, a good ball park estimate for throughput will fall between 3300 and 3400 cps.. Throughput can be further improved using data compression. This will vary depending on the compressibility of the data, line quality, and a number of other factors. There is a difference between the line speed at which your modem talks to another modem (DCE speed), and the speed your modem communicates with your PC, (DTE speed). Modern high-speed modems have the ability to compress the data they transmit. By using different compression algorithms the modem transmits fewer bytes than it receives from the computer. To keep the modem sending data at the maximum rate, data must be transmitted to it at a higher rate. To do this, set the DTE speed on the computer higher to the maximum modem connection rate. If DTE speed is set at speeds lower than the modems’ connect



speed the modem will essentially be waiting for data to arrive from the computer so it can then be transmitted. The result will be lower then possible throughput and a slow down in the users’ voice and data system. High-speed modems generally aren’t able to compress files which are already compressed like .zip, .gif, and .jpg files. They will however compress average text files to an approximate 2:1 ratio. Spreadsheets and databases may be compressed at up to a 4:1 ratio. As a general rule of thumb the DTE rate should be set 4 times higher than the DCE modem speed. A word of caution, setting the DTE rate too high will cause interface overruns and negatively affect throughput. For example: Using a 56kpbs modem your DTE speed should be 115,200.

Summary This chapter introduced the information systems professional to analog telephone system terminology, technology, and operational concepts. We discussed analog signaling & electronic information transfer using changes in signal frequencies and amplitude. We looked at how traditional broadcast technologies like radio and television, and public switched telephone networks (PSTN), make use of analog technology and the merging of analog and digital transmission mediums. The term “analog” can be traced to the similarity between fluctuations on the sound of a human voice and the “analogous” or comparable modulation of sine waves viewed as a signal screen capture. Telephone systems use analog-switched lines to provide voice communications by converting sound waves•vibrations that move in the air•into electrical signals. Telephone handsets contain a transmitter covered by a diaphragm, and a receiver composed of a coil attached to a speaker cone that vibrates to produce sound. These same telephone systems use dial pulse (DP) and/or dual-tone multifrequency (DTMF) to establish, and tear down telephone calls as well initiate account billing functions. These calls are begun using one of two basic methods: loop start and ground start. Loop start lines signal off-hook by completing a circuit at the telephone. Used by a COs PBX, ground start lines are partially operational at all times, with the remainder of the line activated instantly upon detecting a dial tone. Telephone systems are composed of telephone handsets, drop wires, local loops, COs, analog and digital carriers, DC voltage generation units, and billing, monitoring, and line maintenance computer systems. These systems function and communicate with each other using DC, tone, and CCIS signaling protocols. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (32 of 34) [13/12/02 18:18:37]


Data generated by computer then transmitted across these telephone systems must first be converted from digital to analog at the sending location, then from analog to digital at the receiving location. Computer systems dialing into the Internet use modems to modulate and demodulate information transmitted across a largely analog telephone system. The trend in today’s fast paced telecommunications environment is the merger of voice and data into an integrated system capable of handling both voice and data across the same channels we use solely for data today. Once implemented an integrated system will provide greater bandwidth to utilization efficiency, better cost control, and improved circuit management capability.

FAQs Q: Which is better, analog or digital transmission? What is the difference? A: My favorite engineering answer applies here: “It depends.” Analog transmission has a greater informational range than digital but analog transmission is not as precise as digital transmission. Analog transmission over long distances is prone to pick up noise and amplify it. Digital technology uses binary codes (0 or 1) to represent information. Digitally transmitted information has two major benefits: (1). The signal can be reproduced precisely. In long telecommunications transmission circuits, the signal progressively loses strength and picks up electro-magnetic static and electrical interference. Using digital transmission, the signal is regenerated and reconstructed to an exact replica of the original signal, minus the noise. (2). Technology needed to reproduce signals digitally has become considerably less expensive and more powerful. Q: Is it true that a personal computer (pc) modem converts digital data to analog then sends the data over twisted pairs of copper wire? A: Yes. When you use a pc connected to a modem to dial into the internet or call another computer system the data is typically sent over the standard telephone connection between your residence and the telephone company. Most connections to/from residences consist of twisted pair copper wire. Q: Do individual phone lines always connect to a T1 line? file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_02.htm (33 of 34) [13/12/02 18:18:37]


A: No. Individual phone lines connect to a telephone switch like BasicNET3, Basic-5ESS, or Basic DMS100. T1 lines are digital circuits typically used to interconnect these telephone switches. Inter-switch connections are sometimes referred to as “digital trunks.” Q: Do V.34 and V.42 modems have the capability to exceed analog phone line bandwidth limitations? A: Yes. High-speed V.34 and V.42 modems compress the data they transmit. Usually a 2:1 or 4:1 ratio, depending on file type and characteristics. Due to data compression and the modems use of codes to represent data bit patterns, the modem actually stuffs more information into the data it transmits. Q: What is the bandwidth limitation of today’s analog telephone circuits? A: The Telephone signal bandwidth may be calculated by taking the upper frequency range then subtracting the lower frequency range. The result will be typical telephone bandwidth. For example to calculate telephone bandwidth: 3300Hz – 300Hz = 3000Hz


Chapter 3: IOS Voice Protocols


Chapter 3 IOS Voice Protocols Overview of IP Network Voice over IP Signaling, Addressing, and Routing H.323 Family of Standards Introduction to H.323 H.323 Components H.323 Terminals (Endpoints) H.323 Gateways H.323 Gatekeepers Multipoint Control Units (MCUs) H.323 Protocol Stack H.323 Call Stages H.323 Discovery and Registration Call Placement (Intra-zone) Call Placement - Inter-zone H.323 Call Setup Logical Channel Setup Media Stream and Media Control Flows Call Termination H.323 Endpoint to Endpoint Signaling Session Initiation Protocol (SIP) Key Benefits of Session Initiation Protocol Session Initiation Protocol Components Session Initiation Protocol Messages Media Gateway Control Point (MGCP) Summary Exercises



A good knowledge about the standards/protocols is important in designing a successful network including packetized voice architecture. In this chapter, we will introduce the standards and protocols that support packetized voice technology, and identify the key information needed to design packetized voice networks. Solutions in this chapter: •

Overview of IP Networks

•

Voice over IP (VoIP) Signaling, Addressing, and Routing

•

H.323 Family of Standard

•

Session Initiation Protocol (SIP)

•

Media Gateway Control Point (MGCP)

Overview of IP Network Unlike Frame Relay and ATM connection-oriented networks, IP is a connectionless network protocol that uses variable-length bit streams. In a connectionless network protocol, information is transferred between two entities without first establishing a connection. Upper layer protocols may be connectionless or connection-oriented. IP is a network layer protocol (layer three of the OSI model Figure 3.1). It contains the addressing and control information that enable datagrams to be routed and thereby provide a connectionless best-delivery service of datagrams through an inter-network. A message may be transmitted as a series of datagrams that are reassembled at the receiving location. Typically, IP traffic has been transmitted on a first-in, first-out basis. Packets have been variable in nature, allowing large file transfers to utilize the efficiency with large associated packet sizes.



Figure 3.1 Internet Protocol (mapping to the OSI reference model protocol stack). The Internet is a “best effort” network, meaning that if a packet cannot reach its destination, the network discards the packet and relies on the endpoints to discover that packets are missing. As a result, most IP-based networks cannot deliver the same quality as that provided by the PSTN. The Internet Protocol provides for addressing within the Internet. Each packet sent on the Internet contains both a destination address and a source address. The IP network may be the public Internet or a private IP-based network. The IP network supports real-time services via: •

Resource Reservation Protocol (RSVP)

•

Differentiated Services (Diff Serv)

•

Real-time Transport Protocol (RTP)

•

Real-time Control Protocol (RTCP)

Transmission Control Protocol (TCP) is a connection-oriented protocol responsible for divided a message into IP-manageable packets and then reassembling the packets into a complete message at the other end. TCP is considered a reliable transport service. It is a Layer 4, end-to-end protocol that provides virtual connection reliability. Virtual Connection is simply an association between processes on two machines. TCP is not processed at the network file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (3 of 35) [13/12/02 18:18:48]


routers/switches but at the endpoints. It provides the application with reliable virtual circuit and flow control, and determines and adapts to network congestion. TCP is responsible for providing reliable transmission of data over the network by providing the following services: •

Streamed data transfer

• Multiplexing (numerous upper layer conversations can be transferred simultaneously over a single connection) •

Efficient flow control

•

Reliability

•

Full duplex operations

Streamed data transfer delivers data as a steady and continuous stream of bytes. A sequence number identifies each byte so that applications do not have to segment data into manageable blocks before handing it to TCP. When TCP receives the byte stream, it groups it into segments and sends them to IP for delivery. Each byte contains a forward acknowledgment number that indicates to the receiver which segment number is expected next by the transmitter. TCP has the ability to recover from lost and delayed packets. The User Datagram Protocol (UDP) is another Layer 4 protocol. It is a connectionless protocol that sends data (datagrams) from one computer to another. UDP does not provide any delivery guarantees, and is considered a best-effort transport service. UDP is different from TCP and more appropriate to applications where acknowledgments are unnecessary, or retransmission is not appropriate. For example, Domain Name Service query and Internet Telephony. This protocol provides so-called “unreliable” transport layer service to the application because there are no acknowledgments. Essentially, UDP adds in Layer 4 port numbers. UDP is used for Voice over IP and is a simple protocol that exchanges datagrams without acknowledgements or guaranteed delivery, this requires that error processing and retransmission be handled by other protocols. UDP adds no reliability, flow control, or recovery functions to IP. It simply acts as an interface between IP and upper-layer processes. UDP’s header contains fewer bytes and consumes less network overhead than TCP, and because UDP does not handshake with the receiving end, the initiation and sending process is faster than TCP. This makes UDP a logical transport protocol for VoIP.



To successfully integrate connection-oriented voice traffic in a connectionless-oriented IP network, enhancements to the signaling stack are required. In some manner, we must make this connectionless network appear connection-oriented.

Voice over IP Signaling, Addressing, and Routing VoIP signaling has three distinct areas: signaling from the PBX to the router, signaling between routers, and signaling from the router to the PBX. When signaling from PBX to Router, the user picks up the handset, signaling an offhook condition. The connection between the PBX and router appears as a trunk line to the PBX, which will signal the router to seize the trunk. Once a trunk is seized, the PBX forwards the dialed digits to the router in the same manner the digits would be forwarded to a telephone company switch or another PBX. The signaling interface from the PBX to the router may be any of the common signaling methods used to seize a trunk line, such as FXS, FXO, E&M or T1/E1 signaling. The PBX then forwards the dialed digits to the router in the same manner the digits would be forwarded to a Telco switch. Within the router the Dial Plan Mapper maps the dialed digits to an IP address and initiates a Q.931 Call Establishment Request to the remote peer router that is indicated by an IP address. Meanwhile, this control channel is used to set up the Real-Time Protocol (RTP) audio streams, and the RSVP protocol may be used to request a guaranteed quality of service. When the remote router receives the Q.931 call request it signals a line seizure to the PBX. After the PBX acknowledges this seizure, the router forwards the dialed digits to the PBX, and signals a call acknowledgment to the originating router.



Figure 3.2: VoIP Signaling. In connectionless network architectures like IP, the responsibility for session establishment and signaling resides in the end stations. To successfully emulate voice services across an IP network, enhancements to the signaling stacks are required. For example, an H.323 agent is added to the router for standards-based support of the audio and signaling streams. The Q.931 protocol is used for call establishment and tear down between H.323 agents or end stations. H.225 is essentially the same as Q.931. Real-Time Control Protocol (RTCP) provides for reliable information once the audio stream has been established. A reliable session-oriented protocol such as TCP is deployed between end stations to carry the signaling channels. RTP, which is built on file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (6 of 35) [13/12/02 18:18:48]


top of UDP, is used to transport the real-time audio stream. RTP uses UDP as a transport mechanism because it has lower delay than TCP, and because actual voice traffic, unlike data traffic or signaling, tolerates low levels of loss and cannot effectively exploit retransmission. H.245 Control Signaling is used to negotiate channel usage and capabilities. H.245 provides for capabilities’ exchange between endpoints so that codecs and other parameters related to the call are agreed upon between the endpoints. It is within H.245 that the audio channel is negotiated. Table 3.1 depicts the relationship between the ISO reference model and the protocols used in IP voice agents. ISO Protocol Layer ITU H.323 Standard Presentation G.711, G.729, G.729a, etc. Session H.323, H.245, H.225, RTCP Transport RTP,UDP Network IP, RSVP, WFQ Link RFC1717(PPP/ML), Frame, ATM, etc. Table 3.1 ISO Reference Model and H.323 Standards In an existing corporate intranet, an IP addressing plan will be in place. To the IP numbering scheme, the voice interfaces will appear as additional IP hosts, either as an extension of the existing scheme, or with new IP addresses. The dial plan mapper performs translation of dial digits from the PBX to the far-end IP address of the receiving VoIP router. When the dialed number is received by the originating router, the router compares this number to those defined in the router table. If a match is found, the call is routed to the appropriate far-end router. One of the strengths of IP is the maturity and sophistication of its routing protocols. A modern routing protocol, such as EIGRP, can take delay into consideration when calculating the best path. These are also fast converging routing protocols, which allows voice traffic to take advantage of the selfhealing capabilities of IP networks. Advanced features, such as policy routing and access lists, make it possible to create highly sophisticated and secure routing schemes for voice traffic. RSVP can be automatically invoked by Cisco’s VoIP gateways to insure that the appropriate bandwidth and delay characteristics are provided in the IP network to transport voice with a high level of Quality of Service (QoS). One of the most interesting developments in IP routing is the development of Tag Switching and other IP switching disciplines. Tag Switching provides a way of extending IP routing, policy, and QoS features over ATM and other high-speed transports. Another benefit of Tag Switching is its traffic engineering capabilities, which are needed for the efficient use of network resources. Traffic engineering can also be used to shift traffic load based on different predicates, such as time of day. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (7 of 35) [13/12/02 18:18:48]


H.323 Family of Standards The accepted model for transmitting multimedia such as voice across a network that does not guarantee QoS, such as IP, is H.323. H.323 allows for standards-based interoperability with other vendors’ H.323-compatible equipment. The Cisco 2600, 3600 and AS5300 routers act as H.323 gateways. The 3600 series can also serve as a H.323 gatekeeper. The H.323 protocol comprises audio, video, data applications, and system control. Available audio codecs within Cisco VoIP gateways include G.711, G.729, G.729a, and G.723.1.

Introduction to H.323 H.323 is probably the most important standard supporting packetized voice technology. During the 1990s, the H.320 standard was defined for ISDN BRI videophones and Videoconferencing systems. The initial H.323 (H.323 v.1) recommendation in October 1996 was heavily weighted toward communications in a LAN environment, but experiments with voice communications over the Internet were already underway. H.323 v.1 was mainly developed for multimedia LANs without packet-based QoS. These initial attempts were based on proprietary methods for setting up calls, compressing voice, locating and alerting endpoints, and so on. As Voice over IP became more commonplace, the need for a standard method of providing voice communications over the Internet became apparent. In 1998, experiments with sending voice over the Internet led to the need for new standards and new applications such as PC-based phones calling analog phones. H.323 is an ITU-T Recommendation umbrella set of standards that defines the components, protocols, and procedures necessary to provide multimedia (audio, video, and data), communications over IP based networks. Essentially, H.323 provides a method to enable other H.32X compliant products to communicate. It is today's most mature VoIP protocol, and it has widespread industry support. In addition to control and call setup standards, H.323 encompasses protocols for audio, video, and data as follows: • Audio: The compression algorithms for audio supported by H.323 are all proven ITU standards (G.711, G.723, and G.729). Because audio is the minimum service provided by the H.323 standard, all H.323 terminals must have at least one audio codec support, as specified by G.711. • Video: Video capabilities for H.323 are optional. However, any video-enabled H.323 terminal must support the ITU-T H.261 encoding and decoding recommendation (H.263 is optional).



• Data: H.323 references the T.120 specifications for data conferencing. An ITU standard, T.120 addresses point-to-point and multi-point data conferences. It provides interoperability at the application, network, and transport level.

Figure 3.3 H.323 an ITU-T umbrella set of standards for Audio, Video, and Voice. H.323 can be applied in a variety of scenarios such as: •

Audio only (IP telephony)

•

Audio and video (Video telephony)

•

Audio and data

•

Audio, video, and data

•

Multipoint-multimedia communications

H.323 Components Let’s spend some time reviewing the components that comprise the H.323 standard. The



H.323 standard specifies four different components that when networked together, enable point-to-point and point-to-multipoint multimedia communications services. Figure 3.4 shows H.323 components.

Figure 3.4: H.323 Components. • Terminals or Endpoints - Provide real-time, two-way multimedia communications. All endpoints must support voice communications and can optionally support video or data communications. • Gateways - Provide services that allow communications between H.323 and nonH.323 entities (for instance, between H.323 terminals and telephones on the circuitswitched network). • Gatekeepers - Considered the most important component. Provides call control functions, such as address translation and bandwidth management. • Multipoint Control Units (MCUs) - Provide support for conferences of three or more endpoints. It is not necessary that all of these components be implemented in order to achieve voiceover-data functionality. For instance, the PC to PC service can be offered without the “Gateway” or “Gatekeeper” in some scenarios, but to gain complete productivity the elements must be offered and will enhance what is already in place. Let’s look at each of these components in a little more detail. H.323 Terminals (Endpoints) file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (10 of 35) [13/12/02 18:18:48]


H.323 terminals are primarily IP telephones and PCs, not traditional telephones. An H.323 terminal must have: •

A network interface

•

audio codecs

•

H.323 software

H.323 terminals must support audio (G.711 is mandatory, G.723.1 and G.729 are recommended for networks of low bandwidth). Video and data support is optional; H.261 is mandatory when video is supported. H.245 and H.225 are required for control functions, and the RTP is required for sequencing media packets. Many IP telephones are being introduced that will support H.323, and any PC can easily be upgraded to support an H.323 terminal application. (Microsoft NetMeeting is an example of an H.323 terminal application.) H.323 Gateways What are gateways and what are their functions? Gateways provide a means for interoperability between different telecommunications systems. H.323 gateways provide translation functions between H.323 and circuit-switched networks. Encoding, protocol, and call control mappings occur in gateways between two endpoints. Gateways provide many functions, including: • Translating protocols – the gateway acts as an “interpreter,” allowing the PSTN and the H.323 network to talk to each other to set up and tear down calls. • Converting information formats – different networks encode information in different ways. The gateway converts this information so both networks can freely exchange information such as speech and video. •

Transferring information – the gateway is responsible for transferring information

between different networks, like the PSTN and the Internet. H.323 Gatekeepers Let’s move on to a discussion of the H.323 gatekeeper. The gatekeeper performs the call control functions and administration of policy for registered H.323 endpoints. Gatekeepers are considered by many to be the “brains” of the H.323 network. Gatekeepers in H.323 networks are optional, however, if they are present, it is



mandatory that endpoints use their services. The H.323 standards define several mandatory services that the gatekeeper must provide and specifies other optional functionality. The following services are mandatory: • Address Translation - The gatekeeper must be able to translate an alias address into a transport address. This function is particularly important in scenarios where a phone on the circuit-switched network is attempting to call a PC on an IP network. (an E.164 number like 212-555-2121 will be translated into an IP Network Address like 180.23.12.78). • Admissions Control – H.323 defines the Registration/Admission/Status (RAS) messages necessary to authorize network access, but does not define the rules or policies used to authorize access to network resources. To do this the gatekeeper can interface with an existing authorization mechanism. • Bandwidth Control and management- Gatekeepers must support RAS bandwidth messages. However, how they provide the bandwidth access or bandwidth management is left to the provider. The H.323 standards have yet to define a mechanism for enforcing bandwidth control. A gatekeeper may also determine that there is no bandwidth available for a call or no additional bandwidth available for an ongoing call requesting an increase. The gatekeeper can instruct an ongoing call to reduce its bandwidth usage. All of these decisions are outside the scope of the H.323 standards and are, therefore, left to the discretion of the H.323 provider. • Zone Management – An H.323 “zone” is the collection of all components—terminals, gateways, and Multipoint Control Units—managed by a single gatekeeper. Within its zone, a gatekeeper must provide required functions (for example: address translation, admissions control, bandwidth control) to all endpoints that have registered with it. The gatekeeper can also perform some optional functions like: • Call Authorization - The gatekeeper can decide to authorize or reject a given call; the provider of the H.323 service specifies the reasons for authorization and rejection. Reasons may include the time of day, type of service subscription, desire to access a restricted gateway, or lack of available bandwidth. • Call Control Signaling –A gatekeeper can decide that it will process all call signaling associated with the endpoints registered with it, or allow the call signaling



messages to pass directly between the endpoints. The first method is commonly referred to as “gatekeeper routed call signaling.” • Call Management - The gatekeeper may provide intelligent call management. For instance, it may be known that a requested terminal is currently engaged in a call. The gatekeeper can choose to redirect the call or, at a minimum, save the call setup time by not attempting to establish a call to a busy terminal. The call management may be based on address translation functions providing call screening, call forwarding/redirection, and call routing based on time of day, network congestion, or least cost path. Some other optional services include bandwidth management and reservation, gatekeeper management information data structure, and directory services. Multipoint Control Units (MCUs) The final H.323 component is the Multipoint Control Unit or MCU. MCUs provide conference support for three or more endpoints. All terminals participating in the conference establish a connection with the MCU. It manages conference resources and negotiations between endpoints to determine which audio or video codec to use. The Multipoint Control Unit may or may not handle the media stream. An MCU has two functional parts: • A Multipoint Controller (MC) that performs Conference control by controlling what media streams go where. The MC has a reconciliation capability (common mode) and may be located in the terminal, gateway, or gatekeeper. The MC is required for all conferences. • A Multipoint Processor (MP) that Mixes, switches, and processes media streams including some or all of the streams in the conference call (video, data, or audio). The MP is not required while its absence can put a burden on a terminal.

H.323 Protocol Stack A protocol may be part of a structured set of protocols that implement a communications function. This structure is referred to as a protocol stack. The protocols within the stack are independent parts and stand alone, but can use and be used by other protocols. Media streams are transported on RTP/RTCP. RTP carries the actual media and RTCP carries status and control information. The signaling is transported reliably over TCP. The following protocols deal with signaling: •

RAS manages registration, admission, and status.



•

Q.931 manages call setup and termination.

•

H.245 negotiates channel usage and capabilities.

•

H.235 handles security and authentication.

Figure 3.5 shows the H.323 protocol stack and its major components, they are defined as follows: •

IP – addressing protocol used for routing packets through the Internet or Intranet.

• TCP – connection oriented protocol responsible for ensuring that a message is properly divided into IP packets, and for reassembling the packets back into the complete message at the other end. It is considered a reliable transport service. • UDP (User Datagram Protocol) – connectionless protocol used to send data (datagrams) from one computer to another. It does not provide any delivery guarantees; best-effort transport service. • H.225 – provides call setup and control with all signaling necessary to establish a connection between two H.323 endpoints. The ITU Q.931 provides a means to establish, maintain, and terminate network connections across ISDN. It is defined as the basic call setup protocol for an ISDN. In the Blue book (1988) Q.931 uses 22 messages, and 29 in case of Q.932. H.225 adopted a subset of Q.931 messages and parameters. The H.323 mandatory messages are Alerting, Call Processing, Connect, Setup, Release Complete, Status, Status Inquiry, and Facility (Q.932). • H.245 Control Signaling – used to negotiate channel usage and capabilities, H.245 exchanges end-to-end control messages managing the operation of the H.323 endpoint. Control messages carry information related to: 1. capabilities exchange 2. opening and closing logical channels used to carry media streams 3. flow control messages 4. general commands



Figure 3.5 H.323 Protocol Stack. After call setup, all communications are over logical channels. H.245 defines procedures for mapping logical channels (Logical channel 0 is for H.245 control, open for the duration of the call, and multiple logical channels of varying types, such as video, data, voice, are allowed for a single call). H.245 defines the protocol for accomplishing specific tasks such as signaling entities. The H.245 Capability Exchange Signaling Entity identifies the capabilities of participating entities, and may identify options and valid combinations of capabilities: 1 video channel (H.261) and 1 audio channel (G.711 or G.723). The H.245 Master Slave Determination Signaling Entity identifies which entity will act as Multipoint Controller (MC); deterministic rules apply, based on hierarchy of capabilities and entity types. •

T.120 – protocol used for sharing of data.

•

G.7XX – ITU series of audio codecs (G.711, G.723, G.729).

• H.26X – ITU series of video codecs (H.261, H.263). H.26x series describe a video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP. • RTP - The Real-time Transport Protocol (RTP) provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast network services. It is used to transport data via UDP. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (15 of 35) [13/12/02 18:18:48]


control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. • RTCP – (Real-time Transport Control Protocol) control transport for RTP. Provides feedback on the quality of data distribution. Also carries a transport-level identifier for an RTP source used by receivers to synchronize audio and video. • RAS (Registration, Admission, and Status) – protocol between endpoints (terminals and gateways) and gatekeepers. It is used to perform registration, admission control, bandwidth changes, status, and to disengage endpoints from gatekeepers. RAS uses UDP port 1719.

H.323 Call Stages The connection procedures involved in creating an H.323 call can be grouped into six stages as follows: •

Discovery and Registration

•

Call Setup

•

Call Signaling Flows

•

Media Stream and Media Control Flows

•

Call Termination

A lot is happening within each of these stages from the time the call is requested to the time it is terminated. Let’s look at each of the specific steps: H.323 Discovery and Registration During the Discovery and Registration stage of the H.323 call, the gatekeeper goes through a “discovery” process to determine the gatekeeper with which the endpoint must register. Registration is used by the endpoints to identify a zone with which it 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.



Figure 3.6 H.323 Gatekeeper Call Control/Signaling-Discovery and Registration. Let’s look at the flow within this stage: 1. An H.323 gateway (or terminal) sends a Request to Register (RRQ) message using H.225 RAS on the RAS channel to the gatekeeper. 2. The gatekeeper confirms the registration by sending a Registration Confirmation (RCF) or a Reject Registration message back to the gateway. Call Placement (Intra-zone) Assuming that the gateways (or terminals) are already registered. In the case where a gateway X (Figure 3.7) wishes to place a call to a terminal connected to gateway Y, gateway X sends a ARQ message to the gatekeeper requesting permission to place a call to a phone number serviced by gateway Y.

Figure 3.7 H.323 Gatekeeper Call Control/Signaling - Call Placement (Intra-zone). Let’s look at the flow within this stage: 1. Gateway X sends an Admission Request (ARQ) message using H.225 RAS on



the RAS channel to the gatekeeper to request one of the following: a. The gatekeeper requests the direct call signaling by sending an Admission Confirmation (ACF) message back to Gateway X. b. Call Setup Call Placement - Inter-zone In this case, we will assume that the network is relatively large and divided into different zones (two zones for example). Zone A is controlled by Gatekeeper A, and Zone B is controlled by Gatekeeper B. Gateway X (or Terminal X) is registered with Gatekeeper A, and Gateway B is registered with Gatekeeper B (see Figure 3.8). Gateway X wants to place a call to a terminal connected to Gateway Y. Gateway X sends an ARQ message to the gatekeeper requesting permission to place a call to a phone number serviced by Gateway Y. Since Gateway Y is not registered with the gatekeeper in Zone A, we assume that the gateways (terminals) are already registered.

Figure 3.8 H.323 Gatekeeper Call Control/Signaling Call Placement (Inter-Zone).



H.323 Call Setup Once discovery and registration, and then the call placement are successfully completed, the H.323 call moves to the call setup stage. Within this stage, the gateways are communicating directly to set up the connection. An alternate method of call setup is gatekeeper-routed call signaling, where all of the call setup messages traverse the gatekeeper.

Figure 3.9 Call Setup – The setup protocol is based on Q.931; The setup message includes caller name and IP address. 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. The H.323 call setup flow is as follows (See Figure 3.9): 1. Gateway X sends an H.225 call signaling setup message to Gateway Y to request a connection. 2. Gateway Y sends an H.225 message back to Gateway X, advising that it may proceed with the call. 3. Gateway Y sends a RAS message (ARQ) on the RAS channel to the gatekeeper file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (19 of 35) [13/12/02 18:18:48]


to request permission to accept the call. 4. The gatekeeper confirms that the call can be accepted by sending a message (ACF) back to Gateway Y. 5. Gateway Y sends an H.225 message to Gateway X, alerting that the connection has been established. 6. Gateway Y sends an H.225 message to Gateway X, confirming the call connection, and the call is established. Logical Channel Setup After call setup, all communications traverse over logical channels. The H.245 protocol is now used to define procedures for managing these logical channels. Multiple logical channels of varying types (video, audio, and data) are allowed for a single call (Figure 3.10). The H.245 Logical Channel Signaling Entity (LCSE) opens a logical channel for each media stream. Channels may be uni-directional or bi-directional.

Figure 3.10 Media channel setup. Let’s see how this logical channel setup fits within the flow of this H.323 call (see Figure 3.11). The H.245 control channel is established between Gateway X and Gateway Y. Gateway X uses H.245 to identify its capabilities by sending a Terminal



Capability Set message to Gateway Y. The media channel setup flow is as follows: 1. Gateway X exchanges its capabilities with Gateway Y by sending an H.245 Terminal Capability Set message. 2. Gateway Y acknowledges Gateway X’s capabilities by sending an H.245 Terminal Capability Set Acknowledge message. 3. Gateway Y exchanges its capabilities with Gateway X by sending an H.245 Terminal Capability Set message. 4. Gateway X acknowledges Gateway Y’s capabilities by sending back an H.245 Terminal Capability Set Acknowledge message. 5. Gateway X opens a media channel with Gateway Y by sending an H.245 Open Logical Channel message, and includes the transport address of the RTCP channel. (the media stream is managed by the RTCP) 6. Gateway Y acknowledges the establishment of the logical channel with Gateway X by sending an H.245 Open Logical Channel Acknowledge message, and includes: • the RTP transport addresses (which will be used for sending the RTP media stream) allocated by Gateway Y, and •

the RTCP address previously received from Gateway X. 7. Gateway Y then opens a media channel with Gateway X by sending an H.245 Open Logical Channel message, and includes the transport address of the RTCP channel. 8. To complete the establishment of the bi-directional media stream communication, Gateway A acknowledges the establishment of the logical channel with Gateway Y by sending an H.245 Open Logical Channel Acknowledge message, and includes:

• the RTP transport addresses (which will be used for sending the RTP media stream) allocated by Gateway X, and •

the RTCP address previously received from Gateway Y.



Figure 3.11 Media channel setup call flow. Media Stream and Media Control Flows In Cisco VoIP gateways RTP media streams are transported over UDP ports 16384 through 16384 + 4 x (the number of voice ports on the gateways). For example, a Cisco 3620 router with 4 E&M ports would use UDP ports 16384 – 16400 for RTP flows. Media Streams in the H.323 call flow are managed by RTCP. This protocol provides a 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. Let’s briefly review the steps in this stage of the H.323 call flow (Figure 3.12).



Figure 3.12 Media Stream Communication. 1. Gateway X sends the RTP encapsulated media stream to Gateway Y. 2. Gateway Y sends the RTP encapsulated media stream back to Gateway X. 3. Gateway X sends the RTCP messages to Gateway Y. 4. 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, and may be asked for bandwidth decreases. Endpoints must comply with gatekeeper responses and requests. The bandwidth change flow is diagramed in Figure 3.13.



Figure 3.13 Bandwidth Change Request. Call Termination Call termination stops the media streams and closes logical channels. It may be requested by any endpoint or by a gatekeeper. Call termination closes the media logical channel, ends the H.245 session, releases H.225/Q.931 connections, and provides disconnect confirmation with gatekeeper via RAS. Figure 3.14 shows call termination flow, and is described as follows: 1. Gateway Y initiates the call termination by sending an H.245 End Session Command message to Gateway X. 2. Gateway X releases the call endpoint and confirms the release by sending an H.245 End Session Command message back to Gateway Y. 3. Gateway Y completes the call release by sending an H.245 Release Complete message to Gateway X.



4. Gateway X and Gateway Y disengage with the gatekeeper by sending a RAS DRQ message. 5. The gatekeeper disengages and confirms by sending DCF messages to both Gateway X and Gateway Y.

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

Exercise Which endpoint decides if the call is to be terminated or not (the calling or the called)? From Figure 3.14, can you tell which endpoint actually decided to terminate the call? Is it X or Y, and why?

H.323 Endpoint to Endpoint Signaling Assuming that endpoints (clients) know each other’s IP addresses, the H.323 signaling is shown in Figure 3.15. This figure is based on the steps we spoke about in the previous section, "Call Termination."



Figure 3.15 H.323 Endpoint to Endpoint Signaling. Exercise Based on the H.323 call flows we have just covered, explore call flows for the following typical scenarios: •

Phone to Phone (Single Stage)

•

Phone to Phone (Two stage)

•

PC to PC

•

PC to Phone

•

Phone to PC

Discuss the functional elements before giving the call flow.

Session Initiation Protocol (SIP) The next protocol for discussion is the Session Initiation Protocol, or SIP. The Session Initiation Protocol (SIP) is a simple signaling protocol used for Internet conferencing and telephony. Based on SMTP and HTTP, SIP was developed within the IETF 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 the underlaying packet protocol (TCP, UDP, ATM, X.25). SIP has been modeled after the text-based Simple Mail Transfer Protocol



(SMTP) and Hypertext Transfer Protocol (HTTP) based on a client server architecture in which the client initiates the calls and the servers answer the calls. By conforming to these existing text based Internet standards, troubleshooting and network debugging are facilitated since the protocol can be read in the clear without decoding the binary ASN.1 payload which is required in non-text based protocols such as H.323. 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 architecture. •

SIP addresses are URLs: user@host

•

User: name, telephone, number

•

Host: domain, numeric network (IP) address

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

Key Benefits of Session Initiation Protocol SIP is complementary to MGCP in that MGCP provides for device control while SIP handles session control. Some of the key benefits of SIP are: • Simplicity – SIP is a very simple protocol. Software development time is very short compared to traditional telephony products. Due to its similarity with HTTP and SMTP, code reuse is possible. • Extensibility – SIP has learned from HTTP and SMTP and has built a rich set of extensibility and compatibility functions. • Modularity – SIP was designed to be highly modular, a key feature is its independent use of protocols. For example, SIP issues invitations to called parties, independent of the session itself. •

Scalability 1. server processing - SIP has the ability to be either stateful or stateless. 2. conference sizes - since there is no requirement for central multi-point controller, conference coordination can be fully distributed or centralized.



• Integration – SIP has the capability to integrate with the Web, email, streaming media applications, and other protocols.

Session Initiation Protocol Components The SIP system contains two components: User Agents and Network Servers. A user agent (UA)-is SIP's endpoint that makes and receives SIP Calls. •

The client is called the User Agent Client (UAC) and is used to initiate SIP requests.

• The server is called the User Agent Server (UAS), receiving the requests from the UAC and returning responses for the user. SIP has two kinds of network servers: • Proxy Server: Proxy Servers decide which server the request should be forwarded to, and then forwards the request. The request can actually traverse many SIP servers before reaching its destination. The response then traverses in the reverse order. A proxy server can act as both a client and server, and can issue requests and responses. • Redirect Server: Unlike the proxy server, the Redirect Server does not forward requests to other servers. Instead, it notifies the calling party of the actual location of destination. We also can talk about the SIP terminal, which can support real-time, 2-way communication with another SIP entity. SIP terminal supports both signaling and media, similar to H.323 terminal. SIP terminal contains UAC.



Figure 3.16 Session Initiation Protocol (SIP) architecture.

Session Initiation Protocol Messages SIP uses messages for call connection and control. There are two types of SIP messages: Requests, and Responses. SIP messages are defined as: •

INVITE used to initiate a user to a call. Header fields contain: 1. addresses of the caller and the one being called 2. subject of the call 3. call priority 4. call routing requests 5. caller preferences for the user location 6. 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 one being called, such as the difference between a plain telephone handset and a fully featured multimedia phone.



Figure 3.17 A Sample SIP call flow - SIP Server in Redirect Mode.

Media Gateway Control Point (MGCP) A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. Examples of gateways are: • Trunking gateways: interface between the telephone network and a VoIP network. Such gateways typically manage a large number of digital circuits. • Voice over ATM gateways: operate much the same way as VoIP trunking gateways, except that they 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, xDSL devices, 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 Voice over IP services and Network Access services. Media Gateway Control Protocol (MGCP) is used for controlling telephony gateways from external call control elements called media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. MGCP is presented as a merger of SGCP (created by Bellcore) and IPDC (created by Ascend, Nortel, and Level 3). These organizations had the foresight to merge two similar protocols and move toward a single protocol. It is a media control protocol, suited for large scale IP Telephony deployment. MGCP supports VoIP only. The concept behind the MGCP is to decompose the components of the gateway by moving the intelligence out of the “dumb” media gateway and into a “smart” Media Gateway Controller (MGC). The MGCP implements the media gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are eight types of commands: •

CreateConnection

•

ModifyConnection

•

DeleteConnection

•

NotificationRequest

•

Notify

•

AuditEndpoint

•

AuditConnection

•

RestartInProgress

Consequently, the gateway becomes a simple device supporting PSTN and LAN interface, and provides voice compression and packetization, while the MGC provides the intelligence and controls the dumb gateways. The call control intelligence is outside the gateways and handled by external call control file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (31 of 35) [13/12/02 18:18:48]


elements. This separation of call control from gateway functions, makes the gateways dumb, but interoperable. The MGCP is used to centrally control: •

VoIP Gateways

•

Network Access Servers

•

Circuit Switches

Summary Most VoIP implementations are based on H.323. The H.323 v.1 defines interfaces and protocols for multimedia communications over LANs with non-guaranteed Quality of Service. The H.323 v.2 addresses WAN issues and is widely deployed by ITSP (Internet Telephony Service Providers). The four H.323 components (gateway, gatekeeper, MCUs, and terminals/endpoints) have been discussed. The protocols that H.323 rely on to establish connections and transmit data have been discussed. These protocols are H.225, Q.931, H.245, RAS, and RTP. Because of its simplicity and flexibility, the nonstandardized SIP, have been discussed. SIP has many of the capabilities as H.323 but introduces them with a different approach. The important aspect of MGCP is the separation of the control and media processing functions. It is expected that MGCP will allow development of an open platform for voice switching over packet networks which is scalable to large size at a relatively low cost per PSTN Port. Industry Standard/ Protocol H.323 Comprised of : H221, H.223. H.225, H.230, H.235, H.242, H.261, H.263, H.320, H.323, H.323AnnexD, and, and Q.931.

Functionality The ITU-T Recommendation umbrella set of standards that defines the components, protocols, and procedures necessary to provide multimedia communications service over IP based networks

Similarity to Other Standards

Generally, Where It Fits

SIP – both used to Fits between PSTN and establish connections in a packet network packet network. Two protocols come from different problem domains, and do not attempt to tackle precisely the same set of problems.



SIP (Session Initiation Protocol)

SIP – both used to Between PSTN and A simple signaling protocol used for Internet establish connections in a Packet Network packet network conferencing and telephony

MGCP (Media Gateway MGCP organizes and controls call flows Control Point) between software and hardware. Media control protocol suited for large scale IP Telephony deployment

IPDC SGCP

Protocol between endpoints (terminals and gateways) and gatekeepers.

It is used to perform RAS (Registration, Admission, and Status) registration, admission control, bandwidth changes, status, and to disengage between endpoints and gatekeepers

RTP (Real-time Transport Protocol)

RTP is a real-time transport protocol for audio, video, & data

RTCP – (Real-time Transport Control Protocol) control Transport for RTP

Provides feedback on the quality of data distribution. Also carries a transport-level identifier for an RTP source used by receivers to synchronize audio and video

Defines the protocol between the “smart” Media Gateway Controller and the “dumb” Media Gateway

Extension to UDP. Makes Application that sits on UDP a real-time the top of the transport connection oriented layer. (Utilized by H.323) service

Exercises Exercise I 1. What does the H.323 protocol set do? file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_03.htm (33 of 35) [13/12/02 18:18:48]


2. Why is H.323 important to packetized voice?

Answers 1.

The H.323 protocol:

• Defines how audio and videoconferencing systems communicate over packetswitched networks that do not guarantee Quality of Service (QoS), such as the Internet and Intranets. • Addresses call control and management for both point-to-point and multi-point conferences. • Addresses QoS issues with a centralized gatekeeper component that allows LAN administrators to manage media traffic, bandwidth, and user participation. Addresses gateway functionality that allows calls to connect from the LAN to the PSTN, as well as to other H.32x standards-based terminals. 2. This question can be answered with one key word – interoperability! The H.323 standard enables real-time multimedia communications and conferencing over packetbased networks. It is a comprehensive standard that covers the selection of audio and video codecs, shared applications, call control, and system control, allowing vendors to develop interoperable products for LAN-based audio and video communications. Essentially, it provides a method to enable other H.32x compliant products to communicate.

Exercise II The H.323 standard specifies four components. Do we need to have all of these components? If the answer is yes, specify the reason. If the answer is no, then discuss different cases, and why each of the components is used. 1. Can a gateway be used instead of a gatekeeper? Why? 2. Based on the size of a network, as well as the services to be provided, investigate the VoIP CISCO products and compare them. Start the discussion by using functional elements, and then match the products with the elements. 3. Do we have to use gateways when implementing PC or IP based phones?



4. Investigate the VoIP CISCO products related to each of the components we have discussed, and list the interfaces and capabilities. 5. For each of the four H.323 components, investigate the performance issues to take into consideration when designing a VoIP network. 6. Compare between the gateway and gatekeeper? 7. Can you describe how User Authentication through the gatekeeper might work?

Exercise III 1. 1. Give an example where the Bandwidth Change Request becomes necessary. Is it necessary to go through the Bandwidth Change Procedure if the bandwidth is to be decreased?


Chapter 4: Configuring Voice over IP


Chapter 4 Configuring Voice over IP FXS - Foreign Exchange Station Interface FXO - Foreign Exchange Office Interface E&M - Ear and Mouth Interface T1 Voice Connectivity (2600/3600/7200/AS5300) Voice Network Modules (VNMs) Different Types of Voice Interface Cards (VIC) VIC-2E/M VIC-2FXS VIC-2FXO Connecting VNMs and VICs to the Router 2600 Series Router Configurations 3600 Series Router Configurations Voice Port Cabling and Configuration Voice Numbering on the 2600 and 3600 series LED Status Configuring Voice Ports on the 2600/3600 Configuring FXO or FXS Voice Ports Configuring E&M Voice Ports Voice Port Tuning Commands Concepts of Delay and Echo Fine Tuning FXS/FXO Ports Fine Tuning of E&M Ports The Connection Command Direct Voice Trunking vs. Dial – Digit Interpretation Standard Dialing Analysis - Digit Interpretation Supervisory Disconnect Wink Start Signaling vs. Immediate Start Signaling



Dial Plans and Dial-Peers Dial Peers Call Legs POTS vs. Voice Network Dial Peers Creating and Implementing Dial Plans Number Expansion Basic Syntax of the Dial-Peer Command for POTS Basic Syntax of the Dial-Peer Command for VoIP Direct Inward Dialing (DID) VoIP QOS over Leased Lines IP Precedence Data Network Queuing Algorithms Queuing on Voice/Data Networks – Real-Time Transmissions Class Based Weighted-Fair Queuing (CBWFQ) IP RTP Priority Resource Reservation Protocol – RSVP RSVP Configuration IP Precedence vs. RSVP Multilink PPP (MLPPP) and Interleaving Compressed Real-Time Protocol – CRTP CODEC and Voice Activity Detection (VAD) VoIP QoS over Frame Relay Configuration of FRF.12 Fragmentation Frame Relay Traffic Shaping VoIP Troubleshooting Case Study 1 Case Study 2 Summary FAQs

Introduction file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (2 of 66) [13/12/02 18:19:04]


In this chapter, we will be discussing all of the steps required to configure a Voice over IP (VoIP) network from the ground up. In order to show the various stages of VoIP development, the following areas will be discussed:Solutions in this chapter: •

Types of Cisco hardware platforms that support basic Voice over IP

•

Types of Voice ports and Their Specific Uses

•

Dial Plan for your Company’s Voice Infrastructure

•

Developing Dial-Peer Programming on the Routers to Implement the Dial-Plan

•

Fine Tuning the Voice ports and Dial-Peers

•

Various Methods of Getting Voice Data Across the Network

•

Quality of Service Considerations and Implementations

•

Basic Frame Relay Standards and Methodologies

Different Types of Voice ports FXS - Foreign Exchange Station Interface The Foreign Exchange Station (FXS) port is configured with a standard RJ-11 connection port (see Figure 4.1). The FXS port is used to connect the router to standard telephony devices and endpoint stations, such as basic telephone equipment, keysets, or FAX machines. The FXS port can supply ring voltage, dial tone and other basic signaling to an end station.

FXO - Foreign Exchange Office Interface The FXO port is also configured with a RJ-11 connection port (see Figure 4.1 and Table 4.1). However, rather than supplying the signaling and voltage needed for basic telephony equipment, FXO ports are used to connect the IP network to offpremises equipment such as a PSTNs (Public Switched Telephone Networks) Central Office (CO) or to a PBX tie line interface. You can set several different parameters that are compatible with tie line features on a PBX.



Figure 4.1 RJ-11 Pinout. Table 4.1 RJ-11 Pinout Pin Signal 1 2 3 4 5 6

Ring Tip -

E&M - Ear and Mouth Interface The Ear and Mouth (E&M) interface is a RJ-48C type connector (Figure 4.2) that allows for connections specifically to PBX trunk lines (otherwise known as tie lines). The E&M interface can be programmed with special attenuation, gain and impedance settings that can conform to the specific attributes of different PBX systems. E&M is a signaling technique for 2-wire and 4-wire telephone and trunk lines. The connections and pinout specifications are listed in Table 4.2.

Figure 4.2 RJ48C Pinout. Table 4-2 E&M Pinouts

Pin Signal Description

Two-Wire Operation, Type 1 2 3 5

Four-Wire Operation, Type 1 2 3 5



1 2 3 4 5 6 7 8

SB -48V signaling battery M-lead Signaling input R Ring, audio input R or R1 Ring, audio input/output or output T or T1 Tip, audio input/output or output T Tip, audio input E-lead Signaling output SG Signaling ground return

M R

SB M R

SB M R

M R

M R R1

SB M R R1

SB M R R1

M R R1

T

T

T

T

T1

T1

T1

T1

E -

E SG

E SG

E -

T E -

T E SG

T E SG

T E -

T1 Voice Connectivity (2600/3600/7200/AS5300) T-1 voice connections are available for Cisco 2600, 3600, 7200 and AS5300 series equipment. The 2600, 3600, and 7200 series routers are capable of Voice over Frame Relay (VoFR) and VoIP. The AS5300 is able to perform VoIP, VoHDLC, or VoFR technologies. Voice channels within the T-1 (DS0 channels) are configured for VoFR or VoHDLC (these serial options are discussed further in this book). The controller t1 0 command is used to set up the T1 voice module for local trunk connections to a PBX or telephone company switch, and the mode command fine tunes what kind of framing and signaling the T-1 can expect. The 7200 series and AS5300 series are primarily used as tandem switch points from T-1 tie lines to PBXs and the PSTN to the IP internal network. The 2600 and 3600 router series are now also capable of performing this function because support for voice T1/E1 interfaces with up to two T1/E1 circuits per card has been added. The T1/E1 VXC network module card is used in the 7200 series routers and can support up to 2 T1s per card. The AS5300 series Access Switch uses the T1 carrier card that can support up to 4 T1s. The 7200 can be used to perform the function of T-1 termination for voice traffic into the WAN and can forward the signals and transmissions to the 3600, 2600 and AS5300 series routers for complete processing.

Voice Network Modules and Voice port Modules In order to implement VoIP on Cisco routers, it is first necessary to understand the different types of hardware and router ports required to use the VoIP technology. The Voice Network Modules and Voice Interface Cards use the VoIP commands to achieve voice communications on Cisco routers.



Voice Network Modules (VNMs) In order to install voice ports on the 3600 and 2600 series routers, equipment must be installed that can interpret analog signals to digital format for transmission over the IP network. The Voice Network Modules (VNMs) are designed to serve this purpose, and at least one VNM is needed to enable the router to handle voice traffic. There are two different models of Voice Network Modules (VNMs) for the 2600/3600 series routers: • Pictured here is a NM-1V – a one slot Voice Network Module. You can install one Voice Interface Card (VIC) in the NM-1V, providing up to two voice ports.

Figure 4.3 NM-1V Voice Network Module. • Also available is the NM-2V – a two-slot version of the Voice Network Module. You can also install up to two VICs in the NM-2V, providing up to four voice ports.

Figure 4.4 NM-2V Voice Network Module.

Different Types of Voice Interface Cards (VIC) There are several different VIC modules that work with the Voice Network Module to provide multiple types of functionality. The types of voice modules that



are currently available are described in this section, as well as some specifications used to differentiate them in the router. VIC-2E/M The two-port E&M module - VIC-2E/M - is typically used to connect an IP network directly to a PBX system. It is capable of being configured for special settings associated with tie line ports on most PBXs. E&M ports are always colorcoded brown. For IT Professionals E&M Port Doesn't Work on PSTN Do not connect an E&M port to the PSTN. This can cause disruptions and unpredictable results back at the STNs Central Office.

Figure 4.5 VIC-2E/M. VIC-2FXS The two-port Foreign Exchange Station (FXS) module - VIC-2FXS - is used to connect directly to endpoint equipment such as a telephone, keypad, or FAX. These ports provide special connectivity by providing ringing voltage, dial tone and other endpoint specific functionality. FXS ports are always color-coded gray. For IT Professionals FXS Port is not designed for PSTN Do not connect an FXS port to the PSTN. The FSX ports are not designed to handle direct connectivity to the PSTN.

Figure 4.6 VIC-2FXS. VIC-2FXO The two-port Foreign Exchange Office (FXO) module - VIC-2FXO - is typically used to connect to a PBX or PSTN. This is the type of interface that a standard file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (7 of 66) [13/12/02 18:19:04]


telephone provides. FXO ports are always color-coded pink. There are other types of FXO cards for use outside of North America which are capable of the switching and signaling techniques used in other geographic regions; VIC-2FXO-EU is intended for use in Europe, VIC-2FXO-M3 is intended for use in Australia. For IT Professionals FXO port should be approved for a particular PSTN or connected to PBX Connect only an FXO port approved for your country to the PSTN. Otherwise, connect an FXO port only to a PBX (connections from the PBX to the PSTN are permitted).

Figure 4.7 VIC-2FXO.

Connecting VNMs and VICs to the Router The new Cisco router standard is to use a chassis-based hardware format that can be customized to meet the needs of any business and scaled to any level of functionality. Depending on the needs of the individual business, there are different chassis formats to accommodate VoIP installations. The different types of router chassis’ are listed in this section. 2600 Series Router Configurations The 2600 series routers come in a variety of base configurations, which differ in the amount and/or type of standard network interfaces that are available (RJ-45 ports, serial ports, and ISDN ports). On all of the various configurations, there is only one slot for an additional Network Module. If it is decided that the Network Module slot is to be used for voice traffic, then that slot will support two to four voice ports, depending on the model of NVM used. Table 4.3 shows which revision of Cisco IOS needs to be installed to support the various voice modules on the 2600 series router. Table 4.3 WAN and Voice Interface Card Options with Cisco IOS Releases for Cisco 2600 Series Routers



WAN Interface Cisco IOS Card Release 11.3T 1-Port T1/FT1 11.3(4)T (WIC-1DSU-T1) 2-Port FXS voice/fax 11.3(1)T interface (VIC2FXS) 2-Port FXO voice/fax 11.3(1)T interface (VIC2FXO) 2-Port E&M voice/fax 11.3(1)T interface (VIC2E/M) 2-Port FXO voice/fax interface for use 11.3(6)T in Europe (VIC-2FXO-EU) 2-Port E&M voice/fax interface for use 11.3(6)T in Australia (VIC-2FXO-M3) 2-Port ISDN BRI voice interface (VIC-2BRI-S/TTE) 1-Port T1 multiflex trunk interface (VWIC-1MFTT1)

Cisco IOS Release 12.0

Cisco IOS Release 12.0T

-

12.0(1)T

12.0(1)

12.0(1)T

12.0(1)

12.0(1)T

12.0(1)

12.0(1)T

-

12.0(1)T

-

12.0(1)T

12.0(2)XD

-

-

12.0(4)T



1-Port E1 multiflex trunk interface (VWIC-1MFTE1) 2-Port T1 multiflex trunk interface (VWIC-2MFTT1) 2-Port E1 multiflex trunk interface (VWIC-2MFTE1) 2-Port T1 multiflex trunk interface with drop and insert (VWIC-2MFTT1-DI) 2-Port E1 multiflex trunk interface with drop and insert (VWIC-2MFTE1-DI)

-

-

12.0(4)T

-

-

12.0(4)T

-

-

12.0(4)T

-

-

12.0(4)T

-

-

12.0(4)T

3600 Series Router Configurations 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. Each slot can hold a maximum of four analog voice ports, therefore the breakdown of analog port capacity is as shown in Table 4.4: Table 4.4 3600 Series Network Module Capacity



Chassis Model

NM-1V Equipped Max # NM-2V Equipped Max # of Voice Ports of Voice Ports 3620 4 8 3640 8 16 3660 12 24 Note that these units also support digital T1 voice connectivity which will significantly increase the voice port density per box. Table 4.5 shows which revision of Cisco IOS needs to be installed to support the various voice modules. Table 4.5 WAN and Voice Interface Card Options with Cisco IOS Releases for Cisco 3600 Series Routers WAN Interface Cisco IOS Cisco IOS Cisco IOS Cisco IOS Cisco IOS Cisco IOS Card Release Release Release Release Release Release 11.1 11.2 11.3 11.3T 12.0 12.0T 1-Port Serial 11.1(7)AA11.2(5)P 11.3(1) 11.3(3)T 12.0(1) 12.0(1)T (WIC-1T) 1-Port T1 (WIC- 11.2(12)P 11.3(3)T 12.0(1)T 1DSU-T1) 11.3(1)T 12.0(1) 12.0(1)T 2-Port FXS voice/fax interface (VIC2FXS) 2-Port FXO 11.3(1)T 12.0(1) 12.0(1)T voice/fax interface (VIC2FXO) 2-Port E&M 11.3(1)T 12.0(1) 12.0(1)T voice/fax interface (VIC2E/M)



2-Port FXO voice/fax interface for use in Europe (VIC-2FXOEU) 2-Port E&M voice/fax interface for use in Australia (VIC-2FXOM3) 2-Port ISDN BRI voice interface (VIC2BRI-S/T-TE) 1-Port T1 multiflex trunk interface (VWIC-1MFTT1) 1-Port E1 multiflex trunk interface (VWIC-1MFTE1) 2-Port T1 multiflex trunk interface (VWIC-2MFTT1) 2-Port E1 multiflex trunk interface (VWIC-2MFTE1)

-

-

-

11.3(6)T -

12.0(1)T

-

-

-

11.3(6)T -

12.0(1)T

-

-

-

-

12.0(2)XD-

-

-

-

-

-

12.0(4)T

-

-

-

-

-

12.0(4)T

-

-

-

-

-

12.0(4)T

-

-

-

-

-

12.0(4)T



2-Port T1 multiflex trunk interface with drop and insert (VWIC-2MFTT1-DI) 2-Port E1 multiflex trunk interface with drop and insert (VWIC-2MFTE1-DI)

-

-

-

-

12.0(4)T

-

-

-

-

12.0(4)T

Voice Port Cabling and Configuration When configuring Cisco chassis based routers, it is essential that the numbering of the slots and function cards is understand to properly program the configurations. The Cisco router numbering scheme is covered in this section.

Voice Numbering on the 2600 and 3600 series Cisco IOS configuration commands identify voice ports using the following syntax: voice port router-slot/voice-slot/VIC-port.

How these port numbers are determined is defined below in Figures 4.8, 4.9 and 4.10.

Figure 4.8 3640 chassis slot numbering scheme.



Figure 4.9 NM-2V slot numbering scheme.

Figure 4.10 VIC port numbering scheme. For example: if you were to install two voice interface cards in a NM-2V module in the third slot on a 3640 chassis, the port numbers would be 3/0/0, 3/0/1, 3/1/0 and 3/1/1. The idea is to follow the Network Module slots from right to left, bottom to top. The Network Modules themselves have their slots numbered 0 and 1, from right to left, respectively. The VICs use the same method for their numbering. To be sure that you have the proper port numbering, use the show voice port or show running-config commands to view the voice port numbering scheme as seen by the router. LED Status The VICs come with LEDs to help troubleshoot hardware responsiveness. There is only one LED per Voice Port, and it represents an active or dormant status. When the LED is lit green, the Port has an active signal on it. When the LED is off and the port is in a dormant state. Configuring Voice Ports on the 2600/3600 We have now discussed the basic hardware installation for the VNMs and VICs. The next step is to configure the cards on the Cisco router IOS. The configuration of the voice cards is covered in the following sections. Configuring FXO or FXS Voice Ports There are some basic configuration parameters that must be set in order for a voice port to operate. All of these parameters have default settings and in most cases, 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: file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (14 of 66) [13/12/02 18:19:04]


•

Signal Type

•

Call Progress Tone

•

Ring Frequency

•

Ring Number •

Dial Type (FXO only)

Follow the steps listed in Table 4.6 to complete a basic setup for all FXS/FXO voice ports. Table 4.6 Basic Setup for All FXS/FXO Voice Ports Step # Related Command Description 1 Enter into Global Config configure terminal mode 2 Identify which port to voice-port nm-module/vic-module/portconfigure number 3 Selects the appropriate signal [loop-start|ground-start] signaling for the start of a call 4 Selects the appropriate cptone country-code country codes for call progression signaling. The default is northamerica. The following steps listed in Table 4.7 are also needed to configure FXO ports. Table 4.7 Configuring FXO Ports Step # Related Command 1 Dial-type [dtmf|pulse] 2

ring frequency [25| 50]

Description Assign the appropriate outdialing dial-type Frequency in Hertz of ringing for the system to which the FXO port is attached.



3

ring number number

Max number of rings allowed before answering a call. There are optional configurations for FXS/FXO ports that may or may not be necessary depending on the particulars of your network setup. The following settings are for usability and convenience and are not mandatory for the voice port to operate: •

PLAR Connection Mode

•

Music Threshold

•

Description • Comfort Noise (Only if VAD is activated at the Dial-Peer level. See Voice Activity Detection for more information later in this chapter.)

Use the commands shown in Table 4.8 to adjust any of these optional settings. Table 4.8 Adjusting Configuration Settings for FXS/FXO Ports Step # Related Command Description 1 Specifies that the port is connection plar string configured for private line auto ringdown (PLAR) – for more information on PLAR see section later in this chapter 2 Threshold in decibels for music-threshold number hold music. 3 Description field for port description string 4 Background noise comfort-noise generated for the comfort of a user when there is no noise. Configuring E&M Voice Ports Contrary to FXS/FXO defaults, E&M default settings are usually NOT sufficient to enable voice transmissions over IP. This is because E&M ports are designed to file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (16 of 66) [13/12/02 18:19:04]


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: •

Dial Type

•

Signal Type

•

Call Progress Tone

•

Operation

•

Type •

Impedance

Follow the steps depicted in Table 4.9 to complete a basic setup for all E&M voice ports: Table 4.9 Basic Setup for all E&M Voice Ports Step # Related Command 1 configure terminal 2 3

Voice-port nm-module/vic-module/portnumber signal [wink-start|immediate|delay-dial]

4

cptone country code

5

Dial-type [dtmf|pulse]

6

operation [2-wire|4-wire]

Description Enter into Global Config mode Identify which port to configure Selects the appropriate signaling for the interface Selects the appropriate country codes for call progression signaling. The default is northamerica. Assign the appropriate outdialing dialtype Cabling scheme selection (see Table 4-2)



7

type [1|2|3|5]

Selects the appropriate E&M interface type (see Table 42) 8 Specifies the termination impedance impedance which needs to [600c|600r|900c|complex1|complex2] match the specifications of the PBX it is attaching to. There are optional configurations for the E&M port that 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 commands shown in Table 4.10 to adjust any of these optional settings. Table 4.10 Adjusting Configuration Parameters for E&M Port Step # Related Command Description 1 Specifies that the port is connection plar string configured for private line auto ringdown (PLAR – see section later in this chapter) 2 Threshold in decibels for Music-threshold number hold music. 3 Description field for port description string 4 Background noise Comfort-noise generated for the comfort of a user when there is no noise. Voice Port Tuning Commands file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (18 of 66) [13/12/02 18:19:04]


Depending on the special needs of your VoIP environment, different variables may first need to be adjusted to allow fine-tuning of the voice transmissions. Voice port fine-tuning commands are instructions to the voice port that adjust timing, delay, impedance parameters, input gain and output attenuation. Once these adjustments are made, you can fine tune such aspects of your transmission as 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 that it involves the transmission of real-time traffic. Speech patterns will become awkward and nondistinguishable if there is too much delay in the voice traffic. Delay is a natural phenomenon of data trafficking, and several factors inherent in any network will cause delay factors. The idea is to minimize delay as much as possible to get the voice traffic as close to real-time as possible. In today’s voice trafficking there are two different kinds of delay that need to be handled: fixed delay and variable delay. Fixed delay is the amount of time the signal needs to transverse whatever media is being utilized to send the signal, as in copper, fiber, or microwave. This time is fixed because the laws of physics dictate how fast the data signals will go on whatever media they are traveling on. Fixed delays should be kept below 150ms one-way per ITU G.114. Fixed delays are composed of CODEC, packet generation, and serialization. Variable delays are synonymous with jitter and are caused by queuing variances during the transmission of a packet through the network. Voice packets share the bandwidth with larger data packets, so as the packets are transferred out of the queue there can be a delay between voice packets that sounds like stuttering speech. This is called jitter. QoS features can be used to alleviate the effects of jitter by prioritizing the voice traffic. Therefore, the best place to reduce delay factors is in the variable delay. • CODEC induced delay – the time it takes for the compression/decompression of a voice packet from analog to digital format and back to analog again. The delay amount ranges from 0.75 ms to 30 ms depending on the type of CODEC used. • Packet Generation delay – the time it takes for the equipment to actually produce a data packet. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (19 of 66) [13/12/02 18:19:04]


• Router Latency – the time it takes for a packet to exit the output queue of the device that is routing the data. This is measured from the time the data is generated on the input queue to when it is released by the output queue. • Jitter – the amount of time between the expected arrival of a voice packet and the actual arrival of a voice packet. Excessive jitter can cause a disruption in real-time speech patterns. Echo is defined as hearing your own voice reflected back to you over the receiver of the telephony equipment. A certain amount of echo is acceptable and desirable because it helps assure the end user of his speech patterns. Too much echo will cause a disruption because the speaker will not be able to discern between his speech and the echo signals. Too little echo will cause a disruption because the end user will not hear his own voice. (This is a common problem in cellular phone technology.) See the echo-cancel commands outlined in the following sections to adjust the amount of echo on an interface. Fine Tuning FXS/FXO Ports Special parameters can be adjusted to fine tune the ports which will minimize some of the issues involved with 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 the steps outlined in Table 4.11. Table 4.11 Adjusting Fine-Tuning Parameters for FXO/FXS Port Step # Related Command Description 1 Enter into Global Config configure terminal mode 2 Identify which port to voice-port nm-module/vic-module/portconfigure number 3 In decibels; specifies the input gain value amount of receiver gain on the interface. Value can be –6 to 14. 4 In decibels; specifies the output attenuation value amount of transmit attenuation on the interface. Value can be 0 to 14. 5 Enables echo-cancellation echo-cancel enable] for voice signals sent out of the interface and received back on the same interface. Excessive echo can cause disruption to normal conversation patterns. This is often a problem on cellular phone technology. 6 In milliseconds; adjusts the echo-cancel coverage value size of the echo-cancel. Values are 16, 24, or 32. 7 Used in conjunction with non-linear echo-cancel. Enables “nonlinear” processing, which shuts off any signal if no speech is detected on the near-end.



8

timeouts initial seconds

9

timeouts interdigit seconds

10

timing digit milliseconds

11

timing inter-digit milliseconds

12

timing pulse-digit milliseconds

13

timing pulse-inter-digit milliseconds

How long the system is going to wait for the first digit to be input by the user after an off-hook state is detected. Can be anywhere between 0 to 120. How long the system is going to wait for subsequent digits after the initial digit is received. Can be anywhere between 0 to 120. For DTMF digit signals. How long the digital signal lasts. Range is from 50 to 100, with a default of 100. For DTMF digit signals. How long of a delay between digit signals. Range is from 50 to 100, default of 100. For FXO ports only using pulse signals. Length of pulse signal. Range is 10 to 20, default is 20. For FXO ports only using pulse signals. How long of a delay between digit signals. Range is from 100 to 1000, default of 500.

Fine Tuning of E&M Ports There are some added features that always need to be adjusted for the E&M ports. Contrary to the default settings of the FXO/FXS ports, in most cases E&M ports in most cases will require fine-tuning adjustments. Follow the steps outlined in Table 4.12 to fine tune E&M ports.



Table 4.12 Fine-Tuning E&M Ports 1 configure terminal 2 3

voice-port nm-module/vic-module/portnumber input gain value

4

output attenuation value

5

echo-cancel enable

6

echo-cancel coverage value

7

non-linear

Enter into Global Config mode Identify which port to configure In decibels; specifies the amount of receiver gain on the interface. Value can be –6 to 14. In decibels; specifies the amount of transmit attenuation on the interface. Value can be 0 to 14. Enables 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. This is often a problem on cellular phone technology. In milliseconds; adjusts the size of the echo-cancel. Values are 16, 24, or 32. Used in conjunction with echo-cancel. Enables “nonlinear” processing, which shuts off any signal if no speech is detected on the near-end.



8

timeouts initial seconds

9

timeouts interdigit seconds

10

timing digit milliseconds

11

timing inter-digit milliseconds

12

timing pulse pulse-per-second

13

timing pulse-inter-digit milliseconds

15

timing delay-duration milliseconds

16

timing delay-start milliseconds

How long the system is going to wait for the first digit to be input by the user after an off-hook state is detected. Can be anywhere between 0 to 120. How long the system is going to wait for subsequent digits after the initial digit is received. Can be anywhere between 0 to 120. For DTMF digit signals. How long the digit signal lasts. Range is from 50 to 100. For DTMF digit signals. How long of a delay between digit signals. Range is from 50 to 500. Used for pulse dialing only. Specifies the pulse dialing rate. Ranges from 10 to 20. Used for pulse dialing only. How long of a delay between digit signals. Range is from 100 to 1000. Delay signal for delay dial signaling. Ranges from 100 to 5000. Minimum time for outgoing seizure to outdial address. Ranges from 20 to 2000.



17

timing delay-pulse min-delay milliseconds Time between generation of “wink-like” pulses. Ranges from 0 to 5000. 14 Specifies the minimum timing clear-wait milliseconds amount of time between the off-hook signal and the call being completely cleared. Ranges in value from 200 to 2000. 15 Delay signal for delay dial timing delay-duration milliseconds signaling. Ranges from 100 to 5000. 16 Max wink-wait duration. timing wink-duration milliseconds Ranges from 100 to 400. 17 Max wink-wait duration timing wink-wait milliseconds for wink-start signal. Ranges from 100 to 5000. Now that all of the voice ports have been individually configured on the network, the task of getting voice packets from one router to another needs to be addressed. To accomplish this we need to look at voice routing methods such as direct dial, trunking, and Private Line Automatic Ringdown (PLAR).

The Connection Command The connection command in Voice Port configuration mode allows for special modes to be set for specific voice ports. If the connection command is not configured, the session application assumes that there is a “standard” connection being initiated and it will output a dial tone when the interface senses an off-hook state. The dial tone will last until enough digits are collected to match a dial-peer and complete the call or until the timeout for digit entry is met. The syntax for the connection command is as follows: connection [plar | tie-line | trunk | plar-opx] string

Note: string - represents the destination telephone number. plar (Private Line Automatic Ringdown) - Used to automatically dial a



destination pattern as soon as the receiver on the phone is lifted and the port is activated. No digits need to be entered to establish the connection. An example of this is if the user picks up the handset and the call is automatically placed to the far-end. tie line (Specific to the Cisco MC3810) - Specifies that the particular port is a tie line connection to a private branch exchange (PBX). It is used on the MC3810 when a dial plan requires that additional digits are added in front of any digits dialed by the PBX and the combined set of digits are used to route the call via the dial-peers settings and into the network. trunk (Specific to the Cisco 3600) - Specifies that the particular port is a straight tie line connection to a PBX. The “connection trunk” mode can be used for E&M-E&M trunks, FX0-FXS trunks, and FXS-FXS trunks. It should be noted that signaling will be transported for the E&M-E&M and FXO-FXS trunks, but not for FXS-FXS trunks since they do not support signaling parameters between them. plar-opx (Specific to the Cisco MC3810) – Specifies a PLAR connection to an off-premises extension. Using this option, the local voice port provides a local response before the remote voice port receives an answer. This ensures that the call is answered before the call flow is completed.

Direct Voice Trunking vs. Dial – Digit Interpretation Trunking is a service that allows semitransparent connections between two PBXs, a PBX and a local extension, or some other combination of telephony devices that will be permanently conferenced together. There is no need to analyze the dialed digits for a destination pattern since the connections are set up to be permanently trunked together and data will automatically be passed between the two interfaces. Consequentially, routing analysis by a router is unnecessary when using trunking since the connection is perpetually up all the time. Following are some advantages and disadvantages to using trunking technology: • Advantage: Less overhead on the routers that are passing the traffic. The destination patterns need not be interpreted or analyzed to determine the destination path. The packets are simply passed on to the PBX for analysis and interpretation. • Disadvantage: No control of the packets that are coming in. The external PBX will handle all of the end station routing. Any fine-tuning of the voice ports



or special configurations are not useable in this mode. • Disadvantage: Special attention must be placed on CODEC management. By passing information on trunk connections, all CODECs will need to match along the entire path of transmission. If the trunking is being performed with a centralized tandem switch, then encoding/decoding needs to be consistent to ensure no data corruption occurs when analog:digital:analog encoding occurs. Proper CODEC must be used for each FXO port connected to the tandem switch. Standard Dialing Analysis - Digit Interpretation If trunking is not being used, the router that receives an initiating call signal will need to access and analyze the incoming dialed digits (destination pattern) of the receiving entity. The router will in turn use its dial-peer configurations to determine where to route the call over the IP network. There are advantages and disadvantages to using this method as well: • Advantage: the routing of the calls is completely controlled by the routing architecture, which allows for greater control and fine-tuning of the VoIP system. There is more control over QoS levels since routing can be fine tuned down to a destination pattern and an IP port. • Disadvantage: More overhead on the routers in the VoIP network since the processors must interpret the dial-peers rather than just pass on the data in a trunking format. • Disadvantage: More latency in passing packets through the system because the router must interpret all of the calls.

Supervisory Disconnect Supervisory disconnect is a form of signaling that shuts off the power from the attached switch. The system interprets this as a disconnect indication and will clear the call. The switch maintains this state for 350 ms to ensure the proper reset of the port. The supervisory disconnect command is used on FXO ports. The switch that is attached to the FXO port needs to support supervisory disconnect to function properly. Without supervision over disconnect conditions on the FXO port, the



interface can remain open if the originating caller hangs up before the receiving entity answers the call. After the router collects the destination pattern and before the receiving entity answers the signal, the router will initiate a tone-detecting mode. While the call leg connection is being completed, the router will listen for signals indicating that the originator has hung up. If the “hang up” is indicated, the router will stop the call leg completion window automatically and disconnect the call. FXO/FXO connections are not supported because there is no mechanism to pass supervisory disconnect information between this combined pair.

Wink Start Signaling vs. Immediate Start Signaling Wink start is a signaling protocol used between switches in which the receiving end reverses polarity (winks) momentarily. The wink is a signal to the transmitting end that dialed digits are ready to be received. A wink start occurs between a DID, two WATS trunks, or E&M tie lines with an interface trunk. You can modify the wink duration (how long the wink state lasts) by using the timing wink-duration command and the wink wait duration (how long to wait for a wink state before disconnect) by using the timing wink-wait command. Immediate start is a signaling protocol used between switches in which the receiving end must be ready to receive the dialed digits immediately (within 70 ms) after line seizure. There can be no delay between the two actions or the call will be canceled.

Dial Plans and Dial-Peers We are now ready to start programming the VoIP routers with the routing required to place and connect voice calls over IP. This involves the development of “dialpeers”, which define the attributes of the “call legs” initiated by the source and destination routers.

Dial Peers Dial peers are the configurations placed on a VoIP router that define how a set of dialed digits are interpreted and routed out to the router ports on call legs. Dial peers define different attributes of the call legs such as QoS (Quality of Service), compression/decompression (CODEC), Voice Activation Detection (VAD) and other attributes.

Call Legs file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (28 of 66) [13/12/02 18:19:05]


The term call legs refers to one of the connections described in the previous section for Plain Old Telephone System (POTS) and VoIP dial peers. A call leg is a discrete segment of the call connection between two points of the connection such as a telephony device, PBX, PSTN, or router. There are four call legs to every established call, two from the perspective of the Source Router and two from the perspective of the Destination Router (Figures 4.12 and 4.13).

Figure 4.12 Dial Peer Call Legs as seen from Source Router.

Figure 4.13 Dial-Peer Call Legs as seen from Destination Router. POTS vs. Voice Network Dial Peers There are two different types of dial-peers that can be configured on a VoIP network: POTS and Voice Network (VoIP) connections. • POTS (Plain Old Telephone System) - dial-peer represents an access port that is wired to a phone set or some similar telephony device locally attached to the router. This connection will interpret or “play out” all of the dialed digits from the sending entity and interpret them to see if they are destined for the dial-peers’ particular port. • A VoIP dial-peer represents a connection that will be routed to another voice enabled router on the network. In this case there is no need to have the port interpret the dialed digits, this will be handled by the receiving entity at the other end of the VoIP connection. Therefore the VoIP dial-peer will simply pass all of the digits to the receiving entity.



The following is a step-by-step scenario of two routers establishing a call over VoIP: • Step 1 The user picks up the handset on a phone. This triggers an offhook condition at the Cisco router, which occurs on the signaling application level of the Cisco IOS on VoIP. • Step 2 The session application level issues a dial tone to the phone and waits for the user to dial the destination telephone number. • Step 3 The user dials the telephone number. This is seen as a discrete step because if there is a timeout condition then the dial tone will be deactivated and Step 3 will not be initiated. • Step 4 Once enough digits have been dialed and stored to allow for interpretation, the telephone number is mapped to an IP host by the dial plan mapper, matched to a VoIP dial-peer statement, and directed to the terminating voice router. The receiving router will have a direct connection to the final end station via a FXS port, a PBX, or a PSTN via an FXO or E&M port. This mapping of a physical port to a destination phone number is defined by dial-peer POTS commands. • Step 5 The session application will initiate an H.323 session protocol to establish receive and transmit channels for each direction of the call on the network. If the call is handled by a PBX at the endpoint, the PBX will handle the transmissions to the end user phone. If RSVP QoS has been configured on the voice port, the reservations are activated at this time. • Step 6 CODEC activation occurs at both ends of the transmission path to ensure proper compression/decompression algorithms are maintained. • Step 7 The setup is complete and all call-progress indications and signaling are passed immediately through to the receiving entity for interpretation or presentation. • Step 8 When either end of the calling session gives an “off-hook” signal, the session will end. If there were any RSVP sessions being used for the call,



they are torn down at this time. Both ends of the circuit go back to a “dormant” state and wait for another initiation session to begin.

Creating and Implementing Dial Plans A dial plan is a template from which your company can implement the VoIP routing structure. Each routed area of the business will be assigned a set of phone numbers, along with an area code, and other shortcuts such as quick dialing features that allow calling parties to reach the calling area without dialing the entire number. Before a VoIP network can be implemented, all of the voice parameters, phone numbers, and dialing conveniences, need to be identified and planned out ahead of time. This will exponentially decrease the time needed for implementation and troubleshooting of the new VoIP network (Figure 4.11).

Figure 4.11 Diagram of a simple Voice over IP network. For the network in Figure 4.11, an example dial plan can be laid out as shown in Table 4.13. Table 4.13 Dial Plan for a Simple VoIP Network Router/Dial Number Destination Type Voice Session CODECQoS Peer Tag Expansion Pattern of Port Target Method Number Extension Peer Router A 1 1…. +1212222…. POTS 1/0/0 2 2…. +1212223…. POTS 1/0/1 3 3…. +1212224…. POTS 1/1/0 4 +1206555…. VoIP IPV4:10.0.0.2G.729 Best Effort



Router B 1 2 3 4 5

+12065551000POTS +12065551001POTS +12065551002POTS +12065551003POTS +1212…….. VoIP

1/0/0 1/0/1 1/1/0 1/1/1

IPV4:10.0.0.1G.729 Best Effort This dial plan will simplify the design and installation of the routers involved and the programming needed to make VoIP work on this network.

Number Expansion In most corporations, it is not necessary to dial the entire phone number to reach an individual within the company. Instead, a small portion of the number that is unique to that station, can be dialed. Let's look at Figure 4.11 again: User A in Seattle is trying to reach User B in New York over a Voice over IP network. Without number expansion, User A would have to dial User B’s entire destination patter: 1 212 222 1000. To make the process easier and increase the usability of the network program in the num-exp command on the dial-peer configuration as follows: num-exp 2…. +1212222…. (“….” are wildcard characters for extended numbers) Now, when User A dials a destination pattern of “2….”, the sequence will automatically be expanded to the destination pattern “+1212222….”. This can be used for any unique number set on the network. To activate this feature properly, certain factors that need to be considered. For instance, it is not required that the number expansions be unique throughout the network. It is possible to have “2….” expand out to “+1212222….” on one router and then have “2….” expand out to “+1206222….” on another router. This will cause confusion to the user environment and should be avoided. When working out your dial plan, try to keep all number expansions unique on the VoIP network. Basic Syntax of the Dial-Peer Command for POTS We now have the basic concepts of the different parameters that dial-peers are used for. It is time to put the parameters into action. To enter into dial-peer configuration mode for any POTS ports, use the procedure depicted in Table 4.14 from global configuration mode. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (32 of 66) [13/12/02 18:19:05]


Table 4.14 Entering into the Dial-Peer Configuration Mode for a POTS Port Step # Related Command Description 1 Enters the dial-peer mode dial-peer voice tag-number pots for POTS peer. Tagnumber is a unique decimal number that identifies the peer. It is only held by the local router, so you can use the number on another router without affecting the current configuration. 2 Defines the telephone of destination-pattern string the POTS peer. Example: +12065551111. There are no dashes or spaces in destination patterns and they are always preceded by a “+” sign. 3 Specific voice port number port slot-num/VNM-num/port 4 (Optional) Used only to direct-inward-dial specify direct inward dialing activation for the port. See DID section following in this chapter. Basic Syntax of the Dial-Peer Command for VoIP To enter into dial-peer configuration mode for any VoIP ports, use the procedure depicted in Table 4.15 from global configuration mode. Table 4.15 Entering into Dial-Peer Configuration Mode for a VoIP Port Step # Related Command Description



1

dial-peer voice tag-number voip

2

destination-pattern string

3

session target [ipv4:destinationaddress|dns:host-name]

Enters the dial-peer mode for voip peer. Tag-number is a unique decimal number that identifies the peer. It is only held by the local router, so you can use the number on another router without affecting the current configuration. Defines the telephone of the POTS peer. Example: +12065551111. There are no dashes or spaces in destination patterns and they are always preceded by a “+” sign. Defines the remote IP host that will handle the call for the defined destination pattern. The target can be defined by an IP address or a DNS name.

Direct Inward Dialing (DID) Direct Inward Dialing is a system that allows voice customers to have many private voice numbers allocated to the business and at the same time lower costs by reducing the number of actual lines needed to service those numbers. Without DID, the customer would need one line installed from the provider per private extension number. If the lines cost $45/line and the customer needs at least 100 extensions to be defined, then their phone bill will be $4500/month! With DID, the provider assigns a bank of private extension numbers and then a reduced number of DID trunks into the business that are logically linked to that DID bank. When someone calls one of the numbers in the DID bank, the first circuit in the DID trunk is tested for an open line and if it is free the call will be connected. If it is not free, the rest of the circuits in the DID trunk will be checked until a free one is located, then the call will be connected. In the case of all circuits busy, the caller will receive a busy signal. With this scenario, if the DID trunk has



10 lines at $85/line, and a bank of 100 numbers is billed at $0.15/number, then the total cost of the same amount of lines with DID is $850/month, a significant reduction in costs. The trick to using DID over VoIP is that the router know to pass the DID information directly over to the DID enabled PBX for processing, and to not tone out the data in the packet. To do this tell the dial-peer that it is DID enabled. In a normal call setup, the switching device that handles the calls sends a dial tone to the caller and starts to receive digits for the destination phone number. Once it has collected the digits it will interpret them and send the transmissions to the proper IP endpoint. There are some cases when a dial tone does not need to be presented to the caller, such as a pre-programmed extension that is already known to the switching engine. In these cases, the Direct Inward Dialing (DID) algorithm is used to route the call. The algorithm uses three different inputs and four different dial-peer attributes to associate the incoming call with a direct dial entity. The three input values are: • The called number (DNIS) - a set of numbers representing the destination of the transmission. • The calling number (ANI) - a set of numbers representing the origin of the transmission. •

The voice port carrying the call

The four defined dial-peer attributes are: • Destination Pattern representing the phone numbers to which the peer can connect. • Answer-Address representing the phone numbers from which the peer can connect. • Incoming call-number representing the phone numbers that associate an incoming call leg to a peer based on the DNIS. •

Port the voice port through which the call originates.



For all peers that match the dial-peer call type (VoIP or POTS), the algorithm follows this pseudo-code: If the type is matched, match the called number with the incoming callnumber Else if the type is matched, match the calling-number with answer-address Else if the type is matched, match the calling-number with the destination pattern Else if the type is matched, match the voice port to port The algorithm will match the DNIS with one of the predefined destination parameters and automatically route the call.

VoIP QOS over Leased Lines We now have the ability to completely configure the hardware and software for Voice over IP. Unfortunately, it is rarely that easy to get VoIP to work efficiently. It was stated earlier in this chapter that Voice over IP transmissions need special consideration because they are “real-time” traffic. They cannot afford the same delay time as regular data packets. Therefore, the next step in configuring VoIP is to ensure that the data transmissions are as close to “real-time” as possible. This is where Quality of Service, or QoS, and queuing comes into play.

IP Precedence IP Precedence is a definable parameter on dial-peers that will give a priority value on the CBWFQ network. It is manually assigned to the particular dial-peer in VoIP configuration mode as follows: dial-peer voice 10 VoIP IP precedence 5 This command should be used to give voice IP packets more priority than standard data packets when they use the same available bandwidth. You should also use IP precedence when RSVP is not being used to ensure proper real-time response. In the following sections, you will see how IP Precedence settings affect the Class Based Weighted Fair Queuing algorithms and how they will help achieve greater performance on the voice data transmissions.



Data Network Queuing Algorithms TCP is designed to give a fully reliable, verified transmission protocol. As such, it is transmission sensitive and needs to have a certain response from the network in order to function. Too much delay on TCP transmissions can cause data loss, packet loss, and loss of connectivity. If there are no controls in place to assure the proper delivery of TCP packets, then there is no way to guarantee the reliability of the network. One of the concerns Cisco faced when designing an IOS to handle TCP traffic was how to manage the traffic so that all applications and conversations were given a fair shot at the available bandwidth on the network. If there were no controls in place, “heavy” data streams would consume all of the bandwidth and smaller data streams would never have a chance of getting the transmissions through to their destinations. In order to alleviate this problem on traditional data networks, Cisco implemented three different queuing algorithms to control the flow of data between network nodes: Weighted Fair Queuing, Priority Queuing, and Custom Queuing. Weighted Fair Queuing (WFQ) is an algorithm that considers several parameters of network data streams. It does not take into account what type of traffic or what application is generating the traffic, it only cares about how much traffic is being generated in a conversation. WFQ will give precedence on the output port to the “smallest” data stream in the queue, thus allowing the “smaller” data stream to complete its transmissions without waiting for bandwidth that would be consumed by the “larger” data stream. This way, all conversations have a “weighted fair” chance at using the available bandwidth. WFQ is the default queuing method on Cisco routers on interfaces less than 2 Mbps. The “weight” in WFQ is controlled by setting IP Precedence bits with the following equation: Weight = 4096/(1+ip prec) IP Precedence bits are the first three bits in the TOS field of the IP header and range from 0 (low) to 7 (high). Using the command “show queue serial 0/0” we can observe the individual flow being handled by the WFQ process. router#show queue se 0/0 Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queuing strategy: weighted fair Output queue: 31/64/0 (size/threshold/drops)



Conversations 2/4 (active/max active) Reserved Conversations 0/0 (allocated/max allocated) (depth/weight/discards/interleaves) 24/4096/0/0 Conversation 184, linktype: ip, length: 1504 source: 10.1.1.2, destination: 10.3.3.1, id: 0x04CF, ttl: 31, TOS: 0 prot: 6, source port 1503, destination port 21 (depth/weight/discards/interleaves) 2/4096/0/0 Conversation 227, linktype: ip, length: 68 source: 10.2.2.2, destination: 10.1.1.1, id: 0xFCCF, ttl: 31, TOS: 0 prot: 17, source port 52601, destination port 49608

Note that in this example there are two flows, each with a weight of 4096. Since both of the flows have the same weight they have equal and ‘fair’ access to the available bandwidth. Now we can mark high priority traffic such as voice with IP Precedence bits: router#show queue se 0/0 Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queuing strategy: weighted fair Output queue: 9/64/0 (size/threshold/drops) Conversations 2/7 (active/max active) Reserved Conversations 0/0 (allocated/max allocated) (depth/weight/discards/interleaves) 1/585/0/0 Conversation 90, linktype: ip, length: 68 source: 10.1.1.2, destination: 10.3.3.1, id: 0x0064, ttl: 255, TOS: 192 prot: 17, source port 16384, destination port 16384 (depth/weight/discards/interleaves) 8/4096/0/0 Conversation 219, linktype: ip, length: 1504 source: 10.2.2.2, destination: 10.1.1.1, id: 0x1C7E, ttl: 31, TOS: 0 prot: 6, source port 52601, destination port 21

Note that the first flow (VoIP) has a lower weight in the WFQ model and, in turn, a higher priority and a greater share of the bandwidth. Priority Queuing (PQ) is an algorithm that the network administrator can configure using extended access lists to define how traffic is defined. Once the traffic has been sorted, it is assigned to one of three different queue levels: high, medium, and low. There is also a management level queue that gives certain control traffic precedence so that routing can be maintained. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (38 of 66) [13/12/02 18:19:05]


Custom Queuing (CQ) is similar to Priority Queuing, but adds more control by allowing the network administrator to define not just a priority queue, but also apply an actual percentage of minimum bandwidth to different types of traffic on the network.

Queuing on Voice/Data Networks – Real-Time Transmissions With the addition of voice traffic to traditional data networking, the default method of WFQ is not enough to guarantee quality transmissions. Originally, data networking was not concerned about voice quality and “real-time” transmissions. If the data was late getting to its destination, it was not as apparent to the end user as a voice skipping out on a phone. The transmission may have taken longer to load onto the computer, but to a human perspective it was unnoticeable. To allow for real-time transmissions of voice packets, however, the level of reliability for queuing and transmission bandwidth has to be increased. Priority and Custom queuing could handle the problem, but implementing these features could cause other problems in the network. If new data type packets•a new application or IP segment•appear on the network, PQ and CQ would require modification all over the network to allow for the new data type.

Class Based Weighted-Fair Queuing (CBWFQ) Weighted-Fair Queuing would still be the ideal queuing algorithm for voice/data networks but unfortunately it classifies traffic based on individual flows which is not optimal for voice transmission. A problem is presented when there are large amounts of background flow relative to the Voice over IP flows. Consider the following example: In order to calculate the bandwidth that is allocated to a flow in WFQ the following formula can be used: Flow A Bandwidth = (flow a parts/sum of flow parts) x circuit bandwidth Where the individual flow parts = 1 + IP Precendence IP Precedence 0 1 2 3 4

Flow “Parts” 1 2 3 4 5



5 6 7

6 7 8

So considering an example where we have a 56K link with 2 VoIP flows at 24Kbps each, and marked with a default of an IP precedence 0 and 2 FTP flows at 56K also marked with an IP Precedence of 0, then according to the formula each voice flow would receive: 14Kbps = (1 / 4) X 56Kbps This is clearly not enough to support the 24Kbps voice flows. We can correct this problem by increasing the IP Precedence of the voice flows to 5 so that each voice flow receives: 24Kbps = (6 / 14) X 56K This works well until the number of FTP flows increases and once again reduces the amount of bandwidth available to the voice flows. According to the formula, if the number of FTP flows increases to 4 the bandwidth available to the voice flows is now: 21Kbps = (6 / 16) X 56K Which again is not enough to support the 24Kbps voice flows. Class Based Weighted-Fair Queuing was developed to solve this problem. Notice that in the example the problem arises when we queue individual flows, as the flows increase all flows get a smaller proportional slice of the total bandwidth. The solution is to classify traffic into a fixed number of classes and perform the WFQ algorithm between these classes. With CBWFQ up to 64 classes can be defined and since the number of classes is no longer a variable the problem outlined previously no longer presents itself. By placing all real-time voice flows in a single high priority class and other background traffic in a lower priority class and instructing CBWFQ to provide a specific amount of bandwidth to each type of traffic, voice can be serviced with a guaranteed level of QoS.

IP RTP Priority The IP RTP priority command allows you to assign a strict bandwidth level file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (40 of 66) [13/12/02 18:19:05]


guaranteed to the voice traffic. The feature must used with discretion because all subsequent traffic will be restricted to the remaining bandwidth available. This amount of bandwidth is guaranteed to voice traffic enqueued in the priority queue. (This is the case whether you use the IP RTP priority feature with CBWFQ or WFQ.) IP RTP priority closely monitors the use of bandwidth for the priority queue, ensuring that the allocated amount is not exceeded in the event of congestion. Once the allocated bandwidth level has been reached, IP RTP priority will stop the transmission of any additional packets. In fact, RTP will start dropping the excessive traffic which would cause serious degradation of the voice traffic. To avoid packet drop, be certain to allocate to the priority queue the most optimum amount of bandwidth, taking into consideration the type of CODEC used and interface characteristics. IP RTP priority will not allow traffic beyond the allocated amount. The best way to handle priority queuing is to determine the expected bandwidth need and then allocate a small amount more than that level. For instance, if your calculation determines that the voice traffic will normally consume 24 Kbps, allocate 25 Kbps to ensure proper queuing levels. The IP RTP priority admission control policy does take RTP header compression into account. Therefore, while configuring the bandwidth parameter of the IP RTP priority command you only need to configure for the compressed calls bandwidth. For example, if a G.729 voice call requires 24 Kbps uncompressed bandwidth, but only 12 Kbps compressed bandwidth, you only need to configure a bandwidth of 12 Kbps. It is standard configuration to allocate up to 75% of the bandwidth to voice and let the remaining 25% go to the other data flows. (Layer 2 header information is included in the 25%.) Bandwidth allocation for voice packets takes into account the payload plus the IP, RTP, and UDP headers, but not the Layer 2 header. The remaining 25% of bandwidth that is used for other overhead includes the Layer 2 header and best-effort traffic. Bandwidth for the CBWFQ default class, for instance, is also taken from the remaining 25%. Allowing 25% bandwidth for other overhead is usually sufficient for proper network operations. In order to override the 75% maximum level, you can use the max-reservedbandwidth command to manually set the maximum bandwidth levels. If you override the fixed amount of bandwidth, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic.



Resource Reservation Protocol – RSVP RSVP allows end-to-end systems to set up a virtual pipe of QoS on the network between them. The RSVP parameters are defined by the network administrator and must be consistent throughout the network in order for the reservations to be maintained properly. RSVP is equivalent to a dynamic access list for packet flows–it can activate and deactivate itself as needed. The parameters that need to be set on the router that sets up the RSVP reservation, are the amount of bandwidth allocated, and the type of RSVP pipe to set up. RSVP should be configured to ensure the proper level of QoS if the following conditions exist on the network link in question: • Small-scale voice network implementation–there is not a lot of management to be done and the voice traffic will be at a small level. • Slow links–if there are any slow linked WAN sites that the voice traffic will need to transverse. • Links with high usage–if there are any links that voice traffic would have a hard time getting real-time performance to. •

Links with less than 2 Mbps–most T-1 links or less.

• There is a need for the best possible voice quality–the voice traffic will have precedence, even at the cost of data performance. RSVP Configuration By default, RSVP is deactivated on Cisco routers to allow for backward compatibility with older systems that do not have RSVP capabilities. Remember, in order to use RSVP, it must be activated throughout the entire network that will be supporting voice traffic. At minimum, to activate RSVP, use the following command on all interfaces that will be activating RSVP sessions. This command sets up the amount of reservation bandwidth for voice traffic on that port. The command is entered in interface configuration mode: IP rsvp bandwidth [interface-kbps] [single-flow-kbps]



This command starts RSVP and sets up the bandwidth and single flow limits. The default maximum bandwidth allocated to RSVP is 75% of the interface bandwidth, and the amount of a single data flow can be up to 100% of the reservable bandwidth. When dealing with sub-interface configurations, special considerations need to be made. The default RSVP bandwidth is the more restrictive of the physical interface or the sub-interface bandwidths. Normally, if a data flow does not exceed the reservable bandwidth limit, then the transmission will succeed with no problems. However, if there are other RSVP flows set up on other sub-interfaces on the same physical connection, and there is not enough bandwidth on the physical interface to allow for any more bandwidth, then the reservation will be refused. This occurs often with T-1 frame-relay circuits that have multiple sub-interfaces on the same physical port where the port has been over-booked. Once the RSVP bandwidth has been activated on the physical interface, the dialpeers need to set up to activate the RSVP reservations. This is done using the following command on the individual dial-peer configuration: req-qos [best-effort | controlled-load | guaranteed-delay] best-effort indicates that the RSVP system makes no bandwidth reservations. It is simply to set up a pipe to get the best performance it can. controlled-load indicates that RSVP is to admission (or capacity) control when assigning a bandwidth. This ensures that even if the bandwidth is congested and overloaded, the data flow will get preferential treatment. guaranteed-delay indicates that RSVP will give preferential treatment only if the bandwidth is not overloaded. The default setting for req-qos is best-effort. It is recommended by Cisco to use the controlled-load setting for VoIP traffic. Another command called acc-qos works with RSVP to allow for pro-active monitoring of QoS levels. The acc-qos command, when applied to a dial-peer setting, will send out an SNMP event if the QoS level falls below stated RSVP settings. The command is issued under the dial-peer configuration mode as follows: acc-qos [best-effort | controlled-load | guaranteed-delay] IP Precedence vs. RSVP file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (43 of 66) [13/12/02 18:19:05]


There are advantages and disadvantages to using either method of QoS for Voice over IP. One of the most important factors to take into account is what kind of QoS features your network can use. It is important to understand the types of traffic that the network is passing for data as well as voice so that you do not cut out any vital data traffic in lieu of voice traffic. Keep in mind the following when deciding on which algorithms to use: • IP Precedence is more controllable for the network administrator. They can choose what level of precedence is available to the traffic that they wish to use QoS on. It cannot be controlled dynamically; it is set manually on each individual dial-peer. Therefore, QoS will have a higher administration overhead should the network need to be more fine tuned. • RSVP is harder to set up initially, since traffic levels need to be analyzed and adjusted on each physical port. RSVP is extremely powerful on high congestion links and slow WAN links. It also has the extra benefit of being a dynamically control system. RSVP pipes are built and torn-down as needed, therefore there are no wasteful pipes utilizing the bandwidth. • At this time, it is recommended by Cisco to use the IP Precedence methods instead of RSVP due to streamlining efforts of the RSVP technologies. IP Precedence is a more stable method of control.

Multilink PPP (MLPPP) and Interleaving MLPPP solves the serialization delay problem of large frames on slow links. Consider the case of a 56 K line and a 1500 byte frame about to be transmitted out of the serial interface. As this large frame is committed to be transmitted and beings to play out the interface, a voice packet arrives and needs to be processed immediately since voice traffic needs to be as close to real-time as possible. Since the router has already started to transmit the larger frame there is no way to interrupt the transmission and the voice packet will have to wait for 214ms. This is clearly unacceptable when the one way delay limits for voice are 150ms. By fragmenting this larger frame into smaller fragments we can interleave the smaller voice packet and avoid this serialization delay. Fragmentation is recommended on interfaces less than 768 Kbps. Interleaving only applies to interfaces that can handle multilink bundle interfaces, such as virtual templates, dialer templates, and ISDN circuits (BRI and PRI).



To activate MLPPP with interleaving on an interface, use the commands shown in Table 4.16 in interface configuration mode. Table 4.16 Activating MLPPP with Interleaving on an Interface Step Related Command Description 1 ppp multilink Enables MLPPP 2 ppp multilink interleave Enables real-time packet interleaving 3 (Optional) configures a ppp multilink fragment-delay milliseconds maximum fragment delay

Compressed Real-Time Protocol – CRTP RTP is used on IP networks to handle audio compression for IP packets. It can compress the IP/UDP/RTP header in an RTP packet from 40 bytes down to about 2 to 4 bytes, significantly decreasing the bandwidth needs of audio packets. As discussed previously in this chapter, there are two kinds of delay on a voice network: variable delay and fixed delay. By enabling RTP, you can reduce the packet header sizes of RTP/UDP and IP. IP rtp header-compression [passive] The passive keyword causes the interface to only compress outbound data if there was corresponding inbound data to match that was RTP compressed. Otherwise the default is to compress all data.

CODEC and Voice Activity Detection (VAD) CODEC and Voice Activity Detection (VAD) are used for bandwidth control on dial-peers. Code/Decode, or CODEC, is used to convert analog signals to digital signals then back to analog. Different CODECs deliver different encoding speeds. The CODEC options can be set up in dial-peer configuration mode with the following command: codec [g711alaw | g711ulaw | g729r8] The default setting for the codec command is g729r8. This is efficient for most links. However, if you require exceptional voice quality, you should use the g711alaw or g711ulaw settings. Keep in mind that these CODECs require a higher



bandwidth capacity. Voice Activity Detection, or VAD, is used to disable the transmission when there is no voice activity, reducing the effective bandwidth required. To activate VAD on a dial-peer, use this command in dial-peer configuration mode: vad The default for the vad command is enabled. If you need exceptional voice quality and you are operating a high bandwidth network, then vad should be disabled since it causes a slight degradation in voice quality.

VoIP QoS over Frame Relay The areas that need to be configured for a basic Voice over IP network are the WAN links that will carry the voice packets. Since these transmissions are going to go over the public network, Cisco needs to comply with industry standards in case the far-end transmissions are being handled by another vendors’ equipment. In order to comply with industry standards, Cisco introduced FRF.12 in IOS Release 11.3. These standards define how Frame Relay traffic is to be handled so that all systems are compliant over a Frame Relay cloud.

Configuration of FRF.12 Fragmentation To configure frame relay interface for FRF.12, first define a frame relay map class to apply to the DLCIs that need the fragmentation algorithms. Use the procedure described in Table 4.17 in global configuration mode to configure a map class for voice traffic. Table 4.16 Configuring a Map Class for Voice Traffic Step # Related Command Description 1 Creates a map class that map-class frame-relay can be assigned to a group of PVCs. The map-classname must be unique.



2

The bandwidth for the map class needs to be entered in bits per second, which will determine the number of voice calls allowed on the DLCI. Do not set this value to higher than the minimum CIR rate in order to avoid packet and transmission loss. Ranges from 8 Kbps to 45 Mbps. Once the map class has been defined, you can apply FRF.12 attributes to it using the commands shown in Table 4.18 in map class configuration mode. frame-relay voice bandwidth bps reserved

Table 4.18 Applying FRF.12 Attributes to the Map Class Step Related Command Description # 1 frame-relay fragment fragment- Configures frame relay for the map class. fragment-size defines the payload size, not size the header size of the fragments. The fragment-size should be less than or equal to the MTU size, and the packet size should be no larger than the largest data packet. Ranges from 16 to 1600 bytes with a default of 53 bytes. 2 frame-relay fair-queue Enables WFQ for the map class. The [Congestive_Discard_Threshold] command does the same thing as the fair [Number_Dynamic_Conversation-_Queues] queue command only this one applies to a [Number_Reservable_Conversation_Queues] Frame Relay PVC. The defaults are as follows: Congestive_Discard_Threshold: 64 Number_Dynamic_Conversion_Queues: 16 Number_Reservable_Conversation_Queues: 2

Frame Relay Traffic Shaping file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (47 of 66) [13/12/02 18:19:05]


When configuring frame relay PVCs to carry traffic, you must be able to handle real-time data flows. Normally, it is acceptable to allow a certain amount of overflow on the PVC queues and “overbook” the port, but if it is not configured properly, there could be disruption in real-time traffic. Frame Relay Traffic Shaping (FRTS) is used to control the data flow of Frame Relay packets and fine tune real-time quality data flow. Using FRTS can assure that as little overbooking as possible is occurring, resulting in a better quality of voice transmission. Without traffic shaping your data is transmitted into the carriers' network at port speeds and allows the carrier to decide what data to discard during congestion situations. By enabling traffic shaping you are moving the queuing port from the carriers’ network to the routers’ egress port where you can control which traffic is high and low priority using the QoS tools in IOS. To alleviate this problem, find out what the Excess Burst size, Committed Burst size and the Committed Information Rate (CIR) values are from the carrier for frame relay traffic. Program these values into the frame relay PVC settings using the commands shown in Table 4.19 in interface configuration mode. Table 4.19 Programming CIR Values Into the Frame Relay PVC Settings Step Command Purpose 1 map-class frameSpecify the rame elay map class name and enter relay map-class-name mapclass configuration mode. 2 frame-relay custom- (Optional) Specify a custom queue list to be used for queue-list list-number the map class. 3 frame-relay priority- (Optional) Assign a priority list to virtual circuits (VCs) associated with the map class. group list-number 4 frame-relay adaptive- (Optional) Select either BECN or ForeSight as the congestion backward notification mechanism to which shaping [becn | traffic shaping will adapt. foresight] 5 frame-relay cir out (Optional) Specify the outbound committed information rate (CIR). bps 6 frame-relay mincir in (Optional) Set the minimum acceptable incoming CIR. bp 7 frame-relay mincir (Optional) Set the minimum acceptable outgoing CIR. out bps 8 frame-relay bc out (Optional) Set the outgoing Committed Burst (Bc) size. bits



9

(Optional) Set the outgoing Excess Burst (Be) size. frame-relay be out bits 10 frame-relay idle(Optional) Set the idle timeout interval. timer duration The following is a basic example of how to configure FRTS on the router: interface Serial0/0 no ip address encapsulation frame-relay bandwidth 1300000 frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.0 bandwidth 56000 frame-relay class alpha map-class frame-relay alpha frame-relay fragment 70 no frame-relay adaptive-shaping frame-relay bc 2000 frame-relay cir 56000 frame-relay mincir 56000 frame-relay fair-queue

The measurement interval is Bc/CIR, or if Bc=0, Be/CIR. If this is too large, the system reserves the right to subdivide it into smaller intervals with a corollary Bc (sustained burst size) value. This happens, in the initial implementation, when the measurement interval exceeds 250 milliseconds.

VoIP Troubleshooting In order to verify the proper operations of real-time traffic, it is essential that you understand the basic troubleshooting commands for VoIP on Cisco routers. Cisco provides several commands to view the packet weights and sizes on the serial ports to assure the proper operations of VoIP traffic.

Case Study 1 In this case study we will demonstrate the effects MLPPP on the VoIP traffic and illustrate how the packets are effected as MLPPP is activated and removed. The setup for this case study involves using two 3600 series routers equipped with



FXS and V.35 serial interfaces. Use the following procedure to emulate the setup for the case study: 1. Cable both routers back-to-back using the supplied DCE/DTE V.35 cables. 2. Load each router with IOS ip plus 11.3.8T. This IOS set allows for all of the features needed to illustrate the MLPPP effects on traffic. 3. Configure each router with the appropriate IP addresses and voice commands. Sample VoIP/MLPPP configurations are supplied below. All serial interfaces should have a clock rate of 64 Kbps. Be sure that you can complete voice calls between FXS ports. Prior to performing the troubleshooting techniques, verify that calls can be placed successfully via the FXS ports on the routers.

Router 1 Configuration ! version 11.3 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname group1-r1 ! enable password cisco ! ip subnet-zero no ip domain-lookup multilink virtual-template 1 ! dial-peer voice 2 pots destination-pattern 1000 port 1/0/0 ! dial-peer voice 1 voip destination-pattern 2000 ip precedence 5 session target ipv4:10.1.1.2 ! ! voice-port 1/0/0



! voice-port 1/0/1 ! voice-port 1/1/0 ! voice-port 1/1/1 ! ! ! interface Loopback0 ip address 10.1.1.1 255.255.255.0 no ip directed-broadcast ! interface Ethernet0/0 no ip directed-broadcast ! interface Serial0/0 ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp no ip mroute-cache bandwidth 64 load-interval 30 no fair-queue ppp multilink ! interface Ethernet0/1 no ip address no ip directed-broadcast shutdown ! interface Serial0/1 no ip address no ip directed-broadcast shutdown ! interface Virtual-Template1 ip unnumbered Loopback0 no ip directed-broadcast fair-queue 64 256 0 ppp multilink ppp multilink fragment-delay 20 ppp multilink interleave !



ip classless ! ! ! line con 0 transport input none line aux 0 line vty 0 4 exec-timeout 0 0 password cisco login ! end

Router 2 Configuration ! version 11.3 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname group1-r2 ! enable password cisco ! ip subnet-zero no ip domain-lookup multilink virtual-template 1 ! dial-peer voice 2 pots destination-pattern 2000 port 1/1/0 ! dial-peer voice 1 voip destination-pattern 1000 ip precedence 5 session target ipv4:10.1.1.2 ! ! voice-port 1/0/0 ! voice-port 1/0/1 !



voice-port 1/1/0 ! voice-port 1/1/1 ! ! ! interface Loopback0 ip address 10.1.1.2 255.255.255.0 no ip directed-broadcast ! interface Ethernet0/0 no ip directed-broadcast ! interface Serial0/0 ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp no ip mroute-cache bandwidth 64 no fair-queue clockrate 64000 ppp multilink ! interface Ethernet0/1 no ip address no ip directed-broadcast shutdown ! interface Serial0/1 no ip address no ip directed-broadcast shutdown ! interface Virtual-Template1 ip unnumbered Loopback0 no ip directed-broadcast ip rtp header-compression fair-queue 64 256 0 ppp multilink ppp multilink fragment-delay 20 ppp multilink interleave ! ip classless !



! line con 0 transport input none line aux 0 line vty 0 4 exec-timeout 0 0 password cisco login ! end

4. Generate 1500 byte pings with a zero timeout across the PPP link using an extended ping. Generate approximately 100000 pings so that you have time to observe the results. Now that you have set up the routers with the proper configurations as described above, you can verify that the VoIP traffic is indeed receiving a lower weight when compared to the rest of the data traffic while the pings are still running by using the show queue virtual-access 1 command as follows: group1-r1#sh queue virtual-acc 1 Input queue: 0/75/0 (size/max/drops); Total output drops: 14433 Queueing strategy: weighted fair Output queue: 65/1000/64/14433/688 (size/max total/threshold/drops/interleaves ) Conversations 2/4/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) (depth/weight/discards/tail drops/interleaves) 1/682/0/0/0 Conversation 126, linktype: ip, length: 62 source: 192.168.1.2, destination: 192.168.1.1, id: 0x3B2D, ttl: 254, TOS: 160 prot: 17, source port 16396, destination port 16396 (depth/weight/discards/tail drops/interleaves) 64/4096/14433/0/0 Conversation 214, linktype: ip, length: 1502 source: 192.168.1.2, destination: 192.168.1.1, id: 0x233B, ttl: 255, prot: 1

This output shows two flows, one voice flow with a weight of 682, and the flow of the pings at a weight of 4096. This in turn provides the voice with a higher priority in the WFQ algorithm. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (54 of 66) [13/12/02 18:19:05]


5. While the pings are still running, verify that multilink fragmentation and interleave is operational. MLPPP insures that larger data packets such as 1500 byte pings will not cause output queuing delay for the smaller voice packets. By using the show interface virtual-access 1 command, you can view the interleaves counter and verify that the fragmentation process is operational. group1-r1#sh int virtual-acc 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Interface is unnumbered. Using address of Loopback0 (192.168.1.2) MTU 1500 bytes, BW 64 Kbit, DLY 100000 usec, reliability 255/255, txload 75/255, rxload 63/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) DTR is pulsed for 5 seconds on reset LCP Open, multilink Open Open: IPCP Last input 00:00:00, output never, output hang never Last clearing of "show interface" counters 00:03:00 Input queue: 0/75/0 (size/max/drops); Total output drops: 23463 Queueing strategy: weighted fair Output queue: 64/1000/64/23463/1905 (size/max total/threshold/drops/interleave s) Conversations 1/4/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 16000 bits/sec, 2 packets/sec 5 minute output rate 19000 bits/sec, 7 packets/sec 217 packets input, 230374 bytes, 0 no buffer Received 164 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 532 packets output, 555364 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions

The debug ppp multilink fragments command allows you to see the fragmentation size of the packets produced by using MLPPP. The output below shows a maximum fragment size of 160 bytes which equates to a maximum delay of 20ms on a 64 K line. Also note the voice packets being interleaved between the fragmented data packets, and that the queue number of 126 matches the



conversation number of the voice flow in the output of show queue virtual access 1. group1-r1#debug ppp multilink fragments Multilink fragments debugging is on 00:04:06: Vi1 MLP: Packet being interleaved from 00:04:06: Se0/0 MLP: O seq 4000135F size 142 00:04:06: Se0/0 MLP: O seq C0001360 size 70 00:04:06: Se0/0 MLP: O seq C0001361 size 70 00:04:06: Se0/0 MLP-FS: I seq C93 size 160 00:04:06: Se0/0 MLP: O seq 80001362 size 160 00:04:07: Se0/0 MLP: O seq 40001363 size 18 00:04:07: Se0/0 MLP-FS: I seq C94 size 160 00:04:07: Se0/0 MLP: O seq C0001364 size 70 00:04:07: Se0/0 MLP: O seq C0001365 size 70 00:04:07: Se0/0 MLP: O seq 80001366 size 160 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Se0/0 MLP: O seq 1367 size 160 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Se0/0 MLP: O seq 1368 size 160 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Se0/0 MLP: O seq 1369 size 160 00:04:07: Se0/0 MLP: O seq 136A size 160 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Vi1 MLP: Packet being interleaved from 00:04:07: Se0/0 MLP: O seq 136B size 160

queue 126

queue 126 queue 126 queue 126 queue 126 queue 126 queue 126

queue 126 queue 126 queue 126

While continuing to generate 1500 pings with a zero timeout, if we remove the commands: ppp multilink fragment-delay 20 ppp multilink interleave

from the virtual template interface, we will disable the fragmentation process. Once we remove fragmentation, placing a call will demonstrate the loss in voice quality that we see when MLPPP is not in use. Another test is to replace the MLPPP commands and then remove the IP Precedence settings. Again, this causes the weight of the voice packets to lose their precedence, thus causing a loss in



quality for the voice transmissions.

Case Study 2 This case study demonstrates Voice over IP over a Frame Relay network using FRF.12 as the fragmentation mechanism. We will verify the effects of IP Precedence on WFQ and verify proper traffic shaping. Each lab group should have two 3600 series routers equipped with FXS and V.35 serial interfaces. 1. Cable each router to the Frame Relay switch using the V.35 DTE cables. 2. Load IOS version 12.0.4T ip plus into each router. 3. Configure each router with the appropriate IP addresses, frame relay DLCIs and voice. Sample VoIP/FRF.12 configurations are supplied below. All Frame Relay PVC have 128 K port speeds. Traffic shaping should be enabled to shape to a 64 K CIR. Be sure that you can successfully complete voice calls between FXS ports prior to doing the following tests.

Router 1 Configuration version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname group1-r1 ! enable password cisco ! ip subnet-zero ! ! ! ! voice-port 1/0/0 ! voice-port 1/0/1 ! voice-port 1/1/0



! voice-port 1/1/1 ! dial-peer voice 2 pots destination-pattern 1000 port 1/0/0 ! dial-peer voice 1 voip destination-pattern 1002 ip precedence 5 session target ipv4:10.1.1.2 ! ! interface Ethernet0/0 no ip directed-broadcast ! interface Serial0/0 ip address 10.1.1.1 255.255.255.0 no ip directed-broadcast encapsulation frame-relay no ip mroute-cache no fair-queue frame-relay traffic-shaping frame-relay class frag frame-relay interface-dlci 101 frame-relay ip rtp header-compression ! interface Ethernet0/1 no ip address no ip directed-broadcast shutdown ! interface Serial0/1 no ip address no ip directed-broadcast shutdown ! ip classless no ip http server ! ! map-class frame-relay frag frame-relay cir 64000 frame-relay bc 2000



frame-relay fragment 160 no frame-relay adaptive-shaping frame-relay fair-queue ! ! line con 0 transport input none line aux 0 line vty 0 4 exec-timeout 0 0 password cisco login ! end Router 2 Configuration ! group1-r2# Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname group1-r2 ! enable password cisco ! ip subnet-zero ! ! ! ! voice-port 1/0/0 ! voice-port 1/0/1 ! voice-port 1/1/0 ! voice-port 1/1/1 !



dial-peer voice 2 pots destination-pattern 1002 port 1/0/0 ! dial-peer voice 1 voip destination-pattern 1001 ip precedence 5 session target ipv4:10.1.1.1 ! ! interface Ethernet0/0 no ip directed-broadcast ! interface Serial0/0 ip address 10.1.1.2 255.255.255.0 no ip directed-broadcast encapsulation frame-relay no ip mroute-cache no fair-queue frame-relay traffic-shaping frame-relay class frag frame-relay interface-dlci 102 frame-relay ip rtp header-compression ! interface Ethernet0/1 no ip address no ip directed-broadcast shutdown ! interface Serial0/1 no ip address no ip directed-broadcast shutdown ! ip classless no ip http server ! !3332 map-class frame-relay frag frame-relay cir 64000 frame-relay bc 2000 frame-relay fragment 160 no frame-relay adaptive-shaping frame-relay fair-queue



! ! line con 0 transport input none line aux 0 line vty 0 4 password cisco login ! end

4. Generate 1500 byte pings with a zero timeout across the Frame Relay link using an extended ping. Generate approximately 100000 pings so that you have time to observe the results. 5. Verify that the VoIP traffic is indeed receiving a lower weight when compared to the rest of the data traffic while the pings are still running by using the show traffic-shape queue serial dlci command as follows: group1-r1#sh traffic-shape queue serial 0/0 dlci 101 Traffic queued in shaping queue on Serial0/0 dlci 101 Queueing strategy: weighted fair Queueing Stats: 66/600/64/82883 (size/max total/threshold/drops) Conversations 2/16 (active/max total) Reserved Conversations 0/2 (active/allocated) Conversation 0, linktype: ip, length: 64 (depth/weight/discards) 2/682/0 source: 192.168.1.1, destination: 192.168.1.2, id: 0x5568, ttl: 254, TOS: 160 prot: 17, source port 16518, destination port 16452 Conversation 6, linktype: ip, length: 1504 (depth/weight/discards) 64/4096/82883 source: 192.168.1.1, destination: 192.168.1.2, id: 0x24D9, ttl: 255, prot: 1

The above output shows that the voice traffic, which is conversation 0, is receiving a weight of 682 within the WFQ algorithm. The 1500 byte pings, conversation 6, are receiving the default weight of 4096.This result is the voice receiving a higher priority in the WFQ algorithm than data. 6. While the pings are still running, verify that FRF.12 fragmentation is operational. FRF.12 insures that larger data packets such as 1500 byte pings will file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (61 of 66) [13/12/02 18:19:05]


not cause output queuing delay for the smaller voice packets. The show framerelay fragmentation command shows that fragmentation is operational and has a fragment size of 160 bytes. group1-r1#sh frame-relay frag interface dlci frag-type frag-size in-frag out-frag dropped-frag Serial0/0 101 end-to-end 160 17638 18206 1

By using the more fine tuned command show frame-relay fragmentation interface serial you can get more detail on the same information: group1-r1#sh frame-relay frag inter serial 0/0 101 fragment size 160 fragment type end-to-end in fragmented pkts 11314 out fragmented pkts 11330 in fragmented bytes 1762566 out fragmented bytes 1764808 in un-fragmented pkts 3343 out un-fragmented pkts 152 in un-fragmented bytes 213353 out un-fragmented bytes 9721 in assembled pkts 4502 out pre-fragmented pkts 1315 in assembled bytes 1910033 out pre-fragmented bytes 1709737 in dropped reassembling pkts 0 out dropped fragmenting pkts 0 in timeouts 0 in out-of-sequence fragments 0 in fragments with unexpected B bit set 0 out interleaved packets 4399

By using the show frame-relay pvc, you can get information on the fragment size, the type of fragmentation, end-to-end, for FRF.12, and the traffic shaping parameters applied to the interface: group1-r1#sh frame-relay pvc 101 PVC Statistics for interface Serial0/0 (Frame Relay DTE) DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0 input pkts 4680 output pkts 138161 in bytes 2177745 out bytes 197936945 dropped pkts 129945 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 2 out bcast bytes 638 pvc create time 00:31:14, last time pvc status changed 00:30:55 fragment type end-to-end fragment size 160 cir 48000 bc 6000 be 0 limit 750 interval 125 mincir 24000 byte increment 750 BECN response no pkts 37595 bytes 4814246 pkts delayed 17667 bytes delayed 2334793



shaping active Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 2 Output queue size 64/max total 600/drops 0

The debug frame-relay fragment interface command will display the FRF.12 header and the related sequence numbers on the data flow, thus allowing fine detail troubleshooting information. Tip Be sure to stop the extended ping before running this command. To observe this output generate a single 1500 byte ping, otherwise you will not be able to get useful information out of the debug. group1-r1#debug frame-relay fragment inter serial 0/0 101 This may severely impact network performance. You are adviced to enable 'no logging console debug'. Continue?[confirm]y Frame Relay fragment/packet debugging is on Displaying fragments/packets on interface Serial0/0 dlci 100 only 00:37:32: Serial0/0(o): dlci 100, tx-seq-num 1072, B bit set, frag_hdr 03 B1 88 30 00:37:32: Serial0/0(o): dlci 100, tx-seq-num 1073, no bit set, frag_hdr 03 B1 08 31 00:37:32: Serial0/0(o): dlci 100, tx-seq-num 1074, no bit set, frag_hdr 03 B1 08 32 00:37:32: Serial0/0(o): dlci 100, tx-seq-num 1075, no bit set, frag_hdr 03 B1 08 33 00:37:32: Serial0/0(o): dlci 100, tx-seq-num 1076, no bit set, frag_hdr 03 B1 08 34 00:37:32: Serial0/0(o): dlci 100, tx-seq-num 1077, no bit set, frag_hdr 03 B1 08 35 00:37:32: Serial0/0(o): dlci 100, tx-seq-num 1078, no bit set, frag_hdr 03 B1 08 36



While continuing to generate 1500 pings with a zero timeout, remove the frame relay class command from the serial interface. This will disable FRF.12 fragmentation. Establish a voice call and observe results. Now re-enable FRF.12 fragmentation and remove the IP Precedence setting from the VoIP dial-peer. Run the 1500 byte ping test again and observe the results. By removing either set of commands we see that there is a loss in voice quality over the Frame Relay connection. This demonstrates the need for traffic shaping parameters and IP Precedence to maintain true voice quality transmissions.

Summary In order to configure a complete Voice over IP network, several steps need to be taken to complete the task. First, plan out the Dial Plan of the VoIP network. This determines what types of hardware will be needed to make connectivity, what kind of circuits will be needed to connect the hardware, and finally what kind of special programming is needed to ensure proper “real-time” transmission of voice data. To complete the dial plan, layout what different areas of the network will use for phone numbers and extensions. Determine what area codes need to considered to comply with the PSTN, and whether or not existing PBX equipment needs to be incorporated into the new VoIP network, also determine how all of the areas will routed. An existing and functional IP network needs to be enabled and tested prior to any dial plan being implemented. Once the planning is complete, the proper hardware needs to be configured to enable connectivity. The 2600 series, 3600 series routers are all VoIP capable when utilizing the Voice Network Modules. The AS5300 Access Switch and 7200 series routers can be used for voice termination and tandem switching of voice transmissions. The VICs, or Voice Interface Cards, are used in conjunction with the VNMs to provide voice port access to the 2600/3600 series. They come in two port configurations of either FXS, FXO, or E&M ports. Now that the hardware has been identified, dial-peers need to be configured on the routers to tell the network how to handle the dialed digits initiating any voice calls. The dial-peer configurations and the voice ports themselves can be fine tuned to handle any special adjustments needed to ensure voice clarity and transmission. The dial-peers can be either POTS or VoIP type, depending on whether they will be for locally attached or routed transmissions, respectively. After all of the local configurations are complete on the routers, connectivity between the routers needs to be established by utilizing trunks, tie-lines, and WAN file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_04.htm (64 of 66) [13/12/02 18:19:05]


links. Special settings for industry standards such as FRF.11 and FRF.12 need to be configured to ensure proper transmissions over WAN trunks working on frame relay. Finally, to ensure real-time response over the entire network for voice transmissions, QoS features such as Weighted Fair Queuing and Class-Based Weighted Fair Queuing need to be enabled. IP Precedence and Resource Reservation Protocol (RSVP) are used to ensure prioritization within the queuing algorithms.

FAQs Here are some everyday questions that may arise in basic configurations of Voice over IP: Q: Is it necessary to do a complete dial-plan prior to setting up the IP network? A: It is not vital to do so, but it is advisable. IP networks are extremely complex to set up. With or without pre-planning, it will take many practice sessions and trial and error to get it right. If you skip the pre-planning stage, it can exponentially increase the amount of troubleshooting necessary before completing the network. Q: Are all of the parameters mentioned in the chapter necessary for operation? Can the default settings for voice ports and dial peers be used? A: For most setups, the default settings for the FXS and FXO ports are sufficient. In most cases, the destination-pattern and port commands are sufficient for most FXS setups, and the destination-pattern and sessiontarget commands are enough to complete basic connectivity. Be sure to go through the list to ensure there is nothing you missed that could affect the network and real-time transmissions. E&M ports, on the other hand, do not usually work on the default settings and need to be fine tuned. Q: My company is currently using PBXs to handle their voice applications and I am trying to set up a VoIP network. How do I ensure voice application availability while the implementation is going on? A: In most cases, it is wise to plan dual circuits for all cutover areas of the network. Allow for dual-links back to the PBXs so that if the IP network experiences unexpected problems, a direct connection back to the PBX is still



available. In other words, use FXO ports to connect tie lines back to the PBXs already in place and initially set up the router as a tandem switch. That way, if there is a problem with QoS and/or routing, you can get the users back online by putting the tie-line directly between the PBXs again, and thus allow time for off-line troubleshooting. This will keep development time transparent to the end-users.


Chapter 5: Advanced Voice over Configuration


Chapter 5 Advanced Voice over IP Configuration Introduction H.323 Version 1 vs. Version 2 Lightweight Registration Improved Gateway Selection Processes H.323 RAS and Gatekeepers Gatekeepers Zone Management Gatekeeper Functionality on Cisco Platforms Configuration of a Cisco Gatekeeper Configuring an H.322 Gatekeeper on Cisco Platforms Directory Gatekeepers and Location Requests Gateways RAS: Registration, Admissions, and Status Gateway Discovery Configuring an H.322 Gateway on Cisco Platforms Configure Gateway Interface Parameters AAA and Call Detail Records Acct-Session-Id Field NTP Time Format Interactive Voice Response IVR Scripts Fax Hop On/Off Procedure for Creating Audio (AU) Files Store-and-Forward Fax On-Ramp and Off-Ramp Gateway Concepts Configuration of Store-and-Forward Faxing Redialer vs. Direct-Inward-Dialing Configuring the On-Ramp Gateway Configure the Called Subscriber Number Configure the Sending Mail Transport Agent Configure the On-Ramp POTS Dial-Peer Configure the On-Ramp MMoIP Dial-Peer Configuring the Off-Ramp Gateway Configure the Transmitted Subscriber Number Configure the FAX Transmission Speed Configure the Receiving Mail Transport Agent Configure the Off-Ramp POTS Dial-Peer

file:///H:/edonkey/docs/programming/SYNGRESS_Configuring_Cisco_Voice_OverIP.JanezSlovenec/70_voip_web_05.htm (1 of 30) [13/12/02 18:19:17]


Configure the Faxed Header Information Configure the Fax Cover Page Information Advanced Troubleshooting show gateway debug ras debug h225 Show Call Application Voice Summary FAQs

Solutions in this chapter: •

H.323 Gateways and Gatekeepers

•

AAA and RAS Processes for Authentication and Accounting

•

FAX Store-and-Forward Technologies

•

Interactive Voice Response Scripts

Introduction One of the primary design goals in any data network today is to make sure that the network is expandable and scalable. Not doing so will cost extra time, money, and administrative overhead in the future. In Chapter 4, “Voice over IP Configuration,” we described the basic steps involved in developing a simple Voice over IP (VoIP) network. There are numerous factors to take into account when changing the simplest of parameters on a working VoIP network, and Chapter 4 only covers how to create a static environment, not a dynamic one. Network designers use software tools such as the Domain Name Service (DNS), Dynamic Host Control Protocol (DHCP), and Network Address Translation (NAT) to allow their IP network to expand dynamically with minimal overhead on the network administrator. VoIP can have similar functions, and this functionality is handled by the H.323 specification. The H.323 industry standard was implemented to simplify functionality and add scalability and other features, such as accounting, authentication, resource load balancing, and advanced features like Interactive Voice Response, and Faxing over IP networks.

H.323 Version 1 vs. Version 2 Cisco has improved upon the original release of the H.323 functionality. We will review some of the enhancements between versions 1 and 2 here so that the concepts in this chapter can be more clearly understood. We will then discuss in detail the various services and applications of H.323 and how to configure the different options supplied by the system. The major improvements made between H.323 versions 1 and 2 include: •

Lightweight registration

•

Request in Progress messages to extend registration time-out capabilities

•

Gateway resource reporting

•

Gateway preference assignment

•

DTMF—digit relay for IVR applications

Lightweight Registration file:///H:/edonkey/docs/programming/SYNGRESS_Configuring_Cisco_Voice_OverIP.JanezSlovenec/70_voip_web_05.htm (2 of 30) [13/12/02 18:19:17]


Before version 2, H.323 gateways needed to reregister with the zone’s gatekeeper every 30 seconds. The renewal process was no different from the initial registration—everything was sent to the gatekeeper whether it had changed or not. This caused considerable overhead on the network. Version 2 now has a lightweight registration process in which only an abbreviated registration is used for renewal (after the initial registration) after a certain TTL (time to live) has expired. This reduces the amount of information to be renewed, and allows for periodic renewal as needed.

Improved Gateway Selection Processes In version 1, when the gatekeeper was deciding which gateway to transfer information to, the gatekeeper would use its registered technology prefixes to determine which gateways could handle the information at hand, and then randomly choose one. There was no way to select exactly which gateway to use; even if one gateway had better resources available, it may not get picked as the gateway of choice at that time. In version 2, you can now use zone prefixes instead of technology prefixes, thus streamlining the process of routing voice traffic. Also, there is now the preference command that allows the administrator to assign a preference as to which gateway will be picked and in what order. Version 2 supplies the following improvements to gateway selection: •

When more than one gateway is registered within the same zone, the updated zone prefix command allows assignment of selection priorities to particular gateways.

•

Gateway resource reporting can be used in the selection process so that an overtaxed gateway will not be overloaded.

H.323 RAS and Gatekeepers H.323 is an International Telecommunications Union (ITU-T) standard developed for the control of audio, video, and voice and data conferencing. It is the culmination of several other standards that fall under the H.323 umbrella. The H.323 standard is designed to give a central control on a network for multiservice protocols. The H.323 systems work primarily around two entities on the network: gateways and gatekeepers. Gateways perform the function of controlling access to resources on the network, and gatekeepers control the access to the gateways. In the following sections, we discuss the basic function that each entity performs.

Gatekeepers A gatekeeper is defined as a service that maintains a registry of devices in a multimedia network. All devices register themselves with the gatekeeper at startup and then request admission to a service from the gatekeeper. The gatekeeper is an H.323 entity on the local area network (LAN) that provides services such as address translation and control access to the LAN for H.323 endpoint devices and gateways. In addition to these basic services, gatekeepers can also supply special services to the gateways, such as bandwidth management and accounting. Zone Management The gatekeeper is responsible for various functions within its zone, and there is one gatekeeper for every H.323 zone. The gatekeeper provides the following functions for all H.323 terminals and gateways that have registered themselves with the gatekeeper: •

Address translation

•

Admissions control

•

Bandwidth control / management

•

Call authorization

Address Translation All H.323 entities on the LAN register themselves with the local gatekeeper at startup. Each H.323 zone needs to have its own gatekeeper. The H.323 entities, when registering, supply various pieces of information about themselves, including an H.323 ID, IP address, special functionality (tech prefixes or zone prefixes), and other bits of information discussed in detail later in this chapter. When a gatekeeper is trying to place a call to another gatekeeper’s area, the origin gatekeeper will first contact the foreign zone’s gatekeeper to authenticate and get the address to send the call to. This process is known as address translation for H.323.

Admissions Control When an H.323 resource needs to access the resources on the LAN, it must first receive access permission from the zone gatekeeper. An H.225 message for Admission Request (H.225 is a subset of H.323 specifically related to admissions control) is sent, and the gatekeeper will then confirm or reject access based on several parameters such as bandwidth availability, call authorization, or some



other defined parameter. If desired, the Admissions Control feature can set to a NULL state, which then allows all requests through.

Call Authorization An optional feature of the gatekeeper function is call authorization. Call authorization is the process of accepting or rejecting a call based on certain criteria. These criteria can be based on specific terminal exclusions, IP subnets, or locale criteria such as time of call or network origin points. The process of call authorization is based on the Q.931 (RAS) call control signal standards.

Bandwidth Management The gatekeeper is responsible for bandwidth management and control of its designated zone of influence. Bandwidth control is handled by bandwidth requests from the H.323 terminals. The gatekeeper can confirm or reject the request of the terminals or gateways by issuing BRQ (request), BCF (confirm), or BRJ (reject) (RAS message types are discussed later in the chapter). The gatekeeper can determine its decisions on available bandwidth before a call is set up and/or during the call if more bandwidth is requested. Gatekeeper Functionality on Cisco Platforms Cisco supports gatekeeper functionality on several of its router platforms. The following sections describe the platforms that support gatekeeper functionality and some of the advanced features provided by Cisco’s IOS.

Cisco Router Platforms Supported Cisco supports the gatekeeper functionality on the 2500, 2600, 3600, and 7200 router platforms. In order to optimize performance on a large VoIP network, it may be beneficial to have a router act solely as a gatekeeper to maximize processor utilization. Traditional protocol routing should not be activated on the router in order for the gatekeeper functionality to be properly utilized. The minimal Cisco IOS release is 12.0.4T with the IP/H.323 image.

Redundancy of Gatekeeper Functionality—HSRP There is no support for two active gatekeepers in the H.323 standard, so the problem of how to make the system redundant comes into question. Hot Standby Routing Protocol (HSRP) for H.323 can be used to make redundant gatekeepers in a single zone. The Cisco HSRP protocol functionality allows for a gatekeeper to sit on standby and take over the function of the gatekeeper it is shadowing. The HSRP protocol does not care what a router port is used for, it simply checks to see if the port is alive and activates the backup system if the port cannot be reached. Therefore, two gatekeeper routers will never be active at the same time, which allows for redundancy within a zone. The H.323 entities will always register with the gatekeeper at certain times (30-second intervals for version 1, TTL for version 2). The backup gatekeeper will take over if it cannot communicate with the primary gatekeeper. Configuration of a Cisco Gatekeeper Setting up a Cisco router for gatekeeper functionality involves registering the zone of influence, stating where the other gatekeepers are 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 the registration of domain names. As an example, when using DNS servers to access resources on the Internet, there needs to be a DNS server for each domain registered with InterNIC, the overall recognized Internet authority that controls domain name registrations. That server is responsible for its domain of influence, and in turn is registered with a DNS server in whose domain it happens to reside on the Internet. H.323 interzone communications work very much the same way. 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 “[email protected],” the endstation’s gatekeeper will find a gatekeeper that has the “zone1.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 a domain name, but handle it 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 being dialed because the destination you are calling is within the same area, or zone. To get to a number outside of your area code, you need to dial the destination area code first so the telephone company can route the call properly. Zone prefixes are the internal functions that handle this problem. As an example: The local gatekeeper knows that if it receives a telephone call with a zone prefix of 206xxxxxxx (the area code of 206 followed by seven arbitrary digits), the call is to be forwarded to the gatekeeper registered with that zone: gk-seattle. This command is issued on the local gatekeeper using the following syntax: router1 (config-gk) # zone prefix gk-ny 212…….

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 determine how to handle the transmission more efficiently, and immediately tells the gateway to send an LRQ to the remote gatekeeper for resolution. If this command is not used, the local gatekeeper will be queried first. It will have to perform



general broadcasts for resolution to other gatekeepers. By using the zone remote command, this process is streamlined and performance is improved. In conjunction with the zone remote command is the zone local command, which identifies a zone as belonging to the local gatekeeper. The resolution process is again streamlined by prequalifying the zone as local. The zone remote command will send the call from the Seattle gatekeeper to the gatekeeper in New York. At this point, the call is received by the New York gatekeeper, and now has been routed out to its final destination zone. If the E.164 address for the destination is registered with the gatekeeper, it will be able to immediately route the call to the H.323-enabled device. Usually, though, the device is not an H.323-enabled device and has not registered itself with the gatekeeper. The call is probably going to a standard telephone that is not registered directly with the gatekeeper and needs to be forwarded to a gateway for processing. At this point, the gatekeeper needs to look at zone prefixes or technology prefixes to determine the proper gateway.

Technology Prefixes When setting up gateways, network administrators need to determine what type or class of gateway they are initializing; in other words, what services the gateway is providing. By assigning technology prefixes to the gateways, the gateway will then register itself with its local gatekeeper with the prefix information. The prefixes are determined by functionality; for example, voice gateways can be registered with a prefix of 1xx, and voicemail gateways can be registered with 2xxx. Multiple gateways can register the same tech prefix number, but they all have to have the same functionality. When multiple gateways are configured, the gatekeeper needs to determine which to use. In version 1 of H.323, this would be a random selection. In version 2, the additional functionality of preferential assignment was added to the specification, so now the network administrator can define which gateways have higher preference over others in the zone. Multiple gateways within a zone can advertise the technology prefix, allowing the gatekeeper to distribute workload and handle bandwidth management processes. They have autonomy from the zone selection process, so calls can be routed within and between zones and only apply to the local zone selection. This requires that the technology prefixes be ignored during the zone selection process and zone prefixes be used so that version 2 features can be utilized to determine gateway selection. For example: Once the local gatekeeper has located the remote gatekeeper to handle the processing of a call, it will then request the location, via an LRQ request, of the remote endstation. The remote gatekeeper will then decide which gateway within its zone to send the call to for processing based on zone prefixes, bandwidth availability, preferences, and then finally technology prefixes if nothing else was able to settle the selection. With the advent of zone prefixes and the precedence abilities now incorporated into H.323 version 2, technology prefixes are maintained for backward compatibility to H.323 version 1 networks. With the proper programming of version 2 enabled devices, an entire network can potentially be configured without the use of technology prefixes. To assign a technology prefix, use the following command in gatekeeper configuration mode: gw-type-prefix

To verify that the technology prefixes programmed into the gatekeeper are functional, use the following command to list the gateway functions: show gatekeeper gw-type-prefix

Configuring an H.322 Gatekeeper on Cisco Platforms The steps to take to configure a Cisco router to act as a gatekeeper are listed in Table 5.1. Table 5.1 How to Configure a Cisco Router Step # Related Command Description configure terminal Enter Global Config mode. 1 gatekeeper Activates the gatekeeper 2 functionality on the router. zone local gatekeeper-name domain-name Sets the local domain 3 name of influence for this [rasIPaddress] gatekeeper. The gatekeeper name is given out to all registered entities. If a rasIPaddress is assigned, it is given out to all entities as the address to communicate with in the future (this is an interface on a router).



4

5

6

zone remote other-gatekeeper-name other-Sets a static entry for another zone’s gatekeeper domain-name other-gatekeeper-ipaddress address so that information [port number] for that zone can be forwarded. Configures the gatekeeper zone prefix gatekeeper-name e.164to acknowledge its own or prefix remote prefixes. Configure a technology gw-type-prefix type-prefix [hopoff prefix for the different gkid] [default-technology] [[gw types of service in the ipaddr ipaddr [port]]…] zone. The hopoff command tells which gatekeeper to pass off the tech prefix to, if appropriate. The default-technology keyword sets this particular tech-prefix as the default for the gateway that is registering the prefix. The gw ipaddr keyword is used if the gateway is not allowed to register, or when multiple gateways use the same prefix.

Example Gatekeeper Configuration The following is an example gatekeeper configuration for a 3600 series router. !Define this Ethernet port as the RAS gatekeeper. interface Ethernet0/0 ip address 172.9.53.15 255.255.255.0 ! gatekeeper ! !Specify the name of the local zone that this gatekeeper managers. Specify the IP !address that the gatekeeper advertises. zone local GK1.seattle.com seattle.com 10.2.1.5 ! !Statically define a remote zone and the associated gatekeeper's IP address. zone remote GK2.seattle.com seattle.com 10.2.2.5 ! !Statically define the E.164 prefixes that a remote zone handles. This causes GK1 to !direct any call with a called number that matches 12* (12 and any number of trailing !digits) to GK2. This is not the same as a tech prefix. If a call comes in with an !E.164 pattern of (206) 555-1234, it will be routed to GK2 because the pattern !matches 206*. zone prefix GK2.seattle.com 206* zone prefix GK2.seattle.com 13*


Chapter 5: Advanced Voice over Configuration ! !Statically define a tech prefix routing. Any call that comes in to the gatekeeper !with a technology prefix of 88# (the * catches any following E.164 address), is !directed to the gateway at IP address 10.2.2.5. This is a static technology prefix !definition. The gateway can also dynamically register its tech-prefixes with the !gatekeeper. gw-type-prefix 88#* gw ipaddr 10.2.2.5 1720 ! !Activate the gatekeeper function by activating the port. no shutdown !

Directory Gatekeepers and Location Requests One of the functions of a gatekeeper is to keep a track of various zone and technology prefixes so that it can attempt to forward the calls to the proper zone. The only way for a gatekeeper to know about a zone is to have it programmed in with the gw-type-prefix and the zone prefix commands as in the preceding example. When a call comes in specifying a remote zone prefix, the local gatekeeper will send an LRQ message to the remote gatekeeper registered to handle the particular prefix. The request will be for an address of a remote host under the remote gatekeeper’s domain. If the requested zone is not known, the default action for the gatekeeper is to try to service the call on the local gateways in its zone. This causes extra overhead on the network’s gateways in the local zone. In order to avoid this, use the following command in gatekeeper configuration mode: lrq reject-unknown-prefix

When activated, this command will make the gatekeeper reject any calls that come in with an unknown prefix. To enhance the performance of gatekeeper LRQs, some large VoIP installations have a gatekeeper in a central location to create a registry of all the zone prefixes within the WAN. That way, there can be a hierarchical chain of gatekeepers to assist in the call resolution process. These directory gatekeepers are normally configured with redundant systems over HSRP to ensure the stability of the H.323 resource network. Gateways In the previous section on gatekeepers, we kept mentioning an entity called the gateway. The gatekeepers are the pivotal resource that allows for resource management, directory services, accountability, and other functions. We equated gatekeepers to DNS servers for the Internet because they retain a record of resources and how to find those resources. To continue the analogy, if gatekeepers are like DNS servers, then gateways are the resources that the DNS servers point to. Gateways provide the local connection between the LAN data network and the analog controlled phone system or switched-circuit network such as the PSTN or PBX. The gateway provides the ability to translate to and from LAN traffic and phone traffic. Depending on the type of function the gateway provides, it will register itself with the gatekeeper with a certain technology prefix or zone prefix that identifies that gateway with the particular function. Gateways perform the following functions: •

Admission control, address lookup and translation via RAS

•

AAA accounting

•

Interactive voice response

•

ISDN redirect

•

Rotary call pattern support

Rotary Call Pattern Functions and Dial-Peer Preference It is possible to enable several dial-peers to be configured with the same destination pattern. This allows for network failure options to back up a vital voice link, and allows several users to dial in to the same number for remote access to a network. The configuration is simple for rotary functions: Just apply the same destination pattern to two or more dial peers. If this is done with a simple configuration and no preferences for ports are assigned, the gateway will follow a “round-robin” algorithm and take each dial-peer in turn. In order to actually set a preference as to which voice port is accessed in which order, use the preference command in dial-peer configuration mode. If several dial-peers are configured with rotary functionality, the system will attempt to place the call with the dial-peer with the highest preference rating. If the call cannot be completed (due to a gatekeeper or gateway not being available or for other reasons), the rotary feature performs the following tasks:



•

Lists all the conditions and symptoms where the outage occurs and send the findings to logs.

•

Retries the call to the next highest preference peer. If there are equal preferenced peers, the system will randomly select one.

•

Continues to go through the dial-peers in the rotary until all options are exhausted.

ISDN Redirect ISDN allows for connectivity to the user for data on one channel and also provides the ability to place voice calls over the same connection at the same time. This causes an obvious resolution problem: If the call is already connected to the ISDN provider, how does the connection know to handle a voice call, provide a dial tone for it, and how to route it properly? ISDN Redirect is included by Cisco to provide support for the ISDN redirecting call feature in a standard H.323 VoIP gateway. When the LEC (local exchange carrier) detects that the destination of an incoming call is not answering or not responding, the redirect feature sends out a special modified call message that contains the original destination number in the “redirecting number” field, and replaces the destination pattern with that of the local gateway. The local gateway will then receive the message and check its dial-peers for a match. It will realize that the destination is actually itself, automatically check for a “redirecting number” field, and place the call using that destination pattern; in other words, the original destination pattern. In this way, the gateway is able to take a busy call and try to do a redirect on the call leg to complete the call. To activate the ISDN redirect call, you need to use the direct-inward-dial command on the incoming dial-peer configuration (this function was covered in Chapter 4). The direct-inward-dial command sets a TRUE state to the function flag, and this determines whether a second dial tone is provided to the caller to collect another destination pattern. The following is an example of how a call is placed over ISDN Redirect: 1. A call is placed from Phone A to Phone B. 2. Phone B is not available (busy or not responding). 3. The call is rerouted to the gateway. 4. The incoming call to the gateway arrives in the form of a setup message containing calling/called and redirect number information. calling = Phone A called = gateway redirect number = Phone B 5. The gateway matches the dial-peer destination pattern against the called number. 6. The gateway places the call to the proper remote gateway with: •

calling = Phone A

•

called = Phone B 1. The remote gateway matches the outgoing dial-peer with destination pattern B.

RAS: Registration, Admissions, and Status RAS is the protocol and signaling mechanism that H.323 uses for registration, admissions control, status messages, and disengage procedures between the VoIP gateways and gatekeepers. The RAS system is handled within Cisco by implementing two commands within the dial-peer configurations: •

tech-prefix or zone prefix to register a technology type with the local gatekeeper

•

session target ras

The session target command was described in Chapter 4, where VoIP used it on dial-peers to route a call to the next gateway or gatekeeper for handling. Previously, a DNS name or IP address was needed to complete the command, thus statically assigning addressing to the gateways. Now, when using H.323, you can specify RAS as the method of routing a call, thus forcing the session target



command to find the gatekeeper that the gateway is registered with to resolve the call over H.323. This allows for dynamic changes in the underlying IP architecture without affecting H.323 systems riding over it. RAS performs two basic functions once the session target ras command has been initialized: •

Gatekeeper Discovery

•

RAS State Machine operations.

Gateway Discovery When a gateway initializes and comes online, it first attempts to locate and register with the local gatekeeper. If the gatekeeper is not available, it will periodically re-attempt to find a gatekeeper until its registration is completed. The gateway can be configured to register with the local gatekeeper using either a static IP address (unicast method) or a special assigned multicast address that will broadcast for a gatekeeper to respond. The gateway cannot route any calls until it is registered with a gatekeeper. When a gatekeeper is located, the gateway will then register all of its data with the gatekeeper—for example, aliases, H.323 ID, call signaling address, tech and zone prefixes—and start requesting permission to route calls over the network.

RAS State Machine This is a fancy term for Reject/Request/Confirm operations that function between a gateway and gatekeeper. The gateway will converse with the gatekeeper and make Requests for admissions control, bandwidth control, and so forth, and will expect a response of Confirm or Reject on any Request made to the gatekeeper. If the gatekeeper does not respond, the RAS State Machine function allows the gateway to gracefully stop making Requests of the defunct gatekeeper and look for another gatekeeper to Confirm or Reject the Request. This is an example of the HSRP system in operation. The gateway will not forward any calls without authorization. Table 5.2 lists different message types that will be seen between RAS entities. Table 5.2 Message Types in RAS Entities ACF Admission Confirmation ARJ Admission Reject ARQ Admission Request BCF Bandwidth Change Confirmation BRJ Bandwidth Change Reject BRQ Bandwidth Change Request GCF Gatekeeper Confirmation GRJ Gatekeeper Reject GRQ Gatekeeper Request LCF Location Confirmation LRJ Location Reject LRQ Location Request RCF Registration Confirmation RRJ Registration Reject RRQ Registration Request UCF Unregister Confirmation URJ Unregister Reject URQ Unregister Request Configuring an H.322 Gateway on Cisco Platforms To configure a basic H.323 gateway, you need to enable VoIP gateway functionality. You do this by using the gateway command. To enable gateway functionality, use the commands listed in Table 5.3. Table 5.3 Gateway Functionality Commands Step Command Description



1 2

configure terminal gateway

Enter global configuration mode. Enable the VoIP Gateway.

Configure Gateway Interface Parameters The next step in configuring an H.323 gateway is to configure the gateway interface parameters. You do this by first defining which interface will be presented to the VoIP network as this gateway's H.323 interface. Only one interface is allowed to be the gateway interface. You can select either the interface that is connected to the gatekeeper or a loopback interface. After you define the gateway interface, you configure the gateway to discover the gatekeeper, either through multicasting or by directing it to a specific host. Finally, you configure the gateway's H.323 identification number and any technology prefixes that this gateway should register with the gatekeeper. Use the commands listed in Table 5.4 to define the interface to be used as the H.323 gateway interface and configure the H.323 gateway interface parameters, beginning in global configuration mode. Table 5.4 Interface Definition Commands Step Command Description 1 interface type Enter interface configuration mode to configure parameters for the specified interface. slot/port 2 ip address ip- Specify the IP address for this interface. address subnet-mask h323-gateway Designate this interface as being the H.323 gateway interface. 3 voip interface h323-gateway Specify an H.323 name (ID) for the gateway associated with 4 voip h323-id this interface. This ID is used by this gateway when this gateway communicates with the gatekeeper. Usually, this interface-id H.323 ID is the name given to the gateway with the gatekeeper domain name appended to the end. h323-gateway Specify the name (ID) of the gatekeeper associated with this 5 gateway and how the gateway finds it. The gatekeeper ID voip id configured here must exactly match the gatekeeper ID in the gatekeeper gatekeeper configuration. The gateway determines the {ipaddr iplocation of the gateway in one of three ways: by a defined IP address [port]| multicast | ras} address, through multicast, or via RAS. 6

h323-gateway voip techprefix prefix

Specify a technology prefix. A technology prefix is used to identify a type of service that this gateway is capable of providing. Note: If a gateway is capable of handling multiple services, specify each service with a tech-prefix command.

AAA and Call Detail Records The AAA feature (Authentication, Authorization, and Accounting) is a required feature of the VoIP gateway system. Cisco’s AAA feature handled accounting for its generic routing functions, but now the enhancements built into version 2 of the H.323 specification allow for digits to be collected and processed from the IVR (Interactive Voice Response) system. Two of the new features in the AAA specification are: •

AAA can create Call Detail Records (CDRs).

•

AAA can authenticate a call based on information obtained from the IVR system or from caller ID data. This is done using the RADIUS authentication system.



Authentication is performed by the IVR system collecting digits that are then passed to the RADIUS system for verification. This action is performed on the gateway, not the gatekeeper, thereby consolidating call leg processing and freeing up the gatekeeper from the processing of validation functions. Authorization is currently limited to the user being authorized only. AAA cannot drill down to the specific access to different technologies and deny access to various resources. Accounting is performed with as much cohesion to the RADIUS system attributes as possible. For nonRADIUS attributes, the Acct-Session-Id attribute in the Call Detail Records will contain the various information fields. Data is collected about each call leg that gets created on the gateway. Each call generated by the gateway will have two legs (from the perspective of the gateway): incoming and outgoing. The outgoing and incoming legs of any given call can be correlated for troubleshooting using the Call ID, which will be the same for both legs. The standard RADIUS attributes recorded for each leg are as follows: •

Calling station ID

•

Called station ID

•

Call duration

•

Received bytes

•

Transmitted bytes

•

Received packets

•

Transmitted packets

Beyond the standard attributes for RADIUS, the following nonRADIUS attributes are recorded: •

Call leg setup time

•

Gateway identifier

•

Connection ID

•

Call leg direction (incoming to or outgoing from the gateway)

•

Call leg type (telephony or IP)

•

Call leg connect time

•

Call leg disconnect time

•

Call leg disconnect cause (Q.931 code)

•

Remote gateway IP address

Acct-Session-Id Field Any nonRADIUS, unsupported attributes are held in the Acct-Session-Id field. The field has a maximum of 256 characters and is designed to contain the RADIUS account session ID, which is a unique identifier based on the user’s login and the actual call. The field’s format is as follows. The field descriptions are listed in Table 5.5. session id/<setup time>////////

Table 5.5 Acct-Session-Id Field Descriptions



Field Identifier session id setup time gateway id call origin

call type connection id

connect time disconnect time disconnect cause

remote IP address

Description RADIUS account session ID. Q.931 setup time for the call. Name of underlying gateway (gateway.domain). Origin of call from the perspective of the gateway. Valid answers are originate and answer. Indicates call leg type. Valid answers are telephony or voip. Identifier to associate the call legs of the same call together. Hexadecimal in form. Q.931 connection time in NTP format (see NTP Time Format). Q.931 disconnect time in NTP format. Documented in Q.931 specifications. Valid answer is a decimal number ranged 1 to 160. Address of remote gateway port where the call is connected.

NTP Time Format The time fields in the Acct-Session-id field are configured for NTP format. The NTP format is displayed as %H:%M:%S.%k %Z %tw %tn %td %Y. •

%H is hour (00 to 23)

•

%M is minutes (00 to 59)

•

%S is seconds (00 to 59)

•

%k is milliseconds (000 to 999)

•

%Z is timezone

•

%tw is day of week (Saturday through Sunday)

•

%tm is month (January through December)

•

%td is day of month (01 to 31)

•

%Y is year including century (ex: 1999)

Examples of Call Detail Records Example 1: Start Record Acct-Delay-Time = 0 Client-Id = 10.1.2.5 NAS-Port-Type = 0 User-Name = "1001" Called-Station-Id = "+111"



Calling-Station-Id = "+222" Acct-Status-Type = Start User-Service-Type = Login-User Acct-Session-Id = "4/23:21:14.078 UTC Mon Oct 25 1999/ak3620-1.seattle.com/859BF275 D7C80001 0 3AFF4/originate/VoIP///"

Example 2: Stop Record Client-Id = 10.1.2.5 NAS-Port-Type = 0 User-Name = "1001" Called-Station-Id = "+111" Calling-Station-Id = "+222" Acct-Status-Type = Stop User-Service-Type = Login-User Acct-Session-Id = "4/23:21:14.078 UTC Mon Oct 25 1999/ak3620-1.seattle.com/859BF275 D7C80001 0 3AFF4/originate/VoIP/23:21:14.093 UTC Mon Oct 25 1999/23:21:23.084 UTC Mon Oct 25 1998/4" Acct-Input-Octets = 8340 Acct-Output-Octets = 8900 Acct-Input-Packets = 417 Acct-Output-Packets = 445 Acct-Session-Time = 9 Acct-Delay-Time = 0

Example 3: Update Record Client-Id = 10.1.2.5 NAS-Port-Type = 0 User-Name = "1001" Called-Station-Id = "+111" Calling-Station-Id = "+222" Acct-Status-Type = 3 User-Service-Type = Login-User Acct-Session-Id = "4/21:54:17.052 UTC Mon Oct 25 1999/ak3620-1.seattle.com/BF1AC9CA 8DE60006 0 5ED24/originate/VoIP///" Acct-Delay-Time = 0

Table 5.6 Example AAA Configuration Step Command Description router1(config)# aaa new-Initiates the AAA script. 1 model 2

router1(config)# aaa authentication login h323 radius

Configures the router to use the H.323 method list for authentication purposes.

3

router1(config)# aaa accounting connection h323 start-stop radius

Tells the system to use connection-based accounting and the H.323 service.



4

router1(config)# radius- This command sets the server host IP address, and server host 10.1.2.5 the ports for both the authentication service and the auth-port 165 acct-port accounting service. 1646

5

router1(config)# radius- Tests the connection accounting service. server key testing123

The following example shows the show running-config output for authentication and accounting: aaa new-model aaa authentication local-override aaa authentication login default radius ! gw-accounting h323 ! radius-server host 10.90.1.1 auth-port 1645 acct-port 1646 radius-server key gte

Interactive Voice Response The Interactive Voice Response (IVR) feature for gateways provides the ability to enter destination numbers, passwords, user IDs, and any other items needed for entry via a telephone keypad. This can be a series of voice response menus, security codes, or other user feedback information. The IVR system consists of simple voice prompts, which can be modified via the user’s discretion, and a digit collection facility to collect information from the caller. IVR allows for the use of predefined embedded scripts. These scripts cannot be modified under the current code, but the audio prompts within the scripts can be modified for customization of your network. The user is prompted via audio script to supply information, and the digit collection facility starts collecting data to be interpreted. The IVR can be set to activate via specific ports of a DNIS entry. The DNIS entry format allows the system to launch an IVR script if a particular destination pattern is accessed. This allows for security to be applied to particular endpoints, while other endpoints can have open access. This also allows a user to access voicemail at his or her station without having to enter that station’s DNIS. To activate IVR for a dial-peer, use the application field during configuration to choose the particular application to be activated. This functionality is only for pots type dial-peers. The application field designates which IVR application will be run in association with the dial-peer. Security to certain dial-peers can be controlled via ANI authentication. The origin pattern is used as the account number for an application, which will then prompt IVR to get information from the person accessing the ANI station. When the ANI picks up, a tone indicates that an account number or password needs to be entered. When this happens, either the caller will be denied or the system will provide a dial tone for a destination pattern to be collected. This is often used to track long-distance billing in companies.

IVR Scripts The following are the embedded IVR scripts available from Cisco. The code can be displayed on any IVR-enabled router by using the show call application voice [|summary] command. •

clid_authen•Authenticates the call with ANI and DNIS, collects the destination data, and makes the call.

•

clid_authen_collect•Authenticates the call with ANI and DNIS and collects the destination data. If authentication fails, it collects the account and password.

•

clid_authen_npw•Same as clid_authen, but uses a NULL password when authenticating rather than DNIS.

•

clid_authen_col_npw•Same as clid_authen_collect, but uses a NULL password, and does not use or collect DNIS.

• clid_col_npw_3•This script is similar to clid_authen_col_npw, but it allows two retries (three tries total) for entering the account and password. For each of the two retries, it plays a special retry message. •

clid_col_npw_npw•This is similar to clid_col_npw_3, but it does not collect a PIN number. Instead, it uses the collected account number with a NULL password for authentication.

Fax Hop On/Off file:///H:/edonkey/docs/programming/SYNGRESS_Configuring_Cisco_Voice_OverIP.JanezSlovenec/70_voip_web_05.htm (14 of 30) [13/12/02 18:19:17]


Fax Hop on/off allows for the use of redialer boxes common with FAX applications (see the “Store and Forwarding Fax “section later in this chapter for more detail). The redialer is a small unit that sits between the FAX machine and the equipment providing the voice line for sending. The redialer will collect the digits, call the originating telephone equipment for line access, and supply the destination pattern for calling the far endpoint. The following IVR application is specifically designed to handle this function: • fax_hop_on_1•This application interacts with the redialer and collects digits from it; for example, a collect account number and destination number. When placing the call to H.323, the set of fields in the call info structure are entered, destination, and account.

Procedure for Creating Audio (AU) Files IVR applications make use of audio files to prompt the user to enter certain information. These files need to be stored on the IVR application-serving device for use with the scripts. In order to provide your own audio files for the IVR applications, you will need to use the following procedure to embed them in the IVR application: 1. Use the copy command to TFTP audio files (*.au) to the flash memory of the gateway: copy tftp flash filename

2. Use the audio-prompt load command to read the audio file into RAM for use with the IVR application: audio prompt-load filename

Store-and-Forward Fax Store-and-Forward faxing is a feature provided on the AS5300 Access Server platform. It allows the AS5300 to transmit and receive faxes across an IP network. This is done using the dial-peer technology of the VoIP feature set for the 5300 line, but does not require any voice port hardware to be configured on the system. Rather, the Store-and-Forward Fax system uses dial-peer configurations with an installed modem to complete and send faxes over the IP network. With Store-and-Forward faxing, you can perform the following: •

Send and receive faxes to and from Group 3 FAX devices

•

Receive faxes that will be delivered as e-mails with TIFF attachments

•

Create and send a standard e-mail message that will be delivered as a fax to a standard Group 3 FAX device

To comprehend how the AS5300 performs faxing, the concept of on-ramp gateway and off-ramp gateway interfaces needs to be understood.

On-Ramp and Off-Ramp Gateway Concepts The on-ramp gateway on an AS5300 acts as a facility to accept faxes from end-users’ faxes and convert them into TIFF graphic files. The AS5300 then creates a standard multipurpose Internet mail extensions (MIME) e-mail message and attaches the TIFF file created from the fax to it. The e-mail is then sent to an SMTP mail server that will forward the message to the appropriate user. The SMTP MTA (message transfer agent) server is responsible for delivering the mail to the user. Once the message is in the hands of the MTA, it can be handled one of two ways: 1) the MTA can send it to an end user as a standard e-mail with attachment, or 2) send it off as a fax to a Group 3 FAX device. If option 2 is used, the MTA must have the ability to send the e-mail to an entity that can translate the mail message and attachment to a fax format and then fax it out. The AS5300 can perform this operation as well—it is called off-ramp gateway operation. The off-ramp gateway can translate the attached TIFF file to a fax format and send the fax off to a Group 3 device. The offramp gateway can also perform functions to create fax headers and handle DSNs (delivery status notifications) and MDNs (message disposition notifications).

Configuration of Store-and-Forward Faxing There are several prerequisites for setting up Store-and-Forward Faxing: 1. Set up and test the AS5300 system on a working IP network. The AS5300 needs to have an IOS installed with VoIP options available, but it does not need to be configured for VoIP hardware. The dial-peer software technology is the only part needed to perform Store-and-Forward Faxing. 2. Configure the SMTP server to support Store-and-Forward Faxing. (We will not go into detail on the functions and conversions needed to enable the Store-and-Forwarding features on particular SMTP servers, since each SMTP server system has different settings. Refer to your SMTP server vendor for instructions on how to enable the Store-and-Forward capabilities



properly.) 3. Decide whether to use Redialers or DID (Direct Inward Dialing) and perform the proper configurations. 4. Set up the dial-peers on the AS5300 for mail and fax routing. Redialer vs. Direct-Inward-Dialing The faxing technology works with one of two methods: using a direct-inward-dialing feature on the dial-peer configurations, or using a hardware device called a redialer. If DID has not been enabled, you must install a redialer on the originating FAX machine for Store and Forward to work. Use a redialer under the following conditions: •

Provisioning a DID service is not possible.

•

You need user information, such as a PIN number or security code for accounting.

•

T1-CAS signaling is being used.

The redialer is attached to the originating FAX machine between the FAX machine and the PSTN. When a telephone number is entered into the FAX machine, the digits are captured and sent via proxy to the on-ramp gateway of the AS5300, which provides a dial tone to the redialer to collect the digits. The originating number provided is the number of the FAX machine, so all intermediate operations are transparent to the user. As long as the no direct-inward-dial command is on the on-ramp dial-peer, a secondary dial tone will be provided to the redialer. If the direct-inward-dial command is configured on the dial-peer, then the AS5300 is expecting a proxied number to be sent and it will reinterpret the message with the buffered originating pattern. On the AS5300, you need to configure an MMoIP dial-peer to match the forwarded digits from the redialer. When a fax is received, the destination pattern is mapped against any MMoIP dial-peers for a match and is then converted to a TIFF file and e-mail message according to the settings in the MMoIP dial-peer. Configuring the On-Ramp Gateway Follow these steps to configure the On-Ramp Gateway features: 1. Configure the Called Subscriber Number. 2. Configure the Sending Mail Transport Agent. 3. Configure the On-Ramp POTS dial-peers. 4. Configure the On-Ramp MMoIP dial-peers. Configure the Called Subscriber Number The called subscriber number is the number displayed on the LCD screen of the originating FAX machine. To configure the called subscriber number, perform the task in Table 5.7. Table 5.7 Configure the Called Subscriber Number Step Command router1(config)# fax received 1 called-subscriber ($d$|string)

Description Defines the number displayed on the sending FAX machine.

Configure the Sending Mail Transport Agent The next task is to assign all of the variables for the particular MTA server that you are using for faxing. Use these commands to change any of the following parameters associated with the e-mail being created (see Table 5.8): •

Subject

•

Destination



•

Return Path

•

Postmaster

•

Any additional information for the e-mail header

•

Address for disposition notices to be sent to

Table 5.8 Assigning the Variables for the Particular MTA Server Step Command Description router1(config)# mta Specifies the originator (hostname) of the fax message. 1 send mail-from When configured, the hostname is used in conjunction with the mta send mail-from username command to hostname string generate a complete e-mail address to send the fax to. router1(config)# mta Specifies the originator (username) of the fax message. 2 send mail-from When configured, the username is used in conjunction with the mta send mail-from hostname command to (username string | generate a complete e-mail address to send the fax to. username $s$) router1(config)# mta Specifies the destination server. 3 send server (hostname|IP address) router1(config)# mta Defines the subject field of the e-mail generated. 4 send subject string router1(config)# mta Defines an address to send the e-mail if either the 5 send postmaster email- hostname and/or username are blank. address Configure the On-Ramp POTS Dial-Peer The next task is to create an On-Ramp POTS dial-peer to define the characteristics between the PSTN and the AS5300. The AS5300 uses the parameters set by the POTS dial-peer to determine which MMoIP interface to send the message out to. Use the steps listed in Table 5.9 to configure the On-ramp POTS dial-peer. Table 5.9 Configuring the On-Ramp POTS Dial-Peer Step Command Description router1(config)# dial- Defines a POTS dial-peer tag number and enters the 1 peer voice number pots dial-peer configuration mode. 2 3

4

5

router1(config-dial-)# information-type fax router1(config-dial-)# direct-inward-dial

Identifies the incoming calls associated with this peer as fax as opposed to voice transmissions. This allows for the secondary dial tone to be generated for the collection of the destination digits. Do not use this step if a redialer is being used. router1(config-dial-)# Defines the telephone number associated with the dialincoming called-number peer. The DNIS is used to match the call with an MMoIP peer. string router1(config-dial-)# (Optional) Maximum number of on-ramp connection available on this 5300. max-conn number

Configure the On-Ramp MMoIP Dial-Peer



The next task is to create an On-Ramp MMoIP dial-peer to define the characteristics between the AS5300 and the SMTP MTA. The AS5300 uses the parameters set by the MMoIP dial-peer to determine how to form the e-mail message that carries the TIFF fax message. There are a few concepts that need to be addressed before configuring the MMoIP dial-peer: • Image encoding and image resolution: Use the image resolution command to decrease or increase the resolution of the TIFF file generated from the fax message,. The default for the TIFF resolution is set to passthrough, which means that whatever resolution comes in, the gateway sends it out the same way. See Table 5.10 for different settings adjustments. • Delivery Status Notification (DSN): DSNs are automatically generated and sent to the originating sender, notifying the sender of the status of the message. Three possible states can be reported back to the sender. •

Delay: The message was delayed for some reason in being delivered to the final destination.

•

Success: Indicates that the message has been successfully delivered.

•

Failure: The SMTP server was unable to deliver the message.

•

Message Delivery Notification: This notification is sent back to the originating sender indicating that the message has been opened and read.

Table 5.10 Configuring the On-Ramp MMoIP Dial-Peer Step Command Description 1 router1(config)# dial-peer voice number Defines a MMoIP dial-peer tag number and enters the mmoip dial-peer configuration mode. router1(config-dial-)# information-type Identifies the incoming calls 2 fax associated with this peer as fax as opposed to voice transmissions router1(config-dial-)# destination Identifies the destination fax 3 telephone number. If DID is pattern [+] string enabled, this should be the same as the called number. If DID is not enabled, this will be the phone number of the redialer. router1(config-dial-)# session target Defines the destination 4 email address for the fax{mailto: {name|$d$}@domainmail (SMTP server address). name|ipv4:destinationaddress|dns:[$s$.|$d$.|$u$.|$e$.]hostname|loopback:rtp|loopback:compressed |loopback:uncompresed} router1(config-dial-)# session-protocol Identifies the SMTP 5 smtp protocol as the sending entity transport. router1(config-dial-)# image encoding Identifies the encoding 6 {mh | mr | mmr | passthrough} method for the TIFF file attachments.



router1(config-dial-)# image resolution {fine | standard | super-fine | passthrough} router1(config-dial-)# max-conn number

7

8

9

router1(config-dial-)# dsn {delay | failure | success}

10

router1(config-dial-)# session-protocol smtp

Identifies the level of resolution for the TIFF file attachments. (Optional) Defines the number of simultaneous fax connections to the 5300. (Optional) Replies to username previously identified as to status of the message. The SMTP server must support DSN.

Configuring the Off-Ramp Gateway The off-ramp gateway is necessary if there is a need to create fax messages from e-mail messages and send them out to standard Group 3 FAX machines. The off-ramp gateway can perform the following tasks: •

Convert a fax-mail and attached TIFF file to a standard fax transmission, along with fax header and other features, and send it out to a standard Group 3 FAX machine.

• Deliver an e-mail as a standard fax transmission, which is received and processed by a standard FAX machine. The source is an e-mail message, and the 5300 will generate header and fax cover sheets for the transmission. The off-ramp gateway generally uses POTS dial-peers to handle its transmission. To configure the off-ramp gateway, perform the following tasks: 1. Configure the Transmitting Subscriber Number. 2. Configure the FAX Transmission Speed. 3. Configure the Receiving Mail Transfer Agent. 4. Configure the Off-Ramp POTS Dial-Peer. 5. Configure the Fax Header Information. 6. Configure the Fax Cover Page Information. The last two tasks only apply when the fax originates as an e-mail message. Otherwise, they do not need to be configured. Configure the Transmitted Subscriber Number The transmitted subscriber number is the number displayed on the LCD screen of the destination FAX machine. To configure the transmitted subscriber number, perform the tasks listed in Table 5.11. Table 5.11 Configuring the Transmitted Subscriber Number Step Command Description router1(config)# fax send Defines the number displayed on the 1 transmitted-subscriber destination FAX machine. ($d$|string) Configure the FAX Transmission Speed file:///H:/edonkey/docs/programming/SYNGRESS_Configuring_Cisco_Voice_OverIP.JanezSlovenec/70_voip_web_05.htm (19 of 30) [13/12/02 18:19:17]


The next step is to configure the maximum transmission speed for the transmission (see Table 5.12). Table 5.12 Configuring the Maximum Transmission Speed for the Transmission Step Command Description router1(config)# fax send max-speed Specifies the off-ramp fax 1 {12000 | 14400 | 2400 | 4800 | 7200 | transmission speed. 7600} Configure the Receiving Mail Transport Agent The next task is to assign all of the variables for the particular MTA server you are using for faxing (See Table 5.13). Table 5.13 Assigning the Variables for the Particular MTA Server Step Command Description router1(config)# mta receive Specifies the aliases for the MTA server. You 1 can specify up to 10 aliases to send to. aliases string 2 3

router1(config)# mta receive (Optional) Configures the AS5300 to generate generate-mdn an MDN message when requested. router1(config)# mta receive Defines the maximum number of simultaneous recipients handled by the AS5300. maximum-recipients number

Configure the Off-Ramp POTS Dial-Peer The next task is to create an Off-Ramp POTS dial-peer to define the characteristics between the receiving FAX device and the AS5300. Use the steps listed in Table 5.14 to configure the On-ramp POTS dial-peer. Table 5.14 Configuring the On-Ramp POTS Dial-Peer Step Command Description router1(config)# dial-peer Defines a POTS dial-peer tag number and 1 enters the dial-peer configuration mode. voice number pots 2

router1(config-dial-)# information-type fax

3

router1(config-dial-)# destination pattern [+] string router1(config-dial-)# prefix number

4

Identifies the incoming calls associated with this peer as fax as opposed to voice transmissions. Identifies the destination fax telephone number.

(Optional) Specifies the prefix of the dialed numbers associated with the dial-peer.

Configure the Faxed Header Information Store and Forward allows standard e-mail to be converted to fax transmissions. In most standard faxes, header information is appended to the top of each faxed page. You can configure the AS5300 to translate the information in the e-mail message to header information for the resulting fax. Use the procedure in Table 5.15 to set up fax header information. Table 5.15 Setting Up Fax Header Information Step Command

Description



1

2

3

router1(config)# fax send Specifies the information for the center center-header {$a$ | $d$ | $p$ field of the header. The variables represent the following: | $s$ | string} $a$•date $d$•destination address $s$•source address $p$•# of pages $t$•transmission time string is used for personalized header information. router1(config-dial-)# fax Same as above, only for the right header. send right-header {$a$ | $d$ | $p$ | $s$ | string} router1(config-dial-)# fax Same as above, only for the left header. send left-header {$a$ | $d$ | $p$ | $s$ | string}

Configure the Fax Cover Page Information Store and Forward allows standard e-mail to be converted to fax transmissions. In most standard faxes, you will want to include a cover page for the fax. You can configure the AS5300 to translate the information in the e-mail message into cover page information for the resulting fax. Use the procedure in Table 5.16 to set up fax cover page information. Table 5.16 Setting Up Fax Cover Page Information Step Command Description router1(config)# fax send Enables the off-ramp gateway to send a 1 coverpage enable cover page for e-mail originating faxes. 2 3

router1(config-dial-)# fax (Optional) Adds personalized text in the send coverpage comment string string variable. router1(config-dial-)# fax (Optional) Adds the e-mail header send coverpage show-detail information to the cover page.

Advanced Troubleshooting Several commands allow for the monitoring, verifying, and troubleshooting of the gateways and gatekeepers on Cisco platforms. Listed in this section are some of the basic troubleshooting commands that are available, along with some sample output as to what each command produces.

show gateway The show gateway command is used to verify and troubleshoot the current configuration of a Cisco gateway. The following example shows the report that appears when the gateway is not registered with a gatekeeper. gw-1#show gateway Gateway gw-1 is not registered to any Gateway alias list H323-ID gw-1 H323 resource thresholding is Enabled H323 resource threshold values: DSP: Low threshold 60, High threshold DS0: Low threshold 60, High threshold

gatekeeper

but NOT Active 70 70

This next example indicates that an E.164 address has been assigned to the gateway.


Chapter 5: Advanced Voice over Configuration gw-1#show gateway Gateway gw-1 is registered to Gatekeeper gk1 Gateway alias list E.164 Number 5551212 H323-ID gw-1

The next example shows the report that appears when the gateway is registered with a gatekeeper and H.323 resource threshold reporting is enabled with the resource threshold command. gw-1#show gateway Gateway gw-1 is registered to Gatekeeper gk1 Gateway alias list H323-ID gw-1 H323 resource thresholding is Enabled and Active H323 resource threshold values: DSP: Low threshold 60, High threshold 70 DS0: Low threshold 60, High threshold 70

The following example shows the report that appears when the gateway is registered with a gatekeeper and H.323 resource threshold reporting is disabled with the no resource threshold command. gw-1#show gateway Gateway gw-1 is registered to Gatekeeper gk1 Gateway alias list H323-ID gw-1 H323 resource thresholding is Disabled show gateway endpoints

This command displays all of the registered H.323 endpoints for the given gatekeeper. Following is a sample of the output. Table 5.17 lists the fields and their descriptions. Router#show gatekeeper endpoints CallsignalAddr Port RASSignalAddr Port Zone Name Type F --------------- ---- ------------- ----- ---------------172.21.127.81720 172.21.127.824999 sj-gk MCU H323-ID:[email protected] 172.21.13.881720 172.21.13.881719 sj-gk VOIP-GW O H323-ID:la-gw

Table 5.17 Registered H.323 Endpoints Field Description CallsignalAddr The endpoint's call-signaling IP address. If the endpoint also registered with alias(s), a list of all aliases registered for that endpoint should also be listed on the line below. Port The endpoint's call-signaling port number. RASSignalAddr The endpoint's RAS IP address. Port The endpoint's RAS port number. Zone Name Zone name (gatekeeper ID) which this endpoint registered in.. Type The endpoint type (terminal, gateway, MCU, and so forth). F 'S' --- Indicates that the endpoint is statically entered from the alias command--rather than dynamically registered through RAS messages. `O' --- Indicates that the endpoint, which is a gateway, has sent notification that it is almost out of resources.

debug ras Use the debug ras command to view sent and received RAS messages on a given router. Following are some examples of the output. In the following output, gateway GW1.seattle.com sends a RAS registration request message (RRQ) to gatekeeper GK1.seattle.com at IP address 10.1.2.5. GW1.seattle.com then receives a registration confirmation (RCF) message from the gatekeeper. If there is no response, it could mean that the gatekeeper is offline or improperly addressed. If you receive a reject message (RRJ), it



could mean that the gatekeeper is unable to handle another gateway or that the registration information is incorrect. GW.1#debug ras *Oct 29 19:53:34.231: *Oct 29 19:53:34.231: *Oct 29 19:53:34.247: *Oct 29 19:53:34.251:

RASlib::ras_sendto:msg length 105 from 10.1.2.5:8658 to 10.1.2.3:1719 RASLib::RASSendRRQ:RRQ (seq# 36939) sent to 10.1.2.3 RASLib::RASRecvData:successfully rcvd message of length 105 from 10.1.2.5:1719 RASLib::RASRecvData:RCF (seq# 36939) rcvd from [10.1.2.5:1719] on sock [0x6168356C

debug h225 Use the debug h225 command to display additional information about the actual contents of H.225 RAS messages. asn1•Indicates that only the ASN.1 contents of any H.225 message sent or received will be displayed. events•Indicates that key Q.931 events that occur when placing a H.323 call from one gateway to another will be displayed. The following is an example of a string of messages debugged under the events mode: GW-1# debug h225 events H.225 Event Messages debugging is on GW-1# *Oct 29 02:47:14.689: H225Lib::h225TConn:connect in progress on socket [2] *Oct 29 02:47:14.689: H225Lib::h225TConn:Q.931 Call State is initialized to be [Null]. *Oct 29 02:47:14.697:Hex representation of the SETUP TPKT to send.0300004D080200DC05040380C0A36C0991313323313333303070099131342331343330307E0026050080060008914A000102004B1F5E5D8990006C0000000005BF7454000C0700000000000000 *Oct 29 02:47:14.701: *Oct 29 02:47:14.701: H225Lib::h225SetupRequest:Q.931 SETUP sent from socket [2] *Oct 29 02:47:14.701: H225Lib::h225SetupRequest:Q.931 Call State changed to [Call Initiated]. *Oct 29 02:47:14.729:Hex representation of the received TPKT03000021080280DC013401017E0012050340060008914A000100000109350E2B28 *Oct 29 02:47:14.729: *Oct 29 02:47:14.729: H225Lib::h225RecvData:Q.931 ALERTING received from socket [2] *Oct 29 02:47:14.729: H225Lib::h225RecvData:Q.931 Call State changed to [Call Delivered]. *Oct 29 02:47:17.565:Hex representation of the received TPKT03000034080280DC07040380C0A37E0023050240060008914A0001000109350E2B2802004B1F5E5D8990006C0000000005BF7454 *Oct 29 02:47:17.569: *Oct 29 02:47:17.569: H225Lib::h225RecvData:Q.931 CONNECT received from socket [2] *Oct 29 02:47:17.569: H225Lib::h225RecvData:Q.931 Call State changed to [Active]. *Oct 29 02:47:23.273:Hex representation of the received TPKT0300001A080280DC5A080280107E000A050500060008914A0001 *Oct 29 02:47:23.273: *Oct 29 02:47:23.273: H225Lib::h225RecvData:Q.931 RELEASE COMPLETE received from socket [2] *Oct 29 02:47:23.273: H225Lib::h225RecvData:Q.931 Call State changed to [Null]. *Oct 29 02:47:23.293:Hex representation of the RELEASE COMPLETE TPKT to send.0300001A080200DC5A080280107E000A050500060008914A0001 *Oct 29 02:47:23.293: *Oct 29 02:47:23.293: H225Lib::h225TerminateRequest:Q.931 RELEASE COMPLETE sent from socket [2]. Call state changed to [Null]. *Oct 29 02:47:23.293: H225Lib::h225TClose:TCP connection from socket [2] closed

The following output shows the same call being placed from gateway GW1 to gateway GW2 using the debug h225 asn1 command. The output is very long, but you can track the following information: •

The admission request to the gatekeeper.

•

The admission confirmation from the gatekeeper.



•

The ASN.1 portion of the H.225/Q.931 setup message from the calling gateway to the called gateway.

•

The ASN.1 portion of the H.225/Q.931 setup response from the called gateway, indicating that the call has proceeded to alerting state.

•

The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has been connected.

•

The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has been released.

•

The ANS.1 portion of the H.225 RAS message from the calling gateway to the gatekeeper, informing it that the call has been disengaged.

•

The ASN.1 portion of the H.225 RAS message from the gatekeeper to the calling gateway, confirming the disengage request.

•

The ASN.1 portion of the H.225/Q.931 release complete message sent from the called gateway to the calling gateway.

gw-1# debug h225 asn1 H.225 ASN1 Messages debugging is on gw-1# value RasMessage ::= admissionRequest : *Oct 29 02:48:18.445: { *Oct 29 02:48:18.445: requestSeqNum 03320, *Oct 29 02:48:18.445: callType pointToPoint :NULL, *Oct 29 02:48:18.445: callModel direct :NULL, *Oct 29 02:48:18.445: endpointIdentifier "60D6BA4C00000001", *Oct 29 02:48:18.445: destinationInfo *Oct 29 02:48:18.445: { *Oct 29 02:48:18.445: e164 :"14#14300" *Oct 29 02:48:18.445: }, *Oct 29 02:48:18.449: srcInfo *Oct 29 02:48:18.449: { *Oct 29 02:48:18.449: e164 :"13#13300" *Oct 29 02:48:18.449: }, *Oct 29 02:48:18.449: bandWidth 0640, *Oct 29 02:48:18.449: callReferenceValue 0224, *Oct 29 02:48:18.449: conferenceID '4B1F5E5D899000720000000005C067A4'H, *Oct 29 02:48:18.449: activeMC FALSE, *Oct 29 02:48:18.449: answerCall FALSE *Oct 29 02:48:18.449: } *Oct 29 02:48:18.449:25800CF7 00F00036 00300044 00360042 00410034 00430030 00300030 00300030 00300030 00310103 80470476 33010380 46046633 40028000 E04B1F5E 5D899000 72000000 0005C067 A400 29000CF7 40028000 0109350E 06B80077 value RasMessage ::= admissionConfirm : *Oct 29 02:48:18.469: { *Oct 29 02:48:18.469: requestSeqNum 03320, *Oct 29 02:48:18.469: bandWidth 0640, *Oct 29 02:48:18.469: callModel direct :NULL, *Oct 29 02:48:18.469: destCallSignalAddress ipAddress : *Oct 29 02:48:18.469: { *Oct 29 02:48:18.469: ip '0109350E'H, *Oct 29 02:48:18.469: port 01720 *Oct 29 02:48:18.469: }, *Oct 29 02:48:18.469: irrFrequency 0120 *Oct 29 02:48:18.473: } *Oct 29 02:48:18.473:value H323-UserInformation ::=


Chapter 5: Advanced Voice over Configuration *Oct 29 02:48:18.481:{ *Oct 29 02:48:18.481: h323-uu-pdu *Oct 29 02:48:18.481: { *Oct 29 02:48:18.481: h323-message-body setup : *Oct 29 02:48:18.481: { *Oct 29 02:48:18.481: protocolIdentifier { 0 0 8 2250 0 1 }, *Oct 29 02:48:18.481: sourceInfo *Oct 29 02:48:18.481: { *Oct 29 02:48:18.481: terminal *Oct 29 02:48:18.481: { *Oct 29 02:48:18.481: }, *Oct 29 02:48:18.481: mc FALSE, *Oct 29 02:48:18.481: undefinedNode FALSE *Oct 29 02:48:18.481: }, *Oct 29 02:48:18.481: activeMC FALSE, *Oct 29 02:48:18.481: conferenceID '4B1F5E5D899000720000000005C067A4'H, *Oct 29 02:48:18.481: conferenceGoal create :NULL, *Oct 29 02:48:18.485: callType pointToPoint :NULL, *Oct 29 02:48:18.485: sourceCallSignalAddress ipAddress : *Oct 29 02:48:18.485: { *Oct 29 02:48:18.485: ip '00000000'H, *Oct 29 02:48:18.485: port 00 *Oct 29 02:48:18.485: } *Oct 29 02:48:18.485: } *Oct 29 02:48:18.485: } *Oct 29 02:48:18.485:} *Oct 29 02:48:18.485:00800600 08914A00 0102004B 1F5E5D89 90007200 00000005 C067A400 0C070000 00000000 00 value H323-UserInformation ::= *Oct 29 02:48:18.525:{ *Oct 29 02:48:18.525: h323-uu-pdu *Oct 29 02:48:18.525: { *Oct 29 02:48:18.525: h323-message-body alerting : *Oct 29 02:48:18.525: { *Oct 29 02:48:18.525: protocolIdentifier { 0 0 8 2250 0 1 }, *Oct 29 02:48:18.525: destinationInfo *Oct 29 02:48:18.525: { *Oct 29 02:48:18.525: mc FALSE, *Oct 29 02:48:18.525: undefinedNode FALSE *Oct 29 02:48:18.525: }, *Oct 29 02:48:18.525: h245Address ipAddress : *Oct 29 02:48:18.525: { *Oct 29 02:48:18.525: ip '0109350E'H, *Oct 29 02:48:18.525: port 011050 *Oct 29 02:48:18.525: } *Oct 29 02:48:18.525: } *Oct 29 02:48:18.525: } *Oct 29 02:48:18.525:} *Oct 29 02:48:18.525:value H323-UserInformation ::= *Oct 29 02:48:22.753:{ *Oct 29 02:48:22.753: h323-uu-pdu *Oct 29 02:48:22.753: { *Oct 29 02:48:22.753: h323-message-body connect : *Oct 29 02:48:22.753: { *Oct 29 02:48:22.753: protocolIdentifier { 0 0 8 2250 0 1 }, *Oct 29 02:48:22.753: h245Address ipAddress : *Oct 29 02:48:22.753: { *Oct 29 02:48:22.753: ip '0109350E'H,


Chapter 5: Advanced Voice over Configuration *Oct 29 02:48:22.753: port 011050 *Oct 29 02:48:22.753: }, *Oct 29 02:48:22.753: destinationInfo *Oct 29 02:48:22.753: { *Oct 29 02:48:22.753: terminal *Oct 29 02:48:22.753: { *Oct 29 02:48:22.753: }, *Oct 29 02:48:22.757: mc FALSE, *Oct 29 02:48:22.757: undefinedNode FALSE *Oct 29 02:48:22.757: }, *Oct 29 02:48:22.757: conferenceID '4B1F5E5D899000720000000005C067A4'H *Oct 29 02:48:22.757: } *Oct 29 02:48:22.757: } *Oct 29 02:48:22.757:} *Oct 29 02:48:22.757:value H323-UserInformation ::= *Oct 29 02:48:27.109:{ *Oct 29 02:48:27.109: h323-uu-pdu *Oct 29 02:48:27.109: { *Oct 29 02:48:27.109: h323-message-body releaseComplete : *Oct 29 02:48:27.109: { *Oct 29 02:48:27.109: protocolIdentifier { 0 0 8 2250 0 1 } *Oct 29 02:48:27.109: } *Oct 29 02:48:27.109: } *Oct 29 02:48:27.109:} *Oct 29 02:48:27.109:value RasMessage ::= disengageRequest : *Oct 29 02:48:27.117: { *Oct 29 02:48:27.117: requestSeqNum 03321, *Oct 29 02:48:27.117: endpointIdentifier "60D6BA4C00000001", *Oct 29 02:48:27.117: conferenceID '4B1F5E5D899000720000000005C067A4'H, *Oct 29 02:48:27.121: callReferenceValue 0224, *Oct 29 02:48:27.121: disengageReason normalDrop :NULL *Oct 29 02:48:27.121: } *Oct 29 02:48:27.121:3C0CF81E 00360030 00440036 00420041 00340043 00300030 00300030 00300030 00300031 4B1F5E5D 89900072 00000000 05C067A4 00E020 400CF8 value RasMessage ::= disengageConfirm : *Oct 29 02:48:27.133: { *Oct 29 02:48:27.133: requestSeqNum 03321 *Oct 29 02:48:27.133: } *Oct 29 02:48:27.133:value H323-UserInformation ::= *Oct 29 02:48:27.133:{ *Oct 29 02:48:27.133: h323-uu-pdu *Oct 29 02:48:27.133: { *Oct 29 02:48:27.133: h323-message-body releaseComplete : *Oct 29 02:48:27.133: { *Oct 29 02:48:27.133: protocolIdentifier { 0 0 8 2250 0 1 } *Oct 29 02:48:27.133: } *Oct 29 02:48:27.133: } *Oct 29 02:48:27.133:} *Oct 29 02:48:27.133:05000600 08914A00 01 .

Show Call Application Voice The show call application voice command defines the names of the audio files the script will play, the operation of the abort keys, prompts used, and caller interaction. The fields and their description are listed in Table 5.18. show call application voice [name | summary]



Table 5.18 The show call application voice Command Fields Field Description name The name of the desired IVR application. summary Enter this field to display a one line summary. If the command is entered without summary, a complete detailed description is displayed of the application. The following output is the result of a show call application voice clid_authen_collect : router1>show call application voice clid_authen_collect Application clid_authen_collect has 10 states with 0 calls active State start has 1 actions and 5 events Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnis If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK and goto state start If Event IVR_EV_AAA_SUCCESS goto state collect_dest If Event IVR_EV_AAA_FAIL goto state get_account State end has 1 actions and 3 events Do Action IVR_ACT_END. If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY and do nothing State get_account has 4 actions and 7 events Do Action IVR_ACT_PLAY. URL: flash:enter_account.au allowInt=1, pContent=0x60E4C564 Do Action IVR_ACT_ABORT_KEY. abortKey=* Do Action IVR_ACT_TERMINATION_KEY. terminationKey=# Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+ If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin patName=account If Event IVR_EV_ABORT goto state get_account If Event IVR_EV_PLAY_COMPLETE do nothing If Event IVR_EV_TIMEOUT goto state get_account count=0 If Event IVR_EV_PAT_COL_FAIL goto state get_account State get_pin has 4 actions and 7 events Do Action IVR_ACT_PLAY. URL: flash:enter_pin.au allowInt=1, pContent=0x0 Do Action IVR_ACT_ABORT_KEY. abortKey=* Do Action IVR_ACT_TERMINATION_KEY. terminationKey=# Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+ If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate patName=pin If Event IVR_EV_PLAY_COMPLETE do nothing If Event IVR_EV_ABORT goto state get_account If Event IVR_EV_TIMEOUT goto state get_pin count=0 If Event IVR_EV_PAT_COL_FAIL goto state get_pin


Chapter 5: Advanced Voice over Configuration State authenticate has 1 actions and 5 events Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_AAA_SUCCESS goto state collect_dest If Event IVR_EV_TIMEOUT do nothing count=0 If Event IVR_EV_AAA_FAIL goto state authenticate_fail State collect_dest has 4 actions and 8 events Do Action IVR_ACT_PLAY. URL: flash:enter_destination.au allowInt=1, pContent=0x0 Do Action IVR_ACT_ABORT_KEY. abortKey=* Do Action IVR_ACT_TERMINATION_KEY. terminationKey=# Do Action IVR_ACT_COLLECT_DIALPLAN. If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_PLAY_COMPLETE do nothing If Event IVR_EV_ABORT goto state collect_dest If Event IVR_EV_TIMEOUT goto state collect_dest count=0 If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest If Event IVR_EV_TIMEOUT goto state collect_dest count=0 State place_call has 1 actions and 4 events Do Action IVR_ACT_PLACE_CALL. destination= called= calling= account= If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_CALL_UP goto state active If Event IVR_EV_CALL_FAIL goto state place_fail State active has 0 actions and 2 events If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing State authenticate_fail has 1 actions and 2 events Do Action IVR_ACT_PLAY. URL: flash:auth_failed.au allowInt=0, pContent=0x0 If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing State place_fail has 1 actions and 2 events Do Action IVR_ACT_PLAY_FAILURE_TONE. If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing sblab115>show call application voice clid_authen_collect Application clid_authen_collect has 10 states with 0 calls active State start has 1 actions and 5 events Do Action IVR_ACT_AUTHENTICATE. accountName=ani, pinName=dnis If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_CALL_SETUP_IND do action IVR_ACT_CALL_SETUP_ACK and goto state start If Event IVR_EV_AAA_SUCCESS goto state collect_dest If Event IVR_EV_AAA_FAIL goto state get_account State end has 1 actions and 3 events Do Action IVR_ACT_END. If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing


Chapter 5: Advanced Voice over Configuration If Event IVR_EV_CALL_DISCONNECT_DONE do action IVR_ACT_CALL_DESTROY and do nothing State get_account has 4 actions and 7 events Do Action IVR_ACT_PLAY. URL: flash:enter_account.au allowInt=1, pContent=0x60E4C564 Do Action IVR_ACT_ABORT_KEY. abortKey=* Do Action IVR_ACT_TERMINATION_KEY. terminationKey=# Do Action IVR_ACT_COLLECT_PATTERN. Pattern account is .+ If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_PAT_COL_SUCCESS goto state get_pin patName=account If Event IVR_EV_ABORT goto state get_account If Event IVR_EV_PLAY_COMPLETE do nothing If Event IVR_EV_TIMEOUT goto state get_account count=0 If Event IVR_EV_PAT_COL_FAIL goto state get_account State get_pin has 4 actions and 7 events Do Action IVR_ACT_PLAY. URL: flash:enter_pin.au allowInt=1, pContent=0x0 Do Action IVR_ACT_ABORT_KEY. abortKey=* Do Action IVR_ACT_TERMINATION_KEY. terminationKey=# Do Action IVR_ACT_COLLECT_PATTERN. Pattern pin is .+ If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_PAT_COL_SUCCESS goto state authenticate patName=pin If Event IVR_EV_PLAY_COMPLETE do nothing If Event IVR_EV_ABORT goto state get_account If Event IVR_EV_TIMEOUT goto state get_pin count=0 If Event IVR_EV_PAT_COL_FAIL goto state get_pin State authenticate has 1 actions and 5 events Do Action IVR_ACT_AUTHENTICATE. accountName=account, pinName=pin If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_AAA_SUCCESS goto state collect_dest If Event IVR_EV_TIMEOUT do nothing count=0 If Event IVR_EV_AAA_FAIL goto state authenticate_fail State collect_dest has 4 actions and 8 events Do Action IVR_ACT_PLAY. URL: flash:enter_destination.au allowInt=1, pContent=0x0 Do Action IVR_ACT_ABORT_KEY. abortKey=* Do Action IVR_ACT_TERMINATION_KEY. terminationKey=# Do Action IVR_ACT_COLLECT_DIALPLAN. If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_PLAY_COMPLETE do nothing If Event IVR_EV_ABORT goto state collect_dest If Event IVR_EV_TIMEOUT goto state collect_dest count=0 If Event IVR_EV_DIAL_COL_SUCCESS goto state place_call If Event IVR_EV_DIAL_COL_FAIL goto state collect_dest If Event IVR_EV_TIMEOUT goto state collect_dest count=0 State place_call has 1 actions and 4 events Do Action IVR_ACT_PLACE_CALL. destination= called= calling= account=


Chapter 5: Advanced Voice over Configuration If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing If Event IVR_EV_CALL_UP goto state active If Event IVR_EV_CALL_FAIL goto state place_fail State active has 0 actions and 2 events If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing State authenticate_fail has 1 actions and 2 events Do Action IVR_ACT_PLAY. URL: flash:auth_failed.au allowInt=0, pContent=0x0 If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing State place_fail has 1 actions and 2 events Do Action IVR_ACT_PLAY_FAILURE_TONE. If Event IVR_EV_DEFAULT goto state end If Event IVR_EV_CALL_DIGIT do nothing

Summary In this chapter, we discussed the basic concepts associated with the H.323 standards for multiservice applications. H.323 is a registration, accounting, and control system that allows the network administrator to dynamically configure, control, and expand the VoIP network. The H.323 system is primarily based on two controlling entities: gateways and gatekeepers. Gateways are the service providers that allow access to various resources and applications for the Voice network. They can provide services to the public switched telephone networks, PBXs, and other areas of the IP network and special services such as Interactive Voice Response systems, messaging, and faxing. Gatekeepers are the controllers and directory servers on the H.323 systems. There is one gatekeeper for every defined zone of the H.323 network, and all H.323 registered entities must register with the gatekeeper in order to be eligible for access to resources and applications. Gatekeepers are also responsible for address translation between different zones and keeping track of how to route H.323 packets through the network. The gatekeeper is also responsible for bandwidth management on the network, selecting the best gateway for transmission of messages based on technology abilities, bandwidth availability, and preference settings. AAA (Authentication, Authorization, and Accounting) is a required feature of the Voice over IP gateway system. Cisco’s AAA feature handles the entire authentication of users, accounting of calls and dial-peers, and the authorization of users to access various applications and services on the network. AAA works in conjunction with RADIUS authentication protocols. IVR (Interactive Voice Response) allows users to run application scripts on the voice network by using digit collection algorithms prompted by audio files defined by the network administrator. Common examples of IVR include voice-messaging systems, and reception routing at main switchboards for companies. Store-and-Forward Faxing allows faxes to be sent via e-mail SMTP servers over the IP network. A fax can be received by an AS5300 and processed by the access server as a MIME e-mail message with a TIFF file attachment. The AS5300 is capable of converting faxes to e-mails and e-mails to faxes, and relaying of faxes from one section of the WAN to the other to avoid toll charging.

FAQs Q: Is it necessary to implement the advanced H.323 protocols covered in this chapter to use Voice over IP? A: No, it is not necessary to go through these configurations of H.323 gatekeeper/gateway entities when designing a Voice over IP network if the network does not require it. In fact, depending on the size of the network in question, this advanced H.323 configuration may become a hindrance rather than a help. In order to implement advanced H.323 services, you need to have enough equipment to handle the different roles of gateways and gatekeepers for each section, or zone, of the WAN. In small companies, this may be an unnecessary expense if the H.323 functionality does not buy you enough benefits to justify the cost of the extra equipment. Q: Can all Cisco platforms (2600, 3600, 7200, AS5300) handle all of the functions of H.323? A: No, each platform is capable of certain services, but they do not all support all of the service discussed in this chapter at this time. Always check with your Cisco consultant to determine which platform performs best with the service you are looking to implement. In many cases, a service or feature may be discontinued on one platform and enabled for another, while other features may become available that may affect your platform choices for VoIP in the future. Always consult with your Cisco representative to determine which platform is best for your given situation.


Chapter 6: AVVID


Chapter 6 AVVID (Architecture for Voice, Video and Integrated Data) Introduction AVVID IP Phones Phone Features Cisco Call Manager Call Manager Features Access Devices Analog Gateway Analog Station Digital Gateway AVVID Equipment Initialization and Registration Phone Initialization and Configuration How AVVID Works Placing an IP to IP Phone Call Placing an IP to PSTN Call Placing an IP to IP Call over the Wide Area Network Plug-in Applications Directory Services Virtual Phone CiscoValet Manual Attendant Conference Bridge Media Termination Point SUMI TAPI Interface Web Help


Chapter 6: AVVID

The Future is near… Summary

Solutions in this chapter: •

AVVID IP Phones

•

Cisco Call Manager

•

AVVID Equipment Initialization and Registration

•

The Future of AVVID

Cisco Systems has introduced a new Voice over IP (VoIP) based telephone to complement the already wide range of VoIP router-based solutions. Cisco acquired Selsius Systems in October of 1998 to gain instant market share of the IP based PBX market. Selsius was the leader of IP based phones and PBX technology, with over five years of development and having applied for over twelve communication related patents. Architecture for Voice, Video and Integrated Data (AVVID) emerged as the new product line name under Cisco, bringing Voice over IP to the end user.The release of the AVVID line completed phase four of Cisco’s five phase Voice over IP development cycle. These phones bring true VoIP technology to the desktop, as opposed to the router-based solution which is voice over data between Cisco routers. The ability to packetize voice as it enters the handset is important because the voice traffic has become yet another ‘user-based application’ consuming network bandwidth. Voice is the newest application added to the network, and its requirements need to be considered when designing the network. You will see that the Cisco AVVID product is a great technology that will make possible new uses for voice that have never been dreamed of before. AVVID is truly going to revolutionize the telecom industry. AVVID Components are all IP based and when combined create a PBX phone system. The components necessary to complete the IP PBX system including file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (2 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

phones, access gateways, and the management software that links them all together. The IP phones look, feel and function just as traditional PBX phones. The gateways are equivant to a line card or T1card in a PBX, and provided access to the outside Public Switched Telephone Network (PSTN). The Management software resides on a server that acts as the switching mechanism of a PBX. These devices and software are the equipment involved with the Cisco AVVID phone system.

AVVID IP Phones Two versions of AVVID IP phones available today are the 12 SP+ and the 30 VIP button phones (Figure 8.1). Each version supports all of the commonly used features that a traditional key-system or PBX phone would support. These phones have an RJ-45 ethernet jack built into the back to provide connectivity to the LAN using a one port hub to connect PCs or other network devices to the same ethernet drop. The AVVID phones are no more than a 386-processor computer packaged in a phone shell. The phones have a Digital Signal Processor (DSP) on board to convert analog voice streams into packetized data. Voice compression types of G.711 (64 Kbps) and G.723 (6.4 Kbps) are supported for LAN or WAN voice transmission.


Chapter 6: AVVID

Figure 6.1 Cisco IP phones, 12 SP+ and 30 VIP button. Tip The internal hub currently only supports 10BaseT connections. Look for the next major release of this product to support 10/100 connectivity. Power is supplied to the phone either from a 48-volt power connector or from power supplied through pins 7 & 8 over the ethernet connection. The phones come with a standard power adapter similar to those found on most small electronic devices. This power supply adds a second cord to the phone that most users are not accustomed to seeing. Current phones receive power through the phone cable, so the only cable to the desk is the phone cord. This power cord has raised many concerns regarding power outage issues and extra cables hanging off the desk. The phones themselves currently support power provided across the ethernet cable. Cisco has the patent on providing phantom power over the ethernet pins with the power being injected by the switch, but does not currently have a product on the market to support this technology. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (4 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

Other solutions of providing power, such as to a patch panel or 110 punch down box, are not supported by Cisco and have to be implemented with third party equipment. These solutions would allow for back-up power or UPS systems to maintain power to the phones instead of having individual UPS systems at each desk. There is a vendor selling an ‘inline power coupler’ that connects the phone power supply to a RJ-45 ‘coupler’ so that the power cord can be left on the floor. These are quick solutions that take care of immediate concerns regarding power to the phones. Look for future releases from Cisco that take advantage of the patent they hold on providing power over the ethernet connection.

Phone Features The 12SP+ phone supports up to two different lines and four programmable speed-dialing buttons. The standard phone features, such as hold, transfer, ringer-volume control, speaker phone, mute, redial and audio-volume control are all easy push button features. The 30 VIP button phone has an expanded touch pad with up to 12 lines, multiple speed dialing numbers and other programmable push button features. Table 8.1 lists features supported by both phones: Table 6.1 List of Phone Features Feature Function Audio Volume Control Adjusts the volume in the ear piece Call Forward – All Forwards all calls to designated extension Call Forward – Busy Forwards call to new extension if first one is busy Call Forward – No Answer Forwards call to different extension if there is no answer on the first line Call Hold/Release Places call on hold and retrieves it Call Park/Pickup Puts call on hold to be retrieve by entering Call Park extension Call Transfer Transfers call to another extension or phone number Call Waiting Alerts user that second call is arriving


Chapter 6: AVVID

on the line Caller ID Caller’s telephone number displays for identification Time and Date Displays time and date Last Number Redial Redials last number dialed LCD Display (40 Characters) Displays time, date, Caller ID info and other phone setup features Message Light Indicates that a message has been received Message Retrieval Push button to instantly gain access to voice messaging system Multiple Calls per Line Appearance Allows for two simultaneous calls to single line appearance Multiple Line Appearances Phones can be programmed with multiple line appearances per phone NetMeeting Connections from Push Button NetMeeting sessions can be initiated with a single push of a button. Privacy Only one user can be active on a line, no one can access or break into the call Ringer Pitch Adjust Adjusts the pitch of the ringer Ringer Volume Adjust Adjusts the volume of the ringer Shared extension on multiple phones Multiple phones can have the same extension, first one to answer gains control of the call Speakerphone Allows for multiple people to join in on a call Speed Dial Frequently called numbers can be stored as push buttons on the phone

Cisco Call Manager The Cisco Call Manager is a client/server application that resides on a Windows NT server, and performs all of the tasks and processes associated with a traditional PBX. Call Manager processes all calls, controls all Cisco devices and system configurations, and routes calls to proper destinations. Call Manager is the Cisco IP PBX. The system is administered from this easy to use Call Manager interface


Chapter 6: AVVID

(Figure 6.2). The fact that the administrator is a web-based application enables the system to be remotely managed or configured from anywhere there is IP connectivity. Call Manager stores all system and phone information in Microsoft Access databases that can only be administered from this application.

Figure 6.2 Cisco Call Manager Administration browser interface. Call Manager supports the two most common browsers, Microsoft Internet Explorer (4.01 and later) and Netscape (4.0.4 and later). The software should be loaded onto a server class Pentium box loaded with NT 4.0 running; Service Pack 4. IIS 4.0 (Internet Information Server) also needs to be loaded to support the hosting of this web application.

Call Manager Features The Call Manager system is highly scalable, and is able to support up to 5000 phones on a single Call Manager server. Call Manager is H.323 compliant so it


Chapter 6: AVVID

integrates with H.323 compliant gateways or applications like Microsoft’s Netmeeting. Cisco has also integrated H.323 protocol standards starting in routers running 11.3(T) IOS. These routers can now be used as H.323 gateways. Call Manager not only provides the configuration support for all of the features listed in Table 1, but has many system wide processes that are feature rich. Table 6.2 lists all of the Call Manager system features: Table 6.2 List of Call Manager Features Feature Function Automatic Bandwidth Selection Provides bandwidth negotiation between IP phones based on configuration and geographic region Automatic Phone Installation Automatically initializes and configures phone when added to network Automatic Phone Moves Automatically reinitializes phones if they are moved Call Detail Reporting (CDR) Provides record of incoming and outgoing calls DHCP Services Phone initializes DHCP services for automatic registration Dial/Route Plan Dial plan can be customized to meet business requirements Direct Inward Dialing (DID) Call can be delivered directly to a phone without interrupting a receptionist Direct Outward Dialing (DOD) Call backs can be made directly to PSTN from phone Event Logging and Reports Call Manager events are recorded within NT event log Event Viewer Interface NT application that displays system events External SMDI Interface Allows for external Voice Mail system to be integrated with Call Manager IP Precedence Bit IP precedence bit is set to give voice packets priority over normal data packets Number Portability The phone number is retained when a phone is moved file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (8 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

Performance Monitor Interface NT application that monitors system conditions Redundancy Additional Call Manager server can be added for back-up support Remote Process Control Provides remote administration access using a web browser Virtual Phone Support Supports the use of Virtual Phone Web Administration Call Manager system is administered via a web browser Web “Directory Services” Online phonebook integrated into Call Manager Web documentation Online help documentation integrated into Call Manager The dial plan administration is a very important component of the Call Manager system. Not only does it determine and allow calls to take place, but it can also block particular calls, for example: long distance calls, ‘976’ numbers, or international calls. This feature allows the phone system to be managed according to business requirements. Your business can now manage costs and enforce calling policies. Call Detail Reports (CDR) are created and maintained by Call Manager. Whenever an AVVID device places a call, either to another IP phone or gateway, an entry is logged in the CDR. Once the call is completed the CDR is updated with the time that the call was completed. This provides a means of charging back network costs to different departments, monitoring external calls, and managing system performance.

Access Devices The IP phones must be able to communicate with the traditional switch-based PSTN network to make off-net calls to non AVVID phones. The AVVID system has three different devices that take Voice over IP data packets and convert them back to analog signals to use the PSTN (Figure 6.3). These devices allow for seamless integration between the AVVID system and traditional phone systems already installed.


Chapter 6: AVVID

Figure 6.3 AVVID Components. These devices use RJ-45 ethernet interfaces to connect with the LAN, allowing for communication with Call Manager and for connection with IP phones. These devices do not have LCD displays, so all configurations and device information are managed from Call Manager. Configurations are stored in nonvolatile memory, so if the system is power cycled, the access device will receive a new configuration from Call Manager. Cisco access devices are H.323 compliant when used with Call Manager. This allows interoperability with other H.323 compliant devices. Ports also automatically detect G.711 and G.723 compression standards and adapt accordingly, all seamless to the caller.

Analog Gateway The analog access device called the Analogy Trunk Gateway (AT) (Figure 6.4) is an FXO device used to connect AVVID phones to the PSTN (Figure 6.5). The Analog Gateway comes in three different configurations 2, 4, and 8 ports, all with RJ-11 analog interfaces. The different port configurations support normal 1FB analog phone lines to provide dial tone from the PSTN. The Analog Gateway is typically used in small offices where a receptionist can answer all calls and then transfer them to the appropriate extension. The AVVID system can be integrated with current PBX systems by using the AT. An analog port off of a PBX or Key-System plugs into the Analog Gateway (Figure 8.4) to provide dial tone from the PBX. The Dial Plan within Call Manager can be configured to direct a call to the AT when a user dials ‘9’ then the number. The AT then passes on the Dual Tone Multi Frequency (DTMF) tones to the PBX, where it dials out to the PSTN. In large companies it is very difficult to get the support to move away from PBX to the IP phone system. This device not only allows direct connections to the PSTN, but also allows for the interoperability between PBX and IP telephony. There is going to be a strong need in the next few years to support PBX phone systems along with the AVVID. This product supports the interoperability of two very different technologies, allowing a slow migration away from traditional PBX systems to IP.


Chapter 6: AVVID

Figure 6.4 Four-Port Analog Trunk Gateway. The ability to transfer or initiate calls from PBX to AVVID phones can only be achieved with a one-to-one mapping within Call Manager. The PBX has to map one analog port to one analog port on the Analog Gateway. This allows calls to be made from legacy PBX phones to AVVID phones, but it consumes a lot of analog gateway ports in the process. It becomes cost prohibitive to add large numbers of analog ports to the PBX, so it can be a scaling issue if the two systems need to co-exist for long periods with a high number of ports. Warning Analog Trunk Gateway does not support DID functionality. Voice Mail systems are very expensive and usually integrate with PBX systems. The AVVID is able to access voice mail through the PBX because the Analogy Gateway passes on DTMF tones to the messaging system. Octel and similar systems use the DTMF tones to navigate through the prompts and retrieve messages. The Analog Gateway is H.323 compliant when used with Call Manager. The file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (11 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

gateway communicates with Call Manager using the “skinny” protocol, which then converts to H.323 to be used with other H.323 devices. One H.323 device that works very well with the Cisco gateways is the Symbol line of cordless IP phones. The Symbol phone uses the Cisco Analog Gateway and Call Manager to connect to the PSTN.

Analog Station The Access Analog Station (AS), also comes in the same 2, 4, and 8 port configurations. The Analog Station is an FXS device; it allows analog devices to be plugged into the network. FAX machines and analog phones can be integrated into the AVVID system to take advantage of the full extent of the IP network and toll-bypass. Tip Maximum FAX transmission speed is 4800 Kbps. Voice Messaging systems such as Octel can be integrated with the AVVID system via the AS gateway. Voice Response Units (VRU) or Interactive Voice Response (IVR) units can also be integrated with AVVID using the Analog Station.

Digital Gateway The DT-24+ is the name of the Cisco Digital Access Gateway. The Digital Gateway allows for a full T1 PRI to connect to the AVVID system (Figure 6.5). This support is very necessary for a company with a large volume of calls to the PSTN. The DT-24+ would allow for 24 simultaneous calls to be made to the PSTN. The DT-24+ is a NIC type card with DSP processors on board that can be inserted into the NIC slot on the Call Manager server. Figure 6.5 AVVID components connected to PSTN. When integrating with a current PBX, the DT-24+ can be the trunk between the AVVID and the PBX for dial tone. This also allows better interoperability between the two systems because you no longer need a one-to-one relationship on the gateway to call from the PBX to the IP phones. Tip Direct Inward Dialing (DID) capabilities are only supported on the digital gateway. The Analog Gateway does not support DID to the phones. The digital trunk brings DID capability to the phones. Call Manager can be configured so that you can transfer from a PBX phone to any AVVID phone.


Chapter 6: AVVID

This opens the door for a much easier migration and integration schedule so there is no longer a mapping issues between the two systems.

AVVID Equipment Initialization and Registration The AVVID equipment are stateless devices that require Dynamic Host Configuration Protocol (DHCP) services for automatic registration and initialization. The phones can be statically programmed using the keypad if DHCP is unavailable. The initial registration process of all AVVID devices requires that DHCP be running on the LAN to allow for automatic registration and configuration of the phones. As a part of the system requirements, DHCP must be configured to assign the TFTP server, default gateway, DNS Server, and BOOTP information to requesting entities.

Phone Initialization and Configuration When an IP phone is first powered-up and connected to the LAN, it does a DHCP broadcast for an IP addresses. The DHCP server on the network assigns the phone an IP address, DNS server location and the TFTP server address. The phone first requests a configuration file from Call Manager (using DNS), if this fails then the system uses the TFTP address assigned during DHCP. The TFTP server houses all of the configuration files for the individual phones; if a phone is new, a default configuration is transferred to it. The phone will complete the initialization process in less than 30 seconds (Figure 6.6). If the phone has been configured in the past, then the phone will regain all the characteristics that were pre-configured, for example: speed dials, line extensions, user identity on the LCD display, and the correct time zone and compression types. If the phone is new, the next available extension from a pool will automatically be assigned and the default keypad template is installed. The phone has dial tone even before you have to make a single configuration change on Call Manager. After the phone and user have been paired up, Call Manager can be updated to reflect the user’s personal preferences. Figure 6.6 Initialization and Configuration of IP Phone. This registration process allows for a phone to be easily moved from one location to another. The phone has NVRAM to store IP address information, so when the phone is moved, it can retain IP address and TFTP addresses. If the file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (13 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

phone is moved to a different subnet the phone would request a new IP address from the DHCP server and obtain a new set of DHCP settings. Moving a phone costs next to nothing when compared to a similar move on a traditional PBX. The cost for a traditional PBX phone line to be re-punched down and the switch configured usually runs between $75 and $250. The savings associated with adds, moves and changes over the lifetime of the phone can be substantial. These savings need to be factored into the decision process when considering the IP phone for your business. The money saved in a year can pay for a large portion of the new system. If DHCP is unavailable, the phones can be configured on the phone keypad to assign all the information that DHCP would have automatically provided. This is not an intuitive process so the fear that an end user might change a setting is unlikely. Phones on a LAN without DHCP need to have an IP address, mask, TFTP server address, DNS server address, and default gateway addresses entered into the phones. The AVVID phone can now initialize and load a phone configuration from the TFTP server. The access gateways go through the same registration and initialization process as the phones do to establish connectivity to Call Manager. They obtain an IP address from DHCP and request a configuration file from the TFTP server. The configuration file is transferred to the access gateway via TFTP and loaded into NVRAM. Tip The Analogy Gateway, Station and Digital Gateway do not have a means of being configured without DHCP services on the LAN. Unlike the phones, the access devices do not have keypads or LCD displays. The gateways rely solely on DHCP services for the complete set of IP addresses to direct the device to the configuration files and default gateway.

How AVVID Works All of the Cisco devices are connected together over a LAN and take direction from Call Manager. The phone and Call Manager use a “skinny” station protocol to communicate and negotiate states between them. The “skinny” protocol is a low bandwidth TCP protocol used by the phones to communicate states and events. All events that occur on the phone are reported back to Call Manager. Call Manager is the equivalent to the Central Processor on a PBX in terms of its function and call routing.


Chapter 6: AVVID

Placing an IP to IP Phone Call When one AVVID phone wants to call another phone, all of the call setup steps are handled and dictated by Call Manager. When an end user picks up the handset to place a call, the phone signals to Call Manager that it is “off hook”. Call Manager sends back the command to generate dial tone for the user to hear. The user now hears dial tone and can dial the desired extension. This communication between the phone and Call Manger takes place very fast, by the time you lift the receiver to your ear, the dial tone is already playing. Once the desired extension is entered, Call Manager notifies the receiving end that a call wants to connect with it. If Call Manager sees that the extension is busy, then the call can be routed to another extension based on user preference that was configured for that extension. Call Manager passes the IP address of the incoming call to the phone; the two phones have a conversation setting up compression rates and other setup parameters. The call is established directly between the two phones, and Call Manager drops out of the communication and call setup process, other than logging an entry in the Call Detail Report (CDR) (Figure 6.7). The two phones now communicate totally independent of Call Manager. The phones use the “skinny” protocol to communicate with Call Manager and to set up the communication parameters between them. Once the phones have established the call setup parameters they communicate directly using, Real Time Protocol (RTP). RTP is used because it is a connectionless oriented and “best effort’ protocol, so a retransmitted packet is worse than a dropped packet. If a data packet is lost in transmission, it is better that the packet be dropped instead of being retransmitted and inserted into a later point in the conversation. RTP provides a good transmission mechanism to support voice over data delivery. Figure 6.7 How AVVID Works – Establish call between IP phones. Once the conversation is completed between the two phones, messages are sent to Call Manager stating that they are “on hook” and can receive future calls. Call Manager then completes the CDR entry and stores it away. Placing an IP to PSTN Call When an IP phone goes “off hook” Call Manager sends the command to play the dial tone locally generated by the Digital Signal Processor.


Chapter 6: AVVID

The user then enters a ‘9’ to reach an outside line (‘9’ is the common digit dialed to reach an outside line, this is configurable based on the dial plan) followed by the external phone number. A secondary dial tone is generated after ‘9’ is pressed so the user knows an outside line has been established. TIP Secondary dial tone is an option and can be disabled. Call Manager then notifies the Gateway that a call is coming. The IP address of the phone is passed to the Gateway so that connectivity can be set up between the two devices. Once the connection is established, the Gateway forwards the digits onto the PSTN for the call to be completed. Again Call Manager has dropped out of the set up process and logs CDR entry. The conversation is completed when the IP phone goes back “on hook”, and Call Manager completes the CDR log. The IP phone and Gateway are again ready to place or receive calls. Placing an IP to IP Call over the Wide Area Network If your network has some remote locations across a WAN, then the phones can be used for long distance savings. Phone conversations across the WAN are set up and established in the same way as if they are on a LAN. The only likely difference between these calls is that the conversation will be compressed using G.723 to conserve bandwidth over the WAN. The quality of the G.723 connection is almost indistinguishable from the quality of a phone call placed over the PSTN network. The compression allows for small remote offices with only 56 K of bandwidth to place multiple calls and use the network for applications all on one link. The benefits of linking remote offices and saving costs with toll by-pass can also be increased by adding a way to jump off the network at the remote side to the dial plan. If you design an Analog Gateway on the remote end, a user at a headquarters location can ride the data network across the network and exit the Analog Gateway to the remote PSTN. The dial plan must be configured to direct the call to the appropriate Gateway so the connection can be established with the IP phone and remote PSTN network. This not only allows for toll savings between remote offices and headquarters, but also for any other business calls made in the area surrounding each location.

Plug-in Applications Call Manager software comes with many “Plug-In Applications” to enhance file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (16 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

and demonstrate the new IP based PBX system. Many of these “Plug-Ins” can be accessed from the Call Manager Administration page, otherwise they can be loaded during installation. Many of the applications are unsupported demonstrations used to introduce the user to the technology and what to expect once the product matures. These applications are the tip of the iceberg in terms of what can be developed for the Cisco IP phone system. Cisco has created an open standard so the applications can easily be developed and integrated into the Call Manager system. Directory Services The Call Manager web interface has an added application that helps users place calls within the organization. This online phonebook is tied to the Call Manager database to share user information. The application is called Directory Services and is an easy to use web interface that helps users search for phone numbers of fellow co-workers.


Chapter 6: AVVID

Figure 6.8 Directory Service. Directory Services lists all of the users that are entered into the Call Manager system in alphabetical order. The “User” screen from Call Manager collects information about a user like name, e-mail address, department and assigned extension. The directory easily displays this information to be used as a directory service or phonebook by all employees (Figure 6.8). Companies are spending a lot of money webifying employee information to make it available to the entire company. This information is already collected about each user in order to assign them a phone, why not use this information as a tool. Directory Services has eliminated the need to re-enter user information into another ‘employee phone list’ application or spreadsheet. Directory Services has the ability to search by name, department or e-mail address. The phones are associated to a user’s PC within the configuration, so this link can dial the phone from your desktop browser by clicking an extension. There is also a “enter a number to dial” box, which connects your phone to the desired extension. Virtual Phone Virtual Phone is a PC based version of the AVVID IP phone that is integrated into the Call Manager system (Figure 6.9). Virtual Phone enables your PC to become a phone by installing the same phone client that is embedded in the hardware-based phones. Warning Virtual Phone is currently unsupported by Cisco. Virtual Phone can be loaded onto Windows 95/98/NT platforms. The Virtual Phone PC requires a sound card, speakers and microphones to properly use the phones’ functions. The phone is functionally and graphically equivalent to the 30 VIP phone. Virtual Phone only supports G.711 coding, so remote location use is going to be limited by bandwidth constraints. The Virtual Phone software is easily loaded onto a PC or laptop by downloading the image from the Call Manager web interface. Virtual Phone goes through the same initialization and configuration set up steps that the AVVID phones go through. Phones are automatically assigned extensions and default configurations. Through Call Manager user information can be assigned to the Virtual Phone definition within the system. The phones’ characteristics can be personalized just as the hardware-based phones are for speed dial buttons and user display information. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (18 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

Figure 6.9 Virtual Phone. NetMeeting can be associated to Virtual Phone so that by pressing a preconfigured ‘NetMeeting button’, a session is created between you and your calling party. NetMeeting automatically opens on both callers’ PCs so that whiteboard sessions can be interactive and files can be shared. Virtual Phones operate and establish connections with Call Manager just as AVVID phones do. For better quality a handset with built in microphone and earphones is recommended. The PC running Virtual Phone client is busy running other applications and at the same time converting voice to packetized data. The quality of the calls are going to vary depending on how busy the processor is. Unlike Virtual Phones, the AVVID phones have processors that are dedicated to this conversion, so quality is controlled and predictable. Warning The Microsoft stack adds 87ms of delay due to Windows TCP/IP processes. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (19 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

The added delay introduced by the PC is quite long when considering that the one-way delay budget for an IP call should be between 150 and 200ms. Using Virtual Phone within a LAN environment will probably not impact the quality of the conversation. However, when using the PC based phone over a WAN, the added delay could severely impact quality. CiscoValet Cisco offers an integrated voice messaging system along with Call Manager called Cisco Valet. Cisco Valet is a free application that Cisco developed to demonstrate the capabilities of an IP based messaging system integrated with an IP PBX. Cisco Valet has a full set of features that are common to enterprise voice messaging systems. TIP Cisco Valet is currently unsupported by Cisco. Personalized greetings can be created directly on the phones by following the system prompts. The greetings and voice messages are saved as WAV files on the Call Manager server so plenty of storage space is needed to accommodate lengthy messages. The message light illuminates when messages are left, and by pressing the message button you instantly enter the message system to retrieve your messages. The system is easy to use and is integrated into the Call Manager software. Mailboxes are set up within the Call Manager Device Wizard, which steps you through the necessary procedures to set up voice mailboxes. The number of mailboxes are determined, that is the number of simultaneous mailboxes that can be accessed for leaving or retrieving messages. This needs to be determined based on your company’s voice messaging patterns and volume. Each phone has voice mail capabilities as long as a user is assigned to that particular phone. For the system to work properly, the phone and user must be correlated so that passwords and message lights properly match the phones. Users are able to administer their mailbox from the phone by following the message prompts, just as people are accustomed to on traditional messaging systems. The Call Manager administrator also can set up passwords at the time of installation. Users do have the ability to retrieve messages from any phone; it is not limited to the users assigned phone. Tip 1 Cisco Valet only runs G.711, so remote locations that use G.723 compression are unable to access voice mail. file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (20 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

Tip 2 No time stamps are placed on messages. Tip 3 No group messaging available. Cisco Valet also comes with a web browser interface (Figure 6.10) allowing individual users to administer certain changes to their phone. A user can access the Cisco Valet ‘User’ web page, enter extension and password, and have the capability to change phone characteristics. The possible changes are limited to; changing a user’s password, configure speed dial buttons, forwarding calls and printing out the telephone keypad template. These are tasks that are easy to change by the user, but very time consuming for a busy Call Manager administrator. The Valet user interface allows the user greater functionality and flexibility and at the same time frees up administrators from mundane tasks. Voice messages can be accessed from this web interface as another added feature to the messaging system. An individual’s voice mail messages are displayed on the screen along with message length. The messages can be listened to by pressing the play button displayed next to the desired message. The user can now listen to all calls from the web interface without picking up the phone to check messages. This functionality is combining voice and data technologies onto a common web platform. Voice mails can now be retrieved from anywhere around the world.


Chapter 6: AVVID

Figure 6.10 Cisco Valet User Interface. Tip System can be configured so that if a caller reaches a voice mail box and does not wish to leave a message, the caller can dial ‘0’ to reach an operator. Cisco Valet is feature rich and is a great demonstration of applications that can be developed to integrate with the Cisco IP phone system. A number of applications can be developed with this system; the advantage being that all the components are IP based. Cisco has also based the design and architecture of Call Manager on open standards. The integration of applications are easy since there are no proprietary signaling or application designs usually associated in traditional PBX systems. You will start to see more voice messaging systems and other voice enabled applications written for the AVVID system. Messages are stored as WAV files, they can easily be e-mailed or integrated into electronic mail applications. Users now have multiple choices on how to


Chapter 6: AVVID

access voice mail, either from the phone, web interface or from e-mail. A single messaging or communications application is what most users are requesting. There are many ways to communicate in today’s work environment, and the burden to check voice mail, cellular phone messages, pagers and e-mail is becoming quite large. There are almost too many ways of messaging an employee; it is not efficient to try all of these ways. Cisco Valet demonstrates the start of the basis for a unified messaging platform, so that one message can find the employee as they see fit. Systems to send alphanumeric pages or translate voice messages into text can easily be developed and implemented into AVVID products. Cisco acquired Amteva Technologies, Inc in April of 1999, a leader in enabling voice mail, fax and e-mail over IP based networks. Cisco plans to integrate Amteva’s voice messaging product line with Call Manager sometime in the first half of 2000. This new product line will bring the concept of unified messaging to the AVVID system. Manual Attendant Most small business offices and even some big ones have a receptionist that answers calls. The receptionist usually has a huge phone with a push button for every extension. To overcome the limitation of creating these huge keypads, IP enables you to build this transfer function into a GUI application. Manual Attendant is an application that a receptionist uses to answer calls and transfer them to the desired extension. This application is best used when an office is not served by a digital connection and utilizing DID lines. Manual Attendant has many capabilities as listed in Table 6.3. Table 6.3 Manual Attendant Features Feature Function Call Answering Calls can be answered by one central attendant Call Holding Calls can be placed on hold from GUI application Call Making Calls can be placed from the Attendant application Call Retrieving Calls can be retrieved by using the GUI interface Call Routing Attendant routes calls to appropriate


Chapter 6: AVVID

extensions Call Transferring Calls can be transferred using the Attendant software Disconnecting Calls Calls can be disconnected by Attendant Multi-Line Visibility Attendant can view status of all lines The receptionist can transfer calls using this Manual Attendant software package. The screen displays the list of all users and shows if a user is on the phone or not. When a call comes into the receptionist, the inbound call can be dragged and dropped onto the appropriate extension, thus transferring the call. If the user is on the phone, the receptionist can put the call into voice mail by dragging to the voice mail bin. This is a great solution and demonstration of integrating GUI applications into Call Manager. This does solve the problem of manufacturing phones with dozens of extensions, but most receptionists are accustomed to using the multiline phones for this function. This application creates some problems, using a GUI interface is not preferred by most receptionists. Training and adjustment periods are necessary when moving away from the old push button systems to Manual Attendant. Conference Bridge AVVID supports two different types of conference calls, Ad-Hoc and MeetMe. The Conference Bridge application must be loaded and running on the Call Manager server or another NT server in the network. The Bridge software enables all the features that are supported by both of these conference types. All of the data streams representing voice calls are summed at the Conference Bridge to create a bridged call. Ad-Hoc conferences are initiated by a caller, conferencing other extensions or phone numbers in on the line. This is the type of conference call that most people use on today’s phone system. The process works exactly the same as on traditional PBXs; when talking to someone and you wish to bring someone else in to the conversation, you put the caller on hold and dial the new number. When the new caller connects, you hit the Conference button and the three calls are merged into one. The maximum number of calls that can be initiated with Ad-Hoc conferences is 9. Meet-Me conference call is the equivalent to a conference bridge that is usually associated with a conference calling service. A preconfigured Meet-Me bridge


Chapter 6: AVVID

number is set up and callers join the call as they please. The maximum number of callers is limited to 99, and everyone can interject as long as no more than 4 callers are speaking at the same time. Each DSP in each phone is responsible for mixing, so when multiple people are speaking at the same time the DSP can mix the first 4 people to start speaking. However, as soon as one or more of these callers backs off other people can interject. This is a very common phenomenon in conferencing systems. You may have heard this phenomenon during a traditional conference call when people are arguing on a call and you try and interject and no one hears you. This could be a huge limitation based on your company’s conference calling requirements. If your business usually has calls where executives are passing on information to remote locations, then this should not be a problem since only one caller is doing most of the talking. If your company has very interactive conference calls then only the last four callers can interject while everyone else listens in. Media Termination Point Supplementary Services are phone features such as transfer, park, forward, conference calls, and hold which are not supported with H.323 gateways and applications. To transfer a call or conference two calls together, there must be signaling to help establish these extra connections. H.323 does not support these types of services, so a Media Termination Point is used to connect H.323 and IP phone calls (Figure 6.11). This Media Termination Point (MTP) is an application that can be loaded on to Call Manager or loaded on a separate NT server. The MTP is controlled and administered from the Call Manager Administrator interface. The Media Termination Point is only needed when using a router or other H.323 gateway in conjunction with the IP phones. TIP The MTP is not needed when using the DT-24+ or the Analog Gateways. To give a call these supplementary services, the MTP acts as a concentration point to bridge H.323 and IP phone calls. Call Manager is still involved in the call setup communication between the MTP and IP phone and between the H.323 gateway and MTP. The MTP becomes the middle device, or concentrator to complete the call. The conversation between the two devices now must stream through the MTP instead of a normal RTP session directly file:///H:/edonkey/docs/programming/SYNGRESS_Co...o_Voice_OverIP.JanezSlovenec/70_voip_web_06.htm (25 of 31) [13/12/02 18:19:25]

Chapter 6: AVVID

between devices. This introduces a bottleneck if the number of calls becomes large. The MTP can support up to a maximum of 48 calls concurrently. Figure 6.11 Media Termination Point. The MTP can only accept and set up G.711 connections, so lots of bandwidth is consumed with each stream to the MTP. When trunking two Call Managers so that calling plans can be shared, H.323 is used for inter Call Manager communication. Since H.323 does not support supplementary services, the MTP is needed to add this functionality for calls placed between Call Manager regions. Supplementary Services are important features associated with a phone system. The Media Termination Point enables H.323 connections to integrate with the standard AVVID functionality. SUMI Selsius Unified Messaging Interface (SUMI) is used to connect to a Small Message Desktop Interface (SMDI) complaint voice mail system (Figure 6.12). When connecting AVVID to an external voice mail system, such as Octel, signaling is needed between the two systems for the message light to work properly on the phones. Without this connection the message light will not light when a message is left.

Figure 6.12 SUMI Connectivity. Two connections are required to connect AVVID to the external voice mail system. The voice mail system uses POTS line connections to the Analog Station. For the SMDI connection to work properly an RS-232 serial connection links the Call Manager server to the voice mail system. This SUMI connection allows the phones to be integrated with third party messaging systems so that the message light features are not lost. TAPI Interface The AVVID system has been built on the foundation of open standards-based IP telephony. Cisco does not want to limit development of applications for the AVVID system by building the system on proprietary coding standards. AVVID’s strategic direction is to continue to have an open architecture so that


Chapter 6: AVVID

third party companies can develop future applications for IP telephony with the AVVID. Telephony Application Programming Interface (TAPI) will enable third party development of voice applications. A number of applications focusing on voice mail, call center implementations, billing, accounting and paging will be created to fill a void left open because the product is so new. Microsoft’s Telephony API standard is the key to future application integration with the Cisco Call Manager. Web Help Call Manager comes with online help that is very user friendly and full of data designed to answer a multitude of questions. Help is accessed from the Call Manager Administrator interface. The index of topics are organized on the left side of the screen, with the topics selected displayed on the right (Figure 6.13). Topics can be selected by clicking an index item. Topics are displayed along with further links to similar topics or “next steps” to configure the system. The online help can make a first time user very comfortable with the system in a very short period of time. Help is a very strong feature to the Call Manager system.


Chapter 6: AVVID

Figure 6.13 Web Help.

The Future is near… With the introduction of the IP phones, new innovations are going to be developed to take advantage of the endless possibilities of having Voice over IP. Businesses will find new ways to integrate this technology into the work place, to save costs and exploit the technology. City and State governments are cracking down more and more on traffic and pollution regulations forcing companies to implement employee telecommuting programs. Most companies drop data connections to support users that work from home; the cost of installing a second phone line can now be eliminated. These IP phones will allow employees to work from home and still keep their same phone extensions, have access to voice mail and all the phone features employees are accustomed to. This will enable employees to be more


Chapter 6: AVVID

productive and reachable when away from the office. Businesses are spending more and more money on desk and cube space to support large call centers. A large call center can now we moved away from a centralized location. The employees of call centers can work from home and still have access to the network and fellow employees. The costs associated with running a call center can be reduced by dropping data connections to the employees home and giving them an IP phone. Space is saved at the call center, while also reducing traffic and city pollution. Along with saving costs on office space, new customer service tools can be implemented using Web telephony. The same code that allows Virtual Phone to run on a PC, can be integrated into a company’s web page. A client can now push a button on the web page to instantly talk with a live customer service rep. The rep can be in a call center or working from home using a Cisco IP phone. This push button IP telephony can be used for a number of business needs. With e-commerce becoming so important to a company’s business, any improvement with client interaction can translate into millions of saved or new dollars. Why not add video to the web conversations and take web telephony to the next level? A client not only talks to, but sees the customer service rep. This can add great value to any customer service department. The IP phone can now open the minds of management to create more virtual roles, not only for the sake of reducing traffic and pollution but also for employee moral. Those individuals that have long commutes or prefer the privacy and quietness of working from home can now have that luxury. Fellow co-workers will not be able to tell if you are on the floor above them or working from home since your phone rings to the same extension. A user will also have all the phone features needed to conduct business as normal. Parents that want to stay home and spend more time with families will be able to work more flexible hours by having an extension of the office in the next room. The new possibilities are just starting to be realized.

Summary If you are interested in finding out more about the AVVID phones, look on Cisco’s web site for details. Cisco is introducing these products to the market very slowly and with intense support from Cisco’s Value Added Resellers. Cisco does not want to be in the phone maintenance business, and it realizes


Chapter 6: AVVID

that these products will not be successful without the full support of channel partners. Cisco created an Early Adopter Program to enlist the help of a few selected partners to introduce this product with the correct knowledge and support. Inquire within your local Cisco office about the companies that are participating in the Early Adopter program; there are approximately 55 of them around the country. These selected companies are the only resellers authorized to sell, implement and support the AVVID products. Cisco is relying on its partners to help take on the responsibility of making these products successful with all their clients. Cisco has also created other partnership programs to support the roll out of voice applications and voice implementation knowledge. Cisco Voice Application Partners are companies that have agreed to develop software applications to integrate with the AVVID. Look on the web page for Voice Application Partners, under Partners & Resellers off of the main page. The complete list of the companies involved, along with the application that is being developed can be found under Partners & Resellers. If you were worried that the system lacks application support such as all the third partner programs associated with PBX systems today, please consult this web page to investigate what companies are creating the newest applications for the system. The application you are looking for could be right around the corner. The second voice program focuses on the partners that have the knowledge to help your business make the right decisions when implementing a voice over data solution. Companies that have passed Cisco’s voice qualifications based on sells and technical expertise are members of the Voice Access Specialization Program. Look for voice partners, under the Partners & Resellers section on Cisco’s web page. These companies will be able to assist with your network voice strategy, designs and implementation to meet your business requirements for voice traffic. This appendix has a high level overview of the Cisco Communications Network product line. This is a new line of products that is creating a lot of excitement now that Voice over IP can be extended all the way to the desktop. Many new business initiatives will spawn from this new advancement in technology. Business leaders will be able to take advantage of voice riding the data network. Voice doesn’t look any different than data to devices on the network. This enables applications and devices to be created to take advantage


Chapter 6: AVVID

of this single infrastructure and single data packaging. Cisco is committed to enhancing the Cisco Communication Network devices and software to be world class. The AVVID devices will equal and surpass the reliability and functionality of legacy PBXs found in the majority of businesses today.


Appendix A: IPv6 Addressing


Appendix A IPv6 Addressing Introduction IPv6 Addressing Basics IPv6 Addressing Scheme Characteristics Version Traffic Class Flow Label Payload Length Next Header Hop by Hop Options Header Destination Options Header I Fragment Header Authentication Header Encrypted Security Payload Header Destination Options Header II Hop Limit Source Address Destination Address More Bits! A More Flexible Hierarchical Organization of Addresses FP: Format Prefix TLA ID RES NLA ID SLA ID Interface ID Minimizing the Size of Routing Tables Global Addresses for the Internet and Local Addresses for Intranet IPv6 Benefits Increased IP Address Size Increased Addressing Hierarchy Support Simplified Host Addressing

file:///H:/edonkey/docs/programming/SYNGRESS_Co..._Voice_OverIP.JanezSlovenec/70_voip_web_apA.htm (1 of 41) [13/12/02 18:19:33]


Simpler Autoconfiguration of Addresses Improved Scalability of Multicast Routing The Anycast Address The Need for Further Development The Multihoming Problem The 6Bone Summary FAQ

Introduction First, in order to understand how IP version 6 (IPv6) can solve some of the current and future problems encountered with IP version 4 (IPv4), we must understand the motivation for its inception. This chapter will give a short introduction to the history and development of the IPv6 protocol, through its current accepted form. Second, we will look at some of the key aspects of IPv6 that separate the protocol from IPv4, and look into the benefits that we can gain by utilizing IPv6 and its addressing schemas to build a more scalable network. From there, we can begin to build real-world examples of how this addressing can be deployed in Internet-connected networks to come. Finally, we will look into some of IPv6’s outstanding issues IPand its addressing schemes, and some of the proposed solutions to cope with these yet unsolved issues. Also in this section, we will give a brief introduction to the IPv6 test network, the 6Bone.

IPv6 Addressing Basics By the early 1990s, it was clear that the Internet was going to take off. The average person was becoming aware of its existence, and the killer-apps of today (web browsers) were coming into their own. This dramatic increase in usage of the Internet, which stemmed from outside the research community, was clearly not going to go away. Address space delegations increased at an alarming rate, and it was clear that the Internet Protocol version 4 had a foreseeable upper limit in terms of the number of entities it could connect to the everincreasing worldwide Internet. The Internet Engineering Task Force (IETF), the standards group from which a large portion of Internet technologies emerge, was beginning to see this as an issue that needed to be tackled earlier rather than later. At present, for example, regional numbering authorities (such as ARIN, RIPE, APNIC, etc.) are delegating numbers from within the 216/8 network block. In 1996, by contrast, ARIN was only delegating in the 208/8 range. This would mean that just over 150 million hosts were added to the Internet in this three-year span (if delegations and address assignments were made efficiently). We calculate this by raising 2 to the power of 24 (for each /8) and multiplying by 9. Although the Internet is growing at an alarming rate, and slowly working its way into our day-to-day lives, it is clear that 150 million hosts were not added. There was a major problem with address allocation, even after the efforts of CIDR (Classless Inter-Domain Routing) were file:///H:/edonkey/docs/programming/SYNGRESS_Co..._Voice_OverIP.JanezSlovenec/70_voip_web_apA.htm (2 of 41) [13/12/02 18:19:33]


implemented. Address space was being wasted. Furthermore, we know that 224/8–239/8 is set aside for multicast, and that 240/8–255/8 is reserved. From this, we can see that we are nearing our end (although some of the addresses in the middle, from 64/8–128/8, are just now being delegated, so it will buy a little more time than expected). Now we see that not only was there not enough space to take us far beyond the millennium, but also much of the current delegated address space was being wasted. Additionally, a greater need for enhanced Network-Layer (Layer 3 on the OSI stack) features was beginning to emerge, for example, end-to-end encryption, authentication of packets, source-routing, and Quality of Service. For all of these reasons, it was becoming apparent that a new Internet Protocol, or IP, was going to have to be conceived and adopted for the future of the Internet. This is where the fun began. As people began to see these factors as a reality, many proposals for a new Internet Protocol emerged. The first draft that gained widespread notice was loosely based on the CLNP (Connection-Less Network Protocol), which was based upon another protocol suite, the OSI stack. This stack originally ran on the early Internet, but was quickly replaced by IPv4 when the Internet began to take on size and popularity. The proposal was coined TUBA (TCP/UDP over Bigger Addresses). CLNP does provide for a much larger address range than the current IPv4. Its Network Service Access Point (NSAP) address consisted of 20 octets, and would provide adequate addressing ranges for the Internet’s foreseeable future. However, this proposal was rejected because CLNP lacked some of the value-added features that were already installed into the current IP (quality of service, multicast, etc.), and these were determined to be important to the Internet’s future growth. There was a proposal that attempted to create a packet format compatible with current IP, CLNP, and IPX. Yet another proposal, known as SIPP (Simple IP Plus), simply advocated increasing the current IP addressing format to 64 bits, and fine-tuning some of the feature sets of IPv4, as well as establishing better routing strategies. SIPP turned out to be the closest match for what the Internet needed, after some modifications. The addressing range was changed from 64 to 128 bits, and the name was changed to IP version 6, or IPv6 (IPv5 was already delegated to another protocol). This would be the protocol to solve the Internet scalability problems, and put us into the next millennium (and the foreseeable future). In this appendix, we will learn more about the specifics of IPv6. We will begin by looking at IPv6 addressing schemes, and discuss how they can improve routing stability and efficiency. Then we will look at how the protocol design will aid in numbering and renumbering networks. Finally, we will discuss some of the value-added services that come with IPv6, and how they can benefit both residential users and big businesses on the Internet. We will also go into some details about the 6Bone, the IPv6 proving ground, where deployment and transition strategies are developed and tested.

IPv6 Addressing Scheme Characteristics Now that we have looked at some of the history of IPv6, as well as some of proposals that competed with IPv6 as the new Internet standard, let us take a look at some of the generic



characteristics of IP version 6. A full discussion of IPv6 can be found at www.ietf.org/rfc/rfc2460.txt. Figure A.1 is the IPv6 packet header, taken from this RFC. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | | + + | | + Address

Source +

| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | | + + |



| + Address

Destination +

| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ Figure A.1 IPv6 header format. Let’s look at these fields in a little detail (Appendix B will provide a more intense study of the specifics of the IPv6 protocol).

Version The version field in the IPv6 header is so that Internet mechanisms that know how to route, or even speak routing protocols, will know what type of routing protocol they are about to deal with. Notice the similarities to IPv4. In the case of IPv6, the Version field is a 4-bit integer, with the value of 6 (0110 in binary), to designate this packet as an IP version 6 packet.

Traffic Class The Traffic Class field is an 8-bit field in which some sort of traffic differentiation identifier can be placed. Currently, in the IETF, many working groups are dedicated to coming up with the best way to utilize this type of differentiation mechanism (though they mostly concentrate on IPv4 today). One example of such a group is the DiffServ (Differentiated Services). The members of DiffServ are trying to come up with a way to give more important traffic a higher priority for routing on the Internet today. This field was designed for things such as IP Precedence bits (giving certain values of this field higher priority, and then using differentiated queuing strategies in the router to tell “who goes first”). You can learn more about DiffServ on the Web at www.ietf.org/html.charters/diffserv-charter.html. A number of drafts and RFCs have been written with ideas as to how to implement such a policy. The list of current open drafts (they are only good for six months after writing, at which time they need to be resubmitted, just to keep things current) and RFCs is at the bottom of the aforementioned URL.

Flow Label This is a 20-bit field used when special handling of a packet is needed. Common file:///H:/edonkey/docs/programming/SYNGRESS_Co..._Voice_OverIP.JanezSlovenec/70_voip_web_apA.htm (5 of 41) [13/12/02 18:19:33]


interpretation of this field at the time of this writing is that the field will assign flow labels in order to engineer different traffic patterns in an IPv6 network. The major player in this (though for mostly IPv4 at this time) is the MPLS (Multi-Protocol Label Switching) working group. To see the group’s charter, please see www.ietf.org/html.charters/mpls-charter.html. This group’s main intention is to come up with an efficient way to assign labels to flows, and to come up with an efficient and scalable way to route based on these flows. A flow can be defined as any class of traffic going from one point to anther, whether point-to-point traffic, or a TCP flow from one end-station at a given port to a destination end-station on a given port. The possibility of assigning flows opens up many interesting options for deployment. Perhaps Quality of Service (quite a buzzword in the field today!) can be deployed with scalability this way. Many Internet providers are keeping their eyes wide open as this working group develops, since advanced services that the MPLS working group sees as feasible could lead to ground-breaking new developments in the Internet industry as a whole.

Payload Length This 16-bit integer is used to designate the length of the payload (the data) in the IPv6 packet, in octets. Notice this field is 16 bits long (2 raised to the power 16), which gives us over 64,000 different possibilities, allowing IPv6 to have fairly big packets (over 64,000 octets). To have the ability to make big packets can increase the efficiency of the Internet as a whole. When your packets are bigger, the number of packets needed to send a given amount of data becomes smaller for a given flow. When there are fewer packets to route, then a router has more time to route other packets, or perform other tasks (routing table maintenance, cache aging, etc.). You can see how this can help to increase Internet efficiency altogether. Note that any extension headers (see later) outside of this header are included in the total packet length in this case. Compare this with the IPv4 case (RFC791) where the total length field includes the IPv4 main header.

Next Header This field is designated to tell routers if there are any other headers that need be looked at for the packet to route according to instruction. This differs drastically with the IPv4 case, where there is only one header with a fixed length. The IPv6 main header is fixed length as well (allowing routers to know beforehand how much of the packet they need to read), but has built-in functionality to stack other headers that provide other value-added services, on top of the main header. This field is 8 bits in length, allowing for up to 255 types of next-headers. Currently, only a finite amount of next-headers are developed. Here is a list of the ones currently on the plate: 1. Hop by Hop Options Header 2. Destination Options Header I 3. Routing Header 4. Fragment Header file:///H:/edonkey/docs/programming/SYNGRESS_Co..._Voice_OverIP.JanezSlovenec/70_voip_web_apA.htm (6 of 41) [13/12/02 18:19:33]


5. Authentication Header 6. Encapsulating Security Payload Header 7. Destination Options Header II The preceding list shows the selection of Next-Header fields that can occur in an IPv6 packet. These headers are listed in order of the appearance they would make in an IPv6 packet utilizing this extra functionality. All of these headers will be discussed in detail in the next chapter, but for now, we can give a brief explanation of each one, and why they are in a particular order. Hop by Hop Options Header This header designates properties that are to be examined by each IPv6 speaking node in the path. Destination Options Header I This header is reserved for options to be performed by the destination concerning handling of the packet. Notice this header is the first of two with the same name. In the case of IPv6 packets, with the Hop by Hop header in use, the destination can be the next hop on the router. This is the motivation for putting the Destination Options header right behind the Hop by Hop header. For a full descrIPtion of this header and its options, read on, and see RFC 2460, the protocol specification. Routing Header The routing header designates a list of intermediate nodes that a packet must traverse prior to arrival at the final packet destination. This is analogous to the functionality in IPv4 known as Loose Source Route and Record. This allows you to designate, at the very least, a set of routing devices that a packet must travel through on its way to its destination. For IT Professionals Only How Much of IPv6 to Enable As an Internet backbone engineer, you can see that this may not be something that Service Providers would want to enable on their networks. Think of the ramifications: Suddenly, the way that you design your network can become irrelevant! Customers can now pick and choose their path through the network. This can lead to very difficult build-out strategies. Although this may have benefits for organizations savvy enough to route around congested areas, I believe there are other considerations to look at prior to deploying this on a live Backbone. Fragment Header This header is used by the source to send packets that are bigger than the defined Maximum Transmission Unit, or MTU of the path. Normally, in IPv4, intermediate nodes may fragment packets in order to fit the standards of given media that the packet may traverse. Each media,



be it Ethernet, FDDI, or other, is designed with a specific MTU in mind for optimal performance of the given media. In contrast, IPv6 does not allow for fragmentation of a packet at an intermediate point through the path. Instead, the IPv6 speaking device will undergo MTU Discovery. In this, IPv6 will use ICMPv6 (Internet Control and Message Protocol version 6) to send packets hop-by-hop through the path from source to destination, each time reporting the MTU for that particular link between hops. The lowest value for MTU is used as the maximum size packet that the source will send (again, this can increase routing stability and efficiency, since routing entities now don’t have to spend time and CPU fragmenting packets, but can concentrate on simply routing them). This header is used when the source wants or needs to send a bigger packet than the largest MTU that was discovered. Authentication Header This header is used if the need for end-to-end authentication exists. It contains a method of authentication so that a destination can be sure that a given packet is, in fact, from the source that it says it is. Please note the order of this header in the line. We allow for the preceding headers to come first for good reasons. For instance, if a source and destination are using complex authentication, but we still want to utilize the Hop by Hop header, no authentication information needs to be read or tampered with along the path. Think of the extra CPU time if all routers had to authenticate packets prior to routing them! We can still use the Hop by Hop or Destination Options I (the hop by hop destination) without having to check or tamper with the authentication. Encrypted Security Payload Header Now that we have methods to ensure that packets come from the source that they say they do, we need some way to ensure that no one can read the payload of the packet along the way. The Encrypted Security Payload (ESP) header allows for encryption of both the data in the packet, and all headers behind it, in order to ensure security of the data in the packet. Details of this header can be found later in the next chapter, or in the RFC archives. The combination of this header and the Authentication header make up IPSec (IP Security). This is currently being implemented with IPv4, but since it is not inherent in the protocol, the IETF is challenged to make this work in a way that is not severely performance enhancing. This is one of the benefits of IPv6: It is already built into the protocol, so minimal performance hits are required to enable this functionality. Destination Options Header II This is similar to the Destination Options header I, except this header is designated for options destined for the final destination only. Note that the ESP and Authentication headers come prior to this header in order. This will allow secure Options to be passed without worrying about someone learning something valuable about the destination while the packet is in transit across the Internet. So as we can see, the next header field is of vast importance to security and value-added services associated with IPv6. Also of note, Service Providers may not always have their Backbones listen to certain next headers, as they can cause routing inefficiency. Notice the



VPN solutions that can result from the Authentication and ESP headers alone. Does this mean that Internet data will now be secure? At the time of this writing, it definitely looks like a good attempt at data security over the Internet. Ramifications of IPv6 deployment with full functionality could include the collapse of the “Intranet” (“secure” Internet), which uses physically separate backhaul facilities in order to prevent data or machines from getting attacked or stolen by mean Internet users. Hop Limit This is similar in function to the TTL field in IPv4. It specifies the number of Layer 3 (Network Layer) hops that a given packet can traverse before a routing system will discard the packet. Having a limit such as this is of vital importance. If a routing loop occurs on the Internet, as they sometimes do even today, packets have the potential to circle around and around to infinity. If a user gets tired of waiting, and sends more packets, you can see how quickly this can bring certain areas where a loop exists to its knees. To fix this, the TTL field is used in IPv4. This originally was meant as a Time To Live (in seconds) parameter, by which a packet will be discarded if it exists on a network for a specified amount of time. It was quickly determined that this was not the best approach, so the concept of Hop Limit came into being. Every time a router receives a packet, the TTL field is decremented by 1. When a packet is received with a TTL of zero, the packet is discarded. This helps to ensure that packets do not exist forever on the Internet, taking up valuable CPU cycles and bandwidth. In IPv6, the Hop Limit field is 8 bits long, giving a maximum of 255 routed hops between source and destination. Although we would be extremely dissatisfied if we had to traverse even 100 hops from a source to a destination today, this field is given a high available maximum value to ensure that future routing requirements are met. Who knows how many hops your home refrigerator will be from your office? Source Address This is the IPv6 address of the machine that originates the packet. This is discussed in detail later in the section. Destination Address This is the 128-bit IPv6 address of the destination for the packet (note that based on the NextHeader field discussed earlier, this can be the final destination, or an intermediary destination, depending on which next headers are used).

More Bits! Internet Protocol version 6 was developed to rescue the Internet from current problems discussed in the Introduction section of this chapter. First and foremost of these problems is the address scalability problem that the Internet faces today. The current Internet Protocol address field, being only 32 bits in length (see IPv4 Figure A.2), can be shown to have scaling problems given current Internet growth. It is becoming clear that the number of Internetconnected entities will only increase as time passes. Eventually everyone will be connected, and given population expansion alone, we can see scaling problems already (a 32-bit address



field provided for roughly 4.2 billion addresses). When you take into account other devices that either already are, or may be, connected to the Internet in years to come (phones, television, routers, radios, diagnostic equipment, Web servers, refrigerators!), we can see this problem only getting worse. If you then factor in the legacy problems with IP wasting (owning more IP addresses than you have assigned to Internet entities), it is clear that another solution is needed. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ Figure A.2 IPv4 packet header format. IPv6 does a good job at handling this problem. Rather than the 32-bit address field of IPv4, IPv6 was designed with four times as many bits for addressing. With 128 bits for addressing (see IPv6 Figure A.3), we are left with enough address space to accommodate future growth as predicted within the IETF (128 bits is roughly enough for 4.2 E37 (4.2 *10 to the power of 37) Internet connected entities. This is roughly equivalent to having 8.27E+016 unicast Internet addresses for each square millimeter of Earth’s surface! As we can see, this appears file:///H:/edonkey/docs/programming/SYNGRESS_Co..._Voice_OverIP.JanezSlovenec/70_voip_web_apA.htm (10 of 41) [13/12/02 18:19:33]


to scale to future growth for what hopefully will be a long time. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | | + + | | + Address

Source +

| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | | + + | | +

Destination



Address

+

| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ Figure A.3 IPv6 packet header format. Before we dive into the addressing schemes inherent to IPv6, let us first look at the new convention for expressing IPv6 addresses. Contrary to IPv4, which uses dotted decimal notation, with one number per octet of its 32-bit address, IPv6 utilizes hex notation for describing its addresses. Although dotted decimal notation is well suited for the relatively short IPv4 host address, it does not scale well to the 128-bit IPv6 host address (with dotted decimal notation, we would need 16 numbers to designate each host). With hex notation, each digit signifies 4 bits of address space, cutting address length, when written, substantially. Table A.1 summarizes how hex notation differs from dotted decimal notation. Notice that hex notation has 16 values, instead of the classical 10 values of decimal notation. This allows a byte of data to be summarized by two digits. Therefore, an address in IPv6 will look a little different from what you are used to. However, with a little practice, hex notation becomes easy to use. For instance, the IPv4 address 24.172.96.240 can be written in hex (with dots in the same place) as 18.AC.60.F0. For IT Professionals Only This Is the Trick This is something to become proficient at as soon as possible when deploying IPv6. Subnetting, as you have known it, is usually the hardest part to master with Hex notation. Practice, however, will make this easy after continued use. The trick is to forget about trying to translate between dotted decimal and hex. Instead, allow yourself to actually think in hex, and things will become a lot easier much more quickly. Hex notation is useful for condensing large numerical expressions. Each digit expresses 4 bits of the address. The next convention to know about that differs from IPv4 is that addresses are grouped together in groups of 16 bits. For instance, a sample IPv6 address may be 3FFE:2900:B002:CA96:85D1:109D:0002:00AD. The colon (:) is used as a delimiter in IPv6 addresses. Most implementations will support dotted decimal notation as well, to aid in a smooth transition in the networking community (old habits are hard to break, you know), but the agreed upon convention will be hex with colon delimiters. file:///H:/edonkey/docs/programming/SYNGRESS_Co..._Voice_OverIP.JanezSlovenec/70_voip_web_apA.htm (12 of 41) [13/12/02 18:19:33]


Now that we see how IPv6 addresses are formed, we can use a couple additional conventions to aid in IPv6-address hex expressions. The convention carries over from IPv4: All zeroes that are to the left of a given 16-bit expression may be left out. For instance, the IPv6 address 3FFE:2900:C005:001A:0000:0000:0AD0:0001 can be reduced to 3FFE:2900:C005:1A:0:0:AD01:1, which saves substantial time. This is analogous to the writing of the addresss (for example) in IPv4 of 199.000.055.085 as 199.0.55.85. The second convention helps even more. It states that if there is more than one string of 16 binary zeroes in a row, they can be omitted. In place of the zero strings, we simply use the double-colon (::).From the preceding address, we can express this address as 3FFE:2900:C005:1A::AD0:1, which shortens the expression even further. Please note that the double colon can only be used once in an address. Since the length of the zero string is unknown, any IPv6 node interpretting the expression would not know how many 16-bit zero strings to pad the address with, if this shortcut were to be used more than once. For instance, 3ffe:2900:1::1::2 could be 3ffe:2900:1:0:1:0:0:2 or 3ffe:2900:1:0:0:1:0:2. When we look at both of these shortcuts in full use, we can see that addresses can become especially easy to express. For instance, the IPv6 6Bone address 3FFE:2900:0000:0000:0000:0000:0000:0001 can be written as 3FFE:2900::1. This dramatically reduces both the time to write IPv6 addresses, and the thinking associated with making sure that you get all 128 bits into your expression. Now that we have all of these rules down, we can begin to look at the protocol addressing scheme in more detail. Familiarize yourself with Table A.1 prior to moving into the next sections of this book, as hex will be the normal method for expressing IPv6 addresses from here on out. Value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Hex Notation 0 1 2 3 4 5 6 7 8 9 a b c d e f

Decimal Notation 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Binary 00000000 00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000 00001001 00001010 00001011 00001100 00001101 00001110 0000111

Table A.1 Hex to Decimal Translation Cheat Chart file:///H:/edonkey/docs/programming/SYNGRESS_Co..._Voice_OverIP.JanezSlovenec/70_voip_web_apA.htm (13 of 41) [13/12/02 18:19:33]


Now that we have more bits from which to address Internet entities, we need to make sure that we have sufficient means for all of these machines to talk with one another. In other words, we must also incorporate into the new Internet Protocol ways for routing to maintain an efficient state. Just imagine the processing power Internet backbone routers would need to have in order to retain and process against a list of every host in IPv6! At the time of this writing, there are between 62,000 and 65,000 classless routing entries in the Internet defaultfree backbone routing tables. This number is increasing, but at a much slower rate than address allocations (providers are delegating address space that can be aggregated into supernets; this keeps global routing table growth less than that of Internet connected entity growth). We need to ensure that the upper limit of routing entries with IPv6 is still within foreseeable limits of what Backbone routers can hold, and process upon, quickly. In the following sections, we will first look at how IPv6 addressing works, and then look at how this addressing scheme ensures that these concerns are sufficiently addressed.

A More Flexible Hierarchical Organization of Addresses As stated earlier, any protocol that replaces the current IP will need to not only provide for more Internet routable addresses, but it will also have to contain inherent mechanisms by which to ensure a stable and efficient backbone routing system. If we were to adopt an Internet Protocol without addressing this issue, we may solve an address space problem, but getting from one point in the Internet to another will become cumbersome for Backbone routing equIPment and could lead to a less stable Internet on the whole. Many Internet gurus today envision the Internet replacing all prior means of communication, be it phone, television, radio, etc., so the routing stability issue has to be held in high priority for this dream to become reality. In this section we will look at one of the main improvements IPv6 attempts to make over IPv4, and study the effects this can have on Backbone routing tables. Although IPv4 first routed based on classful entries (Class A, B, C blocks), it was apparent that this was not sufficient for wide-scale deployment. Then, the concept for Classless InterDomain Routing was developed. With CIDR, the concept of classes went away, allowing the ability to aggregate smaller networks into supernets, or to break up big blocks into subnets. This increased the efficiency of network addressing, because we could now address a network with the appropriate sized network block, regardless of what class the address fell into. With this new development, IPv4 addresses were now used more efficiently, but there was a side effect on the Backbone routing tables of the Internet. Instead of carrying the first 128 blocks of network space with 128 entries, these networks could now be spread out over large noncontiguous geographic areas. This caused routing-table size to grow at an increased rate. Let us perform a mental exercise to help demonstrate this point. Suppose that Internetconnected Network I has two Internet Providers, A and B. Network I has been delegated a subnet from Provider A from which to address their Internet connected machines, to provide for Internet routability. When this provider runs BGP, he announces this subnet up to both providers. This is where the problems occur. If Provider A decides to announce to its peers only the aggregate of the Address block from which Network I was given a subnet, only



traffic originating on Provider A’s network (and sometimes not even that) would use the connection from Provider A to Network I to get to Network I. Since Provider B receives, and passes on, the subnet that Network I announces, all Internet traffic will use Provider B’s connectivity to Network I for its best path (via the longest match routing rule). We can see that this limits a downstream network’s ability to load-balance between multIPle provider links. The only solution that would allow Network I to control its traffic load on either connection would have to include the external announcement of both the Aggregate and the subnet from Provider A to its peers. For IT Professionals Only BGP Functionality BGP4 (Border Gateway Protocol version 4) will do this automatically, since the originator of the subnet will be the Autonomous System of Network I in this example. The route will be announced to both providers, unless either one has a policy in place to filter this announcement. This is how most Internet Backbones today take care of this problem. This is also why most Tier 1 providers will not allow a customer to use static routing between the Provider and the customer, if that customer is multihomed to multIPle providers, since this would break this model of deaggregation via BGP4. So as we can see, the inception of CIDR provided for more efficient use of Internet Routable addresses, but in turn, it also reduced the efficiency of Internet routing tables. When this example is expanded to the global Internet, we can see that this is a problem. IPv6 makes some good modifications in policy to rid the Internet of both problems. The IPv6 address consists of 128 bits. One thing that IPv6 has over CIDR is a built-in, welldefined set of boundaries from which to define sets of address space to delegate downstream to other people who get Internet connectivity from you. | 3| 13 | 8 | 24 | 16 | 64 bits | +--+-----+---+--------+--------+-------------------------------+ |FP| TLA |RES| NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+-----+---+--------+--------+-------------------------------+ Figure A.4 Globally routable IPv6 addressing architecture. Notice in Figure A.4 that the IPv6 globally routable unicast prefix is divided into six different sections. Let us look at each section in detail. FP: Format Prefix



The Format Prefix for globally routable unicast prefixes will always have the same three bits (in the initial deployment of IPv6). These first three bits will always be set to 001, and are there to designate (to any routing entity on the Internet) that this address is a globally routable unicast address. For each type of IPv6 address that we discuss, the FP will be unique to that type of address, thus making it easier for routing entities to discern packet types, and process them according to the rules that apply to the respective packet type. For instance, multicast packets and unicast packets are routed in very different ways. Unicast packet routing is 1-to-1 (a packet with an IPv6 Globally Routable Unicast destination originates from one host, and is delivered to one host), and multicast packets are are1-to-N (one multicast packet may be delivered to N interested destination hosts), or N-to-N (N sources delivering packets to N destinations), so these packets are handled in vastly different ways on an Internet backbone. The FP serves as a delimiter, so a routing device can make a quick decision as to how to handle the incoming packet, and ensure that it is handled correctly. Note that using the first few bits of an address to designate type of address is more efficient than putting it into the packet, because now we can utilize more of the packet for other valuable features, discussed earlier. TLA ID This is the Top Level Aggregator Identifier, 13 bits used to signify to which Top Level Aggregator the address belongs. A Top Level Aggregator is a Network Provider that sits at the top level of aggregation of Internet traffic. In unicast terms, Top Level Aggregators are sometimes referred to as “Tier-1 Providers.” These are Internet Providers who make up the core of the Internet Backbone. They usually have equal part peering (they don’t pay the other provider to receive the other provider’s routes) relationshIPs with other TLAs (nonpaid connectivity to other TLAs), encompass a large area of the globe with coverage of Internet core routing, and provide the high-speed transport that moves packets from one part of the globe to another. Their Backbones are composed of highly sophisticated, fast-routing devices, and their cores carry full Internet routes. Current examples of Top Level Aggregators include Sprint and WorldCom. In IPv6, providers of this caliber are given blocks of IPv6 Globally Routable Unicast addresses (a TLA assignment), and they, in turn, delegate pieces of this block down to their customers. RES These bits are reserved for now. It has not been determined by the IETF what course of action should be used for these bits. At this stage, it is appropriate for TLAs to subnet their assignment using these 8 bits to increase the amount of Globally Routable Unicast address space that a TLA can use to delegate to their customers, or use on their Backbone. NLA ID These 24 bits depict the Next Level Aggregator Identifier. A Next Level Aggregator can be thought of today as a Tier-2 Network Service Provider or ISP. An NLA can range from a small organization with one TLA connection, to a large, regional Provider with many upstream TLA connections, and complex Backbones. An NLA will receive an NLA ID from



their upstream TLA, and in turn, will break their NLA ID into chunks, which will be delegated to their customers. SLA ID A Site Level Aggregator Identifier describes an entity that has no downstream customers who are network service providers. A SLA could be a small to large business, or a small Service Provider who does not delegate address space to its providers (for instance, today’s cablemodem providers could fit into a SLA arrangement). Interface ID The final 64 bits of the globally routable IPv6 unicast address is reserved for the Interface Identifier. In IPv4 terms, this is known as the host id. These 64 bits will be designated to distinguish one host from another on a given network segment. Each Interface ID on a given network segment must be unique. We will see that IPv6 builds in a clever way to ensure this is so.

Aggregation Realized Now that we know how the IPv6 Globally Routable Unicast address format is split up, we can begin to see how aggregation based on this format is possible. Figure A.5 depicts a TLA that has a variety of customers for which they provide transit Internet connectivity. By delegating a subset of their address space (TLA ID) to each customer, depending on that customer’s purpose, they are ensured that all address space that is advertised to them from their downstream customers is a subset of their address space. This brings up a good point regarding the political changes surrounding IPv6. With IPv6, small to regional Network Service Providers as well as end-users will no longer have the ability to obtain address space directly from registries. Instead, Top Level Aggregators will be assigned address blocks, which they will in turn be in charge of managing and delegating down to their downstream connections (NLAs and SLAs). This shift in address management is thought to be much more efficient than the current address management policies of today. If a small to midsize ISP/NSP can no longer get address space from registries, and therefore put a burden on Backbone TLA core providers to carry these routes as transit, then the possibility of aggregation beyond what IPv4 can do today becomes a reality. In the next section, we will look at how this aggregation works, and why it will increase the stability of the Internet as a whole.



Figure A.5 A generic IPv6 Internet.

Minimizing the Size of Routing Tables As we have discovered, IPv6 will allow ample address space for the future of the Internet. With 128 bits of address spacing, there should be adequate addresses for Internet connected entities to grow in number and complexity. With a well-defined format for IPv6 addressing, we can see that addressing becomes more organized than classical IPv4. From this, we will now look at how the addressing scheme for IPv6 helps to minimize the number or Internet Core routing entries that need to be carried, thus limiting the scope of future Internet routing complexity. In Figure A.6, we see two TLAs, with various connected customers of both the NLA and SLA variety. Let us look at the routing announcements necessary for this scenario to function with stability and efficiency.

Figure A.6 Generic addressed IPv6 Internet.



In Figure A.6, we have two TLAs (Tier 1 Network Service Providers) and a variety of NLAs and SLAs in various configurations. TLA I is in a bilateral peering arrangement for TLA II, and both exchange routes via BGP (there are changes to BGP that are currently in IETF working groups to support different types of NLRI (Network-Layer Reachability Information), so BGP4 very well may not be the standard BGP by the time IPv6 is deployed; for the purposes of this example, BGP4 will serve adequately). TLA I owns a Top Level Aggregator Block. In this example, we designate TLA I with 3FFE:2900::/24 as its TLA delegation, and TLA II with 3FFE:4200::/24 as its TLA delegation. So we know that TLA I and TLA II must supply each other with these routes at a minimum for routing to operate properly between TLA I and TLA II Backbones. TLA I will subdelegate blocks of address space to its NLA and SLA customers. In this case, let us assign NLA I with 3FFE:2900:1::/48, and NAL II with 3FFE:2900:2::/48. Furthermore, these NLAs must delegate blocks down to their customers out of this block. Let us assume SLA I will be given 3FFE:2900:1:10::/63, SLA II 3FFE:2900:2:20::/63, and SLA III 3FFE:4200:D:E::/63. Starting at the bottom aggregators, SLA I must announce its block 3FFE:2900:1:10::/63 up to NLA I. Because this is a subset of NLA I’s space, NLA A is not required to announce this SLA (from SLA I) up to TLA I. A similar situation exists with NLA II. TLA I only needs to hear the NLA aggregations that it delegated down to these two NLAs, regardless of how that NLA has subdelegated its space. So from this, we can see that at this point, TLA I has to carry only three announcements for nonbackbone space: 3FFE:2900:1::/48 (from NLA I) 3FFE:2900:2::/48 (from NLA II) 3FFE:4200::/24 (from TLA II)



Figure A.7 Routing advertisements along aggregation paths. Even further, we notice that the first two of these announcements are simply subsets of the block assigned to TLA I. Therefore, in the bilateral peering between TLA I and TLA II, we can see that only one route needs to be exchanged between these peers. Although this is a limited example, we can see the routing simplicity that has come to pass as a result of this aggregation. The beauty of this comes from two facts. The first is that no address blocks are portable. Today, a large part of IP space is known as portable. A portable address block is a block that can be taken with you when you leave a certain service provider’s jurisdiction, and go to another provider. This leads to many extraneous announcements in the core of the Internet backbone, as Network Service Providers lose the ability to aggregate announcements properly. For example, if a service provider is given the classless block 71.16.0.0/16, and loses one part of this, say 71.16.241.0/24, from its possession (a customer takes it with them when they leave), we are left with a suboptimal routing scenario. Now, 1. The Service provider has to announce this block one /16 to peers and customers as many different subnets—in this case, eight announcements (71.16.0.0/17, 71.16.128.0/18, 71.16.224.0/19, 71.16.240.0/24, 71.16.242.0/23, 71.16,244.0/22, 71.16.248.0/21). The Service Provider has to update its filters to peers to allow this lost 2. block to be heard via BPG from peers. Normally, this block would be denied, to prevent routing loops (see the note regarding BGP in a previous section of this chapter; the BGP4 provider helps a little due to the originating ASN). Not only is this a management nightmare for Network Service Providers, it is also extremely inefficient for the Internet core. For IT Professionals Only Not All Allocations Are as Depicted It is important to note that not all allocations will go exactly as we cited earlier (in the IPv6 Internet example corresponding to Figures A.6 and A.7). NLAs generally will be given whatever address space is necessary for them to operate. They should be given as much address space as they can deploy efficiently, or delegate down to SLAs. So in reality, a TLA will delegate down a /X prefix, where 24<X

VOIP. Configuring Cisco Voice over IP

Configuring Cisco Voice Over IP

Deploying Cisco Voice over IP Solutions

Deploying Cisco Voice over IP Solutions

Voice over IP Fundamentals

Implementing voice over IP

Voice over IP Security

Voice Over IP

Voice Over IP

Voice over IP Security

Implementing Voice over IP

Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions

IP Telephony - Deploying Voice-over-IP Protocols

Carrier Grade Voice over IP

Voice over IP First-Step

Carrier Grade Voice Over IP

Carrier Grade Voice Over IP

Voice Over IP Crash Course

Cisco - Deploying Large Scale Voice Over IP 406

Cisco - Advanced Voice over IP Tuning and Troubleshooting 409

Cisco Voice over IP (CVOICE) (Authorized Self-Study Guide)

Delivering Voice over Ip Networks

Cisco Voice over IP CVoice) Authorized Self-Study Guide

Voice over Internet Protocol (VoIP) Security

Configuring Cisco AVVID

Voice over IP. Telefonieren über das Internet

Delivering Voice over IP Networks, 2nd Edition

Configuring Cisco AVVID: Architecture for Voice, Video, and Integrated Data

Configuring Cisco AVVID : Architecture for Voice, Video, and Integrated Data

Configuring IPv6 for Cisco IOS

Configuring IPv6 for Cisco IOS

VOIP. Configuring Cisco Voice over IP

Configuring Cisco Voice Over IP

Deploying Cisco Voice over IP Solutions

Deploying Cisco Voice over IP Solutions

Voice over IP Fundamentals

Implementing voice over IP

Voice over IP Security

Voice Over IP

Voice Over IP

Voice over IP Security

Implementing Voice over IP

Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions

IP Telephony - Deploying Voice-over-IP Protocols

Carrier Grade Voice over IP

Voice over IP First-Step

Carrier Grade Voice Over IP

Carrier Grade Voice Over IP

Voice Over IP Crash Course

Cisco - Deploying Large Scale Voice Over IP 406

Cisco - Advanced Voice over IP Tuning and Troubleshooting 409

Cisco Voice over IP (CVOICE) (Authorized Self-Study Guide)

Delivering Voice over Ip Networks

Cisco Voice over IP CVoice) Authorized Self-Study Guide

Voice over Internet Protocol (VoIP) Security

Configuring Cisco AVVID

Voice over IP. Telefonieren über das Internet

Delivering Voice over IP Networks, 2nd Edition

Configuring Cisco AVVID: Architecture for Voice, Video, and Integrated Data

Configuring Cisco AVVID : Architecture for Voice, Video, and Integrated Data

Configuring IPv6 for Cisco IOS

Configuring IPv6 for Cisco IOS

Recommend Documents