This document describes the Peer Firmware Sharing (PFS) feature of the IP Phone that allows IP Phones located at remote sites in order to share firmware files amongst them, unlike the traditional method of IP Phone firmware upgrade that demands the Trivia File Tranfer Protocol (TFTP) server to send firmware files to each phone.
Cisco recommends that you have knowledge of these topics:
Cisco Unified Communication Manager (CUCM)
IP Phone Firmware Upgrade Process
The information in this document is based on these software and hardware versions:
Cisco Unified IP Phone 7961 and 7961G.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
In the traditional firmware upgrade process, the TFTP server is supposed to communicate individually with each phone, and send the upgrade files to them simultaneously. However, consider a scenario wherein 1000 phones are located at a remote site and the TFTP server at the headquarters is approximately 15000 kms away. In this case, phones are connected to the server over the Wide Area Network (WAN), and in a huge quantity. So, the firmware upgrade for these phones takes a considerable amount of time.
PFS allows IP Phones located at remote sites to share the firmware files amongst them, which saves bandwidth when the upgrade process takes place. This feature uses Cisco Peer to Peer Distribution Protocol which is a Cisco proprietary protocol used to form a peer to peer hierarchy of devices. Cisco Peer to Peer Distribution Protocol is also used to copy firmware or other files from peer devices to the neighbouring devices.
PFS is included in the phone firmware versions 8.3(1) (and above) which ships as a part of the CUCM 6.0 release. It will be applicable to 3rd Gen Cisco IP Phones that includes:
7941 7961 (Gig and non-Gig)
Future 3rd Gen phone models will be supported as well.
Note: PFS is neither applicable to 2nd generation 7960 or 7940 phones nor to OEM phones like the Tandberg video phones.
Here are some of the key advantages of PFS over the traditional upgrade method:
Limits congestion on the link between centralized TFTP server and the remote IP phones.
Helps in the case of low bandwidth scenarios.
The more the number of IP phones, the better it's performance compared to the traditional firmware upgrade method.
The PFS field needs to be enabled in order for this to work.
PFS works in a hierarchy, where one phone becomes the parent, and the other, its child phone. When the upgrade is initiated, the TFTP sends the firmware files (one by one) to the parent phone. The other phones wait till the download of the component is complete on the parent. Then, once one component is received completely by the parent, it passes it on to its child phones through a TCP connection. This works in the manner of a binary tree, where one phone can have maximum 2 child phones as shown in the image:
Figure 1. Peer Firmware Sharing Distribution Hierarchy
Figure 2. Hierarchical Difference between Traditional Upgrade Method and PFS
Figure 2 (a). Traditional Firmware Upgrade
Figure 2 (b). PFS
Only the PFS field needs to have the value enabled on either of these in decreasing order of precedence as shown in the image:
1. Phone Configuration page of every remote device.
2. Common Phone Profile.
3. Enterprise Phone Configuration.
This is an excerpt from the console logs taken from the root phone, in order to confirm that PFS works here:
"DBG 02:19:22.634167 DLoad: +++ fd=7 Listening on peer TCP port 4051"
Indicates the phone starts the process of peer to peer and is ready to listen to the handshake packets to setup a Peer to Peer structure before it shares the firmware:
NOT 02:19:22.634945 DLoad: ^.idl_child.c-openUDPPort
NOT 02:19:22.664131 DLoad: |parent=-1><fd=-1 fd=-1 FULL=0
Phone becomes the root since it did not get any incoming packets of handshaking from the peers:
NOT 02:19:24.412806 DLoad: @@@HROOT:XID080027F8 H=36685558 m=CP-7961G
Mark a difference between both:
When you enable PFS from the Phone Configuration page, there is no considerable difference between PFS and the traditional method of upgrade. However, while the upgrade is in process, a few differences can be marked from the phone screens.
Traditional Upgrade Method
All the phones show the same screen throughout the process. For example, if there is one component that is downloaded on one phone, others also show the same.
Some of the phones show a different behavior here. Basically, whoever is/are the parent(s) at one instant, might show the status of component x as 100%, whereas others still upgrade to component x, and, show the KBs that are downloaded for x.
The box is blank for a traditional upgrade as shown in the image.
You can see the PFS icon at the top right corner of the screen of the phones at the time of upgrade as seen in the image.
Points to Remember:
PFS works on a file by file basis. One phone might become parent for one file or child for another, at the time of the same upgrade.
PFS is phone-model specific; different phone types will form multiple hierarchies.
PFS can only work with phones in the same subnet.
The more the number of devices, the better is its performance.
It gives better results when phones are reset in bulk.
All UDP broadcast traffic and TCP child connections from phone to phone take place on port 4051.
In order to configure Peer Firmware Sharing for multiple phones at once:
For Cisco Communications Manager 5.0 and later, enable Peer Firmware Settings in the Phone Template window of the Bulk Administration Tool.
For Cisco Unified Communications Manager 4.1(3), 4.2(3) and 4.3(1), download an AXL script: