Diagnosing false answer supervision with the SIP Event Report

Your connect rate looks great, your drop rate looks ugly, and agents keep getting dead air when a call lands. That combination is the signature of False Answer Supervision: the carrier sent back an answered signal before a real person actually picked up the phone. The dialer believed the call was live, so it counted as a connect and handed dead air to an agent.

What false answer supervision does to your stats

Normal Answer supervision is the carrier telling your box the exact moment a human answers. When that signal fires too early — during ringing, or on a network tone — every premature answer inflates your connect count and, because there is no human, often turns into a drop or a hang-up. Your Drop rate climbs for reasons that have nothing to do with pacing or agents, and a 200 OK in the SIP response code column hides the lie.

sequenceDiagram
  participant C as Carrier
  participant D as Dialer
  participant A as Agent
  C-->>D: 200 OK answered
  Note over C,D: but the phone is still ringing
  D->>A: route the call as connected
  A-->>A: hears dead air
  Note over A: short ring time then drop

How to spot it in the SIP Event Report

The SIP Event Report is the tool built for exactly this. It only works if SIP Event Logging is enabled for the campaign, so turn that on first. Once messages are logging, the report lets you sort the SIP messages for calls by several criteria — the one that matters here is Ring-Time. Sorting Ring-Time UP and DOWN is how you separate real answers from fake ones.

1. Enable SIP Event Logging on the campaign and let it run long enough to gather a representative sample of calls.
2. Open the SIP Event Report and sort by Ring-Time ascending. Calls that show answered with a near-zero ring time are the suspects — a real person needs at least a few seconds to reach and answer the phone.
3. Sort descending too, to confirm your genuine connects have believable ring times. A clean carrier shows a spread; a bad one shows a pile of answers at zero or one second.
4. Note which trunk or Carrier the zero-ring answers cluster on. False answer supervision is a property of the route, so the fix is to move traffic off that path.

Why this hides from your normal reports

Most of your day-to-day reports only know whether a call was answered, not how long it rang before that answer arrived. A premature answer looks identical to a real one in those summaries — same 200 OK, same connect tick, same line in the connect column. The only place the truth shows is the timing, and that is exactly what the Ring-Time sort surfaces. A real human answer has a plausible gap between ring and pickup; a faked one collapses that gap to nothing.

It also tends to come and go. A route can behave for days and then start firing early answers when it gets congested or when it reroutes your traffic through a cheaper downstream path. That is why a one-off sample is not enough — leave SIP Event Logging on through a few busy hours so you catch the route on a bad stretch, not just a quiet one. If the zero-ring cluster only appears at peak, that is a strong hint the provider is overflowing your calls onto a low-quality path under load.

Once you can point at the route producing zero-ring answers, the action is simple: raise it with the provider with the unique IDs in hand, or shift the campaign to a cleaner trunk. For the wider method see the troubleshooting playbook, and for a full tour of the report read how to read the SIP Event Report. If chasing carrier quality is not how you want to spend your week, VICIfast runs the box so you do not have to.