Showing posts from July, 2015


In a collaboration environment TFTP service can be provided using two models:
CUCM TFTP ServerExternal TFTP Server
Configuration files are delivered to endpoints using TFTP transfer protocol. Configuration files share the following parameters:
Prioritized list of CUCM servers for endpoints to registerTCP port used to connect to CUCM serversExecutable load identifiers
In addition, the configuration file per device include the following parameters as well:
Local/language informationURLs for phone buttons (messages, directories, services, and information)For gateways (e.g. MGCP), the configuration file contains gateway configuration
The configuration file can be in the following formats:
Note: A key difference between .cnf and .xml that phones requesting .cnf will get the load ID from CUCM while phones using .xml will get the load ID in the XML file
The format of the file is controlled by the service parameter Build CNF Files. Navigate to System > Serv…

IP Phone Boot Sequence

Powering Once IP phone is connected to PoE Ethernet Switch, it will get the required power through Cisco-proprietary PoE or 802.3af PoE.
Configuring VLAN In this phase, the phone will be waiting for the response of CDP broadcast to get the voice vlan. If the phone is connected to a device that does not support CDP, the CDP query times out, and the phone moves to the next step in the registration sequence. The registration might if you have voice and data vlan
Configuring IP
The IP phone will send DHCP broadcast on its voice vlan asking for IP address DHCP server will respond with DHCP offer. This offer will include IP address, subnet mask, default gateway, domain name, dns server, etc. It will include TFTP server details under option 150
Note: By default Cisco IP Phones will have DHCP client enabled. You can disable DHCP client from the phone (Navigate to Settings > Network Configuration) and configure the network settings manually.
Configuring CM
At this stage, the …

PVDM3 DeepDive

I have created a document on Cisco Support Forum which might be interesting for your :). Here you go.


MED is an extension for LLDP that support additional TLVs. LLDP-MED supports the following three classes of endpoints:
Generic (class 1): Basic participant endpoints; for example, IP communications controllers. Media (class 2): Endpoints that support media streams; for example, media gateways and conference bridges. Communication Device (class 3): Endpoints that support IP communications end users; for example, IP phones and Softphone.
By default, a network connectivity device (e.g. switch) sends out only LLDP packets until it receives LLDP-MED packets from an endpoint device (e.g. IP Phone). The network device then sends out LLDP-MED packets until the remote device to which it is connected ceases to be LLDP-MED capable.
The additional TLVs supported can be groups as (by default all MED TLVs are enabled):
Capabilities TLV — Endpoints determine the types of capabilities that a connected device supports and which ones are enabled.
MED Information:

Link Layer Discovery Protocol (LLDP)

Link Layer Discovery Protocol (LLDP), standardized by the IEEE as part of 802.1ab, enables standardized discovery of nodes in a multivendor environment.
Use of LLDP is limited to 802.1 media types such as Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) networks. It can't be used for HDLC, Frame-Relay, ATM, etc. LLDP and CDP can run on the same interface
LLDP is unidirectional, operating only in an advertising mode. LLDP enabled nodes will send multicast frames out of all LLDP enabled interfaces. LLDP enabled nodes which receive LLDP frames can record information about their neighbors and build their own topology database. Each node can be configured to enable/disable send and/or receive of LLDP frames as separate task.
LLDP exchange attributes in the format of TLVs between devices to discover each other.
The switch supports these basic management TLVs. These are mandatory LLDP TLVs. Port description TLV System name TLV System des…