Welcome back.
This is part two of our discussion on the Cisco IP phone startup process.
Previously, we looked at how an IP phone obtains power, how it learns its VLAN information using CDP
or LDPE.
Are we going to continue the discussion by looking at how an IP phone acquires an IP address, how it
downloads its firmware and configuration, and how it registers with the CU CM.
We'll also discuss the two signaling protocols of Skinny and SIP.
Now once the phone is obtained, power booted and received its VLAN information by a CDP or LDPE.
It then requires an IP address.
You could manually configure an IP address on a Cisco IP phone.
That's fine when you only have two or three phones, but if you have a deployment of several thousand
phones, it's very unlikely that you want to configure the IP addresses manually.
So more common method of allocating IP addresses in the real world is to use a DHCP server.
So in this example, the phone is on the voice VLAN.
The PC is on the data VLAN and you've configured a DHCP server with a scope for both the data VLAN and
the voice VLAN.
And you've set up a layer three switch to forward DHCP requests to the DHCP server.
Otherwise you could configure a DHCP server on the voice VLAN or on the switch or other networking device.
Now a lot of VoIP deployments.
The DHCP server is configured on the layer three switch so that when the phone sends out a broadcast
requesting an IP address, it receives a directly from the switch.
However, you could run the DHCP server on a Cisco Unified Communications Manager that's not generally
recommended.
You would only run the DHCP service on the Q CM if you had less than 1000 phones in your topology.
In a Cisco IP phone environment.
It's very important that you configure the following options on the DHCP server.
Firstly, you need to configure the network and mask for the voice VLAN.
So what subnet of the IP phone is on and what mask are they going to use?
You're going to specify option three, commonly known as default router or default gateway, and then
you need to specify option 150, which specifies the IP address of the TFTP server.
The phones need to get their configuration and updated firmware from a FTP server.
So option 150 is critical.
So once the DHCP request has been received, the DHCP server will send a DHCP offer back to the phone
and that offer will contain these parameters.
Now, once again, the unified communications manager can be configured to act as a DHCP server for
up to 1000 phones.
This is not recommended because only one DHCP server can be configured per cluster.
In other words, it's a stand alone DHCP server with no backup.
The service would normally be run on the publisher.
Multiple subnets can be configured on the DHCP server, but it's generally not recommended to do this
because of the issue of no redundancy and lack of scalability.
So it's better to use an external DHCP server running on a router or a switch or on a Windows server
or Linux server.
In other words, use an external DHCP server rather than the CU cm.
I'd like to show you, however, how to set up DHCP on the Cisco Unified Communications Manager.
What you need to do is open up a browser and point it to https.
Colon forge slash.
Forward slash the IP address of your unified communications manager.
Ford slash CM service.
Now because the Q CM is using a self sign certificate.
Your browser won't recognise the certificate, so you've got to click continue to this website to accept
the certificate.
The only issue you need to be aware of is that the self signed certificate is not recognized by your
operating system and Internet Explorer or Firefox.
You've just got to make sure that the server you're connecting to is the correct server.
So the server that you think you're connecting to is the correct CAC server.
Notice on the top right hand side, there are various menu options and we'll cover a lot of this during
this course.
We are currently on the Serviceability Menu, which allows us, for instance, to start and stop services.
You need to log in with your username and password.
Well, just increase the size of the browser window here.
You need to go to tools service activation.
We're going to activate the DHCP service.
And yeah, you can see a list of services.
The service that we need to activate is the Cisco DHCP Monitor Service.
I'll discuss the various services in more detail later in this course.
But notice for instance, there's the Cisco Core Manager Service.
The Cisco TFTP service and so forth and so on.
But you need to click Save.
The SIU team will warn you that activating and deactivating services can take a while.
We'll just click.
Okay.
You just need to wait for the page to refresh.
And that will be a confirmation that the service is activated.
Okay.
The update operation was successful.
To check if the service is running, we can go to tools control center.
Feature Services.
And in the list of services.
We can see that the Cisco DXB Monitor service has started.
And it has been activated.
So going to the top of the page, I can select the Cisco Unified Cwm Administration Option and click
go.
This will take me to the administration pages of Q CM.
I just want to point out the URL.
Notice it's https.
Colon Ford slash forward slash 10 to 1 one.
In other words, the IP address of you see UCM Ford slash CM admin.
This is a famous URL to remember.
See, UCM is the administration pages of the Cisco Unified Communications Manager or call manager or
whatever you prefer to call it.
Going to the system menu.
I can choose the option dhcp dhcp server.
There is no default dhcp server.
But just to show you that I can click find.
And you'll notice here it says zero records found.
So let's click add new.
I choose the IP address of my Q CM.
So that's the server that I'm going to configure DHCP on.
I can then specify a primary DNS server.
So whatever the IP addresses of my DNS server.
So primary and secondary DNS servers can be configured.
I can specify the primary TFTP server.
Now this is very important.
Remember, option 150 is required for the phones to get their configuration and firmware.
So this will be the IP address of my SIU CM server or comms manager server.
There are various other options that I can specify here, like the IP address, leash time and so forth.
We're just going to leave all of those at default values and click Save.
So I've specified information like my DNS server and my TFTP server.
Now going to system dhcp dhcp subnet, I can create various subnets.
I'm going to click ADD.
What you're doing here is essentially creating scopes or subnets for devices on different VLANs or subnets
within your organization.
Once again I can select my DHCP server.
I can now specify the subnet.
So, for instance, 10.2 2.0.
Specify the starting IP address to allocate to my phones.
10.2 2.1 and IP address.
So these are just values that specify the IP addresses to give to the phones.
I can specify my router's IP address.
10.2 2.101.
I can specify my subnet mask to 55 to 50 5 to 55.0.
I could specify my domain name.
Once again I could specify my TFTP server.
Notice it's the same IP address as the IP address of my DHCP server because both the FTP server and
the DHCP server are running on my c UCM server.
Once again, I could specify various other options, including the least time for this scope or the
specific subnet.
I could then click Save.
That's how you configure DHCP on q cm.
In a separate section of this course, I'm going to show you how to set up SIU CME with DHCP.
In other words, configuring DHCP on a router.
Once the phones have received an IP address, the phones will attempt to download their firmware and
configuration from a FTP server.
Phones get updated firmware and their phone configuration from the TFTP server running on the Q CM.
The Cisco TFTP service builds configuration files and serves embedded component executable ring files
and device configuration files to the phone's.
So when the phone connects to the TFTP server, it's going to attempt to download a device specific
configuration file.
In other words, a phone with a mac address.
Quadruple A, quadruple B.
Quadruple C will attempt to download a file starting with CEP, which once again just stands for Celsius
Ethernet phone with its MAC address config XML.
That configuration file is built automatically on the Q CM when you add that phone to the Q configuration.
If the phone is not being created on the communications manager or C cm, the phone will attempt to
download a file xml default CNF XML.
This is a configuration file that contains basic settings like the firmware.
The phone should be using and the communications manager that the phone should be communicating with.
So it points to the Q CM server and provides details like the IP address of the Q CM and the port number
the phone should be using when communicating to the Q CM.
It can also contain other information like location information and URLs for phone buttons.
To configure TFTP on the SIU cm you need to do the following.
On the navigation pages.
Go to the serviceability menu.
So select serviceability and then click go.
You could also go directly to https IP address of the Q cm forward slash CM service.
Under the Tools menu, we're going to select service activation once again.
Under the services.
You'll notice Cisco TFTP.
So we'll select that and then click Save.
We once again warned about activating and deactivating services and we'll just click.
Okay.
And the update operation has been successful.
Notice the Cisco TFTP service is activated.
That's all there is to configuring TFTP on the QC server.
Once the phone has downloaded its configuration and updated its firmware, it will attempt to communicate
with the Q CM to important port numbers that you need to remember or TCP port 2000 use by skinny client
control protocol or skinny and TCP port 5060 used by SIP.
The two signaling protocols used on handsets in Cisco environments are skinny or SEP.
So the phones will now try to connect to the system and register.
These are default numbers and can be changed.
To change them on the Q CM You would do the following.
Under the navigation menu, you would go to Cisco Unified CRM Administration.
Click.
Go.
Under the system menu, you can go to the option Cisco Unified Cwm.
And then notice this option.
Find.
You can see in this example, we have one Q.
CM So I'm going to click on that option.
And scrolling down to the bottom, you'll notice you have options here for the TCP port settings for
the server.
The first one is Ethernet phone port, in other words, skinny, which is port 2000.
Then we have TCP, listen, port and TCP lives.
MGP is typically used on gateways rather than phones, but you could change the port numbers used over
here.
Here's the port used by SIP 5060.
And if you want to use secure sip, the port number by default is 5061.
You can change the port numbers just by changing the options in this list.
Now Skinny Cold Control Protocol, or CCP, commonly known as Skinny, is a Cisco Proprietary Terminal
Control Protocol.
This is the first of two protocols used for signaling and control of Cisco IP phones.
The second one is session initiation, protocol or SIP.
The recommended protocol for implementation of Cisco IP phones has for many years been skinny.
That is changing these days as more features are added to SIP.
But for now, understand that Skinny is a proprietary protocol.
It's a stimulus protocol.
For every event, the device sends a message to the system.
The phones themselves are clients to the unified communications manager.
They cannot even provide dial tone without the SIU cm telling them to provide that dial tone.
It's proprietary, which has the advantage of quick additions and changes, but disadvantage of not
being interoperable with other vendors.
Once again, it's a client server architecture where the SIU, CM is in control of the IP phones.
It allows for simple configuration where the phones themselves have no configuration but get their entire
configuration from the SIU cm.
The SIU CM maintains the dull plan and root patterns.
In other words, it maintains all the information for the phones.
The phones themselves can do nothing without the SIU cm telling them what to do.
So, for example, if we had a situation like this.
With IP phone 1000, an IP phone 1001 connected to a switch physically, but registered with the Cisco
communications manager.
These phones are totally under the control of the Q CM.
If 1000 win or -- the phone would send a skinny message to the SIU cm saying I'm more --, what
must I do?
And the C.U. scheme would send a message to the phone saying Play dial tone.
It's important to notice that Dalton does not come from the SIU like it would in a traditional environment.
The dull tone is played locally from the phone.
If the phone dialed digit let's say digit one that would be sent to the Q Cwm becomes manager, would
process that message and send a message back saying stop dial tone.
Now, there are a lot of other messages taking place in the background, but I just want to show you
a high level overview of the process.
For subsequent digits, the same thing would happen.
The phone would send a message to the comms manager and the comms manager would send messages back.
For example, when you dial digit, let's say digit one that digit displays on your phone because a
message has been sent to the comms manager and a message is being sent back again saying display this
digit on the phone.
Once 1000 has dialled digits 1001, the comms manager can match those digits to a phone that's currently
registered.
In other words, this handset becomes manager, has a record of all phones that are currently available
and registered.
So the comms manager will send a skinny message to this phone telling it to ring.
It'll also tell the phone to make its lamp flash.
Other messages that are sent to the phone are to change the display so that 1001 can see that the call
is coming from 1000.
When the user answers the call, a skinny message is sent back to the comms manager, telling the comms
manager that the phone is now or hook.
The comms manager will send a message back to the phone, telling it to stop ringing, telling it to
stop flashing its lamp, telling it to change its display, and so forth and so on.
The moral of the story is that these two phones can do nothing without the comms manager telling them
what to do.
They are clients to the server as EUCOM will then send messages to both phones, telling the phones
to set up an OTP stream to each other.
It's important to remember that the OTP streams are direct between the two phones.
So there's a separate ATP stream from 1000 to 1001 and another separate unidirectional ATP stream from
1001 to 1000.
The OTP streams do not flow via the SIU cm.
They are direct between the two handsets.
Obviously physically they are flowing through the switch, but logically they are going directly to
one another.
So the comms manager communicates with both phones, telling them about each other because Phone 1000
needs to know the IP address of 1001 so that it can stream the IP to the right IP address.
1000 also needs to know the port number that 1001 is using so it can stream to the right port number.
And by the same token, 1001 needs to know the IP address and port number that 1000 is using.
So skinny messages are used by the system to communicate that information to the handsets.
But once the call is established, the SIU CM is no longer involved in the conversation.
The two devices are communicating directly with each other without any interaction from the SIU cm.
Now session initiation protocol or CIP is an open standard.
Unlike Skinny, which is proprietary, it's a peer to peer protocol.
Unlike Skinny, which is client server.
But be aware, please, that SIP supports basic functionality in the open standards.
But to get featured parity with Skinny SIP has been extended by Sysco to provide the functionality.
So even though SIP is an open standard, it is extended by vendors to provide features.
So don't expect to be able to go and buy a cheap SIP handset from your local retailer and connect it
to a Cisco core manager or express environment and have the same features as Sysco phones.
That's not going to happen.
You're going to be able to make and receive calls and have basic functionality, but don't expect the
same features as what you'll get on a Cisco handset.
A peer to peer protocol isn't a great idea when you have 10,000 phones.
So in SIP we have the concept of a proxy server, which as an analogy controls the call between the
two phones.
Please note this is not a pure client server environment like you have in Skinny.
Certain processing can be done by the local handset with most of the processing done by the Q CM.
Whereas in Skinny all processing is done on the CU cm SIP is becoming more and more popular, and over
the last few years, Sysco has been investing more and more in the features and functionality of their
SIP phones.
One of the great things that you get with is presence.
SIP also provides interoperability with other vendors and is the protocol of choice for interoperability
between vendors.
Once registered with the SIU Cwm, the phones will download their soft key templates.
We'll be talking more about the soft key template later, but essentially that is the layout of some
of the buttons on the phone.
That concludes our discussion of the Cisco IP phone start up process.
We looked at how an IP phone obtains power.
We discussed different methods of provisioning power to an IP phone.
We looked at how an IP phone obtains VLAN information, IP addressing configuration and firmware and
how it registers with a system.
We also discussed the two signaling protocols that can be used by Cisco IP phones, skinny and SIP.
Thank you for watching.