VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

DIDforSale SIP trunking: IP authorization, registration, gateways and DID routing evidence

Separate portal-approved IP or FQDN interconnection, SIP-account registration, outbound termination enablement, multiple inbound gateway sources, DID format and PBX routing.

Reviewed 2026-10-22Current DIDforSale IP-interconnection, SIP-account, FreePBX PJSIP, product and customer-agreement pages plus the current Asterisk chan_sip status page were reviewed October 22, 2026. The current account, portal worksheet, order and installed PBX documentation govern where a public example differs. No DIDforSale account, portal role, IP or FQDN record, termination flag, SIP account, credential, registration, DNS answer, gateway, DID route, source packet, international-calling setting, limit, PBX, firewall, call, media stream, emergency call, bill, price, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Choose one interconnection model from the current account

DIDforSale documents two interconnection paths. The IP path authorizes a portal-approved source IP address or FQDN. The SIP-account path creates a domain, username and password and requires activation before a device registers. Preserve the current account, portal role, interconnection record, credential owner, assigned domain and PBX object; do not infer one model from the other.

A green registration indicator is SIP-account evidence, not proof that an IP-authorized trunk should register. Conversely, a saved IP or FQDN record is administrative state rather than proof that a packet arrived from the resolved production address or that a call completed.

Documented service facts

Reviewed 2026-10-22. Compare SIP trunk services →

Authentication

Documented

DIDforSale documents portal-approved IP or FQDN interconnection and a separately activated SIP account with domain, username and password. Preserve one intended model and its owner. For IP interconnection, outbound termination must be enabled on the portal record.

SIP registration

Documented

Registration belongs to the activated SIP-account path and can expose a green portal indicator. An IP-authorized path instead relies on the approved source record. Registration, source authorization, DID routing and call completion remain separate evidence.

Inbound delivery

Documented

DIDforSale publishes multiple inbound gateway sources and says rejecting only some is a common cause of split failures. Reconcile the current list, then preserve provider selection, customer-edge receipt, delivered DID format and first PBX route separately.

Inbound failover

Not verified

Multiple provider gateways support load balance and uptime, but the public pages do not define customer destination priority, retry timer, restoration or established-call survival. Accepting current provider sources is an ingress requirement, not proof of observed failover.

Number and regional availability

Not verified

The current service and pricing pages advertise local and toll-free numbers across more than 13,000 US and Canadian rate centers plus porting. Exact inventory, portability, activation, identity requirements, caller-ID rights and number features remain specific to number, account and date and must be confirmed in the ordering workflow.

Audio codecs

Documented

DIDforSale lists G.711, G.729, u-law and A-law for its SIP trunks. That list does not prove availability on every destination, license entitlement, DTMF behavior or the payload selected by a call. Capture the offer, answer, RTP payloads and any transcoding for each required route.

T.38 fax

Not verified

The reviewed trunk pages do not establish T.38 support, fallback rules or route-specific fax behavior. Separate fax-by-email references and PBX interoperability listings are not proof that a customer trunk negotiates T.38 or carries in-band fax reliably. Qualify the exact number, direction, gateway and approved document set.

Signaling and media encryption

Not verified

Source-IP authorization and DIDforSale's security marketing do not establish TLS signaling, certificate validation, SRTP media or a downgrade policy for this trunk. The reviewed public setup pages do not publish a trunk-specific TLS/SRTP procedure. Obtain supported transports and profiles in writing and verify the negotiated customer-facing leg.

Concurrent calls and call starts

Not verified

DIDforSale says new accounts can have a one-call outbound limit and directs customers to sales to remove limits. This is not a universal channel count or calls-per-second value; preserve current account controls and authorized load-test bounds.

Emergency calling

Not verified

DIDforSale advertises E911 on eligible numbers, while its agreement ties 911 service to two-way SIP trunking and a number purchased from DIDforSale. Confirm activation, validated location, callback behavior and approved test procedure for each account and site.

Pricing model

Documented

DIDforSale publishes pay-as-you-go, channel-based inbound, toll-free, messaging and unlimited-use examples with tiered commitments. Displayed figures are dated public list prices, not an account quote. Preserve direction, number and channel fees, destination rates, billing increment, acceptable-use terms, commitment, taxes and renewal conditions.

Administration and support

Documented

Preserve the portal IP or FQDN record or activated SIP account, termination flag, international-calling state, current gateway set, DID format, account limits, loaded PBX objects and authorized change history. Public FreePBX examples are version-scoped starting points.

SMS and MMS

Not verified

The pricing page says local and toll-free numbers can be SMS/MMS enabled and publishes separate message rates. A voice-capable number or SIP trunk does not establish messaging activation, campaign registration, sender approval, consent, API behavior, throughput or deliverability. Verify the exact number and messaging program independently.

Separate outbound authorization from number routing

For IP interconnection, DIDforSale says the portal record must have termination enabled before it can originate calls. Its troubleshooting guidance also says US and Canada destinations use a 1 prefix plus ten digits, international destinations use 011 plus country code and number, and international calling is disabled by default until the account representative enables it.

Preserve the actual source address, selected portal record, termination flag, international setting, normalized digits, caller identity, outbound host and first response. A registered SIP account, a DID owned by the account or a reachable gateway does not establish outbound authorization.

Accept every current inbound provider source without flattening them

DIDforSale publishes multiple inbound gateway sources and says rejecting some of them is a common cause of intermittent inbound failure. Record the current provider list, DNS answers, customer-edge allow rules, packet source and PBX endpoint or identify match. An allow rule proves neither provider selection nor receipt.

The public IP-based FreePBX example creates separate inbound trunks for provider addresses. That example is evidence of a multi-source handoff, not a universal current list or a reason to allow arbitrary Internet traffic. Reconcile the current first-party list and constrain the smallest supported source and port scope.

Trace the DID format into the first loaded route

DIDforSale's FreePBX examples distinguish local-number routing with a leading 1 from toll-free routing without that prefix. Preserve the exact Request-URI or called identity at the customer edge, the endpoint match, context, normalization and first loaded inbound route rather than creating a broad catch-all.

The reviewed FreePBX pages name version 14.0.5.2 and include both PJSIP and older chan_sip examples elsewhere in the documentation set. Asterisk removed chan_sip in version 21. Treat screenshots and example objects as version-scoped provider handoff evidence, not a current FreePBX paste-in configuration.

Keep provider limits, failover and media as separate evidence

The IP troubleshooting page says new accounts can have an outbound limit of one call and directs customers to sales to remove limits. That is account-policy evidence, not a universal channel count or calls-per-second value. Multiple provider gateway addresses support a redundant ingress design but do not publish customer destination priority, retry timers, restoration or established-call survival.

After signaling succeeds, preserve both SDP bodies, selected codec and DTMF payload, RTP endpoints, NAT translation and packets in each direction. Gateway reachability, registration, answered signaling and decoded audio remain separate observations.

Bind emergency service and commercial terms to the order

DIDforSale advertises E911 on eligible phone numbers, while its service agreement says 911 service is available with two-way SIP trunking products and one of the numbers purchased from DIDforSale. Do not infer activation, location validation, callback behavior or an approved test procedure from a product badge. Complete the provider process for every served location and keep an independent means of reaching emergency services.

Obtain dated commercial terms for directions, numbers, limits, emergency service, taxes and support. The public pages document possible workflows; no account, portal record, call, packet, media stream or emergency result was tested for this guide.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Troubleshooting · Current DIDforSale IP-interconnection, SIP-account, FreePBX PJSIP, product and customer-agreement pages plus the current Asterisk chan_sip status page were reviewed October 22, 2026. The current account, portal worksheet, order and installed PBX documentation govern where a public example differs. No DIDforSale account, portal role, IP or FQDN record, termination flag, SIP account, credential, registration, DNS answer, gateway, DID route, source packet, international-calling setting, limit, PBX, firewall, call, media stream, emergency call, bill, price, availability, compatibility or support response was inspected or tested

DIDforSale has split inbound calls, no outbound calls or the wrong registration route

Trace one DIDforSale failure through interconnection model, portal state, registration or source authorization, gateway receipt, DID format, PBX route and media.

Read guide →
Guide

SIP trunking: numbers, capacity and operational control

Plan the carrier relationship that connects a self-managed PBX to outside calling.

Read guide →
Protocol reference

SIP REGISTER explained

Understand contact bindings, authentication challenges and why registration does not prove calling works.

Read guide →
Guide

SIP trunk IP authentication

Understand source-address trust and the consequences of a WAN address change.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

Assign responsibility for location, routing and outage procedures before rollout.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Troubleshooting · First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call test

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Read guide →
Troubleshooting · Current Sangoma outbound-route guidance, current Asterisk Dial and troubleshooting documentation, and SIP standards reviewed October 5, 2026; no phone, PBX, carrier or live call test

Outbound VoIP calls fail: locate the broken call leg

Classify one failed call, then follow the exact digits through the phone, PBX route, attempted trunk, remote response, answer and media.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →