There are some articles already in this site covering topics from CCNA Voice. In this one I’ll present a GNS3 lab with a very good SCCP (Skinny Client Configuration Protocol) softphone which makes a lot of experimenting possible as it provides more e-phone devices on one computer. We can configure phone settings, call forwarding, dial peers and other things more easily than with the Cisco IP Communicator, as it allows only one instance per PC. The software is called VTGO-PC Multilab from IPBlue Software. You can download it here: http://www.ipblue.com/products_vtgo_multilab.asp.

VTGO-PC Multilab allows us to use up to five e-phone instances which behave like Cisco IP Communicator or a real 79xx series IP phone. We’ll use the unregistered version which has restrictions on the duration of the calls and session length. In lab environments, those are not too important.

The base topology is as follows:

The phone objects are clouds which connect to Loopback interfaces on the host PC. We can create and manage the loopbacks from GNS3 (under the Tools/Loopback manager menu) and give them a static IP address from the 172.16.1.0/24 network. I changed the symbol to reflect that the connected devices are phones and indicated the addressing scheme also.

Another way to place phone devices is to use the Edit/Symbol manager: select the ip_phone from the Available symbols and move it to the right panel by clicking “>”. Then in the upper right corner change the name to “IP Phone” and the type to “Cloud.”

One more important note is to use an IOS which supports voice. I used 2600 series routers with the Advanced IP Services feature set.

First we need to configure the phone instances with the Setup Phones Wizard:

As can be seen we need to configure the TFTP server’s IP address, the MAC addresses of the phones (I used these ones for easy management) and the phone type.

Before launching the softphones, let’s configure the CME1 router by the telephony-service setup command. The relevant questions and answers of the wizard are as follows:

When this part is complete, we have a common configuration file called XMLDefault.cnf.xml stored in RAM, specifically in the system:/its directory. During the booting process, the softphones will search for this configuration file, but in order to provide it for the softphones, we have to do some work. First, copy this XML file to Flash with the following command:

copy system:/its/XMLDefault.cnf.xml flash:SEP000000000001.cnf.xml

The command asks to erase the Flash: let it do this.

The softphones will search for a configuration file under a special name: the SEP prefix means Selsius Ethernet Phone, followed by the MAC address of the phone. Repeat this for the second and third phone also, but now of course don’t let it erase the Flash, which will now contain three XML files. We then need to export these files by TFTP – issue this command for the first e-phone:

CME1(config)# tftp-server flash:SEP000000000001.cnf.xml

If we want to, we can see the whole phone registration process with the debug ephone register command but this time it’s enough to issue the debug tftp events command just to check if TFTP works well. The last housekeeping procedure is to turn off the Windows firewall as it may block TFTP packets. Now launch Phone Instance 1 and see if it gets registered. It should look like this:

Repeat this for the second and third phone also, and place calls between them. It’s strange to hear the call progress tones together, but never mind!

Now let’s customize our system a bit. First, change the Cisco Unified CME message to CME1 by issuing the system message CME1 command in telephony-service mode. Next change the line number with the phone’s name,: for example, for e-phone 1 it looks like this:

Then make the so-called local directory: to make the caller’s name visible we need to use the name keyword and to change the text of the line buttons on the phone we need to use the label keyword. Configure Phone1 accordingly:

From now on the name “Joe Phone” will appear on the called party’s phone and the label of the uppermost button changes to Joe.

Next, place speed dial numbers to the Line2 and Line3 buttons. We want to set it up so that by pressing Line2 the device should call 555112, by pressing Line3 it calls 555113 immediately, and of course the buttons should reflect the name of the called parties. The configuration now starts under the ephone section, because the line buttons belong to the e-phone device itself:

Let’s continue with configuring call forwarding. This feature is useful when we don’t pick up our phone: the call can be redirected to another phone so it can be successful. The CME and the phone device support several ways to configure this.

The simplest is to use the phone itself: locate and press the CFwdALL button then enter the number of the phone you want to forward the call to. This setting causes all calls to be forwarded unconditionally to that number. Try it by setting call forward to 555-113 on the second phone, and then calling 555-112 from the first phone: the third phone should ring, as the second forwards all calls (or more precisely: CME forwards it). To stop forwarding calls, press the CFwdALL button again.

This behavior is unwanted sometimes, since we may only want to forward calls when our own phone is busy, or when we don’t pick it up after a defined amount of time. In this case we need to configure call forwarding on CME itself. Let’s go into the ephone-dn configuration mode for DN 2 (i.e. 555-112) then look at the available settings:

The “all” parameter is the same we can achieve through the phone as described previously. The “busy” parameter is used when we want to forward our calls if our phone is busy, and “noan” means that the calls are forwarded if we don’t respond to it within a given time.

Let’s try this feature: say we want to configure it so that if we don’t respond to the call within 15 seconds, it’ll be forwarded to the number 555-113. The necessary command is:

CME1(config-ephone-dn)#call-forward noan 555113 timeout 15

Now try to call the second phone from the first, but do not answer it: the call should be forwarded to the third after 15 seconds. As homework, configure the system to use the “busy” feature – you need to have an active call on the second phone, so you need four phones for this scenario. At the end, remove the call forward settings from the configuration.

Call transfer is somewhat similar to call forward. When we have an incoming call and we have to pass this call to another person, we can use this feature.

We have two options with CME: we can talk to the third person first before transferring the call; this method is called consult mode. The other – and simpler – method is called blind transfer. In this case the call will be transferred immediately without consulting first. We’ll use this method in our lab.

The configuration steps are the following:

As we see, the full-blind method is used from the three available options. Anyway, we need to configure our ephones to use a dual-line setup in order to use consult mode. This means that our phones have two numbers in this case. Another thing is the transfer-pattern setting: this can be important if we want to prevent our users to make unwanted calls, because users can transfer calls only to numbers described by the pattern.

Now try to call the second phone from the first, and answer it. Then, press the Trnsfer button on the second phone and enter the number of the third phone: this e-phone should ring and we can continue the call on this device.

The next feature that we can easily try out is intercom. An intercom is a special connection: the called party doesn’t have to answer the call in the regular way, and instead their phone will be connected to the caller’s phone immediately. It can be used if the called party doesn’t want or cannot respond to our call as usual.

We’ll now model the following scenario: the boss wants his junior worker to go out and buy pizza for him. He doesn’t want to wait while the junior picks up the phone, he wants his message to go through immediately (we don’t want such a boss, do we?).

First we need two spare directory numbers to be used for intercom, so we have to modify the max-dn parameter first to the value of 10 in telephony-service mode (the maximum value depends on the router platform). The ephone-dn configuration is as follows (I’ll show the relevant part from the running configuration):

We used DN 4 and 5 for the intercom. The first interesting thing is the number: the character “A” prevents all other parties to dial this number. Of course we can set up a dialable intercom also. The “intercom” keyword is used to define the other party’s number with a label to easily identify him.

On the ephone configuration we need to use the button command to place the intercom DNs to the second button. This way the speed dials automatically go to the next free places. If we configure the intercom DN to button 4, for example, then the speed dials come after it and we don’t want this. So we issue the following in the ephone configuration:

For this to take effect, we need to restart our phones, but this can be done from telephony-service mode also with the restart command. We can restart all the devices or one by one by issuing their MAC address. To test, click on the “Junior” button on the first phone and see the call progress. The connection should be established and we can see the following:

Next feature we can try out is paging. This function is similar to intercom, but in this case there is at least one group of phones which can be reached by a common number. When someone dials this number, all phones in the paging group will activate their speakerphones and receive the call automatically. So, this is like a broadcasting system and can be used to send messages to a group of people at the same time.

The configuration is rather easy. Because paging uses more data streams, it’s a lot more efficient to use multicast addressing than separate unicast streams. In the ephone configuration we just have to set the paging number to the given instance. The whole configuration is:

We use the 239.1.1.100 multicast address, the range recommended for Cisco devices. After restarting the first two e-phones, try to dial 555555 from the third: the phones in the paging group will receive the call. We can declare more paging groups and an e-phone can belong to more than one group.

One last thing to mention: we can use unicast streams instead of multicast if we want. This is of course recommended if we only have a few phones, and in this case we need to indicate it with the paging-dn x unicast command.

Finally, experiment with after-hours settings. This allows the administrators to define time ranges under which the calls are forbidden (for example, in an office after official working hours). We can define some exceptions of course. Some e-phones can be completely free from this restriction, while on others the user has to enter a PIN code to use the system as usual. Let’s do the configuration according to the following:

  • * The after-hours time range is from 6 p.m. to 7 a.m. (or from 18:00 to 7:00 in 24 hour format) on every working day (i.e. from Monday to Friday).
  • * E-phone 1 is completely free from this restriction; it can start calls any time.

The necessary commands are as follows:

The first step is to define the time ranges. Next, we have to tell the system which patterns of numbers to block. Using the “T” keyword, we can match all numbers starting with 555. Finally, we define ephone 1 as a device exempted from the restriction. Now, if time settings are all correct and we are in the given time range, try to place a call from ephone 1 to ephone 2: it should work, but if we try the same from ephone 3, we’ll get a busy signal.

These exercises are just part of the CCNA Voice curriculum, but with this useful softphone program we can do more difficult lab scenarios in GNS3 and experiment with them easily.

Useful links:

VTGO-PC Multilab manual:
http://www.ipblue.com/documents/vtgo-pc-multilab.pdf

The CUCME System Administrator Guide:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm.html