What a carrier actually sees when your team dials

A carrier does not know what your rep said. It does not know your product, your list, or whether the person on the other end had ever asked to be called. What crosses the boundary is a SIP INVITE carrying a calling number, a called number, and, if the originating provider signed it, a token asserting something about that calling number. What comes back afterwards is a record: answered or not, and for how long.

That is the whole evidence base. Every judgement the network makes about your outbound calling is a function computed over those columns. If you want to understand why a number gets labelled, the useful move is not to argue about your intentions. It is to sit on the other side of the boundary and ask what is actually legible from there.

The signature answers a narrower question than most people think

Caller ID authentication is a legal requirement, not a best practice. 47 CFR 64.6301 requires a voice service provider to authenticate caller identification information for SIP calls it originates and will exchange with another provider, to transmit that information onward where technically feasible, and to verify caller identification information on authenticated SIP calls it receives from another provider. I read that from the 2023 CFR edition published on govinfo.gov, fetched 14 August 2026, and not from fcc.gov, which returned HTTP 403 to two fetch attempts during earlier research for this series.

Here is the part worth internalising. The attestation attached to a call is a statement by the originating provider about the relationship between a customer and a calling number. At its strongest it says: I know this customer, and I know they have the right to use this number. It is a provenance claim. It is not, and was never designed to be, an opinion about whether the call should ring.

That distinction explains a lot of confused vendor marketing. A perfectly signed call from a number you legitimately own can still be labelled, because the signature closes the impersonation question and leaves the wanted question completely open. What signing does buy you is the removal of an easy negative signal, which is not nothing, and is also not a defence.

The attestation-level definitions themselves are one place I could not verify from a primary source. The govinfo text of 64.6301 does not define A, B and C; it references sections that excerpt did not include. So treat the paragraph above as our reading of the framework rather than a quotation from a standards document.

Reading your own attestation turns out to be work in its own right. Our attestation parser exists because two providers encode the same fact four ways: Twilio reports stir_status, sometimes as a validation string with the letter buried in it, and sometimes stir_verstat; Telnyx reports attestation, or a nested stir_shaken.attestation. One fact, four field names, a regex to pull the letter out. If you need a parser to see your own signing coverage, you can be confident you are not seeing the analytics vendor's model of you at all.

The same module has a small design decision worth copying. When a batch of calls carries no attestation whatsoever, the attestation summary returns a null attestation-A rate and an explicit warning, rather than a rate of zero. Zero is a measurement. Null is the absence of one, and the two must not be allowed to look alike on a dashboard.

Why duration and answer rate carry so much weight

A party that cannot read content has to infer intent from behaviour. Answer rate and call duration are the two cheapest behavioural signals on the network, and they share a property that makes them unusually good for the purpose: they are produced by the callee, not by the caller.

You choose who to dial and when. You do not choose whether they pick up. You certainly do not choose whether they stay on the line. So a number whose calls are answered and then collapse within a few seconds is emitting the statistical signature of a call people hang up on, and no content analysis is required to see it. Volume is the third signal, and it is the one that separates a busy salesperson from a machine: a single identifier placing an implausible number of calls in a day is the pattern the models were built to catch.

We model the same signals on our side, because you cannot manage what you cannot see. Our number health model scores each number from its connect rate, the share of calls ending in under about 15 seconds, dials per day against a pacing guideline of 100 dials per day held as a single constant, any provider spam flag, and STIR/SHAKEN attestation-A coverage, banding the result into healthy at 80 and watch at 55. That is our model of the thing rather than the thing itself, and the difference matters enough that it has its own article.

One honest note about that model, because it is the kind of gap that usually goes unmentioned. The provider spam-flag input, the single field in the scoring model capable of carrying an actual carrier verdict, has no producer in non-test source at the commit this was written against. A grep for it returns the field declaration, its two uses inside the scoring file, and a comment elsewhere saying so; the same grep shape on the scoring function itself returns four non-test files, so the search works. The carrier verdict does reach the dialer, but through a separate auto-pause path, not through that field. The scoring branch is currently unexercised.

The verdict itself is not readable

Here is the asymmetry that makes this whole subject frustrating for the people living it. You can read your own call detail records in full. You cannot read the conclusion drawn from them.

There is no endpoint that returns what a given carrier's handset will display for your number. The closest available thing is a vendor's summary of its own view. Telnyx Number Reputation, which is what our stack reads, returns a spam risk of low, medium or high, plus null when there is not enough data yet, a spam category, four subscores on a 0-to-100 scale named maturity, connection, engagement and sentiment, and a timestamp for the last refresh. Every field is nullable and the entire object stays null until a first refresh has been collected. That is from the Telnyx developer documentation, fetched 14 August 2026, which is vendor documentation and not an independent source.

Read what that is carefully. It is one provider's opinion, exposed back to its own customer. It is not the label. It does not tell you which subscriber on which network sees what, and the category string is opaque enough that our own type documents it as opaque and treats it as a display value rather than something to branch on.

And while I was checking, the two sources disagreed. Our sync module's header says Telnyx refreshes each enrolled DID business-daily, and the seven-day staleness limit on a stored verdict is sized on that assumption. The vendor page fetched 14 August 2026 says scores update hourly. Both cannot be current. Our limit errs conservative in the direction that matters, since a stale verdict is discarded rather than acted on, but the comment is a claim about someone else's system and it has drifted from what that system now publishes. That is the ordinary fate of every hardcoded fact about a third party, and the only defence is to date it and re-check it.

Which of these you can actually move

Sort the four inputs by whether you can touch them, and the strategy falls out.

Dials per number per day is the one lever that is fully yours, and only if you own the numbers and can make a decision per number rather than per campaign. A team-wide throttle does not help here, because the model scores an identifier and not an organisation.

Answer rate and call duration are downstream of who you chose to call and why. They are real levers, but they are list and targeting decisions wearing telecom clothing, and they move slowly.

Attestation is a property of your trunk and your provider relationship. It is a configuration question with a yes or no answer, which makes it the cheapest of the four to fix and the easiest to leave broken for a year without noticing.

The label itself is not a lever at all. It belongs to somebody else, it is applied on evidence you cannot inspect, and removing it is a separate process with its own queue and its own timeline. That is a different article.

The uncomfortable summary is that none of the four is a message-level control. Nothing about how the call was written, framed or scripted enters the computation at any point, because none of it is visible from where the computation happens. A carrier is not forming an opinion about your company. It is scoring a pattern it can observe from the outside, and the inputs you hold are mostly structural: how many numbers you own, how hard you push each one, whether your calls are signed, and who you decided to ring.