Symptoms

Any of the following, alone or in combination, may indicate this issue:

• Recordings that do not match the actual call — wrong caller ID, wrong agent, or wrong extension attached to the recording
• Recordings that are out of sync with when the call actually took place (timestamps do not line up with the real call start/end time)
• Recordings that show as existing but contain no audio
• Recordings missing entirely for calls that are known to have occurred
• Excessive delay between when a call ends and when its recording becomes available (backlog/processing delay)
• Backend logs showing high volumes of entries such as: Can't determine whether or not to record. Requeue for later, often correlating with the calling_party field being empty on a large percentage of requests

Cause

Why this happens

Chronicall/ACR's port mirror recording engine associates a call recording with the correct call based on SIP signaling exchanged between the PBX and the external SIP trunk provider — specifically, the moment a call is offered to the PBX (entering a hunt group or auto-attendant), not the moment it is subsequently offered to an individual agent's extension.

If the network's port mirror (SPAN) is instead configured to capture traffic between the PBX and the internal office phones, the recording engine never sees the trunk-side signaling it needs. It falls back to using the internal offer-to-agent event as a substitute, which does not correspond to the actual call timeline and frequently carries no real caller ID (since internal signaling uses an internal interface identity rather than the original PSTN caller information).

There are two distinct ways this misconfiguration commonly occurs:

1. SPAN source set to the wrong (internal) switch port. The SPAN/mirror source is pointed at the switch port connecting the PBX to the internal LAN (where phones register) instead of the port carrying trunk traffic.
2. SIP trunk traffic bypasses the switch entirely (SD-WAN topology). In some network designs, the SIP trunk terminates directly on an SD-WAN appliance, which proxies the call to the PBX over a direct connection that never touches the LAN switch. In this scenario, no switch port carries the trunk traffic at all, so no amount of switch-level SPAN reconfiguration can ever capture it — the traffic must be mirrored at the SD-WAN appliance itself.

This second scenario was confirmed via SD-WAN session logs showing a SIP session established directly between the SD-WAN appliance's internal proxy address and the PBX, with both forward and reverse traffic traversing the same interface — never touching the switch..

Resolutions / Fixes

Follow these steps in order. Each step includes how to confirm it worked before moving to the next.

Step 1

Confirm the port mirror is capturing internal-only traffic

Capture a PCAP on the Recording Library server's mirror-facing NIC during a few live test calls (include at least one inbound call from an external cell phone). Review the capture for:

• From: header on inbound SIP INVITEs — From: sip:acme@{PBX-IP} or a bare internal extension number indicates internal-only traffic. A real external phone number in the From header indicates trunk-side traffic is present.
• IP address scope — if every IP address in the capture is private (10.x.x.x, 172.16–31.x.x, 192.168.x.x) with no exceptions, the capture is internal-only.
• H.323 (port 1720) traffic volume — high H.323 volume combined with CCMSInterface-dominated SIP traffic strongly indicates an internal-only mirror.
• RTP port range — Avaya IP Office commonly uses UDP ports 40000–65000+ for RTP, not the standard VoIP range of 16384–32767. Filter accordingly or the RTP traffic may appear absent when it is not.

If the capture shows only internal traffic, proceed to Step 2.

Step 2

Reconfigure the SPAN source to the trunk-facing switch port

1. Identify the switch port that carries traffic between the PBX and the SIP trunk / SD-WAN uplink (not the port connecting to internal phones).
2. Reconfigure the SPAN session's source to that port. The SPAN destination (feeding the Recording Library NIC) does not need to change.
3. Ensure the SPAN session and any capture filters are not scoped to a single VLAN unless that VLAN has been confirmed to carry the trunk traffic. If unsure, request an unfiltered capture first, then narrow the scope down.
4. Take a new PCAP and repeat the checks in Step 1.

If the new capture still shows only internal traffic, proceed to Step 3.

Step 3

Determine whether the SIP trunk bypasses the switch (SD-WAN topology check)

Ask the network team directly: does the SIP trunk terminate on an SD-WAN appliance that connects directly to the PBX, or does it pass through the LAN switch?

If the SD-WAN appliance proxies the SIP trunk directly to the PBX without touching the switch, no switch-level SPAN configuration will ever capture the trunk traffic. This can be confirmed via the SD-WAN appliance's own session/flow logs, which will show a SIP session established between the appliance's internal proxy address and the PBX with both forward and reverse traffic on the same interface.

Step 4

Mirror the traffic at the SD-WAN appliance (if Step 3 confirms bypass)

1. Confirm with the SD-WAN vendor/network provider whether the appliance supports port spanning/mirroring internally (most SD-WAN and firewall-class appliances do).
2. Identify an unused port on the SD-WAN appliance, or free one up by relocating an existing low-priority connection.
3. Configure the SD-WAN appliance to span the port carrying the SIP trunk traffic to the unused port.
4. Run a physical cable from that unused port directly to a NIC on the Xima Recording Library server.
5. Take a new PCAP on that NIC during live test calls and confirm trunk-side SIP signaling is now visible (real caller ID present, SIP traffic between the SD-WAN proxy address and the PBX).

If switch-level reconfiguration and SD-WAN-level spanning are both not feasible, consider:

• Installing an inline network tap between the SD-WAN appliance and the PBX, with a copy sent to the Recording Library NIC.
• Re-engineering the network so trunk traffic passes through the switch (more disruptive; not typically the first option).
• Evaluating an alternative recording method not dependent on network topology, such as Avaya DevLink-based Active Recording (requires a base Avaya Call Reporting license) or legacy VM Pro-based recording.

Step 5

Verify the fix

1. Take a fresh, unfiltered PCAP on the Recording Library NIC.
2. Place at least one inbound call from an external cell phone and one outbound call to an external number during the capture, noting exact times.
3. Confirm SIP INVITEs show a real external caller ID in the From: header for the inbound test call.
4. Confirm the capture includes traffic to/from the trunk provider or SD-WAN proxy address, not exclusively internal-to-internal traffic.
5. Test actual recordings end-to-end: correct caller ID, correct agent association, correct timestamp, and audio present.

Step 6

Expect a temporary processing backlog

Immediately after a SPAN/mirror change, the Recording Library may need time to process a backlog of recordings that were queued waiting for association ("limbo"). Processing delays of several minutes to roughly 20 minutes per call are expected during this catch-up period and typically resolve on their own. A small number of recordings captured during the transition period may still be missing audio or fail to associate — these should be reported to Xima Support for confirmation but are not necessarily indicative of an ongoing problem

Preventions / Tips

• Ask the trunk-vs-internal question early. Before adjusting any Chronicall/ACR settings, confirm whether the port mirror is capturing trunk-side or internal-side traffic. This single question is the highest-value diagnostic step for any port mirror recording complaint.
• Ask about SD-WAN topology up front for any SD-WAN-managed site. If an SD-WAN appliance manages the SIP trunk, confirm early whether trunk traffic passes through the LAN switch or connects directly to the PBX. If it bypasses the switch, standard SPAN troubleshooting on the switch will never succeed.
• Do not assume the standard RTP port range. Avaya IP Office commonly uses UDP 40000–65000+ for RTP, which differs from the typical VoIP RTP range (16384–32767). Using the wrong filter can make it appear that no RTP is present when there is a large volume of it.
• Do not assume every external IP in a capture is the SIP trunk. Background traffic from unrelated devices (cloud services, DNS, software updates) can appear as external IPs in a capture. Confirm any candidate IP is actually carrying SIP (port 5060) or RTP.
• Avoid scoping captures or SPAN sessions to a single VLAN unless that VLAN has been confirmed to carry the trunk traffic — an overly narrow filter can mask whether a SPAN change had any effect.
• Change one variable at a time. Making multiple changes in parallel (recording software settings, SPAN configuration, VLAN filters) makes it harder to isolate which change had which effect.
• Confirm what Xima Support can and cannot do. Xima Support can review PCAPs and advise on what traffic the recording engine requires, but does not configure customer network equipment (switches, SD-WAN appliances, VLANs). Network-side changes must be made by the customer's network team or SD-WAN provider.