I am a very curious person. In fact, my mom tells me that the first word from my mouth was not “mama,” but “why.” I am not the type that accepts something without asking a number of probing questions. “Where did you hear that?” “Do you have any supporting documentation?” “Is that a reliable source?” Needless to say, my grade school and high school teachers probably sighed every time I raised my hand in class.
This sense of curiosity and need to verify are still with me today. I double, triple, and quadruple check a so-called fact until I am convinced of it. Even then, I am always on the lookout for information that might sway me one way or the other. I can’t even begin to count the number of times when I was convinced that I was right only to find new data that forces me to question my conclusion.
At this point you may be wondering what all this has to do with unified communications. Stick around and I will tell you.
I have been working with Avaya SIP telephones for a number of years and was certain that I knew exactly what was occurring when one booted up. However, I recently came across a couple of documents that caused me to rethink that. It’s not that I was way off base, but I found a number of places where things worked a little differently than what I previously understood — different enough to make me want to write the steps down for posterity.
Warning: This is pretty nerdy stuff and not for the faint of heart. I applaud anyone who is as curious as I am about SIP in the detail I am about to present.
At a high level, the boot sequence for an Avaya 9600-series SIP phone is as follows:
1: Power on and initialize hardware and software.
2: Set the LAN speed and begin talking to DHCP in order to acquire IP addresses for the phone and and HTTP configuration server. If the HTTP server’s IP address is not set in DHCP option 242, it may be manually configured on the phone.
3: If present on the network, initiate Link Layer Discovery Protocol (LLDP). Among other things, LLDP allows the SIP phone to determine the virtual LAN (VLAN) used for voice traffic.
4: Using the HTTP server, request the 96x1Supgrade.txt file. This file will indicate if it is necessary to download new SIP firmware.
5: Using the HTTP server, request the 46xxsettings.txt file. This file contains information that an Avaya SIP phone needs to properly function. The phone obtains its domain name, Network Time Protocol server, time zone, DiffServe Code Point, speaker phone settings, and other such values from the 46xxsettings.txt file. This file is used in both Avaya and non-Avaya environments. Used with non-Avaya systems, the file contains information that would otherwise be downloaded via the Avaya Personal Profile Manager. Examples of such data includes the addresses of the Message Waiting and Music-on-Hold servers.
6: Using the HTTP server, retrieve language files. For example, Mlf_Hebrew.xml allows the phone to display prompts and text in Hebrew.
7: Using the HTTP server, retrieve the Avaya Menu Admin file. This file contains links for useful web content. For example, help desk for phone issues, news, ESPN news, etc. can be set in the Menu Admin file.
8: Contact the Network Time Protocol (NTP) server to synchronize time-of-day.
9: Within the 46xxsettings file is the value, SIP_CONTROLLER_LIST. This value provides the IP addresses and transport types (UDP, TCP, or TLS) for the Session Managers this phone has been assigned to. The phone sends SIP REGISTER request messages to all Session Managers in the list. This allows the phone to be simultaneously registered to more than one Session Manager at a time. Avaya phones support three SIP registrations – two core Session Managers and one Survivable Remote Session Manager (i.e. LSP).
These registrations will most likely be challenged with “401 Unauthorized” response messages. The phone will then resend the registrations with the user’s encrypted password.
To read more about SIP authentication, please see my blog, Proving it With SIP Authentication.
The REGISTER request contains a lot of valuable information. In addition to the duration of the registration, the phone will announce its model number, serial number, firmware release, and if this registration is for the primary or backup session manager.
10: Next, the phone will send out a series of SIP SUBSCRIBE messages. Known as event packages, the phone will subscribe to the following:
- “phone features” such as send all calls, call-fwd, etc.
- used for reloading configuration, button changes, contact changes, etc.
- line appearance state
- message waiting indicator
- type of registration, phone’s Address of Record (AOR)
For some detail on these subscriptions, please refer to my article, Avaya SIP Telephones.
11: The phone will now exchange data with the Avaya Personal Profile Manager (PPM) using a series of HTTP/XML SOAP requests.
The PPM is a software module that runs as part of an Avaya Session Manager. It consists of a series of web services that phones use to retrieve and manage SIP related user data. Key PPM data elements consist of the following.
– Endpoint “Features”
- Contact lists and Speed dial information
- Device data (user, ringer, volume)
– SIP Telephony / Feature Data
- Dial plan
- Location data
- Button data
- Emergency numbers
– Configuration Data
- Primary, Secondary, and Survivable Remote Session Managers
– Maintenance Operations
Examples of PPM requests include getInitialEndpointConfiguration, getDeviceData, getHomeServer, getOneTouchDialList, and getVolumeSettings.
There is overlap in the values that can be set in the 46xxsettings file and PPM. PPM values always take precedence.
At this point the phone has booted and is ready to go. For the most part, SIP will be sent to and from the phone, but the phone will also use PPM to perform operations such as adding a new number to the user’s contact list.
I hope you were able to stick with this. Yes, it’s a little involved, but these steps enable an Avaya SIP phone to be nearly on par feature-wise with its H.323 and digital counterparts. Without the SIP subscriptions and data obtained from the 46xxsetting file and PPM, you wouldn’t get much more than SIPPING-19 functionality.
In a future blog I plan on addressing what all this means for remote users and session borders controllers.