Registration vs IP Authentication: How Your Carrier Knows It's You

Before your VICIdial server can hand a call to a phone-number provider, the provider has to be sure the call is really coming from you and not from someone trying to ride on your account. There are two common ways to prove that: registration and IP authentication. They solve the same problem in different directions, and the one you pick changes how you fill out the carrier form.

This post explains both methods in plain terms, shows where each lives in the carrier setup, and gives you a quick rule for choosing.

What registration actually does

With registration, your server reaches out to the carrier on a schedule and says "I'm here, and here's my username and password." The carrier remembers your current address and uses it to send inbound calls back to you. In VICIdial this is the Registration string field on the carrier record, and it looks like register => user:pass@host:5060. Because your server initiates the connection, this method works even when your server sits behind NAT (network address translation) on a changing IP, which is why home labs and small offices lean on it.

The trade-off is that registration depends on a username and secret living in your config, and it has to re-register periodically. If the credentials drift or the network blips, the registration drops and calls stop until it recovers. You verify it from the Asterisk CLI with "sip show peers" to confirm the SIP peer shows as registered.

What IP authentication does

With IP authentication, there's no login at all. You tell the carrier the public IP address of your VICIdial server, the carrier adds it to a whitelist on their side, and any call that arrives from that address is trusted. There is no register line and often no secret in the account entry. This is the cleaner option for a dedicated server with a static IP, because there's nothing to expire and nothing to re-register.

The catch is obvious: your IP must be stable. If it changes, your calls stop until you update the whitelist on the carrier portal. On a managed box your IP stays put, so this is usually the lower-maintenance path.

How the decision flows

flowchart TD
  A[New carrier trunk] --> B{Static public IP?}
  B -->|Yes| C{Carrier supports IP auth?}
  B -->|No| D[Use registration string]
  C -->|Yes| E[Use IP authentication]
  C -->|No| D
  D --> F[Add register line + secret]
  E --> G[Whitelist IP on carrier portal]
  F --> H[Set Active=Y]
  G --> H

Filling out the VICIdial carrier record

Either way, the connection still rides on a SIP trunk, so the rest of the carrier form is mostly the same. The account entry defines the SIP peer settings (type, allowed Codec, host, context), and the Dialplan entry tells Asterisk which dialed pattern routes out this trunk. Registration adds one extra field; IP auth leaves it empty and shifts the work to the carrier's portal.

• Registration: fill the registration string, set host=dynamic, include username and secret.
• IP auth: leave the registration string blank, set host to the carrier's IP, drop the secret.
• Both: set the right context for inbound, choose your codec, and only flip Active=Y once the peer shows up in the CLI.

For the full carrier setup walk-through, see the VICIdial carrier integration guide. And once your trunk is up, read how outbound calls find the right carrier to make sure your dialed numbers actually reach it. If you're still picking a provider, our notes on choosing a SIP carrier cover the auth question too.

Which one should you use?

If you run a dedicated server with a fixed public IP, use IP authentication. It's less to maintain and there's no credential to leak. If your IP can change or you can't whitelist on the carrier side, use registration. Most managed VICIdial servers ship with a stable IP, so IP auth is the default we'd reach for.

VICIfast provisions a dedicated server with a static IP in under 40 seconds, so IP authentication just works out of the box. See our pricing to get a branded dialer running with your own carrier today.