What Sangoma CPD Detected That Asterisk Can't: SIT Tones

The built-in answering machine detection (AMD (answering machine detection)) in Asterisk is good at one thing: deciding whether a live answer is a person or a machine. What it cannot do is read the tones and signals that play before or instead of a real answer. The Sangoma NetBorder engine could, and that pre-answer classification is the main reason teams paid for its call progress detection (CPD (call progress detection)). Although the product is now end-of-life, the distinction it drew is still useful to understand.

Pre-answer signals Asterisk misses

When you dial a number, the network can answer with something other than a person or a machine. Special Information Tones, the three rising beeps you hear before a recorded error message, signal that a call cannot be completed. Disconnects and congestion (CONGESTION) indicate dead numbers or overloaded routes. Asterisk's AMD is not built to classify these; it focuses on the audio after a call is answered.

Sangoma CPD added accurate classification of this pre-answer call progress: SIT tones, plus more detailed grouping of disconnects and congestion. That gave operators a far clearer view of what actually happened on each attempt.

flowchart TD
  A[Outbound attempt] --> B{What the line returns}
  B -->|Human voice| C[Route to agent]
  B -->|Machine greeting| D[Answering machine]
  B -->|Fax tone| E[Fax]
  B -->|SIT tones| F[Number cannot complete]
  B -->|Congestion| G[Overloaded route]
  B -->|Disconnect| H[Dead number]
  F --> I[Asterisk AMD cannot label these]
  G --> I
  H --> I

Why the extra detail matters

Knowing that a number returned a SIT tone is different from knowing only that a call failed. A SIT tone usually means the number is bad, so you can retire that lead instead of redialing it for days. Better disconnect and congestion grouping tells you whether the problem is the number or a carrier route having a rough moment.

This accuracy fed straight into your called status (Called status) data. Instead of a pile of vague failures, you got specific outcomes you could trust, which made list cleanup and recycling decisions far easier. It also helped your drop math, since clearly non-human results could be excluded from the answered pool.

The payoff showed up most in lead hygiene over time. A campaign that cannot tell a SIT tone from a no-answer keeps recycling dead numbers, burning agent attention and dialer capacity on lines that will never connect. A campaign that can label those outcomes precisely retires the bad numbers early and keeps redialing only the leads worth a second attempt. Across a few weeks that difference compounds into noticeably higher contact rates from the same list.

What Asterisk gives you instead

Without a CPD engine, you lean on the hangup cause (Hangup cause) and SIP response codes your carrier returns to infer some of this. A busy or unallocated-number response is a clue, but it is coarser than tone-level classification and depends on the carrier reporting honestly. For many campaigns that is enough; for high-volume programs that need clean lead data, the gap is real.

Since the Sangoma engine is no longer sold, the realistic path is to combine well-tuned AMD with careful reading of carrier signaling, and to consider another gateway engine if you genuinely need pre-answer tone detection. The campaign routing settings stay the same regardless of which engine produces the classification.

For the full detection and routing story, read our AMD and CPD complete guide, and for the engine's history and end-of-life status see Sangoma CPD integration.

Want cleaner lead status without running your own detection gateway? VICIfast tunes the detection and carrier handling for you. See VICIfast pricing to get started.