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.
CLICK HERE TO DOWNLOAD GNS3 FILES FOR THIS LAB
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.