Updated my Google doc table of IP Phone firmware:
Updated my Google doc table of IP Phone firmware:
When IP Phones enter a reboot loop, attempt to “upgrade”, fail, then reboot again, or
When IP Phones enter a reboot loop, attempt to “upgrade”, fail with “FW authentication failure”, then reboot again
UNIStim 5.0 or earlier
Avaya IP Phone 1100, Avaya IP Phone 1200
UNIStim firmware is digitally signed.
Signature has an expiration date.
UNIStim versions prior to 5.0 had shorter expiration dates.
New IP Phone hardware will not load firmware with expired signatures.
Use UNIStim 5.1 or later firmware.
Avaya has applied a digital signature with a 10 year expiration date to UNIStim 5.1 and later.
I updated my Google drive table of UNIStim firmware releases.
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.
I forgot to update my Google doc.
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.)
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