Dec 282013
 

I like building applications, and these days that means web applications. The challenge is enjoyable. During my vacation this year I decided to spend some time expanding some code that I’ve been working on over the years. In this case, a tool that runs on my PC that integrates with a database. Previously, I tended towards integrating with a local DB, be it via ODBC, a local text or Excel file, etc. This year I’m setting myself the challenge of integrating with a MySQL database over HTML.

The reason for this is because there is a substantial amount of information in my company’s online database (hosted by NetSuite), but getting access to it for any kind of automation can be tricky. However, it can be done if you’re willing to invest the development time to building an application (both sides of one). But, such a task is not something I’ve ever done before. So I’m combining a hobby and self improvement with the intention of building skills which may be useful at some point in the future at work.

As an example, an application which retrieves system information and helps organize and launch system connections (http, ssh, rdc) is a lot more portable if it retrieves the system information from a central database than something which requires all of the system information to be stored locally. If someone updates the system information and you don’t notice it, it means you could be attempting to connect to the wrong IP or server name. By automating the information retrieval you can save minutes (or over a calendar year, save hours or even days) worth of lookup time.

There are plenty of other uses, such as pulling information from a system, parsing it and then pushing it to a MySQL database directly, and then allowing that information to be displayed in an HTML format. Log parsing, etc., could be streamlined. Even, in one case, parsing the Microsoft hotfixes applied to servers and scrubbing it against a database for which hotfixes have been tested/approved by the manufacturer, would be a great application for my environment. Avaya already has something like that for the CS1000 that was created by the engineers back in the Nortel days. But they don’t have anything like that for the Avaya Aura Contact Center product line, even though they have the audit tool that would be necessary to implement the first half of that endeavor.

While tooling around with the XMLHTTP GET/POST integration for the client tool, I ran into an error on my website that was generated by Mod_Security. “An appropriate representation of the requested resource could not be found on this server. This error was generated by Mod_Security.

Upon further investigation, I managed to capture an error log out of the shared error log on my web host “ModSecurity: Access denied with code 406 (phase 2). Match of “rx ^0$” against “REQUEST_HEADERS:Content-Length” required. [file “/etc/httpd/modsecurity.d/10_asl_rules.conf”] [line “101”] [id “392301”] [rev “5”] [msg “Request Containing Content, but Missing Content-Type header”] [severity “NOTICE”]

The rest of the error is largely environment specific, so I’m omitting that info, but if you’ve run into this error yourself, you know what it looks like.

Here’s what I learned in my search (I’m effectively building a custom browser using Microsoft XMLHTTP— the mechanism isn’t too important, be it Power Shell, vbscript or jscript)

  1. Must declare RequestHeader User-Agent
  2. Must declare RequestHeader Content-Type
  3. For POST, must declare RequestHeader Content-Length

These are not mandatory for all HTML interactions, but some security configurations may require certain headers in order to process an XMLHTTP request. In the case of my web server (shared webhosting) and my custom browser application, for a GET request only the User-Agent and Content-Type were required. However, Mod_Security was configured on the shared webhost to mandate Content-Length.

What triggered this research and error was a typo in my code.

The typo came down to a bad choice in variable declaration. In a foreach ( item in array ) statement, I poorly chose the variables to be foreach ( item in items ) and, I’m sure you can see the typo risk already, I accidentally typed foreach ( item in item ). As such, the foreach loop did not properly iterate over the array… and since the foreach loop set the RequestHeaders, the request headers were not being set. Thus, the mod_security error.

I didn’t catch the typo initially, as the first error message was mostly meaningless and I couldn’t immediately determine the cause. Still, I saw a number of articles (including some wordpress blog support requests for this error, with some fixes involving changing the behavior of Mod_Security). While the Mod_Security error isn’t very meaningful, if you dig into the error_logs deep enough, you’ll find the error message which will lead you to the root cause of the problem. In my case, an HTTP 406 indicating that “Rquest Containing Content, but Missing Content-Type header.”

Once I found the typo in the code and fixed it, the XMLHTTP request worked perfectly (except that mod_security was also configured to require a content-length request header on POST requests, but once I’d fixed the one problem the other was easily to identify and fix.)

Nov 122013
 

Issue:

  • Ports, Cards or entire Shelves disable during midnight routine.
  • NWS messages generate during midnight routine
% NWS301 8 0 : -1 -2 -3 -4 -5 -6
%
% NWS101 1 : 24
%
% NWS211 24 : 0 1

Environment:

  • Avaya CS1000, all releases
  • Nortel Meridian-1, all releases
  • Digital phones only

Cause:

  • Cabling issues and/or unplugged phones cause “continuity test” failures during midnight routines.
  • After sufficient number of port-based continuity tests fail a card reports a failure
  • After sufficient number of card-based continuity tests report failures the shelf reports a failure

Solution:

  • If a phone is removed from the jack, restore or de-program
  • If a phone cabling issue exists, fix

Comments:

  • I saw this for the first time when I was working for HellerEhrman. The site’s telecom tech would deploy phones where needed, moving phones from existing workspaces to new workspaces and document in a personal document all unused terminal numbers (TNs) for later re-use but did not de-program them. This was “speedier” for them than removing & reprogramming TNs. Doing this allowed them to save the time of programming the entire TN, they just plugged a new phone in, re-enabled the port, changed the DN and they were good.
  • However, users began reporting phones were disabling during midnight routine and had to be manually re-enabled next business morning.
  • Issue escalated to me (Firm-wide Telecom team).
  • I’d never seen this particular issue before and did not know root cause.
  • I performed routine troubleshooting and recommended several corrective actions, including routine maintenance (cleaning up TNs, etc.) but having no authority over the site tech (not being able to force them to do the recommended work and I did not know that the absence of routine maintenance was the proximate cause) I was told to escalate to Nortel (via our Service Provider).
  • Service provider had not seen it before and escalated to Nortel
  • Nortel indicated performance of routine maintenance. i.e., clean up all programmed TNs that were not going to be put back into service or reconnect a phone to any TN that needed to remain.
  • Issue resolved.

I’ve seen a couple of these tickets recently at my place of employment. So far each one appears to be the same cause/solution. I’ll post a comment later if I learn anything new.

Nov 072013
 

Issue

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

Environment

Avaya CS1000

UNIStim 5.0 or earlier

Avaya IP Phone 1100, Avaya IP Phone 1200

Cause

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.

Source: http://downloads.avaya.com/css/P8/documents/100152833

Solution

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.

UNIStim 5.5.1 (C8T) released in Aug 2013.

I updated my Google drive table of UNIStim firmware releases.

 

Nov 062013
 

Microsoft– MSTSC /console deprecated, and replaced by MSTSC /admin for Windows XP SP3, Windows Vista SP1, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2. However, MSTSC /admin is no longer applicable to Windows Server 2008 environments (such as AACC). http://support.microsoft.com/kb/947723

The KB is from 2008. I occasionally find myself looking for the article, so that’s why I’m posting it here.

Nov 032013
 

Recently worked on an AACC (Avaya Aura Contact Center) where the partitioning of the server was determined to be the cause of the problem. While Disk Management (diskmgmt.msc) is easily accessible from START>>RUN, a screenshot is not quite as portable as text. To that end (and as a recommendation for addition to the Nortel Enterprise Audit Tool, or NEAT, used to survey Contact Center servers for Avaya engineering), I put together a script to query WMI (Windows Management Instrumentation) for the necessary information.

WMI Objects:

  • Win32_DiskDrive
  • Win32_DiskDriveToDiskPartition
  • Win32_DiskPartition
  • Win32_LogicalDiskToPartition

Using WMI queries against these objects you can derive:

  • Win32_DiskDrive => Physical Device ID (.\\.\PHYSICALDRIVE0\)
  • Win32_DiskPartition => Partition Device ID (Disk #0, Partition #1) and a derived type (e.g., Simple Volume? Primary Partition? Extended Partition/Logical Drive?)
  • Win32_LogicalDiskToPartition => Logical Drive Device ID (D:)

For quick “automated” checks of a system to verify compliance with engineering guidelines, this is a must.

Sample output:

\\.\PHYSICALDRIVE0,Disk #0, Partition #2,Basic,True,C:,Primary Partition
\\.\PHYSICALDRIVE0,Disk #0, Partition #3,Basic,False,D:,Extended Partition/Logical Drives
\\.\PHYSICALDRIVE0,Disk #0, Partition #3,Basic,False,F:,Extended Partition/Logical Drives
\\.\PHYSICALDRIVE0,Disk #0, Partition #3,Basic,False,G:,Extended Partition/Logical Drives
\\.\PHYSICALDRIVE0,Disk #0, Partition #3,Basic,False,T:,Extended Partition/Logical Drives

and

\\.\PHYSICALDRIVE0,Disk #0, Partition #2,Dynamic,True,C:,Simple Volume?
 \\.\PHYSICALDRIVE0,Disk #0, Partition #3,Dynamic,True,D:,Simple Volume?
 \\.\PHYSICALDRIVE0,Disk #0, Partition #3,Dynamic,True,F:,Simple Volume?
 \\.\PHYSICALDRIVE0,Disk #0, Partition #3,Dynamic,True,G:,Simple Volume?

The cool thing is that the script is applicable for all systems going back to Windows 2000 (Symposium 4 if I recall correctly) when the WMI query objects were instantiated in the OS by Microsoft.

Oct 282013
 

One of the things that I find useful to understand when building tools on an existing framework is where the hooks are for scripting. I’ve been doing a lot of scripting over the last two years to optimize my company’s NetSuite deployment. A short list of some of the things that I’ve worked on include:

  • Time Entry Automation improvements
    • auto-format memos on time entries with date, ticket/project/task, and the event subject
    • Validation on Service Item, Payroll Item, Class– certain combinations are verboten but must be restricted via scripting as there is no built-in validation
    • Auto-complete Service Item, Payroll Item, Class– certain combinations are only allowed to be entered a certain way
  • Ticket validation improvements
    • Tickets are changed from New to In Progress when Engineer assigned
    • Repair tickets not allowed for T&M customers
    • Mandate entry of certain information when the ticket type is a certain value
    • Prevent internal tickets from CCing to customer contacts
  • Customer validation improvements
    • Validation on lots of fields including verifying that IP addresses and subnet mask info entered is valid for IPv4 format. Validate that DNS addresses follow the public standard. Auto-name records to reduce data entry. etc.
    • Enforce entry of critical information on new records (no half-creating a record allowed– sublist fields can’t be marked as mandatory except via scripting.)
  • Project validation improvements
    • Ensure certain roles are exempt from mandatory field requirement (conditionally required field based on role of person editing/creating the record)
  • Solutions validation improvements
    • Pre-formatting the Abstract and Details via custom button

When working on all of these, it’s important to understand the best place to hook the action into.

  • Do you want to prevent a user from entering certain values or values outside of the accepted format? Use validateField.
  • After changing a field value and post sourcing occurs (i.e., updating the customer on a ticket causes the contact to be cleared), do you want to ensure the original field value is restored (if possible)? Use postSourcing (note: in some cases, the parent value might prevent use of the child value because the child value is not an acceptable value under the new parent.)
  • Do you want to prevent a user from inserting new sublist (time entry) records to a closed event? Use validateLine within the parent event, use onSave from the Time Entry form.

 

Here’s the diagram that I’ve been keeping in my head (because NetSuite doesn’t supply one). I thought other NetSuite admins/consultants/programmers might find it handy.

 

 

I welcome comments, questions and feedback. I don’t normally post NetSuite or scripting related stuff to my blog as my primary role is not a coding role (even though I enjoy it on a limited basis. I prefer to use coding/scripting to enhance my primary job function, rather than my primary function being to code.)

Sep 262013
 

A co-worker was recently tasked with providing cross training for a product which I do not have much experience with on the topic of T1 troubleshooting and alarm clearing. After getting this class, I decided it would be fun to put together something similar (in blog format) for CS1000 T1 alarm clearing.

Receiving an alarm

There are a variety of PRI alarms, but we’ll take one of them as an example:

DTA021 [loop]

Interpreting the alarm

Some systems have part of the alarm lookup database on-system which can be accessed via the Overlay Loader (OVL000 and a > prompt) using the ERR command

>ERR DTA021

If the alarm library is loaded with that alarm, then you’ll get the help text. If not, you’ll get an error:

OVL441 Help text not found for error code: [code]

All alarms in the documentation are in 4 digit length after the 3 letter alarm group code. DTA are digital trunking alarm. 021 is the specific alarm. Finding it in the documentation can be done by searching for DTA0021. From the documentation we get the alarm text:

Frame alignment alarm persisted for 3 seconds

Responding to the alarm

Let’s talk briefly about some of the different tools available for troubleshooting:

  • LD 60 / Digital Trunk Interface and Primary Rate Interface Diagnostics
  • LD 96 / D-channel Diagnostics
  • LD 20 / Print Routine 1 – Use to identify a trunk’s association with a Route Datablock (RDB).
  • LD 21 / Print Routine 2 – Used to list trunk members to determine trunk group associations between PRIs/DTIs.
  • LD 22 / Print Routine 3 – Used to print common equipment (CEQU) and D-channel configuration (ADAN DCH)
  • LD 73 / Digital Trunk Interface – Used to check clocking (DDB)

Digital Trunk Interface and Primary Rate Interface Diagnostics

DTI and PRI diagnostics (LD 60) cover a variety of tasks, you can: enable/disable loops, clocking, individual bearer channels (B-channels or BCH) and print/clear counters.  For a full list of commands, see the Software Input/Output Reference – Maintenance (NN43001-711).

Commands:

STAT
STAT [loop]
STAT [loop channel]
Show status of all loops or loop specified. Loop status include loop state and BCH state.
LCNT
LCNT [loop]
List counters
RCNT
RCNT [loop]
Reset counters
SSCK [core]
SSCK [loop shelf]
Show system clock. Includes which circuit is being used for primary clocking and clock state.
SWCK Swap clock from current active to current standby
TRCK [Source] Set clock controller tracking to PCK/Primary Clock, SCK/Secondary Clock, FRUN/Free run-no clock.
ENLL [loop] Enable loop
ENCH [loop channel] Enable B-channel
DISL [loop] Disable loop
DISI [loop] Disable loop when idle. Disables any IDLE channel then waits till other channels are disabled. Loops until all B-channels are disabled then disables loop.
DSCH [loop channel] Disable B-channel

D-channel Diagnostics

DCH Diagnostics covers: enable/disable d-channels, d-channel monitors, and work with MSDL or TMDI cards. On larger legacy 1000M systems, the Multipurpose Serial Data Link (MSDL) card is used to provide D-channel functionality. On smaller 1000M systems and newer 1000E systems, the D-channel functionality is built into the TMDI (T1 Multipurpose Digital Interface) card. In this article, we will not be discussing troubleshooting D-channel diagnostics for MSDL cards on larger 1000M systems.

Commands:

STAT DCH
STAT DCH [dch]
Show status of all/specific DCH.
ENL DCH [dch] Enable DCH
DIS DCH [dch] Disable DCH
STAT TMDI [card] Show status of TMDI. (CS1000M small system)
STAT TMDI [loop shelf card] Show status of TMDI. (CS1000E)
DIS TMDI [card] Disable TMDI. (CS1000M small system)
DIS TMDI [loop shelf card] Disable TMDI. (CS1000E)
SLFT TMDI [card] Selftest TMDI. (CS1000M small system) Performs multiple hardware tests to verify TMDI is functional.
SLFT TMDI [loop shelf card] Selftest TMDI. (CS1000E) Performs multiple hardware tests to verify TMDI is functional.
ENL TMDI [card [fdl]] Enable TMDI. (CS1000M small system) Optional FDL/Full Download of TMDI EPROM.
ENL TMDI [loop shelf card [fdl]] Enable TMDI. (CS1000E) Optional FDL/Full Download of TMDI EPROM.
PLOG DCH [dch]

Print Routine 1

The command architecture for the CS1000 is built on the older Meridian-1 systems, which in turn is built upon the even older SL-1 systems. When the SL-1 hardware architecture was replaced or improved, Nortel introduced new commands or Overlays as needed, all while keeping the essential command structure introduced with the first SL-1 system in the mid-1970s.

Print Routine 1 covers peripheral programming, including the bearer channel (BCH) configuration for a T1. From the Terminal Number configuration of a BCH, it is possible to identify the route membership for a particular channel, and by extension the T1. (While it is technically possible to configure different channels within a T1 to belong to multiple routes, I’ve never seen this and excepting MUXed circuits I am not aware of any reason why it might be done.)

Print Routine 2

Print Routine 2 covers customer datablock configurations, including route datablock (RDB) settings. By using the List Trunk Members command, it is possible to identify all of the BCH (and by extension all the T1s) that belong to a particular route (i.e., trunk group).

Print Routine 3

Print Routine 3 covers hardware and system configuration data, such as the Common Equipment (CEQU) datablock and Action Device and Number (ADAN) datablock, the latter of which is used to store information about D-channel configuration.

Digital Trunk Interface

When building a PRI/DTI in a CS1000 system for the first time, the Clock Controller and Alarm Threshold values must be set. For systems in the USA, the DDB (digital data block) configuration record contains the relevant configuration settings.

Diagnostics vs Print Routines & configuration

LD 60 and 96 are used primarily for diagnostics. Overlays 20-22 and 73 would be used to configuration review to assist with diagnostics. For the purposes of this article, we will assume that a configuration issue is not at fault. Perhaps in some future article I might cover PRI configuration in more detail.

References

NN43001-611 Software Input/Output Reference – Administration

NN43001-711 Software Input/Output Reference – Maintenance

NN43001-712 Software Input/Output Reference – System Messages

NN43001-301 ISDN Primary Rate Interface Installation and Commissioning

Sep 192013
 

Tagged & Unregistered Frame Diagram

Recently found myself troubleshooting Untagged and Unregistered frame filtering on an Avaya Ethernet Routing Switch. This is a quick tutorial for future discussions with other engineers about how filtering works on an Avaya Ethernet Switch.

A quick description of tagged vs registered:

  • A tagged frame is a frame which has an 802.1q VLAN ID tag on the packet.
  • A registered frame is a frame which has an 802.1q VLAN ID tag on the packet that matches the VLAN MEMBERS configuration on the port.

In the above diagram, if the packet egressing from the first data switch is tagged with VLAN 10 (PVID or Primary VLAN ID 10), then the packet is both tagged and registered when it ingresses on the second data switch. However, if the packet is tagged with VLAN 20, the packet is tagged but unregistered when it ingresses on the second data switch.

Use of untagged filtering or unregistered filtering is for environments where the administrator wishes to protect against mistakes in recabling network devices or vlan configuration mistakes. One of the historical issues that has happened in the past with Nortel Ethernet Routing Switches is that if an unregistered frame is received and the receiving data switch does not know what to do with it, it may divert the packet to VLAN 1 (the default VLAN ID on all data switches). This can result in accidental broadcasts of extraneous packets.

A few examples of network changes that might result in problems:

  • Accidentally connecting a server to the second data switch trunk port– the server packets are filtered by filter-untagged-frame enable.
  • Accidentally connecting a different data switch to the second data switch trunk port– if the vlan membership and PVID settings are different, the server packets can be filtered by filter-untagged-frame or filter-unregistered frame.
  • The first data switch is factory reset or the trunk port is configured with VLAN membership that need not be extended to the second data switch– if the 802.1q VLAN ID on the packet is not one of the VLAN member IDs on the ingress port, then the packet will be filtered by filter-unregistered-frame. If the first data switch port is configured as a non-trunk port (any other tagging configuration: tagging untagpvidonly, tagging untagall, tagging tagpvidonly) and the packet is untagged and sent to the second data switch, then the filter-untagged-frame setting may cause the packet to be filtered on ingress.

Michael McNamara posted an article back in 2007 discussing an issue with Avaya IP Phones where filter-unregistered-frame enable caused problems with IP Phone registration. The relevant excerpt is as follows:

The option (vlan ports 1-46 filter-unregistered-frames disable) was added after an issue was discovered when trying to upgrade the firmware on the IP phones. The filter-unregistered-frames is enabled by default and should be disabled to avoid and issues with upgrading the firmware on the IP phones. We are attempting to investigate further with Nortel and our voice vendor…

Take away:

  • The way I read the documentation, and I haven’t had a lot of opportunity to thoroughly test this, filtering is ingress only. This means you’re consuming bandwidth with improper egress port configuration. Depending on your environment, this wasted bandwidth might be minor or major.
  • Use of VLAN ID is strongly frowned upon in a multiple VLAN environment. Don’t assign PVID 1 or VLAN ID to any ports (i.e., remove VLAN 1 from all ports, because VLAN ID 1 is on everything in factory default configurations.) If you’re not doing any VLANing or any Layer 3 routing (i.e., simply Layer 2 switching only), then VLAN ID 1 is fine– but as soon as you start tagging packets on that switch you should stop using VLAN ID 1.
  • Filtering is best used on trunk ports to prevent broadcast storms or extraneous packets from being broadcast into a data switch (and the impact of extraneous packets from diverted unregistered frames is minimized if you do not use VLAN ID 1.)

What to do with this information:

  • Review all ports for VLAN membership or PVID of 1– if found and if you are a multi-VLAN environment, convert VLAN ID 1 to another VLAN ID on all ports then remove VLAN ID 1 from all ports (including PVID 1).
  • Review all ports set with tagging tagAll (including multi-link trunk (MLT) ports)
    • Compare VLAN membership and PVID settings on each side of a trunk connection.
    • Make sure VLAN membership matches on both sides.
    • Make sure the PVID ID on each side is a VLAN member on the opposite side.
    • Make sure the PVIDs match on both sides (I can’t think of any valid design reasons why PVIDs might not match.)
  • Review all trunk ports (tagging tagAll) and set filter-untagged-frame enable
  • Review all trunk ports (tagging tagAll) and set filter-unregistered-frame enable
  • Review all non-trunk ports (access ports) and set filter-untagged-frame and filter-unregistered-frame based on the network design
    • Note: If the port will not be receiving 802.1q tagged packets on ingress, then filter-untagged-frame and filter-unregistered-frame should be disabled.

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.