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

DIDWW SIP trunking: inbound routing, registration, outbound authentication and Caller ID evidence

Separate inbound Static Endpoint and Dynamic Registration delivery from outbound source, digest, dialing, Caller ID, encryption and attempt evidence.

Reviewed 2026-10-23Current DIDWW inbound routing, registration, connectivity, failover, call-log, outbound authentication, Caller ID and emergency documentation was reviewed October 23, 2026. Account configuration, current DNS answers, selected Points of Presence, installed PBX objects, assigned numbers, eligibility, limits and commercial terms remain deployment specific. No DIDWW account, trunk, credential, registration, Contact, address, DNS answer, Point of Presence, DID, Caller ID, emergency record, PBX, firewall, packet, CDR, call, media stream, price, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Keep inbound and outbound trunks as different service objects

DIDWW documents inbound trunks as delivery paths from its numbers to a customer system, while outbound trunks authenticate customer-originated INVITE requests and apply Caller ID, dialing, destination, capacity and spending controls. Preserve direction, trunk identifier, assigned number, authentication method, endpoint and first response instead of treating one successful direction as proof of the other.

Outbound access is not enabled automatically according to the current guide. A saved inbound trunk, active DID or successful registration is therefore not evidence that outbound termination is provisioned, authorized or permitted for the requested destination.

Documented service facts

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

Outbound authentication

Documented

Outbound Credentials & IP-Based authentication combines a matching source range with SIP Digest using realm out.didww.com. IP-Only is support-enabled. Authentication remains separate from allowed Caller IDs and destinations.

SIP registration

Documented

Dynamic Registration uses generated inbound credentials and the current Contact from successful REGISTER requests; the endpoint must refresh before expiry. Static Endpoint delivery does not require registration. Registration history shows successful active intervals, not failed transactions.

Inbound delivery

Documented

Static Endpoint constructs the Request-URI from configured user part, host and optional port; leaving port empty invokes DNS SRV. Dynamic Registration uses the active Contact and can replace its user part with the called DID through Use DID in R-URI.

Inbound failover

Documented

DNS SRV supplies destinations inside one Static Endpoint attempt and one CDR. Trunk Groups can create separate attempt records and reroute only for configured outcomes, timeouts and available capacity; neither moves an established call.

Number and regional availability

Not verified

DIDWW advertises broad international coverage; exact number type, inventory, porting and local regulatory eligibility for the intended location were not verified.

Audio codecs

Documented

The outbound SIP reference lists G.711 A/µ-law, G.729, G.723.1 and GSM. Inbound trunk codec preferences are configurable; actual negotiation and transcoding on the chosen routes need testing.

T.38 fax

Documented

DIDWW documents T.38 and G.711 fax services, with geographic availability dependent on the selected number and route; test the exact equipment and direction.

Signaling and media encryption

Documented

TLS protects the DIDWW-to-customer signaling leg and SRTP protects that media leg. Enabling one does not enable the other or create end-to-end encryption. Restrict outbound source ranges and protect digest credentials.

Call-start capacity

Not verified

Inbound trunks and groups expose simultaneous-call limits; the public pricing page describes outbound concurrency as uncapped, but a calls-per-second commitment or tested burst limit was not verified.

Emergency calling

Documented

Outbound emergency calling requires a verified DID with active Emergency Calling Service and an allowed source number on the outbound trunk. Confirm the site, country and provider-approved test procedure.

Pricing model

Documented

Outbound termination is per-minute; inbound capacity can be metered or flat-rate channels. Number rental, destination rates, minimum balance and optional tier terms must be included in an actual estimate.

Administration and support

Not verified

Current documentation exposes registration history, inbound call logs, routing attempts and trunk controls. Correlate current account state, Call-ID, attempt, CDR and edge evidence; no support, availability or recovery result was measured.

SMS and MMS

Not verified

Messaging is separately marketed, but number-specific eligibility, sender registration and interoperability with this voice trunk were not verified.

Choose Static Endpoint or Dynamic Registration from the actual destination owner

A Static Endpoint trunk builds its Request-URI from the configured user part, host and optional port. An empty port invokes DNS SRV discovery, while a configured port uses address resolution and that port. Dynamic Registration instead uses the Contact supplied by authenticated REGISTER requests and requires refresh before expiry. Choose one method per trunk.

For dynamic delivery, Use DID in R-URI can replace the registered Contact user part with the called DID so the receiving system can distinguish numbers. Preserve the active Contact, Request-URI, called DID and loaded PBX route separately. Registration does not prove number assignment or route acceptance.

Read inbound authorization, transport and media as separate layers

Authentication runs in opposite directions. With Static Endpoint authorization enabled, DIDWW answers the receiving system's digest challenge using credentials stored on the trunk. With Dynamic Registration, the customer authenticates REGISTER to DIDWW using generated trunk credentials. Do not reuse one direction's secret or infer a registration requirement for a static destination.

TLS protects signaling and SRTP protects media on the DIDWW-to-customer leg; enabling one does not enable the other or create end-to-end encryption. SIP OPTIONS establishes endpoint reachability only, not route acceptance, authentication, negotiated codecs, DTMF or two-way media.

Prove outbound trunk selection before changing credentials or source ranges

The current default Credentials & IP-Based method combines an allowed source range with SIP Digest. IP-Only is a support-enabled method and skips the challenge. Where allowed ranges overlap, DIDWW documents IP-Only before Credentials & IP-Based, then the narrowest matching range within a method; failed authentication is rejected rather than falling through to a lower-priority trunk.

Preserve translated source address, matching range, selected trunk, challenge realm out.didww.com, redacted username, nonce sequence and final response. A 401 challenge is a normal digest step; the authenticated retry and authorization controls must be evaluated before calling it a failure.

Separate caller authentication, Caller ID permission and downstream display

DIDWW explicitly separates authenticating the originating system from validating the Caller ID in the SIP From header. After authentication, the number is compared with allowed Caller IDs and the configured mismatch policy; the trunk does not substitute another number. Destination, Caller ID and available coverage then influence route selection.

Caller ID validation does not guarantee display by the destination network. CNAM OUT and STIR/SHAKEN also carry different information and neither replaces the calling number. Preserve the requested number, matched trunk policy, response, identity headers and received display as separate observations.

Correlate failover, attempts, call records and operational limits

Inbound DNS SRV and Trunk Groups are separate resilience mechanisms for call establishment. DNS SRV targets remain inside one call-log record, while a Trunk Group can produce a separate CDR for each member attempt. Rerouting also depends on selected disconnect codes, ringing timeout, member capacity and remaining eligible destinations; it does not move an established call.

Correlate timestamps, Call-ID, destination, attempt number, routing_attempt, is_last_cdr, provider response, edge receipt and PBX result. Keep emergency activation, pricing, capacity, availability and compatibility tied to dated account evidence; the documentation review does not establish any of them for one deployment.

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 DIDWW inbound routing, registration, connectivity, failover, call-log, outbound authentication, Caller ID and emergency documentation was reviewed October 23, 2026. Account configuration, current DNS answers, selected Points of Presence, installed PBX objects, assigned numbers, eligibility, limits and commercial terms remain deployment specific. No DIDWW account, trunk, credential, registration, Contact, address, DNS answer, Point of Presence, DID, Caller ID, emergency record, PBX, firewall, packet, CDR, call, media stream, price, availability, compatibility or support response was inspected or tested

DIDWW static endpoint, registration, outbound authentication or Caller ID is wrong

Trace one DIDWW failure through direction, inbound destination, Contact, source and digest selection, Caller ID policy, provider attempt and PBX evidence.

Read guide →
Troubleshooting · DIDWW failover, trunk-group and response-code documentation updated October 7–8, 2026 was reviewed October 14, 2026; it documents priority, weight, ringing timeout, selected re-routing disconnect codes, capacity controls, DNS SRV and a separate CDR for each routing attempt, but no account, DID, trunk group, endpoint, DNS answer, capacity state, request, response, CDR stream, failover event, media stream or live call was inspected or tested

DIDWW inbound trunk group does not try the next trunk

Prove DID assignment, trunk-group membership, priority and weight, the configured rerouting-code set, ringing timeout, capacity and every DIDWW CDR attempt before changing a working inbound route.

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 →
Guide

SIP trunk IP authentication

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

Read guide →
Protocol reference

SIP REGISTER explained

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

Read guide →
Protocol reference

SIP authentication: challenges and modern digest support

Understand the difference between a normal challenge, failed credentials and an unsupported algorithm.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP DNS discovery: NAPTR, SRV and address records

Understand service selection and failover before hard-coding a SIP server IP address.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

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 →
Hub

VoIP troubleshooting

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

Explore topic →