Avaya IP Office SMDR Explained: A Field-by-Field Guide

If you manage an Avaya IP Office, each call that touches the system leaves a trail: a single comma-separated line of SMDR (Station Message Detail Reporting) output. The line records who called, who answered, how long the phone rang, how long the parties talked, and any transfers along the way. It is the raw material for call accounting, missed-call reports, and 911 alerting.

The line has thirty-odd fields, the documentation is scattered, and a couple of fields behave in ways that trip up first-time parser writers. This guide goes through the whole record, field by field, with realistic examples you can check your own parser against.

What SMDR is on IP Office

IP Office generates one SMDR record per call, at the end of the call. If a call is transferred or handled in stages, the system emits one record per segment and chains the segments with a shared Call ID and a Continuation flag. More on that below, because it is the number one parsing mistake.

Two things to know before you touch the configuration:

• IP Office is the TCP client, not the server. The system pushes SMDR records out to an IP address and port that you configure. Your receiving application has to be listening; you cannot connect in and pull.
• IP Office buffers records while nothing is listening. The system can hold up to 3,000 records while the receiving end is down. Once the buffer fills, the system discards the oldest records. A weekend outage on a busy system will cost you data, so run the receiver on an always-on machine.

Enabling SMDR output

In IP Office Manager:

1. Receive the system configuration (File > Open Configuration).
2. Select System in the left tree, then open the SMDR tab.
3. Set Output to SMDR Only.
4. Enter the IP Address of the machine that will receive the records.
5. Set the TCP Port. 33333 is the conventional choice and what most collectors expect.
6. Set Records to Buffer to the maximum (3000).
7. Tick Call Splitting for Diverts if you want forwarded calls broken into separate legs (recommended for accounting accuracy).
8. Save the configuration back with a merge; current releases apply SMDR settings without a reboot.

To verify output before pointing it at real software, run a listener on the target machine (nc -l 33333 on Linux, or any TCP listener utility on Windows) and make a test call. Within a few seconds of hanging up you should see a CSV line arrive. If nothing shows up, confirm the IP Office can reach the listener’s address and that no firewall blocks port 33333. Each record arrives as one CRLF-terminated line with no header row, so the first line you see is already data.

The SMDR record, field by field

The record is comma-separated, in fixed order. An empty field still appears as consecutive commas, so field position is reliable. Here is the layout:

Newer IP Office releases can append additional fields after these. Write your parser to read by position from the left and tolerate extra trailing fields rather than demanding an exact count.

Three worked examples

An answered inbound call. External caller rings DDI 290370, which targets extension 201; Sara answers after 9 seconds and talks for 3 minutes 45 seconds:

2023/02/06 09:12:08,00:03:45,9,02035551234,I,201,290370,,0,1000023,0,
T9005,LINE 5.1,E201,Sara Bell,0,0,n/a,n/a,...

A missed call. Same DDI, but the call goes unanswered. The caller hangs on for 25 seconds and gives up. Connected Time is zero; Ring Time records the 25 seconds they waited:

2023/02/06 12:47:51,00:00:00,25,07700900123,I,201,290370,,0,1000031,0,
T9002,LINE 2.1,E201,Sara Bell,0,0

A record with Connected Time 00:00:00 and Direction I is a missed external call. That one filter is the basis of any missed-call report you build on IP Office.

A transferred call. The caller reaches Reception (200), talks for 41 seconds, and is transferred to Raj on 214. Two records, one Call ID:

2023/02/06 14:03:10,00:00:41,7,02035556789,I,200,290370,,0,1000042,1,
T9001,LINE 1.1,E200,Reception,12,0
2023/02/06 14:03:58,00:04:12,5,02035556789,I,200,290370,,0,1000042,0,
T9001,LINE 1.1,E214,Raj Patel,0,0

The first record carries Continuation = 1, the Called Number stays 200 on both segments (it never becomes 214), and the 12 seconds the caller spent on hold while Reception announced the transfer land in the first record’s Hold Time.

Gotchas worth knowing

Count distinct Call IDs. A transferred call produces two or more records. Count raw lines and your inbound volume inflates while your average talk time collapses. Count distinct Call IDs instead, and sum Connected Time across segments for total talk time.

Internal calls carry Direction O. The Direction field alone cannot isolate external traffic. Combine it with Is Internal, or check whether Party1Device or Party2Device includes a T trunk device.

Called Number is the original target. To find who ended up handling a transferred call, read Party2Device on the last segment.

Call IDs restart on reboot. Key your storage on Call ID plus date, or you’ll merge unrelated calls after a power cycle.

Clock drift ruins reports. SMDR timestamps come from the PBX clock with no timezone marker. Keep the system on NTP, or your “calls after 6 p.m.” alert will fire at odd hours.

Voicemail looks like a party. A call answered by voicemail shows a V device as Party2. Decide up front whether your reports treat that as answered; for most businesses, a call that hit voicemail counts as missed.

Where PBXDom fits

The PBXDom collector does all of the above: it listens on the port you configured in Manager, parses each SMDR record by position, stitches continuation records back into whole calls, and turns the stream into live dashboards, missed-call alerts, and call accounting in the cloud. The collector installs in about 15 minutes on any always-on Windows machine, and IP Office is one of the systems we have supported since 2015. If you would rather skip writing the parser, start with the onboarding guide and point your SMDR output at it.