Jun 112014
 

https://support.avaya.com/downloads/download-details.action?contentId=C20145311538319080_3&productId=P0599&releaseId=UNIStim%205.x

Updated my Google doc table of IP Phone firmware:

Sep 172013
 

Avaya CS1000 IP Phone registration process, DHCP (c) 2013 John Williams, DATARAVEIn 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:

  • As noted in the 3rd blog post, Stickiness can cause deployment issues for refurb phones– Always add a factory reset to your troubleshooting efforts (**RENEW[MAC]##), which was introduced in UNIStim 3.0, otherwise your refurb phone may not operate as expected when first deployed.
  • When you have multiple Signaling Servers– Always make sure that both Sig Servers are using the same IP Phone firmware, otherwise your phones may “upgrade” to an earlier firmware release when they failover, resulting on extended and unexpected downtime.
  • Know your current UNIStim firmware. There have been issues in the past where newer IP Phone hardware requires a minimum firmware level, which means that all IP Phones in the environment must be upgraded in order to deploy new phones.
  • Learn how to use PRT TNB commands in LD 20 and STAT IP commands in LD 117 (I’m actually planning on doing a future blog post on this topic, since the LD 117 commands can be used to also inventory your IP phones)–
    • Make sure that the TNB is programmed, otherwise you’ll get SRPT062/SRPT0062 – Request to register TN rejected. Reason = UNEQUIPPED.
    • Make sure the set isn’t deployed elsewhere, otherwise you’ll get SRPT062/SRPT0062 – Request to register TN rejected. Reason = DUPLICATE.
    • Make sure the set is the right TYPE, otherwise you’ll get SRPT062/SRPT0062 – Request to register TN rejected. Reason = WRONGTYPE.
    • Make sure the set is of the right TN_TYPE (covered in part 2 of the company series), otherwise you’ll get SRPT062/SRPT0062 – Request to register TN rejected. Reason = CANNOTCONVERT
      • 2004P1, 2004P2, 2210, 2211, 2007, 1140, 2050PC, 2050MC, 6140
      • 2002P1, 2002P2, 1120, 1220, 6120
      • 2001P2, 2033, 1110, 1210
      • 1230
      • 1150
  • Know how to troubleshoot your data network– Always make sure that your provisioning method is supported in the subnet where the IP phone is being deployed and know how to check the data network configuration, otherwise your phone might get stuck at “Starting DHCP…” or “Connecting to S1…” (or “Connecting to S2…”)
    • I can’t tell you how many times I’ve seen a telecom tech install an IP Phone into a brand new subnet which has no DHCP configuration options, or a new data switch without correct VLAN settings, and then request help– only to be landed with a bill for not setting up the new subnet correctly.

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…
DHCP Starting DHCP…
Manual Provisioning Prov. 192.168.0.254 (or whatever IP you have)
system.prv reading…
(system.prv failed may display)Attempting TFTP…
Registration (pre-connect) Connecting to S1
Connecting to S2
Registration (post-connect) Connect Svc
Node & TN
Connect Svc
Forwarding…

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;

  • If you get stuck at “Starting DHCP…” then you should check (a) is your DHCP server still running, (b) are you in a subnet that provides the DHCP options you need, (c) can your IP phone reach the DHCP server, (d) does the IP Phone firmware support the features you’re trying to push to it?
  • If you get stuck at “Attempting TFTP…”, (a) is your TFTP server still running, (b) can you IP Phone reach your TFTP server, (c) are your PRV files correctly configured?
  • If you get stuck at “Connecting to S1” (or S2), (a) is your IP Phone in the right VLAN, (b) Can the IP Phone reach the signaling server, (c) is the signaling server still running?
  • If you get stuck at “Connect Svc Forwarding…” then there is something wrong with your signaling server– it’s responded to the initial connect request, and it’s forwarded the request to the signaling server but the signaling server isn’t responding correctly to complete the registration process.

Aug 272013
 

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.

Getting started

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.

Fact checking

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.

Formatting

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.)

Approval

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:

  • Part 1, IP Phone registration process overviewA review of the basic registration process, the phases, a couple of tips and some hints of topics to come.
  • Part 2, Manual IP deployment, Partial and Full DCHP deployment – the essential information needed for all phone deployment scenarios.
  • Part 3, Full DHCP in more detail – the power of DHCP and auto configuration.
  • Part 4, integrating switch level registration – creating efficiencies in phone registration using LLDP/ADAC.
  • Part 5, Using TFTP provisioning for security and redundancy – advanced IP phone deployment techniques using TFTP provisioning.
  • Part 6, remote worker scenarios, NAT, VPN, Firewalls – advanced networking scenarios.

 

Aug 232013
 

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:

  • Part 1, IP Phone registration process overviewA review of the basic registration process, the phases, a couple of tips and some hints of topics to come.
  • Part 2, Manual IP deployment, Partial and Full DCHP deployment – the essential information needed for all phone deployment scenarios.
  • Part 3, Full DHCP in more detail – the power of DHCP and auto configuration.
  • Part 4, integrating switch level registration – creating efficiencies in phone registration using LLDP/ADAC.
  • Part 5, Using TFTP provisioning for security and redundancy – advanced IP phone deployment techniques using TFTP provisioning.
  • Part 6, remote worker scenarios, NAT, VPN, Firewalls – advanced networking scenarios.

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.

Jan 142013
 

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.

via Hack turns the Cisco phone on your desk into a remote bugging device | Ars Technica.

Jul 282012
 

IP Phones LLDP/ADAC Boot Procedure

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.

NOTE
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.

 

WARNING
This LLDP Process diagram does not include LLDP-MED behavior.

Configuration Methods

  • By default, LLDP is enabled on the IP Phone. If LLDP is enabled on the Phone, ADAC can use LLDP to identify the connected device for ADAC configuration.
    If LLDP is disabled on the IP Phone, ADAC can use the MAC Address of the connected device for ADAC configuration.
  • After DHCP Provisioning or “Manual Provisioning” via TFTP, LLDP can be disabled. However, if LLDP is manually disabled on the IP Phone, it cannot be enabled via DHCP or “Manual Provisioning”.
  • LLDP-MED can configure the following settings on the IP Phone:
    • Voice VLAN ID
    • Control pBits (priority bits, Layer 2)
    • Media pBits (priority bits, Layer 2)
    • Data pBits (priority bits, Layer 2)
    • DSCP Override of Voice and Media DSCP (DiffServ Code Point, Layer 3)

Recommended Scenarios

  • LLDP on the IP Phone is recommended where the data network is using LLDP or ADAC. If LLDP or ADAC are not enabled on the data network, then LLDP should be disabled on the phone to speed the IP Phone boot process.
  • ADAC is recommended on data networks where security is critical, or where the size of the voice network creates a requirement to distribute the boot-provisioning-registration load.
  • LLDP-MED on the data network is recommended to speed the boot procedure where Voice VLAN, pBits and DSCP values are currently configured via DHCP or TFTP (i.e., “Manual Provisioning”) and/or where security is critical.

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.)

ADAC

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):

  • Untagged-Frames-Basic – Used when the IP phones are sending untagged traffic.
  • Untagged-Frames-Advanced – Used when the IP Phones are sending untagged traffic.
  • Tagged Frames – Used when the IP Phones are sending tagged traffic.

Detection Modes configured on each port (one or both must be assigned to each port to enable ADAC for that port):

  • MAC address
  • Link Layer Discovery Protocol, or LLDP (IEEE 802.1ab)

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:

  • op-mode untagged-frames-basic or op-mode untagged-frames-advanced, at least one IP phone is detected on the port and no non-IP phones are detected on the port.
  • op-mode tagged frames, and at least one IP phone is detected on the port.

ADAC is removed if any of these conditions become true:

  • Auto-detect becomes disabled on the port.
  • The ports operational state becomes disabled.
  • op-mode untagged-frames-basic or op-mode untagged-frames-advanced, and at least one non-IP phone device is detected on the port.
  • There are no IP Phones detected on the port and the link is down.
  • If the link is still up but there are no IP phones on the port, auto-configuration is disabled after an aging period of about 90 seconds.
  • If all MAC addresses belonging to Nortel IP Phones on a port age out, the auto-configuration settings are removed from the port.
WARNING
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.

Jan 232012
 

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:

  1. NVRAM (non-volatile RA) is loaded, including the local configuration information. Any configuration options set to manual on the phone will overwrite automatic configuration information received.
    NOTE
    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.

     

  2. Phone then boots and determines if data switch provides LLDP or ADAC. This setting can be disabled manually, via DHCP or via manual provisioning. Unless this is disabled manually, the phone will always check LLDP/ADAC when it first boots.
    NOTE
    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.

     

  3. The phone then requests DHCP. If DHCP is available it processes the DHCP information.
  4. If a provisioning server is provided via DHCP Option 66, DHCP or manually configured on the IP Phone, then the the IP Phone requests the system.prv and <TYPE>.cfg from the HTTP or TFTP servers. While there is a lot more available under manual provisioning than just firmware upgrades (and while I will be writing an article to cover those topics later), I have only written the manual firmware upgrade article.
  5. Then the phone attempts to contact the S1 and S2 (primary signaling server and failover signaling server). If the phone cannot make a connection to the signaling server (or that information isn’t provided via any of the configuration methods available: manual, DHCP or provisioning server) then the Phone reboots and tries again.
  6. If a connection is made to either the primary or failover signaling server, then the phone will register and proceed with attempting to connect to External Application Servers (XAS) such as the Application Server 1000. A lot of the functionality that was originally relegated to an External Server (screen savers, backgrounds, some directory functions) have been incorporated in to the base firmware/functionality of the IP Phones. Others still require an XAS. For more information on this, contact an authorized Avaya distributor.

The only information that is critical to an IP phone for the boot process is:

  1. Set IP address, subnet mask and gateway
  2. Primary signaling server (S1) IP address, Port, Action and Retry values
  3. Node and TN

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.)

Jan 212012
 

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.)

Jan 212012
 

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.

  1. Writer’s Acronyms: i.e. and e.g.
  2. How to reset a Nortel IP phones to factory default

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.

 

Jan 202012
 

There are several reasons why you might want to enable manual provisioning of your Avaya IP Phones:

  1. Branch office scenarios, where you want to reduce bandwidth requirements for provisioning or firmware distribution.
  2. Large site scenarios, where you want to offload provisioning from the DHCP server or offload firmware distribution from the signaling server.
  3. Secure environment scenarios, where phone security is paramount and phones should not allow themselves to be reconfigured.
  4. Any scenario where a signaling server is not available, such as a home office scenario or staging warehouse scenario. This includes scenarios where you want to load VPN client licensing on to the IP phone to allow it to be deployed remotely (e.g., a home office.)

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:

  1. DEVICE (e.g., <MAC>.prv, or, 001365FEF4D4.prv)
  2. TYPE (e.g., <TYPE>.prv, or, 1140E.prv)
  3. ZONE (e.g., headqrtr.prv)
  4. SYSTEM (e.g., system.prv)

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.

  1. TYPE (e.g., <TYPE>.cfg, or, 1140E.cfg)

The Configuration file can contain a lot of information:

  1. [FW] Set Firmware
  2. [GEM FW] Expansion Module Firmware
  3. [USER_KEYS] User keys
  4. [DEVICE_CONFIG] Device configuration
  5. [IMAGES] Backgrounds and screensavers
  6. [FONTxx] Custom fonts
  7. [LANGUAGE] Language (associated with customized fonts)
  8. [LICENSING] Feature licensing
  9. [DIALING_PLAN] Dialing plan (SIP only?)

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
PROTOCOL TFTP Download protocol. Must be TFTP Documentation for CS1000 7.5 says that this must be TFTP, but the sample CFG files available from AVAYA show that HTTP is supported. Further testing is recommended.
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:

NOTE
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.
  1. DHCP Option 66 – TFTP/HTTP Server Name
  2. DHCP Option Nortel-i2004-B specification
  3. Manually configuring the Provisioning Server on the IP phone.

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.

Addendum:

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