Let Providers Compete for Your Minutes

You have read the Grandma version. You are comfortable editing configuration files. Now you want to choose a calling provider—or move to a better one—while keeping your Doorman Brain and compatible handsets.

Start with the bill. Then test the connection. Move the important number last.

1. Price the calls your household makes

Export a representative month of call records from your current provider. Count incoming and outgoing minutes separately, and separate international or special-rate destinations. Keep local room-to-room calls and separately configured private-network calls out of the outside-provider total.

For each candidate, calculate:

Monthly outside-calling cost =
  phone-number charges
  + incoming minutes × applicable incoming rates
  + outgoing minutes × applicable destination rates
  + emergency-service charges
  + other recurring fees and taxes

Check billing increments, minimum charges, prepaid funding requirements, and the cost of the destinations you call. A low advertised starting rate is not necessarily the rate for every call. The Telnyx SIP rate card is one example of why direction and destination matter.

Add any chosen Doorman subscription separately. Compare a normal month and a busy month against a flat-rate alternative. Include temporary overlap, setup, and porting charges in the switching decision. Saving a dollar a month may not justify hours of work; better reliability might.

2. Check that the provider fits the Brain

A consumer calling app is not automatically a SIP service your Brain can use. Ask about credential-based SIP registration, inbound-number routing, supported codecs, NAT behavior, and emergency calling for your actual address. Check those answers against the Doorman provider runbook.

The project’s trunk configuration example includes VoIP.ms and Telnyx examples. Treat them as configuration starting points; confirm current pricing, coverage, and account requirements directly with the provider.

Use a SIP sub-account or connection credential for the Brain. It should not need your main billing login to place calls.

3. Stage the new connection beside the old one

Back up your working configuration and keep a copy off the Brain. Include your policies, handset assignments, provider configuration, and the active Asterisk files under /etc/asterisk/. Protect copies containing credentials.

Open the new provider account and use a temporary number to test it. Keep the old provider and Grandma’s usual number working during setup.

First determine which configuration style you have. A single-provider installation can use a hand-written pjsip.conf with no trunks.toml. That is normal. Moving to generated multi-provider files is a one-time migration; creating a TOML file alone does not switch the running phone system.

For generated configuration:

1. Edit the existing trunks.toml, or use the shipped example as a starting point if you do not have one. Include both the existing provider and the new one. Do not overwrite an existing configuration with the example.
2. Give each trunk a unique id, the provider’s actual host and SIP username, and a password_env naming its secret in .env. The password itself stays out of TOML. Retain the established emergency-trunk selection while staging.
3. Assign a test line its temporary number and matching trunk ID. Both [line] number and [line] trunk are required for the generated route. Keep the primary line unchanged until the new connection is ready.

From the installation directory, run as the user that owns your Doorman configuration:

cd /opt/call-me-maybe
./bin/doorman check
./bin/doorman render

Resolve validation errors before installing anything. Rendering generates files; it does not prove that Asterisk has loaded them.

4. Apply the generated configuration completely

Follow the runbook’s “Switch Asterisk over to the generated files” step for your installed version. On the first migration, reconcile the existing PJSIP registrations and inbound contexts with the generated replacements, enable their includes, and confirm the shared cmm-outbound context and DEFAULT_TRUNK setting. Preserve your local dialplan changes.

Deploy the updated handset files as well as the trunk files: the generated handset configuration carries each handset’s outbound-trunk assignment. Installing only the new provider registrations can leave calls taking the old route. Keep generated credential files readable only by the appropriate system users; do not paste them into a public issue.

Once the files and includes are in place:

sudo asterisk -rx 'pjsip reload'
sudo asterisk -rx 'dialplan reload'
sudo asterisk -rx 'pjsip show registrations'
sudo asterisk -rx 'dialplan show cmm-emergency'

Expect both intended registrations to be registered. Compare the emergency route Asterisk loaded with the route doorman check reported. On a generated multi-provider installation, a missing cmm-emergency context means the migration is incomplete.

5. Test before trusting it

Call every number from an outside phone and make an outgoing call from each line. Check audio in both directions, keypad responses, voicemail, and another incoming call after the system has been idle.

For outgoing calls, verify both the number shown on the receiving phone and the new provider’s call records. A connected call alone does not prove it used the intended provider.

Review emergency calling separately. Setting e911 = true declares a configuration fact; it does not register your address with a carrier. Confirm the address and activation in the provider portal, review fallback trunks, and use the provider’s approved verification procedure rather than an unscheduled emergency call. The emergency-routing documentation explains the fallback behavior. Keep another way to reach emergency services during internet or power outages.

6. Transfer the number, then retire the old service

Ask the receiving provider to confirm portability and start the transfer. Have the current account details and requested ownership documents ready. Follow its instructions: Telnyx’s port-in guide describes its process.

Keep the old number active until the transfer completes. VoIP.ms’s porting guidance explicitly warns against cancelling first. Plan for a transition window; a number transfer is not a promise of uninterrupted service.

At cutover, update the appropriate line’s number and trunk, validate, render, deploy the affected files, and repeat the call tests with the real number. Only after the transfer and tests succeed should you retire unused registrations, temporary numbers, and remaining old-provider services. Check the final bills rather than assuming porting cancels everything.

Before a port, restoring your saved configuration can restore the old setup. After a port, restoring files does not move the number back; that requires coordination with the carriers.

7. Make the small bill easy to maintain

Enable provider balance alerts and a suitable replenishment arrangement if you use prepaid service. A depleted account can interrupt calls. Review the first full bill against your estimate, then check rates and service occasionally instead of making provider shopping a household chore.

The aim is to let providers earn your business while Grandma keeps the phone she likes.

Configuration steps checked against the public project documentation on October 15, 2026. This guide was not validated through a live carrier migration. Use the runbook matching your installed version when applying changes.