Nov 072013


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


Avaya CS1000

UNIStim 5.0 or earlier

Avaya IP Phone 1100, Avaya IP Phone 1200


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.



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.


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

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.


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


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.

Aug 092012

Zone Bandwidth Strategy

One of the things I run into regularly with deployments is an issue where the installer improperly configures the Zone Bandwidth Strategy. This information can be checked by printing the interzone and intrazone configurations in LD 117.

=> prt zone

=> prt interzone
 |Near end  |Far end   |State| Type  |Stra|MO/ |QoS| Bandwidth | Sliding |  Usage  |  Quota  |Peak|  Calls  |  Alarm  |
 |          |          |     |       |tegy|BMG/|Fac|Configured |   max   |         |         |    |         |         |
 |          |          |     |       |    |VTRK|tor|           |         |         |         |    |         |         |
 |Zone|VPNI |Zone|VPNI |     |       |    |    | % |    kbps   |   kbps  |   kbps  |   kbps  | %  |   Cph   |   Aph   |
 |   1|     |    |     | ENL |SHARED |  BB|  MO|   |    1000000|         |      380|        0|   0|         |         |
 |   5|     |    |     | ENL |SHARED |  BB|VTRK|   |    1000000|         |      380|        0|   0|         |         |
 |  42|     |    |     | ENL |SHARED |  BB|  MO|   |    1000000|         |        0|        0|   0|         |         |

=> prt intrazone
 |Zone|State| Type  |Strategy|MO/ | Bandwidth |  Usage  |  Quota  | Peak |
 |    |     |       |        |BMG/|    kbps   |   kbps  |   kbps  |   %  |
 |    |     |       |        |VTRK|           |         |         |      |
 |   1| ENL |SHARED |   BQ   |  MO|    1000000|      380|        0|    0 |
 |   5| ENL |SHARED |   BQ   |VTRK|    1000000|      380|        0|    0 |
 |  42| ENL |SHARED |   BQ   |  MO|    1000000|        0|        0|    0 |
  Number of Zones configured = 3


The Strategy column for intrazone and interzone can be configured as either:

  • BQ aka Best Quality aka G.711 codec selection
  • BB aka Best Bandwidth aka G.729 codec selection

BB should be used when a WAN interface is handling VoIP with the following limitations/restrictions:

  • Bandwidth shaping or rate limiting restrictions
  • Bandwidth availability limitations (either the pipe is too small, or other usage + VoIP traffic exceeds available bandwidth)
  • No QoS policies configured

Even if you believe your WAN can support the bandwidth demands of VoIP + other usage, if you are experiencing any quality issues with VoIP, it’s worth changing your bandwidth strategy to BB (i.e., Best Bandwidth, G.729) as part of your troubleshooting efforts. I also recommend that you configure the available bandwidth to match the actual available bandwidth.


As the word root suggests, the Interzone Strategy is used for all VoIP calls that leave the zone wherein the caller is configured. This strategy is also used for calls that are inter-site.


As the word root suggests, the Intrazone Strategy is used for all VoIP calls within the zone.

Purpose of Zones

Zones provide a way of controlling the behavior of VoIP and QoS within a site (and between sites). Zones work best when used to represent physical locations.


Zone 1 is set up for all phones within a site (on the LAN). BQ strategy is used for intrazone and BB is used for interzone.

Zone 2 is set up for all phones at a branch office. BQ strategy is used for intrazone and BB is used for interzone.

Zone 3 is set up for all softphones connected via VPN (remote employees). BB strategy is used for both intrazone and interzone.

If a caller in Zone 1 calls anyone in Zone 1, they use G.711 (BQ). If they call anyone outside of Zone 1 (a VPN user softphone, or the branch office) they use the G.729 (BB strategy) codec.

If a caller in Zone 2 calls anyone in Zone 2, they use G.711 (BQ), but calls out of Zone 2 use G.729 (BB). Just like Zone 1.

If a caller in Zone 3 calls anyone they use G.729 (BB).

Mixed VoIP/TDM environments

TDM resources are sometimes configured to be in a separate zone by installers. I’ve never understood this, because following the logic above, if all the TDM equipment (Media Gateways, MGCs, MC32s, IP Trunks, etc.) are put in Zone 4 and everyone uses BB for interzone, then all calls between Zone 1 and TDM resources in Zone 4 will use the G.729 codec (BB) (even if those Zone 4 resources are physically located in the same site as Zone 1).

From my way of thinking, all physical TDM equipment should be configured in the zone appropriate to its physical location in the network. Zone 1 VoIP users should share the zone with Zone 1 TDM equipment/users. But, if there is TDM resources at the branch office, they would go into Zone 2 (using the above example).

Virtual Trunking would be a special case, in that Virtual Trunks are not used by IP Phones, so putting them in a separate zone has no negative impact (and the fact that they show up as a zone type in the Intrazone/Interzone print out tells us it was Nortel’s Design Intent that they be put in their own zone.)

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.

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.


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


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

Feb 092012

NOTE: The source for this document is several years old and available free from the ITU. The latest version of this model (G.107) is available from the ITU for 77 CHF (Swiss Francs), which as of today is roughly $84. This information is routinely useful for interpreting the R-Value on

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

R:75 refers to the R-Value of 75 which using Table 1 below indicates that the voice call  quality is estimated to be Medium, which usually indicates that some users will be dissatisfied. “R-value is a number, or score, that is used to quantitatively express the subjective quality of speech in communications systems, especially digital networks that carry voice over IP (VoIP) traffic, or for which VoIP service is under consideration.” (Quote sourced from R-Value) R-Value is calculated using the E-model.

E-model Tutorial


The E-model (ITU-T Rec. G.107 [1]) is a transmission planning tool that provides a prediction of the expected voice quality, as perceived by a typical telephone user, for a complete end-to-end (i.e. mouth-to-ear) telephone connection under conversational conditions. The E-model takes into account a wide range of telephony-band impairments, in particular the impairment due to low bit-rate coding devices and one-way delay, as well as the “classical” telephony impairments of loss, noise and echo. It can be applied to assess the voice quality of wireline and wireless scenarios, based on circuit-switched and packet-switched technology.

The E-model is based on modeling the results from a large number of subjective tests done in the past on a wide range of transmission parameters. The primary output of the E-model calculations is a scalar quality rating value known as the “Transmission Rating Factor, R”. R can be transformed into other quality measures such as Mean Opinion Score (MOS-CQE [2]), Percentage Good or Better ((GoB) or Percentage Poor or Worse ((PoW). However, caution should be exercised when comparing these transformed measures with values of MOS, %GoB or %PoW from other sources, which may not have been obtained under comparable conditions.

The E-model is based on a mathematical algorithm, with which the individual transmission parameters are transformed into different individual “impairment factors” that are assumed to be additive on a psychological scale. The algorithm of the E-model also takes into account the combination effects for those impairments in the connection which occur simultaneously, as well as some masking effects. To the extent that impairments are present for which psychological additively is not maintained, E-model predictions may be inaccurate.

The relation between the different impairment factors and R is given by the equation:

R = Ro – Is – Id – Ie,eff + A


  • The term Ro expresses the basic signal-to-noise ratio (received speech level relative to circuit and acoustic noise).
  • The term Is represents all impairments that occur more or less simultaneously with the voice signal, such as: too loud speech level (non-optimum OLR), non-optimum sidetone (STMR), quantization noise (qdu), etc.
  • The term Id sums all impairments due to delay and echo effects.
  • The term Ie,eff is an “effective equipment impairment factor”, which represents impairments caused by low bit-rate codecs. It also includes impairment due to packet-losses of random distribution. Values of Ie for specific codecs without packet loss are given in ITU-T Rec. G.113 App. I [3], and these values are transformed to Ie,eff in case of random packet loss, using the E-model algorithm.
  • The term Ie,eff is an “effective equipment impairment factor”, which represents impairments caused by low bit-rate codecs. It also includes impairment due to packet-losses of random distribution. Values of Ie for specific codecs without packet loss are given in ITU-T Rec. G.113 App. I [3], and these values are transformed to Ie,eff in case of random packet loss, using the E-model algorithm.
  • The term A is an “advantage factor”, which allows for an “advantage of access” for certain systems relative to conventional systems, trading voice quality for convenience. While all other impairment factors are subtracted from the basic signal-to-noise ratio Ro, A is added and thus compensates other impairments to a certain amount. It can be used to take into account the fact that the user will tolerate some decrease in transmission quality in exchange for the “advantage of access”. Examples of such advantages are cordless and mobile systems or connections into hard-to-reach regions via multi satellite hops.

Values of R fall in the range of  0 £ R < 100, with higher values indicating higher speech quality. Table 1, taken from ITU-T Rec. G.109 [4], relates the E-model Ratings R to categories of speech transmission quality and to user satisfaction.


Table 1 – Definition of categories of speech transmission quality

Range of E-model Rating R

Speech transmission quality category

User satisfaction

90 £ R < 100


Very satisfied
80 £ R < 90


70 £ R < 80


Some users dissatisfied
60 £ R < 70


Many users dissatisfied
50 £ R < 60


Nearly all users dissatisfied
NOTE 1 – Connections with E-model Ratings R below 50 are not recommended.NOTE 2 – Although the trend in transmission planning is to use E-model Ratings R, equations to convert E-model Ratings R into other metrics, e.g. %MOS, %GoB, PoW can be found in ITU-T Rec. G.107 Annex B [1].

Application of the E-model

Figure 1 shows the basic reference configuration used by the E-model for estimating end to end speech quality, with the parameters involved defined below:

  • SLR = Send Loudness Rating
  • RLR = Receive Loudness Rating
  • OLR = Overall Loudness Rating1
  • STMR = Sidetone Masking Rating2
  • LSTR = Listener Sidetone Rating2
  • DS = D-value of telephone at send-side
  • DR = D-value of telephone at receive-side2
  • TELR = Talker Echo Loudness Rating
  • WEPL = Weighted Echo Path Loss
  • T = Mean one way delay of the echo path
  • TR = Roundtrip delay in a closed 4-wire loop
  • TA = Absolute one-way delay in echo free connections
  • QDU = Number of quantization distortion units
  • IE = Equipment impairment factor
  • PPL = Random packet-loss probability
  • BPL = Packet-loss robustness factor
  • NC = Circuit noise referred to the 0 dBr-point
  • Nfor = Noise floor at the receive-side
  • PS = Room noise at the send-side
  • PR = Room noise at the receive-side
  • A = Advantage factor

The connection is basically divided into a “send side” (subscript S) and a “receive side” (subscript R) with a virtual centre referred to as a “0 dBr-point”. One of the most important assumptions in the model is that the perceived quality is referred to the user on the “receive side”, with this user experiencing conversational conditions (talking and listening). This is important when inputting parameters relating to listening (loudness, equipment impairment factor etc) and talking (e.g. sidetone, delay, echo etc).


Figure 1 – Basic reference configuration of the E-model

Values of SLR, RLR and NC must be referred to a 0 dBr-point (i.e. any gains or losses taken into account). For the basic end to end loudness, use SLRS and RLRR.
To evaluate the impairment due to talker echo, the E-model expects two parameters, the mean one-way echo path delay (T), and the Talker Echo Loudness Rating (TELR) of the echo path. It is very important to note that talker echo is referred to the user on the receive side. The value for TELR is obtained in a pre-calculation according to the basic formula:


where: EL (Echo Loss), represents the effective echo return loss seen by the receive side.
To evaluate the impairment due to one-way delay in the absence of echo, two approaches may be used:

i. Input the required value of Ta and set T = Tr = 0. This effectively turns “off” the echo algorithm and can be considered the absolutely ideal echo-free case.
ii. It may be more realistic to input the required value of Ta and set T = Tr/2 = Ta, with TELR and WEPL set to their default values. This corresponds to the practical case of a near-ideal echo canceller.

Default values for all E-model parameters and nominal parameter ranges3 are listed in Table 2. With these default values, the resulting value of R is 93.2.

Table 2 – Default values and recommended ranges for the parameters



Default value

Recommended range


Send Loudness Rating




0 to +18


Receive Loudness Rating




-5 to +14


Sidetone Masking Rating




10 to 20


Listener Sidetone Rating




13 to 23


D-value of telephone, send side



-3 to +3

D-value of telephone receive side



-3 to +3


Talker Echo Loudness Rating




5 to 65

Weighted Echo Path Loss




5 to 110

Mean one-way delay of the echo path




0 to 500

Round trip delay in a 4-wire loop




0 to 1000

Absolute delay in echo free connections




0 to 500

Number of Quantization distortion units



1 to 14

Equipment impairment factor



0 to 40

Packet-loss Robustness Factor



1 to 40


Random Packet-loss Probability




0 to 20


Circuit noise referred to 0 dBr-point




-80 to -40

Noise floor at the receive Side





Room noise at the send side




35 to 85

Room noise at the receive side




35 to 85

Advantage factor



0 to 20

NOTE 1 – Total values between microphone or receiver and 0 dBr-point.NOTE 2 – Fixed relation: LSTR = STMR + D.NOTE 3 – Currently under study.



[1] “The E-model, a computational model for use in transmission planning” ITU-T Rec. G.107 (March 2005) [2] “Mean Opinion Score (MOS) terminology” ITU-T Rec. P.800.1 [3] “Provisional planning values for the equipment impairment factor Ie and packet-loss robustness factor Bpl” ITU-T Rec. G.113 App. I [4] “Definition of categories of speech transmission quality” ITU-T Rec. G.109

Recommended bibliography

The following references provide more details on the E-model and its application.
“Application of the E-model – A Planning Guide” ITU-T Rec. G.108
“Guidance for assessing conversational speech transmission quality effects not covered by the E-model” ITU-T Rec. G.108.1
“Transmission and Multiplexing (TM); Speech communication quality from mouth to ear for 3.1 kHz handset telephony across networks” ETSI ETR 250, July 1996
“The ETSI Computation Model: a Tool for Transmission Planning of Telephone Networks”, N.O. Johannesson, IEEE Communications Magazine, January 1997
“Voice Quality Recommendations for IP Telephony” TIA/TSB-116-A (March 2006)
1 No direct input value; calculated as OLR = SLRS + RLRR.

2 These parameters have a fixed relation by: LSTR = STMR + DR.

3 The E-model is not validated outside of these ranges

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

Jul 172008

Resetting a Nortel IP phone just became a lot easier.  Nortel has announced in their Unistim 3.0 documentation the ability to reset a Nortel IP phone to factory default settings.  The following code is required to reset to factory default:

  • **RENEW[mac]##

Where [mac] is replaced by your MAC address.  Example: If your MAC address is 00:11:22:33:44:55, then your reset code would be:

  • **73639001122334455##

For more information on what the factory default settings are, refer to the Unistim 3.0 Revision 1 product bulletin located on Nortel’s Partner Information Center webpage.

You must have valid Nortel Partner credentials to access this bulletin.