Updated

Support / Voice / SIP Trunking / Inconsistent PBX registration

Inconsistent PBX registration.

When a PBX registers some of the time and not others, the fastest path is to verify the small set of settings that actually control registration: credentials, authentication mode, source-IP access, the SIP profile state, and the registration target. Work these checks in order before changing routing or opening a deeper interop investigation.

Free trial Contact us

1. Verify the SIP username, password, and authentication method

Confirm that the PBX is using the SIP username and password assigned to the trunk. Then confirm the authentication method matches the trunk configuration:

  • Digest authentication — the PBX registers with a SIP username and password.
  • IP authentication — VoiceTel identifies the trunk by source IP address; there is no SIP password challenge.

A mismatch here looks like a registration problem even when the network path is healthy.

2. Confirm the VoiceTel infrastructure IPs are allowed

Make sure every VoiceTel infrastructure IP address required for the trunk is present in the PBX, SBC, and firewall access-control lists. Then confirm that the ACL is actually applied to the SIP profile, trunk, or interface handling the registration traffic.

This matters especially on Switchvox: a Switchvox system can have the right IP addresses entered but still reject traffic if the ACL is not attached to the active profile or rule set. Check both parts:

  1. The VoiceTel IP addresses are present.
  2. The ACL containing those addresses is applied to the active SIP path.

3. Restart the SIP profile and verify that it restarted

Restart the SIP profile, gateway, or trunk process on the PBX.

Do not assume the restart completed just because the button was clicked or the command was issued. Confirm that the profile actually restarted and that the PBX attempted a fresh registration afterward — look for a new REGISTER attempt, a new contact binding, or updated registration status in the PBX logs.

4. Reboot the device to clear local in-memory bans

If the configuration is correct but registration still fails, reboot the PBX or edge device. Some PBX platforms, firewalls, and SIP stacks hold temporary in-memory blocks, failed-authentication bans, stale NAT mappings, or cached registration state. A reboot clears the local state and forces a clean registration attempt.

5. Change the registration target

If the PBX still will not register, change the registration domain. Start with the general registration domains:

geo.voicetel.com
bgp.voicetel.com

If the PBX is currently using geo.voicetel.com, test bgp.voicetel.com.

If that does not resolve the issue, register directly to a specific geographic target as a last-ditch test:

sjc.geo.voicetel.com
dfw.geo.voicetel.com
den.geo.voicetel.com
ord.geo.voicetel.com
clt.geo.voicetel.com
nyc.geo.voicetel.com
west.voicetel.com
east.voicetel.com
europe.voicetel.com

Direct geographic targets isolate whether the issue is tied to a specific network path, local routing decision, or POP preference.

When to contact VoiceTel

If registration still fails after these checks, collect the following before opening a ticket:

  • PBX make and model
  • Current registration domain
  • Authentication method in use
  • Source public IP address of the PBX or SBC
  • Timestamp of the most recent failed registration attempt
  • SIP response code, if visible
  • SIP trace or packet capture, if available

With that, VoiceTel engineering can review the registration attempt, confirm whether traffic is reaching the network, and identify whether the failure is credentials, ACL, routing, or SIP interop related.