IP Office DHCP Scope

The IP Office has a built-in DHCP server that can be configured to provide addresses for all devices or just for Avaya phones, however many companies have their own DHCP servers that they manage. The IP Office phones look for one of two DHCP Options for their information, either 176 or 242. Both of these options use similar formats.

Option 176 is used for legacy IP Office phones (4600 and 5600 series phones). Option 242 is used for 1600 and 9600 series phones. The DHCP option provides the IP Office address, the H.323 port number, the TFTP or HTTP server used, and (optionally) VLAN information.

The options look like this:

OPTION 176  MCIPADD=xxx.xxx.xxx.xxx,MCIPORT=yyyy,TFTPSERVER=zzz.zzz.zzz.zzzOPTION 242  MCIPADD=xxx.xxx.xxx.xxx,MCIPORT=yyyy,HTTPSERVER=zzz.zzz.zzz.zzz

xxx.xxx.xxx.xxx is the IP Address of your IP Office that the phones will use for registration, and yyyy is the port number (almost always 1719). The TFTP or HTTP server address is almost always the same as the IP Office address, however some deployments may use an external server to support additional simultaneous connections.

In a scenario where you have multiple servers in a resilient environment you can have multiple entries for MCIPADD - simply separate them with a comma:
With Option 242 you can specify a folder on the HTTP server that contains the files needed by the IP Phone using the HTTPDIR=path_to/files.

Keep in mind that there is a limit of 127 characters in a DHCP Offer. If the scope would exceed this you can use OPTION 66 to specify the TFTP Server for Option 176.

When using VLANs to separate voice and data traffic you need to ensure that the VLAN details are specified in the default VLAN:
L2Q=1                                      enables VLAN tagging.
L2QVLAN=xxx                       where xxx is the VLAN ID for your voice VLAN.
In this scenario you would have your options as follows:
Default DHCP Offer:
OPTION 242 L2Q=1,L2QVLAN=200
Voice VLAN DHCP Offer:
The IP Phones will pick up their VLAN from the default offer then request a new DHCP scope in the correct VLAN, at which point they will receive their configuration from the voice VLAN.

IP Office Personal Directory with pauses

Today I had someone call me to say they were trying to create a personal directory entry in their IP Office for someone with an external number and and extension. I couldn't conceive of why there would be any problem with this until I learned that the Personal Directory only allows entry of keypad keys (0-9, *, #). Since none of the allowable entries will make the call pause I had to find a way to make this work.

After some thought about how I could make this work for my customer I came up with a plan. I would try to dial a short code that would make the call for me!

First I created the PD entry:

Then I create a corresponding Dial Direct short code with the number I have put into the PD:

Once I had followed these quick and easy steps I was able to make a call from my personal directory to an extension. I was surprised that Avaya hadn't allowed pauses in the directory but the IP Office always provides a way!  It is not necessary to use the phone number, I simply used this method to ensure that I was able to track what numbers were being manipulated at a glance.
Make sure to include the dial prefix if it is expected in the ARS. If it is not needed in the ARS you don't need to include it in the short code.

Network failures and the Dell R620

So we recently installed a Dell R620 server with IP Office Server Edition 9.1. While troubleshooting an unrelated issue we came up with a big problem: The device could no longer be reached on the network! Well that's a huge problem since we have IP phones and all the bells and whistles on this server. Avaya support wasn't able to resolve the issue because...guess what? They couldn't get into it remotely...

So we replaced the server and I took a look once we had it back in the lab. It turns out that the devices had been renamed. ETH0 switched with ETH2 and ETH1 switched with ETH3. By plugging in to Port 3 (which should have been ETH2) and enabling the port (#ip link set up) I was able to get connectivity right away. But how could this have happened, and what can I do to make it work with the correct network port? It turns out there is an issue with the way CentOS uses UDEV to create network interfaces. So how do you fix it? Well it's not too hard. I was able to make it work exactly as it did before by looking at a few files and changing one.

In the root folder there are four interesting files. They are ifcfg-eth0, ifcfg-eth1, ifcfg-eth2, and ifcfg-eth3. These files each contain a single line of text with the MAC address of the server:


Trust these files. They are the gospel. I was also able to find the MAC address of eth0 (Port 1) printed on the circuit board inside the server. The four addresses should be sequential, but keep in mind that they are sequential in HEXADECIMAL. So...29 does not go to 30, 29 goes to 2a.

So you may wonder, now that we have these MAC addresses, what are we going to do with them?

That's easy. Use your favourite text editor (I personally like NANO) to edit the file /etc/udev/rules.d/70-persistent-net.rules. You'll see your interfaces and, I bet, incorrect MAC addresses. Or at least MAC addresses that are not associated with the correct device name. Simply change the MAC addresses to the correct address for each device and you're on your way.

For example, change:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:2a:72:dc:17:2a", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:2a:72:dc:17:28", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Security Certificates - 9.1

With the release of IP Office 9.1 there have been enhancements made to the way security is handled. When deploying an IP Office Server Edition or Select Server Edition for a customer it is best practice to have them provide a fully qualified domain name or a machine name to use for the security certificate. The IP Office can be configured with a valid host name and the certificate can be imported into the Trusted Root Certification Authority certificate store. When accessing the system by the proper host name with the certificate properly stored there will be no security warnings while accessing the page.

When defining the hostname for the IP Office you need to either enter the FQDN that will be used to access the system or the IP address that will be used to access the system. In the case of my example I used the IP address of as the host name. If you are using a fully qualified domain name (FQDN) or a server name (NetBIOS) you will want to make sure it resolves with your DNS server or you will see a certificate mismatch error.

To use a self-signed certificate we will select “Generate New”:

After you click Next you will see the following warning:

The certificate will now be generated. 

Once the certificate has been created it is available for download. For a Windows Certificate Store you need to download the DER-Encoded certificate:

Once you have downloaded the certificate click Apply. The process will take several minutes, after which you will be logged out of the system.  Be sure to add the certificate you downloaded to your Trusted Root Certification Authority. If you're working with a domain this can be pushed to client systems using a group policy, or it can be added to machines individually using the Microsoft Management Console.