Troubleshooting

What goes wrong with Avaya IP Office SMDR Connector, how to recognise it, and what to do.

No calls arriving

Work down this list; it is ordered by how often each one is the answer.

1. Endpoints → Health and Last Call Received. If Last Call Received is recent, calls are arriving and your problem is matching, not delivery. Skip to the next section.

2. Request Log — are requests arriving at all?

• No rows — the listener is not reaching Odoo. Run healthcheck.py on the listener host.
• Rows with 401 — wrong token, or the source IP is not in the allowlist. Both return 401 on purpose, so check both.
• Rows with 413 — the payload cap is lower than the listener's batch.
• Rows with 429 — the rate limit is too low for your call volume.

3. Did the PBX ever connect?

journalctl -u avaya-smdr-listener | grep connected

No line means IP Office is not dialling out to the listener.

4. Check the direction. IP Office Manager → System → SMDR must point at the listener's address and port. The PBX is the client; the listener waits. This is the most common cause and it fails silently — both ends look healthy.

5. Firewall. The listener's port has to be reachable inbound from the PBX.

Calls arrive but match nothing

Matching compares the trailing Phone match digits — nine by default.

• Numbers stored with country codes and matching the wrong contact: raise it.
• PBX adding a trunk prefix that eats the significant digits: lower it, never below 6.

Change the setting, then select the calls and press Reprocess. Existing calls are not re-matched automatically by a settings change, though the scheduled action Avaya: re-match unmatched calls does pick up calls as contacts are added.

The same call is in the list twice

PBX_UTC_OFFSET_MINUTES was changed on a running system whose IP Office does not emit unique call ids. The id is synthesised from the timestamp, so shifting the clock makes one call look like two.

Change it during a quiet period, or put the PBX clock on UTC and leave the offset at zero.

Retries are not a cause: duplicate prevention is a database constraint, not application logic, because the listener retries as a matter of course.

A ringing group produced five calls

Expected. IP Office emits one SMDR record per leg and all legs are kept — discarding them would lose who actually answered.

Mark the extension as a hunt group under Configuration → Extensions. Missed-call activities are suppressed for hunt groups, which is the part that would otherwise be unusable.

Missed calls are not creating activities

Three things, in order:

• The endpoint's Missed calls create activities switch.
• The extension is mapped to an Odoo user — the activity needs an assignee.
• The extension is not marked as a hunt group, for which activities are deliberately suppressed.

Leads are being created for the same unknown number repeatedly

Missed calls create leads is doing exactly what it says. It suits a sales line and not a support line, where one unhappy caller rings six times.

Turn it off on the endpoint; the calls are still logged.

The agent column is empty

Extensions are not mapped. Configuration → Extensions — map the PBX extension to an Odoo user. Calls are logged without it; they simply have no owner, and the per-user figures have nothing to group by.

I cannot see the raw SMDR record

It is restricted to Avaya Technical Administrator. It contains every dialled number, which is why it is not on the sales manager's screen.

I cannot see the webhook token

Same group. Show Credentials on the endpoint reveals it once; afterwards it is masked. If it is lost, rotate — rotation keeps the previous token alive for a grace period so the listener can be restarted without losing records.

Old calls are piling up

Archiving and deletion are both off by default. Settings → Avaya Telephony → Archive calls after hides them while keeping them; Delete calls after destroys them.

Think before enabling deletion. A call log is often the evidence for a dispute about what was agreed.

Odoo was down for an hour. What did I lose?

Nothing, assuming the listener stayed up. The SQLite spool holds each record until Odoo confirms it is stored, so an outage costs delay and nothing else. That is the whole reason the spool exists.