What to send a carrier when escalating a call-quality fault
A useful call-quality escalation identifies specific failed calls and shows what arrived at your network boundary. “Calls sound robotic” may describe the user experience accurately, but a carrier cannot trace it without times, directions and call identifiers.
The minimum incident record
| Field | Example format | Why it matters |
|---|---|---|
| Start time | 2026-08-17 14:32:18 AEST | Locates carrier signalling and media records |
| Direction | Inbound to Brisbane office | Identifies the relevant call leg |
| Calling and called numbers | Redacted in email; full values in approved secure channel | Correlates routing records |
| Call-ID | From the SIP dialog seen at the boundary | Provides a precise signalling key |
| Symptom and direction | Remote party sounded broken to local user; return audio clear | Shows which RTP direction to inspect |
| Boundary evidence | Loss and jitter measured on received carrier RTP | Places the observed impairment at a useful boundary |
Collect at least three examples when the fault is intermittent, plus one good call made through the same route. A comparison call helps distinguish a permanent configuration error from a time-dependent network or upstream problem.
Describe sound in packet terms
User descriptions are still valuable. Translate them into a testable direction:
- Remote voice breaks up locally: examine RTP arriving from the carrier.
- Remote party hears broken local voice: examine RTP leaving toward the carrier and ask for its receive statistics.
- Both directions fail: investigate each stream separately.
- Audio changes after transfer or hold: include the signalling event and new media addresses.
Report packet loss, sequence gaps, interarrival jitter and unexpected source changes where the tools support them. Avoid turning a single jitter value into a universal pass/fail threshold. RFC 3550 describes RTCP reception reports and notes that jitter is most useful when compared over time or across receivers using the same calculation.
State what has already been ruled out
A compact boundary statement prevents the ticket returning to the beginning:
For the three calls listed, the PBX received impaired RTP from the carrier-facing interface. Internal extension-to-extension test calls during the same period were clear. No interface errors or local congestion were recorded. A control call over the secondary carrier was clear.
Only write what the evidence supports. A clean LAN capture does not prove the wider internet was healthy, and a speed test does not reproduce a real-time call path.
Attach evidence safely
Use the carrier’s approved secure upload channel for packet captures and full telephone numbers. State the capture point and timezone. Remove unrelated traffic, credentials and calls, but do not edit packets in a way that destroys timing or sequence evidence. Retain the original securely until the incident closes.
A reusable escalation summary
Impact:
First observed:
Timezone:
Affected sites or routes:
Failed call timestamps:
Call direction and symptom direction:
Call-IDs:
Codec and packetisation:
Evidence at our carrier boundary:
Control-call result:
Changes before the incident:
Secure capture reference:
Requested carrier check:
Ask a bounded question. “Please confirm the RTP source, loss and route for these Call-IDs” is more actionable than “please check your network”.
Related: VoIP QoS and call quality, voice-quality testing and packet captures.
Technical references
Scheduled for 23 August 2026. Handle call records and packet captures according to organisational privacy and retention requirements.