Modern networks are converged networks which transport data, voice and video on the same infrastructure. Voice over IP is an important piece of this framework, and for a network technician it’s good to know at least the basics of it. Fortunately we don’t have to own a complete VoIP system to learn, because Cisco’s Packet Tracer has some features to experiment with. In this article, we’ll build a very simple system with just two IP phones, and then develop further with voice VLANs, softphones and other bells and whistles. This topology can be used in a small office to handle voice calls.

Let’s begin with the necessary devices which are available in Packet Tracer (PT). The heart of the VoIP system is a router with an IOS containing the Call Manager Express (CME), which will control the calls, as the name implies. We’ll use a 2811 type router. Another important device is a switch to connect the end devices to. The simplest solution is to use a Catalyst 2960 switch, but in this case we need to use separate power adapters to every phone. In the second version we’ll change this to a 3560 type switch, which provides Power over Ethernet (PoE) – this will eliminate the need of many cables. Last but not least we need two IP phones. PT supports the 7960.

Place the components to the workplace and connect them. The phones have a PC and a Switch slot, now we need to connect them with the Switch. Don’t forget to connect the power adapter to the phones on the Physical tab. The topology will look like this:

The configuration begins on the switch. Although we don’t use separate VLANs for data and voice in this first example, PT needs to define the voice VLAN. Voice VLAN is a VLAN designed for the special requirements of carrying voice data over the network, and it’s always a good practice to use this – but now we use the default VLAN for this purpose.

To define the voice VLAN on all the used ports issue the following commands:

On the router we need to configure the DHCP service, as we want to assign the IP addresses of the phones dynamically. In a small office we can use static addresses as well, but PT doesn’t support static settings on the phones. Of course, before this we need some basic configuration:

One important piece of information here: the last line tells the clients where to find a TFTP server from which they can download their configuration. In this case the TFTP server will be the router itself. At the same time we can see that DHCP has a lot of other options besides the basic ones. At this stage the phones will get their addresses, and if we look at their GUI, the “Configuring CM list” message appears.

The next thing can be the configuration of the call manager on the router. This can be achieved by issuing the telephony-service command (note: on real devices there’s a setup parameter, which will invoke a wizard, but PT doesn’t support this):

Let’s analyze it line by line:

  • the max-ephones command defines the maximal number of Ethernet phones. This number will vary model by model, the software supports maximum of 42 (perhaps because this is the “Answer to The Ultimate Question of Life, the Universe, and Everything” 🙂 Ephone can be a physical device or software (a softphone). It doesn’t hurt to define more than the current number of our devices: if our network grows, it can be easier to manage the new devices.
  • The max-dn sets the quantity of Directory Numbers. These will hold the extension (or line) numbers of the ephones. We can define more DNs than devices, and on a real system we can use dual-line or even octo-line DNs to use such things as call waiting or conference calls. PT supports maximum of 144 DNs on a 2811 router.
  • The ip source-address command specifies the CME device itself, and the port to communicate with it by the SCCP protocol. Skinny Client Control Protocol is a Cisco proprietary signaling protocol. For example, our phones will use this for registration themselves to the CME.
  • Last, but not least, we need to generate configuration files of the phones with the create cnf-files command. This generates the necessary XML files that the phones use for booting.

Next we need to create the ephone configuration. This can be achieved in an easier way, but now we use the static method: after we determine the MAC address of an IP phone, we use this information to assign a specific device to a DN:

On a real device we can see the MAC address on the back of the device, but in PT we need to use the following method: leave the mouse cursor on a phone, and the program will display the important settings in a popup window, including the MAC address. The type command is self-explanatory.

Now we can define the actual DNs for the two phones:

The commands are not so difficult: we need to specify an identifier for each DN and set the number we want to use to dial.

One final step is to bind the phone number (the so called extension) to a button on the device. The button command does that: the first parameter is the button-index; the second is the DN identifier. We bound the first DN to button 1 on the first phone, and the second DN to button 1 on the second phone:

At this stage the phones register themselves, get line numbers and are ready to call each other. Before the test we can issue the show ephone command to see if the registration was successful. Then try to call the second phone with number 112 from the first one: go to the GUI, click on the handset to raise it, enter the numbers and check if the “Ring Out” message appears. On the other phone we can see the visual ringing, and a message about the caller. If we click on the handset, the connection is ready, and we can test it without real voice: just click on the “Do, Re, Mi” icons and watch the other phone’s GUI.

If we don’t want to buy a physical phone, we can still use IP telephony with software phones or softphones for short. If you have ever used Skype, than you know what a softphone is. Cisco also has its own software called Cisco IP Communicator (CIPC) for this purpose, and in PT we can use this.

First, put a PC or laptop into the topology, and connect it to the switch on the Fa0/4 port. Set it up to use DHCP (Desktop tab/IP configuration/DHCP). Then go to the console of the switch and set VLAN 1 as the voice VLAN for the Fa0/4 port (switchport voice vlan 1).

On the router we need to define another DN for the new device and make an ephone entry into the configuration. Before this we need to know the MAC address of the PC: use ipconfig /all command, or find on the Config/Interface/FastEthernet0 window, or use the Inspect tool on the PC’s icon to reveal the Port status summary table – it’s up to you. Then enter the following configuration:

Soon after this “the phone has registered” message should appear and the show ephone command should list the CIPC among the registered devices. When we launch the application from the Desktop of the PC, we should see that it received the extension number 113, and we can call any other phone by entering the numbers and then clicking on the Dial button. One of the advantages of PT is that the whole call progress can be observed in the Simulation mode: it’s a very good tool if we want a bit deeper understanding of what’s going on behind the scenes.

This lab was a simple example using VoIP, but let’s go further. In our second lab we change some things:

  • we’ll use a 3560 type multilayer switch. This will provide Power over Ethernet, so we don’t need to use the power adapters of the phones
  • we want to connect traditional analog phones to our system and use them the same way as VoIP devices
  • we want to automate the registration process of the phones.

We’ve already used two kinds of VoIP devices: real IP phones and softphones, but in a real system there are traditional phone devices also, and of course we want to use them. In the real world we can connect them more than one way. For example we can use a special line card in the router which has FXS ports. FXS is an acronym of Foreign Exchange Station. These ports are capable of directly serving an analog phone or fax device, but PT doesn’t support this method. We need to use an ATA (Analog Telephone Adapter). This is nothing more than a converter for a traditional phone to connect to VoIP system through Ethernet. In the simulator the usage is very simple: the only configurable option on ATA is the IP address of the CME router.

So let’s build the topology which will contain all the voice devices that PT supports:

As can be seen, the PC can have a microphone and a headphone and is more realistic. These two devices are available among the modules of the left of the Physical tab. The ATA can be found in the End devices category, under the name of “VoIP device.” Its neighbor is the analog phone. The connection between them is made by a Phone cable.

The setup begins on the ML_switch. We need to define the voice VLAN on the switchports in the same way as we did in the first lab: using the switchport voice vlan 1 command.

Next will be the CMErouter. After configuring the IP address and the DHCP pool (don’t forget the option 150), we’ll use a new method to help the phones in the registration. The auto-reg-ephone command will turn on automatic registration to an ephone even if it is not in the configuration. With this method we don’t need to precisely define ephone entries, collect MAC addresses and such, but if we want specific devices to get specific line numbers, we need to pay attention to connect them in the proper order. Another necessary command is the auto assign. This will assign a previously defined line number to a phone, more specifically to button 1 on that phone. On a real router it has a type parameter, with it we can define a range of DNs to assign to a specific type of phone. In PT we just need to tell the command the first and the last assignable DN and the rest is automatic.

In this example we’ll use the keepalive command also. This will set the length of time interval of the keepalive messages between the CME router and a phone. If three of the keepalive messages drop out, the router treats the phone as dead. The configurable range is between 10 and 65535 seconds.

The complete configuration is:

The last device to configure is the ATA, but it’s really simple. On the Config tab, in the Settings window we need to set the Server address, which is the address of the CME router. Now every device should get its IP address (except the analog phone, of course) and line number and we can test the calls between them.

PT supports the 2901 and 2911 series routers also, and the 15.x series IOS. If we want to use VoIP features, then we need to enable the technology package named uck9, which stands for Unified Communications with cryptographical functions. (Information about the licensing of the 15.x version can be found at the end of the article). So if we want to use a 2901 or 2911 type router instead of the 2811, then replace and type in the following command:

CME_2911(config)# license boot module c2900 technology-package uck9

We have to accept the agreement then (as the output states) issue the write command in privileged mode to make the configuration take effect on the next reboot. Now restart the router with the reload command, and after it comes up, we’ll find the telephony-service command.

These basic labs were really simple but hopefully useful. In the next article we’ll discuss how to use separate VLANs for data and voice and make calls between different networks.

Useful links:

An overview about CME:

About the CIP software:

About IOS 15 licensing: