A VoIP call can ring correctly and carry no audio. It can register successfully and fail only for outbound calls. It can sound perfect in one direction and break up in the other. These are not contradictions: a business voice service is a chain of distinct systems.

Good diagnosis follows the call through that chain instead of treating every symptom as “SIP” or opening a collection of internet-facing ports.

The five layers of a business VoIP call

1. Provisioning and identity

The phone or softphone needs the intended account, service address, certificates, time and policy. A device can be fully provisioned yet unable to reach the service, or it can reach the service with the wrong identity.

2. Registration

Many SIP endpoints register a current contact location with a registrar. Registration proves only that a particular exchange succeeded for a period. It does not prove that inbound provider routing, outbound authorisation, media or call quality will work.

3. Call signalling

SIP is the signalling layer used to create, modify and terminate sessions. Requests and responses explain whether a call was attempted, challenged, redirected, rejected, cancelled or accepted. Read the response and the PBX/provider reason; “SIP error” is not a diagnosis.

4. Media

Voice commonly travels as RTP on a path that may differ from signalling. RTP sequence numbers and timestamps help receivers and monitoring systems interpret delivery, while RTCP can report reception quality. RTP itself does not guarantee bandwidth, ordering, timely delivery or quality of service.

5. Provider and telephone-network routing

The PBX or hosted platform hands calls to a provider, which applies account policy and routes them to or from the wider telephone network. Number presentation, inbound destination, emergency routing and nuisance-call controls may depend on this layer.

Record one failed call properly

Use a single representative call and capture:

  • date, time and time zone;
  • calling and called numbers in a protected case record;
  • endpoint/user and location;
  • inbound or outbound direction;
  • whether the endpoint was registered;
  • call identifier or provider reference;
  • SIP response and which system produced it;
  • whether each side rang, answered and heard audio;
  • duration and release reason;
  • media addresses/relay and quality counters where safely available;
  • affected and working comparison calls; and
  • recent endpoint, PBX, network or provider changes.

Redact credentials, authentication headers and unnecessary personal call data before sharing a trace. A SIP capture can contain far more identity and routing information than the visible symptom suggests.

Diagnose by symptom

The phone will not provision

Check power, network/VLAN, address assignment, DNS, time and access to the approved provisioning service. Confirm the device belongs to the correct tenant or PBX and that its identity has not already been assigned elsewhere. Do not factory-reset it until the configuration source and ownership are known.

Provisioning works but registration fails

Confirm the configured service name, DNS result, clock, certificate trust, supported transport and provider-side account state. Correlate the endpoint request with PBX or provider logs. Repeated authentication failures can trigger protective blocking; changing passwords without locating every device that uses the old one may prolong the fault.

Do not expose the PBX management interface or an unrestricted SIP service to “see if it works”. Use the provider’s supported connection and access model.

Registration works but outbound calls fail

Inspect the call attempt and response. Check dialled-number normalisation, outbound route, trunk selection, account permissions, credit/fraud controls and provider rejection reason. A registered extension does not automatically have authority to call every destination.

Inbound calls do not reach the expected user or queue

Confirm that the public number is assigned to the intended service and that provider routing reaches the correct PBX/tenant. Then inspect the inbound route, time condition, interactive menu, queue and final extension. Test a known external caller and preserve the provider call reference.

The call connects but has no audio

Signalling succeeded far enough to establish a session; now inspect the negotiated media path. Determine which side sent RTP, which side received it and whether a media relay or NAT mapping is involved. One-way audio often means the two directions follow different reachable paths.

Avoid broad port forwarding as a diagnostic shortcut. Current hosted PBX and provider designs may use relays, established outbound flows, session border controllers or platform-specific ranges. Apply only the supported design and limit sources where the provider permits it.

Audio breaks up, pauses or arrives late

Record packet loss, delay variation, round-trip latency and interface errors over the affected period. Compare wired and wireless endpoints, busy and quiet periods, sites, providers and directions. Check congestion, link errors, Wi-Fi roaming/interference, overloaded edge devices and competing uploads.

Quality-of-service marking cannot manufacture bandwidth or repair a lossy access link. It helps only when every relevant managed hop recognises and schedules traffic as designed. Measure the path before and after a change.

Calls drop after a repeatable interval

Compare the duration across calls and inspect session-refresh, registration, NAT and provider records around the release time. A consistent interval is useful evidence, but the value alone does not identify the faulty device.

Treat security as part of availability

A phone system is an internet-connected identity and billing system. Protect:

  • administrative interfaces with a restricted management path and strong authentication;
  • SIP and provider credentials as secrets;
  • endpoint and PBX software with supported updates;
  • outbound destinations and spend with least-privilege limits;
  • call forwarding, voicemail and recovery settings against takeover;
  • logs and alerts for unusual registration, destination and volume patterns; and
  • backups and tenant ownership so recovery does not depend on one person.

If call volume, destinations or costs suddenly change, stop treating the incident as ordinary call quality. Involve the provider promptly, preserve records and restrict the compromised path without destroying the evidence needed to explain it.

Diagnose nuisance and suspicious calls

Do not trust the displayed number by itself

Caller identity can be misleading or impersonated. A caller who claims to represent a regulator, bank, provider or support desk should be verified through a trusted published contact route. Do not disclose passwords, one-time codes or personal information because the caller ID looks familiar.

Preserve a minimal call record

Keep the date/time, displayed number, called number, ring group or recipient, frequency, voicemail or message content, provider call reference and relevant PBX call identifier. Preserve threats or fraudulent requests exactly enough for an authorised report, but avoid circulating recordings or personal data unnecessarily.

Separate blocking from investigation

Handset or PBX blocking may reduce disturbance for one presented number. Provider-side controls may be more effective across changing sources. Neither proves who originated the call. Avoid publishing or confronting an assumed individual based solely on caller ID.

Ask the provider a precise question

Provide representative call references and ask what their records show about ingress route, presented identity, account/trunk handling and available nuisance/fraud controls. Ask for a complaint reference number and keep every response.

Escalate appropriately in South Africa

ICASA’s published process says a telecommunications complaint must first be lodged with the service provider and assigned a reference number. Allow the provider 14 working days to resolve it. If the response is unsatisfactory or the issue remains unresolved, the complaint may then be referred to ICASA in writing with the supporting record.

That process does not replace urgent action for threats, fraud or crime. ICASA’s February 2025 scam warning tells recipients of suspected fraudulent activity to notify ICASA and report it to their nearest police station. Use the current official guidance for the actual case.

Verify the whole service after a change

Use an agreed call matrix:

  • internal call;
  • inbound call from an external network;
  • permitted outbound local and other required destinations;
  • transfer, hold, queue or voicemail if used;
  • two-way audio and caller identity in both directions;
  • remote and on-site endpoint paths;
  • emergency calling according to the provider’s approved procedure; and
  • an expected restricted destination or unauthorised action.

Correlate endpoint, PBX and provider evidence. “The phone rang” proves one useful fact, not the service.

Leave a supportable voice system

Document the tenant and service owner, number inventory, endpoint assignment, supported network design, provider escalation route, emergency-calling assumptions, backup method, certificate and software lifecycle, fraud limits and log-retention rules. Keep secret values in the approved credential store rather than the diagram.

VoIP stops being mysterious when each layer has an owner and evidence. Follow provisioning, registration, signalling, media and provider routing in order; change the first failed layer; then prove the call works in both directions without weakening the boundary around the system.