SIP Registration: PBX Extension vs Provider Account

A PBX extension and a provider SIP account are the same thing to the SIP protocol: a client sends a REGISTER request with a username and password to a server, and the server remembers where to reach that client. The differences are practical. With a PBX extension, someone in your organisation creates the credentials, the PBX offers star feature codes, NAT is usually solved with a VPN or a setting on the PBX, and the server should not be exposed to the internet. With a provider account, the provider issues the credentials, there are usually no feature codes, the server is on the public internet and NAT must be handled on the client with STUN and ICE. In a softphone such as SIPdia both fill the same Server, Transport, Username and Password fields.

This article walks through each difference and ends with a field-by-field mapping.

What a SIP registration is

RFC 3261 defines registration as the way a user agent tells a registrar where it can be reached. The client sends REGISTER with an address of record such as sip:1002@pbx.example.com. The server challenges with a 401 response, the client repeats the request with a digest of the password, and the server stores the binding between the address of record and the client's current network address. The binding expires after a set time, so the client refreshes it regularly. Every softphone, desk phone and PBX trunk that uses a password works this way. Whether the registrar is a PBX in a server room or a provider's cluster changes nothing about the exchange.

Where the credentials come from

PBX extension. The PBX administrator creates an extension in the PBX web interface. On Asterisk-based systems such as Issabel and FreePBX this is a short number (for example 1002) and a secret. The administrator chooses the transport, codecs and NAT settings for the extension, and also decides whether the PBX is reachable from outside the office. If something does not work, the administrator can look at the PBX logs and change the extension's settings.

Provider account. The provider creates the account when you sign up and shows the details in a portal: the SIP server (also called registrar or proxy), sometimes an outbound proxy or a separate domain, the username (often your phone number or an account ID), the password and sometimes an auth username. You cannot change the server-side settings beyond what the portal exposes, and the provider's support team is your only view into the server logs.

A useful habit is to test each kind with a second client before blaming the softphone. For a PBX, register the extension with any other softphone; for a provider, check the portal's registration status page if it has one.

Feature codes

Feature codes, also called star codes, are short dial strings that a PBX dial plan interprets as commands instead of calls. On Asterisk-based PBXs the common ones are *72 plus a number to forward all calls, *73 to cancel, *78 and *79 for Do Not Disturb, and *97 for voicemail. They exist because the PBX owns the dial plan and can add any shortcut it likes.

Providers rarely implement star codes. Forwarding, voicemail greetings and Do Not Disturb are set in the provider's web portal, and dialling *72 on a provider account usually gives a failure tone or a "number not in service" announcement.

For a softphone this means two things. A PBX extension can control forwarding and Do Not Disturb from the app, because the app dials the codes for you and the PBX stores the result. A provider account needs those codes cleared, so the app does not try to dial them, and the voicemail code set to the provider's voicemail number. SIPdia keeps the codes per account under Settings > Feature Codes for exactly this reason. See SIPdia and Issabel for where to check the codes on the PBX.

NAT handling

Both kinds of account face the same problem: a client behind a router has a private address, and SIP messages carry that address inside them. The server then sends audio to a place it cannot reach, and you get one-way or no audio. The usual solutions differ.

PBX extension. The classic answer is to keep the PBX and the client on the same network, or to join the office network over a VPN. Then no addresses are translated and no NAT handling is needed. When a client must connect from outside, the PBX side has settings for it: on Asterisk chan_sip, nat=yes makes the PBX send audio back to the address packets actually arrived from; on PJSIP, force_rport, rtp_symmetric and rewrite_contact do the same. These are documented in the Asterisk documentation.

Provider account. The provider's server is on the public internet and you cannot change its settings, so NAT is handled on the client. A softphone uses STUN (RFC 5389) to learn its public address and ICE (RFC 8445) to test several candidate paths and pick the one that works. Many providers also run media relays on their side to help clients that cannot be reached directly.

In SIPdia, STUN server and ICE are per-account Advanced fields. A PBX extension over a VPN can leave them empty while a provider account on the same device has STUN and ICE turned on.

Security exposure

PBX extension. A PBX that listens for SIP on the internet is scanned and brute-forced constantly, so the usual advice is not to expose the SIP port at all. Keep the PBX reachable only from the office network or through a VPN, or restrict it with an IP allow-list, and run a tool such as fail2ban to block repeated failed registrations. The upside is that your calls and passwords never cross the public internet unprotected, even over UDP.

Provider account. The provider's server has to be reachable from everywhere, so the provider carries the burden of hardening it. Your part is to protect the connection: choose TLS for signalling when the provider offers it and require SRTP for audio, so credentials and voice are encrypted on the way to the provider. Use a strong, unique SIP password, since anyone who guesses it can make calls at your expense.

How the fields map in SIPdia

The same Account page serves both kinds. The table shows where each value goes.

SIPdia field	PBX extension	Provider account
Server	PBX host or IP, with :port if the PBX does not use the default	Registrar, SIP server or SIP host from the portal, with :port if non-standard
Transport	Usually UDP; TLS only if the PBX has a public CA certificate	Whatever the provider lists; prefer TLS
Username	Extension number	Phone number or account ID from the portal
Password	Extension secret	SIP password (not the portal login)
Display name	Your name, if the PBX passes it on	Often replaced by the provider with your number
Domain (Advanced)	Rarely needed	Only if the SIP domain differs from the server host
Outbound proxy (Advanced)	Rarely needed	Only if the provider lists a separate proxy
Auth username (Advanced)	Rarely needed	If the portal lists an authentication ID
STUN server and ICE (Advanced)	Usually off over a VPN; on if connecting from outside	Usually on, for example stun.l.google.com:19302
Encrypt audio (Advanced)	Off or Optional, unless the PBX supports SRTP	Required when the provider supports SRTP
Settings > Feature Codes	Keep the PBX codes (defaults are the common Asterisk codes)	Clear the codes; set voicemail to the provider's number

One thing is the same for both: TLS works only when the server certificate is signed by a public certificate authority. Self-signed PBX certificates are rejected, so a PBX without a public certificate should use UDP or TCP over a VPN.

Which one should you use?

If your organisation runs a PBX, register to it as an extension. You get internal calls, feature codes, voicemail and forwarding that work even when the softphone is closed, and the administrator can help when something breaks. If you need a public number without running any server, a provider account is the direct route: one registration, one monthly bill, settings in a web portal. Many people run both at once, one account for each, and let the softphone's From picker decide which line a call goes out on.

Next steps

• Start with the basics in What is a SIP account?.
• Setting up a provider? Follow How to Connect a Softphone to an ISP or Provider SIP Account.
• Setting up an extension on a Mac? Follow How to Set Up a SIP Softphone on macOS with SIPdia.