Updated my Google doc table of IP Phone firmware:
Updated my Google doc table of IP Phone firmware:
In my 3rd company blog article, I talked about DHCP and auto configuration via DHCP. There are fifteen different feature groups (IP Deskphones Fundamentals, NN43001-368, Appendix B: Provisioning the IP Phones) and 100+ different settings configurable via DHCP (I didn’t count them, I’m estimating). Some of the gotchas I’ve learned over the years are as follows:
Another thing that I find extremely helpful is learning the provisioning cycle and the status messages which display on the IP Phone during boot up:
|Provisioning Step||Display message|
|LLDP||Waiting for Cfg Data…|
|Manual Provisioning||Prov. 192.168.0.254 (or whatever IP you have)
(system.prv failed may display)Attempting TFTP…
|Registration (pre-connect)||Connecting to S1
Connecting to S2
|Registration (post-connect)||Connect Svc
Node & TN
This way, if you get stuck at a particular phase, you know where and can use that to determine your next troubleshooting step. For example;
Last week I talked about an overview of the registration process and the different phases for the Avaya IP Phone registration process. This week my contribution to the company blog covers the essential information needed to deploy any IP phone. Understanding IP Phone deployment, essential information needed for all deployment scenarios. Part two of a six part series.
I start with the assumption that you already know a little bit about the CS1000 architecture and programming– I tried to keep this article to 600-800 words, and even discounting some of the captures I put in the article it still came out to almost double the size. To do a really in depth review of this topic you need a lot more than just a six part series. But, I have plenty of other topics that need attention and while IP Phone deployment is an interesting topic (to me, because of the number of features available compared to those that are implemented in most sites) as a topic, it’s just one of many. Writing white papers is best left to people who have that as a job– amiright?
Unlike completely creative writing, the technical writing comes very easily. The problem with creative writing is always figuring out the answers that you don’t even really understand the questions to– if X happens, how does Y feel about it, how do they react, etc. When a writer gets stuck, often the problem is that either they’re not able to answer the question, or they may not even realize what question they need to answer. But, with technical writing, all you have to be is knowledgeable about your topic and have time to flip through the documentation.
Trimming the fat
But, I removed a lot of in depth detail that I started to slide into the original blog article and instead referenced the documentation. I figure I trimmed at least another 800 words from the article that gave a lot more detail on the use of the Nortel-i2004-A string, as well as a few other B-string mnemonic that I really like when I’m in charge of IP Phone deployment (or tasked with consulting with a customer.)
Trimming takes at least two passes.
Speaking of documentation, it was a challenge getting some of this history straight. I was around during the UNIStim 1.x days (we’re at 5.4 now), but the documentation doesn’t really talk about when features were implemented, changed or removed.
For instance, it wasn’t until 2.2-2.3 that the new Nortel-i2004-B string was introduced, but the latest UNIStim 5.4 documentation doesn’t say when it was introduced. This is important because if you’re on firmware prior to 2.3, you might not be able to support the B string format (I know this is unlikely– but I know of customers that are still on Meridian-1 software that was released before I got into Telecom in 1999.)
In addition to filling in the facts that I could validate through documentation, I also had to make sure that I hadn’t introduced any errors through typos or omissions. Being thorough takes a couple of passes.
Selecting images to fill out a blog is tough for me– I struggle with the artistic creativity required for selecting images that work with the blog post. And, when I cannot find what I’m looking for (and when a google search fails me), I whip something up in Photoshop. You might think that’s creative, but it doesn’t feel that way.
Then, it’s on to getting the text formatting right. Another couple of passes there. Headers are properly coded with the correct H1,H2,H3 tag, words and phrases get the correct bold/underline/italics emphasis. Colored text, when used, can convey information subtly. (e.g., On my company blog articles, I use a dark green bolded text format to represent terms which are universal and not specific to the subject of my blog.)
Then I submit the blog post to the company approval process and if it gets approved, we schedule it for posting.
And thus, Part 2, IP Phone deployment, essential information goes live.
The full series will be:
The IP Phone Registration process articles are some of the most visited articles on my personal blog. So when my employer began a new initiative asking employees to contribute content to the business blog, I proposed and was greenlit to rewrite and publish my IP Phone Registration overview as a six part blog series.
There will be some rehash of information previously posted here, but there will also be parts that haven’t yet been covered.
The full series will be:
Next week, I anticipate getting part 2 approved and published.
Now, for the “Call to Action”– I get special recognition at my job if my articles happen to be the most viewed articles over the next 6 months (compared to any of my co-worker’s articles.) So, I know this topic is popular and I’m hoping you’ll be tempted by more information on this topic.
Go ahead– do us both a favor and click through to the first article Understanding IP Phone deployment, registration process overview.
If you’d like to influence future articles, register to stay informed and ask your questions either via the registration process or the comments section via the Comments section.
The networking giant warned of the vulnerability on Wednesday, almost two weeks after a security expert demonstrated how people with physical access to the phones could cause them to execute malicious code. Cisco plans to release a stop-gap software patch later this month for the weakness, which affects several models in the Cisco Unified IP Phone 7900 series. The vulnerability can also be exploited remotely over corporate networks, although Cisco has issued workarounds to make those hacks more difficult.
All Avaya IP Phones, in factory default mode, are configured with ADAC/LLDP enabled. LLDP, or Link Layer Discovery Protocol (802.1ab), and ADAC, or Auto-Detection Auto-Configuration, can operate independently. ADAC provides automatic configuration of the Data Switch port, while LLDP provides a method for the device to communicate it’s nature to the switch it connects to. ADAC can also utilize LLDP to identify the connected device type and configure the Data Switch port. Additionally, LLDP supports LLDP-MED, Link Layer Discovery Protocol Media Endpoint Discovery which permits configuration information to be provided to the Media Endpoint (i.e., IP Phone) automatically from the data switch without the need to communicate with additional components on the network.
|LLDP can delay the IP Phone boot process if ADAC/LLDP is not enabled on the network. LLDP is only recommended for those environments where LLDP or ADAC is enabled on the data network.|
See the documentation for precedence of configuration methods. Manual configuration always takes precedence over automatic configuration values. If any unexpected behavior is experienced, consider factory defaulting the IP Phone as part of the troubleshooting process.
|This LLDP Process diagram does not include LLDP-MED behavior.|
For environments where Auto-VLAN ID is enabled, the IP Phone must request DHCP (acquiring an IP address and the Auto-VLAN ID from the DHCP server), then release the DHCP IP address and perform DHCPDISCOVERy a second time to obtain the DHCP Provisioning information. By configuring the Voice VLAN ID via LLDP/ADAC or LLDP-MED, you can eliminate the second DHCP request (reducing load on the DHCP server.)
Additionally, ADAC/LLDP and LLDP-MED increase network security by configuring the network port to the Voice VLAN instead of trusting the 801.1q VLAN ID supplied by the connected device. (A standard converged scenario is to configure the data port to trust the VLAN ID tag provided by the attached device, but this does introduce the potential for security issues and is not recommended for a secure environment.)
Auto-Detection, Auto-Configuration (ADAC) provides an automatic configuration method for Avaya (formerly-Nortel) IP Phones.
ADAC Modes configured on the Ethernet Routing Switch (ERS):
Detection Modes configured on each port (one or both must be assigned to each port to enable ADAC for that port):
MAC address detection supports up to 32 devices per port. LLDP detection supports up to 16 devices per port. A standard scenario is one IP Phone and one PC on each port.
Ports are polled every two (2) seconds for their auto-configuration state. ADAC will be applied against a port when one of the following two conditions are true:
ADAC is removed if any of these conditions become true:
|ADAC will automatically update VLAN ID and PVID settings under the above specified conditions. This will cause manual settings to be over-written and is design intent. Michael McNamaranoted in 2008 that an earlier release of the ERS software will maintain the VLAN ID and PVID as the port is configured when ADAC is enabled. For example, if you configure the default VLAN ID and PVID as 10 and the ADAC Voice VLAN and PVID as 20, then change the VLAN ID and PVID to 30, when ADAC resets the port configuration (either enabling ADAC or disabling ADAC), the configuration will go back to what it was configured at the time ADAC was enabled. (VLAN/PVID 10 if ADAC is disabling, VLAN/PVID 20 if ADAC is enabling.)I do not have a lab ERS to play with this configuration at this time, so I’ll just make a note that it’s something to watch for.|
This article provides an overview of the Avaya IP Phone registration procedure (for UNIStim IP Phones)
When the phone is powered up, the following happens:
|If you experience any problems with any part of the process, use the IP Phone Factory Default reset procedure to clear all local configuration settings.|
|Leaving LLDP/ADAC enabled when it is not supported by the Layer 2 switching equipment installed at the site can extend boot times for IP Phone devices. While LLDP/ADAC is enabled in a factory default configuration, it is recommended that this be disabled unless it is specifically supported by the networking environment.|
The only information that is critical to an IP phone for the boot process is:
When troubleshooting, eliminate variables by resetting the unit back to factory default and then configure only the minimum number of settings needed to establish connectivity (start with manually configuring the phone, then migrate components of the configuration back to auto to determine where the process fails.)
The 2033 Conference phone firmware versions are approximations. I’m recreating this table from documentation, since Avaya doesn’t seem to care to keep such a thing current. I do have some old UNIStim 3.0 documentation. I’m debating whether or not to include the now-manufacture-discontinued IP phones (i.e., i2001, i2002, i2004). I’m very tempted to do so, since I still see a lot of 4.5 and earlier systems (which still support the older IP Phones.)
I installed Google Analytics a few days ago, and discovered something really amazing (i.e., amazing for me.): the most searched for pages on my blog are pages that I generated about three and a half years ago.
The Nortel Factory Default reset article was written to help me remember the code. Between my previous job and my current job, I found myself needing to reset phones to factory default irregularly, but often. In fairness to Nortel/Avaya, it’s not always the phone’s fault, but especially when you’re providing remote support and you’re uncertain what the field guy is doing or seeing (because, well, you’re not physically there to look over his/her shoulder), I found it useful to instruct people to factory default the phones as part of a troubleshooting process.
The following month, I posted the article on Latin acronyms. In retrospect, it’s not as much a surprise to me now that I’d already been concerned with how to write well. I am, after all, embarking on my own journey as an author of fiction. When I wrote that article, I was working for my current employer and I’d been writing more and more documentation. In documentation, proper use of acronyms greatly enhances readability. e.g., the latin acronym for exempli gratia is useful when you want to give an example, and much easier to use than throwing around the clunky “for example” or colloquial “forex”. When you want to add clarity to a sentence, the acronym for the latin phrase id est is useful. That is to say i.e. is a lot easier to use than saying that is.
In previous posts, I’ve covered someone else’s great list of building a platform and followed up with an explanation of why I critiquing other people’s work (and post it to my blog). I’m not sure how, going forward, I can capitalize on the popularity of the acronym post. I’m going to have to put some thought in to it. For the IP Phone procedure, there’s a lot of documentation that I can turn in to articles, so I’m going to be doing that at least once a week. I already started with reviewing QOS Notification Levels and Manually Upgrading Firmware on Avaya IP Phones.
There are several reasons why you might want to enable manual provisioning of your Avaya IP Phones:
The provisioning phase of the boot process can use DHCP or HTTP. To use HTTP, you must configure DHCP Option 66 in the IP Phone VLAN to point to the HTTP server name and prefix the server name with “http://”. For example DHCP Option 66 “http://httpserver/”. Whether you select TFTP or HTTP, the provisioning phase process checks the system.prv file and if it exists, may load one of the other provisioning files. If multiple provisioning files are loaded, the configuration parameters take effect in the following priority:
The provisioning files provide the Info Block, which contains all the information you might normally stick in DHCP (or manually configure on the phone if you’re especially sadistic towards your telecom analysts). The Info Block can also contain information that is not normally provided in the DHCP string (e.g., Node and TN.) After the provisioning block is loaded, the IP phone will load the configuration file to determine how it should obtain firmware and font file updates. At some future point, I might come back and write another article to cover provisioning via HTTP or TFTP, but for now, we’re going to focus on the configuration file and manually upgrading the firmware on an IP phone.
The Configuration file can contain a lot of information:
We’re going to focus only on the [FW] values in this article.
|[FW]||Section header for SET FIRMWARE download information.|
|DOWNLOAD_MODE||AUTO||Recommended value. Download firmware only if the VERSION on the provisioning server is newer than the version on the phone.|
|FORCED||VERSION of the phone is ingored. Firmware is always downloaded.|
|VERSION||e.g., 0625C8J||The VERSION string is compared to what is on the phone. VERSION should match the firmware FILENAME exactly.|
|FILENAME||e.g., 0625C8J.bin||Image filename. Must match the filename of the actual IP phone FW file to be downloaded|
|SERVER_IP||x.x.x.x||IP address of the TFTP server in decimal notation.|
|SERVER_PORT||0 to 65535||The port used by the TFTP server at SERVER_IP. Optional|
|SECURITY_MODE||0||For future use|
Example 1140E.cfg file:
[FW] DOWNLOAD_MODE AUTO VERSION 0625C8J FILENAME 0625C8J.bin PROTOCOL TFTP SERVER_IP 192.168.0.101 SECURITY_MODE 0
After placing both the configuration file (e.g., 1140E) and the FILENAME (firmware image) in the root of the TFTP server at SERVER_IP, the next step is to choose the method of configuring the IP Phone to know about the external provisioning server (if you haven’t already done this). The options available are:
|While it is possible to configure the DHCP Option 66 to point to an HTTP server (to retrieve the *.prv or *.cfg files), other files must be available via the protocol specified within the *.cfg file. For the purposes of this article, that means a TFTP server is required whether you provide the <TYPE>.cfg via HTTP or TFTP.|
Select a method and implement it. To keep this article short and focused, we’re going to assume you know how to do this.
Plug in your phone and power it up. Assuming that (your DHCP configuration or manually configured provisioning server is correct and) it is able to reach the provisioning server, it will download the <TYPE>.cfg file from the TFTP/HTTP server, then using the instructions contained within, determine if a firmware download is required and perform that download if necessary.
If you use DOWNLOAD_MODE FORCED, the IP phone will force a download of the firmware each time the phone boots. This will increase the boot time for all IP phones configured to use that <TYPE>.cfg file.
I hope you found this article helpful. If you did, please share it.
Note regarding i2007.cfg file
Early versions of the IP Phone 2007 FW will fail to download newer versions of FW if the [FW] line is present before the FW download information in the .cfg file.
If the FW version currently on the IP Phone 2007 is prior to any version of 0621C4x, then delete the [FW] line. Once the phone has FW version 0621C4x or greater, the [FW] line must be present. Example: Phone has 0621C3A – comment out or delete the [FW] line in the i2007.cfg file Phone has 0621C4J – keep the [FW] line in the i2007.cfg file