GOIP Registration Errors on a SIP Trunk: A Diagnostic Order That Works

GOIP registration errors on a SIP trunk are usually reported as one symptom and caused by one of five faults, and the order in which you test them decides whether the fix takes twenty minutes or two days. The trunk log holds the answer; the device console rarely does.

This is a diagnostic order for engineers who already have the gateway mounted and the trunk configured. It assumes you know what the hardware does and focuses on the sequence that isolates a credential problem from a transport problem, an address-translation problem and a keep-alive mismatch, including the cases where the registration passes through a SIM bank rather than a directly inserted card.

What do 401, 403 and 408 responses each tell you?

Each code points at a different layer of failure.

A 401 is an authentication challenge, a 403 is a refusal after credentials were presented, and a 408 means the request timed out before any server answered it.

Session Initiation Protocol defines these responses in RFC 3261, and the distinction matters because each one eliminates a different half of the configuration. A repeated 401 on a trunk that was working yesterday points at a changed credential, a regenerated secret, or a platform that has begun challenging requests it previously accepted. A 403 tells you the platform recognised the request and decided against it, which moves the investigation to authorisation, source address rules or account state rather than to the password.

A 408 is the code that misleads most teams, because it looks like a credential failure in a dashboard summary but is actually a reachability problem. Nothing arrived at the far end in time, so nothing was evaluated. If you see 408s, stop editing credentials and start checking whether the request left your network at all.

The practical rule is to read the response code before you read any status label in the user interface. A device console that reports “registration failed” is telling you the outcome, not the cause, and the cause is always in the response.

Which side should initiate registration?

The side that holds the account credentials should register.

In most carrier and platform deployments the gateway registers to the platform, but hosted PBX arrangements sometimes reverse that direction, and a mismatch produces a trunk that never appears to attempt registration at all.

Direction changes everything about where you look. When the gateway is the client, it sends a registration request and expects a challenge and an acknowledgement; the exchange follows the flows catalogued in RFC 3665. When the platform is the client, your gateway is waiting for an inbound request that will only arrive if the platform can resolve your address, which introduces a second dependency: name resolution and service discovery.

If your configuration depends on the platform resolving your endpoint, check that the service records exist and point at the right host. Service location through DNS SRV records is specified in RFC 2782, and a stale or missing record produces exactly the symptom teams describe as “the trunk is down”: no registration attempts appear in either log, because the request is being sent to a host that no longer answers.

Reading the trunk log instead of the device console

The trunk log is the only place where a failed registration shows its cause, and it rewards being read in a fixed order. Look for the outbound request first, then the response, then the retry interval. If there is no outbound request, the problem is above the gateway: routing, address resolution or a configuration that was never applied. If there is a request but no response, the problem is reachability or a firewall in the path. If there is a response with a failure code, the problem is credentials, authorisation or timing.

Device-side views compress all three into a single state, which is why a console can show a red indicator for a trunk whose actual fault is a closed port. Where you have both, treat the trunk log as the source of truth and the console as a summary.

What the log shows	What it rules out	Where to look next
No outbound request at all	Credentials and authorisation	Interface selection, routing, service records
Request sent, no response	Credentials and account state	Transport, port reachability, upstream filtering
401 followed by no retry	Reachability	Stored credential, secret rotation, challenge handling
403 after a challenge	Password correctness alone	Authorisation rules, permitted source address, account status
Registration succeeds, then expires	Initial configuration	Keep-alive, expiry interval, NAT binding lifetime

How do credential and transport mismatches cause GOIP registration errors on a SIP trunk?

Most failed binds are one field away from working.

Credentials are compared exactly, and transport is negotiated separately, so an authentication that is correct over one transport can fail over another even though nothing about the account changed.

Start with the account identifier. Some platforms expect the full address of record, others expect only the extension or user part, and a mismatch produces a 401 that never resolves no matter how many times the secret is re-entered. Then confirm the secret has not been regenerated on the platform side, because a rotated credential is indistinguishable from a typo in the log.

Transport is the second axis. Transmission Control Protocol and User Datagram Protocol behave differently under packet loss, and a platform that expects one will not accept the other silently. The registered port numbers that SIP uses are catalogued by the Internet Assigned Numbers Authority, and checking those against your configuration is faster than guessing; the registry is maintained at IANA SIP parameters. Where the platform publishes a preference order, follow it rather than testing both.

Finally, check whether the trunk is being challenged for an identity the gateway cannot present. When a deployment uses a SIM bank in front of the gateway, the identity presented to the platform can be tied to the slot that holds the card, so a slot-mapping error surfaces as an authentication failure. The SIMBANK128, for example, exists to centralise SIM storage and dynamic allocation for GoIP gateways with hot-swapping and failover, and it is priced at $1,600 as a published list price; when the mapping between logical slot and physical card drifts, the registration that fails is the one belonging to the affected slot only.

Why does address translation break a working registration?

Translation breaks the return path, not the request.

The gateway sends its private address in the contact header, the platform stores it, and every subsequent inbound request is sent to an address that does not exist on the public network.

This is the failure that produces a successful registration followed by one-way audio or no inbound calls at all. The registration itself can look perfect in both logs, which is why teams often conclude that the trunk is fine and search for the fault in the audio path. The evidence is in the contact header: if it carries a private address, the platform will use that address for anything it initiates.

Two remedies are in common use. The first is to have the gateway advertise the public address it is actually reachable on, which requires the address to be stable. The second is to let the session border controller or the platform rewrite the contact information at the edge, which keeps the gateway configuration simple but makes the intermediary part of the signalling path. Either works; mixing them usually does not.

Test the result from the outside. An inbound request initiated by the platform is the only proof that the return path is correct, because it exercises the stored address rather than the address the gateway claims during registration.

How do keep-alive and expiry settings drop a registered trunk?

The lease expires while the network path is already closed.

If the gateway sends keep-alive traffic less often than the translation binding expires, the platform cannot reach it even though the registration record still looks current.

Registration is a lease. The platform holds the binding for the expiry interval the gateway requested, and it will keep sending requests to that binding until the lease ends, whether or not the path is still open. Network address translation devices maintain their own timers, and the two intervals are independent. When the translation timeout is shorter than the registration expiry, there is a window in which the platform believes the endpoint is reachable and the network disagrees.

The mechanism for keeping a binding alive from behind translation is specified in RFC 5626, which is worth reading before choosing values, because it distinguishes between keeping the transport open and refreshing the registration. Those are two different operations, and a gateway can perform one while neglecting the other.

Provisional response reliability is a related setting. Where a platform expects reliable provisional responses under RFC 3262, a gateway that does not send the acknowledgement can have its registration treated as incomplete. This is uncommon in carrier trunks and more common in enterprise platforms, which is exactly why it is worth checking before rebuilding a working configuration.

A five-step diagnostic sequence

Work the sequence in order and stop at the first step that produces evidence. Steps one and two take minutes, and they eliminate the two largest categories of fault before any configuration is changed.

1. Confirm the registration direction and the address of record the platform expects. A mismatch here makes every later test meaningless.
2. Read the trunk log for an outbound request. No request means the fault is in routing or name resolution, not in credentials.
3. Read the response code: 401, 403 and 408 lead to three different investigations. Record the code before changing anything.
4. Verify the return path by asking the platform to initiate a request to the gateway. A successful inbound request proves that the stored contact address is reachable.
5. Compare keep-alive and expiry intervals against the translation timers in the path, then adjust one value at a time and re-test.

Change one variable per test. Multiple simultaneous edits are the single most common reason a fix cannot be reproduced on the next unit, and they make the log useless as a record of what worked.

When the trunk registers and then drops every few minutes, what is failing?

A repeated drop points at the lease, not at the credentials.

A trunk that registers cleanly and disappears on a regular cycle is almost always losing its binding to a timer mismatch or to address translation, not failing to authenticate.

The regularity is the clue. Authentication failures are irregular, because they depend on what is being attempted; timer expiry is rhythmic. Measure the interval between the registration and the drop. If it is consistent, compare it with the expiry value the gateway requested and with the translation timeout on the path, and you will normally find the shorter of the two.

If the interval is not consistent, look instead at the transport. A trunk over unreliable transport that loses a registration on packet loss will drop at irregular times and recover on its own, which is often misread as the platform being unstable.