Avaya IP phones, registration procedure overview

 Nortel, PBX, Telecom, VoIP, Work  No Responses »
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.)

 Posted by John Williams at 7:56 pm  Tagged with: , , , , , , , , , , , , , , , , , , , , ,

Nortel/Avaya UNIStim Table

 Nortel, PBX, Telecom, VoIP, Work  No Responses »
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.)

 Posted by John Williams at 1:10 pm  Tagged with: , , , , , ,

Google Analytics, the focus of this blog

 Nortel, PBX, Personal, VoIP, Writing  No Responses »
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.

 

 Posted by John Williams at 12:18 pm  Tagged with: , , , , , , , ,

Upgrade Avaya IP Phones Manually

 Nortel, PBX, Telecom, VoIP  1 Response »
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

 Posted by John Williams at 7:23 pm  Tagged with: , , , , , , , , ,

Avaya CS1000 QOS Notifications

 Nortel, PBX, Telecom, VoIP, Work  No Responses »
Jan 202012
 

When troubleshooting QOS issues (including dropped calls, one way talk path, etc.) on an Avaya CS1000, sometimes it’s helpful to look at all of the alarms (even the unnacceptable or warning alarms) on a per-call basis. This gives you an idea of when there are problems in an entire zone vs individual users within the zone, or zone-wide and ongoing versus intermittant and individualized alarming.

LD 117
CHG ZQNL <zone> <notification_level>

Level = 0-(2)-4, where:

Level 0 = All voice quality alarms are suppressed.

Level 1 = All zone based Unacceptable alarms.

% QOS019 QoS unacceptable packet loss: [42.3] % in zone [1]

Level 2 = Allow all level 1 alarms PLUS zone based Warning alarms.

% QOS013 QoS warning jitter:[30.6] % in zone [1]
% QOS015 QoS warning R factor:[43.0] % in zone [1]

Level 3 = Allow all level 1 and 2 alarms PLUS per call Unacceptable alarms.

% QOS007 Unac pkt loss:[PL:8.2 LT:0 JIT:0 R:75]
%   Near [192.168.16.23:5000],TN[067 16],NZ[0:1]
%   Far [10.1.152.121:5200] TN[063 23], VPNI:Zone[0:1]

Level 4 = Allow all level 1, 2, and 3 alarms PLUS per call Warning alarms

% QOS001 Warning packet loss:[4.3 %]
%   Near [192.168.16.23:5000] TN[067 16],NZ[0:1]
%   Far [10.1.152.121:5200] TN[063 23], VPNI:Zone[0:1]

% QOS002 Warning latency :[50 ms]
%   Near [10.1.152.121:5000] TN[063 23],NZ[0:1]
%   Far [192.168.16.23:5200] TN[067 16], VPNI:Zone[0:1]

% QOS003 Warning jitter :[20 ms]
%   Near [10.1.152.25:5000],TN[064 22],NZ[0:1]
%   Far [10.1.112.28:5200] TN[067 18], VPNI:Zone[0:1]

% QOS005 Warning R factor:[75]
%   Near [192.168.16.23:5000],TN[067 16],NZ[0:1]
%   Far [10.1.152.121:5200] TN[063 23], VPNI:Zone[0:1]

 Posted by John Williams at 9:48 am  Tagged with: , , , , ,

Project Diary: Xtools (9)

 Nortel, WebDev  2 Responses »
Nov 232008
 

I’ve not made any updates lately because I’ve been learning AJAX coding techniques and I’ve been working instead on the hotfix parser.  AJAX has a lot debate on what exactly it is (which is weird), but the definition used in the book that I’m reading (and on Wikipedia) is that it is essentially a client-side programming technique that permits the website designer to asynchronously load content from the website to the client browser.

This means more streamlined content display experiences than you would normally experience from a traditional webpage.  An example would be Yahoo or Google Maps.  Both use AJAX techniques to load map data without refreshing the entire page.

The purpose of this education is the realization that I load a significant amount of page overhead (a wrapper, if you will) around the DNB data and that I could improve the load speed if I could convert the page to an AJAX enabled app (allowing me to load content in to the browser and then “page” between it without refreshing the page.)

I figure that approximately 15-20% of my page is overhead (CSS stylesheet, template information, navigation, images, etc.)  Cutting that data transfer out of each page change would be a pretty dramatic increase in my page efficiency (and make it more user friendly).

Granted, AJAX breaks the traditional BACK BUTTON functionality that we come to expect from our web browsers, but I think that’s a small price to pay.

Additionally, the hotfix parser has become much more appealing to me as a next project than the ESN parser.  I’ve been doing a lot of Microsoft hotfix patch checking on a few customer’s Contact Center and CallPilot servers at work, and this effort would have been dramatically more efficient if I had this parser.

I’ve completed the client-side VBScript that will capture all of the data that I require.  I’ve determined that Windows Installer is required to collect information about what programs are installed on a Server (not critical, but useful information) and even determined how to gracefully handle Windows Installer being missing (thus, preventing the collection of the Programs Installed info.)

Next is to start building the database tables and work on the server-side parser.

 Posted by John Williams at 7:00 am  Tagged with:

Project Diary: Xtools (8)

 Nortel, WebDev  No Responses »
Oct 232008
 

Brought the 0.10.2 revision over to the production site as it fixes a number of critical bugs.  I’m still working on 0.11.0, which begins the implementation of the ESN parser.  All database tables have been generated and the upgrade code has been written in to the core plugin code so that when it’s moved over to the production site, it’ll be automatically upgraded to the latest/greatest.

 Posted by John Williams at 6:00 pm

Project Diary: Xtools (7)

 Nortel, WebDev  No Responses »
Oct 192008
 
  1. Revised all Xtools templates to continue to output the content of the page from WordPress (for notes/comments/documentation links/etc).
  2. Documented known bugs in a publically accessible format (in preparation for adding more beta testers)
    1. DNB Parsing, Best Practices
    2. DNB Types [static list]
  3. Documented best practices in a publically accessible format (same as above)
  4. Continued work on ESN parser & templates

 Posted by John Williams at 3:12 pm

Project Diary: Xtools (6)

 Nortel, WebDev  No Responses »
Oct 162008
 

Resolved all outstanding bugs from v0.10.0 (frankly, I’m embarressed to discover how many critical bugs there were in this release… but they’re all fixed now.) and began working on implementing the new parser.  The next one will be a alternate route selection parser.  NARS/BARS/CDP etc.

All my programming time has diminished my attentiveness to building the ARS 101 tutorial that was my original SEP goal, but I think it’s a fair trade.

Finally finished building the SQL entries and rough sketching out how I wanted to fit all of the pieces of the ESN database together.  This kind of development work is really good for helping me think carefully about how Nortel must have programmed their database (certainly the execution code that utilizes the database is another story all together.)

I also discovered that in the 10+ years I’ve been working on Nortel phone systems, I’ve never once run across a Private Line appearance.  It has it’s own unique entry in a PRT DNB which I had never encountered before this last week.  Added that to the dnbParser and fixed a couple of minor bugs in the dnbParser.

I added a few improvements to the dnbPrint template, but I’m getting kind of antsy to move on to the ESN piece of the toolset so I’m going to take a break from DNB features and work on migrating the esn parsing code from ASPECT to PHP.

You can see the latest roadmap status by visiting: http://datarave.net/bt/roadmap_page.php

I’m thinking about replicating 0.11.1 to the production environment because of all of the problems with 0.10.0.  I’ll spend more time thinking about it later, after I’ve had a good nights sleep.

 Posted by John Williams at 11:35 pm

Project Diary: Xtools (5)

 Nortel, WebDev  No Responses »
Oct 012008
 

Tasks completed:

  • Normal users will only have access to their own customer
    • Ability to add users to a customer record who can also access that information will be added in a subsequent revision
  • Normal users can now add a new customer, associated with their user record
  • Normal users can now add an unlimited number of sites associated only with their customer record
    • Ability to delete sites will be added in a subsequent revision
  • Normal users can now only upload batch information for their associated customer
  • Normal users can now only display batch information for their associated customer
  • Customer and Site management templates are much more modular in design than batchUpload and dnbPrint templates.  Batch and DNB templates will be updated to follow the modular design of the customer and site management templates in a subsequent revision.

Before I can make the dnbParser available on the production site, I have to finish re-writing a piece of the code that deals with file uploads (files are uploaded to a non-public space to prevent users from uploading dangerous content and then attempting to run it via a web browser) to separate the production and development directories used for file uploads (currently, the directories are hardcoded…  but I have to make them variable so that I can completely separate the production and dev content.)

 Posted by John Williams at 10:09 pm
 Older Entries

Favorite Books

Favorite Music

© 2011 Undecided Suffusion theme by Sayontan Sinha