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!

Avaya SBCE Network Interface issues

 I was tasked with configuring a small Avaya SBC this week. I was sent a Dell 3240 system for this job. 

When I tried to power it on I was not able to get it to boot. I did some digging in the product manual and found a chart that showed what different LED sequences meant. I was getting three amber flashes and one white flash which meant that the CMOS battery was dead! Fortunately I keep a few batteries around and I was able to swap it out. The system powered on right away and I was able to load the SBC software.

You would think that would be it - off to the races, ready to go. Unfortunately there was one other problem. I was able to install the software and perform the CLI installation procedure without any hiccups. When I went to connect it to the lab network to perform the web config, though, I found that I was unable to reach the SBC and the SBC Was not able to reach my network. When I checked the interfaces it looked as if M1 was down! Not just that, but I also saw an A2 address that I thought was out of place. The additional network interface was my smoking gun - it was the built-in network interface. I went into the BIOS and disabled it, but that put me in worse shape - the M1 interface was now just missing entirely. I reloaded the software and everything worked out.

Here are some of the things I searched:

• Avaya SBC network interfaces wrong
• Avaya Dell 3240 bios
• M1 interface not responding
• Avaya SBC MAC Address wrong
• Avaya SBC M1 Down

Installing the Avaya SBCE on Proxmox

It has been a while since I've posted anything on this blog, and that is an issue. It's not that I've been slacking - I started a new blog about non-telecom stuff, after all. I just haven't had anything exciting to write about in a while.

All of that changed today. I made a decision: I'm going to do something that hasn't been documented before. So I decided to try to get an Avaya SBCE installed in an environment that is not officially supported - Proxmox.

I had to make two attempts. I wasn't able to get the system to boot when I used the qcow2 image that was available from Avaya, so I blew that machine away and created a new VM with no OS.  I'm not going to go into the failed install - I learned from my failures so that you can succeed on your first try.

I chose to do EMS+SBCE for my deployment rather than separate out the servers. I will document the differences that would be necessary to have a standalone EMS. A standalone SBCE has the same configuration.

First, I had to build the VM. In order to determine how to configure it, I looked at the Avaya documentation. I mostly went with the Small SBC because I'm just doing a Proof of Concept, and not a production system. I did opt to go with six network interfaces though. If I were deploying a true production system I would have created one SBC and one EMS. 

In Proxmox, I clicked on Create VM and started to build by virtual machine. On the General tab I selected my Proxmox node and entered the VM name. I accepted the VM ID that was automatically created.

The OS was loaded from an SBCE ISO that I had uploaded to the software library on my server. The OS is Linux, and I selected the 2.6 Kernel.

I didnt' make any changes to the graphics card, machine, or SCSI controller. I did ensure that I used a UEFI BIOS. I selected the appropriate storage pool.

I created a single 64GB disk. If I was planning on creating a production system I would consider expanding the disk to 160GB to support additional logs, as the Avaya documentation suggested.

I chose one socket, 2 cores, for a total of 2 cores. If this were a standalone SBC I would have set this to 4 cores. A standalone SBC Requires 3 cores. Proxmox doesn't do CPU reservation like VMWare, so there is a risk here. If I were creating a production system I would enable CPU affinity and lock the SBCE to specific cores. Maybe I'll write something up about that on my tech blog some day.

I gave this the 4GB o RAM that the small size requires. If I were deploying this as a standalone SBC or an EMS I would have set this to 8GB.

You can't configure more than one NIC during the initial setup of a virtual machine in Proxox, so I left the existing interface in place on my default bridge. 

I reviewed the configuration and made sure that I did not have Start after created checked - I need to add the additional network interfaces before I do that. 

I have configured VLAN 11 as my trusted network and VLAN 12 as my untrusted network. VLAN 11 is not able to reach the Internet, and VLAN 12 is only able to reach the Internet. I ran through the installation without knowing what order the interfaces were going to be in, so after I started up the machine I confirmed the interface order. Next time I'll assign the VLANs when I create the interfaces. Of course, it's important to confirm the MAC Addresses after the system comes up.

M1: net0    Management VLAN

M2: net1    Segregated network for HA

A1: net2    Inside network 1

B1: net3    Outside network 1

A2: net4    Inside network 2

B2: net5    Outside network 2

Once the network interfaces were added I started the virtual machine. It took a minute but the Linux installer began. I selected the default option: Install ASBCE with Redhat Enterprise Linux 8.10. In retrospect, I couldn't help but wonder if the proper choice should have been Install ASBCE RHEL8.10 using CDROM. If I do it again I will select the CDROM option. 

The installation script ran and created a bunch of different partitions and installed a lot of packages. After some time the SBC settled down and prompted me to enter Manual Configuration Mode.

I selected Option 1 to configure using Command Line Mode. I was prompted for the basic configuration.

I was prompted for information for the self-signed certificate that the SBC presents.

The time zone selection was next - first a region, then a country, and finally a time zone. 

I did not have a proper NTP server configured, so the system did kick back an error that I didn't capture - it was asking me to set a proper NTP server. I selected Option 3 - to skip NTP.

Now I'm able to reach the SBC web interface.

After agreeing to the EULA I am able to log in with the default credentials. I must immediately change the password and am logged out again. After logging in again I am now ready to configure the SBC.

Oh wow, you made it to the end of the post! As a reward, enjoy this link to my tech blog. https://blog.aarondydck.ca/

NRS Backup location

 Any time I've had to recover a signaling server the biggest concern is extracting the NRS database and recovering it. The NRS backup file can be pulled as long as there is access to the file system.

The file is located at /var/opt/nortel/sps/backup/nrsback.tar

Once the NRS file is in hand the rest is easy.