If you operate a voice platform, AI agent or contact center, “the call succeeded” leaves several questions unanswered. A signaling session can succeed while voicemail answers. A receiving endpoint can accept a call while audio works in only one direction. A handset can ring while displaying a warning that discourages the recipient from answering.
Separate six layers of evidence
Record what you observed at each layer. A combined score needs the supporting observations so your team can distinguish an identity problem from a media or routing failure.
| Layer | Question the test must answer | Evidence to retain |
|---|---|---|
| Authentication | What identity assertion was made, and was it verified where observable? | Attestation, verification result, source field and missing-data state |
| Signaling | How did the session request progress through the observed route? | Timestamped Session Initiation Protocol (SIP) or provider events, final disposition and call-leg identifiers |
| Ringing | Did the intended receiving endpoint actually alert? | Controlled endpoint event or handset observation, with settings |
| Answer | What accepted the session? | Answer event and endpoint classification: person, voicemail, interactive voice response (IVR) menu or test responder |
| Audio | Could both sides hear the intended content? | Directional media observations, onset timing and available quality measurements |
| Display | What identity or warning did the chosen receiving interface show? | Screenshot or identified observation source, time and device/app configuration |
With A-attestation, the originating provider asserts that it knows the customer and has verified their authorization to use the calling number. That claim belongs to the authentication row. RFC 8588 specifies the claim used to express the originating provider’s attestation. It does not certify delivery or the recipient’s experience.
Display deserves its own row even when audio is excellent. A business-name lookup and the actual incoming screen are different observations. Likewise, a warning does not establish that audio delivery failed. Keep both results so the team responsible for each issue can act on evidence.
Read the SIP trace without overclaiming
Session Initiation Protocol (SIP) is used to set up and control communication sessions. A SIP trace records signaling at the points where it was captured. You still need endpoint observations to establish what the recipient experienced.
The response definitions in RFC 3261 provide the starting point:
| Response | Defensible interpretation | Common overreach |
|---|---|---|
| 100 Trying | The next-hop server received the request and is processing it. | “The destination phone is ringing.” |
| 180 Ringing | The receiving user agent is attempting to alert the user. | “We observed the handset ring.” |
| 183 Session Progress | The response supplies information about session progress. | “A person answered.” |
| 200 OK to INVITE | The INVITE succeeded and the session was accepted. | “The intended person heard the agent.” |
Synthetic timeline: session accepted by voicemail
This sequence is illustrative, not a measured Spenza result. Times are relative to one fictional attempt; they are not performance benchmarks. The captured leg is the provider-to-controlled-destination leg.
| Relative time | Observation | Evidence source and limit |
|---|---|---|
| t + 0.0 seconds | A-attestation assertion recorded | Originating provider record; receiving verification is not captured |
| t + 1.2 seconds | SIP 180 Ringing received | Trace on the captured leg; no physical handset alert is observed |
| t + 8.0 seconds | SIP 200 OK to INVITE received | Same-leg trace; session accepted, answering party not yet classified |
| t + 8.4 seconds | Voicemail greeting heard | Controlled destination configuration and received-audio observation identify voicemail |
| End of attempt | No handset-display capture exists | Display remains unobserved; no conclusion about a visible name or warning |
The supported conclusion is that signaling progressed and voicemail accepted the session. Human pickup, upstream intelligibility and consumer-screen appearance remain unobserved.
Ringback is especially easy to misread. A caller can hear a locally generated tone or early media. RFC 3960 explains early media and ringing-tone generation; the sound in the originating call is not direct evidence of an audible alert on a particular receiving phone.
After a 200 response to INVITE, determine what answered. Voicemail, an interactive voice response (IVR) menu and a controlled test responder can all accept a session without the intended person participating. Then test media separately. Accepted signaling does not prove intelligible two-way speech.
Apply the same discipline to failures. A rejection or timeout needs route context and supporting observations. Do not turn a SIP status into a spam-label diagnosis without evidence of that classification.
Build a reproducible call-delivery test
Use controlled endpoints and agreed test traffic. Before placing calls, define the behavior your service requires and the evidence you will collect.
For a controlled conversation test, an example acceptance rule is: the intended endpoint alerts, the expected responder is identified, an agreed phrase is audible in each direction, and speech continues after a transfer if transfer is in scope. Choose timing thresholds from your service requirements before the run. Report pass when the required evidence meets those criteria, fail when you observe a mismatch, and inconclusive when required evidence is missing. Mark optional layers you did not test as unobserved.
1. State the question and the tested route
Write a narrow objective, such as whether the agent’s production route reaches a designated endpoint with audible speech in both directions. Record the originating number, provider, route configuration and application version. Note any forwarding, transfer or fallback behavior relevant to the scenario.
Run the test through that path. A manual call from an employee’s mobile phone cannot validate an AI agent’s SIP trunk or media connection. A call leg is one connection segment, such as the agent-to-recipient leg or a new connection created during a transfer. If the agent hands a caller to a human, identify the transfer leg as a separate part of the test.
2. Define the receiving environment
Record the destination network, endpoint type, device model or SIP software, and relevant app settings. A SIP responder and a consumer handset answer different questions. If handset behavior matters, include a handset observation in the plan.
For display testing, record whether the originating number is saved as a contact. Also capture call filtering, Do Not Disturb, forwarding and voicemail settings. A familiar contact name or local filter can change the observed experience, so keep these conditions consistent or identify them as separate scenarios.
3. Correlate the evidence before interpreting it
Use a shared time reference and preserve the time zone. Attach originating call IDs, destination events and any separate leg identifiers to one test case. Record attempt time, signaling progress, answer time, media onset (when audio begins) and termination where available.
Mark the source of each field. An application webhook, carrier trace and handset screen capture may describe different parts of the call. Do not merge their timestamps into one timing metric unless you know what the interval measures.
4. Capture authentication as its own result
Record the attestation and verification information exposed by your provider. Store the source field as well as the interpreted value. Missing information should be “unavailable,” not silently converted into authentication failure.
Twilio’s trusted-calling documentation explains the difference between attestation and validation. Other interfaces may expose different representations, so check the provider’s definition rather than assuming similarly named fields are interchangeable.
For Twilio, keep three interfaces distinct: incoming webhook StirVerstat reports available verification information; outbound status-callback StirStatus reports assigned attestation; the Calls API exposes stir_verstat through the Call resource update. Save the field name, interface, direction and raw value. An originating A assertion is not itself a receiving verification result.
5. Observe alerting and identify the answering endpoint
On a controlled handset, observe whether an incoming alert appears and whether the device audibly rings under its current settings. A SIP probe is a controlled test endpoint. Record the events it can observe and identify them as probe results.
Identify what answered. A short scripted response from a test responder can identify that endpoint; voicemail should remain voicemail. An automated answer rate must not be presented as a human pickup rate.
If the call never appears on the receiving device, preserve that negative observation alongside the originating trace. It narrows the investigation without claiming which intermediate system caused the failure.
6. Test audio in both directions
Have the agent and receiving endpoint each speak an agreed phrase. Verify what the other side hears. Check whether the beginning is clipped, whether there is unexpected silence, and whether speech survives pauses and interruptions. For an AI agent, include the opening prompt and one realistic turn change.
Where available, collect codec, packet loss, jitter and media timing. Identify which connection segment and direction each measurement covers. A healthy metric from one leg does not describe the entire path. Label an estimated mean opinion score as an estimate, and retain the underlying measurements where possible.
Record upstream and downstream separately. For the agent-to-destination leg, upstream means the agent’s phrase as heard at the destination; downstream means the destination’s phrase as heard at the agent. Save the phrase, observer, timestamp and result for each direction. Attach packet loss or jitter to its measured leg and direction; a provider-side metric alone does not prove end-to-end intelligibility.
For a transfer scenario, repeat the audio check after the handoff. Working audio before transfer cannot establish that the new leg works.
7. Capture display and warnings independently
Record the exact incoming name, number and warning on the chosen interface. Preserve a screenshot or identify the source that supplied the observation. Include its timestamp and configuration, and keep sensitive recipient details out of shared reports.
If the test has no handset or supported label-observation source, mark display as unobserved. Neither an authenticated caller ID nor successful probe arrival fills that gap. Verizon’s call feedback guidance explicitly treats authentication as only one factor in call treatment.
For a reproduced warning or incorrect name, continue with AI-agent spam-label troubleshooting by carrier, preserving the exact display and receiving settings.
8. Retest with a comparison and controlled changes
Keep a baseline record before changing configuration. Repeat the same scenario after a fix, using comparable endpoints and settings. When practical, change one variable at a time so the result is interpretable.
Include the number of attempts and the denominator for every reported rate. Define exclusions before drawing conclusions. If only some calls have media or display evidence, show those sample sizes separately. A small controlled test can diagnose an issue without establishing a population-wide delivery rate.
The VoIP number warm-up and testing guide provides related number-lifecycle context. Keep that work connected to repeatable observations rather than assuming time or traffic alone has resolved the issue.
Save one acceptance record
Use these fields in the test ticket so another operator can interpret or repeat the run:
| Field | Required entry |
|---|---|
| Objective and acceptance rule | Intended endpoint, required behavior and thresholds chosen before testing |
| Route and configuration | Originating provider/number, application version, destination and endpoint settings |
| Correlation | Attempt time and time zone, source call ID and any transfer-leg IDs |
| Six observations | Authentication, signaling, ringing, answering endpoint, directional audio and display |
| Evidence references | Trace, endpoint event, audio observation or screenshot supporting each result |
| Untested or missing | Layer, reason no result is available, and any narrower conclusion still supported |
| Decision and owner | Pass, fail or inconclusive against the stated rule; unresolved issue, next action and accountable team |
Filled acceptance record for the synthetic call
Test ID: SYNTH-01. Route: fictional agent provider to a controlled destination configured for voicemail. Objective: reach the agreed test responder with a phrase audible in each direction. Evidence references below are labels for the illustration, not downloadable logs or real test results.
| Layer | Observation and source | Result against the stated check |
|---|---|---|
| Authentication | Provider record AUTH-01 reports A; receiving verification absent | Pass for recording the originating assertion; verification inconclusive |
| Signaling | Same-leg trace SIP-01 contains 180 and 200 to INVITE | Pass for session acceptance only |
| Ringing | SIP-01 has 180; no endpoint alert observation | Inconclusive for actual endpoint alerting |
| Answer | Controlled voicemail configuration and received greeting AUDIO-01 | Fail: voicemail answered instead of the required test responder |
| Audio | Greeting heard downstream; no upstream phrase check | Inconclusive for two-way speech |
| Display | No handset or display-observation source in the test | Unobserved; excluded from this conversation test’s acceptance rule |
Overall decision: fail, because the required responder did not answer. The signaling pass cannot override that mismatch. If a required layer only lacked evidence and no mismatch had been observed, the decision would be inconclusive. Next owner: voice engineering, to inspect destination routing and voicemail configuration before retesting.
Report the failure at the layer where you observed it
A useful handoff names the observed mismatch and the next evidence needed. “A-attested, no handset alert observed” is more actionable than “carrier failed.” “Session accepted by voicemail” is more precise than “customer answered.”
| Observation | Next investigation |
|---|---|
| Authentication evidence is missing | Check provider support, route and field availability. |
| Progress appears in signaling, but no handset alert is observed | Review destination settings, routing and carrier-side evidence. |
| Session is accepted, but one side hears silence | Inspect media negotiation and the affected audio direction. |
| Two-way audio works, but the handset shows a warning | Investigate identity display and reputation through the relevant review route. |
| The agent’s call works until transfer | Correlate the new call leg and repeat its media checks. |
Assign the investigation to the team that can obtain the missing evidence. Confirm the cause before changing a route or treating the number as a reputation problem.
Scope the probe before trusting the result
Spenza’s Voice Observability begins with controlled delivery testing to a T-Mobile SIP probe. A pilot should identify the originating route, receiving endpoint, available events and media evidence. Additional carrier coverage and reputation observations need explicit validation.
That scope matters: a receiving probe can establish what happened at that endpoint. It cannot by itself establish a consumer handset’s display, a human’s willingness to answer or universal carrier delivery. Nor does testing guarantee removal of a spam label.
Test one production-relevant AI calling route with Spenza Voice Observability. Define the receiving probe, signaling and media evidence, acceptance rule and remaining unknowns before expanding the pilot. Bring the resulting acceptance record to engineering and support so each team can see what passed, failed or remains unobserved.
FAQs
Prepared by Spenza, a connectivity management and telecom platform provider. Contact the Spenza team for product-scope questions.
