Skip to content
Phone Guides

Post

The SIP trunk is registered. So why have inbound calls stopped?

A PBX can show a SIP trunk as registered while the carrier can no longer reach it. That is not necessarily a contradiction. The two systems may be looking at different state, and neither status light proves that a fresh inbound INVITE can cross the current network path.

This is a particularly awkward fault because outbound calls may continue to work. Someone refreshes the registration, inbound service returns, and the incident is closed as “probably the firewall”. Then it happens again.

Before changing timers or opening ports, capture enough evidence to say which side stopped hearing the other.

A typical failure timeline

The times below are illustrative, but the sequence is common. Writing down this kind of timeline is often more revealing than staring at a green status icon.

Time What happens What it tells us
09:00 The PBX registers and receives a successful response with a 600-second expiry. The carrier accepted a temporary Contact binding.
09:05 The PBX sends another REGISTER and still shows the trunk as registered. The local registration process appears healthy at this point.
09:09 An inbound test call fails. No INVITE appears in the PBX capture. The failure is upstream of the PBX application.
09:10 An administrator refreshes registration and inbound calls immediately return. The refresh changed carrier or network state; it did not identify which one.

The useful question is not “was the trunk registered?” It is “what changed between the last working call and the first failed one?”

The green indicator is only local state

For a registration-based trunk, the PBX sends REGISTER to a registrar. After any authentication challenge, the registrar accepts a Contact address for a limited period. That binding tells the service where it should try to deliver new requests.

It confirms It does not confirm
The PBX believes its most recent registration succeeded. The carrier still considers the binding current.
A registrar accepted a Contact address for a limited period. That address remains reachable from the carrier’s inbound edge.
Authentication worked for that exchange. A NAT or firewall mapping still exists.
The registration path worked at that moment. The next INVITE will use the same path, match the intended trunk or produce working RTP audio.

RFC 3261—an Internet Engineering Task Force Request for Comments document defining SIP—makes registration a time-limited binding. Despite the modest name, an RFC is the primary technical specification for many internet protocols. The registrar can choose a different expiry from the one requested by the client, so the useful value is the expiry accepted in the successful response, not merely the number entered in the PBX interface.

Write down the failure before touching the trunk

“Inbound calls stop” is not enough detail. During the failed state, note:

  • the time of at least two failed calls, including timezone;
  • the called number and the calling network, suitably redacted in shared material;
  • what the caller hears: silence, busy, ringing, voicemail or a recorded failure;
  • whether outbound calls still work;
  • whether other numbers on the trunk behave differently; and
  • whether refreshing registration restores service, and for how long.

Those details let the carrier find the same attempt in its logs. They also stop a successful outbound call from being mistaken for proof that the inbound route is healthy.

Capture before you refresh the registration

Start a packet capture before refreshing the trunk. Keep it running long enough to see several refreshes and, ideally, the service fail again. A ten-second capture taken immediately after a manual refresh usually records the healthy moment and misses the fault.

For each successful cycle, check:

  1. Where the PBX sends REGISTER.
  2. Whether it receives a challenge and sends the authenticated request.
  3. Whether the final response is successful.
  4. The Contact address and transport advertised by the PBX.
  5. The expiry accepted by the registrar.
  6. Whether the next refresh occurs before that binding expires.

Do not assume every refresh is identical. DNS may select another proxy, a public address may change, or the PBX may advertise a Contact that is valid only from one side of a multi-WAN network.

Find the first boundary that did not see the INVITE

Place an inbound test call while the fault is present and keep the capture running.

No INVITE reaches the WAN interface

The next useful evidence is on the carrier side. Ask which address and port it used, which response it received, and which registration binding led it there. Likely areas include an expired or replaced binding, an unreachable advertised Contact, an IP allow-list, carrier routing, or a closed upstream NAT mapping.

If there is another router, managed service, carrier-grade NAT layer or upstream firewall in the path, “nothing reached our firewall” does not prove that no network device interfered.

The INVITE reaches the WAN but not the PBX

Now the local edge deserves attention. Check the destination address and port, the firewall decision, policy routing, session table, security inspection and any SIP-aware feature. With multiple WANs, confirm that replies leave through the expected interface and public address.

The PBX receives the INVITE and rejects it

This is no longer a registration reachability problem. Follow the SIP response. Source identification, trunk matching, DID format and inbound routing are common boundaries. A packet capture and the PBX activity log should agree on the response sent.

The extension rings but the caller is diverted elsewhere

Check who ends or answers the call. Carrier voicemail, PBX voicemail and an endpoint forwarding rule can sound similar to the caller. The call flow shows which system sent the decisive response.

Do not change timers blindly

Reducing the registration interval or enabling keepalives can restore service when a network mapping expires too early. It can also hide the underlying mismatch and add needless signalling. Make the change only after comparing these three values:

  • the registration expiry accepted by the carrier;
  • the interval at which the PBX actually refreshes; and
  • the idle lifetime of the relevant network flow.

They are related, but they are not interchangeable. SIP registration maintains a location binding. Transport keepalives and traffic may maintain or test a network flow. RFC 5626 deals explicitly with client-initiated SIP flows and detecting flow failure, but support and configuration vary across providers and platforms.

If a manual refresh reliably restores inbound calls, capture the failure before shortening the interval. Changing it first may erase the pattern that would have shown whether the carrier binding, NAT state or transport flow was actually expiring.

What the carrier needs from you

When the evidence points beyond your boundary, send the carrier a compact incident package:

  • two or more failed call timestamps;
  • the public source address used for registration;
  • the registrar or proxy selected at that time;
  • the last successful registration and accepted expiry;
  • whether an inbound INVITE appeared at the WAN edge;
  • the Call-ID if one reached your equipment; and
  • a sanitised capture covering registration and a failed call.

That is far more useful than “the trunk is green here”. It gives both teams a shared timeline and a specific boundary to investigate.

Green is not a health check

Treat the registration indicator as one observation, not a health verdict. The shortest reliable investigation is to compare the PBX’s registration refreshes with the carrier’s binding, then make an inbound call during the failed state and locate the first boundary where the INVITE disappears or is rejected.

For the underlying mechanics, see SIP registration troubleshooting, NAT and firewall troubleshooting, and packet captures for VoIP troubleshooting.

Technical references

Published 17 August 2026. Platform behaviour varies; confirm timer and transport changes with the PBX and carrier documentation for the deployment.