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