Demystifying Your Call Data: Introducing SMDR Lite

Normally I post stuff on this blog about software that someone else has written, but that changes today. I have often been frustrated by the lack of a built-in tool for producing CDR with IP Office. My frustrations peaked a couple months ago, so I wrote some tools to solve this issue. The first of these tools is a simple command-line utility that can pull SMDR data from the IP Office on an ad-hoc basis. This is perfect for pulling records when the client does not need regular CDR information. I have called this tool SMDR Lite. 

The Crucial Need for SMDR

Why bother collecting call records? SMDR data is the foundation of Call Accounting. By analyzing these records, companies can:

1. Control Costs: Accurately track external call charges and allocate costs back to specific departments or projects.

2. Monitor Usage: Identify peak usage times, understand trunk utilization, and plan capacity upgrades effectively.

3. Ensure Compliance & Security: Review call logs for unauthorized usage or potential security breaches, such as toll fraud.

4. Improve Efficiency: Analyze answer times, hold times, and missed calls to optimize staff scheduling and customer service.

How Avaya Generates SMDR Records

The Avaya IP Office doesn't just store SMDR data locally; it's designed to stream it out in a continuous, delimited format.

Each record is a single line of text containing a detailed snapshot of a call event. While Avaya includes many fields, some key pieces of information captured are:

• Call Start Time

• Duration (Connected Time/Ring Time)

• Caller & Called Number

• Direction (Inbound/Outbound)

• Internal Device Names (e.g., extensions, groups)

• Hold Time & Park Time

Crucially, the IP Office acts as a Client in this process. Once configured, it will actively push this stream of text data to a designated network address and port.

The Collection Mechanism: SMDR Lite as a Simple Listener

Collecting the SMDR stream requires a Server—a program that listens for the incoming connection and data. This is where SMDR Lite comes in.

SMDR Lite uses the TCP protocol to open a listening port on your Windows PC. It's designed specifically for environments where a full, complex call accounting server is overkill.

• Non-Privileged Access: SMDR Lite defaults to port 5000. Because this is above the privileged port threshold (1024), it does not require administrative rights to run, making deployment simple and secure.

• Real-Time Appending: As soon as a complete call record is received from the Avaya system, SMDR Lite instantly appends it as a new row to your designated CSV file.

• Live Status: The application displays a live count of records received and the time of the last record, giving you immediate feedback that the connection is working.

Getting Started with SMDR Lite

SMDR Lite is distributed as a single, standalone executable file: smdr.exe. No Python or extra libraries are required on the target machine.

1. Running the Executable

You run the tool via the Windows Command Prompt or PowerShell:

Action	Command	Result
Default Run	smdr.exe	Listens on Port 5000, writes to smdr.csv
Change Port	smdr.exe --port 9000	Listens on the specified Port 9000
Custom Filename	smdr.exe --filename office_data.csv	Writes to office_data.csv

To exit the application gracefully at any time, simply press the Q key on your keyboard.

2. Configuring the Avaya IP Office

The final step is telling your Avaya system where to send the data:

1. Open IP Office Manager and navigate to the System settings.

2. Select the SMDR tab.

3. Set the Output to SMDR Only.

4. In the IP Address field, enter the IP address of the Windows PC running smdr.exe.

5. In the TCP Port field, enter the port number (5000 by default) that you specified when running smdr.exe.

Save and merge the configuration, and your SMDR Lite tool will immediately begin populating your CSV file with valuable call data!

Voicemail Pro Automatic Service Restart

Today someone asked me if Voicemail Pro on Linux would attempt an automatic restart if the service failed, as it would in Windows. Unfortunately the answer is a resounding NO!

I've been using Linux for years and I didn't see any technical reason why this couldn't be done. I decided to do some digging, and I believe that by making the changes I outline below to the Voicemail Pro service you should be able to have it automatically restart in the event of an abnormal termination. 

DISLCLAIMER: I have not tested this in a production environment. This is not supported by Avaya. If you need this functionality you can implement this fix at your own risk. I suggest opening a GRIP Request with Avaya to have them add this functionality to a new release!

Note: Avaya no longer uses GRIP as the mechanism for feature requests. These must be done through the International Avaya User Group (IAUG) Feature Request Tracker.

First, you will need to log in to the Application Server as the root user. Once logged in the next step is to edit the Voicemail Pro service. Enter the following command:

nano /etc/systemd/system/vmpro.service

This will launch the GNU nano editor, allowing you to modify the service directly. The image shown here is the configuration before any changes are made.

Use the arrow keys to navigate to the Service section. In order to tell the service to automatically restart we need to add the following lines:

Restart=on-failure

RestartSec=30s

StartLimitIntervalSec=200

StartLimitBurst=5

This tells the service to restart on failure after waiting 30 seconds, to a maximum of five times. 

Once the changes have been made, use <CTRL>+O to write the file, then <CTRL>+X to exit nano.Once back at the command prompt the system needs to know that you've made changes. Enter the following command:

systemctl daemon-reload

Once this is done the Voicemail Pro service may need to be restarted (again, this is untested), so go ahead and restart the service. 

These instructions should work on any Linux-based IP Office release to date, however future releases may include an updated version of systemd, the process that controls Linux services. If Avaya includes a newer version of systemd these instructions will need to be modified. 

If you do try to implement this, please let me know how well it worked in the comments.

Adding a CertBot Certificate to IP Office

The IP Office generates a self-signed certificate for the purpose of presenting its identity. Any Avaya elements will trust this certificate, but modern web browsers will not by default. One option we have is to add the Avaya Certificate Authority to our list of trusted issuers, but a better way is to ensure that the IP Office presents a certificate that is universally trusted. The Electronic Frontier Foundation (EFF) is providing free publicly trusted certificates with a three month expiration. The short duration is intentional - any malicious use of the certificates wouldn't last longer than three months, making the Internet a safer place. 

The EFF has a utility called CertBot that can be used to generate these certificates on your local machine. They use Public DNS to validate that the correct machine is requesting the certificate. The whole process takes only a few minutes, and when run on a web server can automatically apply the certificates to the hosted pages.Unfortunately Avaya has not yet integrated CertBot functionality into their finished product, so we will need to manually create a certificate, extract the portion that the IP Office needs, and apply the certificate. This will need to be done on a regular basis because of the short certificate duration. Please reach out to your Avaya partner or account manager and ask them to add CertBot integration to the IP Office in future releases! As more people request this functionality Avaya becomes more likely to include it in a future software release. You can download CertBot here. We can't install CertBot directly on the IP Office, so a Linux PC or server will be required. Once CertBot is installed on your Linux PC or Server we can proceed with generating a new certificate. 

The next step is to use CertBot to create a certificate. For the purpose of this example I will redact all my screenshots, hiding the actual FQDN I used. For reference I will use the domain ipo.adventuresinvoip.ca in all of the commands. Simply change out the FQDN for the FQDN you want to assign to your IP Office. Since the CertBot utility uses DNS records you need to be sure to have a DNS A Record for the FQDN you are using. This should point to the public IP Address of the router that the Linux machine is connected to. You will need to enable port forwarding for Port 80 to the Linux machine to get CertBot to work properly since it checks for an HTTP request/response. 

My Linux machine already has a web server running, so I chose to leverage that for the generation of the certificate. To generate the certificate I ran the following command:

certbot run --domains ipo.example.ca

If you don't have a web server running on your Linux machine you can run the commmand in Certificate Only mode:

certbot certonly --domains ipo.example.ca

Once the certificate chain has been created you may be prompted to install it on your web server - since we aren't generating the certificate for this machine we should not be applying it to this server. 

Now we have a new certificate. It will be located in the CertBot folder under a subfolder for that FQDN. In our example this full path would be:

/etc/letsencrypt/live/ipo.example.ca/

The IP Office is unable to use the certificate in this format so we will need to convert it. Change to the folder containing the certificate and extract the PKCS#12 Certificate from the full chain with these commands:

cd /etc/letsencrypt/live/ipo.example.ca/
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out ipo.p12 -CAfile chain.pem

The second line will prompt for an export password. This password will be used to add the certificate back to the IP Office. Once complete the file ipo.p12 will be created. We can apply this certificate to the IP Office. Copy the ipo.p12 file back to your local PC and launch a web browser. The certificate is easiest to apply using Web Manager, so that's the method I will cover here. 

Log in to Web Manger using the Administrator account (other accounts can be used as long as the permissions allow the manipulation of certificates). Select Security from the top menu, then Certificates. 

This will take you to the Certificates portion of IP Office Web Manager. Here you will see a list of all the trusted certificate authorities, as well as some options to manipulate the IP Office certificate. 

The button for Set will allow us to upload our new certificate. Click Set then locate the ipo.p12 file and enter the password set during the extraction process.

The IP Office will advise you that the system and applications will stop responding while the certificate is applied. Click OK and wait for the IP Office to apply the certificate. Once applied you can view the certificate by clicking View.

Now that the IP Office is presenting the ipo.example.ca certificate to users we need to ensure that this resolves properly. We will still get an error if we try to browse to the IP Office by IP Address, since the certificate doesn't contain the internal IP. The internal DNS Server needs to point ipo.example.ca to the internal IP of the IP Office. As with many Avaya applications the IP Office performs a reverse DNS lookup to validate the FQDN. If you skip this step the IP Office will server an error page when you browse to it. Make sure that the IP Office is set to use the DNS Server that hosts your internal DNS entries. If you want your IP Office to be accessible to the Internet you can enable port forwarding on your router for ports 80, 443, 7070, 7071, and 8443. Otherwise, disable the port forwarding that was set up for the certificate creation. 

This process is a manual process that can't be automated at this time. You will need to update the certificate before it expires, following the entire process again. While this is not an ideal scenario, it is the easiest way to get free TLS certificates for your IP Office. The same process can be applied to a UC Module or Application Server - even Server Edition. Just follow the steps and remember that each element will require a unique, DNS-resolvable FQDN.

One final piece of housekeeping - the IP Office will, by default, generate an alarm when the certificate is within 60 days of expiring. To change this open the security settings, navigate to System, then Certificates. Change the Certificate Expiration Warning (days) to 30. This is the lowest number possible, so a System Status Alarm (or SNMP alarm if you've configured that) will be generated when the certificate is set to expire. IP Office Manager will also generate an alarm when logging in. I haven't found a way to eliminate this that doesn't do away with all the application security altogether. If you come up with something please let me know in the comments. I will update my post and give credit where it is due.    

IP Office Server Edition/App Server/UCM Can't escalate to root

Avaya, in their infinite wisdom, decided to take away root access over SSH connections. This was put into place for versions 10.1 SP7, 10.1 SP8, 11.0.4.2, 11.0.4.3 and 11.1. Of course, this makes it very difficult to provide remote support!

Naturally Avaya's customer base revolted at this, so Avaya will be bringing back root access for upcoming releases. Well, that doesn't help if you're stuck now! To that end I've figured out what was blocking it and created a simple workaround. It will require direct access to the system. If you're using VMWare this can be through the VMWare console, otherwise you will need physical access to the server. If you're working on a UC Module remember that the HDMI port will not be active until you reboot. You should be able to execute the commands without a monitor, but being able to see what you're doing is a lot easier. Follow these steps to allow SSH access to root. You will still need to log in as Administrator when connecting via SSH, but you will no longer get the dreaded 'incorrect password' error.

1. Log in to the server (direct-connect) as root, using the Security password
2. enter the command usermod -a -G wheel Administrator 

That's all it takes! Now you should be able to SSH to the system and log in as Administrator. Once logged in enter the command admin, then log in again. Now you can enter root and log in with the security password.

Upgrading the IP Office

I'm not going to tell you how to upgrade your IP Office, that's what the official training is for. I am, however, happy to discuss the various issues that I have experienced while performing upgrades, and the steps I take to ensure that the upgrade goes smoothly.

File Write Errors

I often see people struggling when transferring files to the IP Office during an upgrade. More times than I'd like to count I've seen the system pop up with an error stating "405 Method Not Allowed".  While there are a number of things that can cause this issue the most common, by far, is the File Writer IP field in the system tab. If you're getting this error just check there and see if there is an address populated. I usually set the address to 0.0.0.0, which allows the writing of files from any address. While this may present a security risk, as long as you follow strong password management and don't leave any of the default passwords in place the risk should be next to zero. Alternatively you could specify the address of the PC being used to perform the upgrade, restricting the ability to write to the memory card to just that device. The third option is to set the address to 255.255.255.255, which will cause the system to update the address in this field the next time embedded file management is used to reflect the address of the system that is using embedded file management.

In some cases, even after making the change to the File Writer IP address, some installations still don't proceed. In these cases I've seen a couple of solutions. In some instances the system will allow the completion of the upgrade to the core equipment, and not the update of the files on the SD Card. When this happens it is often possible to simply log in to Embedded File Management and upload the system files from there. If that doesn't work, however, the cause is usually a corrupted SD Card. This happens most often on systems that have been through a number of upgrades, or potentially if you've forgotten that you have to step up from any release below 8.1(65) to 8.1(65) or 9.0 prior to upgrading to the current release. When this happens the best plan is to pop out the SD Card, put it in your laptop, and recreate the SD Card. Once this is complete pop it back in to the system and push your backed up config (and any embedded voicemail files, if applicable) back to the system. Once this is complete you should be able to access the system just fine.

Server Edition and Application Server Upgrades

Server Edition and Application Server upgrades appear to take forever, frequently appearing to stop around the 92% complete mark. This has caused panic for so many of my colleagues over the years. The first time I encountered this I panicked and rebooted the server. Let me tell you, this is a mistake! Now I've learned a thing or two and I have found a better way to keep an eye on the progress than simply looking at that 92% for what seems like an eternity. Log in to the server as root and type the following command:

tail -f /var/log/yum.log

This command will continuously scroll the output of the YUM application. YUM, or the Yellowdog Updater, Modified, is the Linux program that the IP Office uses to manage the installation of software. The yum.log file will scroll frequently even if the Web Manager progress indicator hasn't moved. This should keep your mind at ease while you wait.

It is possible that the updater may fail. Avaya has documented issues with the upgrade failing, and has even written code into the update software to identify issues with YUM failing to complete the upgrade. If you see the error "yum process died before completing its job" you have experienced an issue with the /boot/ partition being full. This happens, again, on systems that have been upgraded multiple times. If your system has been upgraded to at least 9.1.7 you should not experience this issue. If you do have this issue after 9.1.7 engage Avaya support right away, and anticipate a rebuild. If you are at a release older than 9.1.7 there is a quick fix. Download the file UpgradeKernelFix_v2.zip from Avaya. This zip file contains a patch that will allow you to expand the /boot/ partition. Extract UpgradeKernelFix_v2.sh from the zip file and upload it to your server using WinSCP, or your favorite SFTP client. Browse to the location of the file as root and type chmod +x UpgradeKernelFix_v2.sh - this makes the file executable. Run the file with ./UpgradeKernelFix_v2.sh and you should be off to the races. Of course, you will have to start the upgrade again. This issue should only affect systems running on VMWare, however I wouldn't rule it out for bare metal servers. 

You can download the fix from Avaya's web site here.

I can not stress enough the importance of making a full backup before you begin. For an application server this means assessing the applications used and ensuring that all application data is backed up off the system before you begin. For systems using embedded voicemail this means ensuring that you save all the dynamic contents of the SD Card before you even think of starting. 

Let me know if you've experienced any other errors, and if so, what is your resolution. I'll try to help out anyone who is stuck if I can!

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:

HWADDR="b8:2a:72:dc:17:28"

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"

 to:

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

IP Office Registry Hacks

It has come to my attention that Avaya often hides functionality in a registry entry. I'm going to keep a list here. As I learn more I will add them. Feel free to comment any that you have tucked away under your cap!

Maximum UMS Users (166 by default):
Under HKEY_LOCAL_MACHINE/SYSTEM/CurentControlSet/Services/MSExchangeIS/ParametersSystem, add a new key MaxObjsPerMapiSesion. Under the new key, create a new DWORD Value objtMesageView, and set the value to three times the required users. For example, to support 500 users, set the value to 1500.

SIP Line Template:
In IP Office 9.1 the option for SIP Line Templates was included out of the box. In 7.0 and up the option is still there, but it's hidden. There is a two-part step to enable this:
Navigate to File --> Preferences on the IP Office Manager and select the Visual Preferences tab. Check the Enable Template Options box.
Under HKEY_CURRENT_USER/Software/Avaya/IP400/Manager and add a DWORD value TemplateProvisioning and set its value to 1. Reboot the server hosting the IP Office Manager.
You can now generate a SIP Trunk template

No Caller ID Alarms on the IP Office

So the IP Office screams every time a call comes in with no caller ID received. Avaya finally decided to put in a workaround, and it's super quick and easy to implement!

The workaround is only available in 9.1 (and up, I suppose).

Go to the NoUser user and click on the Source Numbers tab.

Add the source number SUPPRESS_ALARM=1

Merge your changes and that's it! The NoCallerID Notification will be suppressed for System Monitor, System Status, Sys Log, SNMP Traps, and e-mail notifications.

Upgrade: File Access Error

I am in the middle of programming up an IP Office and I came across an issue with the phones. I plugged a phone in and I received the following message:

Upgrade: File Access Error

I did some digging and found the solution. I decided to share it here.

This issue comes from the fact that the phone is not able to get the firmware from the system or wherever it is configured to go for the update. In my case I had configured the IP Office to retrieve its firmware from Manager, however I had the wrong IP Address in Manager. Basically what happened is the phone went looking for the firmware and couldn't retrieve it from the identified location. The solution is quite easy. In my case I just changed the Phone File Server Type to Memory Card. The other options would be to configure the Manager PC IP Address to reflect the location of the correct version of Manager (Making sure the IP Office can reach that PC), or to change the type to Custom and specify the IP Address of the server that contains your BIN files.

Hopefully this helps!

IP Office BCM CS1000 Integration with NRS

I recently had to network some BCMs, and IP Office 8.1, and a CS1000 together for four-digit dialing. I figure I will share some of my knowledge here. With the release of IP Office 9.0 a Session Manager is required which greatly simplifies the implementation, as long as you know how to route calls using Session Manager.

For the purpose of this article I'm going to assume that everyone knows the basics of how to build a SIP trunk on all three platforms. I will also assume that the appropriate licenses have been purchased and that the BCM is SIP capable.

Let's start with the CS1000. The NRS needs to be configured You will need to create endpoints for the BCMs and IP Offices, as well as any CS1000 locations that you have. The IP Office and BCM endpoints must be configured as static SIP endpoints.Routing entries need to be created for each endpoint to correspond with your dialing plan. It may seem obvious, but you need to build SIP trunks and routes from the CS1000. It is very important to note that the IP Office must be configured in Proxy Mode. The IP Office does not support Redirect Mode. Once you have finished with this you are done with the easy part.

The BCM configuration is also quite easy. Build your SIP trunks on the BCM. Configure your SIP domain and enable RTP keepalives. Calls will be routed on the Private network, so navigate to the Private tab under SIP Trunking. Ensure that your URI map matches the URI Map on your node:

Next you need to configure your routing table. For any BCM or CS1000 endpoint you need to enter the destination digits and direct it to the NRS IP. I also selected MCDN Protocol CSE. Ensure that the port number matches up with what the CS1000 is expecting. For each IP Office configure the destination digits per your dialing plan and use the IP address of the IP Office.

And now on to the fun piece. Configuring the IP Office is the most time consuming part of the whole setup. You need to configure three items: SIP Lines, Incoming Call Routes, and Short Codes.
For your SIP Lines you need a connection to each networked system. For simplicity I chose to use the same incoming call route, however the Line Group ID needs to be different for each site. In my example I used SIP Lines 17-20. All my Incoming Call Groups were 17, however I matched up the Line Group ID with the line number. Since these are IP trunks you can configure them however you like as long as they don't interfere with any other lines in the system. For the SIP line to the CS1000 use the Node IP address. For the BCM SIP Lines use the IP address of each individual BCM. Configure each SIP line with the maximum number of calls equal to the maximum number of SIP Line licenses in the system. This way each site is capable of having the maximum number of VoIP calls, as long as no other licenses are in use.
If you used the same incoming call route for each SIP trunk you only need to create a single incoming call route for IP calls. For the destination use a period (.) to have the call sent to whichever digits are being sent from the far end.
In order to make outgoing calls work you need to create short codes on the system to match the dialing plan. In my case we had four-digit dialing with each site having a unique first digit. This made it easy, I configured a short code for each first digit (i.e. 1XXX, 2XXX, 3XXX, etc.). Each short code was configured as Dial 3K1 using the appropriate line group for the far end site. The BCMs will not understand the standard dial string sent by the IP Office so you need to configure the phone context in the telephone number. In my example I showed the Private/CDP URI as cdp.udp so I needed the following Telephone Number in my short code:

.";phone-context=cdp.udp"

Once all of this is done just go ahead and commit your changes to the IP Office. It will probably require a reboot as you are changing IP information. Once everything comes up go ahead and make your test calls and give the customer a big smile on your way out the door, you're their hero.

As always feel free to comment if you have any questions. I'll always do my best to help!

IP Office Initial Startup

When powering up an IP Office for the first time a number of things are configured automatically. It is important to remember to power up all expansion cabinets first as the IP Office will reach out to all connected modules to identify them. Without power these devices can't be identified and the IP Office will not configure them.

The IP Office will automatically build extensions and users for each extension port. This does not require the phones to be connected, simply that the port is installed and has power. The numbering starts at 201 and goes up sequentially, going from left to right across each port on the main unit and then sequentially up through the expansion modules. A default hunt group is created called MAIN with the number 200. The first ten users are added to this hunt group. By default all voice calls are directed to this hunt group. Data calls are routed to the RAS Access DialIn.

All lines are assigned to Line Group 0 by default. A Short code of 9 is created to provide access to this line group.

Embedded voicemail is configured by default. Every user will be assigned a mailbox and they will be active by default.

The IP Office will configure IP Networking. LAN 1 will have the IP Address of 192.168.42.1 and LAN 2 will be 192.168.43.1. Both networks will have the Subnet Mask of 255.255.255.0 and will have the DHCP server configured with a 200 address range. When connecting to the network the IP Office will check to see if there is another DHCP server on the network. If another DHCP server is active the IP Office will disable the DHCP server for that interface.

The IP Office System Name is configured using the MAC address of the IP Office control unit.

IP Office 8 Licensing

IP Office licensing is rather complicated. I’m not going to spend too much time on it but I would like to point out a few rather important details.

The IP Office Basic Edition is a starter-edition of IP Office that only supports one PRI (Up to 64 total trunks with analog and SIP) and up to 9 Auto Attendants. It does not support any applications or IP telephones.  It can be configured through a web interface or phone-based administration. Up to 100 telephones are supported on IP Office Basic Edition. Six concurrent connections to embedded voicemail are supported with approximately 25 hours of storage.

IP Office Essential Edition offers more flexibility over the Basic Edition. It supports up to 40 Auto Attendants and 8 PRIs. This version offers the benefit of IP telephony, including One-X Communicator, mobile twinning, and remote worker support. The Essential Edition comes with 2 concurrent voicemail connections and 15 hours of storage. This can be upgraded to 4/20 or 6/25. There is a built-in conference bridge that supports up to 128 simultaneous connections. Up to 64 connections are supported in a single conference call.

An IP Office Preferred license requires the Essential license and adds some additional functionality. Instead of the embedded voicemail Preferred Edition allows the use of Voicemail Pro. This can be on a standalone server or on a Unified Communications Module (UCM). Voicemail Pro adds significant functionality to the IP Office, including unlimited multi-level auto attendants and up to 40 simultaneous VM connections. The amount of storage available for VM Pro depends on the size of the hard drive on the VM server. A good benchmark is that each minute of voice stored will take up about one MB of hard drive space. VM Pro also includes call recording and an enhanced conference bridge. A single IP Office Preferred License can supply VM Pro to multiple sites in a Small Community Network configuration. VM Pro also adds support for web-based voicemail retrieval. The VM Pro server can be installed on a Linux-based or Windows-based server. The UC Module is Linux-based. When installing on a Windows server all Microsoft licensing requirements must be met for the server platform.

IP Office Advanced Edition provides all of the features of the Preferred license and adds a number of contact center features. Advanced Edition supports up to 150 agents and 30 supervisors in a contact center environment. The Advanced Edition can provide access to real-time and historical reporting to manage efficiency. Recording of all calls can be configured with sufficient storage on your server.  You can configure your menus to interact with an SQL database to provide a better interactive customer experience or to offer self-serve options. Visual Basic scripting is supported with a Windows-based Advanced Edition server.

In addition to platform licensing you must also have a license for all your IP endpoints and trunks.  A basic user (Digital or analog station) does not require a license. Any IP set requires an IP Endpoint License. There are two types of IP endpoint licenses: Avaya or third party. The appropriate license must be purchased for each endpoint. Additional licenses must be purchased for PRI B-channels above the eight that are included with the PRI daughterboard.

Currently license files are provided through http://adi.avaya.com/ but this will eventually be transitioned over to https://plds.avaya.com/

IP Office Startup and default passwords

When the IP Office is powered on it will look for any attached hardware. This means that any attached hardware should be powered on prior to connecting power to the IP Office. When started up for the first time the IP Office will automatically build extensions and users for any recognized extension port, starting with extension/user 201. The IP Office will number extension from left to right on the IP Office then left to right on any attached modules, starting at Module 1 and working up. A hunt group (number 200) will be created with the first ten users as members. All detected lines are included in Line Group 0 and a short code on 9 is created to provide access to the default routing table. Embedded voicemail is also configured on startup. Every user on the IP Office receives a mailbox. This is also true when Voicemail Pro is enabled.

The system name for the IP Office will be the MAC Address of the LAN1 port. As I previously mentioned the default IP addresses are 192.168.42.1 and 192.168.43.1 for LAN1 and LAN2, with a netmask of 255.255.255.0. A DHCP Server is built into the IP Office that is automatically configured to assign up to 200 IP addresses. The range is 192.168.42.2-201 and 192.168.43.2-201 for LAN1 and LAN2 respectively. If the IP Office detects that there is another DHCP server on the network it will disable the internal DHCP server.

The IP Office also builds a few default usernames and passwords. They are as follows:

IP Office Administration: Administrator / Administrator

IP Office Security Settings: security / securitypwd

Remote Access Dialin: RemoteManager / password

System Password (for upgrades): password (no username)

A number of other defaults are created as well. These include usernames that are used by the system for various functions as well as a few different levels of administration access. You can see the full list of users in the Security Settings. For obvious reasons you should consider changing some of these passwords. Do not change any of the passwords for system-level users (EnhTcpaService, SCN_Admin, IPDECTService, and SMGRB5800Admin). To change these passwords you need to open Manager and click File -> Advanced -> Security Settings. Log in using the Security Settings information. You can change the default passwords and create new users with various permissions from this screen.  In the event that you do not have any passwords for your IP Office you can use a physical connection to the RS-232 port on the back of the IP Office control unit. You can connect to the RS-232 port by configuring a terminal to connect at 38,400/8/N/1, Flow Control Off, TTY or VT100. The command type to use is at, followed by the type at-securityresetall. The IP Office will prompt for a complex response after which all passwords will be defaulted.

IP Office Telephones

The IP Office supports analog, digital, and IP sets. Avaya uses the second digit of the phone model to indicate the phone type. A phone with the numbering scheme x4xx or x5xx is a digital set and a numbering scheme of x6xx is an IP set. Avaya uses the same sets for the IP Office as they do for Avaya Call Manager.

Avaya offers expansion modules known as Button Modules for some of their digital and IP sets.

1400 series sets are digital sets using the Avaya Digital Control Protocol. Sets in this series include the 1403, 1408, and 1416 sets.  The 1416 set supports up to three DBM32 expansion modules with external power. The 1400 series sets have a red light that shows up next to the first line appearance on the phone. These sets do not have self-labeling buttons and require a paper label for the buttons. Labels can be printed from within IP Office Manager using the DESI software available for free download from http://www.desi.com/

9500 series sets are digital sets that have soft-labels. The button labels that are programmed into the IP Office are passed through using the Digital Control Protocol to the phones. Available sets are the 9504 and 9508.

1600 Series sets use the H.323 protocol and are visually similar to the 1400 series sets. They also require the use of DESI labels for button labeling. In addition to the 1600 sets there are 1600i sets that have a larger screen that support non-English lettering.

9600 series sets include the 9620, 9630, 9640, and 9650 IP telephones. There are letters after the model number to indicate functionality. C indicates a colour display, L indicates low power consumption (PoE Class 1), G indicates Gigabit Ethernet. These sets support the SBM32 expansion module and require Professional Edition licensing. 9608, 9611, 9621, and 9641 sets are newer IP phones that are also supported. The 9600 series sets have displays that support soft labels so no DESI strips are required.

The IP Office supports Nortel (now Avaya) 1120 and 1140 sets, as well as the newer 1220 and 1240 sets.

Avaya has three conference phone offerings. The B149 is an analog conference phone. The B159 is an analog conference phone with a USB connector for attaching to a PC or cell phone. The B179 is a SIP-enabled PoE conference phone that supports the G.722 Codec for HD voice quality. The B179 requires an Avaya IP Endpoint license to function and is supported on IP Office 7.0 and higher.

Avaya supports DECT R4 sets with the IP Office. Each base station can support up to eight simultaneous calls. DECT sets use the x7xx numbering scheme.

Avaya Video phones (1010, 1020, 1030, 1040, and 1050) are available. These video phones support internal video calls only (no, your customers won’t be able to see you). The Avaya softphone also supports video calls. The softphone can be installed on a Windows or MAC computer. The installer is located on the Admin CD.

Legacy IP Office phones include the 4600, 5600, 4400, and 5400 series sets that are also supported. These sets are not available for new sales. 

IP Office Hardware

The IP Office 500 v2 is the base system for all new IP Office installations. It supports up to 384 extensions (ports) and up to 1000 subscribers (users).

The IPO500v2 has a LAN and WAN port, however in the IPO programming these are referred to as LAN1 and LAN2 respectively. The default IP addresses for these ports are 192.168.42.1 and 192.168.43.1 respectively, with a netmask of 255.255.255.0.

Up to four base cards can be installed in the system. Each base card can be fitted with a trunk daughterboard, with the exception of the 4-port expansion module.

A Digital Station card supports up to   eight digital stations. Up to three DS card can be included in the IP Office.

A TCM8DS Module supports up to eight Nortel 7000-series digital stations on the IP Office.

Voice Compression Module (VCM) provides resources for use with IP transcoding (same as DSP resources in the Nortel world). There are two VCM base cards – 32- or 64-VCM cards.

A Combo Card supports six digital stations, 2 analog stations, four analog trunks, and 10 VCMs. You can have up to two combo cards in an IP Office. Port 8 on a combo card can also be configured as a powerfail line.

A P-2 or P-8 base card supports 2 or 8 phone sets. The P2 is often used if a trunk module is required without any other functionality as it is the least expensive card available for the IP Office.

The 4-port expansion module allows for additional expansion modules to be connected. It must be plugged into Slot 4 of the IP Office.

The Unified Communications Module is an embedded Linux server that can host Voicemail Pro (up to 200 users and 40 ports) and the One-X Portal. It is managed separately from the IP Office through a web interface on Port 7070. The UCM is not supported with IP Office Basic Edition.

The IP Office supports up to twelve expansion modules. The IPO500v2 has eight ports built into the back for expansion and an optional 4-port expansion module can be installed into slot 4 of the IP Office to add the extra four expansion modules.

Expansion Modules for the IP Office include 16-Port Analog Trunk, BRI So8, 16- or 30-port Analog Station, 16- or 30-port Digital Station, and 16- or 30-port Amphenol Digital Station for Nortel 7000 series phones.

Daughterboards are connected to the IPO Base Cards to allow for trunking. The possible options are 4-port analog trunk, BRI (not usually used in North America), or PRI (1- or 2-port PRI). By default the IPO PRI module only comes licensed for eight B-Channels. Additional licenses will be required to open channels 9-23.

The IP Office has two slots for SD Cards in the back of the unit. The System SD card contains a feature key that is tied to licensing. The IP Office will run for up to two hours with the System SD Card removed in unlicensed mode. IP Office voicemail is hosted on the SD card so voicemail will not function while the card is removed. A secondary SD Card can be used to back up data and host voicemail. The secondary slot supports SDHC Cards 4GB and greater. 

Changing the time and date on an IP Office

So Daylight Savings Time has begun in most of North America. As a result I have seen a few inquiries about changing the time on the IP Office.

The IP Office supports automatic daylight savings time changes.The dates are configured in IP Office Manager:

Under System, scroll down to see the Time Settings box
Ensure that Automatic DST is checked
Check the dates for the current year (you may need to use the drop down box to see the correct year)
If required hit the Edit button to change the dates.

If you do not have Voicemail Pro the time source can be set manually. Voicemail Pro configuration will match the system time to the time on the Voicemail Pro PC. Ensure that the time zone matches the Voicemail Pro server. If you have a PC that is always running Manager you can use this as a time source as well. The IP Office will retrieve the time from that source.

SNTP can be configured as another time source. This will retrieve the time from a PC on your network or from an Internet Time Server if your IP Office is connected to the Internet. If anyone requires assistance setting this up just say something in the comments and I'll do a post all about SNTP.

If the time on the IP Office is off by too much the time will not sync properly, regardless of your time source. To correct this you will have to change the time source to None, configure the time, then return the IP Office to your chosen time source.

Now on to the good stuff. How to change the time on an IP Office system.

1)      Check the time source on the IP Office. To change the time manually the time source must be set to None.

2)      Ensure that the time zone and UTC Offset are correct.

3)      Select a user to have System Phone rights. This can be any 1400, 1600, 9500, or 9600 phone except for the 1403 and 1603 model.

a.       In IP Office Manager, select the user

b.      Under System Phone Rights select Level 2

c.       Select the Button Programming tab

d.      Add a button with the action of Emulation à Self Administer, and enter 2  for the Action Data

e.      Label the button appropriately, I usually label it Administer

f.        Apply the changes and merge the configuration to the IP Office

4)      Go to your newly configured phone and press the Administer button that you programmed. The option to program the Time and Date will be displayed.

5)      Check the date by pressing Date or the time by pressing Time.

a.       The date is entered using the format specified in the system, using # or * to insert the / separators

b.      The time is entered using 24 hour format, using # or * to separate hours and minutes

c.       The key labeled <<< can be used to backspace

d.      Press Done when finished

6)      The phone will return to idle when you press done. You can remove the Administer button at this point if you want to prevent an accidental configuration change.

Once again I hope this helps! Comments and questions are always welcome.

IP Office Music on Hold

I've seen a lot of questions regarding Music on Hold on the IP Office. It's not nearly as simple as music was on the BCM but it's still quite easy. Starting with IP Office 3.1 you can use an external source There's always the easiest solution - plug it in to an audio source. There is a 3.5mm jack on the IP Office Control Unit. This will allow you to play anything and is a frequent solution for people who are happy to have the radio play as their hold music. There is no real effort required here - you just plug it in and point the IP Office to use this source and PRESTO! you have hold music. You can also configure an internal analog trunk as a music source. I've never seen this implemented myself, however my experience is quite limited. I'm guessing this would be an easy way to integrate a third party MoH source. This is supported on IP Office 6.1 and up. The way that seems to confuse people is using the internal source. This is a WAV file that is housed on the IP Office. There are some rather severe limitations here. The IP Office 500 and 500 V2 can support up to 90 seconds of recording time. The IP401 does not support an internal music source. Up to Release 4.2 there was only one supported source. In release 4.2 and up there are up to four supported sources, This is also the release in 90 second length is supported. Prior to Release 4.2 you can only have up to 30 seconds. Now on to loading the hold music. The IP500 V2 system can have the hold music loaded during the initial setup. I'm copying this right out of the Avaya documentation:

By default the IP Office will use internal music on hold by uploading a music file from the IP Office Manager PC. For IP500v2 systems, you can load a file onto the System SD card prior to installing it in the IP Office. The file must be of the following format and must be called holdmusic.wav. 1. Rename the music file holdmusic.wav. 2. Using a card reader, copy the file into the /system/primary folder on the System SD memory card. 3. If the IP Office is or will be configured for additional hold music files (up to 3 additional files), copy those files to the same location. The name of the additional files must match those specified in the IP Office system's configuration.

The format of the Wav file is important as well. In order to be played by the IP Office the file must be recorded with a bitrate of 128kbps and be recorded in a single channel (mono). The sample size must be 16-bit with an 8Khz sample rate. 

Post-install the Music on Hold can be added using Embedded File Management. Just switch to Embedded File Management mode and copy the file to the IP Office SD Card and upload holdmusic.wav to the PRIMARY folder on the SD Card. The other method of loading the IP Office hold music is to use the TFTP Server. When the IP Office is rebooted it will always look for a copy of holdmusic.wav on a TFTP server (if present). The IP Office Manager acts as a TFTP Server while running so this is an easy solution that requires no additional software. The file can just be placed in the working directory of the IP Office Manager software. If you need assistance in configuring additional MoH source files (IPO 4.2+) it is in the documentation. I hope this little bit helps people with their questions.

The IP Office supports multiple hold music selections, based on the incoming call route. You can use a WAV file or an analog extension to provide the music. In order to use different WAV files you need to add them to the control unit using embedded file management. You can enter a friendly name for the source. The source number is specified by the system, starting with 2.

Specify a WAV file using WAV:filename.wav. Specify an extension using XTN:222 (replace 222 with the extension number). When using an extension you need to change the extension to show that it is a music on hold source.

Once you have added your sources you can add them to the incoming call route: